Discussion:
[Numpy-discussion] PR for complex np.interp, question about assert_almost_equal
Peter Creasey
2015-12-21 23:55:48 UTC
Permalink
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
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
Ralf Gommers
2015-12-22 06:42:25 UTC
Permalink
On Tue, Dec 22, 2015 at 12:55 AM, Peter Creasey <
Post by Peter Creasey
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
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?
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#L1930.
For what "safe casting" means, see
http://docs.scipy.org/doc/numpy/reference/generated/numpy.can_cast.html

Ralf
Jaime Fernández del Río
2015-12-22 09:06:38 UTC
Permalink
Post by Ralf Gommers
On Tue, Dec 22, 2015 at 12:55 AM, Peter Creasey <
Post by Peter Creasey
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
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?
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#L1930.
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-45aacfd88a495829ee10815c1d02326fL623>
.

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.
Peter Creasey
2015-12-22 09:12:31 UTC
Permalink
Post by Ralf Gommers
assert_almost_equal
TypeError: Cannot cast array data from dtype('complex128') to
dtype('float64') according to the rule 'safe'
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#L1930.
Thanks a lot Ralf! The build log I was looking at (
https://travis-ci.org/numpy/numpy/jobs/98198323 ) really confused me
by not mentioning the function call that wrote the error, but now I
think I understand and can recreate the failure in my setup.

Best,
Peter
Peter Creasey
2015-12-22 23:36:10 UTC
Permalink
Post by Jaime Fernández del Río
Post by Peter Creasey
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
assert_almost_equal
TypeError: Cannot cast array data from dtype('complex128') to
dtype('float64') according to the rule 'safe'
The problem then is probably here
<https://github.com/numpy/numpy/pull/6872/files#diff-45aacfd88a495829ee10815c1d02326fL623>
.
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.
Thanks for your tip Jaime, you were exactly right. Unfortunately I
only saw your message after and addressed the problem in a different
way to your suggestion (passing in a flag instead). It'd be great to
have your input on the PR though (maybe github or pm me, to avoid
flooding the mailing list).

Best,
Peter

Loading...