浮動小数点の深淵：FLOAT BINARY(21)と(53)が引き起こす「計算のズレ」の正体
若手の諸君、今日もメインフレームの迷宮で格闘していることだろう。
保守の現場で、バッチ処理の結果が「1円合わない」「精度の境界で値が変わる」といった不可解な現象に遭遇したことはないか？特に、レガシーシステムからオープン系へデータを移行する際、あるいはコンパイラオプションを変更したタイミングで突如として現れるこの手のバグは、往々にして浮動小数点数の内部表現の理解不足が原因だ。
今日は、PL/Iにおいて非常に扱いが難しく、かつ極めて重要な「FLOAT BINARY(21)」と「(53)」の仕様、そしてIEEE 754互換性の罠について、現場の視点から解説する。
—
1. 予約語なき自由と、精度の「落とし穴」
まず、PL/Iという言語の特異性を思い出してほしい。この言語には、驚くべきことに「予約語」が存在しない。`IF` や `THEN` といった構文要素でさえ、変数名として宣言できてしまう。この自由度は強力だが、それゆえに設計者が意図したデータ型を厳密に制御する意識がないと、システムは容易に崩壊する。
特に浮動小数点数は厄介だ。`FLOAT BINARY(p)` において、`p` は精度（ビット数）を指す。ここでの `21` と `53` は、単に数字の長さが変わる以上の意味を持つ。
- FLOAT BINARY(21): IBMメインフレームの歴史的背景を持つ「短精度」浮動小数点数（S/390形式など）の系譜。
- FLOAT BINARY(53): IEEE 754標準の「倍精度」浮動小数点数と直接マッピングされる精度。
現在のIBM z/OSコンパイラ（Enterprise PL/I）環境では、デフォルトでハードウェアのIEEE 754演算が優先されるが、古いコードでは依然として独自形式が混在している。ここがトラブルの温床だ。
—
2. 実践的なコーディング例：精度の検証
以下のコードを見てほしい。浮動小数点の計算結果をVSAMファイルに書き出す際の、あるべきチェック処理の断片だ。
1
/ ————————————————————- /
/ 浮動小数点精度の比較検証用サンプル /
/ ————————————————————- /
TEST_FLOAT: PROC OPTIONS(MAIN);
DCL VAL_21 FLOAT BINARY(21) INIT(1234.5678); / 短精度 /
DCL VAL_53 FLOAT BINARY(53) INIT(1234.5678); / 倍精度 /
DCL DIFF FLOAT BINARY(53); / 差分計算用 /
/
- コンパイラはFLOAT BINARY(21)を内部で短精度(32bit)として扱う。
- 一方、(53)は倍精度(64bit)としてIEEE 754互換の演算を行う。
- この二つを混在させると、コンパイラは型昇格(Promotion)を行い、
- 計算結果に微妙な丸め誤差が生じる可能性がある。
/
DIFF = ABS(VAL_53 – VAL_21);
IF DIFF > 1E-7 THEN
PUT SKIP LIST(‘警告: 許容範囲を超えた精度劣化を検出’);
ELSE
PUT SKIP LIST(‘精度は許容範囲内です’);
/
- VSAMファイル出力時の注意:
- レコード形式によってはバイナリデータがそのままダンプされる。
- 読み書きするプログラム間で精度(21 vs 53)が食い違うと、
- 読み込み時にビット化けしたような数値になるため注意が必要だ。
/
END TEST_FLOAT;
—
3. なぜ「21」と「53」でバグるのか？
現場でよくある失敗は、「数値の大きさ」だけで型を選んでしまうことだ。
- FLOAT BINARY(21) は、有効桁数が約6〜7桁。
- FLOAT BINARY(53) は、有効桁数が約15〜17桁。
基幹システムの金額計算において、`FLOAT`型を使うこと自体が本来はご法度だが（`FIXED DECIMAL`を使うべきだ）、古い分析系システムや科学技術計算のルーチンでは今も現役だ。
もし、以前のメインフレーム専用の浮動小数点形式（HFP）から、最新のIEEE 754演算（DFPやBFP）へコンパイラ設定を移行した場合、`21` の精度では丸め処理のアルゴリズムが微妙に変わり、累積誤差の結果が「1」変わる現象が起きる。これはデバッグが非常に困難だ。
トラブルシューティングのコツ
もし本番バッチで「計算が合わない」という報告が上がったら、以下の点を確認せよ。
1. コンパイラオプションの確認: `FLOAT(BEF)` (Binary Floating-point) と `FLOAT(HFP)` のどちらが指定されているか。
2. ONユニットの活用: 計算時のオーバーフローやアンダーフローを検知するために、`ON UNDERFLOW` や `ON OVERFLOW` を適切に配置し、どの演算で精度が飛んでいるかをログとして吐き出せ。
3. BUILTIN関数の活用: `PRECISION` 関数を使用して、明示的にキャストを行い、計算途中の精度落ちを防げ。
—
最後に：ベテランからのアドバイス
PL/Iは、ハードウェアの能力を極限まで引き出すための言語だ。しかし、その分だけ「言語の仕様」と「ハードウェアの制約」の境界線を曖昧にすると、必ずしっぺ返しを食らう。
`FLOAT BINARY(21)` を見かけたら、「これはレガシーとの互換性のために残された、あるいは過去の設計者が安易に選んだ境界線かもしれない」と疑うこと。そして、大規模な改修を行う際は、必ず倍精度（53）への統一を視野に入れつつ、影響範囲を徹底的にテストしてほしい。
システムを守るのは、マニュアルの知識ではなく、こうした「数値の挙動に対する執拗なまでの執着」だ。君たちの健闘を祈る。
