On 25 Oct 2004, at 18:51, Gary Strangman wrote:
I'm not sure how feasible it is, but I'd much rather an efficient, non-copying, 1-D view of an noncontiguous array (from an enhanced version of flat or ravel or whatever) than a bunch of extra methods. The former allows all of the standard methods to just work efficiently using sum(ravel(A)) or sum(A.flat) [ and max and min, etc]. Making special whole array methods for everything just leads to method eplosion.
I completely agree with this ... an efficient flat/ravel would seem to solve many of the issues being raised. Forgive the potentially naive question here, but is there any reason such an efficient, enhanced view can't be implemented for the .flat method?
I believe it is not possible without copying data. The strides between elements of a noncontiguous array are not always the same, so you cannot efficiently view it as a 1D array.
I like the concept of .flat, but I regularly call functions with arguments that may-or-may-not be contiguous. For robustness, such functions _must_ be coded with ravel() because .flat fails for non-contiguous arrays.
Functions should be coded in the first place to take multi-dimensional nature into account in my opinion. One of the points of numarray is that it is multi-dimensional. If a function can work over multiple dimensions, but it only works for 1D arrays, it is broken in my opinion. In my opinion sum() _is_ broken, and introducing a separate sum_all() is an ugly hack.
I never fully understood why there were two ways of "flattening" in the first place.
I suppose it is for efficiency reasons, flat may not always works, but if it does, it is efficient since it would not need to copy any data. Peter