Mailman 3 November 2007 - NumPy-Discussion

numpy.scons: 2nd alpha
by David Cournapeau Nov. 7, 2007

Nov. 7, 2007

Hi, I have just finished to implement everything I wanted to do for a 2nd alpha for numpy.scons. Most of the work since 1st alpha was infrastructure polishing (performance library, fortran): now, most common performance libraries are fully supported (MKL and ATLAS on linux, sunperf on solaris, vecLib/Accelerate on Mac OS X). I would appreciate people testing the branch http://projects.scipy.org/scipy/numpy/wiki/NumpyScons#Gettingthecode There are minor problem preventing the thing to build on windows for some reasons, but this will be fixed soon. Basically, the whole design is now done, and it should be able to support all the platforms (and more) currently supported by numpy.distutils. I would really like to hear about people intimated with numpy.distutils, and package developers for some things I may have missed. I think numpy.scons is now much better and easier as a build system, but I am obviously biased. Most significant changes since 1st alpha: Documentation ============= I started to put more documentation on the numpy wiki: http://projects.scipy.org/scipy/numpy/wiki/NumpyScons There is also some basic description on the design: http://projects.scipy.org/scipy/numpy/browser/branches/numpy.scons/numpy/di… Configuration check =================== - performance libraries are globally supported (default and site.cfg configuration): MKL, ATLAS, Accelerate/vecLib and Sunperf are implemented. Adding a new performance library can be as easy as a 5 lines code. - 'meta' checkers are now reusing code from performance libraries: Both CBLAS and LAPACK are implemented. This means that numpy can now be entirely built with scons, using optimized libraries on the following platforms: - solaris with sunperf and sunstudio (this one has not been extensively tested: it looks like every solaris machine I have access to behaves really differently). - mac os X and Gnu toolchain - linux + ATLAS/MKL + gnu toolchain I am now relatively happy with the code for BLAS/LAPACK and performance libraries implementation. It is easily extensible and quite flexible. Generci library check ===================== I have updated and improved the basic checker, NumpyCheckLibAndHeader. This should cover most basic needs (check for a library with some functions and some headers), and should be able to replace system_info for many cases. For example, the following will check for the function sf_open in the library sndfile, with header sndfile.h: config.NumpyCheckLibAndHeader(*'sndfile'*, *'sf_open'*, *'sndfile.h'*, section = *'sndfile'*) section is optional, and tells the checker to use sndfile section in site.cfg if found. Fortran support =============== I have polished fortran support: in perticular, name mangling for F77 and F90 is implemented and has been tested with g77/gfortran/ifort/sunfort on various platforms. It also defines variables usable by f2py (http://projects.scipy.org/scipy/numpy/wiki/NumpySconsExtExamples#UsingFortr…). cheers, David

1 0

Making a minimalist NumPy
by Benjamin M. Schwartz Nov. 6, 2007

Nov. 6, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NumPy is included in the OLPC operating system, which is very constrained in space. Therefore, it would be nice to remove some subpackages to save a few megabytes. For example, the system does not include any Fortran code or compiler, so f2py (3.6 MB) seems superfluous. I also think the distutils subpackage (1.9M) is probably not necessary. Therefore, I have two questions. 1. Which packages do you think are necessary to have a functioning NumPy? 2. What is the easiest way to make (or get) a minimal NumPy installation? For example, would the scons/autoconf branch make this easier? - --Ben Schwartz OLPC volunteer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHLjDPUJT6e6HFtqQRAnG/AKCYfJ/RZwg3+5i6ofHt6PpwhgusiQCfRkZa QYvFDDRXuLyy4lxt7VswnOs= =uzX/ -----END PGP SIGNATURE-----

3 2

Assessing the use of packages
by Pierre GM Nov. 6, 2007

Nov. 6, 2007

All, It's evaluation time in my department (Bio. & Ag. Engng, UGA), and I'd need to document the impact of my Python contributions on the scientific community at large, or more realistically on the numpy/scipy user community... * Is there a way to estimate how many people installed one particular package from the SVN ? * if it's too tricky, would anybody using maskedarray and/or timeseries and/or pyloess (the SVN packages I helped implementing) mind dropping me a line off-list, with a very short description of the main field of research/use ? I'd basically need some kind of numbers to give to the People-In-Charge. Thanks a lot in advance for your time. P. PS: Sorry for the cross-posting..

2 1

boolean masks & lists
by John Hunter Nov. 6, 2007

Nov. 6, 2007

A colleague of mine just asked for help with a pesky bug that turned out to be caused by his use of a list of booleans rather than an array of booleans as his logical indexing mask. I assume this is a feature and not a bug, but it certainly surprised him: In [58]: mask = [True, False, False, False, True] In [59]: maska = n.array(mask, n.bool) In [60]: x = arange(5) In [61]: x[mask] Out[61]: array([1, 0, 0, 0, 1]) In [62]: x[maska] Out[62]: array([0, 4])

4 4

Round 2 with Leopard+Python
by Brian Granger Nov. 4, 2007

Nov. 4, 2007

Hi, In the process of working through the issues with sys.path on Leopard, I have found another potential Leopard bug that is particularly nasty. In Tiger, sudo preserves environment variables: $ export FOO=/tmp $ python -c "import os; print os.environ['FOO']" /tmp $ sudo python -c "import os; print os.environ['FOO']" /tmp But, in Leopard, sudo does not perserve environment variables: $ export FOO=/tmp $ python -c "import os; print os.environ['FOO']" /tmp $ sudo python -c "import os; print os.environ['FOO']" Password: Traceback (most recent call last): File "<string>", line 1, in <module> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/UserDict.py", line 22, in __getitem__ raise KeyError(key) KeyError: 'FOO' This is a big problem. First, if you have set PYTHONPATH to point sys.path at the site-packages in /Library, this setting will be lost when you do: sudo python setup.py install On another package. I encountered this in building pytables, which requires numpy >= 1.0.3. I had installed numpy 1.0.4, and set my PYTHONPATH to point to it. But, the pytables setup.py script failts because PYTHONPATH is lost and it only sees the older (1.0.1) builtin numpy. Second, some setup.py scripts use environment variables to determine how things are built, find other dependencies, etc. Currently, this will fail on Leopard if such packages are installed into locations that require sudo. I haven't tried it yet, but I expect that this will also hold true for other python installations. The behavior also shows up with ruby on Leopard. The solution currently is to install all packages to locations that don't require sudo to write to. I will file a bug report, but until the bug is fixed, we should explore putting a note on the numpy/scipy site - and even possibly on the python.org site to describe the problem and its workaround. Brian

