Mailman 3 September 2004 - NumPy-Discussion

PyArray_ContiguousFromObject & PyDECREF
by Michiel Jan Laurens de Hoon 16 May '11

16 May '11

Dear pythoneers, In Chapter 12 ("Writing a C extension") in the Numerical Python manual, in the first example PyArray_ContiguousFromObject is used together with PyDECREF, while in the last example PyArray_ContiguousFromObject is used but the arrays are not PyDECREF'ed before the function returns. From Chapter 13 ("C API Reference") it seems that a PyDECREF is needed in both cases. Or am I missing something here? Is PyDECREF not needed for some reason in the last example? Thanks in advance, Michiel de Hoon U Tokyo First example: ============== static PyObject * trace(PyObject *self, PyObject *args) { PyObject *input; PyArrayObject *array; double sum; int i, n; if (!PyArg_ParseTuple(args, "O", &input)) return NULL; array = (PyArrayObject *) PyArray_ContiguousFromObject(input, PyArray_DOUBLE, 2, 2); if (array == NULL) return NULL; n = array->dimensions[0]; if (n > array->dimensions[1]) n = array->dimensions[1]; sum = 0.; for (i = 0; i < n; i++) sum += *(double *)(array->data + i*array->strides[0] + i*array->strides[1]); Py_DECREF(array); return PyFloat_FromDouble(sum); } Last example: ============= static PyObject * matrix_vector(PyObject *self, PyObject *args) { PyObject *input1, *input2; PyArrayObject *matrix, *vector, *result; int dimensions[1]; double factor[1]; double real_zero[1] = {0.}; long int_one[1] = {1}; long dim0[1], dim1[1]; extern dgemv_(char *trans, long *m, long *n, double *alpha, double *a, long *lda, double *x, long *incx, double *beta, double *Y, long *incy); if (!PyArg_ParseTuple(args, "dOO", factor, &input1, &input2)) return NULL; matrix = (PyArrayObject *) PyArray_ContiguousFromObject(input1, PyArray_DOUBLE, 2, 2); if (matrix == NULL) return NULL; vector = (PyArrayObject *) PyArray_ContiguousFromObject(input2, PyArray_DOUBLE, 1, 1); if (vector == NULL) return NULL; if (matrix->dimensions[1] != vector->dimensions[0]) { PyErr_SetString(PyExc_ValueError, "array dimensions are not compatible"); return NULL; } dimensions[0] = matrix->dimensions[0]; result = (PyArrayObject *)PyArray_FromDims(1, dimensions, PyArray_DOUBLE); if (result == NULL) return NULL; dim0[0] = (long)matrix->dimensions[0]; dim1[0] = (long)matrix->dimensions[1]; dgemv_("T", dim1, dim0, factor, (double *)matrix->data, dim1, (double *)vector->data, int_one, real_zero, (double *)result->data, int_one); return PyArray_Return(result); } -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

3 2

floating point exception weirdness
by Andrew Straw 03 Nov '04

03 Nov '04

Hi All, I've isolated numarray.ieeespecial as the cause of a strange error which I posted on c.l.py: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=41198B29.709… My non-expert guess as to an explanation: some statements early in numarray.ieeespecial (e.g. _na.array(1.0)/_na.array(0.0)) result in a floating point exception being set which lies dormant until I call certain functions in the Intel IPP library (e.g. ippiAddWeighted_8u32f_C1IR), at which point the latent exception bit my Python program is killed while the console says "Floating point exception". I've come to this tentative conclusion based on 3 minimal Pyrex programs: ---------------------------------------------------- Version 1: import numarray.numarrayall as _na plus_inf = inf = _na.array(1.0)/_na.array(0.0) cimport avg avg.work() # calls IPP, terminates with "Floating point exception". ---------------------------------------------------- Version 2: import numarray.numarrayall as _na # Define *ieee special values* _na.Error.pushMode(all="ignore") plus_inf = inf = _na.array(1.0)/_na.array(0.0) _na.Error.popMode() cimport avg avg.work() # calls IPP, terminates with "Floating point exception". ---------------------------------------------------- Version 3: import numarray.numarrayall as _na cimport avg avg.work() # calls IPP, terminates normally In the short term, I'll try and work around this problem by not importing numarray.ieeespecial, but in the long term, I think we should try and fix this. I'm happy to try to debug further if someone gives me advice on where to go from here. Cheers! Andrew

