統計のお話(正規分布と母集団と標本について)

コロナのせいで引きこもり生活を始めたばかりの頃、密かに統計のお勉強をしていた。

まだほんの序盤ではあるが、なかなか楽しい学問であり、学生時代にもう少し学んでおけばよかったと思った。

復習と数学的準備

反復試行の確率

1回の試行で、事象 {A} が起こる確率を {p} とおくと、事象 {A} が起こらない確率 {q}{q = 1 - p} となる。

この試行を {n} 回行って、そのうち {k} 回だけ事象 {A} が起こる確率  {P_{k}} は、{ P_{k} = {}_{n} \mathrm{C}_{k} p^{k} q^{n-k} } である。

二項分布

ここで、確率変数  { X = k } とおくと、 {P_{k}} はそのまま確率関数となり、離散型の確率分布が定まる。

この確率分布を 二項分布 と呼び、 {B(n,\,p)} で表す。

正規分布

二項分布  {B(n,\,p)} {n} {\infty } に近付けると、最終的に 正規分布 と呼ばれる連続型の確率分布になる。

正規分布は、その期待値  {\mu} と分散 { \sigma^{2}} を用いて、 {N(\mu,\,\sigma^{2})} と表す。

確率密度関数積分すると確率になる関数)は  { f_{N} (x) = \displaystyle\frac{1}{ \sqrt{ 2 \pi } \sigma }  e^{ - \displaystyle\frac{ ( x - \mu )^{2} }{ 2 \sigma^{2} } } } である。

ちなみに、この正規分布確率密度関数の導出はちょっと難しい。
せめてヒントだけでも!!
わかったよ。これ知ってる?
  • {x} が十分大きいときに  { \displaystyle\frac{ \log (x!)}{dx} \sim \log (x) } と近似できること
  • { \displaystyle\int_{-\infty}^{\infty} e^{- \displaystyle\frac{x^{2}}{2}} dx = \sqrt{2 \pi} } であること
なんで \( \int_{-\infty}^{\infty} e^{- \frac{x^{2}}{2}} dx = \sqrt{2 \pi} \) になるの?
これはガウス積分といって、大学の試験で出題されるレベルなので、ちょっとここでは……。
やだやだ! 知りたい!!
いきなり \( \int_{-\infty}^{\infty} e^{- \frac{x^{2}}{2}} dx \) を求める前に、こんな重積分 \( \int_{-\infty}^{\infty} \int_{-\infty}^{\infty} e^{-x^{2}-y^{2}} dx dy \) を考えてみようか。
あ、これ、極座標変換しないと苦しいやつだ。

そうだね。

頑張って計算すると、\( \int_{-\infty}^{\infty} \int_{-\infty}^{\infty} e^{-x^{2}-y^{2}} dx dy = \pi \) になる。

左辺を式変形すると、\( \left( \int_{-\infty}^{\infty} e^{ -x^{2} } dx \right)^{2} \) となり、さらに両辺のルートを取ると \( \int_{-\infty}^{\infty} e^{ -x^{2} } dx = \sqrt{\pi} \) になる。

あ、、\( \pi \) が出てきた。
あとは \( x = \frac{z}{ \sqrt{2}} \)、\( \frac{dx}{ dz} = \frac{1}{\sqrt{2}} \) で置換して \( z \) で積分するといいよ。
なるほど……(思った以上にめんどくさい)。

身に付けておきたい考え方

離散型確率分布と連続型確率分布

動いている時計をカメラで撮ったとき、秒針がちょうど文字盤の真上(0秒地点)にある瞬間にシャッターが切れる確率について考える。

実は、その時計がチクタクと動いて離散的に時を刻むタイプかヌルヌルと止まらずに動き続けるタイプかで確率が変わってくる。

チクタクと動く場合は  {\displaystyle\frac{1}{60}} だが、ヌルヌル動く連続型の場合、円周上の無限にある点のうちの一点を指す確率になるので、 {\displaystyle\frac{1}{\infty} = 0} になる。

連続型確率分布を扱う場合、確率変数は点ではなく範囲で考える。

つまり、0秒ぴったりを指す確率は  {0} だが、0秒〜15秒のどこかに入る確率は  {\displaystyle\frac{1}{4}} である。

この 0秒〜15秒という範囲の中に、0秒や15秒といった境界値を含むか含まないは考えなくてよい。 なぜなら、含もうが含むまいが、0秒(もしくは15秒)ぴったりになる確率はどうせ {0} だからだ。

母集団と標本

巨大な母集団から、無作為に  {n} 個の 標本  {X_{1},\, X_{2},\, \cdots ,\, X_{n}} を取り出すことを考える。

