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". 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? For instance, a comparison between the implementation of cmath's sqrt and numpy's sqrt shows that numpy does not check for subnormals. 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? Would there be interest in a pull request that changed the routines to be more compatible with results from cmath? Matti
On Mon, Dec 23, 2013 at 12:14 AM, Matti Picus <matti.picus@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
On Saturday, January 4, 2014, Ralf Gommers wrote:
On Mon, Dec 23, 2013 at 12:14 AM, Matti Picus <matti.picus@gmail.com<javascript:_e({}, 'cvml', 'matti.picus@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
Have you seen https://github.com/numpy/numpy/pull/3010 ? This adds C99 compatible complex functions and tests with build time checking if the system provided functions can pass our tests. I should have some time to get back to it soon, but somemore eyes and tests and input would be good. Especially since it's not clear to me if all of the changes will be accepted. Eric
participants (3)
-
Eric Moore -
Matti Picus -
Ralf Gommers