[Numpy-discussion] generalized_inverse

Travis Oliphant oliphant.travis at ieee.org
Sat Jul 15 23:21:26 CDT 2006


Victoria G. Laidler wrote:
> Jonathan Taylor wrote:
>
>   
>> pseudoinverse
>>
>> it's the same name matlab uses:
>>
>> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/pinv.html
>>     
>
> 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 
on it.

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.


-Travis





More information about the Numpy-discussion mailing list