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 > > 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 <ness...@googlemail.com> wrote: > On 1 Mai, 20:45, Haz <christian.mu...@gmail.com> 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 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. > > > > -- > 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. -- 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.
