[squeak-dev] Re: [ANN] Number comparison, hash, NaN, Point, and other partially ordered sets

Bert Freudenberg bert at freudenbergs.de
Fri Jan 9 15:20:20 UTC 2009


On 09.01.2009, at 05:31, Tim Olson wrote:

>
> On Jan 8, 2009, at 9:30 AM, Hans-Martin Mosner wrote:
>
>> AFAIK, the Croquet project needs to have exactly reproducible float
>> arithmetics on all platforms. Would these rounding effects on the x86
>> affect that goal (perhaps with denormal intermediate results)?
>
> Yes.
>
>> Maybe it would be nice to write a unit test which would uncover
>> different rounding behaviors between purely-double-precision FP  
>> hardware
>> and extended-precision hardware.
>
> I'd have to play around a bit to get this into a Squeak unit test,  
> but here's a test vector which shows the effect:
>
> 	3ff3208a25e04e87 * 000316dd1d02d1ae
>
> 	x86 result:		0003b16ef930a76e
> 	powerPC result:	0003b16ef930a76f
>
> These are IEEE double-precision floating-point numbers, specified in  
> hex (big-endian) so that they are bit exact (no conversion error  
> from a decimal representation).  The first number is between 1.0 and  
> 2.0, while the second number is a denormal value.  The product shows  
> an lsb difference between an x86 platform (extended-precision FPU)  
> and a PPC platform (double-precision FPU), even when the x86  
> floating-point control word is set to use double-precision rounding  
> for all results.


On my Intel Mac with VM 3.8.17b6 I get ...a76f too, so this is not an  
x86 issue.

a := Float newFrom: #(16r3FF3208A 16r25E04E87).
b := Float newFrom: #(16r000316DD 16r1D02D1AE).
{a hex. b hex. (a*b) hex}

  #('3FF3208A25E04E87' '000316DD1D02D1AE' '0003B16EF930A76F')

I do get ...a76e under Linux (x86 VMWare emulation).

- Bert -





More information about the Squeak-dev mailing list