NumPy-Discussion September 2007

numpy-discussion@python.org

76 participants
71 discussions

Initial support for sunperf and sun compilers (linux + solaris)
by David Cournapeau 16 Sep '07

16 Sep '07

Ok, I created a numpy branch to implement this, and get something working. This is still really rough, though. Please check out the numpy.sunperf branch: svn co http://svn.scipy.org/svn/numpy/branches/numpy.sunperf And then, compile it with the following: SUNPERF=SUNPERFROOT python setup.py build --compiler=sun --fcompiler=sun where SUNPERFROOT is the root of your sunperf installation (for me: /opt/sun/sunstudio12/; SUNPERFROOT/lib/ shoudl contain libsunperf.so). If this works, I will then polish the code to avoid having to set SUNPERF variable. On Linux, this seems to work (all test pass), but there may be some things on solaris which prevent it from working. I have not tested scipy either, so that something you could try also if numpy works. cheers, David

1 0

Building numpy 1.0.3-2 on Linux 2.6.8 i686 (Debian 3.1)
by Michael Hoffman 15 Sep '07

15 Sep '07

Hi. I have been trying to build NumPy on a 32-bit Linux box using python setup.py build. I received the following errors: """ creating build/temp.linux-i686-2.5/numpy/linalg compile options: '-DATLAS_WITHOUT_LAPACK -DATLAS_INFO="\"3.6.0\"" -I/usr/include -Inumpy/core/include -Ibuild/src.linux-i686-2.5/numpy/core -I/nfs/acari/mh5/include/python2.5 -I/nfs/acari/mh5/include -I/software/python-2.5/include/python2.5 -Inumpy/core/src -Inumpy/core/include -c' gcc: numpy/linalg/lapack_litemodule.c g77 build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o -L/usr/lib/sse2 -L/usr/lib -lf77blas -lcblas -latlas -llapack -lg2c-pic -o build/lib.linux-i686-2.5/numpy/linalg/lapack_lite.so build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o(.text+0x44): In function `initlapack_lite': numpy/linalg/lapack_litemodule.c:827: undefined reference to `Py_InitModule4' build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o(.text+0x57):numpy/linalg/lapack_litemodule.c:831: undefined reference to `PyModule_GetDict' build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o(.text+0x73):numpy/linalg/lapack_litemodule.c:832: undefined reference to `PyErr_NewException' build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o(.text+0x8f):numpy/linalg/lapack_litemodule.c:833: undefined reference to `PyDict_SetItemString' build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o(.text+0xa1):numpy/linalg/lapack_litemodule.c:836: undefined reference to `PyErr_Print' build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o(.text+0xa7):numpy/linalg/lapack_litemodule.c:836: undefined reference to `PyExc_ImportError' build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o(.text+0xbb):numpy/linalg/lapack_litemodule.c:836: undefined reference to `PyErr_SetString' [...] /usr/lib/libfrtbegin.a(frtbegin.o)(.text+0x32): In function `main': : undefined reference to `MAIN__' collect2: ld returned 1 exit status error: Command "g77 build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o -L/usr/lib/sse2 -L/usr/lib -lf77blas -lcblas -latlas -llapack -lg2c-pic -o build/lib.linux-i686-2.5/numpy/linalg/lapack_lite.so" failed with exit status 1 """ After some Googling, I found a recommendation to unset CFLAGS and LDFLAGS, but they are not set in the transcript above. Any suggestions? -- Michael Hoffman

2 5

Buildbot errors
by Charles R Harris 14 Sep '07

14 Sep '07

I got another buildbot notification and as far as I can tell it has nothing to do with my last commit. The stdio output is at http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell/0 And the errors seem to be of this sort: _configtest.c: In function 'main': _configtest.c:4: error: 'isnan' undeclared (first use in this function) _configtest.c:4: error: (Each undeclared identifier is reported only once _configtest.c:4: error: for each function it appears in.) _configtest.c: In function 'main': _configtest.c:4: error: 'isnan' undeclared (first use in this function) _configtest.c:4: error: (Each undeclared identifier is reported only once _configtest.c:4: error: for each function it appears in.) _configtest.c: In function 'main': _configtest.c:4: error: 'isinf' undeclared (first use in this function) _configtest.c:4: error: (Each undeclared identifier is reported only once _configtest.c:4: error: for each function it appears in.) _configtest.c: In function 'main': _configtest.c:4: error: 'isinf' undeclared (first use in this function) _configtest.c:4: error: (Each undeclared identifier is reported only once _configtest.c:4: error: for each function it appears in.) I haven't had any problems compiling on my own machine. Chuck

3 2

NotImplementedType
by Tom Denniston 14 Sep '07

14 Sep '07

