[Numpy-discussion] OS X PPC problem with Numpy 1.3.0b1
Mon Mar 23 15:22:30 CDT 2009
> PPC stores long doubles as two doubles. I don't recall exactly how
> the two are used, but the result is that the numbers aren't in the
> form you would expect. Long doubles on the PPC have always been
> iffy, so it is no surprise that machar fails. The failure on SPARC
> quad precision bothers me more.
Ah, now I see. A little more googling and I find that the PPC long
double value is just the sum of the two halves, each looking like a
double on its own.
That brought back a distant memory! The DEC-20 used a similar
scheme. Conversion from double to single precision floating point was
as simple as adding the two halves. Now this at most changes the
least-significant bit of the upper half. Sometime around 1970, I
wrote something in DEC-20 assembler that accumulated in double
precision, but returned a single-precision result. In order to insure
that I understood the double-precision floating-point format, I wrote
a trivial Fortran program to test the conversion from double to single
precision. The Fortran program set the LSB of the more-significant
half seemingly at random, with no apparent relation to the actual
value of the less-significant half.
More digging with dumps from the Fortran compiler showed that its
authors had not understood the double-precision FP format at all. It
took quite a few phone calls to DEC before they believed it, but they
did fix it about two or three months later.
More information about the Numpy-discussion