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?
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
