[Numpy-discussion] RE: default axis for numarray

[Konrad Hinsen]

> I think the consistency with Python is less of an issue than it seems.
> I wasn't aware that add.reduce(x) would generated the same results as
> the Python version of reduce(add,x) until Perry pointed it out to me.

It is an issue in much of my code, which contains stuff written with
NumPy in mind as well as code using only standard Python operations
(i.e. reduce()) which might however be applied to array objects.

I also use arrays and nested lists interchangeably in many situations
(NumPy functions accept nested lists instead of array arguments).
Especially in interactive use, nested lists are easier to type.

> There are some inconsistencies between Python the language and Numeric
> because the needs of the Numeric community.  For instance, slices create
> views instead of copies as in Python.  This was a correct break with

True, but this affects much fewer programs. Most of my code never
modifies arrays after their creation, and then the difference in
indexing behaviour doesn't matter.

> I don't see choosing axis=-1 as a break with Python -- multi-dimensional
> arrays are inherently different and used differently than lists of lists

As I said, I often use one or the other as a matter of convenience.
I have always considered them similar types with somewhat different
specialized behaviour. The most common situation is building up
some table with lists (making use of the append function) and
then converting the final construct into an array or not, depending
on whether this seems advantageous.

> in Python.  Further, reduce() is a "corner" of the Python language that
> has been superceded by list comprehensions.  Choosing an alternative

List comprehensions work in exactly the same way, by looping over the
outermost index.

> > 2) Minimization of code breakage.
> 
> Fixes will be necessary for sure, and I wish that wasn't the case.  They
> will be necessary if we choose a consistent interface in either case.

The current interface is not inconsistent. It follows a different
logic than what some users expect, but there is a logic behind it. The
current rules are the result of lengthy discussions and lengthy tests,
though admittedly by a rather small group of people. If you arrange
your arrays according to that logic, you almost never need to specify
explicit axis arguments.

> Choosing axis=0 or axis=-1 will not change what needs to be fixed --
> only the function names searched for.

I disagree very much here. The fewer calls are concerned, the fewer
mistakes are made, and the fewer modules have to be modified at all.
Moreover, the functions that currently use axis=1 are more specialized
and more likely to be called in similar contexts. They are also, in
my limited experience, less often called with nested list arguments.

I don't expect fixes to be as easy as searching for function names and
adding an axis argument. Python is a very dynamic language, in which
functions are objects like all others. They can be passed as
arguments, stored in dictionaries and lists, assigned to variables,
etc.

In fact, instead of modifying any code, I'd rather write an interface
module that emulates the old behaviour, which after all differs only
in the default for one argument. The problem with this is that it adds
another function call layer, which is rather expensive in Python.

Which makes me wonder why we need this discussion at all. It is almost
no extra effort to provide two different C modules that provide the
same functions with different default arguments, and neither one
needs to have any speed penalty.

> True.  But I can tell you that we're definitely doing something wrong
> now.  We have a superior language that is easier to integrate with
> legacy code and less expensive than the best competing alternatives.
> And, though I haven't done a serious market survey, I feel safe in
> saying we have significantly less than 1% of the potential user base.

I agree with that. But has anyone ever made a serious effort to find
out why the whole world is not using Python?

In my environment (which is too small to be representative for
anything), the main reason is inertia. Most people don't want to
invest any time to learn any new language, no matter what the
advantages are (they remain hypothetical until you actually start to
use the new language). I don't know anyone who has started to use
Python and then dropped it because he was not satisfied with some
aspect of the language or a library module.

On the other hand, I do know projects that collapsed after a split in
the user community due to some disagreement over minor details.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------