パスワードを忘れた？ アカウント作成
Close
16360 story

Excel 2007に乗算のバグが発見される 50

ストーリー by GetSet
いやぁん 部門より

あるAnonymous Coward 曰く、

Slashdot本家に衝撃的なMS Excel 2007のバグの 記事が掲載されている。
確認は簡単なようだ。=850*77.1を計算させてみると、100,000となるらしい。
このバグは、乗算の結果が65,535になるときに発生するようで、おそらく2進法と10進法の変換過程での バグがあるのだろう。実に興味深い。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Excel 2007に乗算のバグが発見される More

  • http://blogs.msdn.com/excel/archive/2007/09/25/calculation-issue-update.aspx [msdn.com]
    Specifically, Excel incorrectly displays the result of a calculation in 12 very specific cases (outlined below).  The key here is that the issue is actually not in the calculation itself (the result of the calculation stored in Excel’s memory is correct), but only in the result that is shown in the sheet.
    計算内容は間違っていないが、結果を表示するところで問題が起きていると主張しています。
    --
    I'm out of my mind, but feel free to leave a comment.

    • Re:Microsoftのコメント (スコア:3, おもしろおかしい)

      by Anonymous Coward on 2007年09月26日 22時25分 (#1224925)
      言い訳はいい。

      一般ぴーぷる向けソフトでそんな言い訳、、、、

      釣られないクマー(AA略

      「計算内容は間違っていないが」って成績表を見せるときの新しい言い訳パターンだね
      シェア
      親コメント

      • Re:Microsoftのコメント (スコア:2, すばらしい洞察)

        by F8 (19734) on 2007年09月27日 12時13分 (#1225242) 日記
        データの破損というか汚染がないことはとても重要です。

        計算内容が間違っていない場合は今後パッチを当てれば正しく表示されますが、
        計算内容が間違っている場合は今まで作成したデータを総点検する必要があるでしょう。

        表示が重要はそのとおりですが、それ以上にデータのほうが重要です。
        シェア
        親コメント

        • データの破損というか汚染がないことはとても重要です。

          計算内容が間違っていない場合は今後パッチを当てれば正しく表示されますが、
          計算内容が間違っている場合は今まで作成したデータを総点検する必要があるでしょう。

          表示が重要はそのとおりですが、それ以上にデータのほうが重要です。

          データ (計算) と表示のどちらがより重要かという問題ではないと思います。計算部分にバグがあった場合に総点検の必要があるというなら、今回の表示部分のバグにしても、今までに Excel 2007 で作成して印刷したデータや、 Excel 2007 で作成したデータを画面で見てそれをもとに下した判断を総点検する必要があるわけですから。

          なお、 #1225749 [srad.jp] でも書きましたが、 Excel 開発者のブログではべつに「表示部分のバグだから計算部分のバグほど重大ではない」とは主張していません。

          シェア
          親コメント

          • Re:Microsoftのコメント (スコア:1)

            by F8 (19734) on 2007年09月29日 4時56分 (#1226042) 日記
            どちらがより重要かという問題ではない
            今回のExcel開発者のコメントはどちらが重要かという話ではありませんし、#1225749 [srad.jp]には同意します。
            しかし、問題の対象者を誰にするかで話は変わります。
            ユーザーにとってどこにバグがあるかはとても重要な問題です。

            バグの内容により対応は変わりますし、ユーザーにとって計算部分のバグの方が影響は大きいでしょう。
            # 計算結果をCSVとして出力したり値としてコピーする等の影響のある操作をしていなければ大差ないかもしれません。

            また、重要な意思決定にExcel 2007を使用していたのであれば、過去の印刷物や意思決定を見直す必要があるでしょう。
            見直すかどうかは、バグに遭遇する確率、見直す手間、その意思決定の重要度等を総合的に検討して決めることになります。
            # 表示に問題があるファイル（このバグが再現したファイル）を探すスクリプトを使うと確認の手間を効率化できますね。
            シェア
            親コメント

            • バグの内容により対応は変わりますし、ユーザーにとって計算部分のバグの方が影響は大きいでしょう。

              必ずしもそうとは言えないと思いますが、言われてみると早い段階 (計算部分) のバグの方が、遅い段階 (表示部分) のバグより影響が大きくなる傾向があってもおかしくないというのは納得できました。ありがとうございます。

              また、重要な意思決定にExcel 2007を使用していたのであれば、過去の印刷物や意思決定を見直す必要があるでしょう。

              見直すかどうかは、バグに遭遇する確率、見直す手間、その意思決定の重要度等を総合的に検討して決めることになります。

              それは、まったくその通りだと思います。

              シェア
              親コメント

      • 一般ぴーぷる向けソフトでそんな言い訳、、、、

        バグが計算部分ではなく表示部分にあるというのは、バグの重要度の評価ではなくて、単なるバグの説明です。計算部分でないから重大でない、などとは誰も言っていません。

        このバグの発生条件はわかりにくいです。挙動だけ見ていてもほとんど何もわかりません。一般に、どの段階にバグがあるのかという情報は、バグの発生条件を知る上で重要です。 U-Chan さんのコメント [srad.jp]にあるように、「=850*77.1」や「=850*77.1+1」ではバグが再現し、この例だけを見ると入力か計算の部分にバグがあるように考えられるのに、「=850*77.1+2」では再現しません。逆に表示部分にバグがあるとしたら、なぜ「=850*77.1+1」でも再現するのか。挙動だけ見ていると謎の多いバグです。

        だから、 Excel 開発者のブログではバグの内容を説明する際にまず「これは表示部分のバグだ」と書いてあるのです。

        バグの発生条件に興味がない人には、どの段階にバグがあるかなんてどうでもいい情報だと思いますが、バグの説明を読んで勝手に「言い訳している」と解釈するのはやめた方が良いと思います。

        シェア
        親コメント

      • Re:言い訳パターン (スコア:0)

        by Anonymous Coward
        新しくは無いです。

        すでに「ちゃうねん、本当はわかってんねんで？だけどな～、ごっちゃになるねん」

        というのが、大阪さん（春日歩 あずまんが）により使用されています。
        それを多少高度に変形すると「計算内容は間違っていないが」となります。

        この言い訳を好む人は次の言い訳も好んで使います
        「グラフで比較するとPSファミリーは順調に推移している」 [google.co.jp]

    • Re:Microsoftのコメント (スコア:2, 参考になる)

      by Anonymous Coward on 2007年09月26日 23時29分 (#1224959)
      本家や下記のサイトで言われてるように、保存したファイルの結果は正しいようですね。 恐らくMS(の中の人のブログ)の主張通りで表示のルーチンが間違っているんでしょう。
      http://eigyr.dip.jp/diary/200709.html#excel%202007%20%E3%81%8C%E6%8E%9... [eigyr.dip.jp]
      シェア
      親コメント
    • ＞計算内容は間違っていないが、結果を表示するところで問題が起きていると主張しています。

      ここ [srad.jp]を見る限りでは、結果を表示するところだけの問題でもないように思えるけど。
      同じセルを参照して計算させるだけで、どうしてこうも違うのかという点で、変なコーディングでもしてるのかと。
      --

      /* Kachou Utumi
      I'm Not Rich... */
      シェア
      親コメント
      • >変なコーディング

        実は「ギレを変換するとピカチュウになる」のと同様、不正コピー防止のための手法だったりして ;-P
    • だから何だと…
      表示してナンボのツールじゃないか。

      ４年もいじくりまわした結果がこれじゃ、お粗末過ぎる。

    • 大丈夫。 (スコア:0)

      by Anonymous Coward
      グラフで見るとそう変わらないw

  • 本家での実証例 (スコア:4, 参考になる)

    by flutist (16098) on 2007年09月26日 21時57分 (#1224910)
    セル "A1" に、=850*77.1を入れておきます。
    その時、他のセルでの
    　=A1+1 は 100,001 になります（65536になってほしい）。
    　=A1*2 は 131,070 になります（正しい）。
    　=A1*1 は 100,000 になります（65535になってほしい）。
    　=A1/1 は 100,000 になります（65535になってほしい）。
    　=A1/2 は 32767.5 になります（正しい）。

    ...だそうです。

  • 乗算は本質ではない (スコア:3, 参考になる)

    by fcp (32783) on 2007年09月28日 0時47分 (#1225603) ホームページ 日記

    rxk14007 さんが既に紹介 [srad.jp]している Excel 開発者の David Gainer さんのブログ記事 [srad.jp]を読むと書いてあることですが、このバグの本質は乗算とは無関係です。

    Excel の内部では数値を倍精度浮動小数点数 [wikipedia.org]で表します。このバグは、セルの計算結果が 65534.99999999995 より大きく 65535 より小さい数 (65535 よりも 1～6 ulp 小さい数) になると 100000 と表示され、 65535.99999999995 より大きく 65536 より小さい数 (65536 よりも 1～6 ulp 小さい数) になると 100001 と表示されるというものです。例えば、「=65535-1/137438953472」と書けばセルの内容が 65535 より 1 ulp 小さい数になるので、バグが再現します (137438953472 は 2 の 37 乗)。

    「=850*77.1」でバグが再現するのは、 77.1 が 2 進法で循環小数になるため内部で正確に表せず、その結果乗算の結果が 65535 より 1 ulp 小さい数になるからです。

    では、セルに同じ数を直接書いて「65534.9999999999927240423858165740966796875」と書けば再現するかというと、再現しません。 Excel では、セルに数値を入力すると、自動的に入力が (表示ではない) 15 桁までに丸められてしまうからです。これも David Gainer さんのブログ記事に書いてあります。

  • これでまた (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2007年09月26日 21時46分 (#1224908)
    2007にしなくてもイイ理由が増えた(^_^);

  • ショッキングというか (スコア:2, 興味深い)

    by Anonymous Coward on 2007年09月26日 21時58分 (#1224911)
    こんなバグが今ごろ出てくるということは、演算エンジンをイチから作り直したってことか。どういう経緯なんだろね。

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

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

    • おれが調べてやるよ (スコア:4, 興味深い)

      by Anonymous Coward on 2007年09月26日 23時45分 (#1224973)
      演算誤差を調べてみた。つっても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に修正される?

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

    • 以前よく取りざたされた演算誤差（本家記事 [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 で確認)。知りませんでした。昔からそうなのでしょうか。

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

      シェア
      親コメント
    • 多分該当部分を書いたのがビル・ゲイt(ry なんだよ、きっと(ｗ

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

      # エラい人の御筆先であると云う理由で、直すに直せないケース…でないといいなぁ。
    • 興味深いが2つもついちゃってるけど、RSATOsrvさんのコメント [srad.jp]を読むと、rxk14007さんのコメント [srad.jp]にあるように「間違ってるのは計算じゃなくて表示」ということみたいだね。

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

  • 小数点も関係するのかな (スコア:1, 参考になる)

    by Anonymous Coward on 2007年09月26日 21時46分 (#1224907)
    手元のExcel 2007では

    850*77.1 = 100000
    85*771 = 65535

    その他の数字も試してみましたが、整数では起きず
    小数点数でも起きる場合と起きない場合が
    # 計算順序の関係で、小数が整数扱いになるとダメかな

  • MSファンとしては (スコア:1)

    by hishakuan (32621) on 2007年09月26日 23時02分 (#1224947) 日記
    何故皆気付かないのだ！
    850*77.1=100,000
    で正しいのだ。

  • そこらじゅうバグだらけ (スコア:1, 興味深い)

    by Anonymous Coward on 2007年09月27日 1時09分 (#1225042)
    http://japan.cnet.com/news/sec/story/0,2000056024,20357195,00.htm [cnet.com]
    こんなんもでたし。
    なに使えばいいんだ? まさかiWorkか? かんべんしてくれ…

  • それかっ!! (スコア:1)

    by unchikun (14429) on 2007年09月27日 12時28分 (#1225250)
    Mac版Excel (2004) ではとりあえず「=850*77.1」の答えがちゃんと表示される。

    2007年後半に発売予定 [impress.co.jp]とされていた Office 2008 for Mac [impress.co.jp] の
    発売がずれたのは、文字通りWindows版との互換性向上のためなのだろう。

    ちなみにiWorkの Numbers でもちゃんと表示されてます。

    # きっと別のバグがあるんだろうけど、ユーザー数が少ないから誰も気がつかない
    # んだろうな。そっちのほうが怖い。

  • こんなんじゃ (スコア:1)

    by MkII (26282) on 2007年10月04日 5時15分 (#1228841)
    Execlの計算結果を電卓で検算してから提出しろと言う上司(ソース失念)
    に口実を与えちゃうじゃないですか！

  • 各社互換ソフトの互換性テストになりますね！ (スコア:0)

    by Anonymous Coward on 2007年09月26日 23時04分 (#1224948)
    ダメダメじゃんｗ
typodupeerror

アレゲは一日にしてならず -- アレゲ見習い