[Numpy-discussion] Counting array elements

[Tim Hochberg]

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:
    add.reduce(a, axis=[...])
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