PR for complex np.interp, question about assert_almost_equal
Hi all, I submitted a PR (#6872) for using complex numbers in np.lib.interp. The tests pass on my machine, but I see that the TravisCI builds are giving assertion fails (on my own test) with python 3.3 and 3.5 of the form:
assert_almost_equal TypeError: Cannot cast array data from dtype('complex128') to dtype('float64') according to the rule 'safe'
When I was writing the test I used np.testing.assert_almost_equal with complex128 as it works in my python 2.7, however having checked the docstring I cannot tell what the expected behaviour should be (complex or no complex allowed). Should my test be changed or the assert_almost_equal? Best, Peter
On Tue, Dec 22, 2015 at 12:55 AM, Peter Creasey < p.e.creasey.00@googlemail.com> wrote:
Hi all, I submitted a PR (#6872) for using complex numbers in np.lib.interp.
assert_almost_equal TypeError: Cannot cast array data from dtype('complex128') to
The tests pass on my machine, but I see that the TravisCI builds are giving assertion fails (on my own test) with python 3.3 and 3.5 of the form: dtype('float64') according to the rule 'safe'
When I was writing the test I used np.testing.assert_almost_equal with complex128 as it works in my python 2.7, however having checked the docstring I cannot tell what the expected behaviour should be (complex or no complex allowed). Should my test be changed or the assert_almost_equal?
Hi Peter, that error is unrelated to assert_almost_equal. What happens is that when you pass in a complex argument `fp` to your modified `compiled_interp`, you're somewhere doing a cast that's not safe and trigger the error at https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/ctors.c.... For what "safe casting" means, see http://docs.scipy.org/doc/numpy/reference/generated/numpy.can_cast.html Ralf
On Tue, Dec 22, 2015 at 7:42 AM, Ralf Gommers
On Tue, Dec 22, 2015 at 12:55 AM, Peter Creasey < p.e.creasey.00@googlemail.com> wrote:
Hi all, I submitted a PR (#6872) for using complex numbers in np.lib.interp.
assert_almost_equal TypeError: Cannot cast array data from dtype('complex128') to
The tests pass on my machine, but I see that the TravisCI builds are giving assertion fails (on my own test) with python 3.3 and 3.5 of the form: dtype('float64') according to the rule 'safe'
When I was writing the test I used np.testing.assert_almost_equal with complex128 as it works in my python 2.7, however having checked the docstring I cannot tell what the expected behaviour should be (complex or no complex allowed). Should my test be changed or the assert_almost_equal?
Hi Peter, that error is unrelated to assert_almost_equal. What happens is that when you pass in a complex argument `fp` to your modified `compiled_interp`, you're somewhere doing a cast that's not safe and trigger the error at https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/ctors.c.... For what "safe casting" means, see http://docs.scipy.org/doc/numpy/reference/generated/numpy.can_cast.html
The problem then is probably here https://github.com/numpy/numpy/pull/6872/files#diff-45aacfd88a495829ee10815c... . You may want to throw in a PyErr_Clear() https://docs.python.org/3/c-api/exceptions.html#c.PyErr_Clear when the conversion of the fp array to NPY_DOUBLE fails before trying with NPY_CDOUBLE, and check if it goes away. Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
participants (3)
-
Jaime Fernández del Río -
Peter Creasey -
Ralf Gommers