> I'll just raise an (open) question: how practically feasible would it > be to attempt to address this issue using the rewriting rule system > which is currently being developed? I don't expect anyone to have > definite answers, but I'd definitely be glad to hear opinions (perhaps > in a separate thread). > > The reason I ask this question is that, apparently, the functionality > in Mul and Add can be viewed as consisting of roughly two parts: one > which is quite general (like flatten), and we can actually see it > appearing in MatMul and MatAdd rules already, and the other one which > is more specialised and due to which matrix expressions cannot fit > into Expr. Therefore, I'm wildly supposing that it should be possible > to split Mul and Add into the corresponding halves, at least one of > which (the more general half) can apparently be done using rewriting > rules. > > Sergiu >
Most classes like Add, MatAdd, etc... do serve two purposes as you say. My names for these are as follows Container -- they act as a typed tuple and contain args Canonicalizer -- they take in different inputs like "x + y" and "y + x" and produce a normalized form Rules do strip out a fair amount of canonicalization and leave the classes as mostly just containers. You could use rules for everything and make the classes just containers. This is a question of programming style though, I don't think that it's objectively better or worse. If you wanted to do this I think you would just make a new project. SymPy has its own thing going on and it works pretty well. I've made a project that was based on just rules for matrix expressions. It was neat, I had fun, but I don't expect the world to suddenly decide that rules are how we should do things. Balance is healthy. Regarding "It's unfortunate that Expr can't support MatrixExpr." Actually, I disagree. Expr is effectively ScalarExpr. That's good. We should have different container classes for scalars and matrices. This makes writing a lot of code much more convenient. Example, it's really nice to assume that the additive identity is the number 0. We often type 0 when we actually mean "the additive identity". If we always had to use some object here that would be inconvenient. I think that having different classes for containers is good. Of course, canonicalization is likely to be very similar. The process of removing identities from Adds and MatAdds is pretty similar so it's nice if our canonicalization system is general. Rules provide this pretty easily. I have a function remove identity (rmid) in sympy/sympy/rr/rl.py remove_zeros = rmid(lambda x : x == 0) remove_ZeroMatrices = rmid(lambda x: x.is_Matrix and x.is_ZeroMatrix) These two rules are now ready to be introduced into a set of rules for canonicalization. -- 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.
