A related issue. Besides canonicalization __new__ and __init__ frequently create properties like aliases to different args (e.g. self.arg = args[0] for some functions).
A workaround is to move these to @property decorated getters. My first thought was that this issue supports Aarons statement that one can not mix these two approaches together (the current core and rewrite rules). However another probably useful thing can be deduced: that the current constructors mix together (complect ;) infrastructure related stuff (like creation of aliases) and math related stuff (like canonicalization). On 2 November 2012 21:21, Matthew Rocklin <[email protected]> wrote: >> 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. -- 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.
