On 22.04.2013 10:54, Stefan Krastanov wrote:
What I can see is that flatten spends considerable amounts of time in things
which recursively call flatten *again* (i.e. things like a *= b). This seems
to indicate that it can probably benefit from memoization caching.
Or it might be simpler and as effective to have this half-baked-memoization:
def flatten(expr):
return _flatten(expr, set())[0]
def _flatten(expr, already_flattened):
for subexpr in expr:
if subexpr in already_flattened:
do nothing
else:
add flattened_subexpr to already_flatten
It does not memorize results, it memorizes what is already flat. And
it is the local type of memoization, but that is another topic.
Anyway, I am just making some noise, this is probably not any better
than usual memoization.
Why is this better?
Anyway, we can clearly try both. The advantage with the memoization
caching scheme I mentioned is that we can apply it as a kind of "recipe"
to many existing codepaths, and only individually tune things where
still necessary.
--
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.
