[Numpy-discussion] rank-0 arrays
tim.hochberg at ieee.org
Sun Sep 15 14:30:04 CDT 2002
----- Original Message -----
From: "eric jones" <eric at enthought.com>
> > And it should fail, because a rank-0 array is not a sequence, so it
> > doesn't have a length.
> I disagree. You should not have to write special code to check for a
> specific case. It breaks one of the beauties of Numeric -- i.e. you can
> write generic code that handles arrays of any size and type. Any method
> that works on a 1 or more d array should also work on 0d arrays. If you
> ask for its shape, it returns a tuple.
No problem up to here.
> If you ask for its size it
> returns its length along its "first" axis.
Here's where we part ways. As Konrad already pointed out, it return
anArray.shape except in the case of zero-D arrays where the arbitrary
decision was made that:
> This will always be 1.
Why 1 and not 0 or -1 or 42. If you really had to return something, the
thing to return would be None.
> It allows for generic code.
I don't see how. Even poking around in MA didn't convince me that this would
help although I didn't spend enough time with it to get a great feel for it.
The one function I did come close to working all the way through looked like
it would be about _half_ as long if it didn't have to support the zero-rank
> On this note:
> I do not see the benefit of making a scalar type object that is separate
> for 0d arrays. It seems to remove instead of enhance capabilities.
> What does a scalar object buy that simply using 0d arrays for that
> purpose does not?
Unless somethings changed, you can't index into lists and what not with a
rank-0 array, so returning ints or some subclass from integer arrays would
be convenient. It would be easy to always return subclasses of int, float or
complex (or object for those few who use object arrays) so that the results
would always play nice with the rest of Python.
However, given that the coercion rules have changed in numarray, I don't
really see the point of returning anything other than int, float of complex.
However, I have no objection to allowing the creation rank-0 arrays as long
as they behave consistently with other array objects.
> > - a.astype(N.Float) should also work for scalars
> > Similarly, it would be nice if complex operations (real/imaginary
> > part) would work on integers and floats.
If these are needed, and I agree they would be nice, it seems that in order
to integrate well with the rest of Python we should supply:
numarray.astype(a, type) -> array or scalar of type type.
numarray.imaginary(a) -> imaginary part of a
numarray.imaginary(a) -> real part of a
I actually had these latter two in JNumeric back when I was working on that,
so I kinda thought they were Numeric, but I musta just added them in because
I liked them.
[Eric and Konrad agree that the inconsistency between Python and Numeric's
mod should be cleaned up]
More information about the Numpy-discussion