Mailman 3 April 2001 - NumPy-Discussion

Bug (?) in numpy 19.0 under win32
by T.Meyarivan 18 Apr '01

18 Apr '01

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> from Numeric import * >>> from LinearAlgebra import * >>> a = array([[1,0],[0,1]]) >>> print a, type(a) [[1 0] [0 1]] <type 'array'> >>> eigenvectors(a) Traceback (most recent call last): File "<pyshell#4>", line 1, in ? eigenvectors(a) File "c:\program files\python21\numeric\LinearAlgebra.py", line 151, in eigenvectors dummy, 1, vr, n, work, lwork, 0) LapackError: Expected an array for parameter a in lapack_dge.dgeev >>> the above test works fine under unix environment using the same version of python and numpy

1 0

Re: Numeric on OS X - Anyone get it to work ?
by Rob Managan 18 Apr '01

18 Apr '01

> Konrad Hinsen <hinsen(a)cnrs-orleans.fr> wrote > > Could you give a quick explanation why? I thought the whole point of >> the "extern" specifier was to flag that this variable was defined >> elsewhere. > >Right, but with most platforms' shared library systems, this means >"in another source file that is part of the same shared library", >not "in another shared library" or "in the main executable". > >> Otherwise, doesn't it imply that the API pointer is >> defined in each file that includes arrayobject.h? >> >> i.e. shouldn't headers declare "extern double x" for everything except >> the file that actually defines x? > >If a dynamically loaded module consists of more than one source file, >then all but one of them (the one which calls import_array()) must >define NO_IMPORT_ARRAY before including arrayobject.h. This is also >the answer to Kevin Rodgers' question. > > >However, it seems to me that the current arrangement in NumPy has >another serious drawback: it should be impossible to link NumPy >statically with the Python interpreter, due to multiply defined >symbols. And I am rather sure that this was possible many versions >ago, since I used NumPy on a Cray T3E, which does not have shared >libraries. > >I checked my own extension modules that export a C API, and they all >declare the API pointer static. This is also what the C API export >section in the "Extending & Embedding" manual recommends. (OK, I admit >that I wrote that section, so that is not a coincidence!) > > >So perhaps the best solution is to make this static. Client modules >that consist of more than one source code file with PyArray... calls >must then call import_array() once in every such file, or equivalently >pass on the PyArray_API pointer explicitly between the files. That >sounds quite acceptable to me. > In my experience porting other libraries to the Mac I find that most Unix boxes are not at all upset by what CodeWarrior calls multiple definitions. The answer in that case was in details that are not specified in the C standard. Section 4.8 of "A Reference Manual" by Harbison and Steele goes into the details of how external names are handled. Most UNIX compilers use the mixed Common Model. In this case you can define a global any number of times and if there is no initializer present they are all merged into one much like a Fortran Common block. My point is that what I consider lazy coding practice (not using externs where needed) is tolerated by many C compilers. I am not competent to comment on the impact of shared libraries on all this. -- *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*- Rob Managan <mailto://managan@llnl.gov> LLNL ph: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808

1 0

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?
by Johann Hibschman 18 Apr '01

18 Apr '01

Paul F Dubois writes: > On Tue, 17 Apr 2001, Johann Hibschman wrote: >> >> All I did was insert a >> >> #define NO_IMPORT_ARRAY >> before the >> #include "arrayobject.h" >> in umathmodule.c > Such a change breaks other platforms... Could you give a quick explanation why? I thought the whole point of the "extern" specifier was to flag that this variable was defined elsewhere. Otherwise, doesn't it imply that the API pointer is defined in each file that includes arrayobject.h? i.e. shouldn't headers declare "extern double x" for everything except the file that actually defines x? I should go back and read my copy of K&R... --Johann -- Johann Hibschman johann(a)physics.berkeley.edu

6 5

Re: [Numpy-discussion] Numeric on OS X - Anyone get it to work ?
by Johann Hibschman 18 Apr '01

18 Apr '01

Konrad Hinsen writes: > You'd have to declare PyArray_API static in each module, but that > won't be easy as some modules consist of more than one C source file. All I did was insert a #define NO_IMPORT_ARRAY before the #include "arrayobject.h" in umathmodule.c I repeated this for all the Packages, and it seems to work just fine. --Johann -- Johann Hibschman johann(a)physics.berkeley.edu

3 2

Sparse Arrays
by victor＠idaccr.org 18 Apr '01

18 Apr '01

I found by looking up through Google that Travis O. has written a package called SparsePy for manipulating sparse arrays. However, when I tried to download it I was asked for a userid and password. Is this not yet publicly available? Are there any other packages for this that are available? -- Victor S. Miller | " ... Meanwhile, those of us who can compute can hardly victor(a)idaccr.org | be expected to keep writing papers saying 'I can do the CCR, Princeton, NJ | following useless calculation in 2 seconds', and indeed 08540 USA | what editor would publish them?" -- Oliver Atkin

