[PYTHON MATRIX-SIG] First impressions from the docs

[Jim Hugunin]

Konrad Hinsen wrote:
...
> In general, the current function set is a big step forward.  I
> expectthat I can now replace most awkward constructions in my
> applicationcode by something more concise and more efficient. More on
> that whenI am finished...

Well of course you think its a big step forward, I did almost everything
you asked for... ;)

> I would like to see more flexibility in the constructor if it iscalled
> with a non-sequence first argument. It should try to dosomething
> meaningful whenever possible. If presented with a file,for example, it
> should assume a text file with numbers and doits best to turn it into
> an array (this is very important forreading data produced by other
> programs). And for argumentsthat have no type/class with special
> meaning, it should calla method toArray() if it exists.I do realize
> that reading from a file intelligently is a non-trivialproblem, and
> therefore the best solution is probably to provide afunction hook
> similar to the one for array printing. Thatgives everyone ample
> opportunity to play with array reading code.I have a function (in
> Python) that reads 1D and 2D arrays wellenough for me, but it is not
> very efficient. That could be astarting point for a more sophisticated
> version.

I completely disagree with this.  I think that reading an array from a
text file should probably be a function that comes with the standard
distribution, but I see NO good reason to overload the array creation
operator with this.  There is support for something like a toArray
method, I'll have to remember what this is and add it to ths docs.

I'd be happy to add your fromFile function to Numeric if you want to
send it to me.

> I wonder what exactly resize() does. First, I don't understand whyit
> is less efficient than reshape(); if the size remains the same,
> itshould perform exactly the same operation. But I really wonder
> what"strange" things can happen if I am not "careful". As long as
> theshape argument makes sense (i.e. contains no negative numbers)
> theresult should be well defined.

If the size remains the same, resize is exactly as efficient as
reshape.  All of my warnings are there because I think many people will
find resize a slightly unusual concept.  I think it needs some sort of
dangerous bend signs around it so that novice users won't be confused. 
If I think I'm just applying a reshape function, but I make a mistake in
my matrix size, I personally want to see an exception.  resize will
instead give me a very different array from what I expected.  That's the
strange thing that can happen.

> The function diagonal() is a typical example of a function thatwould
> benefit from J-style function ranks. As it is defined now,it assumes
> that higher-rank arrays are to be treated as arraysof 2D subarrays
> (i.e. function rank 2). This is a useful function,but a "true"
> higher-rank diagonal (the list of elements for whichall indices are
> equal), corresponding to function rank infinity,is also useful. The
> same applies to trace().

I agree with this, but I've decided to keep ranks out of the 1.0
release  as a general rule.  I'm more concerned at the moment with
getting something coherent out the door.

> The axis defaults for sort() and argsort() should be 0.

Default axes...this merits a new thread...

> There are two methods that I would like to see as functions:
> shape()and asType(). Both occur commonly in numerical algorithms,
> wheretheir argument might be a rank-0 array (i.e. a
> scalar).(Alternatively the two methods could be added to the
> Pythonscalar types, but I am not sure if Guido would approve such
> achange.)

I'll add shape, I find I need it all the time too, its really nice to be
able to get the shape of a list or a tuple.

> I still think that in the general spirit of Python, the defaultmath
> module used by Numeric should be umath, not fast_umath.For someone who
> doesn't know all the details, it is betterto be slow than to be wrong.

This also needs its own thread as there are several issues here.

> More when I have the code running...

Glad to see that you're back with us too - Jim

> Konrad.

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

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