Integers, Overflow, and Floating Point

Fixed sizes

On paper, numbers go on forever. In a computer, each number is stored in a fixed number of bits, chosen in advance: registers in the processor are a fixed width, usually 64 bits, and every value takes space ¹. With n bits, an unsigned number (never negative) can be anything from 0 to 2ⁿ − 1 ¹:

That’s the whole story for unsigned numbers. Negative numbers need a trick.

Negative numbers

Nearly every computer stores signed integers in two’s complement ¹. The leftmost bit still counts as a place value, but a negative one: in 4 bits, the places are −8, 4, 2, 1 ¹. So:

• 0111 is 4 + 2 + 1 = 7, the largest positive value;
• 1000 is −8, the smallest;
• 1111 is −8 + 4 + 2 + 1 = −1.

A leftmost 1 means negative, and there’s exactly one zero, all bits 0 ¹. With n bits the range is −2ⁿ⁻¹ to 2ⁿ⁻¹ − 1: 4 bits give −8 to 7, 8 bits −128 to 127 ¹.

To negate a number: flip every bit and add one ¹. For 13 in 8 bits, 00001101, flipping gives 11110010, and adding one gives 11110011, which is −13. The design pays off in hardware: subtracting 3 is adding −3, so a processor can reuse its negation and addition circuits instead of building a separate subtractor, and −1 + 1 rolls over to exactly zero ¹.

Overflow

When a result needs more bits than there are, it overflows. The leftover carry is lost, and the value wraps around, like a car’s odometer rolling from 999999 to 000000 ¹. In 4 bits, 7 + 1 gives 1000, which is −8.

bash does its arithmetic in the largest fixed-width integers available, 64 bits on current computers, with no check for overflow ², so you can watch it happen:

me@linuxbox:~$ echo $((2**63 - 1))
9223372036854775807
me@linuxbox:~$ echo $((9223372036854775807 + 1))
-9223372036854775808

The largest 64-bit signed integer, plus one, wraps to the most negative. No error, no warning: a program that doesn’t expect it just carries on with a wrong number. Real bugs have come from exactly this, and it’s why careful code checks ranges.

Python’s integers don’t overflow: they grow to as many bits as they need.

me@linuxbox:~$ python3 -c 'print(2**64)'
18446744073709551616

Floating point

Fractions are a different problem. A floating-point number stores a binary fraction, with about 53 significant bits ³. Just as 1/3 has no exact decimal form (0.333…), most decimal fractions have no exact binary form. In binary, 1/10 is a repeating fraction, 0.000110011001100110011…, so 0.1 is stored as the nearest value that fits ³:

me@linuxbox:~$ python3 -c 'print(f"{0.1:.20f}")'
0.10000000000000000555

The stored value is actually 0.1000000000000000055511151231257827021181583404541015625 ³. Python normally prints a short version that reads back to the same value, so you rarely see it, until the tiny errors add up:

me@linuxbox:~$ python3 -c 'print(0.1 + 0.2)'
0.30000000000000004
me@linuxbox:~$ python3 -c 'print(0.1 + 0.2 == 0.3)'
False

This isn’t a Python quirk: it’s how binary floating point behaves in every language ³.

Three practical rules follow:

• Don’t compare floats with ==. Ask whether they’re close ³:

  me@linuxbox:~$ python3 -c 'import math; print(math.isclose(0.1 + 0.2, 0.3))'
  True
  

• For money, don’t use floats. Count whole cents as integers, or use Python’s decimal module, which does decimal arithmetic exactly ³:

  me@linuxbox:~$ python3 -c 'from decimal import Decimal; print(Decimal("0.1") + Decimal("0.2"))'
  0.3
  

• Huge floats lose whole numbers. With 53 significant bits, past 2⁵³ a float can’t even hold every integer:

  me@linuxbox:~$ python3 -c 'print(2**53, 2**53 + 1.0)'
  9007199254740992 9007199254740992.0
  

  Adding 1.0 to 2⁵³ changes nothing; the 1 falls off the end.

Your turn

So

Numbers live in fixed numbers of bits: n bits hold 0 to 2ⁿ − 1 unsigned, or −2ⁿ⁻¹ to 2ⁿ⁻¹ − 1 in two’s complement, where the top bit counts negative and you negate by flipping and adding one. Results that don’t fit overflow and wrap around, silently, as bash’s 64-bit arithmetic shows; Python’s integers just grow. Floating point stores binary fractions with 53 significant bits, so 0.1 is only approximate and 0.1 + 0.2 isn’t 0.3: compare with math.isclose, keep money in whole cents or decimal, and remember huge floats can’t hold every integer.