The first approach was hackish (actually both are, but the decorator way is 
*significantly* better). And I agree, I'm still not sure this a problem 
worth solving. Just food for conversation. I posted some timings on the 
decorator PR https://github.com/sympy/sympy/pull/8297

The core tests ran about 6% slower on my machine, but the long running ones 
ran only neglibly slower. The overhead of calling `_ask` without a timeout 
set is only ~70 ns on my machine. With one set it's more intrusive, due to 
the need to lookup the time. Polling is *not* the nicest approach to this, 
I fully agree.

On Thursday, October 23, 2014 1:23:07 PM UTC-5, James Crist wrote:
>
> 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/4e02bf63-6b16-4922-ad27-75074429185f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to