On Wed, Apr 10, 2013 at 2:14 PM, Tom Bachmann <[email protected]> wrote: > On 10.04.2013 17:55, Aaron Meurer wrote: >>> >>> What modules rely most heavily on caching? I know that series does >>> very much, and meijerint does to some extent. What about other modules? >> >> >> Let's not forget the most important module of all, the core. I know >> expand relies on the cache for most of its speed. I think it's used >> elsewhere in the core too. >> > > Oh my. Expand is always there to stop a party, isn't it. > > I'll take it into consideration. > > >>> >>> clear_cache will be True by default, and do what you think it does. >>> However, in the above situation, it is safe not to clear the cache, >>> since the dummy is fresh. I *think* this should solve most problems. >>> Indeed, this pattern always works when creating "fresh" symbols, and >>> so it works in all situations where the current assumptions are set up >>> (since we currently never allow to change them). >> >> >> That seems way too sensitive. People will either not use it, or use it >> incorrectly. O ey will use it incorrectly but then someone else will >> change the code in a way tag invalidates it without realizing it. >> > > True. Any strategy which relies on third parties to not flush our cache will > have issues like this. > > >>> Here new_local_cache is a context manager which creates and destroys >>> an entry in local_caches_dict. This kind of cache decorator is >>> tailored towards the use of caching in gruntz. Will it help in other >>> cases? >>> >>> >>> It seems to me that, under the general strategy outlined in my >>> previous mail, (4) and (5) seem essentially equally beneficial. (5) >>> feels slightly cleaner to me. >>> >>> What do you guys think? >> >> >> Perhaps what we really need is memoization. The difference between >> memoization and caching for me is that memoization is not global. So for >> example, we could memoize the gruntz algorithm, but at the end of each >> gruntz call, it would reset the cached values. > > > I assume with "end" of gruntz call, you mean the end of some recursive set > of gruntz calls. > > If so, how does what you say differ from what I described?
In my experience, caching bugs are very non-local. You do something and then much later, in a completely different calculation, something goes wrong. That's why the most annoying bugs are only reproducible by running the whole test suite (this doesn't happen any more because we clear the cache between test runs, but it happened a lot before that). If somehow the cache were cleared between "top-level" calls, it would fix this. And assuming the reason that the cache helps so much is that the same expression produces similar results, but it is the case that different expressions produce different results, then this shouldn't slow things down too much. For example, with expand(), common subexpressions are only expanded once, with the result cached (*). But a completely different expression is less likely to contain some of the same common subexpressions than different parts of the same expression. At least, that's what I'm hoping. (*) - expand() is a poor example for the current implementation because @cache it is on Basic.expand, but expand uses Basic._expand_hint to recurse through an expression. But assuming that _expand_hint were cached instead, it would work as I described it. I don't know much about gruntz, but my hope is that what I describes applies to it well. Aaron Meurer > > >> If the "cache" we're >> basically always reset between atomic operations, then these subtle >> issues of things affecting other things would go away. > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy?hl=en-US. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
