[Numpy-discussion] Solaris Sparc build broken
Charles R Harris
Thu Nov 5 00:52:43 CST 2009
On Wed, Nov 4, 2009 at 11:37 PM, Charles R Harris <firstname.lastname@example.org
> On Wed, Nov 4, 2009 at 10:56 PM, David Cournapeau <email@example.com>wrote:
>> On Thu, Nov 5, 2009 at 4:47 AM, Charles R Harris
>> <firstname.lastname@example.org> wrote:
>> > And it looks like extended precision has disappeared from the latest
>> > or the ieee_754-2008 standard, being replaced by quad precision. I know
>> > Intel is also working on quad precision FPU's, so I think that is where
>> > things are heading.
>> The problem is not so much the format itself, but that it is different
>> for almost every arch, and that it needs to be distinguished between
>> OS and compilers (long double on ia32 does not mean the same thing on
>> mac os x and windows, and does not mean the same thing on windows
>> depending on the compiler and even the compiler option).
>> This sounds like a maintenance nightmare, with tens of configurations
>> to implement (and test). I can't see a simple solution, short of
>> dropping support for long double for any feature which needs knowledge
>> of the exact representation.
> I don't think it's that bad. Leaving out the ppc and sticking to ieee,
> there is only double precision, extended precision and quad precision
> versions of long double and they are easily determined at run time. The ppc
> is the odd one out.
A good place to start is to rip out the routine used by finfo. It's a bit of
crap taken, IIRC, from Numerical Recipes and is way more complicated than
needed to deal with ieee numbers. An exception for PPC can be hardwired in
and the needed data for that is already part of cpu_info.h
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion