On Sat, Nov 5, 2011 at 7:35 PM, Nathaniel Smith <[email protected]> wrote:
> On Sat, Nov 5, 2011 at 4:07 PM, Matthew Brett <[email protected]> > 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 [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
