なぜ 0.1 + 0.2 は 0.30000000000000004 になるのか

2進数では 0.1 を正確に表せないからです。 1/3 を10進数で書くと 0.333… と終わらないのと同じことが、0.1 に起きています。

console.log(0.1 + 0.2);
console.log(0.1 + 0.2 === 0.3);

console.log((0.1).toPrecision(20));
console.log((0.2).toPrecision(20));
console.log((0.3).toPrecision(20));

これは JavaScript の不具合ではありません。IEEE 754 の倍精度を使う言語では Python でも Java でも C でも同じ結果になります。

実際に何が入っているのか

0.1 の中身をもっと桁数を出して見ます。

console.log(0.5 + 0.25 === 0.75);
console.log((0.5).toPrecision(20));
console.log((0.1).toPrecision(20));

console.log(Number.MAX_SAFE_INTEGER);
console.log(Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2);
console.log(9007199254740993);
console.log(Number.isSafeInteger(9007199254740993));

0.1 は少しだけ大きく、0.3 は少しだけ小さく保存されています。 0.1 + 0.2 はわずかに大きい側に寄るので、0.3 と一致しません。

画面に 0.1 と出るのは、そう見えるように丸めているからです。 中身は最初から 0.1 ではありません。

正確に表せる数もある

2進数で書ける小数、つまり2の冪の和で作れる数は正確です。

console.log(9007199254740991n + 2n);
console.log(typeof 9007199254740991n);

const a = 0.1 + 0.2;

console.log(a === 0.3);
console.log(Math.abs(a - 0.3) < Number.EPSILON);

0.5 は 1/2、0.25 は 1/4 なのでぴったり入ります。 0.1 は 1/10 で、2進数では割り切れません。

整数はどこまで正確か

小数と違い、整数はある大きさまで正確です。

const a = 1e10 + 0.1;
const b = 1e10 + 0.2;

console.log(Math.abs(a - b) < Number.EPSILON);
console.log(a - b);

function nearlyEqual(x, y, rel = 1e-9) {
  return Math.abs(x - y) <= rel * Math.max(Math.abs(x), Math.abs(y), 1);
}

console.log(nearlyEqual(0.1 + 0.2, 0.3));
console.log(nearlyEqual(1e10 + 0.1, 1e10 + 0.1));
console.log(nearlyEqual(1, 2));

9007199254740991（約9千兆）を超えると、隣り合う整数を区別できなくなります。 +1 と +2 が等しくなっているのがその証拠です。

3行目に注目してください。書いた数と、出てきた数が違います。 …993 は表せないので、リテラルを書いた時点でいちばん近い …992 に置き換わっています。

大きな整数を正確に扱うなら BigInt です。

console.log((0.1 * 10 + 0.2 * 10) / 10 === 0.3);
console.log(Math.round(0.1 * 10) + Math.round(0.2 * 10) === 3);

let a = 0;
for (let i = 0; i < 10; i++) a += 19.99;

let b = 0;
for (let i = 0; i < 10; i++) b += 0.7;

console.log(a, a === 199.9);
console.log(b, b === 7);

どう比べればよいか

誤差を許して比べる

差が十分小さければ同じとみなします。Number.EPSILON は 1 の隣の数との差で、この種の判定によく使われます。

let total = 0;

for (let i = 0; i < 10; i++) {
  total += 1999;
}

console.log(total);
console.log(`${Math.floor(total / 100)}.${String(total % 100).padStart(2, '0')}`);

console.log((1.005).toFixed(2), (1.005).toPrecision(20));
console.log((1.015).toFixed(2), (1.015).toPrecision(20));
console.log((1.025).toFixed(2), (1.025).toPrecision(20));
console.log((2.675).toFixed(2), (2.675).toPrecision(20));

ただしこれは小さい数でしか通用しません。 数が大きくなると、誤差そのものが大きくなります。

function round2(n) {
  return Math.round(n * 100 + Number.EPSILON * n * 100) / 100;
}

console.log(round2(1.005));
console.log(round2(1.015));
console.log(round2(1.025));

console.log(0.1);
console.log(0.1 === 0.1000000000000000055511151231257827);

大きさに合わせて許容量を変える必要があります。

console.log(0.1 + 0.1);
console.log(0.1 + 0.1 + 0.1);
console.log((0.1 + 0.1 + 0.1).toPrecision(20));

整数にしてから比べる

そもそも小数にしない方法もあります。これがいちばん確実です。

お金は小数で持たない

金額を 19.99 のような小数で持つと、足すたびに誤差が出る……とは限りません。 ここが厄介なところです。

19.99 を10回足すとぴったり合い、0.7 を10回足すとずれます。

どちらになるかは値によって変わり、見ただけでは分かりません。 「試したら合っていた」は何の保証にもなりません。手元で通ったものが、別の値でずれます。

だから最小単位の整数で持ってください。円なら円、ドルならセントです。

toFixed は思ったとおりに丸まらない

「見せるときだけ丸めればいい」も、そのままでは通りません。

4つとも切り下がっています。 どれも中身が見た目よりわずかに小さいからです。 1.005 の実体は 1.00499999999999989… なので、 四捨五入して 1.00 になるのが正しい動きです。

toFixed() が間違っているのではありません。渡している数が、もう 1.005 ではないのです。

「見た目の値」で四捨五入したいなら、誤差を足し戻してから丸めます。

これも万能ではありません。金額を扱うなら、最初から整数で持つのが確実です。

よくある誤解

JavaScript だけの問題だと思っている

IEEE 754 の倍精度を使う言語すべてで起きます。 0.1 を正確に持てる言語は、10進数の型を別に用意しています （Java の BigDecimal、Python の decimal など）。

表示された値が中身だと思っている

console.log(0.1) が 0.1 と出るのは、 その値に戻る最短の10進表記を選んで表示しているからです。

同じ値です。 見た目が違うだけです。

誤差は「たまに」出ると思っている

0.1 を足すたびに毎回ずれています。表示のときに隠れているだけです。

2回足したときは表示上ちょうど 0.2 ですが、 3回足すと隠しきれなくなって出てきます。

同じ IEEE 754 が決めている NaN の振る舞いは なぜ NaN === NaN は false なのか にあります。

「等しい」をどう判定するかという話は、== と === の違いにも繋がります。 → なぜ == ではなく === を使うのか