Primitives & Numbers

There's no such thing as "a number" in a computer. There are several very different types that all happen to look like numbers, and picking the wrong one will burn you.

Analogy

Think of the different measuring tools in a kitchen — they all tell you "how much", but they are wildly different instruments. A set of measuring cups (integers) gives you exact whole units but cannot do half a half. A kitchen scale in grams (floats) gives you any fraction you like, but read it twice and the last digit wobbles. A pharmacist's balance in milligrams (decimals) is painfully slow but perfect for money and medicine. Grabbing the scale to count eggs, or the cup to weigh saffron, ends badly in exactly the ways you'd expect.

Integers

An integer holds a whole number — no fractional part. In fixed-width integer types (C's int32_t, Go's int32, Java's int), you get exactly 32 bits to work with. That means integers live in the range -2,147,483,648 to 2,147,483,647, and adding 1 to the maximum wraps around to the minimum. Silently. No error.

int32_t x = 2147483647;   // INT32_MAX
x + 1;                    // -2147483648, undefined behaviour in C

Python and Ruby integers are arbitrary precision — they grow as needed. 10 ** 100 + 1 just works. The price is speed (operations on big ints are slower) and memory (they take more than 8 bytes).

IEEE 754 floats

A float is a binary scientific notation: sign × mantissa × 2^exponent. The standard is IEEE 754, and a double (64-bit float) has:

• 1 sign bit
• 11 exponent bits (biased by 1023)
• 52 mantissa bits (with an implicit leading 1 for normal numbers)

This gives you about 15–17 decimal digits of precision and a range from 10^-308 to 10^308. But here's the catch: most decimal fractions can't be represented exactly. 0.1 in binary is 0.000110011001100... — infinite repeating. Same for 0.2. When you add them:

0.1 + 0.2 === 0.3;   // false
0.1 + 0.2;           // 0.30000000000000004

This isn't a JavaScript bug. It's how every IEEE 754 implementation works — Python, Java, Go, C, all of them. The fraction 0.1 has no exact binary representation, so what's stored is the nearest double, and adding two nearby-but-imprecise numbers gives you a nearby-but-imprecise sum.

Special float values

Floats have three values that aren't "numbers" in the usual sense:

• Infinity / -Infinity — result of overflow or divide-by-zero
• NaN — "not a number", result of 0/0, sqrt(-1), etc.
• -0 — distinct from +0, surfaces in some edge cases

NaN is famously not equal to itself: NaN === NaN is false. Use Number.isNaN(x) or math.isnan(x) to test for it.

Decimal types

When you need exact decimal arithmetic — money, financial calculations, anything a user sees — use a decimal type:

• Python: from decimal import Decimal
• Java: BigDecimal
• PostgreSQL: numeric(precision, scale)
• .NET: decimal

These store numbers in base 10, so 0.1 + 0.2 is exactly 0.3. They're slower than floats but correct.

Rule: never store money in a float. Use integer cents (1999 for $19.99) or a decimal type.

Signed vs unsigned

An 8-bit unsigned integer (uint8) holds 0 to 255. An 8-bit signed integer (int8) holds -128 to 127. Same 256 possible bit patterns, different interpretations.

JavaScript has no separate integer type — all numbers are doubles, though BigInt was added for arbitrary-precision integers. Bitwise operators coerce to 32-bit signed ints (|0), which is useful when you want C-style integer semantics.

When it matters

• Money: decimal or integer cents, never float.
• IDs: if IDs can exceed 2^53, use BigInt or serialize as string. JSON parsers that cast to Number will corrupt large IDs.
• Coordinates, physics, ML: float is fine. The imprecision is smaller than your input error.
• Hashes, cryptographic values: fixed-width integers (BigInt, Uint8Array). Never float.

The fix for 0.1 + 0.2 !== 0.3 isn't to avoid floats. It's to know when you can tolerate imprecision and when you can't.