[PYTHON MATRIX-SIG] Let's get going

[Jim Fulton, U.S. Geological Survey]

On Wed, 13 Sep 95 12:39:13 -0400 
James Hugunin said:
> 
(snip)
> 
> 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  
> objects.
> 
> >> 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

I think this is too strange.
 
> 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.

Right.  This is polymorphism, not coercion.
 
> 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

Yuck.
 
> 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.

I can't tell 2 and three apart.

Currently, if FIDL calls a function that modifies one of it's
arguments, the modified value is returned as an element of the return
list.  Non-scalar output/modify values are always matrices. If a
modify argument *is* a matrix, then it gets modified, otherwise it
gets copied.  This is a bit gross but it handles most cases.

> 
> >> 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.

I'm not sure what you mean by this.  Surely, you aren't trying to
make:

   m=[[1,2,3],[4,5,6],[7,8,9]]
   b=[11,22,33]
   m=[1]=b
   b[1]=99

cause m[1][1] to equal 99? Are you?

Jim

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

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