Open nbruin opened 11 years ago
Note that many of these algorithms benefit from a lower bound on the rank, and many compute such a bound. Since the rank also seems significant for determining reasonable cutoffs, perhaps this rank estimate should be pulled forward. It can then be passed as an optional parameter to the implementations, to prevent recomputing it.
Note that lines 3841 and 3859 in sage/matrix/matrix_integer_dense.pyx
read:
p = previous_prime(rstate.c_random() % (MAX_MODULUS-15000) + 10000)
which is much more expensive than p=previous_prime(p)
. Do we want to incur such a high cost for getting "true" pseudo-randomness? These are big primes. The probability that a real-world matrix leads to bad behaviour for, say, 5 consecutive primes is really astronomically small.
Presently, there are whole ranges of matrix sizes and ranks where the default heuristic for choosing an
echelon_form
algorithm for matrices overQQ
chooses the slowest choice possible:Timings are reported as
(classical,multimodular,padic)
withclassical
scaled to 1. These tests are all in the range where currentlypadic
is chosen as a default. These timings are all done on 5.3b2 + #12313 + fix of Thierry's code + un-randomization of prime choice inpadic
. Without #12313 one would run out of memory onpadic
and without the other ones, the timings of padic would be much worse:so it seems that the cross-overs could use some tuning. In particular, for non-maximal rank matrices it seems to take a while longer to overtake classical. It would be great if someone would be able to tune this code properly. It is very useful if sage would echelonize small matrices quickly over arbitrary base fields quickly in most most cases (and not make silly choices), because it allows linear algebra intensive algorithms in a base-field agnostic way.
See #13400, comment 29 for the context of some of the remarks about the conditions under which these timings were made. The essential problem reported in this ticket is quite independent of memory issues, though!
Component: linear algebra
Issue created by migration from https://trac.sagemath.org/ticket/13925