[Numpy-discussion] RE: default axis for numarray

[Paul F Dubois]

Konrad's arguments are also very good. I guess there was a good reason
we did all that arguing before -- another issue where there is a
Perl-like "more than one way to do it" quandry. 

I think in my own coding reduction on the first dimension is the most
frequent.

> -----Original Message-----
> From: numpy-discussion-admin at lists.sourceforge.net 
> [mailto:numpy-discussion-admin at lists.sourceforge.net] On 
> Behalf Of Konrad Hinsen
> Sent: Tuesday, June 11, 2002 6:12 AM
> To: eric jones
> Cc: 'Perry Greenfield'; numpy-discussion at lists.sourceforge.net
> Subject: Re: [Numpy-discussion] RE: default axis for numarray
> 
> 
> "eric jones" <eric at enthought.com> writes:
> 
> > The issue here is both consistency across a library and speed.
> 
> Consistency, fine. But not just within one package, also 
> between that package and the language it is implemented in.
> 
> Speed, no. If I need a sum along the first axis, I won't 
> replace it by a sum across the last axis just because that is faster.
> 
> > >From the numpy.pdf, Numeric looks to have about 16 functions using
> > axis=0 (or index=0 which should really be axis=0) and, 
> counting FFT, 
> > about 10 functions using axis=-1.  To this day, I can't 
> remember which
> 
> If you weight by frequency of usage, the first group gains a 
> lot in importance. I just scanned through some of my code; 
> almost all of the calls to Numeric routines are to functions 
> whose default axis is zero.
> 
> > code.  Unfortunately, many of the Numeric functions that 
> should still 
> > don't take axis as a keyword, so you and up just inserting -1 in the
> 
> That is certainly something that should be fixed, and I 
> suppose no one objects to that.
> 
> 
> My vote is for keeping axis defaults as they are, both 
> because the choices are reasonable (there was a long 
> discussion about them in the early days of NumPy, and the 
> defaults were chosen based on other array languages that had 
> already been in use for years) and because any change would 
> cause most existing NumPy code to break in many places, often 
> giving wrong results instead of an error message.
> 
> If a uniformization of the default is desired, I vote for 
> axis=0, for two reasons:
> 1) Consistency with Python usage.
> 2) Minimization of code breakage.
> 
> 
> > We should also strive to make it as easy as possible to 
> write generic 
> > functions that work for all array types (Int, Float,Float32,Complex,
> > etc.) -- yet another debate to come.
> 
> What needs to be improved in that area?
> 
> > Changes are going to create some backward incompatibilities 
> and that 
> > is definitely a bummer.  But some changes are also necessary before 
> > the community gets big.  I know the community is already reasonable 
> > size,
> 
> I'd like to see evidence that changing the current NumPy 
> behaviour would increase the size of the community. It would 
> first of all split the current community, because many users 
> (like myself) do not have enough time to spare to go through 
> their code line by line in order to check for 
> incompatibilities. That many others would switch to Python if 
> only some changes were made is merely an hypothesis.
> 
> > > Some feel that is contrary to expectations that the least rapidly 
> > > varying dimension should be operated on by default. There 
> are good 
> > > arguments for both sides. For example, Konrad Hinsen has
> 
> Actually the argument is not for the least rapidly varying 
> dimension, but for the first dimension. The internal data 
> layout is not significant for most Python array operations. 
> We might for example offer a choice of C style and Fortran 
> style data layout, enabling users to choose according to 
> speed, compatibility, or just personal preference.
> 
> Konrad.
> -- 
> --------------------------------------------------------------
> -----------------
> Konrad Hinsen                            | E-Mail: 
> hinsen at cnrs-orleans.fr
> Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
> Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
> 45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
> France                                   | Nederlands/Francais
> --------------------------------------------------------------
> -----------------
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's 
> Conference August 25-28 in Las Vegas - 
> http://devcon.sprintpcs.com/adp/index.cfm?> source=osdntextlink
> 
> 
> _______________________________________________
> Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>