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 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. I never fully understood why there were two ways of "flattening" in the first place. Gary -------------------------------------------------------------- Gary Strangman, PhD | Director, Neural Systems Group Office: 617-724-0662 | Massachusetts General Hospital Fax: 617-726-4078 | 149 13th Street, Ste 10018 | Charlestown, MA 02129