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