I understand that the internal representation is (probably) floating point. However that is still an assumption of what the internal representation "decimal string" actually is. My point is that using the eq operator targets "decimal string" which has a lower precision (for DWIM reasons?), so you are absolutely right that that method smoothes the rounding errors from floats away

This targeted floating point with high precision.

This is what I (presumably) hope to target with the eq:

I'm not sure if $.11f now shows the exact correct number of decimals (which should be 15 I believe), but as far as I can see this solves OP's problem and that is why I suggested it. Just using eq is in my opinion fine for this particular use case. For the rest floating point is always a pain in the... well, you know

> My point is that using the eq operator targets "decimal string"

Please see Re^3: number comparison with a twist and connected posts to why using == is far better here

Using the small epsilon rounding of stringification is actually a good idea (and not much different to the diff solutions proposed by others) ...

... but one has to first prove that it always works for cents ( which I did)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

So I stole your test here for a moment...

say join "\n", grep { sprintf ("%03d",$_) + 0 ne ($_/1000)*1000 } 0..9
+9999
[download]

I needed to add a + 0 to be able to handle the trailing zero's. The funny thing is that in your case you would need to do the opposite ( "" . value) in case the value undergoes an arithmetic operation.