Talk:Miller–Rabin primality test

Misc

To 203.217.64.49:

• Please direct questions and other discussion on the talk page, not in the article text.
• Any nonzero integer is uniquely expressible as an odd multiple of a power of 2. This defines k and m from n. In other words, k is the largest integer such that 2^k divides n−1.

-- EJ 11:49, 21 Sep 2004 (UTC)

Don't you get some really large numbers when doing this? I'm trying to write a C++ implementation using 1009, which is prime, as a test number, and I just realized that in larger bases you get very big numbers in the second test. For example, $1009=2^{4}\times 63$, so for the second test you might have $2^{2^{3}63}=2^{504}$

I haven't stepped through it, but as with all crypto stuff involving modular exponentiation, you can keep reducing it at every step. See modular exponentiation. CryptoDerk July 8, 2005 21:25 (UTC)

You do indeed get really big numbers. To quote a step-by-step implementation (see given link):
"[...] probing 24155007172823 for primality requires the evaluation of 17^{12077503586411} mod 24155007172823." Gulliveig (talk) 04:14, 20 June 2009 (UTC)

But you won't ever work with a number larger than 24155007172823^2 using modular exponentiation. CRGreathouse (t | c) 07:13, 20 June 2009 (UTC)

Ruby Code

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)

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)

Smallest number for which MR test is uncertain?

Hello. It seems one could establish by brute force that the MR test gives exactly the right answer for all numbers up to some limit (determined by how long you run the MR test on successive integers). Has anyone done a brute force search like that? Or maybe someone has proved that MR test is correct (i.e., reports N is prime iff N is actually prime) for all numbers up to some bound? -- I'm assuming here that the test is computationally deterministic, i.e., if I run the test twice on the same input, I'll always get the same report. Maybe my understanding of the test is flawed. It seems like the "probabilistic" aspect of the test could be explained at greater length. Many thanks to the authors for their work on this article. 207.174.201.18 18:47, 1 February 2006 (UTC)

You apparently misunderstood something. Probabilistic tests are explained at greater length in Primality test and Randomized algorithm, which are both prominently linked from the first paragraph of the article.

It would help this article to briefly state what is the import of the fact that Rabin's version is probabilistic. Given the subtlety of the concept, it's not enough to give a link and assume the readers can go figure it out for themselves. 207.174.201.18 00:43, 2 February 2006 (UTC)

Well, people certainly can go follow the link, and at some point it becomes necessary to assume they do, because it is impossible to repeat everything everywhere. But I'll try to put some summary here, you're right that the concept is confusing. -- EJ 20:16, 3 February 2006 (UTC)