2 1

segfault
by Eric Firing Nov. 4, 2007

Nov. 4, 2007

A quick scan of the tickets did not show me anything like the following, but I might have missed it. The attached script generates a segfault on my ubuntu feisty system with svn numpy. Running inside of ipython, the segfault occurs upon exiting ipython, not upon running the script. Running the script from the command line gives the attached trace. Eric efiring@manini:~/test$ python numpysegfault.py *** glibc detected *** python: free(): invalid next size (fast): 0x08388d98 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7dbc7cd] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7dbfe30] /usr/local/lib/python2.5/site-packages/numpy/core/multiarray.so[0xb7bd414e] python[0x8085269] python(PyDict_SetItem+0x6e)[0x8086bae] python(_PyModule_Clear+0x158)[0x8088808] python(PyImport_Cleanup+0x153)[0x80dcba3] python(Py_Finalize+0xbf)[0x80e8d9f] python(Py_Main+0x4d1)[0x8058e41] python(main+0x22)[0x8058862] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7d6aebc] python[0x80587b1] ======= Memory map: ======== 08048000-0813f000 r-xp 00000000 08:05 212471 /usr/bin/python2.5 0813f000-08164000 rw-p 000f6000 08:05 212471 /usr/bin/python2.5 08164000-08430000 rw-p 08164000 00:00 0 [heap] b6c00000-b6c21000 rw-p b6c00000 00:00 0 b6c21000-b6d00000 ---p b6c21000 00:00 0 b6d02000-b6d0d000 r-xp 00000000 08:05 586432 /lib/libgcc_s.so.1 b6d0d000-b6d0e000 rw-p 0000a000 08:05 586432 /lib/libgcc_s.so.1 b6d20000-b6d25000 r-xp 00000000 08:05 342572 /usr/lib/python2.5/lib-dynload/_struct.so b6d25000-b6d26000 rw-p 00005000 08:05 342572 /usr/lib/python2.5/lib-dynload/_struct.so b6d26000-b6d39000 r-xp 00000000 08:05 853437 /usr/local/lib/python2.5/site-packages/ctypes-1.0.2-py2.5-linux-i686.egg/_ctypes.so b6d39000-b6d3b000 rw-p 00013000 08:05 853437 /usr/local/lib/python2.5/site-packages/ctypes-1.0.2-py2.5-linux-i686.egg/_ctypes.so b6d3b000-b6d6d000 r-xp 00000000 08:05 750591 /usr/local/lib/python2.5/site-packages/numpy/random/mtrand.so b6d6d000-b6d71000 rw-p 00032000 08:05 750591 /usr/local/lib/python2.5/site-packages/numpy/random/mtrand.so b6d71000-b6d7a000 r-xp 00000000 08:05 752453 /usr/local/lib/python2.5/site-packages/numpy/fft/fftpack_lite.so b6d7a000-b6d7b000 rw-p 00008000 08:05 752453 /usr/local/lib/python2.5/site-packages/numpy/fft/fftpack_lite.so b6d7b000-b6e1f000 r-xp 00000000 08:05 752470 /usr/local/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so b6e1f000-b6e20000 rw-p 000a3000 08:05 752470 /usr/local/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so b6e20000-b6e87000 rw-p b6e20000 00:00 0 b6e87000-b6e8a000 r-xp 00000000 08:05 752451 /usr/local/lib/python2.5/site-packages/numpy/lib/_compiled_base.so b6e8a000-b6e8b000 rw-p 00002000 08:05 752451 /usr/local/lib/python2.5/site-packages/numpy/lib/_compiled_base.so b6e8b000-b6ea5000 r-xp 00000000 08:05 752464 /usr/local/lib/python2.5/site-packages/numpy/core/scalarmath.so b6ea5000-b6ea6000 rw-p 0001a000 08:05 752464 /usr/local/lib/python2.5/site-packages/numpy/core/scalarmath.so b6ea6000-b6ea9000 r-xp 00000000 08:05 344739 /usr/lib/python2.5/lib-dynload/mmap.so b6ea9000-b6eaa000 rw-p 00003000 08:05 344739 /usr/lib/python2.5/lib-dynload/mmap.so b6eaa000-b6ead000 r-xp 00000000 08:05 342574 /usr/lib/python2.5/lib-dynload/cStringIO.so b6ead000-b6eae000 rw-p 00003000 08:05 342574 /usr/lib/python2.5/lib-dynload/cStringIO.so b6eae000-b6ec7000 r-xp 00000000 08:05 214313 /usr/lib/libg2c.so.0.0.0 b6ec7000-b6ec8000 rw-p 00019000 08:05 214313 /usr/lib/libg2c.so.0.0.0 b6ec8000-b6ed5000 rw-p b6ec8000 00:00 0 b6ed5000-b74ac000 r-xp 00000000 08:05 343193 /usr/lib/atlas/sse2/libblas.so.3.0 b74ac000-b74b1000 rw-p 005d6000 08:05 343193 /usr/lib/atlas/sse2/libblas.so.3.0 b74b1000-b79fa000 r-xp 00000000 08:05 343194 /usr/lib/atlas/sse2/liblapack.so.3.0 b79fa000-b79fd000 rw-p 00549000 08:05 343194 /usr/lib/atlas/sse2/liblapack.so.3.0 b79fd000-b7b01000 rw-p b79fd000 00:00 0 b7b01000-b7b12000 r-xp 00000000 08:05 344738 /usr/lib/python2.5/lib-dynload/cPickle.so b7b12000-b7b13000 rw-p 00010000 08:05 344738 /usr/lib/python2.5/lib-dynload/cPickle.so b7b13000-b7b18000 r-xp 00000000 08:05 749369 /usr/local/lib/python2.5/site-packages/numpy/core/_dotblas.so b7b18000-b7b19000 rw-p 00004000 08:05 749369 /usr/local/lib/python2.5/site-packages/numpy/core/_dotblas.so b7b19000-b7b7a000 rw-p b7b19000 00:00 0 b7b7a000-b7ba0000 r-xp 00000000 08:05 749367 /usr/local/lib/python2.5/site-packages/numpy/core/umath.so b7ba0000-b7ba3000 rw-p 00025000 08:05 749367 /usr/local/lib/python2.5/site-packages/numpy/core/umath.so b7ba3000-b7ba4000 rw-p b7ba3000 00:00 0 b7ba4000-b7bfe000 r-xp 00000000 08:05 749349 /usr/local/lib/python2.5/site-packages/numpy/core/multiarray.so b7bfe000-b7c04000 rw-p 00059000 08:05 749349 /usr/local/lib/python2.5/site-packages/numpy/core/multiarray.so b7c04000-b7c05000 rw-p b7c04000 00:00 0 b7c05000-b7c4a000 r-xp 00000000 08:05 586444 /lib/libncursesw.so.5.5 b7c4a000-b7c52000 rw-p 00045000 08:05 586444 /lib/libncursesw.so.5.5 b7c52000-b7c53000 rw-p b7c52000 00:00 0 b7c55000-b7c64000 r-xp 00000000 08:05 752457 /usr/local/lib/python2.5/site-packages/numpy/core/_sort.so b7c64000-b7c65000 rw-p 0000e000 08:05 752457 /usr/local/lib/python2.5/site-packages/numpy/core/_sort.so b7c65000-b7c74000 r-xp 00000000 08:05 344754 /usr/lib/python2.5/lib-dynload/_curses.so b7c74000-b7c75000 rw-p 0000f000 08:05 344754 /usr/lib/python2.5/lib-dynload/_curses.so b7c75000-b7c77000 r-xp 00000000 08:05 342580 /usr/lib/python2.5/lib-dynload/fcntl.so b7c77000-b7c78000 rw-p 00002000 08:05 342580 /usr/lib/python2.5/lib-dynload/fcntl.so b7c78000-b7c7c000 r-xp 00000000 08:05 342578 /usr/lib/python2.5/lib-dynload/binascii.so b7c7c000-b7c7d000 rw-p 00003000 08:05 342578 /usr/lib/python2.5/lib-dynload/binascii.so b7c7d000-b7c80000 r-xp 00000000 08:05 342586 /usr/lib/python2.5/lib-dynload/math.so b7c80000-b7c81000 rw-p 00002000 08:05 342586 /usr/lib/python2.5/lib-dynload/math.so b7c81000-b7c85000 r-xp 00000000 08:05 342592 /usr/lib/python2.5/lib-dynload/strop.so b7c85000-b7c87000 rw-p 00003000 08:05 342592 /usr/lib/python2.5/lib-dynload/strop.so b7c87000-b7c89000 r-xp 00000000 08:05 344730 /usr/lib/python2.5/lib-dynload/_heapq.so b7c89000-b7c8b000 rw-p 00002000 08:05 344730 /usr/lib/python2.5/lib-dynload/_heapq.so b7c8b000-b7c8e000 r-xp 00000000 08:05 342596 /usr/lib/python2.5/lib-dynload/time.so b7c8e000-b7c90000 rw-p 00002000 08:05 342596 /usr/lib/python2.5/lib-dynload/time.so b7c90000-b7c97000 r--s 00000000 08:05 782059 /usr/lib/gconv/gconv-modules.cache b7c97000-b7cd2000 r--p 00000000 08:05 261980 /usr/lib/locale/en_US.utf8/LC_CTYPE b7cd2000-b7d55000 rw-p b7cd2000 00:00 0 b7d55000-b7e90000 r-xp 00000000 08:05 620099 /lib/tls/i686/cmov/libc-2.5.so b7e90000-b7e91000 r--p 0013b000 08:05 620099 /lib/tls/i686/cmov/libc-2.5.so b7e91000-b7e93000 rw-p 0013c000 08:05 620099 /lib/tls/i686/cmov/libc-2.5.so b7e93000-b7e96000 rw-p b7e93000 00:00 0 b7e96000-b7ebb000 r-xp 00000000 08:05 620107 /lib/tls/i686/cmov/libm-2.5.so b7ebb000-b7ebd000 rw-p 00024000 08:05 620107 /lib/tls/i686/cmov/libm-2.5.so b7ebd000-b7ebf000 r-xp 00000000 08:05 620133 /lib/tls/i686/cmov/libutil-2.5.so b7ebf000-b7ec1000 rw-p 00001000 08:05 620133 /lib/tls/i686/cmov/libutil-2.5.so b7ec1000-b7ec2000 rw-p b7ec1000 00:00 0 b7ec2000-b7ec4000 r-xp 00000000 08:05 620105 /lib/tls/i686/cmov/libdl-2.5.so b7ec4000-b7ec6000 rw-p 00001000 08:05 620105 /lib/tls/i686/cmov/libdl-2.5.so b7ec6000-b7ed9000 r-xp 00000000 08:05 620125 /lib/tls/i686/cmov/libpthread-2.5.so b7ed9000-b7edb000 rw-p 00013000 08:05 620125 /lib/tls/i686/cmov/libpthread-2.5.so b7edb000-b7edd000 rw-p b7edb000 00:00 0 b7edd000-b7edf000 r-xp 00000000 08:05 342568 /usr/lib/python2.5/lib-dynload/_random.so b7edf000-b7ee0000 rw-p 00002000 08:05 342568 /usr/lib/python2.5/lib-dynload/_random.so b7ee0000-b7ee1000 r-xp 00000000 08:05 344729 /usr/lib/python2.5/lib-dynload/_bisect.so b7ee1000-b7ee2000 rw-p 00001000 08:05 344729 /usr/lib/python2.5/lib-dynload/_bisect.so b7ee2000-b7ee7000 r-xp 00000000 08:05 342588 /usr/lib/python2.5/lib-dynload/operator.so b7ee7000-b7ee8000 rw-p 00005000 08:05 342588 /usr/lib/python2.5/lib-dynload/operator.so b7ee8000-b7eed000 r-xp 00000000 08:05 342584 /usr/lib/python2.5/lib-dynload/itertools.so b7eed000-b7eef000 rw-p 00005000 08:05 342584 /usr/lib/python2.5/lib-dynload/itertools.so b7eef000-b7ef1000 rw-p b7eef000 00:00 0 b7ef1000-b7f0a000 r-xp 00000000 08:05 586389 /lib/ld-2.5.so b7f0a000-b7f0c000 rw-p 00019000 08:05 586389 /lib/ld-2.5.so bf997000-bf9be000 rwxp bf997000 00:00 0 [stack] bf9be000-bf9bf000 rw-p bf9be000 00:00 0 ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] Aborted (core dumped)

