From: Paul F D. <pa...@pf...> - 2002-03-08 16:24:41
|
To sum up my previous postings: I prefer the "constructor" notation, not the funny-attribute notation. However, I believe an efficient matrix class can be done in Python on top of a numeric array object. Shadow classing just doesn't seem to be an overhead problem in most cases. The coding for MA is very complicated because of its semantics are so different; for Matrix it would be much less complicated. When I designed Basis (1984) I was faced with the operator issue. The vast majority of the operations were going to be elementwise but some users would also want matrix multiply and the solution of linear systems. (Aside: a/b meaning the solution x of bx = a, is best calculated not as (b**-1) * a but by solving the system without forming the inverse.) My choice was: matrix multiply and divide were *!, /!. This was successful in two senses: the users found it easy to remember, and you could implement it in the tokenizer or just in the grammar. I chose to make it a token so as to forbid internal spaces, but for Python it could be done without touching the tokenizer, and it doesn't use up any new symbols. Symbols are precious; when I designed Basis I had a keyboard map and I would cross out the keys I had "used up". If I were Guido I would be very reluctant to give up anything valuable like @ for our purposes. One should not have any illusions: putting such operators on the array class is just expediency, a way to give the arrays a bit of a dual life. But a real matrix facility would have an abstract base class, be restricted to <= 2 dimensions, have realizations including symmetric, Hermitian, sparse, tridiagonal, yada yada yada. Another aside: There are mathematical operations whose output type depends not just on the input type but some of these other considerations. This led me to believe that the Numpy approach is essentially correct, that the type of the elements be variable rather than having separate classes for each type. |