Relatively Prime

[asdf]

I need a fast function which determines whether 3 numbers are relatively prime. I'm thinking of doing 3 GCF's, but that seems slow.

[cheesehead]

Just 2 GCDs, right? gcd ( gcd ( A, B ), C )

I've seen library GCDs that took more than two arguments, but the question would be whether anyone's coded a really fast one.

[Edit: Oh, swiss! I just realized that I got it backward, but find that hyh1048576 has already pointed that out, so I can't save face by sneaking in a silent edit.

Ya know, as ya get older yer subconscious gets wiser but also gets slower.]

[hyh1048576]

Originally Posted by cheesehead

Just 2 GCDs, right? gcd ( gcd ( A, B ), C )

I've seen library GCDs that took more than two arguments, but the question would be whether anyone's coded a really fast one.

:? I don't think it is right. ;)

If gcd(A,B)>1, they are not relatively primes. So when A,B,C are relatively primes, gcd(A,B)=1, so gcd ( gcd ( A, B ), C )=gcd(1,C) must be equal to 1 ......That means it's useless in the determination :( And for example, A=p1p2, B=p3p4, C=p2p3, p1,p2,p3,p4 are primes.The two gcd are both equal to 1, but they are not relatively primes.

My method is A,B,C are relatively primes iff gcd(A,B) and gcd(AB,C) are both equal to 1 :)

[asdf]

Thanks for your help, I'll see how it goes.

[ewmayer]

There is no reason one needs to restrict the GCD to 2 inputs, i.e. N numbers x_1, ..., x_N are relatively prime iff GCD(x_1, ..., x_N) = 1. Of course if the GCD implementation one is using only allows for 2 inputs, one would have to do N-1 pairwise GCDs, but that has the advantage that if any one of these gives a result > 1, one can stop right there.

[Orgasmic Troll]

it seems to me that there should be some way to short circuit this to just look for relatively prime or not, instead of finding out the greatest common divisor.

doing GCD's seems like factoring a number to see if it is prime ..

Any thoughts?

[apocalypse]

Ernst -

Why don't we need N choose 2 gcd's. Or are we not talking about pairwise relatively prime numbers?

[ewmayer]

Originally Posted by TravisT

it seems to me that there should be some way to short circuit this to just look for relatively prime or not, instead of finding out the greatest common divisor.

The definition of relative primality of x and y is GCD(x,y) = 1. The only remaining issues are how fast one can do a GCD, and how best to test RP among more than 2 integer inputs.

doing GCD's seems like factoring a number to see if it is prime ..

While a GCD may superficially look like a kind of factorization, it is in fact algorithmically completely different, and can be done much faster. To factor an N-digit integer takes exponential time, i.e. the amount of work needed grows faster than any finite power of the number of digits N. The fastest GCD algorithms, on the other hand, need just algebraic time, in fact they need only order of N*(log N)^2 work. That is only slightly larger than (say) a fast FFT-based multiply needs. (In fact a fast GCD involves O(log N) FFT-based muls, each of which needs O(N*log N) work, and multiplying these two together gives the overall cost.) Even a naive GCD needs just O(N^2) work.

Originally Posted by apocalypse

Why don't we need N choose 2 gcd's. Or are we not talking about pairwise relatively prime numbers?

I believe there are some optimizations to be gained by processing all N vectors in parallel - for one, we don't need to save a copy of any of the inputs. But I wouldn't expect a huge speedup from this, perhaps at most a factor of ~2.

The Gnu MP package has fast GCD algorithms of various kinds (and both regular and "extended" GCDs - the latter are handy for finding modular inverses).

[Orgasmic Troll]

Forest. Trees.

I'm not talking about the algorithmic details, I know that finding the GCD and factoring are very different, I meant that finding the GCD in the context of testing integers to be RP is akin to factoring a number to prove primality. The definition of a prime number is a number that has only itself and 1 as factors, but that doesn't mean you have to check every number between 1 and p and see if it is a factor, or even factor p to find out it is prime ..

what I'm saying is that if you find GCD(36,45) you get 9, but if you just wanted to know if 36 and 45 are relatively prime, getting 9 is extraneous information .. all you need is one bit of information,where RP(36,45) = false

Perhaps the algorithms for GCD are so fast that this isn't a practical issue, but it still might provide some interest. (Finding a polynomial-time primality proving algorithm is of interest, despite the fact that there are more optimized algorithms out there, again, I'm speaking conceptually)

[apocalypse]

IIRC the Euclidean Algorithm for computing GCD is O(n*lg n) in the size of the input, so you are not likely to get much faster than that.

[cheesehead]

Originally Posted by TravisT

The definition of a prime number is a number that has only itself and 1 as factors, but that doesn't mean you have to check every number between 1 and p and see if it is a factor, or even factor p to find out it is prime ..

That's only because it is possible to distinguish primes from composites by methods which do not involve factoring.

The situation for relatively prime numbers is not analogous. For a given number, the property of being relatively prime to another number is a less fundamental property than the property of being prime itself. So AFAIK no one has found any method of distinguishing relatively prime numbers from relatively nonprime numbers that is simpler than calculating the GCD and comparing that to 1.

Originally Posted by TravisT

what I'm saying is that if you find GCD(36,45) you get 9, but if you just wanted to know if 36 and 45 are relatively prime, getting 9 is extraneous information .. all you need is one bit of information,where RP(36,45) = false

... and you get that one bit of information by comparing the 9 to 1, so the 9 is not completely extraneous.