[Numpy-discussion] Numeric vs numarray?

[Peter Verveer]

> If Numeric3 intends to support byteswapped and misaligned data then
> additional functionality is clearly required;  whether or not the
> functionality is explicitly exposed in the API is another matter;  it 
> is
> hidden in our compatibility API so there's no reason Numeric3 can't 
> hide
> it too.  But it sounds to me like people have found the numarray high
> level API fairly useful so the design features bear discussion even if
> the API itself is dropped.

Exactly, I found the NA_*Array functions better than the original 
Numeric functions. It seems Travis is moving in a similar direction, 
but you are right that it is going to need extra functionality.

A question I have about the compatibility API in Numarray: In cases 
where a temporary is created, does that get copied back when the 
temporary is destroyed? That seems to be needed when you use an array 
as an output. That would be wasteful if you only use the array as an 
input. Its of course fine to do that, since it is a compability API 
that you cannot change, but it would point to a weakness in the 
original Numeric API, which should be fixed by the Numeric people if 
they want to  move forward.

It is relevant to me since I decided to move the nd_image to the 
Numeric compatibility API, and while doing that found myself wondering 
that in some cases I would be introducing a slight performance penalty.

> I used NA_IoArray myself in numarray's Numeric compatibility API and
> also found it useful in adding f2py support.  I found it necessary to
> get Numeric's extra packages (LinearAlgebra, FFT, RandomArray) to pass
> their self-tests.   Don't overlook the fact that arrays are typically
> passed by reference so whether we like it or not I/O behavior is
> normally exposed.  For me,  even for a job as small as the 
> compatibility
> layer or f2py support,  NA_IoArray was an asset.  It's just easier to
> think about and use and eliminates the chance of getting the shadowing
> logic wrong.

Yes, I can only agree with that.

> The NumArray destructor-based array shadowing works well to keep things
> transparent and porting changes low.  You obviously can do the explict
> exit copy you've discussed,  but I think that's the kind of unnecessary
> and intrusive change we're trying to get away from.  With the best code
> coming from experts doing their own thing on their own time,  I don't
> think support for numarray's advanced features is going to happen 
> unless
> it's as automatic and simple to use as possible.

I can confirm that the high-level API of Numarray works very nicely to 
hide you from things you do not want to know (i.e. byte-swapping) while 
at the same time allowing flexibility that does not seem to be 
completely present in the Numeric API, unless I don't understand the 
latter well enough.

Peter