[Numpy-discussion] Int casting different across platforms

[Matthew Brett]

Hi,

On Sat, Nov 5, 2011 at 6:24 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Fri, Nov 4, 2011 at 5:21 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> I noticed this:
>>
>> (Intel Mac):
>>
>> In [2]: np.int32(np.float32(2**31))
>> Out[2]: -2147483648
>>
>> (PPC):
>>
>> In [3]: np.int32(np.float32(2**31))
>> Out[3]: 2147483647
>>
>> I assume what is happening is that the casting is handing off to the c
>> library, and that behavior of the c library differs on these
>> platforms?  Should we expect or hope that this behavior would be the
>> same across platforms?
>
> Heh. I think the conversion is basically undefined because 2**31 won't fit
> in int32. The Intel example just takes the bottom 32 bits of 2**31 expressed
> as a binary integer, the PPC throws up its hands and returns the maximum
> value supported by int32. Numpy supports casts from unsigned to signed 32
> bit numbers by using the same bits, as does C, and that would comport with
> the Intel example. It would probably be useful to have a Numpy convention
> for this so that the behavior was consistent across platforms. Maybe for
> float types we should raise an error if the value is out of bounds.

Just to see what happens:

#include <stdio.h>
#include <math.h>

int main(int argc, char* argv) {
    double x;
    int y;
    x = pow(2, 31);
    y = (int)x;
    printf("%d, %d\n", sizeof(int), y);
}

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?

Cheers,

Matthew