|
-
Mar 21st, 2012, 01:43 AM
#1
Playing around with modular arithmetic
I was reading Wikipedia's page on Wilson's Theorem and thought a few people might enjoy fiddling with some of the underlying ideas on a computer. Here are a few leading questions.
1) Pick a prime number p, multiply the numbers 1, 2, ..., p-1, and take the result mod p. How does the result depend on p? [Computational note: to avoid overflow issues, you can multiply a few of the numbers, take the result mod p, and multiply a few more without changing the answer. Eg. (5*9*15) mod 12 = (((5*9) mod 12) * 15) mod 12.]
2) What happens if p is not prime in (1)? Are there any exceptions to this rule? Can you devise a primality testing algorithm from these results? How good is this algorithm speed-wise?
3) Two numbers a and b are called relatively prime if their prime factorizations share no common prime factors. Eg. 10 and 6 are 2*5 and 2*3 which share the factor 2, so they are not relatively prime. The Euclidean algorithm offers a very fast method for determining if two numbers are relatively prime. In pseudocode (partly stolen from Wikipedia),
Code:
function IsRelativelyPrime(a, b)
if gcd(a, b) = 1
return True
else
return False
function gcd(a, b)
if b = 0
return a
else
return gcd(b, a mod b)
Reconsider (1): the numbers 1, ..., p-1 are each relatively prime to p since p is prime. By contrast, if p is not prime, some of the numbers 1, ..., p-1 are not relatively prime to p. Redo (2) but this time only multiply those numbers 1, ..., p-1 which are relatively prime to p. How does the result depend on p? What happens if p is the power of a prime, like 2^3 = 8? Can you find some simple rules to determine the result in advance without actually multiplying everything out?
[I'd be happy to provide results, proofs, or proof outlines. I'd certainly be interested in original proofs, though without some knowledge of number and/or group theory that's asking a lot.]
The time you enjoy wasting is not wasted time.
Bertrand Russell
<- Remember to rate posts you find helpful.
-
Mar 22nd, 2012, 11:09 AM
#2
Re: Playing around with modular arithmetic
I'm certainly no mathematician(60% on this term's test)
But I like to program, and even more than that I like optimizing things.
For the standard prime testing algorithm any prime p you will have Floor(sqrt(p))-1 MOD operations to test if it is a prime. From your statement and A little playing around I made a equation
(p-1)! MOD p = p-1
So far it is true for all primes and 1,although I have not really done any extensive testing to see if there are exceptions, but if it is true then you have got yourself one quick primarily testing algorithm because I have heard that multiplication is 4 times faster than division. I have a suspicion that any value that will result in TRUE will be prime, but it might not be true for all primes.
-
Mar 22nd, 2012, 12:00 PM
#3
Re: Playing around with modular arithmetic
 Originally Posted by BlindSniper
(p-1)! MOD p = p-1
So far it is true for all primes and 1,although I have not really done any extensive testing to see if there are exceptions,
Yes, that is Wilson's Theorem, so it will always be true, although it is most commonly stated as (p-1)! = -1 MOD p, since -1 and (p-1) are the same thing MOD p.
 Originally Posted by BlindSniper
but if it is true then you have got yourself one quick primarily testing algorithm because I have heard that multiplication is 4 times faster than division.
There are a couple problems with this statement. First, because computers would overflow if they did not use modulation as jemediah suggested in his computational note in question 1, a computer would need to repeatedly use modulo during this algorithm, which is basically division anyway, so you completely lose the "4 times faster than division."
Second, the question of how fast a primality test is is mostly relevant in connection with other primality tests. I assume your division method is just a naive sieve, but that is a horrendously slow primality test. In fact, so is Wilson's Theorem, since it's run time is O(p), which means it could only be used on very small numbers (aka nothing like the 200 digit numbers that are actually useful). As far as I'm aware, the fastest deterministic test out there runs at Õ((log p)^6), which basically implies that it grows with the number of digits in p rather than the magnitude of p itself. To make a long story short, there is no such thing as a quick primality test.
Last edited by Lenggries; Mar 22nd, 2012 at 12:59 PM.
Reason: typos
-
Mar 22nd, 2012, 12:33 PM
#4
Re: Playing around with modular arithmetic
Indeed, It's the overflow that kills this one, I was just playing around with small numbers but when I started using bigger numbers I got an overflow. I modified it so it can do 3 digit numbers still faster than my normal method(and then it starts overflowing), but the overflow problem's are not worth it. It seems RSA is still safe.
-
Mar 22nd, 2012, 02:51 PM
#5
Re: Playing around with modular arithmetic
 Originally Posted by Lenggries
