[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