Mailman 3 April 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

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

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

rant against from numpy import * / from pylab import *
by Sebastian Haase 09 Aug '07

09 Aug '07

Hi! I use the wxPython PyShell. I like especially the feature that when typing a module and then the dot "." I get a popup list of all available functions (names) inside that module. Secondly, I think it really makes code clearer when one can see where a function comes from. I have a default import numpy as N executed before my shell even starts. In fact I have a bunch of my "standard" modules imported as <some single capital letter>. This - I think - is a good compromise to the commonly used "extra typing" and "unreadable" argument. a = sin(b) * arange(10,50, .1) * cos(d) vs. a = N.sin(b) * N.arange(10,50, .1) * N.cos(d) I would like to hear some comments by others. On a different note: I just started using pylab, so I did added an automatic "from matplotlib import pylab as P" -- but now P contains everything that I already have in N. It makes it really hard to *find* (as in *see* n the popup-list) the pylab-only functions. -- what can I do about this ? Thanks, Sebastian

2 3

matlab vs. python question
by Neal Becker 08 May '07

08 May '07

I'm interested in this comparison (not in starting yet another flame fest). I actually know nothing about matlab, but almost all my peers use it. One of the things I recall reading on this subject is that matlab doesn't support OO style programming. I happened to look on the matlab vendor's website, and found that it does have classes. OTOH, I've seen at least some matlab code, and never saw anyone use these features. I'm perfectly happy with python myself, but I wonder if anyone has good arguments for why to prefer python over matlab?

19 31

PyArray_FromDimsAndData weird seg fault
by Trevor M Cickovski 04 May '07

04 May '07

Hi, I'm using SWIG to wrap a function that calls the NumPy routine PyArray_FromDimsAndData. PyObject* toArray() { int dims = 5; double* myH; myH = (double*)malloc(dims*sizeof(double)); myH[0] = 0; myH[1] = 1; myH[2] = 2; myH[3] = 3; myH[4] = 4; return PyArray_FromDimsAndData(1,&dims,PyArray_FLOAT,(char*)myH); } However, for some reason when I call this from Python, the PyArray_FromDimsAndData() seg faults everytime. Does anybody see something wrong with my use of the function itself? Thanks! -Trevor -- ************************************************************* Trevor M. Cickovski Laboratory For Computational Life Sciences University of Notre Dame 325 Cushing Hall Notre Dame, IN 46556 T: (574) 631-3906 F: (574) 631-9260 "Settle never, strive always." *************************************************************

2 1

sort bug
by Anton Sherwood 02 May '07

02 May '07

This code -- adj = [ [eval(y) for y in x.split()] for x in infile ] val,vec = numpy.linalg.eig(adj) master = zip( val, vec.transpose() ) master.sort() *sometimes* gives this error: Traceback (most recent call last): File "3work.py", line 14, in <module> master.sort() ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() What does sort() care about truth values?! numpy.linalg.eig() sometimes returns complex values, which may not have a natural ordering, but I get this error (sometimes) even when it returns reals. -- Anton Sherwood, http://www.ogre.nu/ "How'd ya like to climb this high *without* no mountain?" --Porky Pine

10 17

simpliest way to check: array x is float, not integer
by dmitrey 01 May '07

01 May '07

hi all, please inform me what is the simplest way to check, does the vector x that came to my func is float or integer. I.e. someone can pass to my func for example x0 = numpy.array([1, 0, 0]) and it can yield wrong unexpected results vs numpy.array([1.0, 0, 0]) . Thx, D.

4 3

Documentation examples with doc
by Martin Blais 30 Apr '07

30 Apr '07

Hi Where is the script that generates the Numpy Examples with Doc on the scipy website? I cannot find it in the numpy svn. Maybe I would like to create a version that generates LaTeX for Python-style documentation. I find searching through this big web page a slightly painful experience. thanks,

2 1

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
by Steven Bethard 30 Apr '07

30 Apr '07

On 4/30/07, Bill Janssen <janssen(a)parc.com> wrote: > GvR wrote: > > So how about we reduce the scope of our (!) PEP (or perhaps of a new > > one) to two items: (a) add @abstractmethod, and (b) overload > > isinstance() and issubclass()? Library authors can do everything they > > want with those, and we can always add a specific set of ABCs for > > containers and/or numbers later in the 3.0 development cycle. > > -1. Adding mechanism without content seems less than ideal, despite > Talin's misgivings. I'd recommend adding the base classes in, and see > how they work in the earliest 3.0 releases, then modify them as > necessary in subsequent releases. +1 for Guido's simplified PEP. There are clearly use cases for @abstractmethod, __isinstance__() and __issubclass__(), so I see no reason why the simplified PEP shouldn't be acceptable on its own. Complaining about "adding mechanism without content" seems like saying, for example, that we shouldn't have introduced "functools.partial" without *using* it somewhere in the standard library. Whether the use cases are in the standard library or somewhere else should not determine whether a PEP is acceptable or not. I personally think the simplified PEP is a great compromise -- proponents of ABCs will now be able to introduce them (even for existing types like 'int' and 'list') and folks that don't want ABCs can simply never install the ABC module. Plus, it's much easier to *add* a module to the standard library than it is to *remove* one (even given Python 3.0's somewhat laxer first release plans). STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

1 0

NumPy-Discussion April 2007