...that is a horrendously slow primality test. In fact, so is Wilson's Theorem, since it's run time is O(p)
I just wanted to emphasize that the naive trial division method is O(sqrt(p)), so the Wilson's theorem test, being O(p), is far worse than even that method for p remotely large.
As far as I'm aware, the fastest deterministic test out there runs at Õ((log p)^6)
Yup, a variant of AKS is down to an exponent of 6, which is likely optimal for that type of algorithm. (According to Lenstra and Pomerance, at least: "A fundamentally new idea would be required to obtain a deterministic primality testing algorithm with run time exponent smaller than 6.")
 Originally Posted by BlindSniper
Indeed, It's the overflow that kills this one, I was just playing around with small numbers but when I started using bigger numbers I got an overflow.
Hmm, you shouldn't get overflow problems until p is around the square root of MaxInt.
It seems RSA is still safe.
Actually, RSA can't be broken by a fast prime test. A fast factoring algorithm would break it, though.
The time you enjoy wasting is not wasted time.
Bertrand Russell
<- Remember to rate posts you find helpful.
-
Mar 22nd, 2012, 04:08 PM
#6
Re: Playing around with modular arithmetic
 Originally Posted by jemidiah
I just wanted to emphasize that the naive trial division method is O(sqrt(p)), so the Wilson's theorem test, being O(p), is far worse than even that method for p remotely large.
Yeah, I fiddled with it some. You can definitely reduce Wilson's Therorem to p/2 by pairing n with (p-n) = -n^2 mod p, not that that changes the Big-Oh formula. I wouldn't be surprised if there are other tricks that could reduce it further, though. After all, the naive sieve is only reduced to O(sqrt(p)) due to the non-obvious realization that you only need to consider divisors up to the square root of p. In fact, using the prime number theorem, the naive method can be reduced even further if one has a list of all primes less than the sqrt(p) to O(sqrt(p)/ln(p)).
 Originally Posted by jemidiah
"A fundamentally new idea would be required to obtain a deterministic primality testing algorithm with run time exponent smaller than 6."
Oooohhh... now I know what to work on if I want to drive myself insane 
 Originally Posted by jemidiah
Hmm, you shouldn't get overflow problems until p is around the square root of MaxInt.
I'm not sure he was taking products in modulo, which means he'll hit an overflow a lot faster than sqrt(MAXINT). Even using an unsigned 64 bit integer, he'd overflow before he could test p=23, since 22! > 2^64. Taking products in modulo, however, I think you are correct with your sqrt(MAXINT) approximation.
 Originally Posted by jemidiah
Actually, RSA can't be broken by a fast prime test. A fast factoring algorithm would break it, though.
Something else I can drive myself insane with...
-
Mar 22nd, 2012, 04:46 PM
#7
Re: Playing around with modular arithmetic
 Originally Posted by Lenggries
Even using an unsigned 64 bit integer, he'd overflow before he could test p=23, since 22! > 2^64.
Yes, this combined with "I modified it so it can do 3 digit numbers still faster than my normal method(and then it starts overflowing)" is what confused me. It now occurrs to me that BlindSniper must have been using floating point numbers--for instance, log10(171!) > 309, and MaxDouble (IEEE 754) is around 1.7 x 10^308. In general one should only use integer variables for this type of work. Floating point numbers can and will screw up the results by cutting off bits at the end.
@Lenggries: if you wanted a tractable problem to occupy yourself with, proving the following generalization of Wilson's theorem might be fun: in a finite abelian group G, let #2(G) denote the number of order-2 elements in G.
- If #2(G) = 1, then the product of all elements in G is the unique order 2 element.
- If #2(G) != 1, then the product of all elements is the identity.
Of course, the difficult bit is the #2(G) > 1 case. From this one can immediately pare down the possible answers to the last questions I asked in (3) to +/- 1. Providing a more precise statement requires computing the multiplicative groups of integers mod n, which is remarkably involved--however computational evidence probably guided whoever unraveled that structure originally (Gauss maybe?). I always find it remarkable that (Z/pZ)^x [indeed, (Z/p^a Z)^x] is cyclic for [correction: odd] prime p.
Last edited by jemidiah; Mar 22nd, 2012 at 05:45 PM.
The time you enjoy wasting is not wasted time.
Bertrand Russell
<- Remember to rate posts you find helpful.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|