extended precision hazards

[Eric Grosse]

Since this thread has drawn the link between round-to-53bit in dtoa.c
and Java numerics, it may be worth a minor historical note that the
dtoa.c revision was prompted by testing Inferno numerics
<http://cm.bell-labs.com/inferno/real.pdf>.

Recall from the discussion in February that Inferno insists all
platforms compute in 53 bit precision for portability and lack of
surprises.  (But to avoid the performance penalty that Coonen refers
to, Inferno allows extended exponent range of intermediate results and
allows a built-in nddot() function that uses extended precision
accumulators and fused multiply-add.)

Eric Grosse