> > > My knee-jerk reaction is that this is a bad idea and that > > canonicalization done by the rules should have nothing to do with > > autoevaluation, unlike what the core does. Basically rules should not > > support the notion of autoevaluation. Let's leave the performance > > issues for later. > > I don't see this as a performance issue. I see it as a invariance > issue. If you create an object without its constructor, it loses any > invariants it was supposed to have. To me, it shouldn't even be a > rule, because it should never not happen. >
One fundamental disconnect between rules and autoevaluation in the core is that in the core invariants are enforced by construction logic while in rules they are enforced by external small functions which are generally (but not necessarily) called at construction time. This makes them optional (dangerous) but increases malleability and reuse. For example Aaron I think that the question you posed on my post about unification<http://matthewrocklin.com/blog/work/2012/11/01/Unification/>is relevant here. Unification wants access to those invariants but it also needs to operate on the tree without it shifting mid-flight. I think that this separation enables some very cool techniques. This is a digression from this topic though. > > > However this brings another issue, which made me write this. If you > > agree with me on the previous points, how will you implement the > > following: > > > > my_simplification_function() - a function that looks in the tree and > > if it finds a Trace(very_special_matrix_a**2*stuff) returns > > scalar*Trace(stuff). > > How do you get Matrix => scalar? > > > > points to consider: > > > > 1. I want to use only the following custom rule: > > very_special_matrix_a**2 -> scalar*Identity > > > > 2. Trace will not be autoevaluated, so my rule will not factor out the > > scalar out of the trace and will not remove the identity. How do I > > implement a rule that does this. Doing it in my rules is not > > appropriate as this should have already been implemented for the Trace > > and MatMul classes. The question is, how to get a general rule that > > does those already implemented canonicalization. It is basically what > > autoevaluation does. How do I get the object specific canonicalization > > rules? > > Why is Trace not auto evaluated? I suppose you're creating it via > Basic__new__ rather than the Trace constructor? This is getting to the > issue that Ronan foresaw in the original pull request. Basic.__new__ > seemed ok to me, but only to create the original object. Using it to > create new objects instead of their constructors is a bad idea. > Trace shouldn't require the constructor to operate correctly. See my above post. > > > 3. How do I add the my_simplification_function to the simplify > > function. _eval_simplify() does not work for this, because the objects > > that need to be simplified are inside a very generic container. What > > about creating a full_simplify function that first lists all nodes, > > ask the nodes whether they want to supply new simplification functions > > and then call > > simplify(chain(*newly_supplied_rules)(expr)) > > I guess there will have to be some kind to registry somewhere. Whether > that is in the container's _simplify method or somewhere in simplify() > we will have to decide. > Yar. Good question. -- 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.
