Home Original page

Matlab vs Python (was RE: Discussion: Introducing new operators f

hzhu at localhost.localdomain.bbs hzhu at localhost.localdomain.bbs
Mon Jul 17 19:20:03 EDT 2000 
On 17 Jul 2000 17:39:33 -0400, David M. Cooke <cookedm at physics.mcmaster.ca>
wrote:
>> Consider the proposal of having two classes, Matrixwise and Elementwise,
>> with methods to cast to each other.  I don't know why
>>
>> (a.E()*b.E()).M()*(c.E()*d.E()).M()
>>
>> would be more preferable to
>>
>> (a.*b)*(c.*d)
>
>Well, it doesn't have to be as complicated as your first example. Assume
>the default is Matrixwise, and we get rid of some ()'s by overriding
>__getattr__, so that we can right
>
>(a.E*b.E)*(c.E*d.E)
>

That's a good point.  Can __getattr__ be made to work only on a selected
number of attributes?  We could use it on T, H, I, C for transpose,
Hermitian transpose, inverse and conjugate.  But if it works on all the
undefind members the error message may be too obscure.  Any examples?

BTW, you meant

(a.E*b.E).M*(c.E*d.E).M

for otherwise it is equivalent to (a.*b).*(c.*d).

>But what if we assume that if one operand has .E, the other does also!
>Then we can write
>
>(a.E*b)*(c.E*d)

This won't work.  It would introduce many hard-to-trace bugs.  Looking at

(a*b)*(c*d)

and you have to trace the program all the way down to figure out the
identities of a,b,c,d.  Note that in concept the identities of the objects
do not change.  We are changing their identities only as labels to help
picking different operators.  I can foresee great confusion in practice with
this approach.

Huaiyu
More information about the Python-list mailing list