ここで、 {X_{i}} を標本の取り方によって変化する確率変数と見なす。

母集団は非常に巨大なので、 {X_{1}} を抽出したとしても、それ以外の標本の要素の抽出結果に影響を与えない。

よって、 {X_{1},\, X_{2},\, \cdots ,\, X_{n}} は、同一の確率分布に従う母集団から、それぞれ個別に抽出された、互いに独立な確率変数と見なすことができる。

いきなり訳がわからなくなったぞ。

標本が、確率変数??

まぁ、あれだよ。

たとえば動いている時計をカメラで 100 回撮って、その秒針が指す位置を記録するとするでしょ?

うん。
そうすると、100回分の記録が取れるでしょ?
うん。
その100回分の記録が入る変数を、\(X_{1} , \, X_{2}, \, \cdots , \, X_{100}\) で表すイメージ。
独立な変数って、どういうこと?
すごく雑な説明なんだけど、\( X_{1},\, X_{2},\, \cdots ,\, X_{n} \) が、他のどの変数を使っても書き表せないことだね。
どういうこと?
たとえば \( X_{3} = 2 X_{1} + 5X_{2} \) みたいに、他の変数を使って表現できる場合、それらは独立ではないんだ。

あれ、、ちょっと混乱したかも。

「時計の写真を100回撮る操作」を何回も何回も繰り返せば、偶然たまたま \( X_{3} = 2 X_{1} + 5X_{2} \) が成り立っちゃうこともあるんじゃない?

標本を取るたび、\( X_{1},\, X_{2}, \, X_{3} \) は毎回変わるでしょ?

\( X_{3} = 2 X_{1} + 5X_{2} \) は、確率変数の中身が何であっても成り立つという意味だから。

そうか、、 確かに \( X_{1},\, X_{2} \) の結果で \( X_{3} \) が常に決まるわけではないもんね……。

そうそう。

確率変数 \( X_{1},\, X_{2},\, \cdots ,\, X_{n} \) が、ほかのどの確率変数を使っても書き表せない場合、独立な確率変数って言うんだ。

もう一つ質問。

母集団って離散型なの? 連続型なの?

えーっと、厳密には離散型なんだけど、ほぼ連続型と考えていい。

でも、もはや離散値として扱いきれなくなっていることが多いから、連続型の確率分布に従うものと見なしてしまうね。

でも、さっきの話だと、連続型の場合は確率変数を点で考えちゃダメなんだよね?

確率がゼロになっちゃうから。

ボクも極限について厳密に理解しているわけではないので、ここはもうフィーリングになっちゃう。

限りなく連続型に近いんだけど実は離散型だから、標本 \( X_{i} \) を取ってきて、その実現値を確認することができるのだと都合よく考えている。

ふむ……。

Former2 と CloudFormation の話 #AWS

TL; DR

Former2 というツールを使うと、既に構築済みの AWS リソースの設定情報をエクスポートできるよ。

これを、AWS の CloudFormation に喰わせば、インフラを簡単に再構築できるんだ。

ふむ……?(それのなにが便利なんだろう)

Former2

ナイスな導入

AWS には、たーせるくんのようにインフラの素人でも簡単にネットワークを構築したりサーバを立てたりできる GUI が整っているでしょ。
いわゆるマネジメントコンソールってやつだね。

そうそれ。

ただ、場合によってはマネジメントコンソールではなく、設定ファイルからリソースを一括で自動作成する方が早いこともあるんだよ。

さらば憂鬱すぎるやり直し作業

ところで、キミのその設定、なんかおかしくない?

ああああ…… CloudWatch で監視設定したら、アラーム名をタイポしてしまった……。

一度設定したアラーム名はもう変更できないから、もう一度はじめからやり直しになっちゃう……。

ドジっ子さんめ。 再作成が1つや2つならいいけど、10個、20個になるとキツいね。

マネジメントコンソールの GUI をチマチマ操作する作業を何十回も繰り返すのは切ない。

やる気なくすわー。

せめて現状の設定内容をテキストにエクスポートして、アラーム名を grepグレップ で文字列置換して、再度インポートできればラクなのに。

それなら Former2 を使えば AWS リソースの設定内容をエクスポートできるよ。

なるほど!

エクスポートした設定はどんな形式になるの?

YAMLヤムル という一種のテキスト形式だね。

テキストエディタで編集もできるし、AWS の CloudFormation というインフラ自動化サービスを使えば同じ設定のリソースを一括作成できる。

それはすごい。

まさしく僕が求めていたものだ。

Former2 は、サードパーティ製ツール

