The sixth taxicab number is 24153319581254312065344

Dear number theorists,

I am pleased to announce that, subject to a couple of small caveats, I
have verified that 24153319581254312065344 is the sixth taxicab number.

What are the caveats?

  * I have not scanned the entire range of values from 1 to 1e21:
    while I have scanned parts of this range, I am relying on the
    previously-published report by Durango Bill that he has scanned
    all of that range, and found no new value for Ta(6).
    (http://www.durangobill.com/Ramanujan.html)

  * My computers could have screwed up. This calculation is big enough
    that it's not inconceivable that there could have been undetected
    transient hardware errors.

  * I could have screwed up. Although I have carefully examined the
    programs I used to do this scan, it is still possible that some
    undetected bug remains.

What have I done?

  * I have scanned the entire range of numbers from 1e21 to 2.4153...e22,
    and parts of the range from 1 to 1e21.  I do intend to complete the
    scan of the lower range, as there are some sequences in the On-Line
    Encyclopedia of Integer Sequences that I want to extend. In performing
    this scan, I kept all primitive two-way or higher Ramanujan numbers;
    more below on what I found.

  * In order to attempt to catch screwups by either my electronic minions
    or myself, I repeated parts of the scan with different programs than
    I had used for the main scan; again, more below.

The main findings:

  * 24153319581254312065344, first reported by Rathbun in 2002, with
    the six different representations

      582162^3 + 28906206^3
      3064173^3 + 28894803^3
      8519281^3 + 28657487^3
      16218068^3 + 27093208^3
      17492496^3 + 26590452^3
      18289922^3 + 26224366^3

    is indeed Ta(6).

  * Contrary to previous expectations, I found just four other five-way
    numbers in the range from 1e21 to Ta(6):

      1199962860219870469632
      2337654192461288064000
      7413331235096863544832
      9972542662841658461688

    These were all already known; they are small multiples of smaller
    four-way numbers.

  * In the range from 1e21 to Ta(6), I found 305 four-way (or higher)
    numbers, 17145 three-way (or higher) numbers, and approximately 141
    million two-way (or higher) numbers. (As I write this, I have not
    consolidated all of the partial files, roughly 8 GB total, and their
    ranges overlap very slightly, so I only have an approximate count for
    the two-way numbers.)

The main scan was done using a hash-bucket approach similar to that used by
Durango Bill; like him, I started out following David Wilson's heap-based
approach, and I too found that this was significantly slower than the
hash-bucket approach. I attempted to speed up the heap-based program by
performing calculations mod N (ie, every number in the heap is equal to the
same K mod N. While this worked very well to parallelize the calculations,
it did not improve the overall speed; however, as a check on the main
calculation it proved very effective.

I made several heap runs with different values of K mod 1601 and compared
the results of these with the corresponding values extracted from the main
dataset; I found no differences from the main calculation.

I made another series of heap runs, this time without doing calculations mod
N, as spot-checks on small sub-ranges; again, I found no differences from
the main calculation.

I wrote a couple more programs to perform other checks: first, a trivial
check to verify that each recorded number is indeed expressed correctly as
the sum of the cubes of the two recorded components, for all pairs of
components, and second, a check to see that no components are missing -- in
part to check my main scanners, but in part also to check hardware glitches,
on the theory that if a hardware glitch might have destroyed part of the
data for a number as it was being processed, some partial output might still
appear, and thus a five-way sum might be erroneously recorded as a three-way
or a four-way sum. Obviously, this won't catch all hardware glitches, but
it's better than nothing.

In order to try and keep from introducing common bugs into all programs, I
wrote these last two programs in Haskell; the first two main scanners were
written in C. The two Haskell programs were not run against all the two-way
numbers, only against the three-way or higher numbers. Again, I found no
differences between the results.

I also wrote a Haskell implementation of something similar to the
hash-bucket scanner; that works, but is too slow to provide a realistic
check against the main hash-bucket scanner. However, in the small ranges
where I ran both, there were no differences in the results.

I have placed copies of several data files onto my website at
http://www.korgwal.com/ramanujan/:

  * http://www.korgwal.com/ramanujan/quints.dat
    the five-way (or higher) numbers

  * http://www.korgwal.com/ramanujan/quads.dat
    the four-way (or higher) numbers

  * http://www.korgwal.com/ramanujan/triples.dat
    the three-way (or higher) numbers

  * http://www.korgwal.com/ramanujan/numbers_42mod100.dat
    those two-way (or higher) numbers which are equal to 42 mod 100

  * http://www.korgwal.com/ramanujan/fermat_misses.dat
    those two-way numbers which have one representation as 1 + A^3, ie,
    those for which A^3 is almost equal to B^3 + C^3: Fermat near-misses.

I looked for three-way Fermat near-misses, but found none with a "miss"
as small as 1: the only three-way numbers I found where one component is
less than 10 are:

  * 1915865217 = 9^3 + 1242^3
               = 484^3 + 1217^3
               = 969^3 + 1002^3

  * 18778674824 = 8^3 + 2658^3
                = 575^3 + 2649^3
                = 1899^3 + 2285^3

  * 18212205591125 = 5^3 + 26310^3
                   = 8628^3 + 25997^3
                   = 18765^3 + 22640^3

  * 78543521477001945 = 9^3 + 428256^3
                      = 107392^3 + 425993^3
                      = 242226^3 + 400689^3

There may still be some in the un-scanned portion of [1 .. 1e21].

In all of the above data files, the format is

  sum a1 b2 a2 b2 ...

where sum = ai^3 + bi^3 for each pair (ai,bi).

Here are copies of the programs:

  * http://www.korgwal.com/ramanujan/arith4.c
    the main hash-bucket scanner: this uses GMP to format the
    ramanumbers for output, but can be built entirely by itself:
    in that case, the ramanumbers are printed as uint64:uint32.

  * http://www.korgwal.com/ramanujan/verify1.hs
    check that sums of cubes of given components add up to ramanumber

  * http://www.korgwal.com/ramanujan/verify2.hs
    independently generate components for a given ramanumber candidate

  * http://www.korgwal.com/ramanujan/verify3.hs
    Haskell version of range scanner

  * http://www.korgwal.com/ramanujan/Makefile
    a small Makefile: it uses gcc for the main scanner and ghc for
    the Haskell verifiers

I have not placed a copy of the entire two-way-or-higher dataset onto my
website. While I'm happy to share it with anyone who would like a copy, I
don't have the bandwidth either at home, to upload it, or on the website,
for others to download it. If someone would like a copy, please contact me
and we'll work out a way to get it to you. If you are in the Silicon Valley
area, it should be relatively easy to achieve that.

A portion of these calculations was done using some of the idle cycles of an
old Itanium server at my previous employer, ASML MaskTools (later, both it
and I were acquired by my current employer, Brion Technologies, an ASML
company). I thank them for these idle cycles. Other participating computers
included a Sun server with a couple of Opteron CPUs, a couple of Pentium
PCs, and an old iMac G3. In a moment of madness, I began to port the main
scanner program to a Soekris net4801 which serves as my firewall, but I was
stopped by the lack of GMP on that computer, and sanity returned before I
had finished building it.

Uwe Hollerbach  <uhollerbach@...>
amateur numerologist
March 9, 2008