Description
Original ticket http://projects.scipy.org/numpy/ticket/1633 on 2010-10-11 by @nstange, assigned to unknown.
Testsuite fails with:
FAIL: test_ldexp (test_umath.TestLdexp)
Traceback (most recent call last):
File "/pf/m/m222086/xas/solaris10/64/python2/python-2.7-ve0-gcc/lib/python2.7/site-packages/numpy/core/tests/test_umath.py", line 391, in test_ldexp
assert_almost_equal(ncu.ldexp(2., 3), 16.)
File "/pf/m/m222086/xas/solaris10/64/python2/python-2.7-ve0-gcc/lib/python2.7/site-packages/numpy/testing/utils.py", line 463, in assert_almost_equal
raise AssertionError(msg)
AssertionError:
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:
http://projects.scipy.org/numpy/changeset/8438
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