The probabilistic (Rabin's) version of the algorithm, which is discussed in the article, is provably correct for all composites. It is not deterministic, which is (1) the whole point of the definition of a probabilistic test, and (2) obvious from the description of the algorithm: "pick a randomly in the range [1, n − 1]". I have removed the irrelevant, and wrong as stated, sentence from the "Additional information" section, which might have confused you.

What can be said about Rabin's test if it is implemented on a computer which has deterministic hardware? (I.e., assuming random numbers come from a pseudorandom number generator and not from atomic decay or some other "really random" source.) 207.174.201.18 00:43, 2 February 2006 (UTC)

That's a very good question, but I'm afraid that nobody knows a satisfactory answer. Derandomization and pseudorandom generators are a big topic in theoretical computer science. However, these constructions of PRG tend to be inefficient (and thus rarely used in practice), and they depend on unproven assumptions about computational hardness of certain functions. PRG used in practice are based on heuristic without any serious analysis. -- EJ 20:16, 3 February 2006 (UTC)

The deterministic (Miller's) version of the algorithm, which is only briefly mentioned in the introduction, is only conjectured to be correct for all composites. As for brute force verification, it is known e.g. that all numbers n < 341,550,071,728,321 which pass the test for bases a = 2, 3, 5, 7, 11, 13, and 17, are prime [1]. As 17 is well below 2(ln n)², Miller's test is also correct for these n. The Riemann hypothesis was also verified by brute force for a lot of numbers, but I don't know whether anybody tried similarly to verify the Generalized Riemann Hypothesis for quadratic Dirichlet characters, which is what the Miller test depends on. -- EJ 20:22, 1 February 2006 (UTC)

OK, thanks a lot for these facts. If I understand correctly, the outcome of the MR test is uncertain only if n >= 341,550,071,728,321 (because for numbers less than that, the test reports a number may be prime iff it is indeed prime). I think this aspect should be mentioned in the article itself. 207.174.201.18 00:43, 2 February 2006 (UTC)

Bear in mind that these results only concern the deterministic version of the algorithm, they are irrelevant for the randomized version. Also, do not take the bound too seriously, that fact that I could quickly find it does not mean that no better bounds are available.

The current (almost nonexistent) coverage of the deterministic algorithm in the article should be expanded, thanks for the tip. -- EJ 20:16, 3 February 2006 (UTC)

The ANTS'94 paper by Alford, Granville and Pomerance contains some conjectures about the necessary number of tests needed for a deterministic version. I.e., the expect that $(1+o(1))(\log(n)\log \log(n))$ tests is sufficient, whereas $o(\log(n))$ is not sufficient. 24.228.93.22 05:07, 5 February 2006 (UTC)

Thanks for the pointer. -- EJ 17:30, 11 February 2006 (UTC)

Bleichenbacher [2] showed that Miller's test holds for n < 1×10¹⁶. That's the best result I've seen; I'd love to know of a better result. Sloan's OEIS doesn't have much information about SPSPs above 1×10¹³ and nothing above 1×10¹⁶ as I recall. CRGreathouse (talk • contribs) 02:38, 6 August 2006 (UTC)

Unfortunately I can not open the PS files mentioned in your source with any of my software. I tried to e-mail him, but he does not seem to work there anymore. In the meantime, if someone could answer, if Bleichenbacher did work with "Jaeschke's" witnesses a={2,3,...,17} or if he had to include more, it would really be appreciated. - I also tried to contact Jaeschke (via a 3rd party) about progresses (i.e. better results). If I succeed with these attempts, I will update the article accordingly. Gulliveig (talk) 12:57, 20 June 2009 (UTC)

Meanwhile I did some additional research. Apparently Pomerance, Selfridge, and Wagstaff [PSW 1980] calculated the first 4 values of this sequence, Jaeschke [Jaeschke 1993] calculated the next four, and Zhang and Tang [ZT 2003] provided for more values, not listed yet in the sequence. I added them, incl. reference. With those, we are at 318,665,857,834,031,151,167,461 now. Gulliveig (talk) 13:44, 20 June 2009 (UTC)

There are several freely available PostScript previewers, for example Ghostscript front-ends such as Ghostview or GSview (see [3]). — Emil J. 13:18, 22 June 2009 (UTC)

You misunderstand Zhang & Tang. They give upper bounds, not values. They did not prove that there are no failures below those numbers, only that they fail at those numbers. CRGreathouse (t | c) 20:17, 20 June 2009 (UTC)

Thank you, CR. Now, [4] says, that although it is known that MR holds for n < 10¹⁶, for larger number "[...] no counterexamples are known and if any exist, they are expected to occur with extremely small probability (i.e., much less than the probability of a hardware error on a computer performing the test)." -- Do you know, if the source of this claim is known and if it stand on solid grounds? -- Shouldn't at least Bleichenbacher's result and possibly also that claim (if it does stand on solid grounds) be included in the article? Gulliveig (talk) 07:22, 21 June 2009 (UTC)

The MathWorld comment is solid but not relevant here -- it's talking about the BPSW test, not just a Rabin-Miller. Bleichenbacher's results could be included, perhaps along with Feitsma's -- but it may be better to wait for better sourcing, I'm not sure. CRGreathouse (t | c) 00:33, 22 June 2009 (UTC)

Some imprecise (wrong) formulations ?

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\leq r\leq 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)

You're right that there aren't non-trivial square roots of 1 mod prime p. If x² = 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)

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)

