RetroSearch Browse

Wed Apr 25 18:17:23 EDT 2001 · http://mail.python.org/pipermail/python-list/2001-April/105575.html

[Grant Edwards]
> I presume that on typical platforms, it can't be guaranteed
> that float(repr(x)) == x.

[Tim]
> On IEEE-754 platforms whose C I/O libraries meet the minimal IEEE-754
> accuracy requirements for float<->string conversions, it is in fact
> guaranteed that
>
>    float(repr(x)) == x
>
> [for all finite 754 doubles x]

[Grant]
> It certainly seems to be true on RH6.2

Don't know.

> on an AMD K6-2.

The HW isn't important; it's the string<->float C library software that
matters.

> The level of compliance in Unix systems' floating point support
> seems to have improved a lot in the last 10 years.

Yes, but there's no easy black-box way to tell whether string<->float
routines *do* meet the 754 spec's accuracy requirements.  The worst cases for
string<->float are so incredibly rare that you could check doubles at random
for the rest of your life and not bump into a failing case, despite a flawed
implementation.

    http://www.dnai.com/~khanson/ECRBDC.html

is an interesting web page about this.  His reference #7 points to seminal
work Vern Paxson and I did in the area in the early 90's (as the referenced
web page rediscovered later, it's possible (albeit very delicate) to find
*the* worst cases systematically -- except what his C program took a month of
machine time to find, my Python program takes about 2.5 hours to find
<wink>).

so-as-usual-python-is-300x-faster-than-c-ly y'rs  - tim

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-list/2001-April/105575.html below:

Floating point (in)accuracy?