Thanks everyone for the responses - I like the solution of storing as cents and just converting to dollars and cents as required best. I believe this is called "normalising". I was hoping for a solution with as little overhead as possible, I suppose 1 multiplication by 100 for every amount on input and one division by 100 for every output is about as good as I can hope for.

But I am still unclear as to why a conversion from a string has inaccuracies - why does (for examples sake) "0.15" convert to 0.1499999999999263575 or such like.

Reading the above mentioned FAQ, I dont understand why low precision floats can't be represented correctly. In the FAQ they state

However, 19.95 can't be precisely represented as a binary floating point number,...,

Why not? Surely there is a bit pattern in the IEEE float format that precisely represents 19.95 (1.995E1). If a float is stored in 32 bits on a particulat platfrom, some bits are for the mantissa and some are for the exponent and sign. If 24 bits store the mantissa, isn't there a bit pattern that precisely represents 1.995 ?

If that is so, why can't the conversion library get that bit exact. The machine can represent 0.15 to however decimal places it stores, why can't the conversion library create the correct representation? I understand that _expressions_ will potentially have inaccuracies, like exp(ln(x)) resulting in something very close but not quite x. But a string literal should (in my utopian view) convert precisely. The only exception to this would be a string literal expressing a value beyound the precision of the platform, OS or perl (most restrictive win's) - e.g. "0.1E-2048" will _probably_ end up being represented as 0.0E0

Anyone have a view why string literal conversion of seemingly inoccuous floats has inaccuracies?

Oh and thanks kudra for removing the br tags - my first post and all <blush>