[PEP draft 2] Adding new math operators

[Gregory Lielens]

Konrad Hinsen wrote:
[snip]
> >    - The shadowing class cannot replace a true class, because it does not
> >      return its own type.  So there need to be a M class with shadow E class,
> >      and an E class with shadow M class.
> 
> I don't quite understand this. In practice, the two classes would be
> an "array" and a "matrix" class. Both would be standard classes with
> constructors etc., there is no need for a special "shadow" class with
> different behaviour. Array objects would have an attribute called
> "matrix" whose value is the equivalent matrix object, and vice versa.

As I understand it, Huaiyu is saying that within a particular package
(lets choose Matpy, oriented toward matrix behavior), the all operations
must return matrix type (or array type, within NumPy), regardless of the
type of the operands. The type of operands will only be used to indicate
what the behavior of the operators is, but not to indicate the type of
the result. In this sense, within MatPy, array type will be a "shadow"
type, which should exist only after creation but disapear when any
operation is applyied, e.g.


A -> matrix
B -> matrix
A.E -> array
A.E*B -> matrix 
A.E*B.E -> matrix
sin(A.E) ->matrix
A.E.T  -> maybe matrix, or probably error (what is the elementwise
transpose? no idea!) 
A.T.E  -> array
A = B.E -> A should be a matrix (is it possible? I do not think so...)
and so on...(in NumPy, where array is the default, reverse the
behavior...)

This "non-persistent" (better than shadow?) behavior is preferable,
because one want to avoid backtracking the code to know the type of a
variable to know the meaning of an operation (At least, I would prefer
to avoid that :-))...
Such non-persitent behavior plead for operator distinction instead of
type distinction, imho, and the last example is the one which makes me
feel really uncomfortable about .E

Well, Huaiyu, if this is not what you mean by shadow class, please
correct me!
  
> I think this approach deserves a much more serious study, because it
> is much more "Python-like", and requires no syntactical changes.
> Lobbying for attributes on number types will be a lot easier than
> lobbying for new operators.

Yep, I agree...I hope this message qualify as a part of this study!


Greg.