Unhandled floating point exception running test in numpy-1.0.3 and svn 3875
I have just been updating our version of Python, numpy and scipy and have run into a floating point exception that crashes Python when I test the release.
I am running gcc 3.3.1 on SuSe Linux 2.4.21-144-smp4G. The error first occurred with numpy-1.0.3. I downloaded svn 3875 when I then read the scipy web page and installed the latest subversion. The test command I am using is
python -c 'import numpy; numpy.test(level=1,verbosity==2)'
and occurs during the matvec test. This test uses rand to generate 10x8 and 8x1 matrices. The test that multiplies the first matrix by its transpose works; the second test that multiplies the first matrix times the second causes the floating point exception. The code does not crash if the matrices are created with "zero()" but crashes any random matrix generated by rand. It works fine with all of my applications (ones that only multiply 4x4 and 4x1 matrices.
Does anyone know if this is a known problem? I can't find any mention of it on the web. It is cold comfort to know that my applications will fail catastrophically rather than by being inaccurate.
Thanks.
John
Hi John
On Sat, Jun 23, 2007 at 07:35:35PM +0000, John Ollinger wrote:
I have just been updating our version of Python, numpy and scipy and have run into a floating point exception that crashes Python when I test the release.
I am running gcc 3.3.1 on SuSe Linux 2.4.21-144-smp4G. The error first occurred with numpy-1.0.3. I downloaded svn 3875 when I then read the scipy web page and installed the latest subversion. The test command I am using is
python -c 'import numpy; numpy.test(level=1,verbosity==2)'
and occurs during the matvec test. This test uses rand to generate 10x8 and 8x1
It may be worth checking whether the new version of numpy is picked up. You can do that using
import numpy as N print N.__version__
We have a build slave with a very similar setup to yours (see http://buildbot.scipy.org) and everything seems to be fine.
Regards Stéfan
Stefan van der Walt stefan@sun.ac.za [2007-06-23 15:06]:
On Sat, Jun 23, 2007 at 07:35:35PM +0000, John Ollinger wrote:
I have just been updating our version of Python, numpy and scipy and have run into a floating point exception that crashes Python when I test the release.
I am running gcc 3.3.1 on SuSe Linux 2.4.21-144-smp4G. The error first occurred with numpy-1.0.3. I downloaded svn 3875 when I then read the scipy web page and installed the latest subversion. The test command I am using is
python -c 'import numpy; numpy.test(level=1,verbosity==2)'
and occurs during the matvec test. This test uses rand to generate 10x8 and 8x1
It may be worth checking whether the new version of numpy is picked up. You can do that using
import numpy as N print N.__version__
We have a build slave with a very similar setup to yours (see http://buildbot.scipy.org) and everything seems to be fine.
It's somewhat different: SUSE 10.2 Core 2 Duo 32-bit Kernel 2.6.18.2-34-default gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) Python 2.5 (r25:51908, Nov 27 2006 print N.__version__ 1.0.4.dev3868 python -c 'import numpy; numpy.test(level=1,verbosity=2)' [...] Ran 590 tests in 0.473s
OK
-rex
On 6/23/07, rex rex@nosyntax.com wrote:
Stefan van der Walt stefan@sun.ac.za [2007-06-23 15:06]:
On Sat, Jun 23, 2007 at 07:35:35PM +0000, John Ollinger wrote:
I have just been updating our version of Python, numpy and scipy and
have run
into a floating point exception that crashes Python when I test the
release.
What do you mean by crash? Is anything printed? Do older versions of numpy still work?
I am running gcc 3.3.1 on SuSe Linux 2.4.21-144-smp4G. The error first
occurred
with numpy-1.0.3. I downloaded svn 3875 when I then read the scipy
web page and
installed the latest subversion. The test command I am using is
python -c 'import numpy; numpy.test(level=1,verbosity==2)'
and occurs during the matvec test. This test uses rand to generate 10x8 and 8x1
It may be worth checking whether the new version of numpy is picked up. You can do that using
import numpy as N print N.__version__
We have a build slave with a very similar setup to yours (see http://buildbot.scipy.org) and everything seems to be fine.
It's somewhat different: SUSE 10.2 Core 2 Duo 32-bit Kernel 2.6.18.2-34-default gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) Python 2.5 (r25:51908, Nov 27 2006 print N.__version__ 1.0.4.dev3868 python -c 'import numpy; numpy.test(level=1,verbosity=2)' [...] Ran 590 tests in 0.473s
Do you use Atlas? If so, did you compile it yourself or did you use a package? There is a bug in some older 64 bit Atlas packages running on newer intel hardware that generates illegal instruction exceptions and I am wondering if you may have found a new 32 bit bug. One way to check this is to multiply two big matrices together. There are many paths through Atlas, so the known bug is not encountered in all matrix multiplications, and perhaps not for all floating values either.
Chuck
Charles R Harris charlesr.harris@gmail.com [2007-06-24 06:22]:
On 6/23/07, rex rex@nosyntax.com wrote:
Stefan van der Walt <stefan@sun.ac.za> [2007-06-23 15:06]:On Sat, Jun 23, 2007 at 07:35:35PM +0000, John Ollinger wrote:
I have just been updating our version of Python, numpy and scipy and have run into a floating point exception that crashes Python when I test the release.
What do you mean by crash? Is anything printed? Do older versions of numpy still work?
John needs to respond to this.
I am running gcc 3.3.1 on SuSe Linux 2.4.21-144-smp4G. The error first occurred with numpy-1.0.3. I downloaded svn 3875 when I then read the scipy web page and installed the latest subversion. The test command I am using is >>> python -c 'import numpy; numpy.test(level=1,verbosity==2)' >>> and occurs during the matvec test. This test uses rand to generate 10x8 and 8x1
It may be worth checking whether the new version of numpy is picked up. You can do that using
import numpy as N
> print N.__version__ > > We have a build slave with a very similar setup to yours (see > http://buildbot.scipy.org ) and everything seems to be fine. It's somewhat different: SUSE 10.2 Core 2 Duo 32-bit Kernel 2.6.18.2-34-default gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) Python 2.5 (r25:51908, Nov 27 2006 print N.__version__ 1.0.4.dev3868 python -c 'import numpy; numpy.test(level=1,verbosity=2)' [...] Ran 590 tests in 0.473sDo you use Atlas? If so, did you compile it yourself or did you use a package? There is a bug in some older 64 bit Atlas packages running on newer intel hardware that generates illegal instruction exceptions and I am wondering if you may have found a new 32 bit bug. One way to check this is to multiply two big matrices together. There are many paths through Atlas, so the known bug is not encountered in all matrix multiplications, and perhaps not for all floating values either.
The above system is running the http://buildbot.scipy.org/ buildbot with no errors. It doesn't appear to build ATLAS. It's John's older system (gcc 3.3.1 2.4.21-144-smp4G) -- AFAIK, 2.4.21 was used in SUSE 9.0. Current version is 10.2 -- that is throwing an error, not mine.
-rex
On 6/24/07, rex rex@nosyntax.com wrote:
Charles R Harris charlesr.harris@gmail.com [2007-06-24 06:22]:
On 6/23/07, rex rex@nosyntax.com wrote:
Stefan van der Walt <stefan@sun.ac.za> [2007-06-23 15:06]:On Sat, Jun 23, 2007 at 07:35:35PM +0000, John Ollinger wrote:
I have just been updating our version of Python, numpy and scipy and have run into a floating point exception that crashes Python when I test the release.
What do you mean by crash? Is anything printed? Do older versions of
numpy
still work?
John needs to respond to this.
I am running gcc 3.3.1 on SuSe Linux 2.4.21-144-smp4G. The error first occurred with numpy-1.0.3. I downloaded svn 3875 when I then read the scipy web page and installed the latest subversion. The test command I am using is >>> python -c 'import numpy; numpy.test(level=1,verbosity==2)' >>> and occurs during the matvec test. This test uses rand to generate 10x8 and 8x1
It may be worth checking whether the new version of numpy is picked up. You can do that using
import numpy as N
> print N.__version__ > > We have a build slave with a very similar setup to yours (see > http://buildbot.scipy.org ) and everything seems to be fine. It's somewhat different: SUSE 10.2 Core 2 Duo 32-bit Kernel 2.6.18.2-34-default gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) Python 2.5 (r25:51908, Nov 27 2006 print N.__version__ 1.0.4.dev3868 python -c 'import numpy; numpy.test(level=1,verbosity=2)' [...] Ran 590 tests in 0.473sDo you use Atlas? If so, did you compile it yourself or did you use a
package?
There is a bug in some older 64 bit Atlas packages running on newer
intel
hardware that generates illegal instruction exceptions and I am
wondering if
you may have found a new 32 bit bug. One way to check this is to
multiply two
big matrices together. There are many paths through Atlas, so the known
bug is
not encountered in all matrix multiplications, and perhaps not for all
floating
values either.
The above system is running the http://buildbot.scipy.org/ buildbot with no errors. It doesn't appear to build ATLAS. It's John's older system (gcc 3.3.1 2.4.21-144-smp4G) -- AFAIK, 2.4.21 was used in SUSE 9.0. Current version is 10.2 -- that is throwing an error, not mine.
Sorry, my mistake. And I misread 2.4.21 as 2.6.21, a very recent kernel. Just shows how fast the years pass by.
Chuck
participants (4)
-
Charles R Harris -
John Ollinger -
rex -
Stefan van der Walt