Very strange. I'd almost say that you'd discovered a bug in perl or the underlying C-libraries that was causing the double precision (64-bit) NV value to be transitioned through a single precision (32-bit) float whilst being formatted.
If the values were always being manipulated as doubles, this shouldn't happen.
It could be a that the IEEE rounding mode isn't being set (correctly?).
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
This is not a bug but the result of converting numbers between base 10 and 2.
The problem is that 0.000005, 0.000015, 0.000025, 0.000035, 0.000045, 0.000055, 0.000065, ... can not be represented precisely in base 2:
printf("%.5f %.30f\n", $_, $_) for (0.000005, 0.000015, 0.000025, 0.00
+0035, 0.000045, 0.000055, 0.000065)
| [reply]
[d/l] |
the result of converting numbers between base 10 and 2.
No. It isn't.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
YOU are wrong! Wrong! Wrong!
IEEE 64-bit doubles are perfectly capable of representing these values to sufficient accuracy to allow them to be rounded correctly.
See Re: RFC: Large Floating Point Numbers - Rounding Errors (Rounding mode)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |