Talk:Miller–Rabin primality test

message: Wouldn't it be much (well, at least a little, compared to the overall complexity) more efficient to store the value of s instead of shifting until we reach n-1 in the example Ruby code? I do not know Ruby, but it is safe to say that shifting the same values repeatedly is less efficient than storing the value of s in the calculation. Coolv(Talk • Contribs) 19:11, 15 June 2007 (UTC)
replies: text: I'd expect that your proposal would have a very small impact on the runtime, because shift operations are cheap compared to modular multiplication. But your proposal would possibly make the code easier to understand. E.g., it seems that even the author of the code was a little confused. The while loop computes all powers a^{2^r d} for all r\leq s while the Miller-Rabin test only calls for the cases with r\leq s-1. I'd further propose the following modifications: (1) the functions should not be called prime, since it is only a pseudoprimality test; (2) negative integers should not be declarde prime. 85.2.99.96 16:16, 4 July 2007 (UTC)
thread_title:  Ruby Code 

message: After reading the article I have the suspicion that some of the formulations are very
imprecise (or plain wrong :-)):
"Strong Witness": If I understand this correctly, it means that we found a number  x 
for which the following equations hold:
:
x \equiv a^{2^r\cdot d} \pmod{n} for some 0 \le r \le s-1
:
x \not\equiv -1\pmod{n}
:
x \not\equiv  1\pmod{n}
:
x^2 \equiv 1 \pmod{n}
To sum up:  x  is a non-trivial square-root of  1 \pmod{n} 
Are there any non-trivial square roots of 1, if  n  is a prime ?
If there are not, then I assume that "Strong Witness" would be better called "Sure Witness" for the
compositeness of  n . Fruther then at the beginning
"Let n be an odd prime, ...  Then, one of the following must be true for some a" it should be
"...  Then, one of the following must be true for EVERY a ..."
Is the above correct ?
213.70.137.66 17:49, 14 February 2006 (UTC)
replies: text: You're right that there aren't non-trivial square roots of 1 mod prime p. If x2 = 1 (mod p), then (x-1)(x+1) = 0 (mod p). If x is neither 1 nor -1 mod p, neither x-1 or x+1 is zero mod p, which means we have a nontrivial factorization of p, which is of course impossible. This is how we can claim that taking square roots repeatedly will either always yield 1 or eventually yield -1. In fact, as the pseudocode shows, any failure of the conditions proves compositeness. I've modified the article to read witness of compositeness rather than strong witness. You're also correct that it should say "for all a"; it is for composite numbers that it is only true for some a. Deco 18:24, 14 February 2006 (UTC)
replies: text: I've added the lemma about non-trivial square roots of 1 to the page. It's fairly obvious, but it doesn't hurt to spell out everything. Deco 18:53, 14 February 2006 (UTC)
thread_title:  Some imprecise (wrong) formulations ? 

message: 82.6.98.77, the result has been published in a respectable peer-reviewed journal, and as it is referenced by several other sources, it seems to be accepted by the community. If you disagree with the result, you cannot just slap a "this is wrong" notice, you have to bring forth convincing evidence. -- EJ 20:18, 27 April 2006 (UTC)
replies: text: Yeah, sorry for my stupid comment. EJ is correct, a must always be smaller than n. In fact, we specify that a\in \left(\mathbb{Z}/n\mathbb{Z}\right)^*, which excludes the possibility that a = 0 (mod n). I assume the result of Jaeschke takes this into account - not to say this doesn't deserve clarification. Deco 19:28, 8 June 2006 (UTC)