2 1

NumPy trunk is frozen for upcoming 1.0.4 release
by Jarrod Millman Nov. 3, 2007

Nov. 3, 2007

Hello, NumPy 1.0.4 is almost out! I will be tagging the release this Sunday (11/4), so please be extra careful about anything you check-in over the next 24 hours. Once the tag is made, the trunk will be open for changes. I plan to announce the 1.0.4 release by Wednesday (11/7). I am hoping that everyone will be able to take the time to test the NumPy trunk this weekend and alert me of any problems. Please check-out the trunk, build it, and run the full test suite: svn co http://svn.scipy.org/svn/numpy/trunk ./numpy-trunk cd numpy-trunk python setup.py build sudo python setup.py install python import numpy numpy.test(10,10) Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

1 0

C or C++ package like NumPy?
by Bill Baxter Nov. 2, 2007

Nov. 2, 2007

Does anyone know of a C or C++ library that's similar to NumPy? Seems like all the big C++ efforts are focused on linear algebra rather than general purpose multidimensional arrays. I've written a multidimensional array class in the D programming language with an API modeled loosely after NumPy's. It works ok but there are a lot of differences between a statically typed language like C++ or D and a dynamic one like Python. So I was looking around for API inspiration from other C/C++ libraries. But the projects I know about are all focused on linear algebra (like ublas and MTL) and don't support general N-dimensional arrays. Thanks for your comments. --bb

