oliphant.travis at ieee.org
Sat Jul 15 23:21:26 CDT 2006
Victoria G. Laidler wrote:
> Jonathan Taylor wrote:
>> it's the same name matlab uses:
> Thanks for the explanation.
> I'm puzzled by the naming choice, however. Standard best practice in
> writing software is to give understandable names, to improve readability
> and code maintenance. Obscure abbreviations like "pinv" pretty much went
> out with the FORTRAN 9-character limit for variable names. It's very
> unusual to see them in new software nowadays, and it always looks
> unprofessional to me.
I appreciate this feedback. It's a question that comes up occasionally,
so I'll at least give my opinion on the matter which may shed some light
I disagree with the general "long-name" concept when it comes to
"very-common" operations. It's easy to take an idea and
over-generalize it for the sake of consistency. I've seen too many
codes where very long names actually get in the way of code readability.
Someone reading code will have to know what an operation actually is to
understand it. A name like "generalized_inverse" doesn't convey any
intrinsic meaning to the non-practitioner anyway. You always have to
"know" what the function is "really" doing. All that's needed is a
"unique" name. I've found that long names are harder to remember
(there's more opportunity for confusion about how much of the full name
was actually used and how any words were combined).
A particularly ludicrous case, for example, was the fact that the very
common SVD (whose acronym everybody doing linear algebra uses) was named
in LinearAlgebra (an unecessarily long module name to begin with) with
the horribly long and unsightly name of singular_value_decomposition.
I suppose this was done just for the sake of "code readability."
It's not that we're concerned with MATLAB compatibility. But, frankly
I've never heard that the short names MATLAB uses for some very common
operations are a liability. So, when a common operation has a short,
easily-remembered name that is in common usage, why not use it?
That's basically the underlying philosophy. NumPy has too many very
basic operations to try and create very_long_names for them.
I know there are differing opinions out there. I can understand that.
That's why I suspect that many codes I will want to use will be written
with easy_to_understand_but_very_long names and I'll grin and bear the
extra horizontal space that it takes up in my code.
More information about the Numpy-discussion