On Sun, May 1, 2011 at 12:30 PM, Tom Bachmann <ness...@googlemail.com> wrote: > > > On 30 Apr., 23:41, "Aaron S. Meurer" <asmeu...@gmail.com> wrote: >> On Apr 30, 2011, at 1:24 PM, Ronan Lamy wrote: >> >> >> >> > Le samedi 30 avril 2011 à 13:36 -0400, Haz a écrit : >> >> So a few things to respond to... >> >> >> Tom: >> >>> Can you describe what went wrong with these branches? In particular, >> >>> why can the following naive strategy not work: >> >> >>> 1. Make the new system at least as good as the old one. That is >> >>> whenever I can write foo.is_bar I can write ask(foo, Q.bar) and I >> >> will >> >>> get at least as good an answer. In particular Symbol('x', >> >>> positive=True) should register automatically in the global >> >> assumptions >> >>> that x > 0 (if I understand correctly how the new system works...). >> >>> 2. Replace all queries foo.is_bar by ask(foo, Q.bar). >> >>> 3. Remove all implementations of the is_bar properties. >> >>> 4. Remove all remaining remnants of the old system. >> >> >> This is what was largely tried with a branch last summer: >> >> -https://github.com/haz/sympy/tree/disconnect-assumptions-2 >> >> >> There was push-back from the community since removing the >> >> Symbol('x', positive=True) syntax was largely frowned upon. >> >> > As I recall, the problems were that it was slow and broke a lot of >> > things. Symbol(x, positive=True) is easy to hack back in. >> >> >> Vinzent: >> >>> I think the only problem could be that ask() is much slower for >> >>> trivial queries, needs to be verified. This should be not too hard to >> >>> fix though. >> >> >> I don't think this is the case. Trivial queries (those that already >> >> have obvious implications) are compiled into quick reference >> >> dictionaries. In particular: >> >> -https://github.com/sympy/sympy/blob/master/sympy/assumptions/ask.py#L114 >> >> > I think that the problem is with non-trivial queries, for which that >> > code does nothing. >> >> >> In the end, everything in the new assumption system is done with a >> >> particular assumption context -- design decisions must be made on >> >> which context is used in the ambiguous cases. There is also an issue >> >> (feature request) that makes things more natural that will be worked >> >> on after the assumptions shift has taken place -- things like the >> >> following would be possible: >> >> >> with <some assumptions on variables>: >> >> <do stuff> >> >> >> This gives the assumptions an explicit local scope. The branch from >> >> last summer was mostly filled with fixing test cases so they used the >> >> new assumption system (with the global assumptions), and then cleaned >> >> up after themselves. >> >> >> It should also be emphasized that it isn't just a simple notion of >> >> cleaning up assumptions after yourself -- the cache interacts in quite >> >> an intertwined way. Under the right assumptions, expressions will be >> >> simplified, and variables will be assigned certain values. If that's >> >> stored in the cache, changing any related assumption will invalidate >> >> the result. For this reason, I had to manually clear the cache on a >> >> regular basis. I think that the cache is only really needed for >> >> lengthy solve algorithms (so you don't recompute an expression over >> >> and over), in which case we can probably wipe it after any sympy >> >> command is invoked (i.e., only use the cache while sympy is computing >> >> things, and then flush it just before returning the result). However, >> >> the branches from last summer never made it this far. >> >> > The cache is the source of a lot of problems. We should try to use it as >> > little as possible, even if it's not really possible to remove it at >> > this time. >> >> If a specific algorithm is slow without the cache, I think it should be >> rewritten to not do duplicate calculations. >> > > Why? For example in gruntz, the performance depends quite a lot of > caching mrv computations, limit computations, and order computations. > Since these hardly arise in a controlled manner, the only way I can > see to not recompute is to roll a separate cache - what would be the > point of this? > > IMHO we should definitely keep the cache. When something breaks it, it > is ill-designed.
Because the cache is a source of tons of our problems with sympy. Very hard to debug problems. Designing an efficient and robust cache is a highly nontrivial task. So if gruntz needs it, then it should use it's own private cache, until we figure out a better algorithm, that doesn't need it. The core of sympy should not use any cache however. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.