As a continuation of my efforts to provide packages of python-control and slycot for OpenSUSE ( see python-control/Slycot#82 and python-control/Slycot#83), python-control now starts to build (because python-slycot is avaialble now) but fails on test_pole_mimo in xferfcn_test.py:
[ 269s] ======================================================================
[ 269s] FAIL: Test for correct MIMO poles.
[ 269s] ----------------------------------------------------------------------
[ 269s] Traceback (most recent call last):
[ 269s] File "/home/abuild/rpmbuild/BUILD/control-0.8.2/control/tests/xferfcn_test.py", line 415, in test_pole_mimo
[ 269s] np.testing.assert_array_almost_equal(p, [-2., -2., -7., -3., -2.])
[ 269s] File "/usr/lib64/python2.7/site-packages/numpy/testing/_private/utils.py", line 1017, in assert_array_almost_equal
[ 269s] precision=decimal)
[ 269s] File "/usr/lib64/python2.7/site-packages/numpy/testing/_private/utils.py", line 754, in assert_array_compare
[ 269s] raise AssertionError(msg)
[ 269s] AssertionError:
[ 269s] Arrays are not almost equal to 6 decimals
[ 269s]
[ 269s] (shapes (6,), (5,) mismatch)
[ 269s] x: array([-1.999985+0.000000e+00j, -2.000007+1.271532e-05j,
[ 269s] -2.000007-1.271532e-05j, -7. +0.000000e+00j,
[ 269s] -3. +0.000000e+00j, -2. +0.000000e+00j])
[ 269s] y: array([-2., -2., -7., -3., -2.])
_common_den() strikes again (#194, #206). I see it has the optional argument imag_tol, but it is never used within the function except where it is set to 1e-8 by default.
Any ideas how to fix this? Is the resulting machine precision on theses arches really worse than the x86 build, where this tests fine? Or is there maybe a problem with the slycot / lapack / (open)blas / numpy environment on those build machines?
As a continuation of my efforts to provide packages of python-control and slycot for OpenSUSE ( see python-control/Slycot#82 and python-control/Slycot#83), python-control now starts to build (because python-slycot is avaialble now) but fails on test_pole_mimo in xferfcn_test.py:
_common_den()strikes again (#194, #206). I see it has the optional argumentimag_tol, but it is never used within the function except where it is set to 1e-8 by default.Any ideas how to fix this? Is the resulting machine precision on theses arches really worse than the x86 build, where this tests fine? Or is there maybe a problem with the slycot / lapack / (open)blas / numpy environment on those build machines?