Mailman 3 May 2008 - 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

Unpleasant behavior with poly1d and numpy scalar multiplication
by Fernando Perez 15 Feb '10

15 Feb '10

Hi all, consider this little script: from numpy import poly1d, float, float32 p=poly1d([1.,2.]) three=float(3) three32=float32(3) print 'three*p:',three*p print 'three32*p:',three32*p print 'p*three32:',p*three32 which produces when run: In [3]: run pol1d.py three*p: 3 x + 6 three32*p: [ 3. 6.] p*three32: 3 x + 6 The fact that multiplication between poly1d objects and numbers is: - non-commutative when the numbers are numpy scalars - different for the same number if it is a python float vs a numpy scalar is rather unpleasant, and I can see this causing hard to find bugs, depending on whether your code gets a parameter that came as a python float or a numpy one. This was found today by a colleague on numpy 1.0.4.dev3937. It feels like a bug to me, do others agree? Or is it consistent with a part of the zen of numpy I've missed thus far? Thanks, f

6 17

Compact way of performing array math with specified result type?
by Russell E. Owen 08 Feb '10

08 Feb '10

I often find myself doing simple math on sequences of numbers (which might or might not be numpy arrays) where I want the result (and thus the inputs) coerced to a particular data type. I'd like to be able to say: numpy.divide(seq1, seq2, dtype=float) but ufuncs don't allow on to specify a result type. So I do this instead: numpy.array(seq1, dtype=float) / numpy.array(seq2, dtype=float) Is there a more compact solution (without having to create the result array first and supply it as an argument)? -- Russell

4 3

Is anyone knowledgeable about dll deployment on windows ?
by David Cournapeau 01 Dec '09

01 Dec '09

Hi, My head hurt trying to understand dll management with windows. I wanted to find a sane way to use dll for numscons, but I can't see how to do this, so I was wondering if anyone on this ML had any deep knowledge on how to install dll, and reuse them with python extensions ? The problem is the following: - you have some dll (say MKL) in a path (say C:\program files\MKL). - how do you tell another dll (more exactly a python extension, a .pyd) to look for mkl dll into the MKL path ? It seems that there is no rpath-like capability on windows, and the only way to load dll is to put them into some windows directory, or to put the dll path into PATH. Is it really the only way ? cheers, David

8 25

Slicing/selection in multiple dimensions simultaneously
by Mike Ressler 17 Mar '09

17 Mar '09

The following seems to be a wart: is it expected? Set up a 10x10 array and some indexing arrays: a=arange(100) a.shape=(10,10) q=array([0,2,4,6,8]) r=array([0,5]) Suppose I want to extract only the "even" numbered rows from a - then print a[q,:] <works - output deleted> Every fifth column: print a[:,r] <works - output deleted> Only the even rows of every fifth column: print a[q,r] --------------------------------------------------------------------------- <type 'exceptions.ValueError'> Traceback (most recent call last) /.../.../.../<ipython console> in <module>() <type 'exceptions.ValueError'>: shape mismatch: objects cannot be broadcast to a single shape But, this works: print a[q,:][:,r] [[ 0 5] [20 25] [40 45] [60 65] [80 85]] So why does the a[q,r] form have problems? Thanks for your insights. Mike -- mike.ressler(a)alum.mit.edu

8 16

access ndarray in C++
by Thomas Hrabe 10 Dec '08

10 Dec '08

Hi all! I am currently developing a python module in C/C++ which is supposed to access nd arrays as defined by the following command in python a = numpy.array([1,1,1]) I want to access the array the following way and use the nd array data for further processing in C. mymod.doSthg(a) The example code on http://numpy.sourceforge.net/numdoc/HTML/numdoc.htm#pgfId-36721 (!PyArg_ParseTuple(args, "O!",&PyArray_Type, &array)) does not work for nd arrays. I always get TypeError: argument 1 must be array, not numpy.ndarray I assume the error is the constant provided as the third parameter, saying that the imput is of PyArray_Type and no nd array. So here are my questions: 1. is there any good tutorial / example code for acessing nd arrays in C? 2. what is the difference between both (arrays and nd arrays? - I am new to python and heard there were different approaches to arrays and that nd arrays work better for multi dimensional applications. Is this right?) 3. which one of both will be used in the future? Thank you in advance for your help, Thomas

15 31

arccosh for complex numbers, goofy choice of branch
by Charles R Harris 20 Jul '08

20 Jul '08

