Recent work for branch cuts / C99 complex maths: problems on mingw
Hi, I was away during the discussion on the updated complex functions using C99, and I've noticed it breaks some tests on windows (with mingw; I have not tried with Visual Studio, but it is likely to make things even worse given C support from MS compilers): http://scipy.org/scipy/numpy/ticket/865 Were those changes backported to 1.1.x ? If so, I would consider this as a release blocker, cheers, David
On Mon, Jul 28, 2008 at 10:29 PM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:
Hi,
I was away during the discussion on the updated complex functions using C99, and I've noticed it breaks some tests on windows (with mingw; I have not tried with Visual Studio, but it is likely to make things even worse given C support from MS compilers):
http://scipy.org/scipy/numpy/ticket/865
Were those changes backported to 1.1.x ? If so, I would consider this as a release blocker,
The only changes to the computations were in acosh and asinh, which I think should work fine. The tests check branch cuts and corner cases among other things and are only in the trunk, so we aren't any worse off than we were, we just have more failing tests to track down. At least one previous failing tests looked to be a Python bug, so finding the root causes here and putting together tests that work everywhere is going to be a project. Some of the problems could be in the windows library, probably sqrt and log. Other problems might be in notations for nans and infs. Anyway, it would be nice to make all these things platform independent but I don't think we should worry about that for 1.1.1. Chuck
Charles R Harris wrote:
On Mon, Jul 28, 2008 at 10:29 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp <mailto:david@ar.media.kyoto-u.ac.jp>> wrote:
Hi,
I was away during the discussion on the updated complex functions using C99, and I've noticed it breaks some tests on windows (with mingw; I have not tried with Visual Studio, but it is likely to make things even worse given C support from MS compilers):
http://scipy.org/scipy/numpy/ticket/865
Were those changes backported to 1.1.x ? If so, I would consider this as a release blocker,
The only changes to the computations were in acosh and asinh, which I think should work fine. The tests check branch cuts and corner cases among other things and are only in the trunk, so we aren't any worse off than we were, we just have more failing tests to track down.
Ok. I though there was more than just tests, but also C code modification. If not, it is certainly much less of a problem.
At least one previous failing tests looked to be a Python bug, so finding the root causes here and putting together tests that work everywhere is going to be a project. Some of the problems could be in the windows library, probably sqrt and log.
One thing is that mingw now uses ancient gcc (3.4.5), and there was a lot of changes since then for C99 conformance. We can just pretend the problem is not there for now, but for 2.6, we will have to handle this, because mingw with gcc 3.4 does not have a runtime compatible with MSVC 9, which is the one used by python2.6 binary release. That will be a lot of fun :) cheers, David
Tue, 29 Jul 2008 15:17:01 +0900, David Cournapeau wrote:
Charles R Harris wrote:
On Mon, Jul 28, 2008 at 10:29 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp <mailto:david@ar.media.kyoto-u.ac.jp>> wrote:
Hi,
I was away during the discussion on the updated complex functions using C99, and I've noticed it breaks some tests on windows (with mingw; I have not tried with Visual Studio, but it is likely to make things even worse given C support from MS compilers):
http://scipy.org/scipy/numpy/ticket/865
Were those changes backported to 1.1.x ? If so, I would consider this as a release blocker,
The only changes to the computations were in acosh and asinh, which I think should work fine. The tests check branch cuts and corner cases among other things and are only in the trunk, so we aren't any worse off than we were, we just have more failing tests to track down.
Ok. I though there was more than just tests, but also C code modification. If not, it is certainly much less of a problem.
I'm not sure whether it makes sense to keep the C99 tests in SVN, even if marked as skipped, before the C code is fixed. Right now, it seems that we are far from C99 compliance with regard to corner-case value inf-nan behavior. (The branch cuts are mostly OK, though, and I suspect that what is currently non-C99 could be fixed by making nc_sqrt to handle negative zeros properly.) Also, it appears that signaling and quiet NaNs (#IND, #QNAN) are printed differently on mingw32, so that the comparisons should be reworked to treat all nans the same, or the functions should be consistent in which flavor they return. I'm not sure whether IEEE 754 or C99 says something about what kind of NaNs functions should return. But I guess in practice this is not so important, I doubt anyone uses these for anything. -- Pauli Virtanen
Pauli Virtanen wrote:
I'm not sure whether it makes sense to keep the C99 tests in SVN, even if marked as skipped, before the C code is fixed. Right now, it seems that we are far from C99 compliance with regard to corner-case value inf-nan behavior. (The branch cuts are mostly OK, though, and I suspect that what is currently non-C99 could be fixed by making nc_sqrt to handle negative zeros properly.)
Is there a clear explanation about C99 features related to complex math somewhere ? The problem with C99 is that few compilers implement it properly. None of the most used compilers implement it entirely, and some of them don't even try, like MS compilers; the windows situations is the most problematic because the mingw32 compilers are old, and thus may not handle than many C99 features. There are also some shortcuts in the way we detect the math functions, which is not 100 % reliable (because of some mingw problems, in particular: I have already mentioned this problem several times, I really ought to solve it at some points instead of speaking about it). So what matters IMHO is the practical implications with the compilers/C runtime we use for numpy/scipy (gcc, visual studio and intel compilers should cover most of developers/users). cheers, David
Tue, 29 Jul 2008 20:16:36 +0900, David Cournapeau wrote: [clip]
Is there a clear explanation about C99 features related to complex math somewhere ? The problem with C99 is that few compilers implement it
The C99 standard (or more precisely its draft but this is probably mostly the same thing) can be found here: http://www.open-std.org/jtc1/sc22/wg14/www/standards
properly. None of the most used compilers implement it entirely, and some of them don't even try, like MS compilers; the windows situations is the most problematic because the mingw32 compilers are old, and thus may not handle than many C99 features. There are also some shortcuts in the way we detect the math functions, which is not 100 % reliable (because of some mingw problems, in particular: I have already mentioned this problem several times, I really ought to solve it at some points instead of speaking about it).
So what matters IMHO is the practical implications with the compilers/C runtime we use for numpy/scipy (gcc, visual studio and intel compilers should cover most of developers/users).
We implement the complex functions completely ourselves and use only the real C math functions. As we compose the complex operations from real ones, corner cases can and apparently go wrong even if the underlying compiler is C99 compliant. The new Python cmath module actually implements the corner cases using a lookup table. I wonder if we should follow... -- Pauli Virtanen
On Tue, Jul 29, 2008 at 5:59 AM, Pauli Virtanen <pav@iki.fi> wrote:
Tue, 29 Jul 2008 20:16:36 +0900, David Cournapeau wrote: [clip]
Is there a clear explanation about C99 features related to complex math somewhere ? The problem with C99 is that few compilers implement it
The C99 standard (or more precisely its draft but this is probably mostly the same thing) can be found here:
http://www.open-std.org/jtc1/sc22/wg14/www/standards
properly. None of the most used compilers implement it entirely, and some of them don't even try, like MS compilers; the windows situations is the most problematic because the mingw32 compilers are old, and thus may not handle than many C99 features. There are also some shortcuts in the way we detect the math functions, which is not 100 % reliable (because of some mingw problems, in particular: I have already mentioned this problem several times, I really ought to solve it at some points instead of speaking about it).
So what matters IMHO is the practical implications with the compilers/C runtime we use for numpy/scipy (gcc, visual studio and intel compilers should cover most of developers/users).
We implement the complex functions completely ourselves and use only the real C math functions. As we compose the complex operations from real ones, corner cases can and apparently go wrong even if the underlying compiler is C99 compliant.
The new Python cmath module actually implements the corner cases using a lookup table. I wonder if we should follow...
We also need speed. I think we just say behaviour on the branch cuts is undefined, which is numerically true in any case, and try to get the nan's and infs sorted out. But only if the costs are reasonable. Chuck
Tue, 29 Jul 2008 08:13:23 -0600, Charles R Harris wrote: [clip]
We also need speed. I think we just say behaviour on the branch cuts is undefined, which is numerically true in any case, and try to get the nan's and infs sorted out. But only if the costs are reasonable.
Well, the branch cut tests have succeeded on all platforms so far, which means the behavior is numerically well-defined. I doubt we can lose any speed by fixing sqrt in this respect. The inf-nan business is the one causing problems. Lookup tables might solve the problem, but they add a few branches to the code even if the arguments are finite. -- Pauli Virtanen
On Tue, Jul 29, 2008 at 8:38 AM, Pauli Virtanen <pav@iki.fi> wrote:
Tue, 29 Jul 2008 08:13:23 -0600, Charles R Harris wrote: [clip]
We also need speed. I think we just say behaviour on the branch cuts is undefined, which is numerically true in any case, and try to get the nan's and infs sorted out. But only if the costs are reasonable.
Well, the branch cut tests have succeeded on all platforms so far, which means the behavior is numerically well-defined. I doubt we can lose any speed by fixing sqrt in this respect.
Because of the discontinuity, roundoff error makes the behaviour undefined. It's just a fact of computational life. I suspect we mean slightly different things by "numerically" ;) Chuck
participants (3)
-
Charles R Harris -
David Cournapeau -
Pauli Virtanen