[Numpy-discussion] Counting array elements
verveer at embl-heidelberg.de
Mon Oct 25 10:09:05 CDT 2004
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.
More information about the Numpy-discussion