[Numpy-discussion] Solaris Sparc build broken
David Cournapeau
david@ar.media.kyoto-u.ac...
Thu Nov 5 01:11:23 CST 2009
David Cournapeau wrote:
> 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).
>
Sorry - I forgot 80 bits extended precision format has no implicit bit,
so the relationship between ibeta and number of bits of mantissa is
different in that case.
David
More information about the NumPy-Discussion
mailing list