[Vm-dev] FloatMathPlugin crashes the VM if compiled with gcc optimization

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Dec 27 19:00:38 UTC 2010


2010/12/26 Andreas Raab <andreas.raab at gmx.de>:
>
> On 12/26/2010 10:24 PM, Igor Stasenko wrote:
>>
>> btw, how old that fdlibm portions there?
>> maybe updating it will be a simple solution to that issue?
>
> I've never found any newer release than here:
>
> http://www.netlib.org/fdlibm/
>
>> Oh, and please, can you shed some light on the history, why for
>> floating-point
>> math in Squeak, VM using non-standard math lib, which comes with any C
>> compiler, but instead, a  portions of separate 3rd party library?
>
> You would be surprised to find out just how much the results of the C
> compiler libraries differ when it comes to edge cases. I've run the
> experiment in the past:
>
> Using Python 2.4:
>>>> import math
>>>> math.cos(1.0e32)
>
> WinXP:    -0.39929634612021897
> LinuxX86: -0.49093671143542561
>

Yes, I like this one.

Considering that 1.0e32 is exactly  100000000000000005366162204393472,
my own approximation would be:
(1.0e32 asArbitraryPrecisionFloatNumBits: 53) cos asFloat storeString
-> '0.8108648261576407'

which is in agreement with fdlibm because enough decimals of pi are
considered for computing the modulo
1.0e32 cos storeString
-> '0.8108648261576407'

But considering that 1.0e32 ulp -> 1.8014398509482e16, the least
rounding error leads to an uncertainty interval [-1,1] on this result.
So this kind of computation has no meaning at all, bit identical or
not, and should better be forbidden.
The IEEE 754 conceivers could as well have stated that the right
answer was NaN (meaning undefined here).

Nicolas

> In short, the results *dramatically* vary depending on processor family,
> processor version, C compiler libraries, and so on. None of the libraries
> produce cross-platform bit-identical results. fdlibm does.
>
> Cheers,
>  - Andreas
>


More information about the Vm-dev mailing list