[Numpy-discussion] OS X PPC problem with Numpy 1.3.0b1
Charles R Harris
Mon Mar 23 15:42:09 CDT 2009
On Mon, Mar 23, 2009 at 2:22 PM, Robert Pyle <firstname.lastname@example.org> wrote:
> > 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.
I wonder if you could get the same service today? Making even one phone call
can be a long term project calling for a plate of cheese and fruit and a
bottle of wine...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion