2016/12/03(土)double-double演算が異常に高精度になる!?
いわゆる普通の電卓で、適当な数(例えば100)を入れて、平方根のボタンを何回か押して、次に二乗(多くの電卓で[×][=]という操作)を同じ回数だけ行います。このとき、その回数がある程度以上多いと、丸め誤差でちゃんと100に戻ってきません。100円ショップに売っていた8桁のごく普通の電卓で試してみたところ、
100 → (10回平方根) → 1.0045072 → (10回二乗) → 99.9806と、誤差が観測されました。更に回数を増やしてみると、
100 → (20回平方根) → 1.0000042 → (20回二乗) → 81.635475
100 → (25回平方根) → 1 → (25回二乗) → 1のようになりました。平方根を取った値は徐々に1に近づき、1+εのεを保持する桁数が徐々に小さくなっていって、誤差がひどくなっていく様子がよく分かります。
もちろん、普通のPCで倍精度(double)を用いても同じことで、誤差が入ります。
#include <iostream> #include <cmath> int main() { int i; double x; std::cout.precision(17); x = 100; for (i=0; i<10; i++) { x = sqrt(x); } for (i=0; i<10; i++) { x = x * x; } std::cout << x << "\n"; }を実行すると、
100.00000000000637のように誤差が入りました。kvライブラリを使って区間演算にしてみます。
#include <kv/interval.hpp> #include <kv/rdouble.hpp> typedef kv::interval<double> itv; int main() { int i; itv x; std::cout.precision(17); x = 100; for (i=0; i<10; i++) { x = sqrt(x); } for (i=0; i<10; i++) { x = x * x; } std::cout << x << "\n"; }すると、
[99.99999999997776,100.00000000004346]のように100を含む区間が得られます。
さて、ここからが本題です。このdoubleで区間演算をしたときの区間幅を、平方根と二乗の回数を変化させながらプロットしてみます。
60回手前で計算が破綻していることが分かります。どこまで行けるかは仮数部の長さで決まる筈なので、mpfrを使って仮数部長を変化させて比較してみます。
すると、mpfrの仮数部を53bit(doubleと同じ)にした場合はdoubleとぴったり同じ、mpfrの仮数部長を長くすればそれだけ破綻までの回数が大きくなっています。ここまでは予想通り。ここで、このグラフにdd(double-double演算による擬似4倍精度、仮数部は106bit相当)を追加してみましょう。
なんだか異常なグラフが得られました。仮数部106bit相当なのでmpfr106と同じ動きをすると思いきや、最初は同じ挙動を示すものの途中から全く精度の悪化が見られず、mpfr212をも凌ぐ精度を叩きだしています。そんな馬鹿なとmpfrの超高精度を追加してみます。
すると、mpfrの仮数部1100bitで、ようやくddに勝つことができました。この現象は、
#include <kv/interval.hpp> #include <kv/dd.hpp> #include <kv/rdd.hpp> typedef kv::interval< kv::dd > itv; int main() { int i; itv x; std::cout.precision(17); x = 100; for (i=0; i<10; i++) { x = sqrt(x); } for (i=0; i<10; i++) { x = x * x; } std::cout << x << "\n"; }のようなプログラムで区間幅を観察すれば容易に確かめられます。
さて、なぜこんなことが起きたのでしょうか。最初はバグを疑ったのですが、バグではありませんでした。後日この現象の原因を追記しようと思いますので、少し考えてみて下さい。
解答 (12月4日追記)
一日経ったので理由を簡単に説明します。まず、ddとmpfr106で、平方根を40回行った場合の値を見比べてみます。表示は40桁にしました。
[1.000000000004188377884927590880100368969,1.000000000004188377884927590880168161704] (dd)ここではほぼ違いは見られません。上限と下限で一致している桁数は32桁で、4倍精度としては普通です。次に、平方根を80回にしてみます。
[1.000000000004188377884927590880118857896,1.000000000004188377884927590880168161704] (mpfr106)
[1.000000000000000000000003809307495356531,1.000000000000000000000003809307495356571] (dd)こちらは顕著な違いが見られます。mpfrの方は32桁で変わっていませんが、ddの方は38桁も一致していることが分かります。
[1.000000000000000000000003809307449647879,1.000000000000000000000003809307498951686] (mpfr106)
これは、ddの内部表現の特殊性によるものです。ddは、簡単にいうと仮数部の上位53bitと下位53bitを分割して格納するようなフォーマットです。よって、上位と下位の指数部は53ずれるのが普通なのですが(正確には下位の符号が利用できるので54ずれる)、上位と下位の間に0(上位と下位の符号が違う場合は1)が連続するような場合、それを省略することができ、上位と下位の指数部のずれが大きくなって仮数部長が大きくなることがあります。この場合も、40回のときの値の内部表現を見ると、
1.000000000004188427382700865564-4.9497773274684e-17ですが、80回のときは
1+3.8093074953565e-24で上位と下位が大きく離れています。たまたま収束先が1(=doubleで正確に表現可能)で、1+εのεの精密な表現力が問われるような問題だったので、ddが異常に高精度になったという仕掛けでした。
極めてレアな現象でいつもこういうことが起きるわけではないですが、偶然出会ったので記事に残しておきたくなったのでした。
2016/11/20(日)kv-0.4.37
今回は、double-double (dd) 関連のアップデートです。ddのsqrtが(多分)精度が上がって速くなっています。また、sqrtに無限大を入れた時にNaNになってしまっていたバグを修正しました。
そして、重大なバグ修正を含んでいます。0.4.36までは、ddを内部に持つ区間演算 interval<dd> の除算において、ある特定の条件のときに丸めの向きを間違うバグがあり、精度保証されていなかった可能性があります。interval<dd> を使って何らかの精度保証を行っている方は、速やかに0.4.37にアップデートをお願いします。近似計算としてddを使っている場合は問題ありません。
また、ddに関してはそれなりに利用者がいるにもかかわらずきちんとした形でアルゴリズムを記載していませんでした。今回、
を書きましたので、興味のある方は是非お読み下さい。
2016/10/02(日)scan2016
自分が発表した内容は大体5月に この記事 に書いたもので、だいぶ忘れかけていたので何というか気合いがなかなか入らなくて大変でした。行きの飛行機の中で電源が使えたのが大助かり。stiffなODEをどう効率的に精度保証するか、というのは何年も前からこの業界の大きなテーマで、それなりに印象を残せたのではないかと勝手に考えています。
この業界は狭くて研究者の数が多くないので、朝から晩までずっと精度保証の話を聞くという機会は滅多に無く、どの話も刺激的で大変満足出来ました。(こういう機会に自分の発表だけしてさっさと遊びに行っちゃう人は何を考えてるんだろう、と毒を吐いておこう。誰が何をしようと勝手だけど、そういう人とは友達になれないなあ。)
メキシコから来た某juliaおじさんのjulia押しが強力で割と印象に残りました。C++のテンプレートのような、型に合わせて何通りもの新しい関数を自動生成する機能があるようで、うまく使えば確かに精度保証付き数値計算にフィットするかなと。
また、double-doubleの誤差評価を厳密に頑張る話もなかなか楽しそう。某Y氏が数年前にやろうとしてた気がするが、それとの関係はどうなんだろうか。
Csendesの話面白かった。やはり遅延微分方程式に手を出すべきか?
Tuckerがオーガナイザーだったせいか、ODEの話が多めでしたね。国府先生の話で出てきた宮路先生のTaylorモデルの実装とか、興味あるなあ。
2年後に東京で開催することが正式に決定したので、頑張らないと!
2016/08/03(水)半精度浮動小数点数に関する思考実験
IEEE754-2008の半精度では、16bitを符号s(1bit)+指数部e(5bit)+仮数部m(10bit)に分割しています。指数部のオフセットは15で、従って正規化数は
x = (-1)s × 1.m × 2e-15のように、非正規化数は
x = (-1)s × 0.m × 2-14のように実数xと対応します。
ところで、URRという浮動小数点数の表現形式をご存知でしょうか。浜田穂積先生が80年代(IEEE754制定より前!)に提案された浮動小数点数の表現形式です。詳細は
- 浜田 穂積, 二重指数分割に基づくデータ長独立実数値表現法, 情報処理学会論文誌, Vol.22, No. 6, pp. 521-526 (1981)
- 浜田 穂積, 二重指数分割に基づくデータ長独立実数値表現法II, 情報処理学会論文誌, Vol.24, No. 2, pp. 149-156 (1983)
さて、半精度浮動小数点数は、bit数が少ないこともあって表現できる数値の範囲が非常に狭く、簡単にアンダーフローやオーバーフローを起こしてしまいます。正の最大数は何と65504です。正の最小数は、精度を保っている正規化数で2-14≃6.1×10-5、非正規化数まで考えても2-24≃5.96×10-8にすぎません。
そこで、URR的な考え方を用いて16bit浮動小数点数を構成したらどうなるか考えてみました。URRは-infやNaNが無いなど、現代のIEEE754に慣れた我々には使いにくいところもあるので、指数部と仮数部の区切りを可変にするという思想はそのままで、適当にフォーマットを定めます。指数部は、Eliasのデルタ符号を用いることにします。デルタ符号は1,2,3,…の自然数しか表せないので、指数部とデルタ符号で表す数値を
デルタ符号 | 1 | 2 | 3 | 4 | 5 | … | 255 | 256 | … | 508 | 509 | 510 | 511 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
指数部 | 0 | -1 | 1 | -2 | 2 | … | 127 | -128 | … | -254 | ±0 | ±inf | NaN |
デルタ符号の長さ | 1 | 3 | 3 | 5 | 5 | … | 14 | 15 | … | 15 | 15 | 15 | 15 |
提案方式の仮数部長 | IEEE754-2008の仮数部長 | |
---|---|---|
2-254 | 1 | - |
⋮ | ⋮ | ⋮ |
2-128 | 1 | - |
2-127 | 2 | - |
⋮ | ⋮ | ⋮ |
2-24 | 6 | 1 |
2-23 | 6 | 2 |
2-22 | 6 | 3 |
⋮ | ⋮ | ⋮ |
2-16 | 6 | 9 |
2-15 | 7 | 10 |
2-14 | 7 | 11 |
⋮ | ⋮ | ⋮ |
2-8 | 7 | 11 |
2-7 | 8 | 11 |
⋮ | ⋮ | ⋮ |
2-4 | 8 | 11 |
2-3 | 11 | 11 |
2-2 | 11 | 11 |
2-1 | 13 | 11 |
20 | 15 | 11 |
21 | 13 | 11 |
22 | 11 | 11 |
23 | 11 | 11 |
24 | 8 | 11 |
⋮ | ⋮ | ⋮ |
27 | 8 | 11 |
28 | 7 | 11 |
⋮ | ⋮ | ⋮ |
214 | 7 | 11 |
215 | 7 | 11 |
216 | 6 | - |
⋮ | ⋮ | ⋮ |
2127 | 2 | - |
2128 | 1 | - |
⋮ | ⋮ | ⋮ |
2253 | 1 | - |
もちろんハードウェアのサポートが無くソフトウェアエミュレーションでは速度は絶望的ですが、将来このような優れたフォーマットが気軽に使えるようになればいいなと思っています。FPGAとかで作って遊んだりできないかなあ。
2016/06/20(月)方向付き丸めクイズ
- x = a + b
- x = a - b
- x = a × b
- x = a / b
- x = (a + b) + c
- x = (a × b) × c
- x = (a - b) - c
- x = a - (b + c)
- x = -a + b
- x = -( (-a) + (-b) )
- x = a × b + c × d
- x = (a + b) × (c + d)
- x = a / (b + c)
- x = a - b × c
- x = a + (-b) × c
- x = sqrt(a)
- x = exp(a)