ちなみに Former2 は公式ツールではなく、サードパーティ製のツールなんだ。
公式じゃないのか……。
一応、公式にも CloudFormer というツールがあるにはあるけど、ずっとベータ版だし、もうアップデートされる見込みはないし、公式が Former2 を使えと言っているくらいだし……。

必要なのは、ReadOnlyAccess ポリシーを持つ IAM ユーザ

Former2 はものすごく直感的に使えるので、改めてここで手順を説明するほどでもないんだけど、注意点が2つあるんだ。

一つはリージョンを間違えないこと、そしてもう一つは実行用の IAM ユーザを用意する必要があること。

ユーザ……?
Former2 を使うには、ReadOnlyAccess という権限を持った IAM ユーザが必要なんだ。
既存のユーザを使うのはダメなの?
アクセスキーとシークレットアクセスキーを委ねてしまうし、不運に不幸が重ならないとも限らないので、使い捨ての IAM ユーザを用意した方がいいね。

スタックを削除すると、作成したリソースも道連れになる

CloudFormation を使ってリソースを作成するには、最初にスタックというものを作る必要があるんだ。
スタックは、リソースを作り終えたあとは消していいの?

それを消すと、リソースも一緒に消えるよ。

もし、スタックを消してもリソースを残したい場合は、設定ファイルのリソースのところに DeletionPolicy 属性を明示的に設定しないとダメだよ。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  myS3Bucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
まぁ、せっかく CloudFormation の管理下にあるリソースを、管理から外してしまうのはどうなんだろ。

設定ファイルにはインスタンス ID とかがベタで書かれていたりするので、いまいち長持ちしない気がするけどね。

もともと手作りしたリソースだったら、DeletionPolicy 属性を Retain にして、スタックは消しておいた方が地球に優しいと思う。

今日のまとめ

既存のリソースをエクスポートしたいときは Former2 を使おう。

マネジメントコンソールで同じ設定作業を何度も繰り返しているなーと思ったら、自動化を検討した方がいいね。

マネジメントコンソールの手順書を作って、「この設定を100箇所に適用して」と人にお願いするくらいなら、テンプレート化して自動生成して機械にやらせる方がみんな幸せになりそう。

単純な定型作業はできるだけ自動化して、僕たちは開発に集中したいよね。

それでは今日はこの辺で。

ではでは。

生存報告とかAWSとか

たーせるくん!

たーせるくん!!

はい。
よかった…… 生きてた。

ごめんよう。

連休明けから何故かくっそ忙しくてブログを更新する暇がなかったんだ。

ところで、AWS のお勉強の方は……?
Udemyユーデミー のオンライン講座をひととおり終えて、今はお仕事で AWS を使うようになりました。

仕事で!?

いきなり!?

VPC を作ったり、EC2 を立てたり、CloudWatch を設定したり…… まだ初歩っぽいけど、ハンズオンで学んだ内容が、割とそのまま実務に活かせているよ。

前回宣言した資格の方も、そろそろ受験日を決めて合格を獲りに行こうと目論んでいる。

すごいね! たった1ヵ月ちょいでもそこそこできるようになるものなんだね。

会社からも、好きに使っていい IAM アカウントを払い出して貰ったので、遠慮せずに実験しているよー。

毎日が新兵訓練みたいな感じだね。

なるほどなるほど。

本当はインフラよりも開発がやりたい

最近、インフラ案件っぽい対応が中心になってきて、コードを書く頻度が減っているのでは?

そうだねー。

個人的には、アプリケーション開発とかをやる方がぶっちゃけ好きだし、楽しいと僕は思う。

ふむ。

ただ、AWS を知ることで、コーディングだけでなく、環境構築からデプロイまでの一連の開発作業がラクになる気がする。

逆説的だけど、PaaS や IaaS の活用でインフラ作業の比重が減れば、開発に集中できるようになると思うんだ。

なるほど。

とりあえず直近の目標は資格を取ることだから、それに向けて頑張るよー。

で、基礎を身に付けたら、Lambda と API Gateway で何か作ってみたいなぁ。

がんばがんば。

ごめん、今日はあまり中身のある話ができなかったね……。

また諸々落ち着いたら、更新頻度を戻していこうと思いますー。

ではでは。

AWS ソリューションアーキテクトに挑戦します

たーせるくん大変です!

UdemyユーデミーAWS ソリューションアーキテクト アソシエイト 試験突破講座が、今だけ 87% OFF になっています!

えっ、、えっ、、、

もともと ¥12,000 の講座が、なんと¥1,560 になってます!

今日までです!! 早く申し込まないと!!!

え、、ちょっと待って、、

実は4月からアーキ屋になりました

言いそびれましたが、たーせるくんは4月から新しい部署に異動になり、役割もプログラマからアーキテクトに変わりました。

