Igor Sylvester | 1 Jan 20:09
Picon

PyArray_DescrConverter segfault

Hi,
Does anyone have an insight on the following problem?

PyObject* descr(PyObject* self, PyObject* args) {
  PyObject *d;
  PyArg_ParseTuple(args, "O&", PyArray_DescrConverter, &d);
  return d;
}

>>> import numpy
>>> import mymodule
>>> numpy.__version__
'1.2.1'
>>> mymodule.descr([('a', 'i4'), ('b', 'i8')])
segmentation fault (core dumped)  ipython

Thanks!
-Igor

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Igor Sylvester | 1 Jan 20:21
Picon

Fwd: PyArray_DescrConverter segfault

I realize I need to call import_array() in the module initialization module.  Why isn't this equivalent to importing numpy before importing my module?

---------- Forwarded message ----------
From: Igor Sylvester <igorsyl <at> gmail.com>
Date: Thu, Jan 1, 2009 at 1:09 PM
Subject: PyArray_DescrConverter segfault
To: Numpy-discussion <at> scipy.org


Hi,
Does anyone have an insight on the following problem?

PyObject* descr(PyObject* self, PyObject* args) {
  PyObject *d;
  PyArg_ParseTuple(args, "O&", PyArray_DescrConverter, &d);
  return d;
}

>>> import numpy
>>> import mymodule
>>> numpy.__version__
'1.2.1'
>>> mymodule.descr([('a', 'i4'), ('b', 'i8')])
segmentation fault (core dumped)  ipython

Thanks!
-Igor

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Robert Kern | 1 Jan 23:11
Picon
Gravatar

Re: Fwd: PyArray_DescrConverter segfault

On Thu, Jan 1, 2009 at 14:21, Igor Sylvester <igorsyl <at> gmail.com> wrote:
> I realize I need to call import_array() in the module initialization
> module.  Why isn't this equivalent to importing numpy before importing my
> module?

In 3rd party extension modules, all of the PyArray_* API functions are
actually #define macros pointing to an array of function pointers.
import_array() imports numpy.core.multiarray and sets up this array.
If you don't do this, then trying to call one of the PyArray_*
functions will result in a segfault because it tries to dereference a
pointer in the array that is not set up.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
Igor Sylvester | 1 Jan 23:25
Picon

Re: Fwd: PyArray_DescrConverter segfault

Robert,

If I import numpy and then import a 3rd party extension module, why does the extension module still have to call import_array if numpy sets this array in the first place?  I assume that there's a single array of API functions in a single python process with multiple extension modules.

Igor.

On Thu, Jan 1, 2009 at 4:11 PM, Robert Kern <robert.kern <at> gmail.com> wrote:
On Thu, Jan 1, 2009 at 14:21, Igor Sylvester <igorsyl <at> gmail.com> wrote:
> I realize I need to call import_array() in the module initialization
> module.  Why isn't this equivalent to importing numpy before importing my
> module?

In 3rd party extension modules, all of the PyArray_* API functions are
actually #define macros pointing to an array of function pointers.
import_array() imports numpy.core.multiarray and sets up this array.
If you don't do this, then trying to call one of the PyArray_*
functions will result in a segfault because it tries to dereference a
pointer in the array that is not set up.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Robert Kern | 1 Jan 23:27
Picon
Gravatar

Re: Fwd: PyArray_DescrConverter segfault

On Thu, Jan 1, 2009 at 17:25, Igor Sylvester <igorsyl <at> gmail.com> wrote:
> Robert,
>
> If I import numpy and then import a 3rd party extension module, why does the
> extension module still have to call import_array if numpy sets this array in
> the first place?  I assume that there's a single array of API functions in a
> single python process with multiple extension modules.

Your 3rd party extension module does not know the location of that
array until you call import_array().

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
Mike Landis | 2 Jan 19:29
Picon

building numpy/scipy

Some of the install instructions are kind of ambiguous.

When a library name ends in .a or .dll, it's obvious what it is, but 
'library' is sometimes used generically without indicating whether 
you're talking about static or dynamic, e.g. how does numpy/scipy 
link to MKL?  Is it statically or dynamically linked?

It's not clear where things should go or how things are found.  After 
downloading numpy and putting numpy-1.2.1 into a directory named 
numpy-1.2.1 in python2.5/Lib/site-packages/ and running python 
setup.py install from the numpy-1.2.1 directory, you get a numpy 
directory in site-packages.  Later, the install instructions refer to 
the numpy directory generically.  Which numpy directory are you 
talking about?  Should the numpy-1.2.1 directory not be in 
site-packages in the first place?  Ditto for scipy.  E.g. are you 
referring to the site.cfg in the distribution directory (numpy-1.2.1) 
or the installed directory (numpy without version notation).  Maybe 
you should give names to these directories (e.g. distribution and 
install) and always refer to them with leading adjectives.

