[Numpy-discussion] Int casting different across platforms

[Matthew Brett]

Hi,

On Sun, Nov 6, 2011 at 2:39 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> 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  - .

To my shame I doubt that I will have the time to do this, but just in
case I or someone does get time, is there a good place to start to
look?

Cheers,

Matthew