スラッシュドット・ジャパン

日本ではExcelを方眼紙ワープロとして使うのが基本なので
そんなややこしい機能を使うような人はほとんどいません :-)

三重大学の奥村教授のブログ「Excel使うな」:

> まず最初の論文(略)のアブストラクト：
> 要約：どうしょーもないから使うな。

> 次の(略)のアブストラクト：
> 要約：どうしょーもないから使うな。

ワラタ。全く異論無し。

Microsoftなら統計や数値計算の分野でもトップレベルの研究者を抱えている
だろうに、それなのにいつまで経っても売り物が改善されないというのは、
単にMS自身にやる気がないんでしょうね。
MSの研究者もExcelの改良するために雇われているんじゃないだろうし。
てゆーか、まっとうな研究者ならExcelの統計機能なんて使わないし。
（もちろん、Excelで用が足りることにExcel使うのは問題ないですよ。）

R [r-project.org]なら、世界中の研究者が使って常にチェックの
目を光らせているので、安心して使えますね。GUI弱いけど。

Sage [sagemath.org](Mathematica置換を狙ったOSS)とか、
Octave [gnu.org](Matlab置換を狙ったOSS)とかの具合は最近どうなんでしょうか？＞識者

どうりで、エンゲル係数とBMI値が高かったわけです。

よく知らないのですが、Pythonの乱数モジュールを調べたときに発見したWichmann-Hill法。
Python標準はメルセンヌツイスタですが、後方互換のためにWichmann-Hill法も残しているそうです。

ただし、この Wichmann-Hill 生成器はもはや推奨することができないということに注意してください。現在の水準では生成される周期が短すぎ、また厳密な乱数性試験に合格しないことが知られています。

http://www.python.jp/doc/current/lib/module-random.html [python.jp]
PythonのメルセンヌツイスタはCで実装されてるのになぜか遅いんですよねえ。Pythonの内部形式に変換するのに時間かかってるぽいのですが、なんとかならないかなあ。

不正確でしたよ（ＤＯＳ版）
統計分析用のアドオンを使ってましたから、そちらの問題かもしれませんが。

ＰＣで傾向を見てから、本番はＳＡＳでした。

最近は大学の卒論とかでもExcelを使う例が増えているとか。

きっとお手軽＆みんな持っているからだとは思われますが……。

Excel2002だと、sinh(1e-19)がゼロになったりして駄目駄目なんですが、2007では直ってますか？

# xがゼロの近傍で、sinh(x)≒xになる筈。

いえいえ、Excel が論文ネタを提供してるわけですよ。

これで、卒業論文・修士論文になるんだったら（さすが博士論文は無いと思うが）マイクロソフトの教育界への貢献は甚大なものです。

詳しい人 -> 使わない
詳しくない人 -> わからない

で全然苦情が発生してない、とか。

同じくソースありませんが。
97年か98年頃に大学で受けた統計の講義にて、Excelを使った実習もやっていたのですが、当時既に統計機能にバグがあることが教官によって指摘されていました。統計機能のアドオンで定義されている関数ではまともな結果がでないので、教科書の定義どおりの式を自分で入力して使え、と。
具体的なバグの内容はおぼえていませんが、まったくおかしな数字が出る、本来の値の数分の1の値が出る、精度が悪い等の症状で、3,4か所以上はあった気がします。

いまはExcelの統計機能を使う機会はないのですが、まだ直っていなかったことに驚きました。

いつからかはわかりませんが、ココ [gunma-u.ac.jp]ではかなり前から指摘してます。
これ読んだときには、注意して使えば良い程度のレベルだなって思いました。

> # コメントの信頼性も大幅に低下してるようですな

いやはや全くもって否定しがたい事実です。

逆です. Excelがそういった現実の数値データを取り扱うのに必要な, 有効桁という概念が無いから使えないのです(最近のバージョンはもしかしたら有るかもしれないけど). 少数以下2桁(有効桁数3桁)で加減乗除すればいいような課題は, 4桁以上の数は出す必要が無いのではなく, 出してはいけないのです. すなわち実験データ処理や統計のソフトで「精度が要求される」と言った場合, 有効桁数を多くする以外に有効桁数を考慮した計算(例えば有効桁数の異なる数値の積では結果の有効桁数を小さいほうに合わせるとか)が必要になります.

さらにExcelでは表示桁数を設定しても内部で保持しているデータは表示とは別になっているので, 例えば

セルA: 10 / 3
セルB: 10 / 3
セルC: セルA + セルC

を有効桁数1桁で取り扱った時の結果が, 本来はセルA=3, セルB=3, セルC=6となるべきところ, セルA=3, セルB=3, セルC=7になって, 見た目と結果が異なってくるなんてことも起こりえます.

まあ, これぐらいなら回避の方法はいろいろありますし, 他の表計算ソフトでも似たような現象は起こりうるんですけどね. 正しい結果を得るためにはデータの内部形式とかも考慮しないといけないので, 専用の統計処理ソフトと比べると労多くしてってことになりやすいですね. 場合によっては10進演算で桁数管理がしっかりしているCOBOLの方がましなんてこともあるみたいで.

統計の「と」というか"S"くらいしか囓っていませんが、100×2500くらいのシートでしょっちゅう
計算しています。小数点下6桁目くらいでExcelの計算結果と統計ソフトの結果にズレが出てきて、
「おかしいねえー。ここ（差で）0にならないと駄目なはずだよねえ」
と一所懸命検算したことがあります。どういう計算だったか今手元にシートが無いので
判りませんが、標準誤差とか四則演算位のはずなんですが。

ppm表示で×10^6とかやるから、目立つんですよね。

>> MSが本気で直そうとしていないということだと考えられます。

かなり前（5年以上前だな）にどこぞのweb siteで見た話なのでホントかどうかわかりませんが，MS側の見解としては「そもそも統計処理のソフトじゃなくて会計計算とかのためのものなので，本気の統計処理とかに使ってくれるな」という話だったはずです．

Excel 互換がウリなら、バグも再現せねばならない。