[Numpy-discussion] OS X PPC problem with Numpy 1.3.0b1

Robert Pyle rpyle@post.harvard....
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 mailing list