[Numpy-discussion] Int casting different across platforms

[Charles R Harris]

On Sat, Nov 5, 2011 at 7:35 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Sat, Nov 5, 2011 at 4:07 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > Intel, gcc:
> > 4, -2147483648
> > PPC, gcc:
> > 4, 2147483647
> >
> > I think that's what you predicted.  Is it strange that the same
> > compiler gives different results?
> >
> > It would be good if the behavior was the same across platforms - the
> > unexpected negative overflow caught me out at least.  An error sounds
> > sensible to me.  Would it cost lots of cycles?
>
> C99 says (section F.4):
>
> "If the floating value is infinite or NaN or if the integral part of
> the floating value exceeds the range of the integer type, then the
> ‘‘invalid’’ floating-point exception is raised and the resulting value
> is unspecified. Whether conversion of non-integer floating values
> whose integral part is within the range of the integer type raises the
> ‘‘inexact’’ floating-point exception is unspecified."
>
> So it sounds like the compiler is allowed to return whatever nonsense
> it likes in this case. But, you should be able to cause this to raise
> an exception by fiddling with np.seterr.
>
> However, that doesn't seem to work for me with numpy 1.5.1 on x86-64 linux
> :-(
>
> >>> np.int32(np.float32(2**31))
> -2147483648
> >>> np.seterr(all="raise")
> >>> np.int32(np.float32(2**31))
> -2147483648
>
> I think this must be a numpy or compiler bug?
>
>
I don't believe the floating point status is checked in the numpy
conversion routines. That looks like a nice small project for someone
interested in learning the numpy internals.

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