text: Why on earth do you test it only for a = 18? There are several deterministic variants of the test mentioned in the article, and none of the involves 18. The algorithm described by the pseudocode requires you to test all values of a from 2 to 2(ln 49)2 ≈ 30, the Pomerance, Selfridge and Wagstaff result tells you to test a = 2 and a = 3. Either way, 49 is declared composite, because it fails the test already for a = 2. — Emil J. 10:31, 7 July 2009 (UTC)
replies: text: I test it for all a from 2 to 30. With a=2, a^3=8 which is not congruent 1 nor -1 mod 49, 2^(2^1*3) mod 49 ≠ -1, 2^(2^2*3) mod 49 ≠ -1, 2^(2^3*3) mod 49 ≠ -1, so it not fail the test and it is a possible composite. If i continue testing with bigger a, when i reach a=18, the if statement is False, so the algorithm won't return composite. Thanks for the attention Kaluppollo (talk) 14:10, 7 July 2009 (UTC)
replies: text: You misunderstand the algorithm. Since 223·3 mod 49 ≠ ±1, the algorithm returns "composite" and stops, you do not continue with any further testing. — Emil J. 14:22, 7 July 2009 (UTC)
replies: text: sorry, you are right, i misanderstood it. thanks for the help Kaluppollo (talk) 21:47, 7 July 2009 (UTC)

text: I see, that this is resolved. However, for future reference: some of the provided links tell you step-by-step what has to be calculated (and why) for any given number, e.g.: . Gulliveig (talk) 04:27, 11 September 2009 (UTC)

text: What you apparently misread is the condition for returning composite, which involves a^{2^r \cdot d} \,{\color{red}\not\equiv}\,{-}1 \pmod{n}. Is it true that a^{2^r \cdot d} \not\equiv-1 \pmod{n} for every r\in[0,2]? No, it is not, specifically it is false for r = 1, because its negation, a^{2^r \cdot d} \,{\color{Red}\equiv}\,{-}1 \pmod{n}, is true for this r. — Emil J. 14:47, 3 February 2010 (UTC)
replies: text: Thanks Emil.  Yes my walkthrough was completely and utterly bogus.  Funnily enough it turns out I'd managed to implement it right in software, but the real reason it was failing on n=41 was because of arithmetic overflow:  once it gets up to testing a=11, r=2, a^{2^r \cdot d} \pmod{n} is 38 if naively calculated using 64-bit finite precision arithmetic.  Using arbitrary precision arithmetic or a "modpow" to keep the range under control fixes the issue and correctly computes 40, avoiding a "composite" result.  I hadn't appreciated just how quickly that double exponentiation blows up!  --83.104.46.24 (talk) 00:25, 4 February 2010 (UTC)

text: The sets at http://miller-rabin.appspot.com/ are even better, and there is a rather obscure reference to that site in the text.  The base sets highlighted in the article are of historical interest and have been published in journals.  It is a little unfortunate that the more practically useful sets are not clearly pointed out. DAJ NT (talk) 06:33, 19 June 2017 (UTC)

text: The sets you mention use large composite numbers as a base set.  I decided to do an exhaustive search restricting the values of the base set to prime numbers. I don't know for sure that restricting them to prime numbers is important.  Heuristically speaking, adding two additional values to the base set seems to increase the smallest pseudoprime of the set by x100.  (200412882870661 is about 100 times greater than 1726021172851).  Given this, there might exist a set of 7 prime numbers that are sufficient to test all numbers less than 2^64.  Also, except for the first few, the base sets I list use small numbers (i.e. numbers less than 10000).  — Preceding unsigned comment added by 59.120.231.199 (talk) 08:44, 19 June 2017 (UTC)

text: I recently found a way to test any 32 bit integer (more specifically, an integer less than 4957839253) which certainly includes any 32 bit integer) using only two witnesses in the test.   Specifically 
if (num % 16 == 1) and num < 9758525617 use {5, 1013}  
if (num % 16 == 3) and num < 46493311411 use {2, 29} 
if (num % 16 == 5) and num < 4957839253 use {149, 443} 
if (num % 16 == 7) and num < 14856014167 use {2, 163} 
if (num % 16 == 9) and num < 5671240489 use {5, 647} 
if (num % 16 == 11) and num < 8749965451 use {2, 37} 
if (num % 16 == 13) and num < 9174782189 use {19, 149} 
if (num % 16 == 15) and num < 20574244687 use {2, 53} 
Fortunately, (num % 16) can easily be computed using a bit shift operation.
This also beats the two witness base sets mentioned at http://miller-rabin.appspot.com/  — Preceding unsigned comment added by 59.120.231.199 (talk) 09:38, 22 June 2017 (UTC)
replies: text:  I do not think that is correct. For instance, 1181 \times 3541 = 4181921 \equiv 1 \pmod{16}; however, that number is a strong pseudoprime for both 5 and 1013 bases. Anton Lapounov (talk) 00:25, 15 February 2022 (UTC)
thread_title:  Deterministic variants of the test 

