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

[Sasha <nd...@ma...>]

On 6/14/06, David M. Cooke <co...@ph...> 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.


> Abbreviations aren't necessary unique (quick! what does eig() return by
> default?), and aren't necessarily obvious. A Google search for irfft vs.
> irefft for instance turns up only the numpy code as (English) matches for
> irefft, while irfft is much more common.
>
Short names have one important advantage in scientific languages: they
look good in expressions.

What is easier to understand:

  hyperbolic_tangent(x) = hyperbolic_sinus(x)/hyperbolic_cosinus(x)

or

  tanh(x) = sinh(x)/cosh(x)

?

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?


> 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>.

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.