Repository navigation
test_psd_csd_equal fails for 12 (but not all) of the test_mlab.spectral_testcases on ppc64 (big-endian) #7798
Description
Continuing to work through test failures that happen on Fedora's ppc64 (big-endian), but not on little-endian arches. The last twelve failures are all like this:
======================================================================
FAIL: test_psd_csd_equal (matplotlib.tests.test_mlab.spectral_testcase_Fs4_complex_defaultsided)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/builddir/build/BUILDROOT/python-matplotlib-2.0.0-0.7.rc2.fc26.ppc64/usr/lib64/python2.7/site-packages/matplotlib/tests/test_mlab.py", line 2096, in test_psd_csd_equal
assert_array_equal(Pxx, Pxy)
File "/usr/lib64/python2.7/site-packages/numpy/testing/utils.py", line 813, in assert_array_equal
verbose=verbose, header='Arrays are not equal')
File "/usr/lib64/python2.7/site-packages/numpy/testing/utils.py", line 739, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Arrays are not equal
(mismatch 98.4375%)
x: array([ 6.851587e-11, 5.656909e-11, 6.650227e-11, 1.223443e-10,
1.294211e-10, 4.895139e-11, 4.816325e-11, 2.429269e-10,
3.889598e-10, 2.063253e-10, 1.297648e-11, 4.368301e-10,...
y: array([ 6.851587e-11 +0.000000e+00j, 5.656909e-11 -7.521779e-30j,
6.650227e-11 +3.815069e-29j, 1.223443e-10 +8.121089e-30j,
1.294211e-10 -5.664577e-29j, 4.895139e-11 +1.171260e-28j,...
The twelve classes which fail are:
spectral_testcase_Fs4_complex_defaultsided
spectral_testcase_Fs4_complex_onesided
spectral_testcase_Fs4_complex_twosided
spectral_testcase_Fs4_real_defaultsided
spectral_testcase_Fs4_real_onesided
spectral_testcase_Fs4_real_twosided
spectral_testcase_FsAll_complex_defaultsided
spectral_testcase_FsAll_complex_onesided
spectral_testcase_FsAll_complex_twosided
spectral_testcase_FsAll_real_defaultsided
spectral_testcase_FsAll_real_onesided
spectral_testcase_FsAll_real_twosided
AFAICS, it's all the classes that specify fstims as something other than an empty list in their self.createStim call. All the ones that specify it as an empty list pass.
Obviously for each failure the non-matching arrays are different, but the general failure mode is the same - the values seem to be in some way the same, but the second array has these +foo and -foo bits in it that the first array doesn't. I've no idea what those mean. (To add to all my other admissions, this is the point where I admit I have a history degree and know sod all about math. :>)
Activity
AdamWill commentedon Jan 11, 2017
@QuLogic @tacaswell
AdamWill commentedon Jan 11, 2017
this and #7797 are the last errors I have on my list.
AdamWill commentedon Jan 11, 2017
I tweaked
test_mlab.pyto logarray.dtypefor both arrays, and they differ. For each failure:Pxx dtype: float64
Pxy dtype: complex128
Pxx comes from
psd(), Pxy comes fromcsd(). The docstrings for both those functions say the return array should be "real valued", which I have a vague feeling means the type of the Pxy (csd()) array is wrong, it shouldn't be complex?QuLogic commentedon Jan 11, 2017
I'm not sure if that's what the doc intended, but the implementation of
psdis simply callingcsdand returning the real value of its result. These should be equal if the complex part is zero.These tests are pretty sensitive to machine specs, so I'm not sure if this is really a BE problem considering the complex values shown are really small. I think these tests have failed on 32-bit, Windows, etc...
AdamWill commentedon Jan 11, 2017
OK. So yeah, you're right: the difference is that the complex part seems to always be zero on x86_64, but not on ppc. Here's an example, with the test hacked to print both arrays (so we can compare). On ppc64:
On x86_64 (with the test sabotaged with an
assert True == Falseat the end, so we get the output):AdamWill commentedon Jan 11, 2017
I also note that there's a patch in the package which disables exactly these tests on aarch64, and with that knowledge, it turns out this is a dupe of #7158 .