Random failure in matrix_integer_dense.pyx

[vbraun]

sage -t --long src/sage/matrix/matrix_integer_dense.pyx
**********************************************************************
File "src/sage/matrix/matrix_integer_dense.pyx", line 4108, in sage.matrix.matrix_integer_dense.Matrix_integer_dense._solve_iml
Failed example:
    t < 10 or t
Expected:
    True
Got:
    13.89298391342163
**********************************************************************
1 item had failures:
   1 of  23 in sage.matrix.matrix_integer_dense.Matrix_integer_dense._solve_iml

CC: @jdemeyer

Component: linear algebra

Keywords: random_fail

Issue created by migration from https://trac.sagemath.org/ticket/19380

[jdemeyer]

comment:1

Well, it passes if the machine is not under extremely high load...

If you really want the doctests to pass always, the only option is removing the test.

[vbraun]

comment:2

Why do we need a timeout different from the doctest timeout? Its not a benchmark, we just want to know if abort works or not. And doctests are totally unsuitable for benchmarks anyways, as can be seen here.

[jdemeyer]

comment:3

Replying to @vbraun:

Why do we need a timeout different from the doctest timeout?

That's too long.

You have a find a time T such that

1. no machine can finish the actual computation in less than time T
2. every machine can process the interrupt in at most time T

And doctests are totally unsuitable for benchmarks anyways

It's not meant as benchmark, it's meant to show that interrupts work.

[vbraun]

comment:4

There are two different times. I'm talking about the t < 10, not the alarm(2). The former unnecessarily duplicates the doctest timeout. Your 1. is referring to the latter.

[jdemeyer]

comment:5

Replying to @vbraun:

There are two different times. I'm talking about the t < 10, not the alarm(2). The former unnecessarily duplicates the doctest timeout. Your 1. is referring to the latter.

No, because I want to test that the function was actually interrupted. If some function takes 5 seconds to run, then it will always take at most 5 seconds to "interrupt", even if the interrupt doesn't work.

[vbraun]

comment:6

But the output would be different; If the function runs to completion it shows the actual output and the AlarmInterrupt would come later. So the doctests already tests that the function was successfully interrupted even without the t<10

[vbraun]

comment:7

Another one:

sage -t --long src/sage/matrix/matrix_integer_dense.pyx
**********************************************************************
File "src/sage/matrix/matrix_integer_dense.pyx", line 4108, in sage.matrix.matrix_integer_dense.Matrix_integer_dense._solve_iml
Failed example:
    t < 10 or t
Expected:
    True
Got:
    13.529191970825195
**********************************************************************
1 item had failures:
   1 of  23 in sage.matrix.matrix_integer_dense.Matrix_integer_dense._solve_iml
    [570 tests, 1 failure, 54.32 s]

[vbraun]

comment:8

Another one:

sage -t --long src/sage/matrix/matrix_integer_dense.pyx
**********************************************************************
File "src/sage/matrix/matrix_integer_dense.pyx", line 4108, in sage.matrix.matrix_integer_dense.Matrix_integer_dense._solve_iml
Failed example:
    t < 10 or t
Expected:
    True
Got:
    19.849074125289917
**********************************************************************
1 item had failures:
   1 of  23 in sage.matrix.matrix_integer_dense.Matrix_integer_dense._solve_iml
    [570 tests, 1 failure, 58.04 s]