アカウント名:
パスワード:
rand, randbetween 関数Excel 2003 の rand 関数には致命的なバグがあります。0 〜 1 の一様乱数を返すはずですが,なんと 10 % の確率で負の値を返すそうです。発生させる乱数の範囲を指定できる randbetween 関数とて rand 関数を下請けにしているのだろうから同じ問題が起きているとのことです。(以下略)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
デジャブ? (スコア:0)
Re:デジャブ? (スコア:5, 参考になる)
これ読んだときには、注意して使えば良い程度のレベルだなって思いました。
素人でもわかる明らかなバグ (スコア:2, 参考になる)
Re:素人でもわかる明らかなバグ (スコア:1)
配列が0ベースの言語と1ベースの言語を併用してると、似たような間抜けをかますことがありますね。
Re: (スコア:0)
Re:デジャブ? (スコア:2, 参考になる)
97年か98年頃に大学で受けた統計の講義にて、Excelを使った実習もやっていたのですが、当時既に統計機能にバグがあることが教官によって指摘されていました。統計機能のアドオンで定義されている関数ではまともな結果がでないので、教科書の定義どおりの式を自分で入力して使え、と。
具体的なバグの内容はおぼえていませんが、まったくおかしな数字が出る、本来の値の数分の1の値が出る、精度が悪い等の症状で、3,4か所以上はあった気がします。
いまはExcelの統計機能を使う機会はないのですが、まだ直っていなかったことに驚きました。
Re:デジャブ? (スコア:1, 参考になる)
# xがゼロの近傍で、sinh(x)≒xになる筈。
Re:デジャブ? (スコア:2, 参考になる)
sinh(x)=(exp(x)-exp(-x))/2
で計算していて、0近傍でexp(x)≒1+x、exp(-x)≒1-xとなるので、これらの値が倍精度で表現出来なくなったところで終わりです。パーセントオーダーの精度だと5e-15で終わりです。
MzScheme(Schemeの処理系の1つ)でも試してみましたが、倍精度なので結果は同じです。sinhは無いので、上記の式を使いました。
ただ、個人的には、この手の計算をするときにExcelを使う奴の方が間違っていると思う。
Re:デジャブ? (スコア:1)
関数計算をしていて有効桁が少ないという問題がありましたね。
あと、sqrt(x) を x^0.5 で代用しているのでこれも有効桁が少ないという
問題がありました。(真面目に計算するならニュートン法でも使うところ。)
補足 (スコア:1)
> (sinh 1e-4)
0.00010000000016666667
> (sinh 1e-5)
1.0000000000166668e-005
> (sinh 1e-6)
1.0000000000001666e-006
> (sinh 1e-7)
1.0000000000000017e-007
> (sinh 1e-8)
1e-008
Excelのsinh(x)では
1.00E-04のとき、
1.00000000166689E-04
ですが、1.00E-05のとき、
1.00000000001210E-05
となるので、Excelでは、1e-5のときの下位の桁は信頼できません。
因みに、MzSchemeで計算しましたが、exp(x)-1を求める関数は、
(define mexp (lambda (x) (exact->inexact (let loop1 ((n 60)) (if (= n 0) 0 (+ (let loop2 ((n n)) (if (= n 0) 1 (* (/ x n) (loop2 (- n 1))))) (loop1 (- n 1))))))))
マクローリン展開のnは60としましたが、0近傍ではそんなにいりません。
Re:デジャブ? (スコア:1)
なんか設定でそういうのをいじれれば、良くなるかも。
Re:デジャブ? (スコア:2, 参考になる)
違うっぽいかも。
セルの値を=Sinh(1E-19)/1E-19にしても0だから。
1E-16前後あたりから値がおかしくなる。
でもSin(x)/xだと(xが十分小さいところで)問答無用でちゃんと1になるから、内部的に
どういう展開を使うかあたりで怪しいんかねぇ。
Re: (スコア:0)
Re: (スコア:0)
に自動変換され、セルには0とでますね。セルのプロパティから数値で小数点以下の桁数30にした状態でも0.0です。小数点以下に0が多く並んでるが数えるの面倒だから放置
Re: (スコア:0)
=IF(A1=0, "真", "偽")としてみると
sinh(1E-16)までは偽で、sinh(1E-17)から真となりました。
元コメントにあるとおり1E-16辺りから怪しいようです。
# さらにsinh(6E-17)では偽、sinh(5E-17)では真……って何ヒマな事をやってるんだろ
(*) 一応注意しておくと、sinh(6E-17)まで正しいという訳ではないです。
Re:デジャブ? (スコア:1)
計算しています。小数点下6桁目くらいでExcelの計算結果と統計ソフトの結果にズレが出てきて、
「おかしいねえー。ここ(差で)0にならないと駄目なはずだよねえ」
と一所懸命検算したことがあります。どういう計算だったか今手元にシートが無いので
判りませんが、標準誤差とか四則演算位のはずなんですが。
ppm表示で×10^6とかやるから、目立つんですよね。
Re: (スコア:0)
昔からあるバグで、かつ競合製品にはないようなバグだとすれば、
技術的には直すことが可能でその時間もあったはずだから、
MSが本気で直そうとしていないということだと考えられます。
そういう場合、MSに本気で直そうとしてもらうためには、
この問題が広く知られて、苦情が殺到するくらいになる
必要があるのではないかと思います。
Re:デジャブ? (スコア:5, すばらしい洞察)
詳しくない人 -> わからない
で全然苦情が発生してない、とか。
Re:デジャブ? (スコア:1)
Re:デジャブ? (スコア:1, 興味深い)
かなり前(5年以上前だな)にどこぞのweb siteで見た話なのでホントかどうかわかりませんが,MS側の見解としては「そもそも統計処理のソフトじゃなくて会計計算とかのためのものなので,本気の統計処理とかに使ってくれるな」という話だったはずです.
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0, 既出)
いまやOfficeがデファクトスタンダードだから、競合製品はどこも
Excel互換 がウリなんだよなぁ。そういう観点からすると
競合製品の質も五十歩百歩じゃないかな。
OOoはどうなんだろうか。
Re:デジャブ? (スコア:1)
the.ACount
Re: (スコア:0)
# コメントの信頼性も大幅に低下してるようですな
Re:デジャブ? (スコア:1)
いやはや全くもって否定しがたい事実です。
Re: (スコア:0)
Excel互換じゃないってことですね。
このスレ定期的に(ry (スコア:0)