[xml] Getting crazy with float parsing

[Peter Jacobi <pj walter-graphtek com>]

Strong disagreement alert!

Whereas the standard runtimes (libc and msc) give 
the uninitiated human observers some surprise, they
observe IEEE 754 and output a result differing only
in the least significant digit from the true result.

This can clearly be seen in 2.0/3.0 example, where the
trio error is about 9 times higher than the others.

0.666666666666666666666666... "true"
0.666666666666666629659233    libc
0.666666666666666630000000    msc
0.666666666666667000000000    trio

0.000000000000000037007433    libc error
0.000000000000000036666666    msc error 
0.000000000000000333333334    trio error

So, when a nice looking result is required, specify
fewer digits. 

I am thinking, that it's impossible to give always
a result which is both of highest achieveable
precision and nice-looking - but perhaps it's
possible to improve the AI in trio to cover more
cases.

Regards,
Peter Jacobi



Igor Zlatkovic wrote:
> Hello,
>
> > The latest baseline of trio (v 1.7) now handles these numbers
> appropriately.
> > Consider the following statement
> >
> >   printf("%30.24f\n%30.24f\n%30.24f\n", 39413.80, 1.4, (2.0/3.0));
> >
> > The libc printf on my machine outputs
> >
> >   39413.800000000002910383045673
> >       1.399999999999999911182158
> >
> > whereas trio outputs
> >
> >   39413.800000000000000000000000
> >       1.400000000000000000000000
> >       0.666666666666667000000000
> >
> > Let me know if you want to use this, and I'll upgrade libxml to the latest
> > trio baseline.
>
> The printf in MS C-runtime 7 (XP) gives
>
>     39413.800000000003000000000000
>         1.399999999999999900000000
>         0.666666666666666630000000
>
> which is not much different to what your libc does. I believe trio should be
> used here.
>
> Ciao
> Igor