Exactly. It takes about 20 min. to get to the part of heurisch that
hangs on my computer, but that's where it eventually stays. If you
apply the following patch:
diff --git a/sympy/integrals/risch.py b/sympy/integrals/risch.py
index bb5f6c9..ed30e71 100644
--- a/sympy/integrals/risch.py
+++ b/sym
No it's hanging in heurisch.
(And in fact smichr already merged my fix - i.e. turning the test into
skip.)
On 23.01.2012 20:13, Aaron Meurer wrote:
Hmm. From what I remember, it was not hanging in the new algorithm,
but in heurisch(). This means that it probably would indeed finish if
you le
Hmm. From what I remember, it was not hanging in the new algorithm,
but in heurisch(). This means that it probably would indeed finish if
you let it run long enough, but that algorithm can be so inefficient
that there's no telling if it could be hours, days, weeks, ...
If it is indeed hanging in
Am 23.01.2012 09:14, schrieb Tom Bachmann:
Hm. Actually we knew when pushing that said test seems to never finish.
I once let it run for two hours, and it was consuming 100% of a CPU core
and didn't stop, so I'm pretty sure it's an endless loop.
I did some analysis but didn't retain the work
Hm. Actually we knew when pushing that said test seems to never finish.
I will submit a pull request that turns @slow into @skip.
Sorry for the inconvenience.
On 23.01.2012 01:28, Joachim Durchholz wrote:
Title describes the situation.
The problem was introduced in d491d48f80840f9e0bd38ed0
Title describes the situation.
The problem was introduced in d491d48f80840f9e0bd38ed0d7d2dfaba4bb
For me, this caused over an hour of
- a wild goose hunt for a nonexistent bug in what I was working on
- bisecting while not being sure whether it's just slow or hanging
Not happy because I spent
