🚀 go-pugleaf

Susukita Ryutaro wrote in message <6c38q4$lqj$1@postman.riken.go.jp>...
>not equalになる理由
>
>(double)1 / 3の結果はdoubleだが、(double)a / 3の結果がdoubleになって
>いない。
>
>この動作はCの規格に合っているか?

>
>Cの規格ではdouble / doubleの結果はdoubleになる。(double)a / 3の結果が
>doubleになっていないのでCの規格からは外れている。


本来は double / int の計算は double / double に格上げされて、
結果も double になるはずです。
そういう意味では「規格から外れている」とみなされても仕方ないかもしれません。

double 以上の内部的な精度と、本来の double との精度との間での計算について
精度合わせが外されてしまっているのは、
精度合わせ自体に計算コストがかかるので、
これを避けるためだったりするんですよね。
こういうのは、最適化しない時は正常動作して、最適化された途端におかしくなる
という厄介なバグになりがちです。

余分な精度と通常の精度との間では不等号の関係は成立するので、
不等号に関しては精度合わせを端折っても大丈夫です。
ここでは等号なので、精度合わせの問題が表面化してしまったのでしょう。

しかし、
「プログラマは、精度内で計算を行なっているから、意図的に同値判定をしているの
だ」
という前提に立てば、これは必ずしもおかしなことではありません。

>gccを変えずにCの規格に合わせられるか?
>
>-ffloat-storeは効かない。
>FreeBSDには387の仮数部の長さの設定をdoubleと同じ53ビットにする関数がある
>らしいので、Linuxにも同等のものがあるかもしれない。


これはわかんないです。

それよりも、仮数部の精度を暗黙に期待するソースを書かないようにするべきだと感
じます。
「IEEEにすれば精度は固定的だから、それを使えばいい」というよう書き方は
正直言って恐いです。

----
Bugbear
樋口 勝也
bugbear@ga2.so-net.or.jp
bugbear@na.rim.or.jp (For PostPet)