[Numpy-discussion] Counting array elements
jmiller at stsci.edu
Tue Nov 2 14:34:57 CST 2004
On Mon, 2004-11-01 at 18:28, Chris Barker wrote:
> Perry Greenfield wrote:
> > This aspect of flat can be considered a wart. There are three different
> > desired behaviors depending on who you talk to. For efficiency reasons,
> > some only want flat (and even ravel) to work if the array is already
> > contiguous; that is, they don't want copies unless they ask for them.
> This isn't just efficiency: having a function (or method) that sometimes
> returns a copy, and sometimes a reference is asking for bugs. What
> happens if I make a change to the result in a function? Sometimes it
> will change the parent array, sometimes not.
I looked at this some more and discovered we're doing what Numeric does
with the .flat attribute: raise an exception for non-contiguous arrays.
So backward compatibility is one motive for keeping .flat the way it is
> > otherwise for it to return a view. Yet others always want a copy.
> > So, are three different versions needed? Or options to a function?
> > The drawback of .flat (as an attribute) is there is only one choice
> > for behavior.
> A agree. I vote for a method.
> By the way, is it really impossible to have a discontiguous 1-d array?
No. RecArray is based on this: elements in a column are typically
spaced by more than the size of one element yet can appear as a single
> I'm not wizard at C or C++ but I've worked with the Numeric api enough
> to see what the problem is. However, it seems that there should be way
> to have a "get the n-th element" function or method to the Numarray
> object that should then work on polymorphic types, one of which would be
> a rank-1 non-contiguous array.
I think the real issue is that non-contiguous arrays cannot be reshaped
to become rank-1 arrays just by munging the strides. Thus, it's
hard/impossible to write a .flat which works without making a copy of
the array when the original was non-contiguous.
> Perhaps there is way too much existing
> code that relies on the array->strides[n] approach to introduce this
> now, but I think this kind of thing would be the key to making it easier
> to write optimized Numarray functions.
Well, there is support now for adding universal functions to numarray.
You supply a C function or macro of 1 or 2 inputs and 1 output, and
numarray's ufunc machinery applies the function element-wise. The
machinery takes care of array shape and non-contiguousness as well as
other things such as misalignment, byte swapping, and type coercion.
This is demoed in Examples/ufunc. In addition, numarray-1.2 will
support functions of M inputs and N outputs.
So, with what we have now, you'd be able to write your own cos() ufunc
and it would be as efficient as numarray's cos().
More information about the Numpy-discussion