Sasha wrote: >On 6/16/06, Sven Schreiber <[EMAIL PROTECTED]> 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. > > Unless the abreviations are obvious, adding second set of names will make it more difficult to read others code. In particular, it will make it harder to answer questions on the newsgroup. Particularly since I suspect that most of the more experienced users will end up using long names while the new users coming from MATLAB or whatever will use the shorter names.
>I would like to suggest the following guidelines: > >1. Numpy should never invent abbreviations, but may reuse >abbreviations used in the art. > > Let me add a couple of cents here. There are widespread terms of the art and there are terms of art that are specific to a certain field. At the top level, I would like to see only widespread terms of the art. Thus, 'cos', 'sin', 'exp', etc are perfectly fine. However, something like 'dft' is not so good. Perversely, I consider 'fft' a widespread term of the art, but the more general 'dft' is somehow not. These narrower terms would be perfectly fine if segregated into appropriate packages. For example, I would consider it more sensible to have the current package 'dft' renamed to 'fourier' and the routine 'fft' renamed to 'dft' (since that's what it is). As another example, linear_algebra.svd is perfectly clear, but numpy.svd would be opaque. >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. > Svd is already a term of the art I believe, so linalg.svd seems like a fine name for singular_value_decomposition. > Unfortunately that would mean linear_least_squares -> lls, not >ols and conflict with rule #1 (rename lstsq -> >ordinary_least_squares?). > > Before you consider this I suggest that you google 'linear algebra lls' and 'linear algebra ols'. The results may suprise you... While your at it google 'linear algebra svd' >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". > > Can I just reiterate a hearty blech! for having two sets of names. The horizontal space argument is mostly bogus in my opinion -- functions that tend to be used in complicated expression already have short, widely used abbreviations that we can steal. The typing argument is also mostly bogus: a decent editor will do tab completion (I use a pretty much no frills editor, SciTe, and even it does tab completion) and there's IPython if you want tab completion in interactive mode. -tim _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
