The sixth taxicab number is 24153319581254312065344

March 9, 2008

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).
• 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³ + 28906206³
  • 3064173³ + 28894803³
  • 8519281³ + 28657487³
  • 16218068³ + 27093208³
  • 17492496³ + 26590452³
  • 18289922³ + 26224366³
  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 www.korgwal.com/ramanujan/:

• the five-way (or higher) numbers
• the four-way (or higher) numbers
• the three-way (or higher) numbers
• those two-way (or higher) numbers which are equal to 42 mod 100
• 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³ + 1242³ = 484³ + 1217³ = 969³ + 1002³
• 18778674824 = 8³ + 2658³ = 575³ + 2649³ = 1899³ + 2285³
• 18212205591125 = 5³ + 26310³ = 8628³ + 25997³ = 18765³ + 22640³
• 78543521477001945 = 9³ + 428256³ = 107392³ + 425993³ = 242226³ + 400689³

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³ + bi³ for each pair (ai,bi).

Here are copies of the programs:

• 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.
• verify 1: check that sums of cubes of given components add up to ramanumber
• verify 2: independently generate components for a given ramanumber candidate
• verify 3: Haskell version of range scanner
• 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
amateur numerologist
March 2008