はい。

これまでとは求められるスキルセットも変わるので、新天地で活躍していくためには、お勉強が必要です。

まぁ、、そうですね。

どのみちコロナの緊急事態宣言で、せっかくの大型連休中も外出自粛は続くので、今は絶好のお勉強日和びより

たしかに。

AWS は昔ほんのちょっとだけ触ったことがあるレベル

AWS は、もともと知っているんだっけ?

いや、ずぶの素人しろうとレベル。

ほんのちょっとだけ、個人的な趣味の Web アプリを AWS で動かしたことがある程度。

じゃあ、ますます危ないね。

ひとまえでボロが出る前にしゅうしなきゃ。

よし、、 受けるよ!

がんばがんば。

AWS ソリューションアーキテクト アソシエイト受けます

何年ぶりかは忘れましたが、超久々の資格取得企画始動です。

楽観目標を 6月合格、悲観目標を 9月合格に定め、遅くとも 2020年度かみ中の合格を目指して学習計画を立てます。

学習の進捗状況は、不定期でこのブログに公開していこうと思います。

そうそう、Twitter のフォロワーさんから宣戦布告が来てますよ!

……負けない!!

Python で数学と仲直り! これなら分かる最小二乗法と直線の当てはめ問題

どうしたの? なんかふるえてるけど。

いや…… ある日 LINE で遊んでいたら、相手の隠していた爪が露わになって戦慄しているのです。

高校最初のテストで世界トップクラスの成績……。


f:id:tercel_s:20200229200808j:plain:w350

……なんか、定期的にガチぜいに出会うよね。

文系だろうが理系だろうが 100点は 100点だし世界の頂点だし神

おわかりいただけただろうか。

なんでキミがそんなに偉そうなんだよ!

まぁでも、たーせるくんもつねづね数学と仲直りしたがっているみたいだし、今日は軽く数学のお話でもしようか。

わーい。

数式だけだと退屈だから、後半ちょっとプログラミングもやろう。


続きを読む

はじめからはじめる @ngrx/data 第4話(たぶん完結編)

NgRx にビビってたみんなゴメン。

もう難所はだいたい抜けました。

麻酔の注射が痛いだけであとは大したことないパターンでしたね。

どうした? 手術でも受けたの?

前回の話
tercel-tech.hatenablog.com

今日はいよいよフロントエンドを構築して、これまで作ってきたすべてを繋ぐよ。

今まで地味だったからね。

結局、バックエンドをいくら作り込んでも、実際にフロントから動かせるようにならないといまいち面白くないよね。

今回はコンポーネント周りの実装がメインなんだけど、いかんせん HTML と TypeScript のしんこっちょうな部分なだけあって、書くコード量は今までで一番多いと思う。

たしかにビューまわりは SPA フレームワークの最も得意とするところだね。

今回は、削除・追加・更新処理で章を分けていて、それぞれ各章の冒頭に完成イメージの GIF アニメを載せているよ。

無味乾燥な仕様書をそのまま載せるよりビジュアル的だし、これから何をしようとしているか予め分かった方が不安にならずに済むかと思って。

はじめからそうしてくれていればよかったのに。

続きを読む

はじめからはじめる @ngrx/data 第3話(Angular In Memory Web API 設定編)

@ngrx/data の連載も 3 回目を迎えました。

前回は、エンティティの CRUD 操作に必要な NgRx まわりのコーディングを終えたのですが(実質10行)、肝心の DB 環境がないというところで終わってしまっていました。

今回は簡単のため、Web API と DB をエミュレートする Angular In Memory Web API を使って、続きをすすめていきたいと思います。

前回の話
tercel-tech.hatenablog.com

Angular In Memory Web API とは

山田よしひろ著『Angular アプリケーションプログラミング』によると、DB や API 用にサーバを用意できない開発の初期段階で使えるお手軽な API エミュレータだよ。

(略) Angular では、Web API をエミュレートするためのライブラリ (angular-in-memory-web-api) を提供しています。 これを使うと、Http / Json サービス[原文ママ]が利用するバックエンドを置き換え、(ネットワーク上のデータではなく)メモリ上のデータを読み書きするようになります。 本来の Web API に代わって擬似データを返す、テストダブルの一種と言っても良いでしょう。

f:id:tercel_s:20200215125243j:plain:w400
Angular In Memory Web API の仕組み

外部環境に依存せずに Web API が試せるのはいいね。

そうだね。

たとえばチュートリアルに出てくる DBMS が自分のよく知らないやつだったりすると、認知負荷が上がってやる気なくすでしょ。

確かに。。。

続きを読む

Copyright (c) 2012 @tercel_s, @iTercel, @pi_cro_s.