首藤です。

> > (2) 1bit，精度を犠牲にする
> >
> > 　一番現実的かな，と思っています．数値計算にどれくらい影響を与える
> > か，わかりません．この辺の評価ってどうすればいいんでしょうか．

仮数部の最下位ビットを使いまわす、という方法について、
ちょっと考えてみました。
問題がありそうです。

もし、IEEE 754 の倍精度では仮数部が 52 bit であるところ、
1 bit 使いまわすことで 51 bit 精度になるというのなら、
それはそれで割とリーズナブルなのではないかと思いました。
(計算科学の方は、それでも難色を示しそうですが。。)

しかし、一度は 52 bit (倍精度) や 64 bit (x86 の拡張倍精度) 精度で
得られた結果を 51 bit に丸めると、
仮数部が元から 51 bit であった場合の演算結果とは
異なる結果が得られてしまうことがあります。

昔書いた論文で、「2度丸め」の問題と呼びました。

例えば
...011 を 1 bit 分ずつ 2度 (最も近い値に向けて) 丸めると、
...011 → ...01 → ...0 となりますが、
2 bit 分を一気に丸めると、
...011 → ...1 となります。
食い違います。


> 堀之内です。
>
> (2)はやばいと思います。NArray 等の拡張ライブラリーを使う場合や、
> Fortran や C での計算と比較する場合と、丸め誤差が一致しなくなり
> ます。カオスなどに代表される、初期誤差が増大するケースでは浮動
> 小数点方式がかわると結果が大きく変わります。そういう問題なんだ
> からしょうがないという考えかたもありえますが、数値計算自体の検
> 証可能性が確保できなくなります。

Fortran や C では、コード上での演算順序と
コンパイル結果の演算順序が同じになる保証がないですよね。
この問題に対しては、最適化を極力抑制 (-O0 とか) して
演算の順序が保存されることを期待して乗り切るんでしょうか。


首藤一幸

--
ML: yarv-dev quickml.atdot.net
Info: http://www.atdot.net/~ko1/quickml