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