[Numpy-discussion] Solaris Sparc build broken

Charles R Harris charlesr.harris at gmail.com
Thu Nov 5 02:55:04 EST 2009


On Thu, Nov 5, 2009 at 12:47 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Thu, Nov 5, 2009 at 12:09 AM, David Cournapeau <
> david at ar.media.kyoto-u.ac.jp> wrote:
>
>> Charles R Harris wrote:
>> >
>> >
>> > On Wed, Nov 4, 2009 at 11:39 PM, David Cournapeau
>> > <david at ar.media.kyoto-u.ac.jp <mailto:david at ar.media.kyoto-u.ac.jp>>
>> > wrote:
>> >
>> >     Charles R Harris wrote:
>> >     >
>> >     >
>> >     > On Wed, Nov 4, 2009 at 11:30 PM, David Cournapeau
>> >     > <david at ar.media.kyoto-u.ac.jp
>> >     <mailto:david at ar.media.kyoto-u.ac.jp>
>> >     <mailto:david at ar.media.kyoto-u.ac.jp
>> >     <mailto:david at 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).
>>
>>
> Works fine here:
>
> #include <stdio.h>
>
> int main(int argc, char **args)
> {
>     long double tol;
>     int i;
>
>     for (i = 0, tol = 1; 1 + tol != 1; tol /=2, i++);
>     printf("count: %d\n", i - 1);
>     return 0;
> }
>
>
> $[charris at ubuntu ~]$ gcc precision.c
> $[charris at ubuntu ~]$ ./a.out
> count: 63
>
> That's 63+1 for the mantissa, which is what intel extended precision is.
>
>
Googling around, it seems that the SUN quad precision is done in software,
not hardware and is available but not used by the compilers in the current
Intel based SUN systems, but will be in the next OS version. So it looks
dependent on the compiler, meaning we probably need a run time check.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20091105/8a18162a/attachment.html>


More information about the NumPy-Discussion mailing list