message: We know 5 is a prime. So s=2, d=1 and n=5. Let's suppose a=4 (it's in the range 1-4) and r=1, since the case r=0 supports the primality. Then we have (1) 4^1 mod 5 = 4, so it is != 1
(2) 4^(2^1 *1) mod 5 = 1, so it is != -1 or 4.
Therefore, 5 isn't a prime? —The preceding unsigned comment was added by 84.159.42.147 (talk • contribs) 23:34, 14 July 2007 (UTC)
replies: text: For all r means for both r = 0 and r = 1. As you say, taking r = 0 already "supports the primality", hence whatever happens with r = 1 is irrelevant. -- EJ 08:40, 15 July 2007 (UTC)

text: The code example on RosettaCode did not properly implement the pseudocode.  The current pseudocode is similar to Cohen Algorithm 8.2.2.  It is similar to Crandall and Pomerance Algorithm 3.5.2 with a difference being the base from 2 to n-2 and the input > 3.  DAJ NT (talk) 17:36, 11 March 2016 (UTC)
thread_title: Broken Algorithm?

message: In an edit summary, User:EJ said: "The algorithm takes a in full Z/nZ (save the obvious exception a=0), because there is no simple way of generating a's coprime to n."
He's correct that the algorithm as it's normally formulated does not restrict a to a value coprime to n, but I think there is a simple way of generating such a: generate a random a, test GCD with n, and if it exceeds 1 return COMPOSITE, else continue. This isn't needed for correctness though, and provided the value n has (as is typical) been prescreened for small divisors, the chance of hitting a value sharing factors with n is so small as to make this not a useful optimization. Dcoetzee 19:57, 5 November 2007 (UTC)
replies: text: You're right that my edit summary was misleading. The actual reason why the algorithm does not restrict a to values coprime to n is that it is a pointless complication: the other a are all compositeness witnesses anyway (they do not need to be explicitly tested for, as the condition a^{n-1}=1\pmod n implies that a is coprime to n), and in fact, provide a factorization of n. And, as you say, they are too rare to make worrying about them worthwhile (which is, after all, one of the reasons why factoring is conjectured to be hard). -- EJ 10:44, 6 November 2007 (UTC)
replies: text: To make the last sentence less confusing: what I was trying to point out was that taking gcd with random numbers is a rather inefficient way of finding factors, it is better to try small divisors in order (if there is a realistic chance that n might have small factors at all). Anyway, forget about factoring, it's irrelevant to Rabin-Miller. -- EJ 11:32, 7 November 2007 (UTC)
replies: text: Yup. Dcoetzee 11:36, 7 November 2007 (UTC)

text: Correct me if Im wrong, but like the Fermat test, a non-coprime 'a' will fail the test anyway, so there is no point in checking for coprimality. As long as 'a' is less than 'n' then any 'a' indicating compositeness is truthfully doing so, regardless if it is coprime or not.  Im not entirely sure what the purpose of such a check would be. Even if it could be done with minimal effort, its hardly an optimization at all. Is this not so or am I missing something? 134.204.1.226 (talk) 19:19, 22 April 2024 (UTC)
replies: text: You are right, this is what both User:Dcoetzee and User:EJ said in that (old) discussion. Maëlan 13:47, 27 April 2024 (UTC)
thread_title:  Generating coprime a 

message: Excellent article, really. Thank you.
Antonind (talk) 16:50, 6 November 2008 (UTC)
thread_title:  Thank you 

message: The pseudocode in Miller–Rabin primality test#Algorithm and running time says:
 Input: n > 2, an odd integer to be tested for primality; k, a parameter that determines the accuracy of the test
 ...
    pick a randomly in the range [2, n − 2]
