山内の授業のページ/08秋/特別ゼミB/第6回

2019年度
├春プログラミングA
├秋オペレーティングシステム
└秋生物分子・情報科学概論

 2018年度
├春プログラミングA
├秋オペレーティングシステム
├秋アーキテクチャ
└秋生物分子・情報科学概論

 2017年度
├秋オペレーティングシステム
├秋アーキテクチャ
└秋大学院

 2016年度
├秋オペレーティングシステム
├秋アーキテクチャ
├秋大学院
├秋卒研準備?
└春プロジェクト

その他
├研究室カレンダ
├資料編
├過去
├以前の演習ネタ
├内部
├免責事項
├プライバシー
└転載

メニュー編集

実験とモデル、グラフと可視化、データの怖さ †

今回の目標：
①データを扱う上での一般的な考え方を理解する。
②データを可視化して情報を得る方法を理解する。さまざまなやり方について考える
③データをそのまま鵜呑みにする危険性を理解する。表現法のトリックについて考える。

↑

データを扱う上での考え方 †

測定実験やデータ取りは、やみくもに行うべきではない。

目的がはっきりしていなければならない。というか、目的をいい加減に考えてデータ取りをしても、取るべき項目が抜けてしまったり、精度が足りなかったり、いろいろな不具合が起こるものだ。あらかじめ何のデータをどのようにとるべきかをよく検討しなければならない。

「何のデータをどのようにとるべきか」は、どうやって決めればいいのか？

そこで大事なことは、実験・測定によって何を検証したいのかを明確にすることである。通常は、実験・測定は、自分が立てた「仮説」を検証するために行う。もし自分が「ウサギはカメより早く走る」ということを主張したければ、ウサギとカメを並べて走らせる実験を行えばよいのである。であるから、実験より先に「仮説」がなければならない。

仮説はモデルを伴う。モデルは現実世界の現象をたとえば数式に「モデル化」したものと考える。例はいろいろと思いつくだろう。

実験・測定が仮説「モデルが現実世界の現象に合致する」を検証するのであれば、その検証を出来るように行わなければならない。ここで「合致する」とは何かを決めておく必要がある。

たとえば「抵抗値が一定であるとき電圧と電流は比例する」というモデルが現実と合致することを示すとすると、本来ならば全ての電圧範囲で、もしくは電流範囲で、比例関係が成立することを示さなければならない。当然ながら、高電圧をかければどこかが絶縁破壊を起こすだろうし、高電流をかければ抵抗が過熱し燃えてしまう。全ての範囲での測定は現実に不可能だし、そもそも目前の物理現象に対してモデルが成立していない。であるから、範囲を限定する必要がある。

では、決められた電圧（電流）の区間で比例関係を確認できるか？電圧・電流は数学モデルでは「実数」であるからその間の点は無限に存在する。だから測定しきれない。できるのは、適当な電圧（電流）の間隔で測定し、その測定点について比例関係が成立することを示せるのみである。

ここで言いたかった事は、比例関係にあるはずだというモデルを前提にして、測定の仕方を考えるのであって、闇雲に値を測定すればよいというものではない。

モデルが精密に出来ていても、現象そのものが安定しない（あとで話をする「誤差」が出て、測定した値が実際の値・あるべき値よりずれてしまうなど）場合は、モデルの正当性を主張するために更に測定方法を吟味する必要がある。

↑

データの可視化 †

例１）並列処理にかかる時間を実験して測定し、次のような結果を得た。起動時の引数-nの後の8, 5, 3, 2が並列に処理するプロセッサの個数である。

oregano[yamanouc]% mpirun -n 8 pi_MPI_ver0921
N = 160000000, S = 0.78539816339054757677, pi = 3.14159265356219030707
time = 4.466481e+00 seconds
oregano[yamanouc]% mpirun -n 5 pi_MPI_ver0921
N = 160000000, S = 0.78539816339732648753, pi = 3.14159265358930595013
time = 7.470108e+00 seconds
oregano[yamanouc]% mpirun -n 3 pi_MPI_ver0921
N = 160000000, S = 0.78539816339745860407, pi = 3.14159265358983441629
time = 1.467710e+01 seconds
oregano[yamanouc]% mpirun -n 2 pi_MPI_ver0921
N = 160000000, S = 0.78539816339748236285, pi = 3.14159265358992945139
time = 2.920387e+01 seconds

結果を表にしてみる。

PU数	所要時間
7	4.466481
4	7.470108
2	14.6771
1	29.20387

表では良く分からないので、グラフを描いて「可視化」する。（Excelのグラフ機能を使った）

何となく「反比例」のような気がするが、正確に反比例しているといえるだろうか？

