[Numpy-discussion] Solaris Sparc build broken

David Cournapeau david@ar.media.kyoto-u.ac...
Thu Nov 5 01:09:25 CST 2009


Charles R Harris wrote:
>
>
> On Wed, Nov 4, 2009 at 11:39 PM, David Cournapeau
> <david@ar.media.kyoto-u.ac.jp <mailto:david@ar.media.kyoto-u.ac.jp>>
> wrote:
>
>     Charles R Harris wrote:
>     >
>     >
>     > On Wed, Nov 4, 2009 at 11:30 PM, David Cournapeau
>     > <david@ar.media.kyoto-u.ac.jp
>     <mailto:david@ar.media.kyoto-u.ac.jp>
>     <mailto:david@ar.media.kyoto-u.ac.jp
>     <mailto:david@ar.media.kyoto-u.ac.jp>>>
>     > wrote:
>     >
>     >     Charles R Harris wrote:
>     >
>     >     >
>     >     > 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.
>     >
>     >     How would you determine this at runtime ?
>     >
>     >
>     > Excepting the PPC, just loop adding a number to one, dividing it by
>     > two at each iteration, and stop when the result is equal to one.
>
>     But that's not what I need. I need to know exactly the binary
>     representation: how many bits in the mantissa/exponent and where, the
>     exponent, where does subnormals start, the range of NAN
>     representations,
>     etc...
>
>
> It tells you how many bits are in the mantissa, and given ieee the
> rest follows. We only support ieee anyway.

But is this reliable ? It does not seem to work for long double in
intel, for example (but seems to work for sparc64, at least using qemu).

David


More information about the NumPy-Discussion mailing list