> When you say you "want none". Do you mean you want objects that don't do *any* simplification on creation?
When working by hand I will almost always want simplification and I will always want verification. There are times when my algorithms want to work on a completely inactive expression tree though. In these cases it's a pain when the tree suddenly shifts on its own. It makes it very hard to successfully reason about algorithms. There are times when I may not even want verification either for performance reasons or because I actually break the rules temporarily. **I** the human user want simplification but sometimes my automated tree munging algorithms do not. On Fri, Nov 2, 2012 at 2:22 PM, Brian Granger <[email protected]> wrote: > When you say you "want none". Do you mean you want objects that don't do > *any* simplification on creation? The informal idea I gave it not that > different from this because the only simplifications that *everyone* will > *always* want are pretty minimal - not far off from none. When we wrote > `sympy.physics.quantum` for example we essentially do nothing on object > creation. There are only a handful of exceptions. > > I do agree with you that rules provide a very nice way of transforming > expressions and that much of the work done in sympy could probably be > replaced by rules, performance not withstanding. > > > On Fri, Nov 2, 2012 at 12:16 PM, Matthew Rocklin <[email protected]>wrote: > >> I'm experimenting with a different system in MatrixExprs. I'm not yet >> advocating that it be used elsewhere. I will advocate for experimentation. >> >> I like your two points. My definition of "evaluations/simplifications >> that everyone will always want" is probably a lot stricter than what >> usually occurs in SymPy so from my perspective a lot of the Expr code is >> broken. My perspective isn't the only valid one though, we have lots of >> different opinions. It's going to be hard to find a single one that >> everyone agrees on. Something like rules allows a bit more flexibility to >> select the degree of automation that you want. I want none (and I think I >> can do some pretty amazing things if you give this to me), the average >> non-developing user probably wants a lot. There is a tension here that I >> think the idea of rules might eventually resolve if it proves to be a good >> idea. >> >> Anyway, for the moment I like the "lets use rules freely in an isolated >> space" policy. I think it allows experimentation without mucking up anyone >> else. For all of the discussion about whether or not rules is a good or bad >> idea no one has actually reported a bug or bad experience. I've been pretty >> careful to not touch the core or any peripheral module other than >> MatrixExprs. >> >> >> On Fri, Nov 2, 2012 at 2:07 PM, Brian Granger <[email protected]>wrote: >> >>> In my mind in sympy we are using the following guidelines to determine >>> what gets done at object construction: >>> >>> * By default only do evaluations/simplifications that everyone will >>> always want. >>> * Rely on methods like, expand, rewrite, doit, etc. to actually trigger >>> additional simplifications/evaluations. >>> >>> I would much prefer this to us starting to create multiple >>> implementations of everything. >>> >>> >>> On Fri, Nov 2, 2012 at 11:54 AM, Aaron Meurer <[email protected]>wrote: >>> >>>> I think we are going to constantly have this battle between things >>>> being unevaluated and evaluating them (at construction time) as long as we >>>> try to do both with the same class. It's a similar issue as >>>> http://code.google.com/p/sympy/issues/detail?id=1887. If you are >>>> conflicted between wanting something to do two things, instead of arguing >>>> about which it should do, maybe the best solution is to just make two >>>> classes. In this case, it means that we need a user-level class Trace that >>>> does the autosimplification at construction time, and another class that >>>> represents an unevaluated trace that you can use to build your unification >>>> rules, or as intermediaries of matrix transformation rules, or whatever. >>>> >>>> This is the same thing as I was saying in the rules PR about need two >>>> classes (https://github.com/sympy/sympy/pull/1560#issuecomment-9640562, >>>> and also the next two comments). >>>> >>>> Of course, you could also try to represent things just using Symbols. >>>> This is like my original suggestion of an identity rule that represents >>>> sin(x)**2 + cos(x)**2 = 1 as the equation with Symbols s**2 + c**2 = 1 and >>>> the mapping {s:sin, c:cos}. Creating unevaluated classes may be cleaner in >>>> the long run, but trying to do it with the classes without creating >>>> unevaluated versions will just be a constant battle and will never work. >>>> >>>> Aaron Meurer >>>> >>>> >>>> >>>> On Fri, Nov 2, 2012 at 9:51 AM, Stefan Krastanov < >>>> [email protected]> wrote: >>>> >>>>> Given the comments of both of you I propose the following addition >>>>> (isolated to the rules module in order not to cause too much arguing): >>>>> >>>>> - adding a gather_rules function that traverses the tree and checks >>>>> for any rules registered with the objects. For instance >>>>> my_very_special_matrix object will have the following property >>>>> >>>>> my_very_special_matrix.rules_register = {'simplify': >>>>> [the_rule_square_is_identity,]} >>>>> >>>>> and trace will have >>>>> >>>>> Trace.rules_register = {'canonicalize': [trace_unpack_scalar, ]} >>>>> >>>>> This will be slow, but it will permit great freedom. We can optimize >>>>> it later. >>>>> >>>>> It will also work with the ugly idea that I had about calling all the >>>>> constructors. >>>>> >>>>> ClassUnsupportedByRules.rule_register = {'canonicalize': >>>>> [call_the_constructor, ]} >>>>> >>>>> On 2 November 2012 16:42, Stefan Krastanov <[email protected]> >>>>> wrote: >>>>> >> How do you get Matrix => scalar? >>>>> > very_special_matrix**2 is equal to scalar*Identity. The scalar is >>>>> > (should be) factored out of the Trace. >>>>> > >>>>> >>> points to consider: >>>>> >>> >>>>> >>> 1. I want to use only the following custom rule: >>>>> >>> very_special_matrix_a**2 -> scalar*Identity >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >> 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. >>>>> > >>>>> > The way that trace works is not based on canonicalization in the >>>>> > constructor (or at least when it is fixed it wont be) hence my >>>>> > disagreement with your comment and Ronan. >>>>> >>>>> -- >>>>> 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. >>>> >>> >>> >>> >>> -- >>> Brian E. Granger >>> Cal Poly State University, San Luis Obispo >>> [email protected] and [email protected] >>> >>> -- >>> 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. >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > [email protected] and [email protected] > > -- > 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.