まずあらかじめ、どんな関係になる「はず」かを予想してみよう（モデルを作る。これは非常に大事なことである）。同じ計算量をN個のCPUで分担して計算できれば、１つのCPUが担当する計算量は1/Nになり、時間も1/Nになるだろう。つまり「モデル」としては、処理時間は1/Nに比例（つまりNに反比例）するはず、と言える。

では、実験で得られたデータが、この「モデル」を支持する（サポートする）だろうか？それがここで最も知りたいことになる。もし実験データがサポートしてくれれば、そのモデルが「より真実らしい」という主張ができる。

ここで得られたデータがNに反比例というモデルを支持するかどうかを、より直感的に見てみたいとする。

（直感的方法１）
モデルでは計算時間が1/Nに比例するはずなのだから、それだけを確認するなら横軸をNではなくて1/Nに取り替えてしまおう。そうすれば、比例のグラフ、つまり直線になるはずであり、直線になっているかどうかはグラフに定規を当ててみればすぐに分かる。

PU数	１／PU数	所要時間
7	0.142857143	4.466481
4	0.25	7.470108
2	0.5	14.6771
1	1	29.20387

グラフにすると

（直感的方法２）一般にyがxのn乗に比例するとき（nは整数でなくてもよい）、グラフでその様子を見るには両対数グラフを描くとよい。つまり
　　log(y) = n・log(x)
にしてしまうのである。「両対数グラフ用紙」を買い求めてその上にデータをプロットしてみるのも１つの方法だし、Excelで対数メモリを選択することもできる。Excelで対数メモリにした場合（X, Y軸それぞれに対して「軸の書式設定」で「対数メモリを表示する」を選択する）、次のようになった

個々で確かめるべきことは２つある。第１は直線になっていることであり、もし直線でなければyがxのn乗に比例していないことになる。第２は直線の傾きである。log(y) = n・log(x)であるから、傾きこそがnの値になる。上の図では横軸と縦軸の目盛りが同じ尺度でないので、同じになるように縮尺を調整したのが下図である。

傾きが、モデルで予想したように-1になっているだろうか？

↑

数字の怖さ・表現法のトリック †

数字データに基づく議論は、抽象的な議論に比べて格段に説得力がある。更に、上記で述べた可視化の手法は、データを持って説得する場合に非常に強力な武器になる。

しかし一方で数字やグラフは、誤った理解をもたらしたり、誤った（もしくは敢えて誤解させるように）説得をすることができ、容易に信用させてしまうので、怖い。

↑

データの表現にごまかされる例 †

例）　都合のいいデータだけを示す

例えば道路の車の騒音が問題になったとする。住民の訴えに対して、行政は測定した数値をもって説得したいとする。そのとき、何ができるか？

何回か測定して、規制に収まる値だけを示す
規制に収まる値が出るまで、何度でも測定するこれに対して科学的に対処するためには、実験・実測データについて
実験の条件を明示すること
複数回測定して、どのていどのばらつきがあるかを示すこと（それによって数値をどう評価するかは受け取った側が考える）

などが必要

例）　表現の仕方でごまかす

次の違いを考えてみよ。

このマークシートリーダーは９９％正しく読み取る
このマークシートリーダーは読み取り時に１％も誤る
この試験のマークシートリーダーは１００００人の解答を読み取ると１００人分も誤る

他人の論文を読むとき、表現の裏側を考えることも必要。①ならば気を引き締めて②を、逆に②で悲観的に描いてあるなら①を考える習慣をつけよう。そのように考えると新しい視点が開けることがある。

↑

測定が間違っているのに気付かない例 †

データが取れなければ（測定エラーになれば）気付くのだが、エラーを出さずに間違った値を読んでいる場合が怖い。

例）　飛行機で、速度計（空気圧差によるピトー管）の流入孔に虫が発生して詰まり、正しく測定さていなかった。離陸時に十分な速度が出ていないのに機首を引き上げたため、失速して墜落した

例）　断層がないというデータを信じていたが、柏崎刈羽原子力発電所の間近に断層があり、それがずれたために大きな地震被害があった

↑

計算にごまかされる例 †

コンピュータによる計算は、一見すると非常に正確に見えるが、任せ切るととんでもない誤りをすることがある。コンピュータ処理を仕事とする人は、常に頭の片隅において欲しい。

例１）プログラムが間違っている例
一般にプログラムは複雑なので、間違いに気付きにくい。

例として、自動改札機が一斉に停止したトラブルを挙げておこう。以下は朝日新聞のサイトからの抜粋である。授業中にリンクをたどるとみづらいので、かなりの部分を引き写させていただく。
（出典：　http://www.asahi.com/national/update/1027/TKY200710270270.html）

