Mailman 3 February 2007 - NumPy-Discussion

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

17 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

Re: [Numpy-discussion] Floating point exception with numpy and embedded python interpreter
by Andrew Straw 20 Sep '07

20 Sep '07

Arkaitz Bitorika wrote: > > On 19 Apr 2006, at 18:37, Andrew Straw wrote: > >> >>> I've been embedding Python for ages on the same program and other >>> modules work fine, only numpy fails. >> >> >> Most other modules don't use the SSE units, so wouldn't get hit by such >> a bug. > > > Is there a way of not using those units from numpy, to check if > that's what's going on? I think that numpy only accesses the SSE units through ATLAS or other external library. So, build numpy without ATLAS. But I'm not 100% sure anymore if there aren't any optimizations that directly use SSE if it's available. > Or alternatively, how would I check if my program is messing with the > SSE bits? Hmm, I think that's a bit hairy. I'd suggest simply asking the C++ library's mailing list if they alter the error bits on the control registers of the SSE unit. (Out of curiousity, what library is it?) If you want hairy, though, I think you'd have to check from C with the appropriate calls -- I'd start with the source code in that bug report. It looks like they're inlining an assembly statement to query a SSE control register.

5 7

numpy.linalg.qr bug on 64-bit platforms
by Fernando Perez 08 Mar '07

08 Mar '07

Hi all, I recently got a report of a bug triggered only on 64-bit hardware, and on a machine (in case it's relevant) that runs python 2.5. This is with current numpy SVN which I just rebuilt a moment ago to triple-check: In [3]: a = numpy.array([[1.0,2],[3,4]]) In [4]: numpy.linalg.qr(a) ** On entry to DGEQRF parameter number 2 had an illegal value sage[~]> # dumped back at system prompt In case anyone has ideas, I added some more initial detail and guesses as to where the problem may be coming from here: http://projects.scipy.org/scipy/numpy/ticket/446 Unfortunately I don't know this part of the code well enough to come up with a quick fix myself. Cheers, f

6 6

Buffer PEP in NumPy SVN
by Travis Oliphant 05 Mar '07

05 Mar '07

I just wanted to point people to the online version of the PEP. I'm still looking for comments and suggestions. The current version is here: http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.txt -Travis

3 6

numpy.dot and ACML
by Yves Frederix 05 Mar '07

05 Mar '07

Hi all, I have managed to compile numpy using pathscale and ACML on a 64 bit AMD system. Now I wanted to verify that numpy.dot indeed uses the ACML libs. The example for dot() (http://www.scipy.org/Numpy_Example_List?highlight=%28example%29#head-c7a573…) suggest a way of doing this: 1 u0050015@lo-03-02 .../core $ python -c "import numpy; print id(numpy.dot)==id(numpy.core.multiarray.dot);" True This indicates that I am not using the acml libraries. When running a benchmark (see attach) and comparing to a non-ACML installation though, the strange thing is that there is a clear speed difference, suggesting again that the acml libraries are indeed used. Because this is not all that clear to me, I was wondering whether there exists an alternative way of verifying what libraries are used. Many thanks, YVES

2 2

Re: [Numpy-discussion] [Matplotlib-users] [matplotlib-devel] Unifying numpy, scipy, and matplotlib docstring formats
by Barry Wark 03 Mar '07

03 Mar '07

Perhaps we should consider two use cases: interactive use ala Matlab and larger code bases. In the first case, being able to import * saves a lot of typing and the namespace polution problem isn't a big deal. The second use, obviously, benefits from avoiding import *. Returning to the OP's questions, why couldn't both cases be helped by creating a "meta-package" for numpy, scipy, and matplotlib? For the sake of argument, lets call the package "plab". Existing code could be affected by changing the individual packages, but a package that essentially does from pylab import * from numpy import * from scipy import * would give a standard API that future code and interactive use could use. Code could do import plab plab.plot() #etc. and interactive use could do from plab import *. Just a thought... Barry On 2/16/07, Matthew Brett <matthew.brett(a)gmail.com> wrote: > Hi, > > > I think a consensus is building in the python community that you should > > NEVER use import *! > > Well, I have only been coding python for a few years, but I would say, > along with writing unit tests, the great importance of not using > import * is one of the secrets that you learn slowly and painfully > with experience. Chris' point about the movement of big projects away > from that idiom is a very good one. It is convenient, but over time > you realize that the value of convenience is far outweighed by the > namespace mess and loss of clarity that results. > > Best, > > Matthew > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >

11 11

NumPy in Teaching
by Steven H. Rogers 03 Mar '07

03 Mar '07

I'm doing an informal survey on the use of Array Programming Languages for teaching. If you're using NumPy in this manner I'd like to hear from you. What subject was/is taught, academic level, results, lessons learned, etc. Regards, Steve

4 5

mac binary distributions
by Steven Bird 02 Mar '07

02 Mar '07

Hi -- the last dmg distribution was for numpy version 0.9.6. Is there any chance of having dmg distributions posted for the current version please?

2 1

PyCon 2007
by Travis Oliphant 01 Mar '07

01 Mar '07

I took the opportunity to go to PyCon this year and met several people there. I had a really good time although I would have liked to stay longer. If you want to see the slides for my talk they are here: http://us.pycon.org/common/talkdata/PyCon2007/045/PythonTalk.pdf It was a good opportunity to integrate better with the Python developers and keep our voices heard. I think in the long term this is going to be important. We are working actively to get something like the array interface into a re-vamped buffer interface for Python 3.0. There are some issues that arise in this process that need addressing so if you have any understanding of the array interface (or want to) please dive in and contribute. Hopefully in this process we will get tighter integration with the struct module, the array module, and ctypes as well. Most of the changes are written for back-port to Python 2.6 as well. Besides how to integrate the buffer interface with discontiguous arrays, the only other issue is how to manage the memory needed to return the shape information and the format information through the buffer interface. I think using Python CObject's (like we do for __array_struct__) is a good idea and allows flexible and simple memory management as well as fast access to direct C-like information about the array. Other solutions, however, may be better. If you have any ideas, it would be good to hear them. I would also like to get feedback on the proposed additions to the string-syntax that the struct module uses for describing data formats. In particular, I'm interested in ideas about what kind of C-API functions for processing such strings might be useful. These are some ideas that I have: 1) A function that produces a ctypes type from a string-struct description. 2) A function that produces a string-struct description from a ctypes type. 3) A function that extracts the string corresponding to a named sub-element. -Travis

4 3

Source install
by Mark Janikas 01 Mar '07

01 Mar '07

Hello all, I have used numpy on both Mac and Windows. The latter is easily installed with the exe file. The former required the gcc program from XCode... but once installed, "python setup.py install" worked. I cant seem to get numpy to work on my linux machine. Can someone point me to a platform-independent doc on how to install from the source tar file? Thanks ahead of time, MJ Mark Janikas Product Engineer ESRI, Geoprocessing 380 New York St. Redlands, CA 92373 909-793-2853 (2563) mjanikas(a)esri.com

2 4

NumPy-Discussion February 2007