Discussion: new operators for numerical computation

Huaiyu Zhu hzhu at knowledgetrack.com
Fri Jul 21 21:32:41 EDT 2000


On 21 Jul 2000 11:53:36 +0200, Konrad Hinsen <hinsen at cnrs-orleans.fr> wrote:

[Excellent points about the need to limit choice of operators, need to avoid
"line-noise" operators, and need to avoid confusions omitted]

>Another point to consider is implementation. In the current Python
>implementation, every operator must be implemented by a special method
>(or subroutine for C types). This can quickly become messy. There are
>other possible arrangements (e.g. all matrix operations could be
>mapped to a.__matrix_op__(b, op_code)), but it is in any case better
>to keep the number of new operators to a minimum.

Is op_code hard coded?  Maybe we need to start an implementation thread soon? 

>For "matrix solve", I propose to follow APL and define it in the sense
>of a least-squares solution, implemented via singular value
>decomposition (SVD). There are two reasons for this:
[snip]

Maybe the algorithm specs should go into the packages instead of operators?
The same algorithm is unlikely to be optimal for all types of matrix
classes, sparse, symetric, tridiagonal, complex, positive definite, etc.  If
these are implemented as subclasses of matrices, should they be allowed to
choose the algorithm?

Huaiyu




More information about the Python-list mailing list