Le 09/04/2019 à 21:16, Jakub Wilk a écrit : > * Santiago Vila <sanv...@debian.org>, 2019-04-09, 15:32: >> AFAIK, this being a primality test, I assume the outcome is either >> "not prime" or "maybe prime", so the only way to test the test is by >> giving a known prime and expect "maybe prime" as output. >> >> So: Why is the test calling mr.test with 221, which is not prime? (221 >> = 13 x 17) > > Correctly implemented Miller-Rabin test should have false positives only > with negligible probability. > >> And why this fails randomly? Does the test perform random calculations >> internally and it's therefore not deterministic? > > Yes. > >> Even in such case I don't see how a non-prime like 221 may help to >> catch obvious errors in a test suite for a primality test. > > It's just proven to be useful. > > Please restore the test and fix the code instead. > > NB, it's been already reported upstream that the number of iterations > this implementation chooses in not adequate: > https://github.com/indutny/miller-rabin/issues/9
I think we could keep this patch for now to avoid FTBFS and reopened this bug with a lower severity (normal) to wait for upstream patch, do you agree ?
