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.
