Le jeudi 05 mai 2011 à 10:27 -0400, Haz a écrit :
>         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).

If you mean something like
https://github.com/rlamy/sympy/tree/refactor-assumptions , it can be
done, but doesn't buy us much.

>   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).

That's very much a hack. It makes top-level calls behave differently
from inner calls, in a way that's hard to control. It's still wrong if
assumptions change within a top-level call. And, since it uses global
state, it'll break down completely in presence of threading (the rest of
sympy isn't likely to be thread-safe either, though) or if an exception
is raised.

>   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)
> 
For the syntax, see http://code.google.com/p/sympy/issues/detail?id=2338

>   I'm sorry I derailed the conversation into discussion on the cache
> (I do feel that the above approach is appropriate).

I think that the cache is a critical roadblock, so it's a good thing
that we discuss it.

-- 
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.

Reply via email to