Hi, The current trunk has 14 failures on windows (with mingw). 12 of them are related to C99 (see ticket 869). Can the people involved in recent changes to complex functions take a look at it ? I think this is high priority for 1.2.0 thanks, David
David Cournapeau wrote:
The current trunk has 14 failures on windows (with mingw). 12 of them are related to C99 (see ticket 869). Can the people involved in recent changes to complex functions take a look at it ? I think this is high priority for 1.2.0
I'm asking just out of curiosity. Why is NumPy using C99 and what features of C99 are used? The Microsoft compilers aren't supporting C99 and they'll probably never will. I don't know if the Intel CC supports C99. Even GCC doesn't implement C99 to its full extend. Are you planing to restrict yourself to MinGW32? I'm not a NumPy developer but I'm a Python core developer. I've laid the foundation for the VS 2008 build system for 2.6 / 3.0. Marc Dickinson and I have put lots of work into mathematical, numerical and IEEE 754 fixes. The work was mostly based on the C99 specs but we used C89 code. That should explain my interest in the matter. :] Christian
On Fri, Aug 15, 2008 at 7:25 PM, Christian Heimes <lists@cheimes.de> wrote:
David Cournapeau wrote:
The current trunk has 14 failures on windows (with mingw). 12 of them are related to C99 (see ticket 869). Can the people involved in recent changes to complex functions take a look at it ? I think this is high priority for 1.2.0
I'm asking just out of curiosity. Why is NumPy using C99 and what features of C99 are used? The Microsoft compilers aren't supporting C99 and they'll probably never will. I don't know if the Intel CC supports C99. Even GCC doesn't implement C99 to its full extend. Are you planing to restrict yourself to MinGW32?
I believe C99 was used as a guide to how complex corner cases involving +/-0, +/-inf, etc. should behave. However, it doesn't look possible to make that behaviour portable without a lot of work and it probably isn't worth the trouble. At the moment the failing tests have been removed. Chuck
Charles R Harris wrote:
I believe C99 was used as a guide to how complex corner cases involving +/-0, +/-inf, etc. should behave. However, it doesn't look possible to make that behaviour portable without a lot of work and it probably isn't worth the trouble. At the moment the failing tests have been removed.
We used the C99 specs as guideline, too. If I recall correctly mostly Annex F and G. We got it all sorted out but it took us a tremendous amount of time and work. We had to reimplement a bunch of math functions like log1p and the reversed hyperbolic functions. Mark introduced a system of lookup tables for complex corner cases. You can find them at the end of the cmath module: http://svn.python.org/projects/python/trunk/Modules/cmathmodule.c The new pymath files contain a series of macros and re-implemenation of C99 features and cross platform workarounds: http://svn.python.org/projects/python/trunk/Include/pymath.h http://svn.python.org/projects/python/trunk/Python/pymath.c HTH Christian
Hi, Sat, 16 Aug 2008 03:25:11 +0200, Christian Heimes wrote:
David Cournapeau wrote:
The current trunk has 14 failures on windows (with mingw). 12 of them are related to C99 (see ticket 869). Can the people involved in recent changes to complex functions take a look at it ? I think this is high priority for 1.2.0
I'm asking just out of curiosity. Why is NumPy using C99 and what features of C99 are used? The Microsoft compilers aren't supporting C99 and they'll probably never will. I don't know if the Intel CC supports C99. Even GCC doesn't implement C99 to its full extend. Are you planing to restrict yourself to MinGW32?
To clarify this again: *no* features of C99 were used. The C99 specs were only used as a guideline to what behavior we want of complex math functions, and I wrote tests for this, and marked failing ones as skipped. However, it turned out that different tests fail on different platforms, which means that the inf/nan handling of our complex-valued functions is effectively undefined. Eventually, most of the tests had to be marked as skipped, and so it made more sense to remove them altogether. -- Pauli Virtanen
Pauli Virtanen wrote:
To clarify this again: *no* features of C99 were used. The C99 specs were only used as a guideline to what behavior we want of complex math functions, and I wrote tests for this, and marked failing ones as skipped.
Got it.
However, it turned out that different tests fail on different platforms, which means that the inf/nan handling of our complex-valued functions is effectively undefined. Eventually, most of the tests had to be marked as skipped, and so it made more sense to remove them altogether.
We hit the same issue during our work for Python 2.6 and 3.0. We came to the conclusion that we can't rely on the platform's math functions (especially trigonometric and hyperbolic functions) for special values. So Mark came up with the idea of lookup tables for special values. Read my other mail for more informations. Christian
participants (4)
-
Charles R Harris -
Christian Heimes -
David Cournapeau -
Pauli Virtanen