Binary Encoding vs Decimal Encoding

When to store and compute numbers in raw binary (IEEE 754 floats, two's-complement ints) versus base-10 decimal types — and why the answer is not "whatever your language defaults to."

The actual disagreement

This isn't binary-the-format versus some exotic rival — it's how you represent fractional and large numbers. Binary encoding means IEEE 754 floats and two's-complement integers: the machine's native tongue. Decimal encoding means base-10 types — IEEE 754-2008 decimal64/128, SQL NUMERIC, Java BigDecimal, Python's Decimal — that store digits the way humans write them. The whole fight lives in the fractional gap: 0.1 has no finite binary representation, so a float stores 0.1000000000000000055. Binary doesn't care; it's fast and approximate by design. Decimal stores exactly 0.1, slower and exact by design. Everything downstream — money bugs, ML throughput, storage cost — follows from that single choice. People who treat this as a style preference ship rounding errors into invoices. It's an engineering decision with a correct answer per field, and most teams never make it deliberately.

Where binary earns the default

Binary is the right default and it isn't close. It's hardware-native — your CPU, GPU, and SIMD units operate on IEEE 754 directly, so floats and ints are single-cycle fast while decimal arithmetic is emulated in software, often 10-100x slower. It's dense: a float64 is 8 bytes; a decimal128 is 16 and BigDecimal is a heap-allocated object graph. Every domain that moves real volume runs on binary: machine learning (the entire field is float32/bfloat16), graphics, simulations, signal processing, telemetry, hashing, IDs. The 0.1 + 0.2 = 0.30000000000000004 meme is real but almost always irrelevant — for measured, statistical, or approximate quantities, the rounding error is smaller than your sensor noise. Demanding exact decimal for a temperature reading is theater. Binary is what you reach for unless a specific, nameable requirement forces you elsewhere.

Where decimal is non-negotiable

Decimal isn't a nicety for money — it's mandatory, and 'just use floats and round at the end' is how you get a one-cent discrepancy that fails an audit. Currency, tax, interest, and billing are defined in base 10 with statutory rounding rules; binary literally cannot represent $0.10 exactly, so errors accumulate across millions of line items and a reconciliation breaks. Decimal types give exact base-10 arithmetic and explicit rounding modes (banker's rounding, ROUND_HALF_EVEN) that match what regulators expect. Same logic for anything legally exact: financial ledgers, GAAP/IFRS reporting, some scientific results that must reproduce bit-for-bit in base 10. The cost is real — slower math, bigger storage, allocation pressure, and APIs that force you to think about scale and context. You pay it because the alternative is being wrong in a way that costs money and trust. Note the cheap trick: store money as integer minor units (cents) and you get exact base-10 in plain binary integers — often the best of both.

The mistake almost everyone makes

The failure mode isn't picking wrong — it's never picking at all. Teams inherit the language default (float in JS, double in Java, NUMERIC in Postgres) and let it ride across every field. JavaScript is the worst offender: it has exactly one number type, a float64, and people compute prices in it until QA finds the penny. The discipline is per-field, not per-project. Money and legally-exact values get decimal or scaled integers. Everything else — measurements, scores, coordinates, model weights — gets binary. Don't 'upgrade everything to BigDecimal to be safe'; you'll torch performance to solve a problem 95% of your fields don't have. And don't store money as a float because 'it's probably fine.' It isn't. Decide at the schema and type-declaration level, document why, and the binary-vs-decimal question stops being a recurring bug and becomes a one-time design call you got right.

Quick Comparison

Factor	Binary Encoding	Decimal Encoding
Exactness for base-10 values (money)	Cannot represent 0.1 exactly; rounding error accumulates	Exact base-10 arithmetic with explicit rounding modes
Performance / hardware support	Native CPU/GPU/SIMD, single-cycle ops	Software-emulated, often 10-100x slower
Storage density	4-8 bytes, fixed width	16+ bytes or heap-allocated object graphs
Ecosystem default / ubiquity	Default everywhere: ML, graphics, telemetry, IDs	Specialist: finance, billing, regulated reporting
Audit / regulatory fit	Fails reconciliation on accumulated cent errors	Matches statutory rounding, audit-friendly

The Verdict

Use Binary Encoding if: You're doing anything that isn't legally-binding base-10 arithmetic: scientific computing, ML, graphics, telemetry, IDs, hashing, general application logic, or anything performance-sensitive.

Use Decimal Encoding if: You're handling money, tax, billing, or any value where 0.1 + 0.2 must equal exactly 0.30 and a regulator or auditor will check your rounding.

Consider: Many systems need both: binary for compute-heavy paths, decimal (or scaled integers) at the money boundary. Pick per field, not per codebase.

Binary Encoding vs Decimal Encoding: FAQ

Is Binary Encoding or Decimal Encoding better?

Binary Encoding is the Nice Pick. Binary wins because it is the default for a reason: it is faster, denser, and hardware-native for the overwhelming majority of numeric work. Decimal is a specialist tool — mandatory for money and regulated arithmetic, useless everywhere else. "Use the specialist tool only when the spec demands it" makes binary the correct default, and defaults are what a pick is about.

When should you use Binary Encoding?

You're doing anything that isn't legally-binding base-10 arithmetic: scientific computing, ML, graphics, telemetry, IDs, hashing, general application logic, or anything performance-sensitive.

When should you use Decimal Encoding?

You're handling money, tax, billing, or any value where 0.1 + 0.2 must equal exactly 0.30 and a regulator or auditor will check your rounding.

What's the main difference between Binary Encoding and Decimal Encoding?

When to store and compute numbers in raw binary (IEEE 754 floats, two's-complement ints) versus base-10 decimal types — and why the answer is not "whatever your language defaults to."

How do Binary Encoding and Decimal Encoding compare on exactness for base-10 values (money)?

Binary Encoding: Cannot represent 0.1 exactly; rounding error accumulates. Decimal Encoding: Exact base-10 arithmetic with explicit rounding modes. Decimal Encoding wins here.

Are there alternatives to consider beyond Binary Encoding and Decimal Encoding?

Many systems need both: binary for compute-heavy paths, decimal (or scaled integers) at the money boundary. Pick per field, not per codebase.

The Bottom Line

Binary Encoding wins

Binary wins because it is the default for a reason: it is faster, denser, and hardware-native for the overwhelming majority of numeric work. Decimal is a specialist tool — mandatory for money and regulated arithmetic, useless everywhere else. "Use the specialist tool only when the spec demands it" makes binary the correct default, and defaults are what a pick is about.

Related Comparisons