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

NumPy Trac numpy-tickets@scipy....
Mon Oct 11 13:58:34 CDT 2010

#1633: Changeset 8438 breaks ldexp on 64bit/bigendian systems
 Reporter:  nics    |       Owner:  somebody
     Type:  defect  |      Status:  new     
 Priority:  normal  |   Milestone:  1.5.1   
Component:  Other   |     Version:  1.5.0   
 Keywords:          |  
 Testsuite fails with:
 FAIL: test_ldexp (test_umath.TestLdexp)
 Traceback (most recent call last):
 /site-packages/numpy/core/tests/test_umath.py", line 391, in test_ldexp
     assert_almost_equal(ncu.ldexp(2., 3),  16.)
 /site-packages/numpy/testing/utils.py", line 463, in assert_almost_equal
     raise AssertionError(msg)
 Arrays are not almost equal
  ACTUAL: 2.0
  DESIRED: 16.0
 >>  raise AssertionError('\nArrays are not almost equal\n ACTUAL: 2.0\n
 DESIRED: 16.0')

 The issue has been introduced here:

 The reason is in DOUBLE_ldexp (loops.c.src:1122):
 const int in2 = *(int *)ip2;

 Since ip2 is being cast from (long*) to (int*), and thus in2 (exponent)
 will only receive the first 4 bytes, that is the 4 most significant bytes
 on bigendian, that is zero on 64bit.

 System's ldexp's exp-argument is _always_ an int, and thus in my opinion,
 the correct behaviour is to reject any exp-argument we cannot convert to
 an system's int, that is an np.intc, and adjusting the docs and the
 testsuite rather than silently giving invalid results.

 The attached diff
 - fixes the ldexp_signatures to match the system's ldexp again (broken by
 changeset 8438)
 - adjusts the testsuite to only put in system's ints

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

More information about the NumPy-Tickets mailing list