Ah, good old integer rounding...

Strangely, typing this into Google does NOT result in 42

((-80538738812075974)^3)+(80435758145817515^3)+(12602123297335631^3)

DDG doesn't handle it correctly either (gives the same very-large answer as Google). I assume there's some sort of integer overflow going on somewhere. Wolfram Alpha does ok, though: https://www.wolframalpha.com/input/?i=%28%28-805387388120759...

Google and Duckduckgo use floating point rather than arbitrary precision integers. Wolfram Alpha's solver is significantly more advanced (including arbitrary precision for integers and floating point numbers)

I’m actually surprised someone at Google hasn’t switched to BigInt yet in JS if the browser supports it? Googlers, front page OKR time! :)

If you're typing it into google on a desktop browser, open your JS console. As earlier comments pointed out, in JavaScript it's

  (-80538738812075974n)**3n + 80435758145817515n**3n + 12602123297335631n**3n

Surprisingly, the calculator that shipped with my phone seems to handle it well.

for big numbers you can use bc (infix) or dc (rpn) calculator:

echo '((-80538738812075974)^3)+(80435758145817515^3)+(12602123297335631^3)' | bc

echo '_80538738812075974 3 ^ 80435758145817515 3 ^ 12602123297335631 3 ^ + + p' | dc

Nice! My go to calc is dc. If you're like me at all, then you might like to know that we can avoid the pipe usng the -e switch

    $ dc -e '_80538738812075974 3^ 80435758145817515 3^+ 12602123297335631 3^+p'

WolframAlpha should handle it fine, with Mathematica behind the scenes.

python handles big int automatically:

sh-4.2$ python -c "print(-805387388120759743+804357581458175153+126021232973356313)" 42

Hn seems to have stripped the asterisks from your message.

nah, bigint is just another wall you may hit

bc/dc arbitrary precision calculators are usually installed by default on *nix platforms and they handle numbers with thousands of digits

$ time echo '12345^67890' |bc |wc -c

285941

real 0m2.137s

user 0m2.128s

sys 0m0.012s

Python's default number implementation has full support for arbitrarily large numbers, and will allocate more memory as needed to do so, making the original claim correct.

With negative numbers, it's still enumerable, as if it were a six-tuple of natural numbers, I figured.

Maybe I'm looking at this the wrong way, but I'd handle enumerating this just like enumerating a set of three numbers. For an integer i just do (1-2(i%2)) * (i/2) using integer division. If it's recursively enumerable with natural numbers then it has to be trivially extendable to all integers just by that method alone.