「Excel 2007に乗算のバグが発見される」記事へのコメント

ショッキングというか

[Anonymous Coward]

こんなバグが今ごろ出てくるということは、演算エンジンをイチから作り直したってことか。どういう経緯なんだろね。

以前よく取りざたされた演算誤差（本家記事 [microsoft.com]、分析記事 [mie-u.ac.jp]、対策紹介 [nikkeibp.co.jp]）なんかはどうなったんだろ？

# calc.exeの拡張精度機能（意外に高性能なんだよねぇ）とか、他のソフトにも搭載すればいいのに、と思っても互換性の足かせとかで実現できないんだろうか（いまさらそんなこと言わないで直せばいいんじゃないかという気もするけど）

おれが調べてやるよ

[Anonymous Coward]

演算誤差を調べてみた。つってもOpenOfficeのCalcだけ。

まずは奥村先生の表 [mie-u.ac.jp]を再現するとこから。

   ε         1+ε      (1+ε)-1
4.30E-15    1.00E+00    4.22E-15
4.20E-15    1.00E+00    4.22E-15
4.10E-15    1.00E+00    4.00E-15
4.00E-15    1.00E+00    4.00E-15
3.90E-15    1.00E+00    4.00E-15
3.80E-15    1.00E+00    3.77E-15
3.70E-15    1.00E+00    3.77E-15
3.60E-15    1.00E+00    0.00E+00
3.50E-15    1.00E+00    0.00E+00
3.40E-15    1.00E+00    0.00E+00

0に落ちるのが早すぎる。

3.77E-15 ≒ 2^-48+2^-52
4.00E-15 ≒ 2^-48+2^-52+2^-52
4.22E-15 ≒ 2^-48+2^-52+2^-52+2^-52

精度は少なくとも2^-52まであるが、計算結果が2^-48以下になったあたりで意に反して0に修正されている。

括弧で囲んだり、1を掛けたりしても結果は変わらず。
つまり、演算の途中で閾値を割り込むと強制的に0に修正される?

結論
表計算ソフトはやっぱりよく分からん理屈で動いてる
あと、数値計算には使うな

Re:おれが調べてやるよ

[Anonymous Coward]

当方の環境では4.4E-15から0.0E-15まででテストした結果、0.1E-15 (1E-16)で初めて0に落ちました。
ちなみにUbuntu 7.04/i386, OOo 2.2です。

Re:おれが調べてやるよ

[5hed (108)]

＞あと、数値計算には使うな

つまりExcelは仕様書作成ツールであると！

＃やーめーてー

これでまた

[Anonymous Coward]

Excelで仕様書を書いてイイ理由が増えた(^_^);

Re:これでまた

[Anonymous Coward]

でも、方眼紙代わりにするな(T_T)

Re:これでまた

[Anonymous Coward]

じゃぁ、方眼紙の代わりになるアプリケーションを提供してくれ。

演算精度 (Re:ショッキングというか)

[fcp (32783)]

以前よく取りざたされた演算誤差（本家記事 [microsoft.com]、分析記事 [mie-u.ac.jp]、対策紹介 [nikkeibp.co.jp]）なんかはどうなったんだろ？

演算誤差自体は、浮動小数点演算を使う以上避けられないもので、どうなったも何もありません。

「分析記事」のリンク先である奥村晴彦さんの「Excel の演算誤差 [mie-u.ac.jp]」で扱っているのは、演算誤差そのものではなく、 Excel では時々計算結果がゼロに「補正」されてしまい、しかもどんな場合に「補正」されるかよくわからない、という問題ですので、誤解のなきよう。倍精度浮動小数点数を使っていれば本来現れるはずの誤差が、この「補正」のせいで現れない場合があります。なぜか OpenOffice.org の Calc については奥村さんと同じ実験をしている人が複数いるのに、このストーリーの主役のはずの Excel 2007 での結果を書いている人がいないので書いておくと、 Excel 2007 でも奥村さんの Excel 2000 での実験結果と変わりません (減算では Excel 2000 の場合と同じ =(1+1.6E-15)-1 以降でゼロになり、式全体を括弧で囲めば本来の通りに誤差が出ます)。

# calc.exeの拡張精度機能（意外に高性能なんだよねぇ）とか、他のソフトにも搭載すればいいのに、と思っても互換性の足かせとかで実現できないんだろうか（いまさらそんなこと言わないで直せばいいんじゃないかという気もするけど）

なんと、 Windows 標準の calc.exe では倍精度浮動小数点数より良い精度の演算ができるのですね (Windows XP SP2 で確認)。知りませんでした。昔からそうなのでしょうか。

他のソフトで精度の高い演算が使われない理由は、互換性の問題というよりは、ほとんど必要とされていないからでしょう。何桁使えれば十分かが場合によって違っているので、結局どこかで妥協しなければならないのではないかと思います。妥協する点として、倍精度浮動小数点数を使うのは合理的だと思います。数値計算をすることが主目的のソフトであれば、多倍長計算をして、しかも精度をユーザーが指定できるようにすれば良いのでしょうが、一般的な表計算ソフト等に求められている機能ではないでしょう。

Re:ショッキングというか

[Anonymous Coward]

多分該当部分を書いたのがビル・ゲイt(ry なんだよ、きっと(ｗ

ゼロの近傍でのtanhの精度が悪いのとか、直ってますか？

# エラい人の御筆先であると云う理由で、直すに直せないケース…でないといいなぁ。

Re:ショッキングというか

[Anonymous Coward]

彼のコードには問題ありません。ただ単に全部BASICで書いてあるだけです。

Re:ショッキングというか

[Anonymous Coward]

興味深いが2つもついちゃってるけど、RSATOsrvさんのコメント [srad.jp]を読むと、rxk14007さんのコメント [srad.jp]にあるように「間違ってるのは計算じゃなくて表示」ということみたいだね。

# ってことは、バグって「100,000」と表示されたセルをコピーして他のアプリに貼り付けたら正常な表示に戻るのかな？（手元にソフトがないから検証できない）
# にしても、

Re:ショッキングというか

[T.Sawamoto (4142)]

B1に"=A1+1"と入力し、さらに"=B1/2"とすると、この結果は32768でした。
このばやいも、B1の数値自体は間違っておらず、表示だけがおかしいようですね。表示が異常な状態も引き継がれている？
あと、"=A1-1"は正しく65534でした。
微妙なバグだ……。

Re:ショッキングというか

[RSATOsrv (19280)]

A1に=850*77.1を入れて
・A1をコピーして、OOo CalcのA1に貼り付け
・"Book1.xls"(not xlsx)として保存、Clacで開く
共に65535でした。

#もう何が何だか