OK, Which branch do we want to use. As it currently is in numpy and scipy.special arccosh(1.5) = 0.96242365011920694 arccosh(1.5+0j) = -0.96242365011920705 + 0.0j This is consistent with gsl, but inconsistent with Mathematica, NAG, Maple, and probably all sensible implementations which use the generally accepted principal value. I've left this inconsistency raising an error in the ufunc tests until we make a decision. It might be nice to know what FORTRAN and MatLab do with this. Chuck

7 16

Infinity definitions
by Bruce Southey 16 Jul '08

16 Jul '08

Hi, Since we are discussing namespace and standardization, I am curious in why there are multiple definitions for defining infinity in numpy when perhaps there should be two (one for positive infinity and one for negative infinity). I really do understand that other people have use of these definitions and that it is easier to leave them in than take them out. Also, it is minor reduction in namespace because I do know that much of the namespace is either defining variables (like different floats and complex numbers) or mathematical functions (like logs and trig functions). Currently we have: numpy.Inf numpy.Infinity numpy.inf numpy.infty numpy.NINF numpy.PINF Most of these are defined in numeric.py: 'Inf = inf = infty = Infinity = PINF' In the f2py/tests subdirectories, the files return_real.py and return_complex.py uses both 'inf','Infinity'. The only occurrence of NINF and PINF are in core/src/umathmodule.c but I don't see any other usage. There does not seem to be any use of 'infty'. A similar case could be made for 'Not a Number' (nan = NaN = NAN). Regards Bruce

7 9

Cookbook/Documentation
by Pierre GM 10 Jun '08

10 Jun '08

All, * I've just noticed that the page describing RecordArrays (http://www.scipy.org/RecordArrays) is not listed under the Cookbook: should this be changed ? Shouldn't there be at least a link in the documentation page ? * Same problem with Subclasses (http://www.scipy.org/Subclasses) * I was eventually considering writing down some basic docs for MaskedArrays: should I create a page under the Cookbook ? Elsewhere ? * Congrats for the DocMarathon initiative ! The 3 points I've just raised would fit nicely with objective #3 (reference sections): what's the plan for that ? Any specific directions to follow ?

3 4

Installation info
by Peter Creasey 09 Jun '08

09 Jun '08

Is numpy v1.1 going to come out in egg format? I ask because I only see the superpack installers on the sourceforge page, and we have users who we are delivering to via egg - requires. thanks, Peter 2008/5/23 <numpy-discussion-request(a)scipy.org>: > Send Numpy-discussion mailing list submissions to > numpy-discussion(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://projects.scipy.org/mailman/listinfo/numpy-discussion > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)scipy.org > > You can reach the person managing the list at > numpy-discussion-owner(a)scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Numpy-discussion digest..." > > > Today's Topics: > > 1. Re: f2py errors: any help interpreting? (Mark Miller) > 2. Re: f2py errors: any help interpreting? (Robert Kern) > 3. Re: f2py errors: any help interpreting? (Mark Miller) > 4. Re: f2py errors: any help interpreting? (Robert Kern) > 5. Re: f2py errors: any help interpreting? (Mark Miller) > 6. Re: f2py errors: any help interpreting? (Mark Miller) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 23 May 2008 14:48:47 -0700 > From: "Mark Miller" <markperrymiller(a)gmail.com> > Subject: Re: [Numpy-discussion] f2py errors: any help interpreting? > To: "Discussion of Numerical Python" <numpy-discussion(a)scipy.org> > Message-ID: > <d1eaff10805231448i69fe8589v18062ef0f737f85(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Super...I'll give it a try. Or should I just wait for the numpy 1.1 > release? > > thanks, > > -Mark > > On Fri, May 23, 2008 at 2:45 PM, Robert Kern <robert.kern(a)gmail.com> wrote: > >> On Fri, May 23, 2008 at 4:00 PM, Mark Miller <mark.miller(a)usu.edu> wrote: >> >> > File "C:\Python25\lib\site-packages\numpy\f2py\rules.py", line 1222, in >> > buildmodule >> > for l in '\n\n'.join(funcwrappers2)+'\n'.split('\n'): >> > TypeError: cannot concatenate 'str' and 'list' objects >> > >> > >> > Any thoughts? Please let me know if more information is needed to >> > troubleshoot. >> >> This is a bug that was fixed in SVN r4335. >> >> http://projects.scipy.org/scipy/numpy/changeset/4335 >> >> -- >> Robert Kern >> >> "I have come to believe that the whole world is an enigma, a harmless >> enigma that is made terrible by our own mad attempt to interpret it as >> though it had an underlying truth." >> -- Umberto Eco >> _______________________________________________ >> Numpy-discussion mailing list >> Numpy-discussion(a)scipy.org >> http://projects.scipy.org/mailman/listinfo/numpy-discussion >> >

7 19

NumPy-Discussion May 2008