Re: [Numpy-discussion] Int casting different across platforms
Hi,
On Sat, Nov 5, 2011 at 6:24 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Nov 4, 2011 at 5:21 PM, Matthew Brett matthew.br...@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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Int casting different across platforms
On Sat, Nov 5, 2011 at 7:35 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Nov 5, 2011 at 4:07 PM, Matthew Brett matthew.br...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Int casting different across platforms
Hi, On Sun, Nov 6, 2011 at 2:39 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Nov 5, 2011 at 7:35 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Nov 5, 2011 at 4:07 PM, Matthew Brett matthew.br...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Int casting different across platforms
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? Thanks for any pointers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
