Below is the code around line 900 for ufuncobject.c
(http://svn.scipy.org/svn/numpy/trunk/numpy/core/src/ufuncobject.c)
There is a decref labeled with below that is incorrect. As per
the python documentation
(http://docs.python.org/api/dictObjects.html):
#PyObject* PyDict_GetItem( PyObject *p,
rex rex at nosyntax.com writes:
There doesn't appear to be a problem with recent versions of the
software. In particular, ATLAS 3.7.33 does not cause an error.
Is there some reason for you to use such old software? (gcc 3.3.1
kernel 2.4.21)? What platform are you building for?
-rex
On Sunday 24 June 2007 13:05, David Cournapeau wrote:
Hi there,
After quite some pain, I finally managed to build a LAPACK +
ATLAS rpm useful for numpy and scipy. Read the following if you
--- snip --
and lapack. I would like to hear
That is normal python syntax. It works with lists. What is slightly
unusual is the multi-dimensional slicing as in arr[:,10:20]. However,
this is governed by the way python translates bracket[] index calls to
the __getitem__ and __getslice__ methods. You can try it out yourself
in ipython or
john,
there was a bug that made it into debian sarge whereby a SIGFPE wasn't
trapped in the appropriate place and ended up causing problems similar
to what you describe. the difficulty in debugging is that you're after
whatever triggers the FPE in the first place (or the bug that lets it go
I have gfortran installed in my path. But when I run python setup.py
build I get
Found executable /usr/bin/g77
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
customize GnuFCompiler
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
The output of python
Eike Welk wrote:
On Sunday 24 June 2007 13:05, David Cournapeau wrote:
Hi there,
After quite some pain, I finally managed to build a LAPACK +
ATLAS rpm useful for numpy and scipy. Read the following if you
--- snip --
and lapack. I
