[Numpy-discussion] Numeric vs numarray?
verveer at embl-heidelberg.de
Thu Feb 10 08:37:03 EST 2005
> 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
> hidden in our compatibility API so there's no reason Numeric3 can't
> 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
> 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
> 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.
More information about the NumPy-Discussion