Talk:Taxicab numbers

Not how Wolfram defines Taxicab numbers

In http://mathworld.wolfram.com/TaxicabNumber.html it says a Taxicab number has to be defined n ways, not just 2 ways. So at minimum, this may be a bad title. --TimToady (talk) 05:45, 14 March 2014 (UTC)

Yes, I'm aware that Wolfram's MathWorld (TM) defines taxicab numbers differently than OEIS does (well, only in part). OEIS also used this alternative definition as A11541. OEIS entry A1235 is the one that is used for a model: Taxi-cab numbers: sums of 2 cubes in more than 1 way. I specifically noted that this (more or less) is the definition used here in this task. If OEIS defines it thusly, I saw no reason not to use that name — albeit there are two different definitions, but that isn't unusual to have multiple (conflicting) definitions. The major difference is that the OEIS A1235 sequence definition omits the (non-)usage of negative numbers (for the cubes), but from the context, he (or they) only used positive integers when generating that OEIS list. Using the OEIS A11541 definition would be beyond the scope of most programs or computers for most, I would think, the numbers almost look rarer than hen's teeth. -- Gerard Schildberger (talk) 07:17, 14 March 2014 (UTC)

Extra credit discrepancy

Extra credit answers of Python and Rexx do not agree. If you swap the commented sumcubes line in and use it instead of the line above in the Python solution I can derive exactly the same Python result by explicitly counting the sets of different ways forming the sums of two cubes. --Paddy3118 (talk) 08:42, 14 March 2014 (UTC)

I don't quite fully understand what you just wrote (two things). Did you say if you swap a Python statement around, it produces the same result as the REXX extra-credit solution? The other thing I don't understand is what sets Python is counting (sets of two sums of cubes?). Are you saying something about 1+3 is the same set as 3+1? Since the REXX solution has lower numbers than the Python solution (in the 2,000 range extra-credit thingy), I suspect one reason may be that the REXX version is computing more taxicab numbers, and since they are out of order, the more taxicab numbers are generated, the more likely chance that a lower taxicab number would be found. One method of resolving this would be for me to (re-)generate the list, but this time, list all 2,007 numbers (and look for mirror sums. There shouldn't be any, but I've been wrong before (once or twice ...). By the way, a nit ... The Python is one number short. … List the 2,000^th plus a half-dozen more, that is, for a total of seven highish taxicab numbers. Not worthy of a flag. I thought I had asked for an index number, but I had forgotten to include it in the task requirement (so everyone could see what the 20th taxicab number is without counting from the top). -- Gerard Schildberger (talk) 09:07, 14 March 2014 (UTC)

The OEIS A001235 b-file gives the extra credit answers as

2000 1671816384
2001 1672470592
2002 1673170856
2003 1675045225
2004 1675958167
2005 1676926719
2006 1677646971
2007 1680918365

—Sonia (talk) 16:43, 14 March 2014 (UTC)