6 9

weird numpy/pickle problem
by Brian Blais Nov. 2, 2007

Nov. 2, 2007

Hello, I encountered a peculiar numpy and pickle problem. My version: Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) Mac OS X Tiger In [2]:numpy.__version__ Out[2]:'1.0.4.dev3869' I pickle a matrix, and reload it. Some operations work ok, but others give a hardware error and a crash! I boiled it down to the code below. Can anyone reproduce (or not) this error? thanks, bb -- Brian Blais bblais(a)bryant.edu http://web.bryant.edu/~bblais ======================================================================= from numpy import matrix,random import pickle w_test=matrix(random.rand(3,21)) fid=open('blah0_test.pickle','wb') pickle.dump(w_test,fid,0) fid.close() fid=open('blah0_test.pickle','rb') w_xh=pickle.load(fid) fid.close() # this works print w_xh*w_xh.T #this works x=matrix(random.rand(2,21)) print x*w_xh.T # this gives a hardware error! x=matrix([0]*21) print x*w_xh.T

2 1

Re: [Numpy-discussion] weird numpy/pickle problem
by Neil Martinsen-Burrell Nov. 2, 2007

Nov. 2, 2007

On 11/2/07 12:00, "numpy-discussion-request(a)scipy.org" <numpy-discussion-request(a)scipy.org> wrote: > Date: Fri, 2 Nov 2007 12:58:33 -0400 > From: Brian Blais <bblais(a)bryant.edu> > Subject: [Numpy-discussion] weird numpy/pickle problem > To: numpy-discussion(a)scipy.org > > I boiled it down to the code below. Can anyone reproduce (or not) > this error? Works for me on OS X 10.4.9, Python 2.5.0, numpy 1.0.4dev3977. -Neil -- "The theory of probabilities is at bottom nothing but common sense reduced to calculus." -- Pierre Simon de Laplace

1 0

Re: [Numpy-discussion] [Pythonmac-SIG] Problem with numpy on Leopard
by Brian Granger Nov. 2, 2007

Nov. 2, 2007

On 11/1/07, Bill Janssen <janssen(a)parc.com> wrote: > > > It's not entirely silly. This has been the advice given to app > > > developers on this list and the PyObjC list for years now. It's nice > > > to have a better system Python for quick scripts, but it's still the > > > System Python. It's Apples, for their stuff that uses Python. And it > > > is specific to OS 10.5. If you use it to build your app, your app is > > > pretty much guaranteed not to work when someone tries to run it on > > > 10.6, etc. > > > > At some level I agree - I haven't used the system python on Tiger for > > a long time now. But, that is not how Apple "sells" the python on > > their system. > > This is really interesting. For my apps, I use the system Python on > Tiger, and expect to do it again with Leopard. If I have to have a > specific version of an extension that's needed, I make sure the > directory where I keep it is on the sys.path of my application before > the standard directories. That seems to be about all that's required. > I'm not sure what all the FUD about the system Python is... There is little fear, uncertainty or doubt about this. The problem is that this represents a huge change of behavior for users making the transition to Leopard. On Tiger, a user could download any basically any python pacakge and do "python setup.py install" and things would work. Now under Leopard, this becomes "python setup.py install" + muck with PYTHONPATH or .pth files. I personally have no problem doing this, but many of the casual python users with whom I work will be tripped up by this....and they will come and ask me what to do....over and over again.... Brian

