Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numpy numpy.__version__ '1.3.0.dev6005' numpy.test(verbosity=2) ... test_umath.TestLogAddExp.test_logaddexp_values ...
The test hangs at the last line and never progresses further. James
On Tue, Nov 11, 2008 at 10:33 AM, James Philbin
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numpy numpy.__version__ '1.3.0.dev6005' numpy.test(verbosity=2) ... test_umath.TestLogAddExp.test_logaddexp_values ...
The test hangs at the last line and never progresses further.
Ah good, some of the buildbots are doing this also and I'm trying to track it down. I don't see it on my machine. Could you post your compiler version? I suspect a library problem. Meanwhile I'll comment out the offending tests... and add some that might hang in more informative places. Chuck
On Tue, Nov 11, 2008 at 11:00 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Nov 11, 2008 at 10:33 AM, James Philbin
wrote: Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numpy numpy.__version__ '1.3.0.dev6005' numpy.test(verbosity=2) ... test_umath.TestLogAddExp.test_logaddexp_values ...
The test hangs at the last line and never progresses further.
Ah good, some of the buildbots are doing this also and I'm trying to track it down. I don't see it on my machine. Could you post your compiler version? I suspect a library problem. Meanwhile I'll comment out the offending tests... and add some that might hang in more informative places.
Oops, I see your compiler/python version is already there. Mine are Python 2.5.1 (r251:54863, Jun 15 2008, 18:24:51) [GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Can you try checking the functions log1p and exp separately for all three floating types? Something like
import numpy as np np.log1p(np.ones(1, dtype='f')*3) array([ 1.38629436], dtype=float32) np.log1p(np.ones(1, dtype='d')*3) array([ 1.38629436]) np.log1p(np.ones(1, dtype='g')*3) array([1.3862944], dtype=float96)
And the same with the exponential function. Chuck
Chuck
On Tue, Nov 11, 2008 at 11:13 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Nov 11, 2008 at 11:00 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, Nov 11, 2008 at 10:33 AM, James Philbin
wrote: Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numpy numpy.__version__ '1.3.0.dev6005' numpy.test(verbosity=2) ... test_umath.TestLogAddExp.test_logaddexp_values ...
The test hangs at the last line and never progresses further.
Ah good, some of the buildbots are doing this also and I'm trying to track it down. I don't see it on my machine. Could you post your compiler version? I suspect a library problem. Meanwhile I'll comment out the offending tests... and add some that might hang in more informative places.
Oops, I see your compiler/python version is already there. Mine are
Python 2.5.1 (r251:54863, Jun 15 2008, 18:24:51) [GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Can you try checking the functions log1p and exp separately for all three floating types? Something like
import numpy as np np.log1p(np.ones(1, dtype='f')*3) array([ 1.38629436], dtype=float32) np.log1p(np.ones(1, dtype='d')*3) array([ 1.38629436]) np.log1p(np.ones(1, dtype='g')*3) array([1.3862944], dtype=float96)
And the same with the exponential function.
It looks like log1pf is borked on some machines. Do you have any CFLAGS in your environment? Meanwhile, the bsd buildbot has suddenly lost the ability to find csqrt in linalg... It's Halloween all over again. Chuck
Can you try checking the functions log1p and exp separately for all three floating types? Something like
Well, log1p seems to be the culprit:
import numpy as np np.log1p(np.ones(1,dtype='f')*3) ... hangs here ...
exp is fine:
import numpy as np np.exp(np.ones(1,dtype='f')*3) array([ 20.08553696], dtype=float32)
If it helps: $ uname -a Linux lewis 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux James
On Tue, Nov 11, 2008 at 12:41 PM, James Philbin
Can you try checking the functions log1p and exp separately for all three floating types? Something like
Well, log1p seems to be the culprit:
import numpy as np np.log1p(np.ones(1,dtype='f')*3) ... hangs here ...
exp is fine:
import numpy as np np.exp(np.ones(1,dtype='f')*3) array([ 20.08553696], dtype=float32)
If it helps: $ uname -a Linux lewis 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
My guess is that this is a libm/gcc problem on x86_64, perhaps depending on the flags libm was compiled with. What distro are you using? I'm not sure how to handle this without some ugly voodoo in the numpy build process. We currently check if the library functions are present, but we have no way to mark them as present but buggy. Can you try plain old log/log10 also? I'll try to put together some c code you can use to check things also so that you can file a bug report with the distro if the problem persists. Chuck
My guess is that this is a libm/gcc problem on x86_64, perhaps depending on the flags libm was compiled with. What distro are you using? Ubuntu 8.10 amd64
Can you try plain old log/log10 also? I'll try to put together some c code you can use to check things also so that you can file a bug report with the distro if the problem persists. log/log10 are fine:
In [4]: numpy.log(numpy.array([3],dtype='f'))
Out[4]: array([ 1.09861231], dtype=float32)
In [5]: numpy.log10(numpy.array([3],dtype='f'))
Out[5]: array([ 0.47712123], dtype=float32)
I tried the following c code which also runs fine:
---
#include
Hmmm... So I examined an objdump of umath.so: objdump -d /usr/lib/python2.5/site-packages/numpy/core/umath.so > umath.asm The relevant lines are here: --- 00000000000292c0 <log1pf>: 292c0: e9 fb ff ff ff jmpq 292c0 <log1pf> 292c5: 66 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1) 292cc: 00 00 00 00 --- Not sure if i'm reading this correctly, but the first line seems to be an unconditional jump to itself, hence an infinite loop? James
On Tue, Nov 11, 2008 at 1:16 PM, James Philbin
Hmmm... So I examined an objdump of umath.so: objdump -d /usr/lib/python2.5/site-packages/numpy/core/umath.so > umath.asm
The relevant lines are here: --- 00000000000292c0 <log1pf>: 292c0: e9 fb ff ff ff jmpq 292c0 <log1pf> 292c5: 66 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1) 292cc: 00 00 00 00 ---
Not sure if i'm reading this correctly, but the first line seems to be an unconditional jump to itself, hence an infinite loop?
Hmm... I'm fishing now, but I think the current configuration doesn't find log1pf in the library even though it is there. Before updating from svn, could you try going into numpy/core/src/math_c99.inc.src line 219 and put "static" in the function definition? Chuck
On Tue, Nov 11, 2008 at 2:25 PM, Charles R Harris wrote: On Tue, Nov 11, 2008 at 1:16 PM, James Philbin Hmmm... So I examined an objdump of umath.so:
objdump -d /usr/lib/python2.5/site-packages/numpy/core/umath.so >
umath.asm The relevant lines are here:
---
00000000000292c0 <log1pf>:
292c0: e9 fb ff ff ff jmpq 292c0 <log1pf>
292c5: 66 66 2e 0f 1f 84 00 nopw %cs:0x0(%rax,%rax,1)
292cc: 00 00 00 00
--- Not sure if i'm reading this correctly, but the first line seems to be
an unconditional jump to itself, hence an infinite loop? Hmm... I'm fishing now, but I think the current configuration doesn't find
log1pf in the library even though it is there. Before updating from svn,
could you try going into numpy/core/src/math_c99.inc.src line 219 and put
"static" in the function definition? I think this is now fixed in svn, I'm trying to see if static fixes the
problem with the old buggy version. What optimization level is numpy being
compiled with?
Chuck
I think this is now fixed in svn, I'm trying to see if static fixes the problem with the old buggy version. What optimization level is numpy being compiled with? Still a problem here:
In [1]: import numpy as np In [2]: np.__version__ Out[2]: '1.3.0.dev6011' In [3]: np.log1p(np.array([1],dtype='f')) ... hangs ... I'm not exactly sure how to get the exact numpy cflags (the gcc invocation is hidden from me), but setup.py outputs the following at various points: C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC I'm haven't added any cflags, just running 'python setup.py build'. James
On Tue, Nov 11, 2008 at 4:13 PM, James Philbin
I think this is now fixed in svn, I'm trying to see if static fixes the problem with the old buggy version. What optimization level is numpy being compiled with? Still a problem here:
In [1]: import numpy as np
In [2]: np.__version__ Out[2]: '1.3.0.dev6011'
In [3]: np.log1p(np.array([1],dtype='f')) ... hangs ...
I'm not exactly sure how to get the exact numpy cflags (the gcc invocation is hidden from me), but setup.py outputs the following at various points: C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC
I'm haven't added any cflags, just running 'python setup.py build'.
It's working on the buildbots. Did you remove the build directory first? Chuck
participants (2)
-
Charles R Harris
-
James Philbin