On Nov 2, 2012, at 7:59 AM, Stefan Krastanov <[email protected]> wrote:

> There is one important performance enhancement that is not implemented
> in rewrite rules, namely autoevaluation. However here I am considering
> the "canonicalization" work done by the autoevaluation and I will
> imagine that performance is not an issue.
>
> I think that while the state of the code that implements it in sympy
> is bad, the notion itself is sufficiently well abstracted: in the
> core, autoevaluation is all that is done by the constructor of an
> object. This will be my definition of autoevaluation for the rest of
> the post.
>
> My question is, is it a good idea to add a very basic rule like
> call_constructor that traverses the raw tree created by Basic.__new__
> and that calls type(node)(args) in order to force the autoevaluation?
>
> 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.

>
> 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.

>
> 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.

Aaron Meurer

>
>
> Most burning for me is issue number 2.
>
> --
> 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.
>

-- 
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.

Reply via email to