On 05.05.2011 17:35, Ronan Lamy wrote:
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.


Can you describe what you have done there? I had a look at the code but chances are I'm missing important points.

Why does this not buy us much? If I understand correctly you moved the assumptions logic to a mixin. This sounds like a first step to me to having swappable assumptions implementations, and indeed no-op assumptions if this is desirable.

   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.

I agree (quite strongly).

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

Reply via email to