[Numpy-discussion] Don't like the short names like lstsq and irefft

[David M. Cooke]

On Wed, Jun 14, 2006 at 11:46:27PM -0400, Sasha wrote:
> On 6/14/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:
> > After working with them for a while, I'm going to go on record and say that I
> > prefer the long names from Numeric and numarray (like linear_least_squares,
> > inverse_real_fft, etc.), as opposed to the short names now used by default in
> > numpy (lstsq, irefft, etc.). I know you can get the long names from
> > numpy.dft.old, numpy.linalg.old, etc., but I think the long names are better
> > defaults.
> >
> 
> I agree in spirit, but note that inverse_real_fft is still short for
> inverse_real_fast_fourier_transform.  Presumably, fft is a proper noun
> in many people vocabularies, but so may be lstsq depending who you
> ask.

I say "FFT", but I don't say "lstsq". I can find "FFT" in the index of a
book of algorithms, but not "lstsq" (unless it was a specific
implementation). Those are my two guiding ideas for what makes a good
name here.

> I am playing devil's advocate here a little because personally, I
> always recommend the following as a compromize:
> 
> sinh = hyperbolic_sinus
> ...
> tanh(x) = sinh(x)/cosh(x)
> 
> But the next question is where to put "sinh = hyperbolic_sinus": right
> before the expression using sinh?  at the top of the module (import
> hyperbolic_sinus as sinh)? in the math library? If you pick the last
> option, do you need hyperbolic_sinus to begin with?  If you pick any
> other option, how do you prevent others from writing sh =
> hyperbolic_sinus instead of sinh?

Pish. By the same reasoning, we don't need the number 2: we can write it
as the successor of the successor of the additive identity :-)

> > Also, Numeric and numarray compatibility is increased by using the long
> > names: those two don't have the short ones.
> >
> > Fitting names into 6 characters when out of style decades ago. (I think
> > MS-BASIC running under CP/M on my Rainbow 100 had a restriction like that!)
> >
> Short names are still popular in scientific programming:
> <http://www.nsl.com/papers/style.pdf>.

That's 11 years old. The web was only a few years old at that time!
There's been much work done on what makes a good programming style
(Steve McConnell's "Code Complete" for instance is a good start).

> I am still +1 for keeping  linear_least_squares and inverse_real_fft,
> but not just because abreviations are bad as such - if an established
> acronym such as fft exists we should be free to use it.

Ok, in summary, I'm seeing a bunch of "yes, long names please",
but only your devil's advocate stance for no (and +1 for real).

I see that Travis fixed the real fft names back to 'irfft' and friends.

So, concrete proposal time:

- go back to the long names in numpy.linalg (linear_least_squares,
  eigenvalues, etc. -- those defined in numpy.linalg.old)
  - of the new names, I could see keeping 'det' and 'svd': those are
    commonly used, although maybe 'SVD' instead?
  - anybody got a better name than Heigenvalues? That H looks weird
    at the beginning.

- for numpy.dft, use the old names again. I could probably be persuaded
  that 'rfft' is ok. 'hfft' for the Hermite FFT is right out.

- numpy.random is other "old package replacement", but's fine (and
  better).

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca