in reply to Re^2: RFC: Large Floating Point Numbers - Rounding Errors (absolutely not rounding mode)
in thread RFC: Large Floating Point Numbers - Rounding Errors
Well, you got rather quiet on the subject
When the discussion turns from attempting to solve the OPs problem, to either a pissing contest or a witch hunt, participating further is of little purpose.
The reason you got results more to your liking is purely due to computing 0.000035 using repeated additions rather than using the constant 0.000035 directly.
So, what you are saying is, my "mistake" (or "cheat") was that I used numbers for (shock horror!) computation.
Obviously, the affect of the float point processors rounding mode will only have a significant affect if you actually perform some -- ta-da! -- floating point calculations.
I guess you could term sprintf "%.5f", '0.000035'; a calculation, but given that '0.00004'; is just easier and clearer, you have to wonder at the purpose.
Rounding (and the effects of rounding mode upon it) only becomes meaningful when outputting the results of a computation. And it isn't just addition, it is all operations.
There are an infinite number of calculations, that in an ideal world would produce exactly 0.000035. Some of them will round out one way, and some the other:
printf "%.23f : %.5f\n", $_, $_ for 0.000005 * 7;; 0.00003500000000000000400 : 0.00004 printf "%.23f : %.5f\n", $_, $_ for 0.000007 * 5;; 0.00003499999999999999700 : 0.00003
The truncation of a 6 sig.fig constant to a 5 sig.fig. string is the least interesting -- read: pointless -- of them all.
And using the appropriate rounding mode, not just for the final calculation, but also all intermediate terms becomes very important as the number and complexity of the operations involved increases.
I stick by my statement that a 64-bit IEEE 754 floating point value is perfectly capable of storing 0.000035 to sufficient accuracy that it can be rounded correctly, for any mathematically significant purpose.
|
|---|