1 0

Re: [Numpy-discussion] numpy FFT memory accumulation
by Ray Schumacher Nov. 2, 2007

Nov. 2, 2007

At 10:57 PM 11/1/2007, Charles R Harris wrote: > > An additional complication is that I pass the numpy (or Numeric) > > array address to the ctypes library call so that the data is placed > > directly into the array from the call. I use the if/else end wrap > > logic to determine whether I need to do a split and copy if the new > > data wraps. > >OK. Hmm, I wonder if you would lose much by taking a straight forward >radix-2 fft and teaching it to use modular indices? Probably not worth the >trouble, but an fft tailored to a ring buffer might be useful for other >things. The problem is, I once compiled my own FFT dll to call from Python and it was 2x slower than FFTPACK - I'm not math-smart enough to make all of the caching and numerical shortcuts. That, and Intel's optimized FFT is 3x faster than FFTPACK... I may still try to do a "zoom/range FFT" which does not compute all bins, and maybe only with a sine transform, which (I think) should be sufficient to determine peak real frequency and maybe use fewer cycles. >Probably the easiest thing is to just copy the ring buffer out into >a linear array. I do that for the buffer-wrap condition, while simply assigning a slice (no copy) to the temp array otherwise. > > I used Numeric functions for the ~40% speed increase, but I don't > >I know that numarray was slow in creating small arrays, but is Numpy >really that bad compared to Numeric? I just saw the # of FFTs/sec go from 390 to 550 just by switching numpy to Numeric (Intel Core Duo). Add a timer to my previous code posts and see how your results look. For the mega-arrays a lot of the numpy developers work with it is much faster, and I now find Numeric is lacking many other niceties, like frombuffer(). Ray -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.18/1104 - Release Date: 11/1/2007 6:47 PM

1 0

vectorizing loops
by Mathew Yeates Nov. 2, 2007

Nov. 2, 2007

Anybody know of any tricks for handling something like z[0]=1.0 for i in range(100): out[i]=func1(z[i]) z[i+1]=func2(out[i]) ??

10 19

Re: [Numpy-discussion] Problem with numpy on Leopard
by Ned Deily Nov. 2, 2007

Nov. 2, 2007

In article <07Nov1.205537pst."57996"@synergy1.parc.xerox.com>, Bill Janssen <janssen(a)parc.com> wrote: > This is really interesting. For my apps, I use the system Python on > Tiger, and expect to do it again with Leopard. If I have to have a > specific version of an extension that's needed, I make sure the > directory where I keep it is on the sys.path of my application before > the standard directories. That seems to be about all that's required. > I'm not sure what all the FUD about the system Python is... For your own apps on your own machines, sure - you can manage the whole environment and the system Python should be fine (that is, if and until you need a newer build of Python itself). I think the "FUD" you refer to concerns a different problem: developing and distributing multiple-component Python apps to multiple users on multiple machines. Controlling all those environments isn't so easy. Deploying apps and components as eggs using setuptools is one way to simplify that problem; building standalone OSX apps with embedded stripped-down Python runtimes and components using py2app is another. -- Ned Deily, nad(a)acm.org

1 0

Re: [Numpy-discussion] [Pythonmac-SIG] Problem with numpy on Leopard
by Brian Granger Nov. 2, 2007

Nov. 2, 2007

> It's not entirely silly. This has been the advice given to app > developers on this list and the PyObjC list for years now. It's nice > to have a better system Python for quick scripts, but it's still the > System Python. It's Apples, for their stuff that uses Python. And it > is specific to OS 10.5. If you use it to build your app, your app is > pretty much guaranteed not to work when someone tries to run it on > 10.6, etc. At some level I agree - I haven't used the system python on Tiger for a long time now. But, that is not how Apple "sells" the python on their system. > Maybe they have changed how py2app works in 10.5, but the old behavior > was to embed Python into your app, UNLESS it was the system python. > Unless there is evidence to the contrary (I don't have Leopard yet), I > assume that is still true. > > The old advice still holds: For building apps, install your own > framework build of Python, put it first in your path, and add any > libraries you require to it. Then you have control over what goes > into your app, not Apple. > > --Dethe > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig >

1 0

Re: [Numpy-discussion] numpy FFT memory accumulation
by Ray S Nov. 1, 2007

Nov. 1, 2007

At 09:00 AM 11/1/2007, you wrote: I saw that Numeric did also (I still use Numeric for smaller array speed) but much more slowly. I will try to repeat with a small demo and post. It turns out to be some aspect of mixing numpy and Numeric; the attached *Stable.py files allocate memory that stays exactly the same mixedGrows.py grows by about 50kB/s while changing slightly, randomly; note that the array is assigned as numpy and operated on with Numeric functions. My main app also uses mmap/numpy to assign the arrays to shared memory for multiple processes, and does other operations as well, possibly accounting for the faster memory growth. I'll re-factor to an all-numpy solution and test. I used Numeric functions for the ~40% speed increase, but I don't have a compiled version of arrayfrombuffer() for Numeric http://www.canonical.org/~kragen/sw/arrayfrombuffer/ (compiler version woes) so, I must use numpy.frombuffer() with mmap to create the shared arrays... Ray

2 1

Re: [Numpy-discussion] numpy FFT memory accumulation
by Ray S Nov. 1, 2007

Nov. 1, 2007

