-------------
Couldn't we have contagious immutability for matrix*matrix, contagious
mutability for symbol*matrix / matrix*symbol and sympification towards
immutable?
-------------
It does not sound good. Basic*Mutable and Mutable*Basic should always
behave in the same way independently of what subclass of Basic we
have
-------------
We have mechanisms to set policies for the following interactions
MatrixBase/MatrixBase interactions -- handled by "matrices.classof(A, B)"
Basic/Basic interactions -- handled by op_priority
Basic/ImmutableMatrix -- works because ImmutableMatrix is Basic and has
op_priority
Basic/MutableMatrix -- less easy - depends on Basic.__mul__(Mutable)
raising NotImplementedError
So what happens when you type
x = Symbol('x')
M = Matrix([[1,0], [0,1]])
x*M ?
Python first tries x.__mul__(M). x doesn't recognize M so it tries
M=sympify(M). This raises a NotImplementedError.
Python then tries M.__rmul__(x) which does the usual (correct) thing
because Matrices know how to deal with the situation.
Ideally we would like it to try M.__rmul__(x) first. This is usually
handled by op_priority which selects which operand should determine the
operation. Sadly op_priority only works for Basics. MutableMatrix is not
Basic.
-------------
To me, evaluation and immutability are completely separate. We should
have separate subclasses to do each (UnevaluatedImmutableMatrix is
probably better than ImmutableMatrix(evaluate=False)).
-------------
I agree that evaluation and immutability are separate. I think this is a
perfect reason not to couple them with a new subclass however. I don't
think we're talking about ImmutableMatrix(... , evaluate=False)), I think
we're instead considering MatMul( ... , evaluate=False). To me this seemed
like the natural way to solve this problem until Ronan warned us away from
it.
Here are some thoughts.
We could put some special logic into ImmutableMatrix.__add/mul__ to try to
evaluate ImmutableMatrix*anything operations by default. We would fall back
on creating MatMuls when we encountered other MatExprs that weren't
ImmutableMatrices. We could use the explicit syntax MatMul(X, Y) if we
wanted unevaluated ImmutableMatrix expressions.
I think this solves our short term problem in a minimally disruptive way.
However, I'm wary of it because we're building in one particular strategy
at a low level. It would be nice to separate the construction of an
expression with the simplification of it (this gets back to the AST and
canonicalizers discussion). There are really two valid reduction strategies
here. We don't currently have a mechanism in SymPy to deal with this other
than to subclass ad naseum. But, despite this concern I think this is still
probably the way to go for the short term.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
