[PYTHON MATRIX-SIG] Final conventions for alpha2
Fri, 16 Aug 1996 13:50:43 -0400
Konrad HINSEN wrote:
> > Because I can't possibly conceive of doing "fft" and its ilk with a
> > default axis other than -1, every function in NumPy will have a default
> > axis of -1 (or -2 for matrix operations). This currently includes all
> Could it be that you have a special bias for FFT? I don't consider
> FFTs so fundamental that they should set the default for all
> array functions. Statistically most functions would best have
> a default of 0, those that should have another default are the
I don't have a particular bias towards fft, but I do have one towards
the huge collection of non-strctural numeric operations that have the
same properties. Things like histogram, spline, sort, argmax, etc.
> > I wish I could come up with a better compromise, but I myself was
> > finding it hard to remember what the default axes were for different
> > operations, and that's just intolerable.
> Using -1 for everything is more intolerable than anything else.
> A quick glance at my existing code shows that I would need
> an explicit axis specifications for 80% of my function calls!
If this really troubles you, write:
def take(a, axis=0): Numeric.take(a, axis)
at the start of your modules (though not at the start of modules that
you want me to be able to read).
> Actually the default axis discussion has a long history in the APL
> community. The original APL allowed axis specifications in the same
> style as Python now does. The default axis was always zero, but for
> reduce and accuulate an alternate form with a default of -1 was
> provided. The various problems with this approach (and other
> limitations in APL) led to the rank concept in J. For most
> applications there is not much difference between function ranks and
> axis specifications, since the effect for simple arrays is rather
> similar. But J also gave up the "the same default for everyone"
> rule. However, it is possible to inquire about the default rank
> of any J function, which helps to reduce confusion and bad memory
> problems ;-)
And one of my greatest complaints with J is similar to the complaints
you are always hearing about perl, it makes for very concise but hard to
read code. Python has always made the tradeoff for greater readability
over less typing where the question has come up. I really think that
I'm following in that tradition here.
> > I will add keyword arguments to all of the functions that accept an axis
> > so that you can at least write concatenate([a,b], axis=0) which I think
> > is much more readable than the non-keyword alternative.
> Definitely. But what happens to dot(), which needs two axes?
Probably gets axis=(axis1, axis2), but I'm not overly concerned about
dot at this point. Right now, and probably until after the 1.0 release
dot does not allow non default axis specification.
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: email@example.com
administrivia to: firstname.lastname@example.org