# [Numpy-discussion] Counting array elements

Tim Hochberg tim.hochberg at cox.net
Sat Oct 30 11:49:36 CDT 2004

```Todd Miller wrote:

[SNIP]

>** Tim Hochberg pointed out that we can overload the reduction (and not
>accumulation?)
>
It seems possible. It's probably marginally useful at best. However, it
might be worth doing if not too painful, just so that the accumulate and
reduce signatures match.

>axis parameter with an "all" or a tuple describing a
>sequence of axes to reduce along.  My perception was that there was a
>consensus behind this and in any case I'm in agreement with Tim.  Alan
>Isaac pointed out that None might be better here than "all" and I
>agree.
>
Using None to mean ALL seems a little perverse to me, but I'll grant
that using an existing singleton makes things simpler. I'll just point
out that it would also be possible to define an ALL singleton and use that.

Very tangential: it's too bad that '...' can't be typed more places: the
natural spelling for ALL is [...] as in:
Sadly, that won't work.

>At this point,  I think sumAll() is dead, the sum() method will
>be deprecated, and the reductions should be expanded as Tim suggested.
>
>** Peter Verveer made some comments about the expectations of a naive
>user regarding reductions, namely that "all" should be the default.   My
>own experience bears this out,  and I am torn about what to do here.
>
>
I suspect that one's experience here depends on your typical problem
domain. If one does a lot 2D work ALL would seem to be the natural
choice. If you use a lot of arrays of vectors, as I do, -1 is the
natural choice. At this point I can't recall a case where ALL would have
been the natural choice for me.

In addition to backwards compatibility, one argument for not using ALL
as the default is that it makes little sense or no sense for accumulate.
Having the default for reduce be ALL, but that for accumulate be -1 (for
instance) would be confusing.

>Chris Barker pointed out the need for backward compatibility with
>Numeric,
>
I'd think that the importance of backward compatibility with not just
Numeric, but with Numarray itself has been underrated. Changing the
default for reduce / sum is a particularly insiduous since many uses
will fail silently, producing the wrong answer, but continuing to run.
This means that all instances of sum, product and reduce will need to be
inspected and corrected. Having 10k LOC that use Numarray, I'll be a bit
irked if this gets changed without a better justification than what I've
seen thus far.

>and given the current numarray goal of supporting SciPy,  this
>need is growing stronger and more complex.  SciPy uses yet another axis
>convention.  If anyone has any ideas how to handle these multiple
>conventions with elegance,  let me know.
>
>
Could you describe the SciPy axis convention: I'm not familiar with it.

[SNIP]

-tim

```