プログラミングで数値計算を行う際、開発者はしばしば整数演算からの安全習慣を浮動小数点演算に持ち込みます。ただし、これらの2つのパラダイムは、エッジケースやエラーの扱いにおいて根本的に異なるアプローチを採っています。整数演算では、表現可能な範囲を超える演算は未定義動作やプログラムクラッシュを引き起こすため、問題となる演算を発生させる前に予測し防止することが不可欠です。この考え方から、開発者はオーバーフローやアンダーフローの可能性に対する事前チェックを実装する傾向があります。
IEEE-754標準に従う浮動小数点演算は、例外ケースを異なる方法で扱います。直ちに失敗を引き起こすのではなく、限界を超える演算や無効な入力を含む演算は、特殊な値を生成します。すなわち、0/0 のように未定義の結果に対しては NaN (Not a Number) 、ゼロによる除算のようにオーバーフローが発生するケースに対しては 無限大 となります。これらの値はその後の計算において安全に伝播します - たとえば、NaN を含む任意の演算は NaN を生み、有限な数を無限大で割るとゼロになります。この封じ込めの特性により、開発者は事前にあらゆるエラー条件を防ぐのではなく、計算結果を事後に検証することがしばしば十分となります。
この画像は、ゼロによる浮動小数点除算が無限大を生み出し、これが安全に伝播する特殊な値であることを示しており、事後検証の必要性を示す記事の主張を裏付けています。
このパラダイムの不一致を示す一般的な間違いは、FLT_EPSILON（1.0と次の表現可能な浮動小数点値の間の最小の差）を使って零の分母をチェックすることです。ソース資料で示されているように、このアプローチは失敗します。なぜなら除算の成功は分子と分母の大きさの両方に依存するからです。大きな分子を中程度に小さな分母（たとえば0.9）で割ってもまだ無限大を生み出す可能性があり、中程度の分子を極めて小さな分母（FLT_EPSILONの次の値）で割っても無限大になることがあります。適切な解決策は、CやRustにおける isfinite() のような言語固有の関数を使って計算結果が有限かどうかをチェックすることです。これにより、NaN と無限大の両方を操作後の単一の検証ステップで捉えることができます。