Disclaimer the 100x time difference between auto-evaluation and just checking probably doesn't carry over to normal sympy. My evaluation system isn't nearly as optimized.
On Wed, Apr 10, 2013 at 7:52 AM, Matthew Rocklin <[email protected]> wrote: > Matrix expressions has been a testbed for these ideas. I'll share the > experience relevant to this conversation here. > > Currently matrix expressions construction works as follows: > > Construction with a class does, at most, type and shape checking. E.g. > MatAdd(X, X, Y) checks shapes and then returns X + X + Y. > > A set of obvious, you-will-always-want-to-do-these simplifications are > implemented in the .doit() method. E.g. MatAdd(X, X, Y).doit() returns 2*X > + Y. > > Syntax operators like __mul__, __add__, .T (for transpose) all call the > doit method. E.g. > > def __mul__(self, other): > return MatMul(self, other).doit() > > But internal methods might choose not to. In particular, this can help > with performance. > > Checks like shape-checking can actually be turned off if you're confident > that your code won't introduce any mistakes. Here are some timings > > In [5]: timeit MatAdd(X, X, Y).doit() # auto-evalutation > 1000 loops, best of 3: 441 us per loop > > In [6]: timeit MatAdd(X, X, Y) # just checking > 100000 loops, best of 3: 4.81 us per loop > > In [7]: timeit MatAdd(X, X, Y, check=False) # no checking > 1000000 loops, best of 3: 1.45 us per loop > > In [8]: timeit Basic(X, X, Y) # best we'll ever do > 1000000 loops, best of 3: 683 ns per loop > > Fancy simplifications are put into small functions and are intended to be > used by some kind of refine function. I'd like refine to eventually take > an objective function so that it can pick and choose which to perform. A > design goal is to have normal MatrixExpr classes not preform > simplifications that require assumptions. These should be in refine code. > > > > On Wed, Apr 10, 2013 at 5:57 AM, Stefan Krastanov < > [email protected]> wrote: > >> I am definitely in favor of this idea. A lot of examples of problems >> with autosimplification can be found on the strategies/rewrite_rules >> pull requests and forum discussions. >> >> On 10 April 2013 12:18, Tom Bachmann <[email protected]> wrote: >> > This mail is not directly related to removing the old assumptions, but >> > rather to the next steps after that. >> > >> > One issue that comes up every now and then seems to be that we dislike, >> in >> > general, automatic simplification (and automatic evaluation). >> > >> > Autosimplification uses the old assumptions system. For example. >> > >> > In [1]: x = Symbol('x', positive=True) >> > In [2]: abs(x) >> > Out[2]: x >> > >> > refine is the "new approach", using new assumptions: >> > >> > In [3]: abs(y) >> > Out[3]: │y│ >> > In [4]: refine(abs(y), Q.positive(y)) >> > Out[4]: y >> > >> > There is also the unify/ module, which I know nothing about. >> > >> > >> > Once the old assumptions system has been replaced by the new one, the >> > following question comes up naturally: in what form do we re-use the >> (still >> > existent) autosimplification code? >> > >> > For example, we could implement a function which does "refinement using >> > autosimplification": >> > >> > def autorefine(expr, facts): >> > with assuming(facts): >> > re-build the expr tree >> > return the new version >> > >> > This seems like a good idea mid-term, but now we have refinement code >> > scattered through all the classes, and some refinement code separate. >> This >> > seems suboptimal. What should the long-term strategy be? >> > >> > It seems to me that, eventually, the separate refine code should be so >> easy >> > to write that all of the autosimplification can be transcribed with >> > reasonable effort. Once we are there, we can remove the >> autosimplification >> > code, and make autosimplification optional (i.e. we can implement some >> > mechanism to optionally automatically refine newly created objects). >> Most >> > sympy modules will likely break with autorefinement disabled, but one >> has to >> > make a start somewhere. In particular, now all the modules can >> transition at >> > their own pace, and some might decide never to do it. >> > >> > Does this seem like a reasonable description of the consensus on >> > autosimplification? >> > >> > Thanks, >> > Tom >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "sympy" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to [email protected]. >> > To post to this group, send email to [email protected]. >> > Visit this group at http://groups.google.com/group/sympy?hl=en-US. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/sympy?hl=en-US. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
