[Numpy-discussion] numpy release

[Christopher Barker]

Alan G Isaac wrote:
> the 
> cost of complexity should be justified by a gain in 
> functionality.

I don't think functionality is the right word here. the Matrix class(es) 
is all about clean, convenient API, i.e. style, not functionality -- we 
have all the functionality already, indeed we have it with plain old 
arrays, so I think that's really beside the point.

I just like the "feel" of Row and Column Vectors.

But this brings me back to:

We need examples of doing linear algebra operations, not just iterating 
operations. Frankly, if you have a matrix, and you want to iterate 
through all the rows, and you want to index into them as 1-d arrays, why 
they heck don't you just:

for r in MyMatrix.A:
    ....

The answer (I think), is that folks have simply been confused and 
annoyed by the fact that they need that extra ".A", which brings us back 
to style.

One extra functionally: you can index a ColumnVector with a scalar:

col = M[:,i]
col[i]

You can't do that now.

This brings me to:
 > the people who write the code (for numpy) don't actually use matrices,
 > they use the arrays

I don't really write numpy code, but I don't really use arrays either. 
Which, I suppose, means I should just shut up. But maybe I would if the 
API was better.

So we're back to: who does want matrices? is it only newbies coming from 
Matlab, where they were used to them?

For once, we do have someone that is writing the code that wants 
improvements, so I guess that's why this discussion has been revived.

Timothy Hochberg wrote:
>    1. The matrices and arrays should become more alike if possible

I'm not sure I agree -- the more alike they are, the less point there is 
to having them.

>       should share more of the same code base. 

Don't they share almost all the same code already? My understanding is 
that they are arrays with a couple operators overloaded -- how much more 
code could they share?

Nevertheless, I'm interested to see what Tim comes up with.

>    2. This doesn't support the concept of arrays of matrices/vectors,
>       which is one thing I've always wanted out of the matrix class. For
>       example it would be nice to be able to spell: 'A' is a 1D array of
>       matrices (3D) overall, 'B' is a 1D array of vectors (3D) overall,

You could do this now with a 1-d object array, with a bunch of matrices 
in it.

>       matrix multiply them together, yielding a 1D array of matrices
>       (3D) overall.

But this, or course, would fail. However, if we expand this scenario to 
A and B being 1-d arrays of other arrays that may not all be the same 
size (and thus you couldn't just use a 3-d array), and be able to run 
various ufuncs on them, that would be cool!

Bill Spotz wrote:
>> The fact that there is another way to get a row vector: M[i] is a  
>> bonus.
> 
> Except that the behavior of M[i] is one of the driving issues of the  
> conversation.

well, yes, but a bit of a red herring, I think -- it's syntactic sugar. 
The issue, I think, is that even if you do:

r = M[:,i]

you can't then index that with a single index -- it's a matrix, NOT a 
1-d array. Again, I proposed disallowing M[i] altogether, as it is 
ambiguous, but that really is gratuitous consistency.

>> A vector is a 1-d array with some functionality overloaded to make it
>> convenient to do linear algebra.
> 
> Again, I would argue for Vectors inheriting from Matrix.  I would make  
> the case based on code reuse and elegance, although these might be  
> overridden by some other concern.

I think that's a bit of an implementation detail -- we need to define 
behavior that we want, and decide how best to implement that. i.e.:

RowVector[i] ->  scalar
RowVector.A  -> 1-d array
(same for column)

How do we want it pretty-printed?

We need to focus on column vectors here -- It's easy to say: a row 
vector is a 1-d array -- that's easy and clean. It's column vectors that 
are tricky -- indeed they are a pain with regular old arrays.

What about
> np.Matrix(<container of RowVector>)
> np.Matrix(<container of ColumnVector>)

I'd say you get a matrix from each of those, but they would be 
transposes of each-other -- another good reason for the Vector classes. 
though maybe those should be spelled:

np.row_stack and np.column_stack

> I have generally thought about this in the context of, say, a
> Krylov-space iterative method, and what that type of interface would  
> lead to the most readable code.

Can you whip up a small example, starting with the current implementation?

Bruce Southey wrote:
> Hi,
> I would like to use the matrix functionality but I, like others, get by 
> without it.

What does it lack that keeps you from using it? That's the key question?

> +1 to Tim's and Nadav's comments. As Tim said, there should be seamless 
> integration between concepts of vectors and matrices - after all there 
> really no distinction between them in linear algebra.

This is all about being able to index a "vector" with a single index -- 
that's it, I think. Matlab handles this by special casing matrices that 
have a single dimension of one. It also has an easy way to spell a 
literal for column vector, though I suppose:

np.Matrix((1,2,3,4,5)).T

isn't so bad.

> -2 for having rowvector and columnvector - both numpy and I should know 
> the orientation, if not, I deserve garbage or an error.

But HOW can you know the orientation? a 1-d array has no orientation -- 
which is why the current version always returns a matrix when indexing.

> 0 for vector - I don't see the need for it as a unique entity but 
> understand the simplicity of saying vector.

I don't think we can have vector without ColumnVector, though I suppose 
a "Vector" can be either a (n,1) or a (1,n) matrix that allows single 
indexing.

By the way, maybe a column vector could be handy for doing array 
broadcasting, as an cleaner way to do:

x = np.arange(10)
y = np.arange(20).reshape((-1,1))

z = FunctionOfXandY(x,y)


Final note:

If no one has an linear algebra examples, then we're wasting out time 
with even this cheap talk.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov