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.
But this is *exactly* what I am describing. I know a bit about gruntz
and not much about expand, but precisely what you are saying is going to
apply there.
That's a good sign, I suppose.
--
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.
