Something I learned is that basically all platforms claim wonderful IEEE 
functionality, but in practice the standard is followed only to a 
certain extent.  In addition, there are wonderful examples of how your 
mileage may vary.  For example...

* The only platform on which I saw sensible arcTan functionality was 
IRIX on RISC.

* On HPUX, doing something like 10d "or a Squeak's float" raisedTo: 
-306, followed by floorLog10, results in 306.  But it fails with 307. 
It works on Windows, Mac, Linux, AIX, IRIX/RISC (when we supported it 
--- the platform is being phased out by Silicon Graphics), etc.  Why?

* Some platforms provide .h files with handy definitions for IEEE 
related functions such as isinf(), isnan(), isfinite() and the like. 
But different versions of the operating system will provide different 
compilation environments.  Consequently, whether you can use such things 
in your code depends on the compilation environment.  And if you upgrade 
the compiler environment but then do that too much, then you don't 
support supported versions of the OS in question.

* x86 FPUs are known to have a somewhat imprecise approximation of pi, 
which in turn affects the trigonometric transcendentals.  This problem 
was fixed back in the early nineties by AMD, but it was rolled back 
because of compatibility concerns.  The 32 bit x86 FPU was never fixed. 
  Supposedly, the 64 bit FPU uses the new pi approximation.  Of course, 
that may mean that you won't get the same floating point results in 32 
and 64 bits.

* Also, on x86, you will get different results if you let the FPU use 
the extended double format that enlarges the mantissa to 64 bits.  So, 
if you keep doing calculations in the FPU, the effects of rounding will 
be different than if you put in some value in the FPU, do the 
calculation, and get the intermediate value out, thus truncating the 
extended double format to the normal double format.  Of course leaving 
the doubles in the FPU is faster, but then you get different results 
unless you twiddle the control bits of the FPU.  Which, OBTW, 64 bit 
Windows defaults to the extended format.

* On the Mac, you get different trigonometric transcendental results 
between 10.4 and 10.6.

And this is just a sample of the wonderful world of IEEE and floating 
point arithmetic.

On 12/27/10 11:09 , Nicolas Cellier wrote:
> It seems that
>      1.0 exp = (Float classPool at: #E)
> is now false with the fdlibm version, at leat on Cog/MacOSX.
>
> (Float classPool at: #E) is the closest Float approximation of e,
> which you can check with:
> (1.0 asArbitraryPrecisionFloatNumBits: 200) exp asFloat = (Float
> classPool at: #E)
>
> It's bad that fdlibm be able to compute (1.0e32 cos) with less than
> 1/2 ulp error, but (1.0 exp) with more than 1/2 ulp !
>
> Nicolas
>
>