On Wed, Aug 7, 2013 at 1:56 PM, Ondřej Čertík <[email protected]> wrote:
> On Wed, Aug 7, 2013 at 1:38 PM, Gilbert Gede <[email protected]> wrote:
>> Yeah, in the PR Aaron pointed out there is some code profiling I pastebin'd
>> in the comments.
>> I haven't gotten around to implementing the expand functionality yet - I
>> still had some questions for you Aaron. When you sugessted we promote
>> _expand_hint() to a user-level function, what did you mean by that (other
>> than removing the leading _)? Would there be any other changes to that
>> method?
>>
>> Also, is there any problem with putting @cacheit before many of the
>> Derviative methods, including __new__()? I did so, and it made the
>> linearization code run in 40% of the original time, and the tests seem to
>> still pass... Is there a reason cacheing isn't used more frequently?
>
> The problem with caching is that we would need to implement something
> like LRU cache, but our caching, as far as I know, is only a dictionary,
> which will keep growing. Historically, we had other problems with caching,
> like if it caches the assumptions wrong, then some tests run when you run
> them individually, but fail when you run them as part of the whole test suite.
> Etc. --- there is lots of problems with caching.
I guess we need to use an OrderedDict. Or maybe there's an even better
data structure. The question is, how often do we clear it? Do we base
it on number of items or size in memory (apparently it's more or less
impossible to get an accurate prediction of how large something is in
memory, not to mention that you have to take Python refcounts into
account). I think it's better to do what I suggest below.
Nowadays, the issues with caching is that things implicitly assume
that the cache is enabled, and so they fail when the cache is off. For
example, you might do an "is" comparison instead of "==", and it works
because of the cache.
>
> That being said, caching
> is of course some times very useful, as you pointed out. So we should
> make it possible
> to use caching when you need it. But I'd be a bit careful before
> decorating the whole sympy
> with @cacheit.
>
> Ondrej
As we discussed with Tom's GSoC project, I think what we need are
local caches, that are only used for single computations, but are
cleared in between. That way, you don't have memory blow up, but
operations that are heavily redundant and rely on caching for speed
can still be fast (for example, the Gruntz algorithm). I think it
should be like a context manager
with Cached:
high_level_function()
which keeps the cache used by @cacheit, but at the end, it is cleared.
high_level_function() is some high level operation, probably just one
level lower than the user-level, for which you know there will be a
lot of repeated calls within that operation, but there will be much
fewer of the same calls outside it. For example, if you wanted to
cache limit(), it would be something like
def limit(expr, x, x0):
with Cached:
_limit(expr, x, x0)
@cached
def _limit(expr, x, x0):
# The actual algorithm goes here, and all the sub algorithms also
have @cacheit
One could also quite easily use this to implement multiple,
independent caches (although I'm not sure right now why you'd want
to...).
Aaron Meurer
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/groups/opt_out.
