[Numpy-discussion] Counting array elements
tim.hochberg at cox.net
Mon Oct 25 09:32:01 CDT 2004
Stephen Walton wrote:
>On Mon, 2004-10-25 at 10:26 +0200, Peter Verveer wrote:
>>On 25 Oct 2004, at 04:17, Stephen Walton wrote:
>>>I don't think we need sumall. The methods and the functions should
>>>simply work the same way. If one wants sumall, use A.flat.sum() or, if
>>>you can't use the methods or attributes on your old version of Python,
>>I think this may be inefficient, because ravel and flat may make a copy
>>of the data. Also I think using flat/ravel in such a way is plain ugly
>>and a complex way to do it.
>You may be right about the copying, I couldn't say. I don't think
>sum(ravel(A)) looks any worse than sum(sum(sum(A))) for a rank 3 array,
>but ugly is in the eye of the beholder.
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.
>>In my opinion functions that calculate a statistic like sum
>>should return the total in the first place, rather then over a single
>It depends on the data. I use rank-2 arrays which are images and are
>therefore homogeneous. Even there, though, I often want the sum of all
>rows or all columns. For heterogeneous data (e.g., columns of different
>Y's as a function of X), the present sum() makes sense. In other words,
>we will always need ways to sum over just one dimension and over all
>dimensions. By analogy with MATLAB (I'm guessing), sum() in Numeric and
>numarray does a one-D sum.
More information about the Numpy-discussion