[SciPy-dev] Re[2]: [SciPy-user] scipy choice of defaults for matrix manipulation

[Alan G Isaac]

On Thu, 05 Aug 2004, Travis Oliphant apparently wrote:
> This is fragmenting the community and is not a good thing in my
> opinion.   You may make a case for which standard is appropriate but the
> axis=-1 was decided on after some deliberation.  It is open for discussion.

Allow me one last comment on this:
It was important to know who was deliberating:
engineers, economists, statistitians, etc.

To illustrate:
in numarray (which seeks Numeric compatibility)
we find

axis=-1:
all of fft stuff
sort, argsort, argmin, argmax, trapz, diff

axis=0:
all of the linear algebra stuff
  (except diff in mlab.py, which numarray no longer documents)
along with repeat, concatenate, compress, reduce,
accumulate, average, take, alltrue, sometrue, zreduce,
areduce, put

I hazard the the linear algebra stuff is the most commonly
used module.

In the econometrics community, data series are by far
most often characterized as columns of a 2D array,
and the numarray defaults in the linear algebra module
seem natural to us.

Since scipy plans sensibly to rely on Numeric and then
numarray, it just does not seem workable to use different
defaults.  This will create widespread confusion.  I would
urge that the scipy and numarray developers hash this out.

But in the meantime, I hope the scipy developers will
emphasize compatibility of the default behavior of 
imported functions.  If the axis question seems pressing,
good simplicity could be achieved here as follows.  For
        sort, argsort, argmin, argmax, trapz, diff
*require* an axis argument, and document this prominently.
(Also, lean on the numarray folks to change the defaults
behavior of these.)  For everything else, use the
numarray defaults.

The bottom line question is: is it really tenable
for users to know that scipy relies of Numeric/numarray
while adopting different default behavior?  I believe not.
Here is an additional consideration: the numarray folks
are producing pretty decent documentation, and SciPy
will be able to rely on that instead of producing its own
documentation for the same functions.  Time is scarce.

Thanks for thinking about this.
I will shut up now.

Alan Isaac