[PYTHON MATRIX-SIG] Re: Version 2.0

[Jim Fulton, U.S. Geological Survey]

On Dec 13, 12:51pm, James Hugunin wrote:
> Subject: [PYTHON MATRIX-SIG] Re: Version 2.0
>
> Paul sent me this as private comments and I'm going to violate all rules of
> Netiquette by replying to the entire group.  I think that there are some
> important things in here to comment on.
>
> > a. It seems like if I don't do the import of omath then 2.*x doesn't
> > work. After a from omath import * it does. (?)
>
> This is true.  You have to import omath somehow, or matrices do not have
> any numeric behavior (notice that if you use import Matrix, or from Matrix
> import *. this gets done for you).  Here are the reasons...
>
> 1) This makes the matrixobject code a lot smaller, and therefore likelier
> to be included in the base python distribution (fingers crossed)

I don't see that this makes any difference.  The matrix module can and should
be in the standard "distribution", but it need not be linked statically into
the interpreter on systems that support dynamic linking, which includes most or
all of the interesting ones.  If it is not linked statically into the
interpreter, but is available as a dynamically linked module, then the size is
not so critical.  I don't think the space issue justifies the weird side-effect
dependencies indicated above.


>
> 2) This makes add.reduce(m) possible.

This doesn't make any sense to me.  But I haven't kept up with this list
either. How does importing or not importing a module have any impact on the
amove expression or it's feasabity?

> 3) This makes it possible to have a vectorized_ofuncmodule (or something
> like that) that defines high performance versions of these operators for a
> particular machine, and then have them be used when you say "a+b".


I don't get this either.  Could you elaborate.



> > b. Matrix(1,2,3) produces a Matrix_l, or at least that is what it
> >     claims it is. Should be a Matrix_i?
>
> This will be seen as a BIG issue, and I'll write more about it later (I've
> a few other demands on my time right now).
>
> It should either be Matrix_b (a matrix of bytes, because 1,2, and 3 can all
> be stored in a single byte) or it should be Matrix_l (a matrix of longs
> because a python integer technically holds a C long).
>
> > c. I preferred the [1.,2.,3.] rather than the Matrix_d(...). A lot. A
> > whole lot. Provide a query function for those who really want to know
> > the flavor of matrix.
>
> The printing of matrices can be GREATLY improved.  I changed the
> matrix_print function so that it goes out and calls a python routine to do
> the actual printing.  Check out the PrintMatrix function in Matrix.py.
> Currently this function just returns the string representation of the object
> (for which Matrix_d is a good choice modulo naming conventions).
>
> Anybody who has good ideas about how to print a matrix can go in and modify
> this python function to get whatever print behavior they like.  If you come
> up with a good print function, send it to me, and I'll include the best one
> in the next release.
>
> > d. I really like the way Matrix decides on a type.
>
> Thanks.
>
> > e. I like the idea that others have suggested of IntegerMatrix(...)
> > instead of a constructor that takes a character to decide type. However,
> > there are times when the latter is useful because you are COMPUTING the
> > type (like choose a precision based on the system, for example) so I
> > wouldn't get rid of the character method.

I agree.

> >     The fact that Matrix() does the right thing and that everything
> > coerces mitigates most of this to the margins, however.
>
> And here I decided to respond to your message in order to stay out of the
> naming issue.  I like both approaches, and I'm waiting to see what things
> look like after the dust has settled.

I think both approaches should be provided.

Jim


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

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