It should be possible to create a script that keeps track of all of 
these extra lib configuration steps, so installs won't be so involved 
and error prone.

I built ATLAS (they need better documentation of processor types and 
how to use what CPU-Z tells you) and I have MKL installed.  A quarter 
of my MKL evaluation days have already ticked away, and I've come to 
the disappointing realization that 30 days is probably not going to 
be enough to get the scipy/MKL install right.

What's compatible with what?  There is mention of MKL, ATLAS, LAPACK 
and CLAPACK (I also downloaded CLAPACK 3.1.1.1).  It seems like 
CLAPACK would be naturally compatible because python uses C-style 
matrix addressing, but does Python (or numpy) flip indexes around if 
you have LAPACK instead of CLAPACK, so it works anyway, if slower?

There is mention of ".numpy-site.cfg" in the user's home directory 
(which I created), but it didn't seem to have any effect on installing.

I created the following site.cfg in the numpy (install) directory:

[mkl]
include_dirs = D:\Programs\Intel\MKL\10.1.0.018\include
library_dirs = D:\Programs\Intel\MKL\10.1.0.018\ia32\lib
mkl_libs = mkl_ia32, mkl_c_dll, libguide40
lapack_libs = mkl_lapack

Do numpy AND scipy each need a site.cfg in their respective install 
directories?  If so, does one take precedence over the other?

When I run 'python setup.py install' from the numpy install directory, I get:

Warning: No configuration returned, assuming unavailable.
blas_opt_info:
blas_mkl_info:
   libraries mkl, vml, guide not found in d:\Programs\Python25\lib
   libraries mkl, vml, guide not found in C:\
   libraries mkl, vml, guide not found in d:\Programs\Python25\libs
   NOT AVAILABLE

atlas_blas_threads_info:
Setting PTATLAS=ATLAS
   libraries mkl, vml, guide not found in d:\Programs\Python25\lib
   libraries mkl, vml, guide not found in C:\
   libraries mkl, vml, guide not found in d:\Programs\Python25\libs
   NOT AVAILABLE

atlas_blas_info:
   libraries mkl, vml, guide not found in d:\Programs\Python25\lib
   libraries mkl, vml, guide not found in C:\
   libraries mkl, vml, guide not found in d:\Programs\Python25\libs
   NOT AVAILABLE

