For the large expressions that we see in `mechanics`, calls to `simplify` can take an extremely long time. However, for simple expressions, simplification is desirable. Currently we don't simplify by default inside any of our library code, as it's impossible to tell whether the expression can be reasonably simplified or not. If a `timeout` argument was added to such functions though, one could simply run
>>> simplify(expr, timeout=some_reasonable_max_time) and get the best of both worlds. However, this isn't the easiest thing to do in Python. The best *composable* option is to use signal.alarm, which is only available on *NIX systems. This can also cause problems with threaded applications. Checks for windows or not running in the main thread could be added to handle this though, but would limit it's use. --- A second option would be to implement a "pseudo-timeout". This only works for functions that have many calls, but each call is guaranteed to complete in a reasonable amount of time (recursive, simple rules, e.g. `fu`). The timeout won't be exact, but should limit excessively long recursive functions to approximately the timeout. I wrote up a quick implementation of this here <https://gist.github.com/jcrist/c451f3bdd6d038521a12>. It requires some function boilerplate for each recursive call that *can't* be replaced with a decorator. However, it's only a few lines per function. I think this is the best option if we were to go about adding this. Thoughts -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e970f287-3b1d-426a-bbb1-b5f7aeefdf29%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
