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 adouble
.The 2 closest choices are:
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 whatdouble
can round-trip.I recommend to also use
"%a"
to gain deeper understanding.