The phrase "Except for powers of 3 (see page 1393 of [3]), every odd composite n has at least one witness a." it is confuse and it has to be rephrased. Powers of 3 have nothing to do here. This in fact is trivially true: all odd composites have witnesses, at least two (not only one!), including the Carmichael numbers, and *especially* the powers of 3: they ONLY have witnesses (no liars!). One third of the numbers lower then a power of 3 give a zero (the one being 0 mod 3) and the other two thirds are witnesses, ex: n=9, b=3,6: b^8=0 (mod 9); b=2,7: b^8=4 (mod 9); b=4,5: b^8=7 (mod 9); for n=27, b^26 (mod 27) is zero for 3,6,9,12,15,18,21,24, it is 13 for 2 and 25, it is 7 for 4 and 23, etc. Powers of 3 have no LIARS. All the other odd composites have at least two liars (if L is a liar, then -L is one, too). — Preceding unsigned comment added by LaurV (talk • contribs) 03:22, 30 May 2013 (UTC)

Deterministic variants of the test

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)

Counter example: Take n=7. So n-1 = 6 and s=1,d=3 since 2^1.3 = 6. The article claims it's enough to check a=2,7 and 61. Try a=7. The test described in "deterministic variants" section then says n is composite. -- XYZ, June 8 2006

Could it be that only a in the range 1...(n-1) should be tested? If so, it's not clear from the page. -- XYZ, June 8 20006.

Yes, only a in the interval [1,n-1] should be checked. -- EJ 19:17, 8 June 2006 (UTC)

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(modn)$. 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)

Following the deterministic algorithm i found some exception: 49=2^4*3+1 s=4, d=3; if a=18, (18^3) mod 49 = 1 -> 49 prime. Like 49 there is also 121, 289. Kaluppollo (talk) 21:15, 6 July 2009 (UTC)

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)² ≈ 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)

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)

You misunderstand the algorithm. Since 2^23·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)

sorry, you are right, i misanderstood it. thanks for the help Kaluppollo (talk) 21:47, 7 July 2009 (UTC)

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.: [5]. Gulliveig (talk) 04:27, 11 September 2009 (UTC)

Actually, I'm having some trouble with the pseudocode myself. - bogus walkthrough subsequently deleted - It seems to correctly classify all odd 1<n<41 (or at least a software implementation according to my understanding of the pseudocode does). What am I misunderstanding to make me think the pseudocode yields composite for 41 ? --83.104.46.24 (talk) 14:15, 3 February 2010 (UTC)

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)

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)

Strength

I added the word in bold: "The Miller-Rabin test is strictly stronger than the Solovay-Strassen primality test in the sense the set of strong liars of the Miller-Rabin test is a proper subset of the set of the Solovay-Strassen primality test."

It was removed, which is fine with me. (It was actually changed to "(often proper)", which seems overly pedantic to me, but that's beside the point.) Thinking of the set of all {M-R, S-S} liars grouped by base the inclusion is proper; thinking of a particular base the result isn't proper (but is still inclusion).

However, it we're not going to call the subset proper, we shouldn't use the term "strictly stronger"; it should be stronger. I propose one of the two wordings below (differences bolded):

"The Miller-Rabin test is strictly stronger than the Solovay-Strassen primality test in the sense the set of strong liars of the Miller-Rabin test is a proper subset of the set of the Solovay-Strassen primality test."

"The Miller-Rabin test is stronger than the Solovay-Strassen primality test in the sense the set of strong liars of the Miller-Rabin test is a subset of the set of the Solovay-Strassen primality test."

If there's no feedback, I'm going to make one of these changes in a few days. CRGreathouse (talk • contribs) 17:01, 5 August 2006 (UTC)

The M-R test is an algorithm, which gets an integer n and a randomly chosen integer a, and tries to use the latter to determine the compositeness of the former. It is strictly stronger than S-S because it is correct whenever S-S is correct, and moreover, there are n and a for which S-S is incorrect, but M-R is correct.

The "set of strong liars", on the other hand, has no absolute meaning. It only makes sense if we fix n, albeit implicitly (as in the offending sentence, in the current version and all versions you proposed). For some n it is a proper subset of Euler liars, for some n it equals the set of Euler liars. We cannot call it proper without further qualification, because that would read as "for every n, the set of strong liars is a proper subset of Euler liars", which is false.

IMO both the original wording and the current wording are OK, in the sense that they are not incorrect, and anyone who understands the concepts will figure out what it exactly means. I disagree with your suggestions, because the first one is incorrect, and the second one fails to mention that M-R is strictly stronger than S-S, which is the whole point of the sentence. If you insist on changing the formulation, the proper way would be

"The Miller-Rabin test is strictly stronger than the Solovay-Strassen primality test in the sense that for every composite n, the set of strong liars for n is a subset of the set of Euler liars for n, and for many n, the subset is proper."

but I think that this is too verbose. -- EJ 18:48, 5 August 2006 (UTC)

I think that's fine actually and not too verbose. Deco 01:43, 6 August 2006 (UTC)

OK. CRGreathouse apparently does not object, so I'll put that in. -- EJ 19:42, 13 August 2006 (UTC)

Broken Algorithm?

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)

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)

