Open numpy-gitbot opened 12 years ago
Original ticket http://projects.scipy.org/numpy/ticket/2174 on 2012-06-20 by atmention:matthew-brett, assigned to unknown.
PPC 32-bit on Debian Wheezy, numpy 1.6.2 and current numpy trunk:
In [2]: np.__version__ Out[2]: '1.7.0.dev-651ef74' import numpy as np arr = np.arange(10, dtype=np.complex256) bs_arr = arr.byteswap().newbyteorder('S') print arr print bs_arr print arr - bs_arr print arr - bs_arr print arr - bs_arr
The result of subtraction is wrong most (~90%) of the time; with the byteswapped array acting as if it is all zeros.
(np-devel)[mb312atmention:joshlegacy ~/tmp]$ python funny_bs.py [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j]
About 10% of the time the arrays appear to behave correctly:
(np-devel)[mb312atmention:joshlegacy ~/tmp]$ python funny_bs.py [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j] [ 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j] [ 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j]
More rarely there is a mix of incorrect and correct. Notice below that the first pass of arr - bs_arr is incorrect, and the second and third repeat of exactly the same statement on the same variables are correct.
arr - bs_arr
(np-devel)[mb312atmention:joshlegacy ~/tmp]$ python funny_bs.py [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 1.0+0.0j 2.0+0.0j 3.0+0.0j 4.0+0.0j 5.0+0.0j 6.0+0.0j 7.0+0.0j 8.0+0.0j 9.0+0.0j] [ 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j] [ 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j 0.0+0.0j]
Float128 and other numpy dtypes appear to be correct.
I'm happy to give access to this machine if someone needs to debug.
Original ticket http://projects.scipy.org/numpy/ticket/2174 on 2012-06-20 by atmention:matthew-brett, assigned to unknown.
PPC 32-bit on Debian Wheezy, numpy 1.6.2 and current numpy trunk:
The result of subtraction is wrong most (~90%) of the time; with the byteswapped array acting as if it is all zeros.
About 10% of the time the arrays appear to behave correctly:
More rarely there is a mix of incorrect and correct. Notice below that the first pass of
arr - bs_arr
is incorrect, and the second and third repeat of exactly the same statement on the same variables are correct.Float128 and other numpy dtypes appear to be correct.
I'm happy to give access to this machine if someone needs to debug.