[PYTHON MATRIX-SIG] Let's get going
Jim Fulton, U.S. Geological Survey
jfulton@usgs.gov
Wed, 13 Sep 1995 16:38:56 -0400
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
=================