[Numpy-discussion] Counting array elements

[Todd Miller]

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
now.  

> > 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
1D array.

> 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().

Regards,
Todd