At 09:00 AM 11/1/2007, Chuck wrote: In Python, collections.deque makes a pretty good circular buffer. Numpy will make an array out of it, which involves a copy, but it might be better than what you are doing now. hmmm, I'll think more about that - and the copy is only at program start, it seems the fft can always be fft(d[:-N]) >>> from collections import deque >>> import numpy as N >>> d = deque(N.zeros(10,)) >>> d.extend(N.ones(4,)) >>> d deque([0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 1.0, 1.0, 1.0]) >>> [d.pop() for i in range(4)] [1.0, 1.0, 1.0, 1.0] >>> d deque([0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]) An additional complication is that I pass the numpy (or Numeric) array address to the ctypes library call so that the data is placed directly into the array from the call. I use the if/else end wrap logic to determine whether I need to do a split and copy if the new data wraps. Thanks, Ray

2 1

Problem with numpy on Leopard
by Brian Granger Nov. 1, 2007

Nov. 1, 2007

Hi, It turns out that Leopard includes numpy. But it is an older version that won't detect the version string of gfortran correctly (thus preventing scipy from being installed). But, when I downloaded the numpy svn and did python setup.py python was still finding the older version of numpy. The problem is a trivial but unfortunate ordering of things in the default sys.path. Here is the message that I sent to the pythonmac-sig about this: ************************************************************************ I have been playing around with python on Leopard today. Overall, I am very pleased, but I just ran into a problem that will affect a large number of users. In Leopard, Apple includes a number of python packages in: ls /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python CoreGraphics easy_install.pyc setuptools-0.6c7-py2.5.egg-info OpenSSL fetchmailconf.py site.py PyObjC fetchmailconf.pyc site.pyc PyObjC.pth fetchmailconf.pyo site.pyo PyRSS2Gen-1.0.0-py2.5.egg-info libsvn svn PyRSS2Gen.py macholib twisted PyRSS2Gen.pyc macholib-1.2.1.dev-py2.5.egg-info wx Twisted-2.4.0-py2.5.egg-info modulegraph wx-2.8-mac-unicode Twisted_Words-0.4.0-py2.5.egg-info modulegraph-0.7.2.dev-py2.5.egg-info wxPython Twisted_Xish-0.4.0-py2.5.egg-info numpy wxPython_common-2.8.4.0-py2.5.egg-info altgraph numpy-1.0.1-py2.5.egg-info wxaddons altgraph-0.6.8.dev-py2.5.egg-info pkg_resources.py wxaddons-2.8.4.0-py2.5.egg-info bdist_mpkg pkg_resources.pyc wxversion.py bdist_mpkg-0.4.3.dev-py2.5.egg-info py2app wxversion.pyc bonjour py2app-0.4.1.dev-py2.5.egg-info xattr bonjour_py-0.2-py2.5.egg-info pyOpenSSL-0.6-py2.5.egg-info xattr-0.5-py2.5.egg-info dateutil python_dateutil-1.2-py2.5.egg-info zope easy_install.py setuptools zope.interface-3.3.0-py2.5.egg-info At first I was very excited to see that Apple is including things like setuptools, numpy, twisted...... But then I saw that some of the versions are quite old. Naturally, I grabbed the latest numpy version from svn and did a python setup.py install. Everything built just fine, but when I did an import numpy, I got Apples version: >>> import numpy >>> print numpy.__file__ /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/numpy/__init__.pyc After looking at sys.path, it became clear what the problem is: Running python setup.py install on Leopard causes packages to be installed in the usual: /Library/Python/2.5/site-packages But, Apple put this directory _after_ /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python in sys.path. This, even if a user installs a newer version of one of these packages, the builtin python will always use Apple's older version. Obviously, I can set PYTHONPATH to get /Library/Python/2.5/site-packages earlier in the sys.path list, but this is going to bite many people. Is this a bug that I should report to Apple, or is there a better work around? Also, this information needs to be posted somewhere so we don't see this question a billion times on various lists over the lifetime of Leopard. Cheers, Brian

5 6

matrix problem: float to matrix power
by Alan G Isaac Nov. 1, 2007

Nov. 1, 2007