2 6

dot!=matrixmultiply bug when dotblas is present
by Fernando Perez 01 Oct '04

01 Oct '04

Hi all, I found something today a bit unpleasant: if you install numeric without any BLAS support, 'matrixmultiply is dot==True', so they are fully interchangeable. However, to my surprise, if you build numeric with the blas optimizations, they are NOT identical. The reason is a bug in Numeric.py. After defining dot, the code reads: #This is obsolete, don't use in new code matrixmultiply = dot and at the very end of the file, we have: # try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot except ImportError: pass Obviously this means that matrixmultiply is stuck with the _old_ definition of dot, and does not benefit from the blas optimizations. This is BAD, as for a 1024x1024 matrix the difference is staggering: planck[Numeric]> pylab In [1]: a=rand(1024,1024) In [2]: b=rand(1024,1024) In [3]: from IPython.genutils import timing In [4]: timing 1,dot,a,b ------> timing(1,dot,a,b) Out[4]: 0.55591500000000005 In [5]: timing 1,matrixmultiply,a,b ------> timing(1,matrixmultiply,a,b) Out[5]: 68.142640999999998 In [6]: _/__ Out[6]: 122.57744619231356 Pretty significant difference... The fix is trivial. In Numeric.py, at the very end of the file, this part: # try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot except ImportError: pass should read instead: # try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot matrixmultiply = dot #### <<<--- NEW LINE except ImportError: pass I just checked and the problem still exists in Numpy 23.4. Cheers, f

3 3

Re: [Numpy-discussion] random number facilities in numarray and main Python libs
by Bruce Southey 30 Sep '04

30 Sep '04

