[Numpy-discussion] Numeric vs numarray?

[Travis Oliphant]

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

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

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

-Travis