[PYTHON MATRIX-SIG] Renaming and Constructors

[James Hugunin]

> 1) Names
>
> This may seem to be a minor issue, but we should tackle this before
> we all get used to the current ones.

I agree completely!

> I strongly dislike the type-specific constructors (also used for
> output). They should be IntegerMatrix, FloatMatrix, ComplexMatrix,
> CharacterMatrix, and GeneralMatrix. Anyone is free to define shorter
> names for efficient typing, if desired.

Does a FloatMatrix contain C floats or doubles (both are possible in  
matrices)?  Please define a complete naming scheme that can be compared to  
the current (admittedly cryptic) typecodes.

Note: The current output is only being used because nobody has yet given me  
a good replacement for the PrintMatrix function.  I deliberately pulled  
this function out into python code so that other people could do it right  
for me.


> I even propose a more radical renaming. Many people associate "matrix"
> with the 2D-matrices from linear algebra. So it would be better to
> call our general objects "arrays", and leave the name "matrix" for
> linear-algebra type objects that are restricted to rank 2 and use *
> for matrix multiplication.  They could be implemented in Python based
> on arrays.

The only problem that I have with array is that python already has arrays  
with a known semantics.  The fundamental rule in python is to never break  
existing code.  I know this is annoying, but the only other option would be  
to make the current matrices completely backward compatible with the  
existing arrays.  (Which is possibly possible...)

Any other naming suggestions?  (I agree that tensor is as bad as matrix)

> The pseudo-index 'None' is very confusing. An index "2" picks item
> number two from an axis, an index "All" picks all items from an
> axis. Consequently "None" should pick no item from an axis, which is
> course is a pointless operation. What it really does is create a new
> axis, so it should be named "New".  "RubberIndex" is not confusing,
> but a bit strange, so it's worth thinking about alternatives. How
> about "Skip", in the sense "skip all following axes for explicit
> consideration"? For the "*" in Yorick I propose "Contract".

I have no good opinions on this issue.  The obvious reason that I chose  
None is that it is a built-in python object, so it is always in the current  
namespace.  This namespace issue is an important one.  I really don't think  
that we are going to be adding any of the three of these to the python core  
any time soon.

One solution would be to use "new", "ellipses", and "contract" and to have  
Matrix.py map these strings to objects.

Note: I picked RubberIndex in the hopes of choosing something sufficiently  
long and hard to type that nobody would assume I meant it to be the final  
solution.  I had hoped that this might be turned into the syntax ".." one  
day, but after the python workshop I doubt that this will happen any time  
soon.

> 2) Constructors
>
> Currently there are two constructors, matrix() and Matrix(), with
> slightly different behaviour: matrix() takes a single argument that is
> a (possibly nested) Python sequence object, e.g. a list. Matrix()
> takes an arbitrary number of arguments that are made into a list
> before being passed to matrix(). So Matrix(1,2,3) is equivalent
> to matrix([1,2,3]).
>
> I find it confusing to have to constructors with almost the same name
> and almost the same function. I propose to have only one, of whatever
> name, which behaves like matrix(). The reason is that many matrix
> functions accept nested lists or tuples instead of matrix arguments,
> e.g. matrix([2,3]) + [5,4] works. So does matrix([2,3]) +
> matrix([5,4]), which is equivalent. But Matrix([2,3]) + [5,4] and
> Matrix([2,3]) + Matrix([5,4]) are not equivalent (well, they are in
> this simple exaple due to broadcasting, but not in general). So
> matrix() can be considered a conversion function from lists and tuples
> to arrays, which is needed anyway.
>
> I realize that the calling style of Matrix() has the advantage of
> saving one pair of brackets, but I don't consider this important
> enough to create the current confusion.

This is a real problem.  I'll repeat my reasons for creating Matrix, but  
otherwise, I'm willing to go along with the consensus of the list on this  
one.

I was looking for the cleanest and easiest to read notation for a matrix in  
the unfortunate world where I couldn't add a new bracket type to python  
(okay, there aren't even any brackets to add so what am I complaining  
about).  I noticed that by using the variable number of arguments notation,  
I got something that looked a lot more like just a new kind of brackets.

Let me know who else agrees with Konrad here.

> I guess that's enough for today ;-) I wish the lucky participants
> of the workshop much fun and hope that they don't have to eat
> spam for lunch ;-)

Had much fun, never ate SPAM - Jim

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

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