But if n = 3, then the range is [2, 3-2] = [2, 1] = ∅, and so no such a can be chosen. Is the range incorrect, or is the initial restriction actually n > 3, or have I missed something else? --67.249.56.101 (talk) 01:38, 31 July 2009 (UTC)
replies: text: It's really a very bad idea to use a complicated randomized algorithm for testing small integers like 3, any realistic implementation will first use trial division to rule out small prime factors, thus the problem does not occur. As for the theory, the natural analysis of the algorithm works for a randomly uniformly chosen in (\mathbb Z/n\mathbb Z)^*. Since there is no good way of doing this directly, the next approximation is to choose it uniformly in [1, n − 1]; since all numbers in this interval which are not coprime to n will happen to be witnesses of compositeness anyway, this can only improve the success probability. Now, the version [2, n − 2] which was used in the article is just a trivial optimization, since 1 and −1 (i.e., n − 1) are never compositeness witnesses, hence it is pointless to test them. Thus, the impossibility of choosing a in [2, n − 2] for n = 3 should be understood as that there are no compositeness witnesses, hence 3 is prime. I'll change it to [2, n − 1] so that people do not wonder. — Emil J. 10:47, 6 August 2009 (UTC)
replies: text:  I think a better change would be to make it "input: n > 3". CRGreathouse (t | c) 17:08, 6 August 2009 (UTC)
thread_title:  Random range in algorithm 

message: There is written: 
Using modular exponentiation by repeated squaring, the running time of
this algorithm is O(k × log3 n).
Shouldn't it be
O(k × s × log3 n) ? julekmen (talk) 11:16, 1 October 2009 (UTC)
replies: text: No, s is accounted for by one of those log n factors. — Emil J. 11:54, 1 October 2009 (UTC)

text: Please enlighten us how modular exponentiation of log(n)-bit numbers can be done in O(log^2 n) time. I thought O(log^2 n) is the time needed to perform a single multiplication (using the trivial algorithm, nothing fancy like FFT), and then there's another O(log n) factor for repeated squaring. -- X7q (talk) 02:22, 30 March 2012 (UTC)
thread_title:  Algorithm complexity 

message: "For example, Pomerance, Selfridge and Wagstaff and Jaeschke have verified that [...] if n < 341,550,071,728,321, it is enough to test a = 2, 3, 5, 7, 11, 13, and 17." - Did someone since extend this range with more potential witnesses (19, ...)? Gulliveig (talk) 05:01, 2 August 2011 (UTC)
replies: text: Yes, there have been several extensions -- including one I did several years ago.  But I don't know of any that have been published in peer-reviewed sources. CRGreathouse (t | c) 13:28, 2 August 2011 (UTC)
thread_title:  New bounds for the deterministic variant? 

message: "However, as a caution, note that Arnault   gives a 397-digit composite number that would pass a Miller–Rabin test for every base a less than 307. One way to reduce the chance that such a number will be declared probably prime is to combine a Miller–Rabin test with another type of test; this is what the Baillie–PSW primality test does."
I believe this promotes a misunderstanding of the type of probabilistic algorithm the MR test is.  For ANY number, the probability of it incorrectly stating that a number is prime decays exponentially with the number of trials.  As long as one is comfortable with probabilities on the order of 1/10^100 of an error (or even smaller, if you want to run it for longer), the test is completely fine.  For all practical purposes, it will never incorrectly determine the primality of a number, when run with hundreds of iterations.
The result of Arnault was a number for which no small bases worked to disprove primality.  But it is still true for this number (like all composite numbers) that most randomly chosen bases would work to disprove primality.  Their number failed the Maple primality test because of a weakness with the Maple implementation: it checked just the bases 2,3,5,7,11 instead of choosing random bases to test.
I have reworked this paragraph as a result.Wpegden (talk) 14:56, 10 October 2013 (UTC)
replies: text: I like the change.  I think this concept is important to keep on the page, because there is still a lot of software being written today (2013) that uses the first N bases instead of random bases, and most people seem to not see the difference.  The usual "solution" I've seen is people just raise the number of tests to silly numbers to weasel out of counterexamples, rather than using a BPSW test. 76.115.142.133 (talk) 04:07, 14 October 2013 (UTC)
thread_title:  misleading 

