[Numpy-discussion] Don't like the short names like lstsq and irefft (original) (raw)

Sasha ndarray at mac.com
Fri Jun 16 09:48:11 EDT 2006

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

More information about the NumPy-Discussion mailing list