結局どうやったって確率は変わらない -ナンバーズ３予想-
ナンバーズ３の当選番号は予想できるか？
勿論、答えはNOであるが、よく予想サイトなどでは可能であるかのように書いてあります。
よくある手法としては、「確率が低い番号の組み合わせを削除していき、残った番号から買う」というものです。「確率が低い番号の組み合わせ」というものは例えば次のような条件に当てはまる番号のことです。
今回はボックスで購入した場合を考えます。
- 前回の当選番号のそれぞれの和と同じ番号の組み合わせ
- ３つとも偶数
- ３つとも奇数
- 前回とボックスでの当選番号が同じ
- ３つそれぞれの和が極端に小さい
- ３つそれぞれの和が極端に大きい
- ３つすべて同じ番号（３つとも偶数または３つとも奇数）
- ２つ以上同じ番号が含まれる
当然このような番号の組み合わせを省いたところで、当選確率など変わらない。変わらないけど、一応シミュレーションしてみましょう。
過去79回について上記の条件に当てはまる番号の組み合わせを省いた時、残りの番号の組み合わせの中に当選番号が存在した割合を調べてみた。ちなみに買い方はボックスである。
シミュレーション結果
結果は、79件中42件で当選番号が存在した。割合としては53.16%である。
また、上記の条件に当てはまる番号を省いた残りの番号の組み合わせは平均90.40パターンであった。
つまり、90.40個の番号の組み合わせの中に当選番号が存在していた割合は53.16%であったということだ。
よってこの手法による当選確率は、
ボックス（しかも３つすべて異なる数字）の当選確率の理論値はなので、つまりそういうことである。
まとめ
３つの番号はそれぞれ独立なので当然どう予想を頑張っても確率は変わらない。
ではどうしてそのような予想サイトが存在するかというと、当然金儲けである。このようなサイトの多くは「会員費」という形でお金を得ている。
こういう所謂、情報商材は似非がほとんどなので注意が必要です。
実験計画法１ -フィッシャーの三大原則-
実験計画法とは
分散分析などの統計的手法を用いるときには信頼性の高いデータが必要になる。実験計画法とはそのデータを効率よく得るためのマナー集のようなものです。
フィッシャーの三大原則
フィッシャーの三大原則は信頼性の高いデータを得るための決まり事です。
なぜ信頼度の高いデータが必要か。分散分析の統計量は以下のように表されるのでした。
目的となる要因以外からの影響が小さい、つまりが大きいデータでなければ目的要因の効果を検出するのが困難になるから信頼度の高いデータが欲しいのです。
その信頼度の高いデータを得るためにフィッシャーの三大原則を守って実験を行う必要があります。３つの原則は以下のとおりです。
- 局所管理の原則
- 反復の原則
- 無作為化の原則
局所管理の原則
目的となる要因以外を制御するために、空間や時間を小分けにします。
それにより、誤差効果を生み出す条件が均一になり群内変動（の分母）が小さくなります。
反復の原則
水準（群）ごとに実験を反復させて同水準内で２つ以上のデータ（データ数）を確保します。
水準間で異なるデータが得られたとしても、が小さければそれが要因効果による差（統計誤差）なのか偶然の差（確率誤差）なのか判別できないからです。
そもそもの時、
の分母である群内変動を計算することができなくなります。
無作為化の原則
局所管理の原則で「要因以外を制御」と述べましたが、実は特定の水準に制御するのもよくありません。
なぜなら、その水準だけが他の要因と交互作用を発揮する可能性があるからです。
よってそのような要因があったとすれば、実験からこの要因を削除することは損です。
そこで、無理に水準を制御しようとせず、要因が偏りを持って実験に影響しないようにランダムに行おうというのが無作為化の原則です。
例えば、時間経過によって効果や結果に影響を受けることが予想される場合は試験の順番をランダムに行います。
乱塊法
上記の三原則に従っても、もともと目的要因以外の効果が大きいと誤差変動が大きくなります。つまり、目的要因の効果が検出されにくくなります。
そこで、水準を自由に制御できないもので、間違いなく実験結果に影響するものは１つの要因として組み込みます。これが乱塊法です。
まとめと次回
フィッシャーの三大原則は精度の高いデータのとり方に関する手法であり、なるべく要因以外の誤差を無くすことを目的としていました。
次回は、効率よくデータを得るための手法のひとつである、直交配列表について紹介します。
参考文献
Railsチュートリアルをやり終えた感想
Railsチュートリアルを一応１周やり終えたので感じたことなどを少し書いてみようと思います。
どうしてこの記事を書こうと思ったか
興味はあるけどボリュームがあってやるのが億劫だなぁと思ってる人に、ちょっとでも雰囲気を知ってもらったり、他人がどのように取り組んだか参考になればと思ってこの記事を書きます。
「次はこうやってやってみるといいよ」というアドバイスもお待ちしております。
前提知識はあった？
- ITの知識は応用情報技術者程度。
- Rubyの基礎はあった。Rubyの父監修の書籍を買って、paizaの問題とかを解いたりしていた。
- HTML/CSSは大丈夫、JavaScriptは読めるけど書きたくはない(笑)
- 以前にもRailsチュートリアルをやったことがあるが（4系）、途中で挫折。
- 挫折しながらも、書籍を買って作りたかったアプリを自作したこともあった。フロント部分やサーバの設定で躓き挫折。
ご覧の通り、とてもヘタレであることがわかります。
Railsチュートリアルをしようと思った理由
理由は２つあります。
Webアプリの開発に興味があった
近年様々なWebアプリが登場し、自分も作ってみたいという欲求があったのですが、それに加えてRubyを少し勉強していたというのもあります。
また、有名どころのサービスがRailsを使っていたり、開発ブログなどを見ていると興味が出て来たという感じです。
やっぱり諦めずに作ってみたいという気持ちがありました。
内容がとても分かりやすかった
始めようと思った理由とはちょっと違うかもしれませんが、ちらっと内容を見た時にとても分かりやすそうな説明だったからです。現に、最初から最後まで分かりやすかったです。
書籍で勉強をしたこともありますが、「見たことないコードが突然出て来た」とか「それ、どこのコードの話？」というストレスが無かったことが大きいです。
どれくらいかかった？
まる１年かかりました。
というのも、途中Python3に浮気してたりしたので完走まで時間がかかってしまいました。
序盤は１日１章でも十分こなすことができますが、中盤のログイン機構などはなかなか手ごわいので時間がかかります。ボリュームも凄いので根気が必要です！
１ヵ月以内で終わらせるストイックな人は尊敬します。
どうやってRailsチュートリアルを進めていった？
１章から順に
１章から順に進めていきました。完成したファイルがあるといっても、内容は順序だてて構成されてるので順番にこなすのが無難だと思います。
適宜メモをとる
また、4系のチュートリアルで挫折した経験を踏まえて、適宜メモを取るようにしました。よく使うテクニックや、基本的な手順、調べないとわからないだろう点を中心にメモを取りました。
再びわからない箇所へ戻って考える手間を考慮するとメモを残しておく方がお得だと思います。「ここ確かメモしてたな」ってのは覚えてるもので、Ctrl+Fで検索すればすぐ対応できます。
コピペでもいいけど、コードは全て理解する
特に1周目、完走することを目的とした場合、コードはコピペでもいいと思いました。
ただし、コードはすべて理解してから進めるようにしました。「わからんけど、貼っとくか」では意味無いですからね。
あと、コードを手打ちすると必ずと言っていいほど入力ミスによるエラーが発生します。このエラー探しが完走までのモチベをじわじわと削っていくのです。
演習はやったりやらなかったり
演習はすべてやったわけではありません。
「ここをこうすればよさそうだな」程度のことは考えましたが、正直コードをいじるとテストがレッドになりそうで怖かったです(笑)
Railsで開発するためにこれから必要だと思うこと
- 調べる力
- フロント部分の知識（JavaScriptやjQuery, Ajaxなど）
- コードの管理能力（GitとかGithub）
- デザイン能力
- データベースの知識
- 構築、運用、管理の知識
Railsは便利な一方、規則も多くあるので、こういうときどうすればいいか調べて解決する力は今後も必要だと感じました。チュートリアルでは「こんなときはこんなメソッドがあるんです」と紹介してくれますが、自身で開発となるとそうもいきません。
チュートリアルではデザインも含めたフロント部分は最小限しか紹介されていないので、自分好みになんやかんやする場合は勉強が必要です。
また、アプリを公開するとなると運用管理の知識も必要になります。
学ぶべきことは山ほどありますね。
最後に
本当に、大変でした(笑)
説明が丁寧なのでこんななまけものでも完走することができました。興味のある方はぜひRailsチュートリアルにチャレンジしてみてください。
railstutorial.jp
今後についてはまだ決めかねていますが、かねてより作りたかったサービスをまた作り始めるかもしれません。これについてはまたここで報告出来たらなと思います。
あと、もし働かせていただける企業様がおられましたらご連絡お待ちしております(๑•̀ㅂ•́)و✧
