[PYTHON MATRIX-SIG] Some thoughts on default axes.
Thu, 22 Aug 1996 11:02:38 -0400
> I have an idea about default axes. I'm not entirely satisfied with it,
> but its been bugging me for a week or so, so I figured I'd let it bug
> you'all instead.
I'm glad you brought this idea up, it seems there might be a solution in
> Some sort of naming convention could provide a way out of this
> box. That is, indicate by the name of the function what the default
> axis is, e.g.,
> fft(f) <=> fft(f,axis=0)
> fft_(f) <=> fft(f,axis=-1) # _ <=> farther away <=> -1 (or -2...)
> A complete set of both functions could be provided, or just guidelines
> on how people are to name their own should they need the other axis.
I really don't think that a complete set of both function should be
provided. The great value in this proposal is it lets me define the
"proper" default axis for each function without fear of people not being
able to remember which one that is.
> 1) No need to type axis=? for what should be the default case.
> 2) Obvious at a glance what the default axis is.
> 3) Removes incentive to create private versions of functions.
The pros all sound good to me.
> 1) Aesthetics?
I don't like fft_ for the last axis. _ is getting a little bit
overloaded in python these days.
> 2) Requires a certain amount of function renaming.
Still not a big concern to me.
> 3) Doesn't help with dot (**).
I don't think this should be too much of a concern.
Now my comments in full:
0) I've been writing code all this week using alpha2 and I've found
myself quite happy writing fft(a, axis=-1) everywhere. This isn't
actually all that much extra baggage to be carrying around. That
1) A naming convention to distinguish between structural and
non-structural operations might satisfy both Konrad and myself. I'm
still not sure what that naming convention should look like.
2) This naming convention should not become a substitute for non-default
axis specification. ie. people should not define concatenate_ as a
substitute for concatenate( arrays, axis=-1). Using this keyword
argument seems to me a great way to change the default axis when you
I can't think of any good naming conventions off hand, but just to make
things concrete, here's a list of some names to discuss:
structural operations: concatenate, reduce, take, repeat, ...
nonstructural operation: sort, argsort, fft, argmax, (sum?), ...
And here are several bad proposals (I'm not planning on implementing any
nonstructural_sort, nonstructural_fft, ...
ns_sort, ns_fft, ...
sort_last_axis, fft_last_axis, ...
If the names of these functions somehow made their categories obvious,
then I'd be happy to set the default axis for the nonstructural
operations to be -1.
Now to shoot down a few directions I don't want this conversation to go.
> (**) Another naming convention that is too ugly too live, but would
> take care of dot, is:
> dot00(f,g) = dot(f,g,axis=(0,0))
> dot01(f,g) = dot(f,g,axis=(0,-1))
> fft1(f) = fft(f,axis=-1)
Definately too ugly to live ;-) To say it again. The point here is to
make it obvious by the name what type of function this is (structural or
non) not to replace the perfectly good way we already have of overriding
the default axis.
On another note:
Janne Sinkkonen wrote:
> Here is a related idea: the default axis could be (could it be
> technically and easily? i'm somewhat new to python) an attribute of
> the functions, so one could write:
This is reasonably easy technically, but see my comments later for why I
won't do it.
> for f in Numeric.ufuncs: f.default_axis=-1
> Code reability would suffer badly, of course. I don't know whether
> this is a good idea or not, it just came to my mind.
Code readability would suffer far too much for my tastes. This is just
another variant on the:
def fft(x,axis=-1): fft(x,axis)
solution. This is the sort of thing that everybody would probably enjoy
when writing their own functions, but which would make reading other
people's code impossible.
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: firstname.lastname@example.org
administrivia to: email@example.com