Le jeudi 05 mai 2011 à 11:25 -0700, Ondrej Certik a écrit : > On Thu, May 5, 2011 at 9:29 AM, Aaron Meurer <asmeu...@gmail.com> wrote: > > On Thu, May 5, 2011 at 8:27 AM, Haz <christian.mu...@gmail.com> wrote: > >>> Well as far as I understand the problems wrt caching and assumptions in > >>> the current model are: > >>> 1) Assumptions are tied in at the lowest level of the core (which > >>> apparently is a problem; I am just accepting that as a fact of life for > >>> now). > >>> 2) If we remove assumptions from objects entirely the cache breaks down. > >>> (Apart from there not being a viable transition strategy, as far as I > >>> see.) > >>> 3) There are certain hacks to fix this like flushing the cache > >>> aggressively, but they remain hacks. > >>> 4) At any rate the cache causes lots of headaches and there are calls for > >>> disabling it in general. > >>> 5) But that won't work either because our performance depends crucially on > >>> it for some computations. > >>> > >>> Having assumptions at a mix-in lower down in the algebra hierarchy solves > >>> (1) [I think], avoids the trouble with (2) and (3). Similarly having > >>> caching > >>> as a "mixin algebra" solves (4) without the hacks of (5). > >> > >> So what is the issue with this solution: > >> - > >> https://github.com/haz/sympy/commit/fb750ea49b963fa12d3a3e2dc833e53931050160 > >> I don`t see it as too hackish, since it simply shifts the use of the > >> cache > >> from being always on to being used for a single calculation. The solution > >> in > >> the branch from last year was indeed more of a hack (flushed the cache > >> whenever an assumption was added or removed from the global assumption > >> context). If the above solution is adopted, this deals with 2-5 (as far as > >> I > >> can see). > >> The big questions that remain are those involving (1): it is generally > >> accepted that the old assumption system should give way to the new one, but > >> to what extent we remove the old ones from the core? How the new ones > >> replace the old ones? What is the syntax that we will use for them? What > >> "assumptions" will we make about the assumption system? (i.e., local -vs- > >> global context by default) > > > > Well, one of the biggest problems with having the assumptions in the > > core is that any time you want to edit the assumptions you have to > > edit the core. Having them separate should make them much more > > extensible. > > > > Also, maybe I am wrong, but I think it would be easier to have > > something like Ask(expr, Q.whatever, Assume(x>y)) with the new system. > > At any rate, this sort of things cannot be done with our current > > is_assumption system (how do you assume x>y using that?). > > > I think that the biggest problem is that the assumptions are standing > in the way to optimize the speed of the core. Ginac doesn't use any > assumptions, neither does csympy (http://github.com/certik/csympy). > Since Sage shows that it is not needed, we should follow the same > route. And figure out some way to use assumptions in addition to the > core somehow.
It's hard to compare between systems with different design philosophies, and even harder to compare a real system with a toy system. Sympy shows that coercing all the time isn't needed. Does that mean that Sage should get rid of coercions? I still don't know how exactly the old assumptions prevent us from optimising the current core, though I do have ideas to improve it (use dicts for commutative expressions, clear up the overhead of expand()). Is there any possible improvement (not redesign) of the current design that is impossible because of assumptions? -- 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.
