[Numpy-discussion] Counting array elements

[Perry Greenfield]

Todd Miller wrote:
> 
> There was understandable confusion about why .flat is sometimes allowed
> to fail.  Since it is an attribute,  we thought it inappropriate to make
> it return a copy of the source array and chose instead to raise an
> exception.  In contrast, it is reasonable for the ravel() function to
> return a completely different array, so it always works.  (I just
> noticed that ravel() is not named flat()).  Some of our more
> contemporary thinkers suggested using iterators to produce a .flat which
> always works.  If anyone has an idea how to make this work with good
> performance,  please let me know;  I don't.
> 
This aspect of flat can be considered a wart. There are three different
desired behaviors depending on who you talk to. For efficiency reasons,
some only want flat (and even ravel) to work if the array is already
contiguous; that is, they don't want copies unless they ask for them.
Others want it to always work, producing a copy if necessary but
otherwise for it to return a view. Yet others always want a copy.
So, are three different versions needed? Or options to a function?
The drawback of .flat (as an attribute) is there is only one choice
for behavior. For a function (or a method) we could modify the
behavior with a keyword argument. Personally, I would rather .flat
always work, even if it means returning a copy. Is there any 
consensus on how this problem should be handled?

> ** 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. 
> Chris Barker pointed out the need for backward compatibility with
> Numeric,  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.
> 
I find this issue particularly vexing as well. Let's be clear about 
this, scipy changes the behavior of Numeric to produce a new flavor.
What should numarray do? Follow the scipy behavior or the Numeric
behavior? Or should there be a scipy/numarray flavor vs the more
Numeric compatible numarray? Note, we never intended numarray to be
100% compatible with Numeric since there were aspects we thought
should be changed (e.g., scalar/array type coercions). Yet there
appear to be two camps of the Numeric community. Some sort of 
survey may be in order here. Is scipy where all the new growth is
now? Should we just adopt the axis convention used there? I'd
very much prefer not proliferate any more flavors of behavior
and just settle on one.

> A number of people commented on our naming conventions, an issue which
> we have side stepped for the moment with sumAll().  My impression is
> that, for better or worse, numarray uses the lowerUpper() version of
> Camel case.  I think this is very much a matter of personal taste and
> don't claim to have any.   My guess is that numarray is probably
> inconsistent at the moment, in part because lowerUpper() often
> degenerates into merely lower() which degenerates into confusion. 
> 
How much of the public interface uses camelCase? I don't think
all that much if any. It seems to me the inclination of scipy
is to avoid it and I'm happy with that. The internal implementation
is a different issue, and there I think Todd is right that it 
probably is somewhat inconsistent on that front.

Perry