Hi, The R project (http://www.r-project.org) provides a standalone GPL'ed Math library (buried in the src/nmath/standalone subdirectory of the R code). This includes random number generators for various distributions amongst other goodies. But I have not looked to see what approach that the actual uniform random generator uses (source comment says "A version of Marsaglia-MultiCarry"). However, this library should be as least as good as and probably better than Ranlib that is currently being used I used SWIG to generate wrappers for most of the functions (except the voids). SWIG makes it very easy but I needed to create a SWIG include file because using the header alone did not work correctly. If anyone wants more information or files, let me know. Bruce Southey ---- Original message ---- >Date: Tue, 07 Sep 2004 16:35:11 -0700 >From: Robert Kern <rkern(a)ucsd.edu> >Subject: Re: [Numpy-discussion] random number facilities in numarray and main Python libs >To: numpy-discussion(a)lists.sourceforge.net > >Faheem Mitha wrote: >[snip] >> Are the random number facilities provided by numarray.random_array >> superior to those provided to those provided by the random module in the >> Python library? They certainly seem more extensive, and I like the >> interface better. >> >> If so, why not replace the random module by the equivalent functionality >> from numarray.random_array, and have everyone use the same random number >> generator? Or is this impossible for practical reasons? > >numarray.random_array can generate arrays full of random numbers. >Standard Python's random does not and will not until numarray is part of >the standard library. Standard Python's random also uses the Mersenne >Twister algorithm which is, by most accounts, superior to RANLIB's >algorithm, so I for one would object to replacing it with numarray's >code. :-) > >I do intend to implement the Mersenne Twister algorithm for SciPy's PRNG >facilities (on some unspecified weekend). I will also try to code >something up for numarray, too. > >> By the way, what is the name of the pseudo-random number generator being >> used? I see that the code is in Packages/RandomArray2/Src, but could not >> see where the name of the generator is mentioned. > ><URL:http://orion.math.iastate.edu/burkardt/c_src/ranlib/ranlib_base.txt> >documents the base algorithm. > >> Faheem. > >-- >Robert Kern >rkern(a)ucsd.edu > >"In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click >_______________________________________________ >Numpy-discussion mailing list >Numpy-discussion(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/numpy-discussion

2 2

random number facilities in numarray and main Python libs
by Faheem Mitha 28 Sep '04

28 Sep '04

Dear People, I recently encountered a strange problem when writing some Python using random number code. I tried setting the seed at top level, but I was still get random results. I submitted a bug report, and had my error explained to me. I had run into this problem several times, and I think some mental block had prevented me from seeing the source of the problem. Part of the reason is that I had previously been using R, and everyone uses the same random number generator facilities. Are the random number facilities provided by numarray.random_array superior to those provided to those provided by the random module in the Python library? They certainly seem more extensive, and I like the interface better. If so, why not replace the random module by the equivalent functionality from numarray.random_array, and have everyone use the same random number generator? Or is this impossible for practical reasons? By the way, what is the name of the pseudo-random number generator being used? I see that the code is in Packages/RandomArray2/Src, but could not see where the name of the generator is mentioned. Faheem.

4 4

RE: [Numpy-discussion] Problems with installation of version 23.3
by Nadav Horesh 27 Sep '04

27 Sep '04

The problem is indicated in the following line: Packages/dotblas/dotblas/_dotblas.c:7:19: cblas.h: No such file or directory I have this file (cblas.h) as a part of ATLAS installation Nadav -----Original Message----- From: Nils Wagner [mailto:nwagner@mecha.uni-stuttgart.de] Sent: Mon 27-Sep-04 10:46 To: numpy-discussion(a)lists.sourceforge.net Cc: Subject: [Numpy-discussion] Problems with installation of version 23.3 Hi all. I tried to install Numeric-23.3, but it failed. Here is the output python2.3 setup.py install running install running build running build_py running build_ext building 'lapack_lite' extension gcc -pthread -shared build/temp.linux-i686-2.3/Src/lapack_litemodule.o -L/usr/local/lib/atlas -llapack -lcblas -lf77blas -latlas -lg2c -o build/lib.linux-i686-2.3/lapack_lite.so building 'FFT.fftpack' extension creating build/temp.linux-i686-2.3/Packages creating build/temp.linux-i686-2.3/Packages/FFT creating build/temp.linux-i686-2.3/Packages/FFT/Src gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/FFT/Src/fftpack.c -o build/temp.linux-i686-2.3/Packages/FFT/Src/fftpack.o gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/FFT/Src/fftpackmodule.c -o build/temp.linux-i686-2.3/Packages/FFT/Src/fftpackmodule.o gcc -pthread -shared build/temp.linux-i686-2.3/Packages/FFT/Src/fftpackmodule.o build/temp.linux-i686-2.3/Packages/FFT/Src/fftpack.o -o build/lib.linux-i686-2.3/FFT/fftpack.so building 'RNG.RNG' extension creating build/temp.linux-i686-2.3/Packages/RNG creating build/temp.linux-i686-2.3/Packages/RNG/Src gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/RNG/Src/pmath_rng.c -o build/temp.linux-i686-2.3/Packages/RNG/Src/pmath_rng.o gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/RNG/Src/ranf.c -o build/temp.linux-i686-2.3/Packages/RNG/Src/ranf.o gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/RNG/Src/RNGmodule.c -o build/temp.linux-i686-2.3/Packages/RNG/Src/RNGmodule.o gcc -pthread -shared build/temp.linux-i686-2.3/Packages/RNG/Src/RNGmodule.o build/temp.linux-i686-2.3/Packages/RNG/Src/ranf.o build/temp.linux-i686-2.3/Packages/RNG/Src/pmath_rng.o -o build/lib.linux-i686-2.3/RNG/RNG.so building '_dotblas' extension creating build/temp.linux-i686-2.3/Packages/dotblas creating build/temp.linux-i686-2.3/Packages/dotblas/dotblas gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/dotblas/dotblas/_dotblas.c -o build/temp.linux-i686-2.3/Packages/dotblas/dotblas/_dotblas.o Packages/dotblas/dotblas/_dotblas.c:7:19: cblas.h: No such file or directory Packages/dotblas/dotblas/_dotblas.c: In function `FLOAT_dot': Packages/dotblas/dotblas/_dotblas.c:18: warning: implicit declaration of function `cblas_sdot' Packages/dotblas/dotblas/_dotblas.c: In function `DOUBLE_dot': Packages/dotblas/dotblas/_dotblas.c:23: warning: implicit declaration of function `cblas_ddot' Packages/dotblas/dotblas/_dotblas.c: In function `CFLOAT_dot': Packages/dotblas/dotblas/_dotblas.c:28: warning: implicit declaration of function `cblas_cdotu_sub' Packages/dotblas/dotblas/_dotblas.c: In function `CDOUBLE_dot': Packages/dotblas/dotblas/_dotblas.c:34: warning: implicit declaration of function `cblas_zdotu_sub' Packages/dotblas/dotblas/_dotblas.c: In function `dotblas_matrixproduct': Packages/dotblas/dotblas/_dotblas.c:150: warning: implicit declaration of function `cblas_daxpy' Packages/dotblas/dotblas/_dotblas.c:154: warning: implicit declaration of function `cblas_saxpy' Packages/dotblas/dotblas/_dotblas.c:158: warning: implicit declaration of function `cblas_zaxpy' Packages/dotblas/dotblas/_dotblas.c:162: warning: implicit declaration of function `cblas_caxpy' Packages/dotblas/dotblas/_dotblas.c:190: warning: implicit declaration of function `cblas_dgemv' Packages/dotblas/dotblas/_dotblas.c:190: error: `CblasRowMajor' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:190: error: (Each undeclared identifier is reported only once Packages/dotblas/dotblas/_dotblas.c:190: error: for each function it appears in.) Packages/dotblas/dotblas/_dotblas.c:191: error: `CblasNoTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:196: warning: implicit declaration of function `cblas_sgemv' Packages/dotblas/dotblas/_dotblas.c:202: warning: implicit declaration of function `cblas_zgemv' Packages/dotblas/dotblas/_dotblas.c:208: warning: implicit declaration of function `cblas_cgemv' Packages/dotblas/dotblas/_dotblas.c:218: error: `CblasTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:244: warning: implicit declaration of function `cblas_dgemm' Packages/dotblas/dotblas/_dotblas.c:251: warning: implicit declaration of function `cblas_sgemm' Packages/dotblas/dotblas/_dotblas.c:258: warning: implicit declaration of function `cblas_zgemm' Packages/dotblas/dotblas/_dotblas.c:265: warning: implicit declaration of function `cblas_cgemm' Packages/dotblas/dotblas/_dotblas.c: In function `dotblas_innerproduct': Packages/dotblas/dotblas/_dotblas.c:463: error: `CblasRowMajor' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:464: error: `CblasNoTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:517: error: `CblasTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c: In function `dotblas_vdot': Packages/dotblas/dotblas/_dotblas.c:652: warning: implicit declaration of function `cblas_zdotc_sub' Packages/dotblas/dotblas/_dotblas.c:656: warning: implicit declaration of function `cblas_cdotc_sub' error: command 'gcc' failed with exit status 1 lisa:/var/tmp/Numeric-23.3 # Any suggestion would be appreicated. Nils locate cblas.h /usr/local/lib/atlas/cblas.h ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Numpy-discussion mailing list Numpy-discussion(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion

2 1

Problems with installation of version 23.3
by Nils Wagner 26 Sep '04

26 Sep '04

Hi all. I tried to install Numeric-23.3, but it failed. Here is the output python2.3 setup.py install running install running build running build_py running build_ext building 'lapack_lite' extension gcc -pthread -shared build/temp.linux-i686-2.3/Src/lapack_litemodule.o -L/usr/local/lib/atlas -llapack -lcblas -lf77blas -latlas -lg2c -o build/lib.linux-i686-2.3/lapack_lite.so building 'FFT.fftpack' extension creating build/temp.linux-i686-2.3/Packages creating build/temp.linux-i686-2.3/Packages/FFT creating build/temp.linux-i686-2.3/Packages/FFT/Src gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/FFT/Src/fftpack.c -o build/temp.linux-i686-2.3/Packages/FFT/Src/fftpack.o gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/FFT/Src/fftpackmodule.c -o build/temp.linux-i686-2.3/Packages/FFT/Src/fftpackmodule.o gcc -pthread -shared build/temp.linux-i686-2.3/Packages/FFT/Src/fftpackmodule.o build/temp.linux-i686-2.3/Packages/FFT/Src/fftpack.o -o build/lib.linux-i686-2.3/FFT/fftpack.so building 'RNG.RNG' extension creating build/temp.linux-i686-2.3/Packages/RNG creating build/temp.linux-i686-2.3/Packages/RNG/Src gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/RNG/Src/pmath_rng.c -o build/temp.linux-i686-2.3/Packages/RNG/Src/pmath_rng.o gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/RNG/Src/ranf.c -o build/temp.linux-i686-2.3/Packages/RNG/Src/ranf.o gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/RNG/Src/RNGmodule.c -o build/temp.linux-i686-2.3/Packages/RNG/Src/RNGmodule.o gcc -pthread -shared build/temp.linux-i686-2.3/Packages/RNG/Src/RNGmodule.o build/temp.linux-i686-2.3/Packages/RNG/Src/ranf.o build/temp.linux-i686-2.3/Packages/RNG/Src/pmath_rng.o -o build/lib.linux-i686-2.3/RNG/RNG.so building '_dotblas' extension creating build/temp.linux-i686-2.3/Packages/dotblas creating build/temp.linux-i686-2.3/Packages/dotblas/dotblas gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -fPIC -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.3 -c Packages/dotblas/dotblas/_dotblas.c -o build/temp.linux-i686-2.3/Packages/dotblas/dotblas/_dotblas.o Packages/dotblas/dotblas/_dotblas.c:7:19: cblas.h: No such file or directory Packages/dotblas/dotblas/_dotblas.c: In function `FLOAT_dot': Packages/dotblas/dotblas/_dotblas.c:18: warning: implicit declaration of function `cblas_sdot' Packages/dotblas/dotblas/_dotblas.c: In function `DOUBLE_dot': Packages/dotblas/dotblas/_dotblas.c:23: warning: implicit declaration of function `cblas_ddot' Packages/dotblas/dotblas/_dotblas.c: In function `CFLOAT_dot': Packages/dotblas/dotblas/_dotblas.c:28: warning: implicit declaration of function `cblas_cdotu_sub' Packages/dotblas/dotblas/_dotblas.c: In function `CDOUBLE_dot': Packages/dotblas/dotblas/_dotblas.c:34: warning: implicit declaration of function `cblas_zdotu_sub' Packages/dotblas/dotblas/_dotblas.c: In function `dotblas_matrixproduct': Packages/dotblas/dotblas/_dotblas.c:150: warning: implicit declaration of function `cblas_daxpy' Packages/dotblas/dotblas/_dotblas.c:154: warning: implicit declaration of function `cblas_saxpy' Packages/dotblas/dotblas/_dotblas.c:158: warning: implicit declaration of function `cblas_zaxpy' Packages/dotblas/dotblas/_dotblas.c:162: warning: implicit declaration of function `cblas_caxpy' Packages/dotblas/dotblas/_dotblas.c:190: warning: implicit declaration of function `cblas_dgemv' Packages/dotblas/dotblas/_dotblas.c:190: error: `CblasRowMajor' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:190: error: (Each undeclared identifier is reported only once Packages/dotblas/dotblas/_dotblas.c:190: error: for each function it appears in.) Packages/dotblas/dotblas/_dotblas.c:191: error: `CblasNoTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:196: warning: implicit declaration of function `cblas_sgemv' Packages/dotblas/dotblas/_dotblas.c:202: warning: implicit declaration of function `cblas_zgemv' Packages/dotblas/dotblas/_dotblas.c:208: warning: implicit declaration of function `cblas_cgemv' Packages/dotblas/dotblas/_dotblas.c:218: error: `CblasTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:244: warning: implicit declaration of function `cblas_dgemm' Packages/dotblas/dotblas/_dotblas.c:251: warning: implicit declaration of function `cblas_sgemm' Packages/dotblas/dotblas/_dotblas.c:258: warning: implicit declaration of function `cblas_zgemm' Packages/dotblas/dotblas/_dotblas.c:265: warning: implicit declaration of function `cblas_cgemm' Packages/dotblas/dotblas/_dotblas.c: In function `dotblas_innerproduct': Packages/dotblas/dotblas/_dotblas.c:463: error: `CblasRowMajor' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:464: error: `CblasNoTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c:517: error: `CblasTrans' undeclared (first use in this function) Packages/dotblas/dotblas/_dotblas.c: In function `dotblas_vdot': Packages/dotblas/dotblas/_dotblas.c:652: warning: implicit declaration of function `cblas_zdotc_sub' Packages/dotblas/dotblas/_dotblas.c:656: warning: implicit declaration of function `cblas_cdotc_sub' error: command 'gcc' failed with exit status 1 lisa:/var/tmp/Numeric-23.3 # Any suggestion would be appreicated. Nils locate cblas.h /usr/local/lib/atlas/cblas.h

1 0

ANN: F2PY - Fortran to Python Interface Generator
by Pearu Peterson 25 Sep '04

25 Sep '04

F2PY - Fortran to Python Interface Generator -------------------------------------------- I am pleased to announce the eight public release of F2PY, version 2.43.239_1806. The purpose of the F2PY project is to provide the connection between Python and Fortran programming languages. For more information, see http://cens.ioc.ee/projects/f2py2e/ Download: http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.tar.gz http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.win32.exe http://cens.ioc.ee/projects/f2py2e/2.x/scipy_distutils-latest.tar.gz http://cens.ioc.ee/projects/f2py2e/2.x/scipy_distutils-latest.win32.exe What's new? ------------ * Added support for ``ENTRY`` statement. * New attributes: ``intent(callback)`` to support non-external Python calls from Fortran; ``intent(inplace)`` to support in-situ changes, including typecode and contiguouness changes, of array arguments. * Added support for ``ALLOCATABLE`` string arrays. * New command line switches: --compiler and --include_paths. * Numerous bugs are fixed. Support for ``PARAMETER``s has been improved considerably. * Documentation updates. Pyfort and F2PY comparison. Projects using F2PY, users feedback, etc. * Support for Numarray 1.1 (thanks to Todd Miller). * Win32 installers for F2PY and the latest scipy_distutils are provided. Enjoy, Pearu Peterson --------------- <P><A HREF="http://cens.ioc.ee/projects/f2py2e/">F2PY 2.43.239_1806</A> - The Fortran to Python Interface Generator (25-Sep-04)

1 0

Assignment from a list is slow in Numarray
by Timo Korvola 22 Sep '04

22 Sep '04

Hello, I am new to the list, sorry if you've been through this before. I am trying to do some FEM computations using Petsc, to which I have written Python bindings using Swig. That involves passing arrays around, which I found delightfully simple with NA_{Input,Output,Io}Array. Numeric seems more difficult for output and bidirectional arrays. My code for reading a triangulation from a file went roughly like this: coord = zeros( (n_vertices, 2), Float) for v in n_vertices: coord[ v, :] = [float( s) for s in file.readline().split()] This was taking quite a bit of time with ~50000 vertices and ~100000 elements, for which three integers per element are read in a similar manner. I found it was faster to loop explicitly: coord = zeros( (n_vertices, 2), Float) for v in n_vertices: for j, c in enumerate( [float( s) for s in file.readline().split()]): coord[ v, j] = c Morally this uglier code with an explicit loop should not be faster but it is with Numarray. With Numeric assignment from a list has reasonable performance. How can it be improved for Numarray? -- Timo Korvola <URL:http://www.iki.fi/tkorvola>

3 5

Conference presentations
by Travis Oliphant 22 Sep '04

22 Sep '04

Hi all, The SciPy 2004 conference was a great success. I personally enjoyed seeing all attendees and finding out about the activity that has been occurring with Python and Science. As promised, all of the presentations that were submitted to abstracts(a)scipy.org are now available on-line under the conference-schedule page. The link is http://www.scipy.org/wikis/scipy04/ConferenceSchedule If anyone who hasn't submitted their presentation would like to, you still can. As I was only able to attend the first day, I cannot comment on the entire conference. However, what I saw was very encouraging. There continues to be a great amount of work being done in using Python for Scientific Computing and the remaining problems seems to be how to get the word out and increase the user base. Many thanks are due to the presenters and the conference sponsors: *The National Biomedical Computation Resource* <http://nbcr.sdsc.edu> (NBCR, UCSD, San Diego, CA) The mission of the National Biomedical Computation Resource at the University of California San Diego and partners at The Scripps Research Institute and Washington University is to conduct, catalyze, and advance biomedical research by harnessing, developing and deploying forefront computational, information, and grid technologies. NBCR is supported by _National Institutes of Health (NIH) _ through a _National Center for Research Resources_ centers grant (P 41 RR08605). *The Center for Advanced Computing Research* <http://www.cacr.caltech.edu/> (CACR, CalTech <http://www.scipy.org/wikis/scipy04/CalTech>, Pasadena, CA) CACR is dedicated to the pursuit of excellence in the field of high-performance computing, communication, and data engineering. Major activities include carrying out large-scale scientific and engineering applications on parallel supercomputers and coordinating collaborative research projects on high-speed network technologies, distributed computing and database methodologies, and related topics. Our goal is to help further the state of the art in scientific computing. *Enthought, Inc.* <http://www.enthought.com> (Austin, TX) Enthought, Inc. provides business and scientific computing solutions through software development, consulting and training. Best regards to all, -Travis Oliphant Brigham Young University 459 CB Provo, UT 84602 oliphant.travis(a)ieee.org

2 1

NumPy-Discussion September 2004