Mailman 3 January 2005 - NumPy-Discussion

Numarray feature request: supporting the buffer interface
by Prabhu Ramachandran Jan. 7, 2005

Jan. 7, 2005

Hi Numarray developers, Numeric arrays support the buffer interface by providing an array_as_buffer structure in the type object definition by doing this: (PyBufferProcs *)&array_as_buffer, /*tp_as_buffer*/ and adding this to the tp_flags: Py_TPFLAGS_HAVE_GETCHARBUFFER), /*tp_flags*/ This is very handy when one needs to pass void arrays into C/C++ code and is used to pass data from Numeric to C or C++ libraries very efficiently. In particular, this is very useful when passing Numeric array data to VTK. I noticed that numarray does not support this interface. My feature request is that numarray arrays also support this buffer interface (if possible). Thanks! cheers, prabhu p.s. I'm not on this list so please cc me in on any messages. Thanks!

3 4

Re: [Numpy-discussion] Numarray feature request: supporting the buffer interface
by Todd Miller Jan. 7, 2005

Jan. 7, 2005

On Fri, 2005-01-07 at 09:54, Robert Kern wrote: > Todd Miller wrote: > > > numarray has a concept of "misbehaved arrays", i.e. arrays in the > > binary format of another platform and therefore byte-swapped, or arrays > > spread across records and therefore possibly noncontiguous or > > misaligned. I think these buffers are likely unusable so providing > > access to them is a mistake. Misbehaved arrays probably don't arise in > > the work of most users, but they are a possibility that has to be > > accounted for. > > > > For cases of misbehaved arrays, I think raising a ValueError exception > > is necessary. How does that sound? > > For the byteswapped case, could I still get a buffer object around the > raw data by using _data? If so, I vote +1. Sure. Alternately, you could make a copy of the array which will automatically be well behaved and therefore usable in C. Regards, Todd

1 0

Padding policy in CharArrays
by Francesc Altet Jan. 6, 2005

Jan. 6, 2005

Hi, I'm experiencing some problems derived from the fact that CharArrays in numarray are padded with spaces. That leads to somewhat curious consequences like this: In [180]: a=strings.array(None, itemsize = 4, shape=1) In [181]: a[0] = '0' In [182]: a >= '0\x00\x00\x00\x01' Out[182]: array([1], type=Bool) # Incorrect but... In [183]: a[0] >= '0\x00\x00\x00\x01' Out[183]: False # correct While this is not a bug (see the padding policy for chararrays) I think it would be much better to use '\0x00' as default padding. Would be any problem with that?. If yes, well, I've found a workaround on this, but quite inelegant I'm afraid :-/ Have a Happy New Year! -- Francesc Altet >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data ""

2 4

A bug in numarray sign function.
by Nadav Horesh Jan. 6, 2005

Jan. 6, 2005

in numarraycore.py line 1504 should be changed from return zeros(shape(m))-less(m,0)+greater(m,0) to return zeros(shape(m))-ufunc.less(m,0)+ufunc.greater(m,0) otherwise sign function raises an error: /usr/local/lib/python2.4/site-packages/numarray/numarraycore.py in sign(m) 1502 """ 1503 m = asarray(m) -> 1504 return zeros(shape(m))-less(m,0)+greater(m,0) 1505 1506 def alltrue(array, axis=0): NameError: global name 'less' is not defined Nadav.

3 3

Re: [Numpy-discussion] Matlab/Numeric/numarray benchmarks
by Bruce Southey Jan. 6, 2005

Jan. 6, 2005

Hi, While on the subject on benchmarks, I thought I would point out an really excellent book by Hans Petter Langtangen's book: 'Python Scripting for computational science' (Springer, 2004: http://www.springeronline.com/sgw/cda/frontpage/0,0,4-0-22-17627636-0,0.html ). The book web site is http://folk.uio.no/hpl/scripting/ that also has the scripts. There is considerable detailed material on using Numeric and numarray as well as using Python callbacks from C/C++ and Fortran. Also addresses GUI programming and other topics in Python including regular expressions. One of the really great things about this book is the discussion on how to improve code with reference to a single example called gridloop. Gridloop just evaluates a function (the actual function used was 'sin(x,y) + 8*x') over a rectangular grid and stores the results in an array. There are well over 25 versions from using straight C, Fortran and C++ to using Python and Numerical Python. These benchmarks are on different ways to implement this gridloop function in Fortran, C/C++, numarray, Numeric and Python callbacks from C/C++ and Fortran. In the vectorized form relative to the F77 version, numarray (v0.9) was 2.7 times slower and Numeric (v23) was 3.0 times slower. Another items that appeared was that since the sin function is scalar, there was a huge difference in the Python implementation between using math.sin (140 times slower than F77), Numeric.sin (230 times slower than F77)and numarray.sin (350 times slower than F77). Perhaps, this suggests that namespace should be checked for scalar arguments before using vectorized versions. Regards Bruce Southey

1 0

install, numpy
by René Bastian Jan. 4, 2005

Jan. 4, 2005

Hi, I tried "python setup.py install" (Python2.4) in order to get Numeric-23.6 messages : running install running build running build_py running build_ext building 'lapack_lite' extension gcc -pthread -shared build/temp.linux-i686-2.4/Src/lapack_litemodule.o -L/usr/lib/atlas -llapack -lcblas -lf77blas -latlas -lg2c -o build/lib.linux-i686-2.4/lapack_lite.so error : /usr/i486-suse-linux/bin/ld: cannot find -llapack collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 Please, what is missing ? -- René Bastian http://www.musiques-rb.org : Musique en Python

4 5