Sometimes numpy operationrs result in NotImplementedType. It makes it a little hard to debug because the problem then crops up later when you try to do an operation with the NotImplementedType. Does anyone know of a way to get numpy to raise instead of returning not implemented type? (Pydb) other.value NotImplemented (Pydb) print other.value NotImplemented (Pydb) type(other.value) <type 'NotImplementedType'> --Tom

2 2

binomial, multinomial coefficients
by Charles R Harris 14 Sep '07

14 Sep '07

Does anyone know if there are routines in scipy to compute these numbers? If not, I could code some up if there is any interest. As a related question, are there routines for returning the probabilities (as opposed to random number generators) for the various distributions? Chuck

2 1

Requesting svn write access to numpy ?
by David Cournapeau 14 Sep '07

14 Sep '07

Hi, I would like to know whether I could request svn write access to numpy svn. There are several things I would like to work on which are big enough so that just patch would be difficult, and branches more appropriate, and my understanding is that svn branches requires write access. The things I would like to work on are: - in the immediate futur: support for sunperf, and solaris compilers - some work on numpy FFT (using KISS FFT, which is a BSD, really small library for FFT, see my other email) - some work on distutils for ctypes support (eg being able to build extension to be used with ctypes). Thank you, David

3 2

Compiling numpy with 64 bits support under Solaris
by Langella Raphael 14 Sep '07

14 Sep '07

Hi, I'm trying to compile numpy with 64 bits support under Sparc/Solaris 8. I've already compiled Python 2.5.1 with 64 bits. I've set up my environnement with : export CC="gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1" export CXX="g++ -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1" export LDFLAGS='-mcpu=v9 -m64' export LDDFLAGS='-mcpu=v9 -m64 -G' I also compiled blas and lapack in 64 bits. I know I don't need them for numpy, but I will soon when I'll compile scipy. I've tried to set up my site.cfg, tu use libfblas and libflapack and it didn't work. I tried libsunperf and got the same result : /outils_std/csw/gcc3/bin/g77 -mcpu=v9 -m64 build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o -L/outils_std/SUNS11/SUNWspro/lib/v9 -L/outils_std/csw/gcc3/bin/../lib/gcc/sparc-sun-solaris2.8/3.4 .4 -lsunperf -lg2c -o build/lib.solaris-2.8-sun4u-2.5/numpy/core/_dotblas.so Undefined first referenced symbol in file PyExc_ImportError build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyCObject_AsVoidPtr build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyArg_ParseTuple build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyExc_RuntimeError build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyEval_SaveThread build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyObject_GetAttrString build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyExc_ValueError build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o MAIN__ /outils_std/csw/gcc3/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.4 /../../../sparcv9/libfrtbegin.a(frtbegin.o) PyErr_SetString build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyErr_Format build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyCObject_Type build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyTuple_New build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyErr_Print build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyImport_ImportModule build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o _Py_NoneStruct build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o Py_InitModule4_64 build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyEval_RestoreThread build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o ld: fatal: Symbol referencing errors. No output written to build/lib.solaris-2.8-sun4u-2.5/numpy/core/_dotblas.so collect2: ld returned 1 exit status Undefined first referenced symbol in file PyExc_ImportError build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyCObject_AsVoidPtr build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyArg_ParseTuple build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyExc_RuntimeError build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyEval_SaveThread build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyObject_GetAttrString build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyExc_ValueError build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o MAIN__ /outils_std/csw/gcc3/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.4 /../../../sparcv9/libfrtbegin.a(frtbegin.o) PyErr_SetString build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyErr_Format build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyCObject_Type build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyTuple_New build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyErr_Print build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyImport_ImportModule build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o _Py_NoneStruct build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o Py_InitModule4_64 build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o PyEval_RestoreThread build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o ld: fatal: Symbol referencing errors. No output written to build/lib.solaris-2.8-sun4u-2.5/numpy/core/_dotblas.so collect2: ld returned 1 exit status error: Command "/outils_std/csw/gcc3/bin/g77 -mcpu=v9 -m64 build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o -L/outils_std/SUNS11/SUNWspro/lib/v9 -L/outils_std/csw/gcc3/bin/../lib/gcc/sparc-sun-solaris2.8/3.4 .4 -lsunperf -lg2c -o build/lib.solaris-2.8-sun4u-2.5/numpy/core/_dotblas.so" failed with exit status 1 Does numpy and scipy support 64 bits under Sparc/Solaris? Thanks. Regards, Raphaël Langella

2 1

APL2007 - Arrays and Objects - Early Bird Registration and Preliminary Program
by Steven H. Rogers 13 Sep '07

13 Sep '07

