[PYTHON MATRIX-SIG] Naming conventions

[James Hugunin]

> a. It is a surprising thing (to me) that while tan is in the Fortran standard,
>    cot isn't. We put one in Basis because it drove us crazy.

I completely agree that we should expand upon the basic mathematical  
functions, not feeling limited by the current math.h C-library.

> c. However, that leads us to the whole discussion of naming. I think if
>    you read "Reusable Software" by Bertrand Meyer, and have some experience
>    with constructing large scale reusable component libraries (which is
>    what Python is generating on a frightening scale) it turns out that
>    a consistent naming convention is very, very important. Some of the
>    lessons the Eiffel community has learned are:
>
>    1. Abbreviations should be avoided. Basically, if you don't abbreviate
>       you can't forget which abbreviation to use. So in the immediate case,
>       I would favor conjugate rather than conjg. This tends to be against
>       the traditions in a rapid prototyping language but the components
>       we are building aren't the rapid prototype they are elements of
>       the reusable software library. (Although, you can make a case that
>       conjg isn't an abbreviation, it is the Fortran name which everyone
>       knows!)

As somebody who hates FORTRAN, I'd really like to argue strongly against  
assuming that everybody knows a FORTRAN name.  I'd like to second your  
motion for "conjugate".

I've been trying to follow exactly the convention that you mention for  
naming my basic ofuncs, thus I have "multiply", "divide", "leftShift",  
"andBoolean", "andLogical", and even things like "absolute", and "power"  
though I can see arguments for "pow" and "abs".

> e. About the printed representation of a complex: shouldn't it be
>    complex(1.0, 1.1) not 1j1.1 ? There are two components to this thought.
>    One is that the two parts should be presented with equal precision.
>    Second is that it might come in handy if the printed form was readable
>    back into Python, and there seems to be some "tradition" of this sort
>    of convention in Python components already. The Fortran representation
>    for code literals is (1.0, 1.1) which is also suggestive.

I believe that what's going on here is that Konrad is hoping that something  
like 1.0j1.0 (note the reasonable precision) will become acceptable as an  
input form to python for creating complex numbers.  I know that printing out  
a matrix that has a lot of complex(1.0, 1.0) entries is hideous, so I'm in  
favor of this idea.

> d. In the matrix class, one ought to worry about putting a name like
>    "pp". Not only are some users going to accidentally call one of their
>    variables pp, when you read it you haven't a clue what it is.
>    PrintMatrix ? (Unless, has pp become a standard Python abbreviation for
>    PrettyPrint?)
> f. Note to ourselves: the printing of large matrices needs to be more
>    orderly and labeled.

I agree, pp is hideous.  It was only a hack so that I could easily write  
sample code and have the matrices printed out looking half-way decent.  The  
whole issue of printing matrices needs to be addressed.  One part of this  
issue is the desire that the basic printed representation of an object  
should correspond to a command that could be used to recreate that object,  
on the other hand, the well-labeled format you show from BASIS is generally  
what a user wants to see.  I'm ambivalent on this issue.  If somebody gives  
me a good routine for printing a matrix I'd love to add it to my code.

-Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================