Oh, so it's not that bad. Still, there's no reason why this has to be implemented recursively. Not only will it avoid recursion error problems, but it will be faster if it's written non-recursively, as function calls in Python are somewhat expensive.
For example, look at the speedup I had rewriting a function deep in the polys to be non-recursive a while back by reading the commit message of 4cb7aa93601c16d26767858175d7b1b4c04e9fca. Aaron Meurer On Sun, Feb 12, 2012 at 11:45 PM, Chris Smith <smi...@gmail.com> wrote: >> In this particular case, it's determining if an Add is positive by >> peeling off one term at a time (see line 440 of add.py), which I think >> should be changed (not only is this needlessly recursive, but it's >> also inefficient, because it recomputes Add.flatten each time, making >> it a O(n**2) operation). > > If I'm not mistaken, it hasn't done this since about 4500 commits ago > :-) (SHA1 40853ad65801838c45b5). But it *is* recursive. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
