Opened 5 years ago

Last modified 5 years ago

## #19380 new defect

# Random failure in matrix_integer_dense.pyx

Reported by: | vbraun | Owned by: | |
---|---|---|---|

Priority: | major | Milestone: | sage-6.9 |

Component: | linear algebra | Keywords: | random_fail |

Cc: | jdemeyer | Merged in: | |

Authors: | Reviewers: | ||

Report Upstream: | N/A | Work issues: | |

Branch: | Commit: | ||

Dependencies: | Stopgaps: |

### Description

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

### Change History (8)

### comment:1 Changed 5 years ago by

### comment:2 follow-up: ↓ 3 Changed 5 years ago by

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.

### comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 5 years ago by

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

- no machine can finish the actual computation in less than time
`T`

- 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.

### comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 5 years ago by

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.

### comment:5 in reply to: ↑ 4 Changed 5 years ago by

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.

### comment:6 Changed 5 years ago by

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`

### comment:7 Changed 5 years ago by

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]

### comment:8 Changed 5 years ago by

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]

**Note:**See TracTickets for help on using tickets.

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.