1 0

Re: [Numpy-discussion] more on MA not pickling
by Tavis Rudd 17 Apr '01

17 Apr '01

> Unfortunately, *my* application does this. (:->. damn, I was hoping you wouldn't say that ;-) > Maybe MA needs to define some special methods to make > this work, so that the objects are pickled without these > attributes and they are restored after being unpickled? do you mean __getstate__ and __setstate__? > There may be another solution but it will take more > effort to develop. I've got a vague idea for another solution that uses the .im_func attribute of methods. I'll toy with it this afternoon and see if I can get it working. Tavis

1 0

more on MA not pickling
by Tavis Rudd 17 Apr '01

17 Apr '01

Hi, I posted something about this a few weeks ago, but got distracted before I had a chance to look into it further ... Revisions 1.5 and up of activeattr.py in the MA package cause a fatal error when pickling is attempted. The pickle and cPickle modules don't allow unbound instance methods to be pickled and the ActiveAttributes mixin is storing attribute handlers, such as ActiveAttribute.basic_get, as unbound instance methods. Revision 1.4 works fine if basic_get is modified so that an AttributeError is raised instead of a KeyError when an attribute is not found. This bug was introduced in an attempt to allow child classes of MA to be able to modify activeattributes. I suggest reverting back to rev 1.4 of activeattr with a modified basic_get method and forgetting about allowing child classes to do this. Cheers Tavis

2 1

PyArray_API, NO_IMPORT, and NO_IMPORT_ARRAY
by Rodgers, Kevin 17 Apr '01

17 Apr '01

I'm working on a project where I'm embedding Python and NumPy (on Win32). For various reasons, I need to have all of my source files as C++, even though I'm not using any C++ features (just using it as a "better C"). When Visual C++ goes to link, I get the following error: Linking... vtuav_sim_wrap.obj : error LNK2005: _PyArray_API already defined in vtuav_sim.obj vtuav_sim_wrap.obj : warning LNK4006: _PyArray_API already defined in vtuav_sim.obj; second definition ignored Creating library Release/vtuav_simc.lib and object Release/vtuav_simc.exp Release/vtuav_simc.dll : fatal error LNK1169: one or more multiply defined symbols found Error executing link.exe. The error is caused by the following lines in arrayobject.h: /* C API address pointer */ #if defined(NO_IMPORT) || defined(NO_IMPORT_ARRAY) extern void **PyArray_API; #else void **PyArray_API; #define NO_PYARRAY_API #endif Because I'm including the arrayobject.h header in two different source code modules, and neither NO_IMPORT or NO_IMPORT_ARRAY are defined, the "else" clause gets executed, which causes the "multiply defined symbol" error. This also appears to be the root cause of the problems currently being discussed on the list about MacOS X. So, how can this problem be fixed? I must confess that I don't understand the code in arrayobject.h that uses PyArray_API. Any ideas? Thanks in advance . . . -- Kevin Rodgers Northrop Grumman Ryan Aeronautical krodgers(a)ryanaero.com "This one goes up to eleven." -- Nigel Tufnel

1 0

Numeric on OS X - Anyone get it to work ?
by Tim Lahey 17 Apr '01

17 Apr '01

All, I've been trying to get the Numeric-19.0.0 working on Python 2.1b2 under OS X. I've successfully install python and have success with most of the modules, but I have problems with Numeric. I can't get it to even load. The following is what I get when I import Numeric. Python 2.1b2 (#1, 04/09/01, 22:37:35) [GCC Apple DevKit-based CPP 6.0alpha] on darwin1 Type "copyright", "credits" or "license" for more information. >>> import Numeric dyld: python multiple definitions of symbol _PyArray_API /usr/local/lib/python2.1/site-packages/Numeric/multiarray.so definition of _PyArray_API /usr/local/lib/python2.1/site-packages/Numeric/umath.so definition of _PyArray_API At this point, I get returned to the command line (python exits). It appears that the dynamic linker mechanism under OS X doesn't like symbols with the same name. Anyone have a way around this ? Thanks, Tim Lahey tjlahey(a)sympatico.ca

4 3

bugs
by Paul F. Dubois 13 Apr '01

13 Apr '01

I am approaching a point where I will cut 19.1. I have reduced the number of bugs in the bug list to six. Please examine this list and see if there is one you could volunteer to fix. Developers, please make fixes directly. Users, please post patches rather than sending email. There are no outstanding patches.

2 1

NumPy-Discussion April 2001