numpy fails trigonometry with complex numbers, what to do?
I am trying to complete complex numbers in numpypy. Progress is good, I picked up from previous work on the numpypy-complex2 branch. Complex numbers come with extensive tests, it seems all the corner cases are covered. In porting the tests to numpypy, I came across a problem: numpy returns different results than cmath. Some of the differences are due to the fact that numpy does not raise a ValueError for dividing by 0 or other silly input values, but other differences are inexplicable (note the sign of the imaginary part):
or this one:
Should I ignore the inconsistencies, or fix the 700 out of 2300 test instance failures? What should pypy's numpypy do - be consistent with numpy or with cmath? cmath is easier and probably faster (no need to mangle results or input args), so I would prefer cmath to trying to understand the logic behind numpy. Matti 2280c2365844
Am 05.09.12 03:30, schrieb Matti Picus:
In NumPy you can change how numerical exception are handled: http://docs.scipy.org/doc/numpy/reference/routines.err.html http://docs.scipy.org/doc/numpy/user/misc.html#how-numpy-handles-numerical-e...
FloatingPointError Traceback (most recent call last) <ipython-input-11-92051afcce38> in <module>() ----> 1 numpy.arccos(complex(float('inf'),2.3))
HTH, Mike
Hi, On Wed, Sep 5, 2012 at 3:30 AM, Matti Picus <matti.picus@gmail.com> wrote:
According to the C99 standard Annex G (draft, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf), the cmath answer is the correct one in both cases. I don't know if that really means that numpy didn't care about the details. It sounds a bit strange given that it has tests for it; I fear it rather means that numpy implemented a different standard. But maybe that's me being too optimistic/pessimistic (depending on the point of view). I would indeed ask on numpy mailing lists or submit a bug entry and see their reaction. A bientôt, Armin.
After more than a year, I am trying to engage with numpy about their non-compliant C99 complex math routines. FWIW, the trigger for this was that we still see failures on our micronumpy -A tests with numpy 1.8. Matti On 09/06/2012 10:12 AM, Armin Rigo wrote:
Am 05.09.12 03:30, schrieb Matti Picus:
In NumPy you can change how numerical exception are handled: http://docs.scipy.org/doc/numpy/reference/routines.err.html http://docs.scipy.org/doc/numpy/user/misc.html#how-numpy-handles-numerical-e...
FloatingPointError Traceback (most recent call last) <ipython-input-11-92051afcce38> in <module>() ----> 1 numpy.arccos(complex(float('inf'),2.3))
HTH, Mike
Hi, On Wed, Sep 5, 2012 at 3:30 AM, Matti Picus <matti.picus@gmail.com> wrote:
According to the C99 standard Annex G (draft, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf), the cmath answer is the correct one in both cases. I don't know if that really means that numpy didn't care about the details. It sounds a bit strange given that it has tests for it; I fear it rather means that numpy implemented a different standard. But maybe that's me being too optimistic/pessimistic (depending on the point of view). I would indeed ask on numpy mailing lists or submit a bug entry and see their reaction. A bientôt, Armin.
After more than a year, I am trying to engage with numpy about their non-compliant C99 complex math routines. FWIW, the trigger for this was that we still see failures on our micronumpy -A tests with numpy 1.8. Matti On 09/06/2012 10:12 AM, Armin Rigo wrote:
participants (4)
-
Armin Rigo -
Maciej Fijalkowski -
Matti Picus -
Mike Müller