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 -