[Numpy-discussion] C99 compatible complex number tests fail

[Ralf Gommers]

On Mon, Dec 23, 2013 at 12:14 AM, Matti Picus <matti.picus at gmail.com> wrote:

> Hi. I started to port the stdlib cmath C99 compatible complex number
> tests to numpy, after noticing that numpy seems to have different
> complex number routines than cmath. The work is available on a
> "retest_complex" branch of numpy
> https://github.com/mattip/numpy/tree/retest_complex
> The tests can be run by pulling the branch (no need to rebuild numpy)
> and running
>
> python <path-to-branch>/numpy/core/tests/test_umath_complex.py >
> test.log 2>&1
>
> So far it is just a couple of  commits that run the tests on numpy, I
> did not dive into modifying the math routines. If I did the work
> correctly, failures point to some differences, most due to edge cases
> with inf and nan, but there are a number of failures due to different
> finite values (for some small definition of different).
> I guess my first question is "did I do the tests properly".
>

They work fine, however you did it in a nonstandard way which makes the
output hard to read. Some comments:
- the assert_* functions expect "actual" as first input and "desired" next,
while you have them reversed.
- it would be good to split those tests into multiple cases, for example
one per function to be tested.
- you shouldn't print anything, just let it fail. If you want to see each
individual failure, use generator tests.
- the cmathtestcases.txt is a little nonstandard but should be OK to keep
it like that.

Assuming I did, the next question is "are the inconsistencies
> intentional" i.e. are they that way in order to be compatible with
> Matlab  or some other non-C99 conformant library?
>

The implementation should conform to IEEE 754.

>
> For instance, a comparison between the implementation of cmath's sqrt
> and numpy's sqrt shows that numpy does not check for subnormals.


I suspect no handling for denormals was done on purpose, since that should
have a significant performance penalty. I'm not sure about other
differences, probably just following a different reference.

And I am probably mistaken since I am new to the generator methods of numpy,
> but could it be that trigonometric functions like acos and acosh are
> generated in umath/funcs.inc.src, using a very different algorithm than
> cmathmodule.c?
>

You're not mistaken.


> Would there be interest in a pull request that changed the routines to
> be more compatible with results from cmath?
>

I don't think compatibility with cmath should be a goal, but if you find
differences where cmath has a more accurate or faster implementation, then
a PR to adopt the cmath algorithm would be very welcome.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140104/66968c7c/attachment.html>