## ABC Conjecture

### September 18, 2012

The ABC Conjecture has recently been in the news on math blogs because of the claim that it has been proved by Shinichi Mochizuki. Though the proof is being taken seriously, due to Mochizuki’s reputation, it is five hundred pages long, and confirmation will take several months. The conjecture states that given two positive integers *a* and *b* and their sum *c* with no common factors, the product of the distinct prime factors of *abc* is rarely much smaller than *c*.

The *radical* of a number *n* is the product of the distinct prime factors of *n*; for instance, rad(18) = 6 because 18 = 2 × 3 × 3 and, eliminating the duplicate occurrence of 3, 2 × 3 = 6. The *quality* of an (*a*,*b*,*c*) triple is given by *q*(*a*,*b*,*c*) = log(*c*) / log(rad(*abc*)). The precise statement of the ABC conjecture is that for every ε > 0 there are only finitely many triples (*a*,*b*,*c*) with *a* and *b* coprime positive integers and *a* + *b* = *c* such that rad(*abc*)^{1+ε} < *c*, or equivalently, such that *q*(*a*,*b*,*c*) > 1.

Your task is to write the functions rad and q and find all the triples with *c* < 1000 for which *q*(*a*,*b*,*c*) > 1. When you are finished, you are welcome to read or run a suggested solution, or to post your own solution or discuss the exercise in the comments below.

Pages: 1 2

A python version. I left out code for gcd and prime factors

Haskell version of the suggested solution. Uses primes and factorization algorithm taken from the haskellwiki

[…] make a long story shorter, there was a challenge on Programming Praxis that intrigued me, which was to write code that given a upper bound on c would generate a list of […]

A Java solution:

I went with quick and easy, using Racket’s excellent

`for*/list`

macro to generate the final step. Interestingly, although it just brute forces the problem rather than the “smarter” solution posted here, it actually runs about 20% faster on the n=1000 case than the code posted here (on the same machine and the same environment). Not entirely sure why, although I am curious if anyone has any thoughts.In any case, you can see my version on my blog.

This algorithm is still to slow to solve http://projecteuler.net/problem=127