[NumPy-Tickets] [NumPy] #1633: Changeset 8438 breaks ldexp on 64bit/bigendian systems

NumPy Trac numpy-tickets@scipy....
Tue Oct 12 13:53:40 CDT 2010


#1633: Changeset 8438 breaks ldexp on 64bit/bigendian systems
--------------------+-------------------------------------------------------
 Reporter:  nics    |       Owner:  somebody    
     Type:  defect  |      Status:  needs_review
 Priority:  normal  |   Milestone:  1.5.1       
Component:  Other   |     Version:  1.5.0       
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by nics):

 > I don't have big-endian machines at hand, so testing is appreciated
 (although it should work). It works superb! Thank you!

 Just one little note:
 Your new testcase asserts a warning:

 >>> ncu.ldexp(2., imax)
 Warning: overflow encountered in ldexp
 inf

 I know that this is correct, but the other testcases don't output anything
 to stdout/err...

 > I don't actually know what would be the easiest way to force downcast +
 raise overflow error. This is not the only place where this int vs. long
 annoyance has come up. Seems like this could  be a useful ufunc feature
 more generally.
 Grep is my friend :) Have a look at arraytypes.c.src.
 LONG_to_INT is already in there, but it is autogenerated and doesn't check
 for overflows.
 At the moment, this conversion is not allowed, see the whitelist of
 allowed conversions in PyArray_CanCastSafely (the long switch statement at
 the end, cancastto==NULL for the builtins).

 I think the way to go here is to make the conversion functions in
 arraytypes.c check for overflows and possibly throw and allow that
 conversion in PyArray_CanCastSafely. But since this is a major design
 decision (for implicit conversions users would possibly encounter
 OverflowErrors they don't understand), it doesn't belong into this bug
 report, I guess.
 At the moment your diff fixes the issue very well.

 > I think the reason why Numpy's default integer type is `long` is that
 the Python integer type is also `long`. So we probably inherited the
 default from there.
 Good point

-- 
Ticket URL: <http://projects.scipy.org/numpy/ticket/1633#comment:8>
NumPy <http://projects.scipy.org/numpy>
My example project


More information about the NumPy-Tickets mailing list