【PL/I深層解説】FLOATの「基数変換」という罠：精度とコストの境界線
メインフレームの保守現場で、ふと見かける `FLOAT DECIMAL` と `FLOAT BINARY` の混在。若手エンジニアから「どっちを使っても同じ浮動小数点ですよね？」と聞かれるたびに、私は「計算機の世界に『同じ』という言葉はない」と答えることにしている。
今日は、バッチ処理の性能劣化や、稀に発生する「1円の差異」を引き起こす、基数変換のオーバーヘッドと丸め誤差の正体について深掘りしよう。
—
なぜ、わざわざ「基数変換」が発生するのか
PL/Iの歴史は長いが、その柔軟性の裏には常にトレードオフが存在する。`FLOAT DECIMAL`（10進浮動小数点）は、我々人間が計算する10進法に近く、金融計算との親和性が高い。一方、`FLOAT BINARY`（2進浮動小数点）は、CPUが最も効率的に処理できる、まさに「ハードウェアの母国語」だ。
もし、貴君の書いたコード内でこれらを混在させて演算を行えば、コンパイラは背後で黙々と、しかし確実に基数変換のルーチンを呼び出す。
1. 変換コスト: 10進から2進への変換には、乗除算を含む複雑な演算ステップが必要となる。数百万件のVSAMレコードを読み込むバッチ処理で、ループ内でこの変換を繰り返せば、CPU使用率（TCO）は目に見えて跳ね上がる。
2. 丸め誤差の増幅: 10進数で割り切れる値（例: 0.1）は、2進数では循環小数となり、表現しきれない。この「表現のズレ」が、演算を繰り返すたびに累積し、最終的な計算結果で1ユニットの誤差として顕在化するのだ。
—
実践：精度を意識したコーディング標準
バッチ処理において、型の不一致による変換を避けるための実装例を示そう。ここでは、VSAMから読み込んだデータを浮動小数点として計算する際のベストプラクティスを提示する。
1
/ 精度変換のオーバーヘッドを避けるための型統一 /
DCL VAL_DEC FLOAT DECIMAL(16); / 金額等の計算用 /
DCL VAL_BIN FLOAT BINARY(53); / 高速な算術演算用 /
/ 誤った実装例：ループ内での混在演算は避ける /
/ DO I = 1 TO MAX_REC; /
/ VAL_BIN = VAL_BIN + VAL_DEC; <- ここで毎回コストのかかる変換が発生 /
/ END; /
/ 推奨される実装：演算前に型を統一し、BUILTIN関数を活用する /
PROCESS;
TEST_PROC: PROC OPTIONS(MAIN);
DCL AMT_INPUT FLOAT DECIMAL(16) INIT(10.5);
DCL RATE_BIN FLOAT BINARY(53) INIT(0.05D0); / 2進浮動小数定数 /
DCL RESULT FLOAT BINARY(53);
/
- 変換コストを最小化するため、一度だけ型変換を行う
- FLOAT関数で明示的に変換を制御する
/
RESULT = FLOAT(AMT_INPUT, 53) RATE_BIN;
/
- 万が一の計算誤差を補足するためにONユニットを仕込む
- オーバーフローやゼロ除算はバッチの「急死」を招く
/
ON CONVERSION BEGIN;
PUT SKIP LIST(‘データ変換エラーが発生しました’);
SIGNAL ERROR;
END;
PUT SKIP LIST(‘計算結果:’, RESULT);
END TEST_PROC;
—
「予約語なき言語」PL/Iとの付き合い方
PL/Iの面白いところは、`IF` や `THEN` といったキーワードが予約語ではなく、文脈依存である点だ。これは強力だが、変数を `IF` と名付けるような無謀な真似をすれば、後続の保守エンジニアを絶望の淵に突き落とすことになる。
同様に、型の命名にも気を使ってほしい。`FLOAT DECIMAL` を扱う際は、変数名の末尾に `_D` をつけるなど、型推論が容易なコーディング標準をチームで確立することが、大規模改修を生き抜くための防具となる。
最後に：トラブルシューティングの勘所
もし、本番環境で「計算結果が微妙に違う」という報告が上がったら、まずは以下のステップを疑え。
1. コンパイラオプションの確認: `FLOAT(DFP)` を指定しているか。最新のIBM Z環境であれば、10進浮動小数点（DFP）のハードウェア支援を活かすべきだ。
2. 中間変数の型: `FIXED BIN` から `FLOAT` への暗黙的な変換が、どこで起きているか。`LIST` 出力で中間値を追えば、誤差の発生源はすぐに見つかる。
3. BUILTIN関数の活用: `ROUND` や `TRUNC` を闇雲に使うのではなく、計算精度を保証した上で必要な桁数のみを処理する設計思想を持つこと。
メインフレームのコードは、書いた人の哲学を映す鏡だ。「動けばいい」というコードは、数年後の貴君自身を苦しめる。基数変換のオーバーヘッドを理解した上で、計算精度を制御下に置くこと。それこそが、ベテラン・アーキテクトへの第一歩だ。
何か詰まったら、いつでもコンパイラのリスティングファイルを読み解きに来い。答えは必ず、そこにある。
