Discussion: Introducing new operators for matrix computation
gjm11 at g.local.bbs
gjm11 at g.local.bbs
Mon Jul 17 18:20:03 EDT 2000
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
More information about the Python-list
mailing list