[SciPy-dev] Accessible SciPy (ASP) project

eric jones eric at enthought.com
Tue Oct 19 12:18:09 CDT 2004

Alan G Isaac wrote:

>On Mon, 18 Oct 2004, Robert Kern apparently wrote:
>>1. Neither Numeric nor numarray have a consistent axis convention to adopt.
>In numarray (which seeks Numeric compatibility) we find
>all of fft stuff
>sort, argsort, argmin, argmax, trapz, diff
>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 consider it a convention to say:
>all of the linear algebra stuff uses axis=0,
>all of fft stuff uses axis=-1
>If the axis question seems pressing for the other functions,
>I suggest that for sort, argsort, argmin, argmax, trapz,
>diff SciPy can *require* an axis argument, and document this
>prominently.  Any other deviation is going to eventually
>lead somebody to make a terrible mistake.
>It is not tenable for users to know that SciPy relies on
>Numeric/numarray but adopts different default behavior.
>And, as I said before, this complicates documentation
>efforts, which could be a shared effort across Numeric,
>numarray, and SciPy.
Hey Alan,

I'm sorry you don't like it.  Rest assured it is a well discussed 
topic.  There is a long thread on the numpy-discussion mailing list 
entitled "default axis for numarray" if you would like to see more 
history of points from both sides.  Here is a summary of the reason that 
axis=-1 is used in SciPy.

SciPy adopted axis=-1 for all functions for the sake of consistency 
across the entire user experience with array operations.  As people add 
modules, there is no question what to use for operations that reduce 
dimensionality along a certain axis.  Also there is no question from a 
user's point of view what type of function they are using.  They don't 
have to decide whether an operation is a "reduction" type operation or a 
time series type operation which is the current distinction for 
Numeric.  Some people may have that rule memorized and be able to apply 
it across the libraries consistently, but it takes getting use.  My 
personal experience, experience teaching and also with clients learning 
python has been counter to yours and suggests that a single rule across 
all functions is more easily learned and intuitive.  The rule has the 
added benefit of working over contiguous regions of memory without 
requiring a copying of strided data into an intermediate buffer.  This 
is more efficient and is likely why axis=-1 was chosen for fft and 
friends in the first place.

I don't like the idea of requiring a keyword argument.  Documenting more 
thoroughly is a good idea as with many many things in the SciPy world.


>Alan Isaac
>Scipy-dev mailing list
>Scipy-dev at scipy.net

More information about the Scipy-dev mailing list