I read a positive integer N from the stdin and I'm trying to figure out if N is a prime number.
I know I can divide N to all the positive numbers up to sqrt(N), but that's time consuming and my algorithm affords to give false positives from time to time so I'm looking for an heuristic to solve this.
I remember I learned about an algorithm in collage last year that would pick a number, then check if N is divisible by that number (or it's factors) and if not, then it could tell N is a prime, but it would falsely identify it as prime about 1/40 of the time.
Does anyone recognize this algorithm I'm talking about?
A link to it would be very helpful.
Well, there are a few probabilistic algorithsm, some described in the wikipedia page, most likely you are speaking about Miller-Rabin Fermat Primality Test
Note that since 2002 there is actually a O(log(n)^6) deterministic approach to determine if a number is prime - called AKS (after its developers)1
It is an interesting issue - many thought that primality test cannot be done both polynomially in the size of the input (i.e. logarithmic in n) and both deterministically, but their approach showed otherwise.
Related
I have searched for ways to determinate if a number is prime or not, but most ways are either probabilistic (Miller Rabin) or for numbers smaller than 64 bits.
The other solution would be to use the brute force method with a few improvements or the sieves, but neither of those is very efficient when the numbers go above the 64 bit threshold.
What you are looking for does not exist. There is no simple deterministic primality test that works always for all ranges of integers.
You already know about the Miller-Rabin test. It can be made deterministic on particular ranges; see here or here for details. If you assume the Riemann Hypothesis, then n is prime if n is an a-SPRP (a Miller strong pseudoprime) for all integers a with 1 < a < 2(log n)². A similar and somewhat better test is the Baillie-Wagstaff test; it is not deterministic, but no failures are known.
For numbers n up to 2128, it's not too hard to factor n − 1 and use a Pocklington test to prove primality. You can use trial division, or Pollard rho, or ECM to perform the factorization. There are also tests (BLS75) that can prove primality based on a partial factorization. Larger n can also be proved prime using a Pocklington test, though sometimes the factorization becomes difficult.
For n up to about 101000, a fast ECPP prime test is not unreasonable, though for the larger numbers in that range it might take a while. Beyond that, unless your number has some special form, you're pretty much out of luck.
I will assume that what you want is a provably correct answer, rather than avoiding randomness altogether.
Run a few rounds of the Miller-Rabin primality test. If this fails, you know the number is composite, and you're done.
Factorize n-1. For this, simplest is the Pollard's rho algorithm. If that's not fast enough, use the Quadratic Sieve.
Check whether the factors are prime, using the same approach recursively. If they are composite, continue factorizing them.
Use the Lucas Primality Test: try to find a generator of the multiplicative group modulo n of order n-1. Pick a random number a, check that a^(n-1) = 1 (mod n), and that a^((n-1)/p) ≠ 1 (mod n) for all prime factors p of n-1. If this is true, a is a generator, and n is provably a prime number, so you are done.
If n is prime, the probability of success in finding a generator is (1-1/p1)(1-1/p2)... where p1, p2, ... are the distinct prime factors of n-1. This is at least 1 / O(log log n). So after O(log log n) attempts you should succeed in proving that n is prime.
If you keep failing in proving n is prime, go back to step 1. Maybe it's composite after all.
I have been reading a competitive programming book for one month. The book is written by one of the world finalists of our country (Bangladesh). Point to be noted, the book is written in our native language (Bengali) and that is not so popular worldwide. Because of having the content in Bengali I can't refer it here. That's why I am sorry first of all.
In Number theory chapter of that book, there are given many algorithms to test Primality. The most optimal he has shown, is "Sieve of Eratosthenes" in O(nloglogn). But he wrote one line. I am translating it.
"There is a more efficient method of testing primality in O(logn). Think it yourself. And if you are undone, just google it!!"
I have googled about it.But I didn't find anything satisfactory.
Is it really possible to test the primality of a number in O(logn) ??
And if it is possible then up to which range it can be concluded ??
The statement is incorrect. For a number N, the number of digits is O(log N), so the statement means that there is an algorithm that's linear in the number of digits. The best known result is polynomial in the number of digits. (Agrawal–Kayal–Saxena primality test, Õ(logN 12). That's logN to the power of twelve, not one.
Still, Õ(logN 12) ⊂ O(N)
Bear in mind I'm almost a complete noob at complexity theory.
I was reading about how AKS Primality shows that numbers of size n can be shown to be prime or composite in polynomial time. Given that, does that imply finding all prime numbers less than a number n is also doable in polynomial time and thus the algorithm runs in FP. Additionally, does this imply that counting all primes less than n is not in #P?
well. What aks says it that primality testing for a number n is O(b^k) where b = log2(n) and k is some integer.
So, if your questions is is listing all the primes from 1 to n also O(b^k). Then the answer is trivially no because the number of primes less than n is O(n/logn). Therefore you would need O(n/log(n) ) just to list them
If your question is does there exist a k such that the complexity of listing all the primes less than n is in O(n^k).
Then the answer is trivially yes because the most trivial form of sieve is O(n^(1.5)).
If anything is unclear please let me know
In two algorithms I've been working with, I use the two functions:
pi(n):=number of primes <= n, and
R(n):=r, where prod(p_i,i=1,r)<=n but n < prod(p_i,i=1,r+1) where p_i is the i-th prime.
Basically pi(n) is the famous prime-counting function, and R(n) just calculates the product of consecutive primes until you reach the bound n and returns the amount of primes used, so for example:
R(12)=2 because 2*3<=12 but 2*3*5>12 and for example
R(100)=3 because 2*3*5<=100 but 2*3*5*7>100.
With my Professor we have been talking about the running time of calculating these functions. I know that the pi(n) that it approximates x/ln(x) over time, but I have my doubts about some stuff:
Can R(n) be calculated in polynomial time? From my point of view, by using dynamic programming we can calculate the products 2*3*5*...*p_i by knowing 2*3*5*...*p_(i-1), so the problem reduces to get the next prime, which as far as I know it can be calculated in polynomial time (PRIMES is in P).
Also because we know that we can determine if a number is prime in polynomial time, shouldn't that mean that pi(n) can be calculated in polynomial time? (Also using dynamic programming can be helpful).
If anyone can help me to clarify these questions or point me on the right direction, I would really appreciate it! Thank you!
There are methods to compute pi(n) in sub-linear time. Google for "legendre phi" or for "lehmer prime counting function", or for more recent work "lagarias miller odlyzko prime counting function". Lehmer's method isn't difficult to program; I discuss it at my blog.
For any n, you can easily determine if it's prime in O(n^(1/2)) time (check for divisibility by 2,3,4...,sqrt(n)), so you could just iterate over n and keep a counter as you go. If you store your primes in a list you could even speed it up checking whether each number is prime (check for divisibility by 2,3,5...,closest prime to sqrt(n)). So this algorithm for finding pi(n) should be O(n^(3/2)).
So let's say you run that algorithm and store the primes in a list. Then for R(n), you could just iterate through them to get their cumulative product, and return once you exceed n. I'm not sure what the time complexity of this would be, but it's going to be small. Probably something along the lines of O(log(n)), certainly something faster than O(n). Put both of those together and you should get something faster than O(n^(5/2)).
Problem
Given a number n, 2<=n<=2^63. n could be prime itself. Find the prime p that is closest to n.
Using the fact that for all primes p, p>2, p is odd and p is of the form 6k+1 or 6k+5, one could write a loop from n−1 to 2 to check if that number is prime. So instead of checking for all numbers I need to check for every odd of the two forms above. However, I wonder if there is a faster algorithm to solve this problem? i.e. some constraints that can restrict the range of numbers need to be checked? Any idea would be greatly appreciated.
In reality, the odds of finding a prime number are "high" so brute force checking while skipping "trivial" numbers (numbers divisible by small primes) is going to be your best approach given what we know about number theory to date.
[update] A mild optimization that you might do is similar to the Sieve of Eratosthenes where you define some small smooth bound and mark all numbers in a range about N as being composite and only test the numbers relatively prime to your smooth base. You will need to make your range and smoothness small enough as to not eclipse the runtime of the comparatively "expense" prime test.
The biggest optimization that you can do is to use a fast primality check before doing a full test. For instance see http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test for a commonly used test that will quickly eliminate most numbers as "probably not prime". Only after you have good reason to believe that a number is prime should you attempt to properly prove primality. (For many purposes people are happy to just accept that if it passes a fixed number of trials of the Rabin-Miller test, it is so likely to be prime that you can just accept that fact.)