[SciPy-dev] Accessible SciPy (ASP) project
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,
>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.
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.
>Scipy-dev mailing list
>Scipy-dev at scipy.net
More information about the Scipy-dev