message: Isn't this true for all odd n > 2? If n is odd then n - 1 is even. As n - 1 is even, it is divisible by some power of two, the greatest one determines both s and d. Nick Garvey (talk) 22:33, 7 December 2013 (UTC)
replies: text: Yes, that part is true for all odd n > 2. Why do you call that incorrect logic? PrimeHunter (talk) 22:58, 7 December 2013 (UTC)
replies: text: Ah I misread the part that came after. Sorry, my mistake. Nick Garvey (talk) 23:07, 7 December 2013 (UTC)
thread_title:  Incorrect logic under Concepts 

message: The pseudocode includes the line:
    repeat s − 1 times:
However, s may be zero, in which case that line reads "repeat -1 times". It is reasonable to interpret that as "repeat zero times", but the ambiguity may be confusing.
Indeed, I discovered this problem by translating the pseudocode into a formal specification, then trying to prove an implementation of that spec correct. The spec demanded at least 's' witness squares, but when s==0, there is still one witness to either primality or non-primality. I understand that the pseudocode's job is not to be a formal reference, but my experience indicates that the ambiguity indeed has the potential to confuse readers. Even one reader with an advanced degree in computer science. :)
The line might be rewritten as one of:
    repeat at least s-1 times:
    repeat max(0,s-1) times:
    repeat s-1 times (or none if s==0):
The first variant is least disruptive to the pseudocode, but doesn't do much to hint at why the qualifier is present. The last variant's parenthetical comment clearly explains its own presence, but is unpleasantly distracting. I don't have a strong preference, but I'm enthusiastic about correcting the problem of -1 loops.
76.104.130.32 (talk) 06:05, 14 March 2014 (UTC)
replies: text: But n is odd so n-1=2s·d is even with d odd. Hence s is at least 1.  — Preceding unsigned comment added by 193.144.198.250 (talk) 12:30, 17 March 2014 (UTC)
thread_title:  Pseudocode underspecified 

message: I assume that the "deterministic variant" is the Miller test. The pseudocode uses ln, as in "natural logarithm" to set a bound. In computer science matters, I usually assume log2. Shouldn't it be log2 instead? Is this a convention thing or a genuine difference?
Note that "log" appearing within Big-O-Notation doesn't care about the base of the logarithm, because converting to another base is just multiplying by a constant.  — Preceding unsigned comment added by 176.199.27.52 (talk) 14:41, 22 June 2014 (UTC)
thread_title:  Use of Logarithm in in the Miller Algorithm 

message: Hi all,
I'm surprised to see that test in the loop. Where does it come from ? That test does not seem to be stated in the text written above.
RBossut (talk) 13:01, 24 April 2015 (UTC)
replies: text: It is not in Crandall and Pomerance Alg 3.5.2.  It is in Cohen (Course in CANT) Algorithm 8.2.2.  In Riesel 1994, it is not part of the definition 4.3, but is included in his program.  It isn't necessary, just practical as repeated squaring of 1 will not change the result, so can be considered an early exit condition.  Cohen structures his loop so this is clearer (repeat r-1 times while x != ± 1). DAJ NT (talk) 18:15, 12 November 2016 (UTC)
thread_title:  About the test "if x = 1 then return composite" in the algorithm 

message: I think the page would be improved if this were either removed or pushed to the end.  It is quite large and breaks up the flow from example to algorithm.  My personal feeling is that it adds no value, and at best we should just point to MathWorld's Strong Pseudoprime page and give a quick list of the first few.  Lastly, base 1 doesn't make sense (or if you think it does, why 9 and not 1 or 4 as pseudoprimes?).  DAJ NT (talk) 07:09, 23 May 2015 (UTC)
thread_title:  Least strong pseudoprime to base n table 

message: Suppose n  - 1 = 4k where k is odd and for some t, t ^ k = 32 mod n. Can we infer that n is composite? Not, surely, until we have checked that 1024 (i.e. 32 X 32) is not congruent to -1 mod n.
Bukovets (talk) 10:00, 11 June 2017 (UTC)
replies: text: Yeah, I asked myself the same question. It turns out this example was taken directly from the given source with some context stripped. In that paper, the GCD of 32−1 and 341 is computed unconditionally, so we know that we get a non‐trivial factor of 341 because we observe this GCD to be neither 1 nor 341. That was not clear in the present article because the algorithm used was not made explicit. I rewrote that part recently, and added the missing step to the example (check that 322 mod 341 = 1). — Maëlan 17:08, 19 February 2019 (UTC)
thread_title:  Is 341 prime? 

