On 22.04.2013 12:10, 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?
Because, depending on how/when you rebuild the tree, you might be able
to skip some rebuilds (without jumping through equality checks. etc).
But this is very much a micro-optimization that might not even work,
so I guess it does not need to be discussed now. Sorry about
mentioning it.
Oh don't worry, it's good to hear all ideas :-).
The main reason why I prefer a more generic approach to caching is that
yours requires rewriting the flatten algorithm. In particular, flatten
does not call *itself* directly. It calls constructors etc which call
flatten internally, etc.
Of course, it might be a good idea to rewrite it in any case, but I'm
trying to not create more work than necessary (at least initially).
--
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.
