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

[Sasha]

On 6/16/06, Sven Schreiber <svetosch at gmx.net> wrote:
> ....
> Abbreviations will emerge anyway, the question is merely: Will numpy
> provide/recommend them (in addition to having long names maybe), or will
> it have to be done by somebody else, possibly resulting in many
> different sets of abbreviations for the same purpose.
>
This is a valid point.  In my experience ad hoc abbreviations are more
popular among scientists who are not used to writing large programs.
They use numpy either interactively or write short throw-away scripts
that are rarely reused.  Programmers who write reusable code almost
universally hate ad hoc abbreviations. (There are exceptions:
<http://www.kuro5hin.org/story/2002/8/30/175531/763>.)

If numpy is going to compete with MATLAB, we should not ignore
non-programmer user base.  I like the idea of providing recommended
abbreviations.   There is a precedent for doing that: GNU command line
utilities provide long/short alternatives for most options.  Long
options are recommended for use in scripts while short are
indispensable at the command line.

I would like to suggest the following guidelines:

1. Numpy should never invent abbreviations, but may reuse
abbreviations used in the art.

2. When alternative names are made available, there should be one
simple rule for reducing the long name to short.  For example, use of
acronyms may provide one such rule: singular_value_decomposition ->
svd.  Unfortunately that would mean linear_least_squares -> lls, not
ols and conflict with rule #1 (rename lstsq ->
ordinary_least_squares?).

The second guideline may be hard to follow, but it is very important.
Without a rule like this, there will be confusion on whether
linear_least_squares and lsltsq are the same or just "similar".