2007年10月28日13時34分

　首都圏の鉄道で１２日と１８日の早朝に起きた日本信号（本社・東京）製の自動改札機と窓口処理機の障害の原因は、プログラムがわずか日本語１文字分のデータの処理を誤ったためだったことがわかった。「極めて単純なプログラムミス」と専門家が指摘する欠陥は、のべ７２７駅、２６０万人の足に影響する事態に発展した。

　１２日は改札機４３７８台、１８日は窓口処理機１０１台で障害が起きた。どちらの機器も、ＩＣ乗車券「Ｓｕｉｃａ（スイカ）」と「ＰＡＳＭＯ（パスモ）」の相互利用に対応している。

　日本信号によると、期限切れなどの理由で使えなくなったカードをチェックするため、無効カードの情報（ネガデータ）が相互利用センターのサーバーから各駅の駅サーバーに送られてくる。駅サーバーはデータ処理に必要な情報を加えて、改札機や窓口処理機にネガデータの情報を送る。

　両機器は毎朝の立ち上げの際、ネガデータの最新版を取り込む。その際、窓口処理機は駅サーバーから直接データを受け取るが、改札機は監視盤という機器で書き換えられたデータを受け取る。

　障害の引き金になったのが、２バイト（２進法で１６けた）のデータだった。例えば改札機の場合、ネガデータは５４５１件分（６万５５１８バイト）を一区切りとして処理される。処理は４バイトずつ進めるため、最後に２バイト余る。全角ひらがなや漢字１文字分のデータ量だ。

　半端な２バイトも、件数がこの一区切りまでなら正常に処理されていた。だが、５４５２件以上になると「８５件増すごとに５件の割合で、余った２バイトの処理を忘れる」（同社）というプログラムの欠陥があった。

　相互利用が始まった３月から９月下旬まで、ネガデータは障害が発生する件数に達していなかった。以後もたまたま障害の条件をすり抜けていたが、１０月１２日のデータは「５件」に合致して２バイトが欠落し、改札機が立ち上がらなくなった。

　窓口処理機でも同様の処理が行われているが、データの受け取り方の違いから１２日に障害は起きなかった。だが、１８日には「５件」の条件に当てはまった。

　今回の事態を受けて日本信号では、すべての機器のプログラムの見直し作業を進めている。

例２）データによって、プログラムが間違った（又は信頼できない）結果を出す。具体的には、

プログラム作者がその状況が起こりえることに気付いていない
その状況が起こりえることをマニュアルに書いていない
マニュアルの片隅に書いてあるのだが見落とした

などの状況が考えられる。

例として、我々が書きそうなプログラムを考えてみる。次のプログラムはＮの階乗（１×２×３×...×Ｎ）を求めようとしている。

public class factorial {
  public static void main(String[] args) {
    int result = 1, N = 20;
    for (int i=1; i<=N; i++) {
      result = result * i;
    }
    System.out.println(result);
  }
}

このプログラムは、原理的には正しい。しかし、Ｎが1３を超えると32ビット整数ではオーバーフローを起こし、正しい結果が得られない。このプログラムでＮが20として計算すると-2102132736を得る。これなら負になるので異常だと分かるだろう。Ｎを１から順に増やして行って階乗を計算した結果は

1!   = 1
2!   = 2
3!   = 6
4!   = 24
5!   = 120
6!   = 720
7!   = 5040
8!   = 40320
9!   = 362880
10!  = 3628800
11!  = 39916800
12!  = 479001600
13!  = 1932053504
14!  = 1278945280
15!  = 2004310016
16!  = 2004189184
17!  = -288522240
18!  = -898433024
19!  = 109641728
20!  = -2102132736

このようになった。１３の階乗から下の桁が00になっておらず、計算が間違っている。（下の桁が00の数に整数を掛けたら、やはり下の桁が00になるはずだ。）　１７・１８・２０の階乗に至ってはマイナスになっている。　

なぜこのようになるのか？　計算のオーバーフロー（桁あふれ）が発生しているのである。　コンピュータ内の整数の計算は（特に指定しない限り）符号付き３２ビットで行われている。表現できる正の最大の数は231-1＝約2,000,000,000であるから、13!=6,227,020,800を表す（符号付３２ビットの整数変数として乗算結果を表す）ことはできず、オーバーフローが発生する。

ここでの問題の核心は、オーバーフローが起こって結果が間違っていることを、教えてくれていないことである。結果の値を見て誤りを見抜ければよいのだが、みなさんは 13! = 1932053504と言われて「何か変だ」と見抜けるだろうか？

例３）　使い方が間違っているために、誤った結果を出す

⇒特別ゼミBトップへ戻る

最新の10件