This is the last day for early bird registration for APL2007, 21-23 Oct in Montreal. It's co-located with OOPSLA2007 and sharing registration services at: http://www.regmaster.com/conf/oopsla2007.html =============== Preliminary Program =============== Tutorials and workshops ================= Introduction to APL (Ray Polivka) Object Oriented for APLers, APL for OOers (Dan Baronet) ... others in the works Presentations ========= No Experience Necessary: Hire for Aptitude - Train for Skills (Brooke Allen) Compiling APL with APEX (Robert Bernecky) APL, Bioinformatics, Cancer Research (Ken Fordyce) Generic Programming on Nesting Structure (Stephan Herhut, Sven-Bodo Scholz, Clemens Grelck) Interactive Array-Based Languages and Financial Research (Devon McCormick) Array vs Non-Array Approaches to Programming Problems (Devon McCormick) Design Issues in APL/OO Interfacing (Richard Nabavi) Arrays of Objects, or Arrays within Objects (Richard Nabavi) Competing, with J (John Randall) ... others in the works There is still room for oral or poster presentations that will not be contributed papers (published in a special issue of APL Quote Quad). If you would like to make an oral presentation or a poster, contact Lynne Shaw (Shaw(a)acm.org). ACM SIGAPL has broadened it's scope to all Array Programming Languages and NumPy/SciPy representation would be welcome.

1 0

numpy.ndarrays as C++ arrays (wrapped with boost)
by Alexander Schmolck 13 Sep '07

13 Sep '07

Hi, I've sent pretty much the same email to c++sig, but I thought I'd also try my luck here, especially since I just saw a closely related question posted one week ago here (albeit mostly from a swig context). I'm working working on an existing scientific code base that's mostly C++ and I'm currently interfacing it to python with boost.python with a view to doing non-performance critical things in python. The code currently mostly just uses plain C double arrays passed around by pointers and I'd like to encapsulate this at least with something like stl::vector (or maybe valarray), but I've been wondering whether it might not make sense to use (slightly wrapped) numpy ndarrays -- since I eventually plan to make fairly heavy use of existing python infrastructure like matplotlib and scipy where possible. Also, ndarrays provide fairly rich functionality even at the C-API-level and I'm pretty familiar with numpy. Furthermore I can't find something equivalent to numpy for C++ -- there's ublas as well as several other matrix libs and a couple of array ones (like blitz++), but there doesn't seem to be one obvious choice, as there is for python. I think I will mostly use double arrays of fairly large size, so having really low overhead operations on small arrays with more or less exotic types is not important to me. Things that would eventually come in handy, although they're not needed yet, are basic linear algebra and maybe two or three LAPACK-level functions (I can think of cholesky decomposition and SVD right now) as well as possibly wavelets (DWT). I think I could get all these things (and more) from scipy (and kin) with too much fuzz (although I haven't tried wavelet support yet) and it seems like picking together the same functionality from different C++ libs would require considerably more work. So my question is: might it make sense to use (a slightly wrapped) numpy.ndarray, and if so is some code already floating around for that (on first glance it seems like there's a bit of support for the obsolete Numeric package in boost, but none for the newer numpy that supercedes it); if not is my impression correct that making the existing code numpy compatible shouldn't be too much work. Provided this route doesn't make much sense, I'd also be curious what people would recommend doing instead. In last week's thread mentioned above I found the following link which looks pretty relevant, albeit essentially undocumented and possibly pre-alpha -- has anyone here tried it out? <http://thread.gmane.org/gmane.comp.python.c++/11559/focus=11560> many thanks, 'as

7 10

Docstring improvements for numpy.where?
by Fernando Perez 12 Sep '07

12 Sep '07

Hi all, A couple of times I've been confused by numpy.where(), and I think part of it comes from the docstring. Searching my gmail archive seems to indicate I'm not the only one bitten by this. Compare: In [14]: pdoc numpy.where Class Docstring: where(condition, | x, y) The result is shaped like condition and has elements of x and y where condition is respectively true or false. If x or y are not given, then it is equivalent to condition.nonzero(). To group the indices by element, rather than dimension, use transpose(where(condition, | x, y)) instead. This always results in a 2d array, with a row of indices for each element that satisfies the condition. with (b is just any array): In [17]: pdoc b.nonzero Class Docstring: a.nonzero() returns a tuple of arrays Returns a tuple of arrays, one for each dimension of a, containing the indices of the non-zero elements in that dimension. The corresponding non-zero values can be obtained with a[a.nonzero()]. To group the indices by element, rather than dimension, use transpose(a.nonzero()) instead. The result of this is always a 2d array, with a row for each non-zero element.; The sentence "The result is shaped like condition" in the where() docstring is misleading, since the behavior is really that of nonzero(). Where() *always* returns a tuple, not an array shaped like condition. If this were more clearly explained, along with a simple example for the usual case that seems to trip everyone: In [21]: a=arange(10) In [22]: N.where(a>5) Out[22]: (array([6, 7, 8, 9]),) In [23]: N.where(a>5)[0] Out[23]: array([6, 7, 8, 9]) I think we'd get a lot less confusion. Or am I missing something, or just being dense (quite likely)? Cheers, f

4 4

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

NumPy-Discussion September 2007