[PYTHON MATRIX-SIG] Let's get going

James Hugunin jjh@mama-bear.lcs.mit.edu
Wed, 13 Sep 95 12:39:13 -0400

In my previous post I comment on what appears to be the primary source of  
controversy for the matrix object, whether it should be treated as a table  
of numbers, or as a true mathematical matrix.  I'm afraid that that issue is  
likely to be the source of substantial more discussion before anything is  

I would also like to comment on some of the less controversial points  
raised by Jim Fulton in his first post regarding basic methods for matrix  

>> transpose - The transpose of the matrix (not needed if "~" is used for
>> transpose)
> I'm thinking that this (or ~) should return by reference.

I agree completely.  In fact, when I went about implementing matrix slices  
(so that m[((1,3),)] can be properly returned by reference, I noticed that  
transposing a matrix was trivially implemented by converting it to a matrix  
slice.  This of course raises the issue of how to properly deal with these  
matrix slices.

For example, the way my code is written now, if I try to add a slice to a  
matrix, I can perform the operation quickly without needing to convert the  
slice to a matrix, as long as the slice meets a fairly obscure list of  
requirements.  Basically these can be summarized as the fact that there must  
be a constant offset between the indices for each dimensions.  ie.

M[((1,3,5),)] would be easy to deal with (as fast as a matrix) whereas:
M[((1,3,6),)] would not be

What bothers me about this gets back to your earlier complaints regarding  
automatic coercion as being a possible source of errors (which I've come  
around to agreeing with in general).  On the other hand, conceptually, it  
would be nice to be able to treat a slice exactly the same as a matrix  
whenever possible.

I see three options, none of which seems perfect, but I am inclined towards  
the third.

1) Don't allow slices to be passed to functions which require a matrix  
argument, and don't allow numeric operations on slices

2) Treat a slice just like any other non-matrix sequence, and allow numeric  
operations, and allow it to be passed to matrix functions using the generic  
sequence to matrix functions (there is an interesting issue here having to  
do with copying data back from the matrix to the input sequence if it turns  
out that the function modifies it's input data.  I'm curious as to how you  
deal with this, or whether you just don't allow this to happen).

3) Whenever a slice is passed to a function requiring a matrix argument,  
automatically copy the data from the slice to a contiguous block of memory.   
Allow slices to be used in numeric operations, doing this efficiently where  
possible, and copying the slice to a contiguous block of memeory where not  
possible.  This would be the most efficient solution.

>> byteswap - Useful for reading data from a file written on a machine with a  
>> different byte order

> Hm. Does this operate in-place or return a value?

In-place.  In fact, I am tempted to try and make all of the methods on  
matrices operate "in-place" in order to be in line with list objects.

>> typecast(t) - Returns a new matrix of the same dimensions where each item  
>> is cast (using C typecasting rules) from the matrix's type to the new type  
>> t.

>Our constructor already gives you this:

>  new_matrix=Matrix(old_matrix,new_type)

True.  My problem is that I am frequently having to cast between types (I  
deal with samples of sound that usually have to come in and go out as  
shorts, but which I usually want to operate on as floats in the meantime).

So, I agree that this should be done using the matrix constructor, and all  
that I'd add is that the matrix constructor should be written so that this  
typecasting is done efficiently.

-Jim Hugunin   hugunin@mit.edu

MATRIX-SIG  - SIG on Matrix Math for Python

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