I am experimenting with optimizing double->text conversion (trying to beat grissu, ryu etc...).
While doing so, I am comparing my results with sprintf outputs. Now I have encountered the above interesting case.
printf("%.15e", 1e23);
(e.g. glibc) prints
9.999999999999999e+22
while my routine prints
1.000000000000000e+23
Now both numbers are the same distance from the "true value" and converting both these values back (e.g. with atof) yields the same double.
However, I believe my result satisfies "round to even" rule (which is the reason it went this way).
Which result is more correct?
1e23 is typically not exactly represented as a double.
The 2 closest choices are:
// %a v %f
0x1.52d02c7e14af6p+76 99999999999999991611392.000000
0x1.52d02c7e14af7p+76 100000000000000008388608.000000
There are both 8388608.0 from 100000000000000000000000.0, one above, one below.
Typically the selected one in tie cases is the even one. (See last bit in hex format.)
99999999999999991611392.000000 is the winner and so an output of "9.999999999999999e+22" is expected.
When printing with more the DBL_DIG (15) significant digits, ("%.15e" prints 16 significant digits) this problem is possible as code is effectively doing a text-double-text round-trip and exceeding what double can round-trip.
I am experimenting with optimizing double->text conversion
I recommend to also use "%a" to gain deeper understanding.