[Numpy-discussion] untenable matrix behavior in SVN

Timothy Hochberg tim.hochberg@ieee....
Tue Apr 29 17:07:19 CDT 2008

On Tue, Apr 29, 2008 at 2:43 PM, Christopher Barker <Chris.Barker@noaa.gov>

> Timothy Hochberg wrote:
> > However, there is matrix related
> > stuff that is at best poorly supported now, namely operations on stacks
> > of arrays (or vectors).
> Tim, this is important, but also appears to be an orthogonal issue to me
> -- whatever we do with matrices, rows, columns, whatever, we still need
> to solve this problem, and any of the schemes being proposed strikes me
> as amenable to having a "array or matrices", and the LA functions that
> act on them. What am I missing?

Ah, that's a very good question. I'll do my best to answer it, it's been a
long time since I dug into this seriously, so I may make some missteps:
holler if you see something odd. Basically, I believe that you need two

   1. The ability to make matrix/row/column objects of arbitrary
   dimensionality, where the extra dimensions contain the
   matrices/rows/columns. Current matrix objects are always 2D.
   2. A way to tell whether a given object represents a row, column or
   matrix. For instance, given a 2D object is it matrix or a stack of vectors.
   You might think that there's enough information implicit in the shape of the
   arrays in conjunction with the nature of the function called that this
   wouldn't be necessary, but it turns out not to be so. As I recall, I had to
   fudge things when I was trying to containerize linalg.solve, because there
   wasn't enough information available to figure out unambiguously the kinds of
   the arguments.

Any of the solutions that attach information to the array, such as your
matrix/row/col approach, or the quasi-tensor approach that I (and someone
else) have mentioned but never detailed, should work for this.

However, any of the solutions that involve trying to encode the information
into the array/matrix shape will probably not work. At least not well.
Fortunately, they seem to be losing traction.

. __
. |-\
. tim.hochberg@ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080429/743bf694/attachment-0001.html 

More information about the Numpy-discussion mailing list