Discussion: Introducing new operators for matrix computation

[gjm11 at g.local.bbs]

Huaiyu Zhu wrote:

>>> How would you write this in list compresension (in less than 10 lines)?
>>>
>>> B*(sin(A*x+b).*(A*y)/3)/C
>>>
>>> Note that * is matrix multiplication and .* is elementwise.  Note that C is
>>> a matrix so the / is matrixwise.  If you want to write everything as for
>>> loops it takes at least 30 lines, without any decent error analysis.
>>
>>    B*[p*q/3 for p in A*x+b, q in A*y]/C
>
> Someone else had already given a similar answer.  But more work is needed
> for such things to work:
>
> The x, b and y could be matrices, so p and q need to be double loops.

Only if you implement matrices as lists of lists, in which
case operations like * and / won't work anyway. I was assuming
that (1) you have a special Matrix class, and (2) the machinery
for list comprehensions is flexible enough to let it express
other kinds of mapping.

> The [ ... ] need to be a double lists.  Is list comprehension defined for
> this?

It doesn't even exist yet. :-)

I repeat that I'm assuming that there's mechanism for doing
"comprehension" on aggregate objects other than lists, so
that [f(p) for p in FOO] can be made to build a copy of FOO
with the operation f applied to its elements. I think this
is the Python Way (consider e.g. the fact that it does
tuple indexing and list indexing and dictionary indexing
all with a uniform syntax).

> B*[..]/C would not work without a cast from double list to matrix.

Not if my assumption above is correct.

> For all these errors, what would the error messages look like?  Do they
> involve the dummy indices p and q?  A previous answer also reused the name b
> for the dummy variable, which would make the error even more obscure.

These are not errors unless my (perfectly reasonable) assumptions
turn out to be false.

> Besides, the main point of using matrix is to be free from specifying loops
> over indices with dummy names.  Compare this double loop with extra syntax
> with a single operator .* and you may wonder why this is considered at all.

And compare the cumbersome expression above with the much simpler
  &
which I have just defined to mean what you write as
"B*(sin(A*x+b).*(A*y)/3)/C". It's easy to make things
look neater by adding syntactic sugar, provided you're
doing it to only one smallish class of things at a
time. But there's such a thing as too much syntactic
sugar. One design decision that's pretty fundamental
to Python is that there's very little syntactic sugar;
if you prefer a language that goes the other way, you
can always try APL or J. They're pretty good with
matrices, too. :-)

--
Gareth McCaughan  Gareth.McCaughan at pobox.com
sig under construction