When Ordinary Calculators Give Up: Big Number Arithmetic

Type 2^100 into a phone calculator and you get an answer that is right to eight digits and wrong for every purpose that needs more. The machine has not made a mistake exactly. It has run out of room and rounded, quietly, without telling you.

Where fifteen digits runs out

Nearly every calculator, spreadsheet and programming language uses double precision floating point by default. That format sets aside 53 bits for the digits themselves, which works out at about 15 to 17 decimal digits of precision. Everything beyond that is approximated.

The 2 to the 53 wall

The first integer a double cannot represent is 9007199254740993, which is 2^53 plus one. Ask a standard calculator for it and you get 9007199254740992 back. It is not a display rounding, the odd number genuinely does not exist in that format. Above the wall, doubles can only store even numbers, then only multiples of four, and the gaps keep widening.

Factorials hit the ceiling early. 20 factorial is 2432902008176640000, which still fits inside a 64-bit signed integer. 21 factorial is 51090942171709440000, which is more than five times the maximum 9223372036854775807 that type can hold. By 25 factorial you are at 26 digits, and 100 factorial has 158 of them. A big number calculator prints every one; a normal one gives you a mantissa and an exponent.

What all those digits are for

This is not purely a curiosity. Several ordinary things depend on exact arithmetic that overflows a calculator.

Public key cryptography is the clearest case. A 2048-bit RSA key is a number roughly 617 decimal digits long, and every operation on it has to be exact, because a single rounded digit produces a key that decrypts nothing. Bank account validation is another. A 22 character UK IBAN is rearranged, each letter is swapped for a two digit code, and the 28 digit number that results has to leave a remainder of 1 when divided by 97. That is nine digits more than a 64-bit integer can hold, so a mistyped account number is only caught if the arithmetic stays exact.

Money is the everyday version

Financial software stores amounts as integers of the smallest unit, pennies or cents, precisely to avoid floating point. Ask any calculator for 0.1 plus 0.2 with enough decimal places shown and you get 0.30000000000000004, because neither tenth has an exact binary form. One stray fraction of a cent is harmless; a billion transactions of it is an audit. That is a different failure from the ones in everyday calculator work, where 15 digits is far more than anyone needs.

Using the big number calculator

Paste or type the operands in full, with no commas, no spaces and no scientific notation. If you paste 1.2676506e30 you have already lost the digits, and the tool cannot invent them back.

Pick the operation from the list: add, subtract, multiply, divide, modulo, or raise to a power. Exponents are the fastest way to produce something enormous, so start modestly. 2^1000 returns a 302 digit number instantly, while asking for 2^10000000 will make any browser think hard.

Division is the input to watch. Integer division returns a whole quotient and a remainder rather than a decimal, so 100 divided by 7 gives 14 remainder 2. If you want 14.2857, that is a job for a graphing or scientific calculator instead. Big number tools are built for exactness, and exactness and decimals pull in opposite directions.

Common questions

Why does my phone show E+ numbers? That is scientific notation, and it appears when the result no longer fits the display's digit budget. 1.2676506e30 means 1.2676506 multiplied by 10 to the power 30. The first eight digits are accurate and the remaining 23 have been thrown away.

Is there a limit to how big a number it can handle? In principle only memory and patience. In practice a browser based tool will happily handle thousands of digits and start to lag on multiplications of very large operands, because the work grows faster than the digit count does.

Can it work with decimals? Most versions are integer only. The workaround used in real systems is to scale: to multiply 1.23 by 4.56 exactly, multiply 123 by 456 to get 56088, then place the decimal point four positions from the right for 5.6088.

Why is 0.1 plus 0.2 not exactly 0.3? Because binary cannot write one tenth as a finite fraction, in the same way decimal cannot write one third. The stored value is a fraction slightly above 0.1, and the error surfaces once you show enough decimal places.