Fixed the algorithm. Check Stinson's "Cryptography Theory and Practice" [6] —Preceding unsigned comment added by 72.226.196.71 (talk) 03:37, 9 May 2009 (UTC)

Generating coprime a

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)

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)

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)

Yup. Dcoetzee 11:36, 7 November 2007 (UTC)

Haskell code

Why Haskell implementation of the algorithm was removed? It's not true that given pseudocode is sufficient to directly write efficient code on a computer language. And removed Haskell code was not straightforward translation of the pseudocode either. So, I think, we must return Haskell sample or write another pseudocode, better suited for an implementation. —Preceding unsigned comment added by 87.255.1.40 (talk) 17:06, 10 April 2008 (UTC)

Wikipedia is not a source code repository. The article is supposed to describe the algorithm so that the reader can understand why it works, it is not supposed to give optimized implementations ready for copy&paste. Furthermore, what is or is not efficient heavily depends on the language used, as well as other circumstances (typical size and structure of input data, hardware parameters, etc.) Thus anybody wishing to write an efficient implementation would still have to do it on his/her own, not by copying a random Haskell implementation, especially since he/she is likely to use a completely different language. Finally, the Wikipedia verifiability policy applies to this situation as usual: unless you can supply a reference to published reliable source, your Haskell implementation counts as original research, which is not permitted on WP. You know, why should we take your word on the correctness or efficiency of your code?

If you are just looking for a public place where to post your code, I'm sure you'll be able to find a plenty of internet sites suitable for that purpose. Wikipedia is not one of them. — EJ (talk) 14:48, 14 April 2008 (UTC)

Thank you

Excellent article, really. Thank you.

Antonind (talk) 16:50, 6 November 2008 (UTC)

Random range in algorithm

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)

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)

I think a better change would be to make it "input: n > 3". CRGreathouse (t | c) 17:08, 6 August 2009 (UTC)

Algorithm complexity

There is written:

Using modular exponentiation by repeated squaring, the running time of this algorithm is O(k × log³ n).

Shouldn't it be O(k × s × log³ n) ? julekmen (talk) 11:16, 1 October 2009 (UTC)

No, s is accounted for by one of those log n factors. — Emil J. 11:54, 1 October 2009 (UTC)

It should be O(k log²) not O(k log³). a^d can be calculated in O(log² d) by modular exponentiation. Since n-1 = 2^sd, s = O(log n). The line x = x2 mod p only involves 2 multiplications and 1 mod. So the total is O(k (log² d + 3s)) = O(k log² n). Angry bee (talk) 15:29, 26 March 2012 (UTC)

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)

New bounds for the deterministic variant?

"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)

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)

misleading

"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)

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)

• From this perspective, the result of Arnault is similar to the those of Pomerance—Selfridge—Wagstaff and Jaeschke, mentioned in section Deterministic variants of the test. In particular, they give the number 2,152,302,898,747 as one that passes Miller–Rabin primality test for bases 2, 3, 5, 7, and 11 and thus should also pass Maple primality test. I therefore think that Arnault, Pomerance—Selfridge—Wagstaff, and Jaeschke results should be mentioned in the same place/context — I would suggest moving mention of Arnault to Deterministic variants of the test section. Maxal (talk) 14:09, 14 October 2013 (UTC)

Incorrect logic under Concepts

Now, let n be prime with n > 2. It follows that n − 1 is even and we can write it as 2^s·d, where s and d are positive integers (d is odd).

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)

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)

Ah I misread the part that came after. Sorry, my mistake. Nick Garvey (talk) 23:07, 7 December 2013 (UTC)

Pseudocode underspecified

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)jonh

But n is odd so n-1=2^s·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)