The correctness of any algorithm should be unaffected by the cache -- so you would only see a (time) difference if repeated sympy commands use the cached results.
On Sunday, May 1, 2011, Aaron S. Meurer <[email protected]> wrote: > > On May 1, 2011, at 2:40 PM, Haz wrote: > This is the chunk that things get done > in:- https://github.com/sympy/sympy/blob/master/sympy/core/cache.py#L75 > > > <https://github.com/sympy/sympy/blob/master/sympy/core/cache.py#L75> Have a > global variable called working, and a local variable called first. Put this > at the top of wrapper: > first = False > if not working: working = True first = True > ...and just before returning anything: > if first: > > working = False clear_cache() # Or whatever equivalent is needed to > flush it out. > If I understand it correctly, this assumes that the cache is needed only > within calls of the outermost decorated function, but not between them. Does > this hold for the Gruntz code that uses the caching? > Aaron Meurer > > Essentially you only enable the cache for the time that sympy is computing > something. And yes, gruntz uses some assumptions during it's calculations, > but that is a rare case and can be handled with local assumption contexts or > cleaning the assumptions they use if it is global (which is how I handled it > last summer). > > > The only overhead this should impose is cleaning the cache at the end of a > computation -- minimal I would suspect. > On Sun, May 1, 2011 at 3:52 PM, Tom Bachmann <[email protected]> wrote: > On 1 Mai, 20:45, Haz <[email protected]> wrote: >> > > The example may sound contrived, but it does arise in practice, and was >> > a >> > > headache to debug. >> >> > Well there must be an end to it, right? Every assumption is about >> > symbols. Every symbol x that depends in any way on another symbol y >> > has y in its free_symbols. In fact any exrpession has all symbols it >> > depends on (recursively) in its free_symbols. Hence it would be enough >> > to pull all assumptions involving any free symbols into the hash >> > computation. >> >> > Right? [If not then one point in the above chain of argument must be >> > wrong; this is very well possible :-)] >> >> x may not depend on y if the right assumptions exist on y, and x is >> simplified. What you're suggesting may work if the hash is computed before >> the simplification occurs, but then you're bringing information about the >> equation into the hash before the equation is dealt with (and as Aaron >> points out, this could have some performance issues). >> > > I'm not sure I understand. The result of any given invocation of a > function should depend only on the arguments passed, and possibly on > assumptions on the arguments. If the assumptions are stored with the > arguments we are fine, if the assumptions are passed around > explicitely (as ondej suggests) we are fine, if the assumptions are > stored separately, they have to be pulled in. > >> But back to my original suggestion -- can anyone see something wrong with >> flushing the cache after a sympy command is invoked? The reason this has >> potential for solving the problem is because the assumptions aren't apt to >> changing while sympy is computing a result (only in between commands). This >> means the gruntz can still do its thing with the cache, etc. > > This still feels wrong to me. Firstly, how do you even define "after a > sympy command"? Sympy is a library with many entry opints (at least I > see it as such). > Secondly, even inside sympy assumptions can be changed. For example > the gruntz algorithm always (locally) adds an assumption to the > variable with respect to which the limit is being taken (it currently > uses a fresh Dummy, but with flexible assumptions in place this would > not be necessary). > > -- > 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. > > > > > > -- > 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. > > > > > > -- > 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. > -- 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.