D:\Programs\Python25\lib\site-packages\numpy\disutils\system_info.py:1340: 
UserWarning:
     Atlas (http://math-atlas.sourceforgr.net/) libraries not found
     Directories to search for the libraries can be specified in the 
numpy/disutils/site.cfg file (section [atlas]) or by setting the 
ATLAS environment variable.
   warnings.warn(AtlasNotFoundError.__doc__)
blas_info:
   libraries blas not found in d:\Programs\Python25\lib
-----------------------------------------------------------------
Where is it looking for blas_opt_info, blas_mkl_info, 
atlas_blas_threads_info, and atlas_blas_info?  Is it actually looking 
on sourceforge for Atlas?  FYI, when I try using make in 
...MKL/10.1.0.018/examples/cblas, I get a "missing separator" error 
on the "!INCLUDE cblas.lst" line (first significant line in the 
file).  There are no spaces on this line.  Could cygwin make be 
complaining about something inside the cblas.lst file, or is 
complaining about the line not being terminated the way it expects it 
to be (I see carriage return, line feed pairs in the file).

HELP!!!!
David Cournapeau | 2 Jan 19:43
Picon

Re: building numpy/scipy

On Sat, Jan 3, 2009 at 3:29 AM, Mike Landis <mlandis001 <at> comcast.net> wrote:
> Some of the install instructions are kind of ambiguous.
>
> When a library name ends in .a or .dll, it's obvious what it is, but
> 'library' is sometimes used generically without indicating whether
> you're talking about static or dynamic, e.g. how does numpy/scipy
> link to MKL?  Is it statically or dynamically linked?

Dynamically first, statically if only the static library is found.

>
> It's not clear where things should go or how things are found.  After
> downloading numpy and putting numpy-1.2.1 into a directory named
> numpy-1.2.1 in python2.5/Lib/site-packages/ and running python
> setup.py install from the numpy-1.2.1 directory, you get a numpy
> directory in site-packages.  Later, the install instructions refer to
> the numpy directory generically.  Which numpy directory are you
> talking about?  Should the numpy-1.2.1 directory not be in
> site-packages in the first place?

No, it should certainly not be in site-packages. Why would you want to
do that ? site-packages is reserved for already built python modules.
It is a very bad idea to put anything else there.

>
> It should be possible to create a script that keeps track of all of
> these extra lib configuration steps, so installs won't be so involved
> and error prone.

There is no ambiguity: when referring to installation, it is
understood we refer to the source directory, always.

>
> What's compatible with what?  There is mention of MKL, ATLAS, LAPACK
> and CLAPACK (I also downloaded CLAPACK 3.1.1.1).  It seems like
> CLAPACK would be naturally compatible because python uses C-style
> matrix addressing, but does Python (or numpy) flip indexes around if
> you have LAPACK instead of CLAPACK, so it works anyway, if slower?

Numpy and Scipy supports the netlib F77 interface to both blas and
lapack. There is no real advantage to using CLAPACK/CBLAS instead of
those if you have the fortran interfaces.

>
> There is mention of ".numpy-site.cfg" in the user's home directory
> (which I created), but it didn't seem to have any effect on installing.
>
> I created the following site.cfg in the numpy (install) directory:
>
> [mkl]
> include_dirs = D:\Programs\Intel\MKL\10.1.0.018\include
> library_dirs = D:\Programs\Intel\MKL\10.1.0.018\ia32\lib
> mkl_libs = mkl_ia32, mkl_c_dll, libguide40
> lapack_libs = mkl_lapack

There are many problems with the MLK - and I bet it does not work on
windows. You are much better of using the numpy and scipy binaries.

>
> Do numpy AND scipy each need a site.cfg in their respective install
> directories?  If so, does one take precedence over the other?

When building, the site.cfg should be put in the *source* directory.

But again, particularly on windows, you should really use the
distributed binaries. Building numpy and scipy with external
BLAS/LAPACK is not easy, especially on windows.

David
Matthieu Brucher | 2 Jan 19:45
Picon

Re: building numpy/scipy

2009/1/2 Mike Landis <mlandis001 <at> comcast.net>:
> Some of the install instructions are kind of ambiguous.
>
> When a library name ends in .a or .dll, it's obvious what it is, but
> 'library' is sometimes used generically without indicating whether
> you're talking about static or dynamic, e.g. how does numpy/scipy
> link to MKL?  Is it statically or dynamically linked?

If the dynamic libraries are available, they are used.

> It's not clear where things should go or how things are found.  After
> downloading numpy and putting numpy-1.2.1 into a directory named
> numpy-1.2.1 in python2.5/Lib/site-packages/ and running python
> setup.py install from the numpy-1.2.1 directory, you get a numpy
> directory in site-packages.

Wait, never put numpy-1.2.1 inside site-packes, build it somewhere else.

  Later, the install instructions refer to
> the numpy directory generically.  Which numpy directory are you
> talking about?  Should the numpy-1.2.1 directory not be in
> site-packages in the first place?  Ditto for scipy.  E.g. are you
> referring to the site.cfg in the distribution directory (numpy-1.2.1)
> or the installed directory (numpy without version notation).

Just get inside numpy-1.2.1, type python setup.py install and you
never have to use this folder. The only relevant folder is the numpy
one inside site-packages.

 Maybe
> you should give names to these directories (e.g. distribution and
> install) and always refer to them with leading adjectives.

Perhaps.

> It should be possible to create a script that keeps track of all of
> these extra lib configuration steps, so installs won't be so involved
> and error prone.

I just use python setup.py install, nothing else, and it works with
the default Linux mathematic libraries.

> I built ATLAS (they need better documentation of processor types and
> how to use what CPU-Z tells you) and I have MKL installed.  A quarter
> of my MKL evaluation days have already ticked away, and I've come to
> the disappointing realization that 30 days is probably not going to
> be enough to get the scipy/MKL install right.

I don't know if many people are using Numpy with the MKL on Windows.

> What's compatible with what?  There is mention of MKL, ATLAS, LAPACK
> and CLAPACK (I also downloaded CLAPACK 3.1.1.1).  It seems like
> CLAPACK would be naturally compatible because python uses C-style
> matrix addressing, but does Python (or numpy) flip indexes around if
> you have LAPACK instead of CLAPACK, so it works anyway, if slower?

CLAPACK is not a standard interface, so it is not usable with MKL or ACML.

> There is mention of ".numpy-site.cfg" in the user's home directory
> (which I created), but it didn't seem to have any effect on installing.

Only site.cfg is relevant.

> I created the following site.cfg in the numpy (install) directory:
>
> [mkl]
> include_dirs = D:\Programs\Intel\MKL\10.1.0.018\include
> library_dirs = D:\Programs\Intel\MKL\10.1.0.018\ia32\lib
> mkl_libs = mkl_ia32, mkl_c_dll, libguide40
> lapack_libs = mkl_lapack

> Do numpy AND scipy each need a site.cfg in their respective install
> directories?  If so, does one take precedence over the other?

Yes and I don't know ;)

> When I run 'python setup.py install' from the numpy install directory, I get:
>
> Warning: No configuration returned, assuming unavailable.
> blas_opt_info:
> blas_mkl_info:
>   libraries mkl, vml, guide not found in d:\Programs\Python25\lib
>   libraries mkl, vml, guide not found in C:\
>   libraries mkl, vml, guide not found in d:\Programs\Python25\libs
>   NOT AVAILABLE
>
> atlas_blas_threads_info:
> Setting PTATLAS=ATLAS
>   libraries mkl, vml, guide not found in d:\Programs\Python25\lib
>   libraries mkl, vml, guide not found in C:\
>   libraries mkl, vml, guide not found in d:\Programs\Python25\libs
>   NOT AVAILABLE
>
> atlas_blas_info:
>   libraries mkl, vml, guide not found in d:\Programs\Python25\lib
>   libraries mkl, vml, guide not found in C:\
>   libraries mkl, vml, guide not found in d:\Programs\Python25\libs
>   NOT AVAILABLE
>
> D:\Programs\Python25\lib\site-packages\numpy\disutils\system_info.py:1340:
> UserWarning:
>     Atlas (http://math-atlas.sourceforgr.net/) libraries not found
>     Directories to search for the libraries can be specified in the
> numpy/disutils/site.cfg file (section [atlas]) or by setting the
> ATLAS environment variable.
>   warnings.warn(AtlasNotFoundError.__doc__)
> blas_info:
>   libraries blas not found in d:\Programs\Python25\lib
> -----------------------------------------------------------------
> Where is it looking for blas_opt_info, blas_mkl_info,
> atlas_blas_threads_info, and atlas_blas_info?  Is it actually looking
> on sourceforge for Atlas?

it looks in site.cfg for those informations.

  FYI, when I try using make in
> ...MKL/10.1.0.018/examples/cblas, I get a "missing separator" error
> on the "!INCLUDE cblas.lst" line (first significant line in the
> file).  There are no spaces on this line.  Could cygwin make be
> complaining about something inside the cblas.lst file, or is
> complaining about the line not being terminated the way it expects it
> to be (I see carriage return, line feed pairs in the file).

Did you try mingw or Visual studio 2003?

Matthieu
--

-- 
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn: http://www.linkedin.com/in/matthieubrucher
Picon
Favicon

Re : Alternative to record array

Thank you for everything, it works fine ant it is very helpful.

Regards,

Jean-Baptiste Rudant

De : Francesc Alted <faltet <at> pytables.org>
À : Discussion of Numerical Python <numpy-discussion <at> scipy.org>
Envoyé le : Mardi, 30 Décembre 2008, 16h34mn 27s
Objet : Re: [Numpy-discussion] Alternative to record array

A Tuesday 30 December 2008, Francesc Alted escrigué:
> A Monday 29 December 2008, Jean-Baptiste Rudant escrigué:
[snip]
>
> The difference for both approaches is that the row-wise arrangement
> is more efficient when data is iterated by field, while the
> column-wise one is more efficient when data is iterated by column.
> This is why you are seeing the increase of 4x in performance
> --incidentally, by looking at both data arrangements, I'd expect an
> increase of just 2x (the stride count is 2 in this case), but I
> suspect that there are hidden copies during the increment operation
> for the record array case.

As I was mystified about this difference in speed, I kept investigating
and I think I have an answer for the difference in the expected
speed-up in the unary increment operator over a recarray field.  After
looking at the numpy code, it turns out that the next statement:

data.ages += 1

is more or less equivalent to:

a = data.ages
a[:] = a + 1

i.e. a temporary is created (for keeping the result of 'a + 1') and then
assigned to the 'ages' column.  As it happens that, in this sort of
operations, the memory copies are the bottleneck, the creation of the
first temporary introduced a slowdown of 2x (due to the strided column)
and the assignment represents the additional 2x (4x in total). 
However, the next idiom:

a = data.ages
a += 1

effectively removes the need for the temporary copy and is 2x faster
than the original "data.ages += 1".  This can be seen in the next
simple benchmark:

---------------------------
import numpy, timeit

count = 10e6
ages  = numpy.random.randint(0,100,count)
weights = numpy.random.randint(1,200,count)
data = numpy.rec.fromarrays((ages,weights),names='ages,weights')

timer = timeit.Timer('data.ages += 1','from __main__ import data')
print "v0-->", timer.timeit(number=10)
timer = timeit.Timer('a=data.ages; a[:] = a + 1','from __main__ import
data')
print "v1-->", timer.timeit(number=10)
timer = timeit.Timer('a=data.ages; a += 1','from __main__ import data')
print "v2-->", timer.timeit(number=10)
timer = timeit.Timer('ages += 1','from __main__ import ages')
print "v3-->", timer.timeit(number=10)
---------------------------

which produces the next output on my laptop:

v0--> 2.98340201378
v1--> 3.22748112679
v2--> 1.5474319458
v3--> 0.809724807739

As a final comment, I suppose that unary operators (+=, -=...) can be
optimized in the context of recarray columns in numpy, but I don't
think it is worth the effort:  when really high performance is needed
for operating with columns in the context of recarrays, a column-wise
approach is best.

Cheers,

--
Francesc Alted
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Mike Landis | 3 Jan 00:27
Picon

Re: building numpy/scipy

So, on page < http://www.scipy.org/Installing_SciPy/Windows#head-c7b42e8bc6116eb66668108df13a49ab1ef6a883 >, what are the unspoken instructions that everyone else seems to know about (except me) that should be implemented between defining .numpy-site.cfg and running
python setup.py config in the numpy distribution directory?  I followed the instructions line by line, but I'm getting a huge number of errors.  How do I get rid of the complaints about blas_opt_info and blas_mkl_info and help python find ptf77blas, ptcblas, atlas, f77blas, cblas, and blas?

At 01:43 PM 1/2/2009, you wrote:
On Sat, Jan 3, 2009 at 3:29 AM, Mike Landis <mlandis001 <at> comcast.net> wrote:
> Some of the install instructions are kind of ambiguous.
>
> When a library name ends in .a or .dll, it's obvious what it is, but
> 'library' is sometimes used generically without indicating whether
> you're talking about static or dynamic, e.g. how does numpy/scipy
> link to MKL?  Is it statically or dynamically linked?

Dynamically first, statically if only the static library is found.

>
> It's not clear where things should go or how things are found.  After
> downloading numpy and putting numpy-1.2.1 into a directory named
> numpy-1.2.1 in python2.5/Lib/site-packages/ and running python
> setup.py install from the numpy-1.2.1 directory, you get a numpy
> directory in site-packages.  Later, the install instructions refer to
> the numpy directory generically.  Which numpy directory are you
> talking about?  Should the numpy-1.2.1 directory not be in
> site-packages in the first place?

No, it should certainly not be in site-packages. Why would you want to
do that ? site-packages is reserved for already built python modules.
It is a very bad idea to put anything else there.

>
> It should be possible to create a script that keeps track of all of
> these extra lib configuration steps, so installs won't be so involved
> and error prone.

There is no ambiguity: when referring to installation, it is
understood we refer to the source directory, always.

>
> What's compatible with what?  There is mention of MKL, ATLAS, LAPACK
> and CLAPACK (I also downloaded CLAPACK 3.1.1.1).  It seems like
> CLAPACK would be naturally compatible because python uses C-style
> matrix addressing, but does Python (or numpy) flip indexes around if
> you have LAPACK instead of CLAPACK, so it works anyway, if slower?

Numpy and Scipy supports the netlib F77 interface to both blas and
lapack. There is no real advantage to using CLAPACK/CBLAS instead of
those if you have the fortran interfaces.

>
> There is mention of ".numpy-site.cfg" in the user's home directory
> (which I created), but it didn't seem to have any effect on installing.
>
> I created the following site.cfg in the numpy (install) directory:
>
> [mkl]
> include_dirs = D:\Programs\Intel\MKL\10.1.0.018\include
> library_dirs = D:\Programs\Intel\MKL\10.1.0.018\ia32\lib
> mkl_libs = mkl_ia32, mkl_c_dll, libguide40
> lapack_libs = mkl_lapack

There are many problems with the MLK - and I bet it does not work on
windows. You are much better of using the numpy and scipy binaries.

>
> Do numpy AND scipy each need a site.cfg in their respective install
> directories?  If so, does one take precedence over the other?

When building, the site.cfg should be put in the *source* directory.

But again, particularly on windows, you should really use the
distributed binaries. Building numpy and scipy with external
BLAS/LAPACK is not easy, especially on windows.

David
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.2/1871 - Release Date: 1/1/2009 5:01 PM
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion <at> scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Gmane