>>> 1.0**numpy.array([1,2,3]) array([ 1., 1., 1.]) >>> 1.0**numpy.mat([1,2,3]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for ** or pow(): 'float' and 'matrix' Why the restriction for matrices? Same question for matrices conformable for broadcasting: why not produce the equivalent of the array result? Cheers, Alan Isaac

4 7

Re: [Numpy-discussion] numpy FFT memory accumulation
by Ray Schumacher Nov. 1, 2007

Nov. 1, 2007

At 11:55 PM 10/31/2007, Travis wrote: >Ray S wrote: > > I am using > > fftRes = abs(fft.rfft(data_array[end-2**15:end])) > > >At first glance, I would say that I don't expect memory to be growing >here, so it looks like a problem with rfft that deserves looking into. I saw that Numeric did also (I still use Numeric for smaller array speed) but much more slowly. I will try to repeat with a small demo and post. >Does data_array keep growing? no, it is a 64k circular buffer Which reminds me, I've been wanting to try to build a Numeric circular buffer object; one that, when sliced or assigned to, auto-magically wraps as needed, exposing only an extra pointer attribute for the "end". I currently always do it with Python if-s and pointer vars for these products that only do "real time" data analysis. >From: "Anne Archibald" <peridot.faceted(a)gmail.com> >If the range is *really* small, you can try using a DFT - sometimes >that is fast enough, and gives you just the bins you're curious about. I've considered weave'ing a simple sine transform with specified range, but until I do and test I won't know if my own implementation is any faster than just the FFTPACK. >If the range is bigger than that, but still a small fraction of the >FFT size, you can do some tricks where you band-pass filter the data >... >There are also "zoom fft" and "chirp-z" techniques which are supposed >to give you only part of the FFT, but the wisdom is that unless you >want less than a few percent of the data points you're better just >FFTing and throwing lots of data away. I've tried zoom before; the issue was just that - 2 FFTs and a shift or convolution eats a lot of CPU cycles and falls behind the real time data. The range of interest in the Fourrier domain is small, 3kHz-7kHz. The sample rate is high for precise phase information. I've got some more testing to do, it seems. Thanks, Ray -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.15/1101 - Release Date: 10/31/2007 10:06 AM

2 1

how to get/set column
by dev new Nov. 1, 2007

Nov. 1, 2007

is there a method for numpy arrays and matrices to get/set a particular column i know that a row can be fetched by mymat[1,:] etc can this be done for a column dn

2 1

strange problem compiling against ndarrayobject.h
by Vincent Schut Nov. 1, 2007

Nov. 1, 2007

Hmm, it seems my original message did not come through? Not in gmane, at least... Well, here's again: Hi numpy and/or gdal guru's, I'm suddenly getting into trouble compiling gdal's python extension, when it includes ndarrayobject.h from numpy. First it complains about my python not being unicode, though I am sure it is unicode, and then it bails out with all kinds of errors (see snippet below). Numpy people, please read on even though this might seem a gdal problem, because it clearly is numpy related, see the snippet... I've tried everything I could think of, but to no avail. I hope one of you can give me a hint, because I'm kind of clueless, and even don't know in what direction I should search... Here is a paste from the output from building (python setup.py build) in the gdal/swig/python dir. make[2]: Entering directory `/usr/local/src/gdal/swig/python' python setup.py build numpy include /usr/lib64/python2.5/site-packages/numpy/core/include running build running build_py creating build creating build/lib.linux-x86_64-2.5 copying gdal.py -> build/lib.linux-x86_64-2.5 copying ogr.py -> build/lib.linux-x86_64-2.5 copying osr.py -> build/lib.linux-x86_64-2.5 copying gdalconst.py -> build/lib.linux-x86_64-2.5 creating build/lib.linux-x86_64-2.5/osgeo copying osgeo/gdalnumeric.py -> build/lib.linux-x86_64-2.5/osgeo copying osgeo/gdalconst.py -> build/lib.linux-x86_64-2.5/osgeo copying osgeo/__init__.py -> build/lib.linux-x86_64-2.5/osgeo copying osgeo/osr.py -> build/lib.linux-x86_64-2.5/osgeo copying osgeo/gdal_array.py -> build/lib.linux-x86_64-2.5/osgeo copying osgeo/gdal.py -> build/lib.linux-x86_64-2.5/osgeo copying osgeo/ogr.py -> build/lib.linux-x86_64-2.5/osgeo running build_ext building 'osgeo._gdal' extension C compiler: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC creating build/temp.linux-x86_64-2.5 creating build/temp.linux-x86_64-2.5/extensions compile options: '-I../../port -I../../gcore -I../../alg -I../../ogr -I/usr/lib64/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: extensions/gdal_wrap.cpp extensions/gdal_wrap.cpp: In function ‘PyObject* _wrap_MajorObject_SetMetadata__SWIG_0(PyObject*, PyObject*)’: extensions/gdal_wrap.cpp:4570: warning: deprecated conversion from string constant to ‘char*’ x86_64-pc-linux-gnu-g++ -pthread -shared build/temp.linux-x86_64-2.5/extensions/gdal_wrap.o -L../../.libs -L../.. -L/usr/lib64 -lgdal -lpython2.5 -o build/lib.linux-x86_64-2.5/osgeo/_gdal.so building 'osgeo._gdalconst' extension C compiler: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC compile options: '-I../../port -I../../gcore -I../../alg -I../../ogr -I/usr/lib64/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: extensions/gdalconst_wrap.c x86_64-pc-linux-gnu-gcc -pthread -shared build/temp.linux-x86_64-2.5/extensions/gdalconst_wrap.o -L../../.libs -L../.. -L/usr/lib64 -lgdal -lpython2.5 -o build/lib.linux-x86_64-2.5/osgeo/_gdalconst.so building 'osgeo._osr' extension C compiler: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC compile options: '-I../../port -I../../gcore -I../../alg -I../../ogr -I/usr/lib64/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: extensions/osr_wrap.cpp x86_64-pc-linux-gnu-g++ -pthread -shared build/temp.linux-x86_64-2.5/extensions/osr_wrap.o -L../../.libs -L../.. -L/usr/lib64 -lgdal -lpython2.5 -o build/lib.linux-x86_64-2.5/osgeo/_osr.so building 'osgeo._ogr' extension C compiler: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC compile options: '-I../../port -I../../gcore -I../../alg -I../../ogr -I/usr/lib64/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: extensions/ogr_wrap.cpp x86_64-pc-linux-gnu-g++ -pthread -shared build/temp.linux-x86_64-2.5/extensions/ogr_wrap.o -L../../.libs -L../.. -L/usr/lib64 -lgdal -lpython2.5 -o build/lib.linux-x86_64-2.5/osgeo/_ogr.so building 'osgeo._gdal_array' extension C compiler: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC compile options: '-I../../port -I../../gcore -I../../alg -I../../ogr -I/usr/lib64/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: extensions/_gdal_array.cpp In file included from /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14, from extensions/gdal_array.h:10, from extensions/_gdal_array.cpp:33: /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:92:2: error: #error Must use Python with unicode enabled. In file included from /usr/include/python2.5/Python.h:62, from extensions/gdal_array.h:16, from extensions/_gdal_array.cpp:33: /usr/include/python2.5/pyport.h:105:1: warning: "PY_SSIZE_T_MAX" redefined In file included from /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14, from extensions/gdal_array.h:10, from extensions/_gdal_array.cpp:33: /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:931:1: warning: this is the location of the previous definition In file included from /usr/include/python2.5/Python.h:62, from extensions/gdal_array.h:16, from extensions/_gdal_array.cpp:33: /usr/include/python2.5/pyport.h:107:1: warning: "PY_SSIZE_T_MIN" redefined In file included from /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14, from extensions/gdal_array.h:10, from extensions/_gdal_array.cpp:33: /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:932:1: warning: this is the location of the previous definition In file included from /usr/include/python2.5/Python.h:131, from extensions/gdal_array.h:16, from extensions/_gdal_array.cpp:33: /usr/include/python2.5/abstract.h:762:1: warning: "PyIndex_Check" redefined In file included from /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14, from extensions/gdal_array.h:10, from extensions/_gdal_array.cpp:33: /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:937:1: warning: this is the location of the previous definition In file included from /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14, from extensions/gdal_array.h:10, from extensions/_gdal_array.cpp:33: /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:919: error: ‘Py_intptr_t’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:920: error: ‘Py_uintptr_t’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1012: error: expected initializer before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013: error: typedef ‘PyArray_SetItemFunc’ is initialized (use __typeof__ instead) /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013: error: ‘PyObject’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013: error: expected primary-expression before ‘,’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013: error: expected primary-expression before ‘void’ /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1013: error: expected primary-expression before ‘void’ /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1015: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1015: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1016: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1026: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1026: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1028: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1028: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1029: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1031: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1041: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1043: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1044: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1044: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1046: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1050: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1052: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1053: error: ‘npy_intp’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1056: error: ISO C++ forbids declaration of ‘npy_intp’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1056: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1069: error: ISO C++ forbids declaration of ‘PyArray_GetItemFunc’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1069: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1070: error: ISO C++ forbids declaration of ‘PyArray_SetItemFunc’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1070: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1121: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1121: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1171: error: ‘PyObject_HEAD’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1190: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1190: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1194: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1194: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1203: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1203: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1213: error: ISO C++ forbids declaration of ‘PyObject_HEAD’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1214: error: expected ‘;’ before ‘char’ /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1216: error: ISO C++ forbids declaration of ‘npy_intp’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1216: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1217: error: ISO C++ forbids declaration of ‘npy_intp’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1217: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1219: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1219: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1229: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1229: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1238: error: ‘PyObject_HEAD’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1246: error: ‘PyObject_HEAD’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1249: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1253: error: ‘PyObject’ has not been declared /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1395: error: ISO C++ forbids declaration of ‘PyObject_HEAD’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1396: error: expected ‘;’ before ‘int’ /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1397: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1398: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1399: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1400: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1401: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1402: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1542: error: ISO C++ forbids declaration of ‘PyObject_HEAD’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1543: error: expected ‘;’ before ‘int’ /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1544: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1545: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1547: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1596: error: ISO C++ forbids declaration of ‘PyObject_HEAD’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1600: error: expected ‘;’ before ‘int’ /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1602: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1604: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1606: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1622: error: ‘npy_intp’ does not name a type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1624: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1624: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1799: error: ISO C++ forbids declaration of ‘npy_intp’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1799: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1800: error: ISO C++ forbids declaration of ‘npy_intp’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1800: error: expected ‘;’ before ‘*’ token /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1802: error: ISO C++ forbids declaration of ‘PyObject’ with no type /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1802: error: expected ‘;’ before ‘*’ token In file included from /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:1814, from /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14, from extensions/gdal_array.h:10, from extensions/_gdal_array.cpp:33: /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h: In function ‘int _import_array()’: /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:945: error: ‘PyObject’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:945: error: ‘numpy’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:945: error: ‘PyImport_ImportModule’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:946: error: ‘c_api’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:948: error: ‘PyObject_GetAttrString’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:949: error: ‘Py_DECREF’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:950: error: ‘PyCObject_Check’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:951: error: ‘PyCObject_AsVoidPtr’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:953: error: ‘Py_DECREF’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:958: error: ‘PyExc_RuntimeError’ was not declared in this scope /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/__multiarray_api.h:958: error: ‘PyErr_Format’ was not declared in this scope In file included from /usr/include/python2.5/Python.h:62, from extensions/gdal_array.h:16, from extensions/_gdal_array.cpp:33: /usr/include/python2.5/pyport.h: At global scope: /usr/include/python2.5/pyport.h:97: error: conflicting declaration ‘typedef ssize_t Py_ssize_t’ /usr/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:930: error: ‘Py_ssize_t’ has a previous declaration as ‘typedef int Py_ssize_t’ extensions/_gdal_array.cpp: In function ‘void init_gdal_array()’: extensions/_gdal_array.cpp:118: warning: deprecated conversion from string constant to ‘char*’ extensions/_gdal_array.cpp: In destructor ‘virtual NUMPYDataset::~NUMPYDataset()’: extensions/_gdal_array.cpp:162: error: ‘struct PyArrayObject’ has no member named ‘ob_refcnt’ extensions/_gdal_array.cpp: In static member function ‘static GDALDataset* NUMPYDataset::Open(GDALOpenInfo*)’: extensions/_gdal_array.cpp:382: error: ‘struct PyArrayObject’ has no member named ‘ob_refcnt’ extensions/_gdal_array.cpp:393: error: ‘struct PyArrayObject’ has no member named ‘dimensions’ extensions/_gdal_array.cpp:394: error: ‘struct PyArrayObject’ has no member named ‘strides’ extensions/_gdal_array.cpp:395: error: ‘struct PyArrayObject’ has no member named ‘dimensions’ extensions/_gdal_array.cpp:396: error: ‘struct PyArrayObject’ has no member named ‘strides’ extensions/_gdal_array.cpp:397: error: ‘struct PyArrayObject’ has no member named ‘dimensions’ extensions/_gdal_array.cpp:398: error: ‘struct PyArrayObject’ has no member named ‘strides’ extensions/_gdal_array.cpp:404: error: ‘struct PyArrayObject’ has no member named ‘dimensions’ extensions/_gdal_array.cpp:405: error: ‘struct PyArrayObject’ has no member named ‘strides’ extensions/_gdal_array.cpp:406: error: ‘struct PyArrayObject’ has no member named ‘dimensions’ extensions/_gdal_array.cpp:407: error: ‘struct PyArrayObject’ has no member named ‘strides’ extensions/_gdal_array.cpp:418: error: ‘struct PyArrayObject’ has no member named ‘data’ going on like this for some more, but I hope this suffices... TIA, Vincent.

1 1