Transcript PPTファイル
シミュレーションの基礎の基礎 ～プログラムの考え方と作り方～ 最終更新日；2010/12/12 D093481 永井 勇 1 目次 • はじめに • シミュレーション作成の全体の流れ – それぞれの流れの中身 – 全体の流れを確認するためのまとめ • シミュレーションのプログラムを作る上で大切 なこと • 最後に • 参考文献 2 はじめに • シミュレーション作成上での、基礎の基礎の部分 です。 • 次のような人用として考えています。 – シミュレーションのプログラムを作ろうとしているけど、 何から手を付ければいいか分からない人 – 今までプログラムを組んだことがない人 – 組んだことがあるけど、昔過ぎて忘れた人 – “言語”(C言語、C++言語、Java言語)がどうのこうのとか 以前の問題だよという人 – R、Matlab、Scilab、Mathematicaなどのソフトがあるけ ど、どっから手を付ければいいかわからない人 • 考え方を押し付けるわけではありません。 – 自己流で何とかできる人は、対象外です 3 シミュレーション作成全体の流れ 1. 2. 3. 4. 5. 6. 7. 8. 9. 逆（結果）から考える 全体の設計図を作る どの言語・ソフトを使うか決める 必要な事（関数など）を調べる 実際に作ってみる エラーのチェック修正 シミュレーション本番 (余力があれば)高速化 結果のまとめと考察 4 1.逆（結果）から考える （シミュレーション作成全体の流れの内 1/9 ） 5 １．逆（結果）から考える I. 逆とは？ II. 逆から考えるとは？ III. 結果がない場合は？ • 必要なモノ – IIIでない限り、シミュレーションの結果の明確な目標 • 推定量の比較をするのか？ • バイアスの補正項の比較をするのか？ – 途中計算などと最終的な結果 • 推定量ならば、最終的な推定量の形 • バイアスの補正項ならば、バイアス補正の計算結果 ⇒つまり、「シミュレーションをしろと言われた事に 関する事が書いてあるノート＋シミュレーションの 明確な目標」が必要 6 １のⅠ 逆とは？ • 命題の逆とは違う • 証明問題に近い形 – ＯＯを示したいから、ＸＸを示そう。そのためには… • 逆から考えるメリットとデメリット – メリット • やるべきことが整理整頓できる – 内容の整理も頭の中でできる • 結果として欲しいものが常に見えている • 過程が複雑な場合でも、考え直したり見直したりしやすい – デメリット • いつもの考え方と反対で、やりにくい • 結果がないとできない(結果がない場合はⅲへ) • 実際に作るときに、もう一回逆にして考えなければならない 7 １のⅡ 逆から考えるとは？ (1/2) • 結果から逆向きに考えていく 1. 結果として何が欲しいのか？比較したいものは何か？ • できる限り明確にする – – 比較するものは何と何なのか どういう基準で比較するのか 2. そのために何がいるのか？ • 比較する対象に必要なものは何かを考える – – – どんなデータがいるか 真値を使うのか 推定量がいるのか 3. 2のために必要なパラメータなどは何か？ • 何が真値なのかを考える – サンプル数は？次元数は？ – 未知のものはどう決めるか？ » 共著者や先生・指導者と話し合うと良い 8 １のⅡ 逆から考えるとは？ (2/2) 4. データをどう発生させるのか？ • 必要なデータを考える – 平均は？分散は？相関の形は？分布は？ – モデルに合うように発生させるのか？ » モデルの中のパラメータはどうするのか？ 3で決めた真値などが必要になる場合もあります 5. データを発生させるパラメータの決定 • 分布などの詳細を決める • 必要な事 – – – – シミュレーションをすることへの意欲・危機感 シミュレーションをする目的 データの構造やモデルなどの仮定されている事 9 パラメータを決める勇気と慣れ １のⅢ 結果がまだない場合 • シミュレーションをやれと言われたけど、まだ 結果がない人 – 方法① できている部分から逆に考える 1. 途中までできている場合は、そこから逆に考える 2. 結果が出た時に、結果から1で作った部分まで逆に 考えてつなげる 3. 全体を見て、不明なパラメータがないか・記号の統 一ができているかどうかをチェック – 方法② データの発生から順に考える 1. モデルから順に途中までの流れを考えていく 2. 方法①の2と3と同じ – 方法③ 結果を急いで出す • どうせいずれ出さなければならないのだから 10 2.全体の設計図を作る （シミュレーション作成全体の流れの内 2/9 ） 11 プログラムなのになぜ、設計図？！ • プログラムを作る上での設計図 – 呼び名があります • アルゴリズム • フローチャート – 微妙に意味が違いますが、省略 – 部屋や家の設計図とは異なる • プログラムを作っている途中で変更する場合もある • 設計というか流れを図示したもの • メリットとデメリット – メリット • プログラムが作りやすい • この時点でミスを見つけることができる • チェックや見直す場合にノートから考え直す必要がない – デメリット • ちゃんと書くと、めんどう • 紙が必要 • 一応、決まりがある 12 全体を一気に描く必要は？ • 全体の設計図ではありますが、一気に全部描かな くてもO.K. – ブロックでまとめて描いて、あとでつなげる • データ発生部分、推定部分、評価する部分と分けて作るなど – 注意事項 • 記号は統一したほうがよい – 後々のプログラムを作る際に、迷わないため • 順にみて、不明なパラメータを急に入れない – 不明なパラメータを最小値探索などで入れる場合は、そう書いておく • ブロックごとにチェックと修正をする必要がある – 全体のチェックに比べて、厳しめでチェック – 全体を通してチェックするより少量でいいが、ブロックが多いと疲れる • 全体のチェックの時にもう一回見直す必要がある 13 全体像を描く手順 (1/2) 1. 逆に考えて作ったものを、逆にする – つまり、流れの方向を順方向にする 2. 詳細まで埋める – その流れを見ただけで、順に何を求めているか分かる ようにする。 3. 流れを数式で書く – 例えば • f(x,y)を求める → f(x,y)の結果をzとすると、g(z)を求める → g(z)で得られた結果をxとして、再びf(x,y)を求める 4. できる限り記号化 – 先の例で書くなら • zにf(x,y)を入れる → x’にg(z)を入れる → y’にf(x’,y)を入れる → y’を結果として表示する 14 全体像を描く手順 (2/2) 5. よりプログラムに近づくように記号化 – フローチャートを描く • 色々記号に決まりはありますが自由に、上からスタートして、 （ループする箇所を除いて）下に向かって流れるように描く • HP(アドレスは下にあります)上にある札幌学院大学の先生が作 られたPDF（第一章. アルゴリズムの表現－流れ図）を参照せよ HPアドレス；http://sci-tech.ksc.kwansei.ac.jp/~inagai/write/write_index.html • シミュレーションの規模が大きさ と フローチャートの長さ は比例 のような関係がある 6. フローチャートからプログラムへより近づける – 順を追って流れを見たときに、不明な部分がないように 詳細まで描く – “Yes” or ”No”以外での分岐を別の方法を考える • 例えば、ある条件でkeyを1にして、keyが1かどうかで判定 15 3.どの言語・ソフトを使うのか を決める （シミュレーション作成全体の流れの内 3/9 ） 16 言語やソフトについて • シミュレーションを組む時に、何を使って組むのか を決める – C言語、C++言語、C#言語、Java言語を使って組む – ソフトを使ってシミュレーションをしたい • Matlab, Mathematica, Mapleなどの数式処理ソフトで組む • 統計ソフト（R、SPSS、S-PLUSなど）で組む • 言語やソフトを決めた場合、 「ほかの言語やソフトに安易に移行できない」 という制約が付く – 例外的に安易に移行できるソフトもある – 言語やソフトごとに得意・不得意な処理はある 17 それぞれのメリット・デメリット • ＯＯ言語を使う場合 – 使える環境にする必要があるかもしれない – プログラムの自由度がソフトを使うより高い – 色々な処理を自分で準備する必要がある • 行列の掛け算などは自分で作る必要がある場合も – 他の言語やソフトで作ったものもある程度理解できる • ソフトを使う場合 – 有料なものがある • Matlab、Mathematica、SPSS、S-PLUSなど – プログラムの自由度が言語を使う場合より低い – ある程度の処理は準備されている場合がある • 言語を使う場合に比べて簡単に作れる • 統計のシミュレーションをする場合のお勧め – R ；無料なので気軽に自分のPCに入れることも可能、資料が豊富 – C言語 ；一回組むと考え方が身に付く、他のソフト・言語でも応用が利く 18 – Matlab；研究室のPCに入っていて、行列演算に特化 4.必要な事(関数など)を 調べる （シミュレーション作成全体の流れの内 4/9 ） 19 必要なことを調べる • フローチャートに描いたモノを実際にプログラムとして 組むときに必要な事を調べる – 調べる事の例 • • • • • • • • 変数への代入の方法 条件での分岐の方法 繰り返して処理をする方法 キーボードからの入力やディスプレイへの出力 ファイルへの出力 関数の宣言の方法 最小値探索の方法 ソフトにあらかじめ入っている関数(組み込み関数)の有無など – 調べ方 • インターネットを使う – 使う言語やソフト＋やりたいこと で検索するなど • 使う言語やソフト名の入っている本を見てみる – 作っているものと同じものはないが、応用などして使えるものも多い • マニュアルを読む – マニュアル読んでも、分かりにくい場合が多いので、最後の手段 20 5.実際に作ってみる （シミュレーション作成全体の流れの内 5/9 ） 21 実際に作ってみよう • フローチャートで描いたモノ と 調べたことを合 わせて、実際に作ってみよう – ブロックごとに作ってもよし – 全体を一気に作ってもよし – 自作関数の部分だけ作ってもよし • 作り方は、自由！！ – 勢い と 慣れ で作ってみよう – 作った部分は、対応するフローチャートの部分に 分かるように印をつけておくといいかも 22 6.エラーのチェック・修正 （シミュレーション作成全体の流れの内 6/9 ） 23 エラーのチェック・修正 • なぜ必要なのか？ – エラーとして表示される場合 • エラーメッセージを見ながら、思いつく限りのことをしてみる – エラーとして表示されない場合 • 何かしら変な処理をしている場合は、その修正案を考える • 少しずつ処理をさせて、表示させてみる。 • 「表示されないから、エラーはない」は少し危険性がある • 自作関数の場合のチェック – エラーが起こる場合を作ってみて、関数に入れてみる • 組み込み関数のエラーの場合 – 組み込み関数の内容をもう一回見直してみる – 違う関数を使ってみる – 関数に渡す変数を変えてみる 24 7.シミュレーション本番 （シミュレーション作成全体の流れの内 7/9 ） 25 シミュレーション本番 • フローチャートの流れに沿って、プログラムができ たら、実際に回してみよう。 – 注意 • 本番でエラーがないように、しっかりチェックと修正をし てから実行せよ • 結果が分かるように、結果をディスプレイかファイルに 出力させる • 何回も全体を反復して時間がかかる場合は、テストとし て数回か反復させてみてから、本番を行う • 予想外に時間がかかる場合もある • 自分のPCでやる場合は、他の作業ができない場合もある 26 8.(余力があれば)高速化 （シミュレーション作成全体の流れの内 8/9 ） 27 高速化とは？ • シミュレーションにかかる時間を短くすること • そのために考えられること 1. 無駄な処理をしない 2. 同じ処理をするなら、一つの関数でまとめる 3. 自作関数と組み込み関数が同じ処理を行うならば、 組み込み関数を使う 4. 入出力は最低限にする – なぜか？ • 無駄な処理は間違いを引き起こす可能性もある。 • 一つの関数の場合、それさえ読みだしてしまえば、あとは 同じ処理で可能なので、早くなる場合がある • 組み込み関数は、あらかじめあるので早い場合が多い • 入出力には、意外と時間がかかるため • 余力がなければ、やる必要なし 28 9.結果のまとめと考察 （シミュレーション作成全体の流れの内 9/9 ） 29 結果のまとめと考察 • シミュレーションの結果を、表などでまとめる – これをしなければ、シミュレーション自体が無意味 – 各パラメータごとの結果をまとめる • 見やすく・分かりやすくまとめる • 考察をする前に結果から分かる事を全部書く – 箇条書きでよい – どんなに小さいことでもよい • フローチャートなどは全て保存しておく – 間違いが後で見つかった場合に備える – 別のシミュレーションを作る場合に、同じようなも のが使える可能性がある 30 シミュレーションを作る流れ ～まとめ～ 1. シミュレーションをする目的を明確にする – 何が知りたいのか、何を比較するのか 2. 流れを描く – フローチャートを詳細まで詰めて作る 3. 4. 5. 6. 7. 言語やソフトを決めて、必要なことを調べる 実際に作ってみる エラーのチェックと修正をする シミュレーション本番 結果のまとめと考察をする • 1と2はノートでもルーズリーフでもできる 31 プログラムを作る上で 大切なこと 最後に と 参考文献はその後ろです。 32 • プログラムを作る上で大切な事は、 「エラー・修正の繰り返しで完成に近づいていく」 – 失敗は成功の元！！ – 一度もエラーを起こさず作れるのは、まだまだ先の話 • 見やすいプログラムを作るため 1. 字下げの活用 • タブ(Tab)やスペースの活用 2. コメントの活用 • プログラムの実行には無関係だが、見直すときに便利 • 言語や使うソフトによってコメントの仕方は違うので注意 3. 「他人に見せて、分かりやすい」を心がける • 研究内容が全く違う人が見ても、何をしているのかが分 かるように 33 最後に • この資料が全てではありません。 – 本やネットには、それぞれの言語やソフトに特化した 分かりやすい説明があったりします。 – 自己流を形成する踏み台にでもしてください。 • 謝辞 学部時代にプログラムに関する膨大な知識と経験をくださった広島工業大学工学 部知的情報システム工学科の先生方へまずお礼申し上げます。 また、大学院時代にプログラムに関する授業のTAをやらせていただいた広島大 学の栁原先生、大西先生、西森先生から学んだ事により、この資料を作る機会とこ の資料の目標とするものが明確になったことに関して、お礼申し上げます。 さらに、広島大学の若木先生、大滝先生、佐藤先生、冨田先生には、様々なデー タ解析のプログラムなどに触れさせていただき、ありがとうございます。この経験に より、自分の知らない部分が減ったと思います。 最後に、この資料を作成するにあたって、キッカケおよびチェックや資料の提供を していただいた、2010年度の統計グループの4年生と博士課程前期の院生、およ 34 び修了された秋田先輩にお礼申し上げます。 参考文献 • 何かしら分かりやすい参考文献があればい いですが、言語やソフトを決めた上での参考 文献はある一方で、このような資料は少ない と思います。 • 参考文献として、次を挙げておきます。 – これからはじめるプログラミング 基礎の基礎,谷 尻 豊寿 監修，谷尻 かおり 著, 2008, 技術評論社 35 終 了 後は、各自で色々やってみよう。 36