[Numpy-discussion] Solaris Sparc build broken

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Thu, Nov 5, 2009 at 12:47 AM, Charles R Harris
> <charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>> wrote:
>
>
>
>     On Thu, Nov 5, 2009 at 12:09 AM, 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:39 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:
>         >     >
>         >     >
>         >     > 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>>
>         >     <mailto: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).
>
>
>     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@ubuntu ~]$ gcc precision.c
>     $[charris@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.

I much prefer compile time check which do not need to run on the target
machine :)

cheers,

David