Re[2]: [SciPy-user] scipy choice of defaults for matrix manipulation
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
participants (1)
-
Alan G Isaac