[Numpy-discussion] Numeric vs numarray?
verveer at embl-heidelberg.de
Thu Feb 10 02:56:53 CST 2005
It is however useful to distinguish between input and output arrays.
If your array is just an input, then the PyArray_FromAny function you
mention below is good enough. If necessary they will make a
well-behaved copy which can be discarded afterwards.
However, if you need to modify an array 'in-place', then your
well-behaved copy needs to be copied back at the end of your function.
That can be done transparently as numarray does that it. You mention
that you could explicitly copy back, but that means that I have to
determine myself if there was a temporary made. And that could also
happen if the array was byteswapped or misaligned not just if I asked
for a contiguous array. The Numarray functions do all that for you.
The point is, that if you use an array just as an input, you don't want
to copy things back, since that is a waste of resources. So you need
somehow to distinguish between input and output arrays, which numarray
does by having separate functions.
For me, the NA_OutputArray function has been very useful, I would like
to see that functionality somehow in Numeric3. The NA_IoArray function
I don't really need.
Maybe I have understood the Numeric API wrong and you can do this right
now, I have not used it very much lately.
I know you avoid these problems if you don't modify arrays at all, but
just return new arrays with your result. However, then you cannot
properly implement output arguments. Many numarray and Numeric
functions do _not_ allow you to pass an output array, to modify
"in-place" as you can do with ufuncs. That annoys me endlessly, it is a
big source of inefficiency if you have big arrays. A good example are
the FFT functions that make lots of temporaries if you do a
multi-dimensional transform. I am digressing now, but maybe output
arrays could be supported more consistently in Numeric3?
On 10 Feb 2005, at 10:25, Travis Oliphant wrote:
> Timo Korvola wrote:
>> Andrew McNamara <andrewm at object-craft.com.au> writes:
>>> I know this is a loaded question, but what does numarray offer that
>>> Numeric does not (as they stand today)? A cleaner implementation?
>> NA_OutputArray and NA_IoArray. Very convenient for wrapping C
>> libraries. NA_InputArray is more or less equivalent to
>> PyArray_ContiguousFromObject but as far as I know Numeric has nothing
>> equivalent to the other two.
> I am not convinced these are really useful additional C-API calls.
> I've done a fair bit of wrapping of C libraries and have never needed
> anything but
> PyArray_ContiguousFromObject and
> PyArray_FromOb ject
> This idea of "shadowing" ala NA_IOArray is a new one. Can somebody
> show me an example of it's usefulness that could not be handled by
> simply a PyArray_ContiguousFromObject with an explicit copy back at
> the end? I don't like this idea of "hiding" what is going on from the
> This kind of C-API alteration which as far as I can tell has not been
> well justified is an example of some of the problems I see with
> Numeric3 condenses the Numeric API calls using numarray's idea of the
> requires flag:
> PyArray_FromAny(PyObject *op, PyArray_Typecode *typecode, int
> mindepth, int maxdepth, int requires)
> typecode is a simple structure with integer elements (type_num,
> itemsize, and fortran).
> For some unexplained reason, the mindepth and maxdepth arguments are
> not copied by the new Numarray C-API. I'm not sure why. Having them
> does make it easier to guarantee you are getting the right dimension
> for the array you want rather than having to check after the fact.
> These kinds of discussions about numarray's C-API never took place.
> In my opinion the Numeric C-API is better tested and easier to
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> Discover which products truly live up to the hype. Start reading now.
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion