[Numpy-discussion] performing operations in-place in numpy

Robert Kern robert.kern at gmail.com
Wed Jul 8 19:34:57 EDT 2009


On Wed, Jul 8, 2009 at 18:28, Pauli Virtanen<pav+sp at iki.fi> wrote:
> On 2009-07-08, Charles R Harris <charlesr.harris at gmail.com> wrote:
>> In that case I don't see a problem offhand. That said, I haven't looked at
>> the code yet.
>
> I'm a bit worried about the problem that cropped up in the ticket
> with the complex ufuncs. As Luca noted in the ticket,
>
>    obj3 = PyArray_Conjugate((PyAO *)obj1, NULL);
>
> needed to be replaced with
>
>    Py_INCREF(obj1);
>    obj3 = PyArray_Conjugate((PyAO *)obj1, NULL);
>    Py_DECREF(obj1);
>
> to avoid overwriting obj1 when refcount of `obj1 == 1`.
>
> Now, having refcounts of 1 can be a common condition in arrays in
> C code, and PyArray_Conjugate is a public function in Numpy's
> C-API. So, as it stands now, this patch seems to potentially
> break existing C-extension modules that use the Numpy/Numeric
> API. This would need to be fixed.
>
>
> Perhaps the INCREF/DECREF pair can be moved inside
> PyArray_Conjugate.

It's entirely possible that this should be done regardless.

> If I understand correctly similar issues can
> only crop up in functions calling the *GenericUnary* etc. ufunc
> functions directly. Are these functions part of the public API?
> If not, there's a chance of fixing their callers inside Numpy.

The public API is exactly the set of function pointers in PyArray_API
and PyUFunc_API.

-- 
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



More information about the NumPy-Discussion mailing list