[Numpy-discussion] Solaris Sparc build broken

[Charles R Harris]

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

>
>
> On Thu, Nov 5, 2009 at 12:39 AM, David Cournapeau <
> david at ar.media.kyoto-u.ac.jp> wrote:
>
>> Charles R Harris wrote:
>> >
>> >
>> > On Thu, Nov 5, 2009 at 12:47 AM, Charles R Harris
>> > <charlesr.harris at gmail.com <mailto: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
>> >     <mailto: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>
>> >         <mailto: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>>
>> >         >     <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
>> >         <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.
>>
>> Now that I think about it, if we only support quad precision, double ==
>> long double and 80 bits Intel format, we could just check for the size
>> and be done with it.
>>
>>
> Won't work. For alignment, 80 bits is stored in 128 bits on 64 bit
> machines, the same as quad precision. I've been complaining about not having
> a decent distinction between those two types for several years ;) But the
> runtime determination could just set some function pointers in a jump table
> if you want to simplify the interface.
>
>
Or I suppose you could initialize a structure with the relevant info and
have a function reference it.

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