Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Not a Number of Floating Point Problems

tyabu12
July 11, 2018

Not a Number of Floating Point Problems

G. T. Leavens
March 2006, Journal of Object Technology 5(2):75-83.

tyabu12

July 11, 2018
Tweet

More Decks by tyabu12

Other Decks in Research

Transcript

  1. Not a Number of Floating Point Problems G. T. Leavens.:

    March 2006, Journal of Object Technology 5(2):75‑83. 2018年 7月 11日 @tyabu12
  2. 2. NaN に関する問題 NaN < NaN の結果はどうすべきか? 論理値には true か

    false しかない true でも false でもない → 例外機構を使う? しかし例外機構を全ての言語持っているわけではない → 標準には組み込めない 4
  3. 片側が NaN の場合の比較演算の定義 (IEEE 754) 以下, ∀x.x ≠ NaN とする

    式 評価 NaN ≠ x true NaN = x false NaN < x false NaN > x false NaN ≤ x false NaN ≥ x false 5
  4. 等価性が成り立たない 形式手法は数学に基づく 等価性という最も基本的な属性は、 "reflexive" つまり ∀x.x = x をい う

    しかし、IEEE 754 が定義する NaN ではこの等価が成り立たない → NaN = NaN の評価は false である 7
  5. 全順序でない IEEE 754 が定義する NaN では三分律が成り立たない (2つ前のスライ ド) 三分律 (trichotomy

    law) : x < y ∨ x = y ∨ x > y が成り立つこと この違反は, 浮動小数点数はもはや全順序でないことを意味する しかし NaN が "Not a Number" であることを考慮すれば, これは理にか なっている (Number は全順序になっている) 問題は, 型システムが NaN を数字と見なしてしまうこと 8
  6. 3 平均計算プログラムの検証例 Java と JML を用いた, 浮動小数点数を用いたプログラムの検証例 NaN による障害をどう取り除きながら, 事前・事後条件をアノテー

    ションしていくかを順を追って解説 基本的には NaN で場合分けしている 特に目新しい記述はないので, 省略 9
  7. 1. 論理値に第三の値 NaB (Not a Boolean) を許す メリット 全ての値の比較について定義できる デメリット

    現在のプログラミング言語や定理証明では一般的ではない 全ての型 T に "Not a T" が必要になる 例: (NaB ? 1 : 2) の条件式の評価は "Not a Integer" 11
  8. 2. 言語から NaN を追放する ビルトイン演算やユーザー定義関数は, NaN を返す代わりに, 例外を投げ る メリット

    言語の簡潔化 整数演算との調和 プログラマは例外処理に馴染みがある デメリット 効率性の損失 12
  9. 二案の中間案1. 例外を起こすか NaN を返すかをきりかえる, スイッ チ, グローバルパラメータ, オプション しかし一旦 NaN

    が言語の一部になったら, NaN 値がたとえ禁じられたと しても考慮する必要がある 結局仕様などの観点から嬉しくない 13
  10. 二案の中間案2. 値としての NaN は許容するが, 標準の浮動小数点数 型には許容しない Java だと, double 型や

    float 型は NaN を含まず, doubleWithNan ( double + NaN) 型や floatWithNaN ( float + NaN) 型を用意する NaN でないなら, doubleWithNan を double にキャストすることが 可能 前半で述べた反射等価性の欠如問題から, doubleWithNan 型には == や != 演算を定義しない 14
  11. 5. 結論 浮動小数点数にかかわる仕様を書く際は, いつも以上に気をつける必要が ある (特に値としての NaN の可能性の考慮) 完結で安定したアプローチは, 値としての

    NaN を使う代わりに例外を投 げることである もし値としての NaN を維持したいなら, 型システムは落とし穴を避ける よう調節することができる 結果としてより複雑になるが, 一般的なケースで仕様はかなり簡潔 になるだろう これは最終的にはプログラマを助け, より信頼できる言語へと至る だろう 15