Home Original page

[PEP draft 2] Adding new math operators

Robin Becker robin at jessikat.fsnet.co.uk
Thu Aug 10 05:33:07 EDT 2000 
In article <m37l9p8o3x.fsf at chinon.cnrs-orleans.fr>, Konrad Hinsen
<hinsen at cnrs-orleans.fr> writes
>hzhu at localhost.localdomain (Huaiyu Zhu) writes:
>
>> You also end up with expressions like
>> 
>> ((a.E*b.E).M*(c.E*d.E).M).E + (x.M*y.M).E  # vs    (a~*b)*(c~*d) ~+ x*y
>>                                            # or    (a*b)~*(c*d) + x~*y
>
>I agree that such expressions are an argument against the "two classes"
>approach, but I am not yet convinced that such expressions do actually
>occur frequently in any real-life application.
>
>In my experience, a more typical situation would be the following:
>
>- a, b, c, d are arrays
>- x and y are matrices
>
>Then you would write
>
>    matrix(a*b) * matrix(c*d) + x*y
>
>or using attributes
>
>    (a*b).matrix * (c*d).matrix + x*y
>
>both of which are perfectly readable.
>
>I have never seen any situation in which matrix objects (i.e. objects
>which are the result of matrix operations) are subsequently used in
>elementwise operations, with a result that has to be used in a matrix
>operation immediately afterwards.


This is my gut feeling as well, although I guess we should ask
people/get some data.
-- 
Robin Becker
More information about the Python-list mailing list