Re: [Patch, Fortran] Rework of floating point number reading

[Geert Bosch <bosch at adacore dot com>]

Realize that strtod and similar functions nowadays correctly
round input values. This means you'll guaranteed to get the floating
point number closest to the input number. If you do your own
computation using a pow() function, you won't get last-bit
accuracy.

The maximum error of a pow() function result will be 0.5
unit in the last place, so if you then divide or multiply
by that amount, the result may have an error of up to 1 ulp.

Don't expect any regression test suites to show you regressions.
Still, a best-case speed up of 35% is great, but knowing the
answer will always be correct might be worth the price.
For most people, output routines will not take a large amount
of computation time. In that case, you'd need to show a more
compelling reason to give wrong answers.

So, I think that if you're changing floating-point conversion
routines, that you should add some test cases that show some
instances of worst expected rounding and see how you're doing
compared to the existing implementation. Also, test on systems
such as IRIX, HP-UX, AIX or any embedded platform. Those tend
to have crappy math libraries.

  -Geert

DISCLAIMER: This assumes strtod is rounded correctly. Most libraries
currently do, but some systems (esp. embedded/legacy) don't. For many
of those systems, the pow() function is a true disaster, not even
giving a guarantee of a small relative error.