[Numpy-discussion] Don't like the short names like lstsq and irefft
Sasha
ndarray at mac.com
Wed Jun 14 22:46:27 CDT 2006
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.
> 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.
More information about the Numpy-discussion
mailing list