Actual traceback looks like this:
sage -t --long src/sage/graphs/matchpoly.pyx
Timed out
**
Tests run before process (pid=22979) timed out:
sage: g = graphs.PetersenGraph() ## line 104 ##
sage: g.matching_polynomial() ## line
I ran the same
for i in `seq 0 1000` ; do sage -t --long src/sage/graphs/matchpoly.pyx ;
done
and most of the runs takes about 5 seconds but there are exceptionally long
runs. A typical one of them is:
sage -t --long --warn-long 75.3 src/sage/graphs/matchpoly.pyx
Timed out
Hi all,
Bill Hart has a nice writeup about the upcoming support for multivariate
polynomial arithmetic in Flint, which is being developed as part of
OpenDreamKit.
https://wbhart.blogspot.fr/2017/07/update-on-fast-multivariate-polynomial.html
Fredrik
--
You received this message because you
New blog post from Bill Hart. It includes a section claiming Sage’s
multivariate polynomial arithmetic speed is much worse than expected...
-- Forwarded message -
From: Bill Hart
Date: Sun, Jul 9, 2017 at 8:34 AM
Subject: [ODK participants] Blog post
I ran
for i in `seq 0 1000` ; do sage -t --long src/sage/graphs/matchpoly.pyx ;
done
and hangs after 30-ish iterations.
On Sunday, July 9, 2017 at 2:03:49 PM UTC+2, Eric Gourgoulhon wrote:
>
>
>
> Le dimanche 9 juillet 2017 07:10:37 UTC+2, Ralf Stephan a écrit :
>>
>> (5) Test manually not
Le dimanche 9 juillet 2017 07:10:37 UTC+2, Ralf Stephan a écrit :
>
> (5) Test manually not once but 10 times since the long runs may not happen
> in 100% of all runs
>
I did: all 10 standalone doctests of src/sage/graphs/matchpoly.pyx returned
"All tests passed" in 3.3 s each.
Moreover, the
I've recently added code to print enhanced tracebacks when we kill a test
due to timeout (#23208), if you have gdb installed then you'll get some
idea of what it was doing when it timed out. I've seen a few cases on the
buildbot that point to FFPACK::CharPoly. This might be a bug in linbox that
On Sunday, July 9, 2017 at 7:10:37 AM UTC+2, Ralf Stephan wrote:
>
> (5) Test manually not once but 10 times since the long runs may not happen
> in 100% of all runs
>
Could you ever reproduce the long run ("Timed out") by repeating standalone
testing?
I suspect the long run happens in the