[Numpy-discussion] Numeric vs numarray?

Todd Miller jmiller at stsci.edu
Thu Feb 10 08:11:41 EST 2005

On Thu, 2005-02-10 at 08:41, Peter Verveer wrote:
> On 10 Feb 2005, at 14:24, Timo Korvola wrote:
> > Peter Verveer <verveer at embl-heidelberg.de> writes:
> >> The NA_IoArray function I don't really need.
> >
> > Depends on what C code you are working with.  Bidirectional array
> > arguments are not uncommon in libraries.
> I agree, this is just a personal preference of me to rather keep the 
> input and output arrays separate arguments, which gives you the same 
> functionality plus a bit more flexibility. I would not argue to remove 
> NA_IoArray though, if you prefer that.

I won't try to explain how the numarray C-API got the way it is because
it's irrelevant.  I agree that the native API is too large and started
encouraging use of the Numeric compatibility API over the summer.  On
the other hand,  I think the numarray problem domain is wider and more
difficult than the one addressed by Numeric.  

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.

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.

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.


More information about the NumPy-Discussion mailing list