[Numpy-discussion] Don't like the short names like lstsq and irefft (original) (raw)
David M. Cooke cookedm at physics.mcmaster.ca
Fri Jun 16 01:54:39 EDT 2006
- Previous message (by thread): [Numpy-discussion] Don't like the short names like lstsq and irefft
- Next message (by thread): [Numpy-discussion] Don't like the short names like lstsq and irefft
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jun 14, 2006 at 11:46:27PM -0400, Sasha wrote:
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 linearleastsquares, > inverserealfft, 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 inverserealfft is still short for inverserealfastfouriertransform. Presumably, fft is a proper noun in many people vocabularies, but so may be lstsq depending who you ask.
I say "FFT", but I don't say "lstsq". I can find "FFT" in the index of a book of algorithms, but not "lstsq" (unless it was a specific implementation). Those are my two guiding ideas for what makes a good name here.
I am playing devil's advocate here a little because personally, I always recommend the following as a compromize:
sinh = hyperbolicsinus ... tanh(x) = sinh(x)/cosh(x) But the next question is where to put "sinh = hyperbolicsinus": right before the expression using sinh? at the top of the module (import hyperbolicsinus as sinh)? in the math library? If you pick the last option, do you need hyperbolicsinus to begin with? If you pick any other option, how do you prevent others from writing sh = hyperbolicsinus instead of sinh?
Pish. By the same reasoning, we don't need the number 2: we can write it as the successor of the successor of the additive identity :-)
> 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>.
That's 11 years old. The web was only a few years old at that time! There's been much work done on what makes a good programming style (Steve McConnell's "Code Complete" for instance is a good start).
I am still +1 for keeping linearleastsquares and inverserealfft, but not just because abreviations are bad as such - if an established acronym such as fft exists we should be free to use it.
Ok, in summary, I'm seeing a bunch of "yes, long names please", but only your devil's advocate stance for no (and +1 for real).
I see that Travis fixed the real fft names back to 'irfft' and friends.
So, concrete proposal time:
go back to the long names in numpy.linalg (linear_least_squares, eigenvalues, etc. -- those defined in numpy.linalg.old)
- of the new names, I could see keeping 'det' and 'svd': those are commonly used, although maybe 'SVD' instead?
- anybody got a better name than Heigenvalues? That H looks weird at the beginning.
for numpy.dft, use the old names again. I could probably be persuaded that 'rfft' is ok. 'hfft' for the Hermite FFT is right out.
numpy.random is other "old package replacement", but's fine (and better).
--
|>|/|<
/--------------------------------------------------------------------------
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca
- Previous message (by thread): [Numpy-discussion] Don't like the short names like lstsq and irefft
- Next message (by thread): [Numpy-discussion] Don't like the short names like lstsq and irefft
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]