message: The factor database website  lists 728,134 composite numbers for which at least ten applications of the Miller-Rabin test failed to detect compositeness. The bases used in the tests were chosen by the mpz_probab_prime_p( ) function in the GNU Multiple Precision Arithmetic Library.
The list of numbers can be viewed and downloaded from .
A short calculation shows that none of these 728,134 numbers is a Lucas pseudoprime when Selfridge's "Method A" is used to choose Lucas parameters D, P, and Q. Therefore, the Baillie-PSW primality test would correctly declare that all of these numbers are composite. MathPerson (talk) 22:43, 8 September 2020 (UTC)
replies: text: Software implementation is not sufficient proof of an algorithm failing, as anyone can write erroneous mathematical code and indeed most do. In the case of mpz_probab_prime_p the selection process is not the same as described by the probabilistic Miller-Rabin  variant, therefore the results are irrelevant, and reading the source code would have told Tervooren that. JSory (talk) 22:39, 16 November 2022 (UTC)
thread_title:  Numbers for which the Miller-Rabin test fails 

message: Can 'a' be restricted to only the primes?  All of the deterministic "below a certain threshold" variants involve checks against only primes.  If 'a' needs to be coprime to the test number then why not just use prime 'a'?  Every explanation of the Miller-Rabin test I see online tells me to pull an 'a' from a range [2, n-1] and Im wondering if I just pull primes, am I setting myself up for failure?  Can a composite smaller than 'n' catch something that a prime smaller than 'n' cant?  I realize Im putting the cart before the horse here because you need to know primes already in order to test for them, so maybe thats why its worded the way it is, but assuming you already know the primes up to a certain point, why not check them only? That is what the deterministic variants are doing, after all.  If you were pulling randomly generated 'a' from a very large range [2,n-2], and perform the test 'k' times, then I could understand why you wouldnt do only primes. But barring the pragmatic side of the algorithm, what is the mathematical basis for using composites? Is there one or should we ideally be using only primes?  Nothing explicit is said about this. 134.204.1.226 (talk) 16:35, 13 December 2021 (UTC)
replies: text: The base a does not need to be coprime to the test number n. In fact, if a happens to have a common divisor with n, it will be a witness for the compositeness of n, because a^{n-1} \equiv 1 \pmod{n} cannot be true. That means you will not need to test any further bases. Moreover, composite bases work a little better in practice. If you look at the best known SPRP bases sets, all bases there are composite, except for 2. And the base 2 is used only because we have calculated a huge table of strong pseudoprimes for that base, which allows us to limit testing other bases to that precalculated list only. Anton Lapounov (talk) 23:52, 14 February 2022 (UTC)
replies: text: "Weak" pseudoprimes rather, however Feitsma & Galway's list can be trivially reduced to strong 2-pseudoprimes. JSory (talk) 22:41, 16 November 2022 (UTC)
thread_title:  Reducing values of 'a' to primes 

message: Point of inquiry.  I have always thought, beginning with Fermat primality test, that arbitrary base 'a' was an inefficiency.  Can someone correct me? Is it sufficient to test only bases that are prime?  In the section of this article for testing against small subsets, for test numbers 'n' beneath a certain limit, the base 'a' sets always comprise prime numbers.  If a base of 2 and a base of 3 are both inconclusive, does a base of 6 provide any more meaningful information? Or would testing it be redundant? If 6 is indeed redundant to testing both 2 and 3 separately, why not just test against some large primorial number? 
134.204.1.226 (talk)  — Preceding undated comment added 19:24, 22 April 2024 (UTC)
replies: text: it doesn't work; a number can be a strong pseudoprime to base b but not to base kb. For example, 703 is a strong pseudoprime to base 3 but not to base 15. - CRGreathouse (t | c) 13:22, 26 April 2024 (UTC)
thread_title:  Prime base 'a'