[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
decided.
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
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
=================