# [Numpy-discussion] Counting array elements

Peter Verveer 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.

Peter

```