読者です 読者をやめる 読者になる 読者になる

日本の高校数学の四分位数の求め方はRの9種類のどれとも違う

こんな驚きのツイートを見かけました。

まず、Rに9種類も四分位数が実装されているのがびっくりですよね。

?quantilesで調べてみると、

type

an integer between 1 and 9 selecting one of the nine quantile algorithms detailed below to be used.

と書いてあります。9種類もあるのは本当だった!

英語のWikipediaのQuantileをみるとわかりやすく9種類を解説してありました。ちなみに、たまたま気になってR-2の式を確認したのだけど、ちょっと間違えていると思います。

もっと丁寧に書いてあるのがQuartiles_in_R.pdfです。9種類のtypeに違いが出る場合を4種類のデータで示しています。下の画像は、data12の表で、data11、data10、data9もあります。

f:id:Akiyah:20170420092903p:plain

 

さて、本題です。日本の高校数学の四分位数は、これらとは違うのでしょうか。高校の教科書は持っていないのですが、ベネッセの解説を見つけました。

kou.benesse.co.jp

データを小さい方から順に並べたとき,中央値に相当するのが「第2四分位数」であり,

下位(中央値より小さい方)のデータの中央値が「第1四分位数」
上位(中央値より大きい方)のデータの中央値が「第3四分位数」

となります。

と書いてあります。なるほど、定義としてはわかりやすいですね。でもRのquantileとは定義は違いますね。quantileはn分位数が出せるけど、この高校定義だとn=4の四分位数に限定されています。

さて、定義は違うけど、計算結果はRの9種類のどれとも違うのでしょうか。確認するために、Quartiles_in_R.pdfで使っているdata12, data11, data10, data9で計算してみました。 

DATA Q1 MEDIAN Q3
data12 <- c(2,3,5,7,11,13,17,19,23,29,31,37) 6 15 26
data11 <- c(2,3,5,7,11,13,17,19,23,29,31) 5 13 23
data10 <- c(2,3,5,7,11,13,17,19,23,29) 5 12 19
data9 <- c(2,3,5,7,11,13,17,19,23) 4 11 18

Quartiles_in_R.pdfと見比べてみると、確かに全部一致するものはないですね。type=2に一番近いですがdata9の時にtype=2は5,11,17ですのでちょっと違います。というわけで最初のツイートは正しいことが確認できました。

Rは9種類も四分位数の定義があるのに、なんで日本の高校はさらに新しい定義を作るのだろう、と最初は思ったのですが、ここまで計算してみるとちょっと考えが変わってきました。Rは9種類の四分位数(quantile)を実装しているけど、四分位数じゃなくてn分位数に対応しているために定義は少しややこしくなっています。一方、日本の高校の定義は、「中央値より下の中央値」「中央値より上の中央値」という感じで、わかりやすいんですよね。n=4の四分位数に限定の定義ですが、確かに教科書に載せるにはこっちの方が適切なのかも。と思いました。

 

実践のための基礎統計学 (KS理工学専門書)

実践のための基礎統計学 (KS理工学専門書)

 

ちなみに、今読んでいるこの本の四分位数は、定義の形はちょっと違うけど、Rのquantileのtype=7(default)と同じ値になるようでした。よかった。

AgileJapan2017でモブプログラミングに飛び入り参加しました。

AgileJapan2017でモブプログラミングに飛び入り参加しました(飛び入りというか、後ろで見てようかなと思ったら座らされちゃった)。参加者は、7人くらい。

お題というか言語はelmというもので、参加者全員が知らない言語でした。みんなで調べながら動くものを作るという場を作るためにそういうマイナー言語を選んだみたいです。

まずJoshが紹介してくれたのがモブプログラミング用のタイマー、モブスターです。

github.com

指定した時間が来たらディスプレイを黒くして、次のドライバーを教えてくれます。

f:id:Akiyah:20170414172004p:plain

elmは、初めてだったけどどうやら関数型言語で、HTMLを作るのに便利だそうです。オンラインの実行環境があったのでここでモブプログラミングしました。

f:id:Akiyah:20170414172404p:plain

最初にハローワールド書いて(これはサンプルを実行しただけ)、assertメソッド書いて単体テストできるようにして、ローマ数字の足し算のお題を解き始めました(I、II、III、IVのみ出てくる演算に関してはできた)。

まあ、わけわからないですよ、初めての言語だし。でもみんなで知恵を出し合って、なんとかそこまでできたのでした。パチパチ。

モブプログラミングのコツ(教えてもらったこと、私の思ったこと)
  • 周りのナビゲーターが次にやることを指示して、ドライバーは手を動かすだけにする
  • モブスターを使ってドライバーを(10分とか)定期的に交代する
  • 周りのナビゲーターはみんなに聞こえるように大きな声で指示する
  • そこ、その行、と言ってもわからないので、行番号を数字で指摘すると良い
感想

やってみて、elmのような初見の言語や技術をみんなで学ぶ場としてモブプログラミングをするのはすごく良いなと思いました。デバッグとか、設計の方針の共有とかもそうだと思います。

あと、今までも同僚とやっていたみんなでディスプレイを見ながらプログラミングするという状態は、だいたいのところモブプログラミングだなと思いました。今までやっていたよと。ただ上に書いたようなコツを使った方がより効果的なんだなとも思いました。

モブプログラミングは普通の開発でも使うものなのですかね。そこらへんが不明でした。ずっとモブプログラミングでも良さそうでもあるし、週に1日というような運用でもありそうだし。そのあたり、詳しい人に聞いてみたいです。

AgileJapan2017 【基調講演】 “モダンアジャイル”

AgileJapanに参加して、おめあての基調講演のモダンアジャイルを聞きました。

www.agilejapan.org

最近はアジャイルバズワードっぽくてアジャイルの話をするとずれていることが多くて困っていたし、アジャイルソフトウェア開発宣言も「いままでのウォーターフォールとはちがう!」というアンチテーゼっぽさが気になっていたのでした。なのでモダンアジャイルというアイデアを聞いた時から期待していました。とくに心理的安全を聞きたかったのです。

で、聞いてみると、ソフトウェアに限っていたアジャイルソフトウェア開発宣言をソフトウェアに限らない領域に広げて、ユーザーのAWSOME!(すごい!)をいかに作るかを目指すのがモダンアジャイルなのかなと思いました。わかりやすい差分をまとめてみると、

  • アジャイル → モダンアジャイル
  • ソフトウェア開発 → 何らかのサービス
  • いかに作り上げるか(DONE) → いかにすごいか(AWSOME)

という感じかなと。だいぶリーンスタートアップに近い印象を受けました。モダンアジャイルの4項目

  • 人々を最高に輝かせる
  • 安全を必須条件にする
  • 高速に実験&学習する
  • 継続的に価値を届ける

のうち、下の二つはリーンスタートアップぽいですよね。一方で、上の二つの、「関係する人々」や「安全」に注目しているのが今までのアジャイルの流れを汲み取っていますね。

 

Joshuaのプレゼンテーションは印象的な例が多くてとても面白かったです。そのうち一つを紹介しますね。

Joshuaには娘さんがいて、子供達は水風船の投げ合いで遊んでいるのだそうです。水風船バトルでは、水風船を準備するのが大変なんですよね。そこで、その娘さんにパパ(Joshua)が水風船をいっきに作れる商品をプレゼントしたのだそうです。

www.gizmodo.jp

「パパ最高!(AWESOME!)」

となるわけですね。これですね。この商品はまさに「パパ最高!」を作るものなんですよね(gizmodeの紹介もそうなっていますね〜)。ちなみに、これ、うちでは去年買いましたよ。AWESOME済みです。

 

講演を聞いている人に、モダンアジャイルステッカーがプレゼントされました。

 

そういえば以前こんなエントリーを書いていたことを思い出しました。

akiyah.hatenablog.com

心理的安全は、2017年度の流行語の予感。今回の講演でも心理的安全についてもおしえてもらいましたが、また別のエントリーで。

Docker内でbundle exec rspecがやけに遅かったけどなおった件

Docker Compose使ってRailsのプロジェクトをしています。

ある時から突然bundle exec rspecが遅くなってしまって、テスト自体は10秒程度なのにコマンドとしては2分くらい待たされるという現象になってしまいました。rspecに限らずbundle execが何やっても遅いという状態でした。

それもプロジェクトの一人が最初にその現象に当たって、数日後に私もなって、また数日後にもう一人が同様になって、という、感染しているんじゃないかという不思議な現象でした。でも、その3人目の人が解決策を見つけてくれました。

rails.hatenadiary.jp

細かいところは違いますが、Docker側とホスト側(Mac)の共有フォルダにvender/bundleがあるとこうなるようです。上記の3人目の感染者はグローバルにインストールしたらなおったと教えてくれました。

でも2番目の感染者である私はグローバルインストールを避けたかったので、ちょっと違う方法を考えました。docker-compose.ymlのvolumesで指定した共有フォルダにrailsプロジェクトを入れているのですが、gem置き場をたとえばvender/bundleというように指定すると結局共有フォルダ内に置くことになってしまうので、bundle installする時に--path=~/project1/vender/bundleとしてみました。そうするとDocker側とホスト側で~/project1/vender/bundleがgem置き場として指定されるけど、実態は共有フォルダじゃない別々のところに管理されます。

グローバルインストールじゃないし、遅い件もなおったしで、ひとまず満足です。

ちなみに、なぜ最初から遅いわけじゃなくて、一人ずつ感染が広がっていったのかは、不明なままです。。。

U-NEXTでアンパンマンの第1043話近辺をみて顔汚れの割合を調べてみた

1歳の娘が夜寝ない時など、U-NEXTアンパンマンをよく見ています。
U-NEXTにはアンパンマンチャンネルというのがあって、過去のTVシリーズの15話を1ヶ月毎に入れ替えているようです。
ふと、アンパンマンの顔汚れの割合が知りたくなって、集計してみました。

話数 タイトル 顔汚れ アンパンチ
第1043話-B ドリアン王女とポッポちゃん
第1059話-B クリームパンダとマグぼうや ×
第1062話-B ばいきんしらたき姫とスキヤキの里
第1068話-B SLマンとオーロラ姫
第1069話 カカオくんと化石の魔王
第1070話-B アンモナイトくんとジャングルの塔 ×
第1071話 コキンちゃんのひなまつり ×
第1072話-A 氷の女王とふきのとうくん ×
第1072話-B カレーパンマンとマダム・ナン × ×
第1085話-A しょくぱんまんとパジャマン × ×
第1085話-B やきそばパンマンとアリンコキッド ×
第1086話 クリームパンダとなまいきナマコ
第1127話 アンパンマンと宇宙のブリキッド ×
第1132話 黒バラ女王とビクビクちゃん
第1170話 ドキンちゃんとたまごひめ ×

ちなみに、テレビの最新版は2017/03/19時点で第1349話だそうで、第1043話は2010/7/23のようです。

意外というか、顔汚れは15話中6話だけで、40%ですね。毎回汚れているイメージだったので、もっと多いと思っていました。この15話の選択はランダムとは言えないですが、ランダムだと仮定すると、n=15, p=0.4で二項分布の標準偏差σ= √(p*(1-p)/n)=0.13で、95%信頼区間は0.4±2*0.13=14%〜66%というところでしょうか。広すぎてなんとも言えないですね。もうちょっとデータを集めなければ。

ちなみに、アンパンチしないで終るときもあるんですよ。この15話の中では2話がそうですね。だいたい特殊なキャラがばいきんまんの行動を封印してアンパンマンが手を下す前にバイバイしています。今回の調査の中では『第1072話-B カレーパンマンとマダム・ナン』のマダム・ナンに注目です。

なぜかばいきんまんを尊敬しているマダム・ナンがばいきんまんほめ殺しにして、バツが悪くなったばいきんまんはすごすごと退散します。

f:id:Akiyah:20170319212932p:plain
f:id:Akiyah:20170319212928p:plain

バツの悪いばいきんまんの顔、そして状況が飲み込めない人々の顔が必見です。

今回の調査では、アンパンマンの顔が汚れて取り替えて元気100倍になったアンパンマンが、アンパンチをしないというパターンは見つかりませんでした。私の記憶にもないので、あったらかなりのレア回だと思います。1000回以上もやっているアンパンマンなので存在するかもしれません。情報あったら教えてください。

生放送中に子供が乱入をベイズ統計学の面積図にしてみた

www.youtube.com

この動画は奥さんと見て楽しませていただきました!

 

www.huffingtonpost.jp

その動画に出てくるお母さんをベビーシッターと勘違いした人がいるようです。まあ、だれでも勘違いはするものなのでそれはそれとして、ベイズ統計学の面積図の題材にちょうどいいと思ったので試してみます。

この記事に出てくる情報として、白人が白人意外と結婚する割合は7%だそうです。また、アメリカの白人率は72.4%だそうです。ベビーシッターを雇っている割合はわからなかったのですが、ここでは必ずベビーシッターさんがいて、奥さんとベビーシッターの人数比は1:1であるとしておきます。(ここに書いた数字は条件次第で全然違ってくるかもしれませんが、こういう設定であるということにして進んでしまいます。)

 

f:id:Akiyah:20170318231133p:plain

すると、白人男性の家にいる女性が『白人ではなかった』場合、奥さんである割合は約20%で、ベビーシッターである割合は約80%ですね。数値は適当ですが、まあ、人々の思っている先入観としてはこんなものなのかもしれません。

参考にしたのは下の本です。上に書いたような面積図でベイズ統計学を説明してくれてわかりやすいです。

完全独習 ベイズ統計学入門

完全独習 ベイズ統計学入門

 

 

 

サムネイル画像を見に行ったらその画像がなかった

この前見た記事がこれです。

dentsu-ho.com

はてなブログで表示するとちっちゃいグラフが見えますね。twitterだとこんな風に見えます。

f:id:Akiyah:20170225023718p:plain

このサムネイルのグラフを見て、統計でウソをつく法の怪しいグラフみたいだからチェックしようかなと思って。

で、クリックして表示してみたら、このグラフがないんですよ。

f:id:Akiyah:20170225023353p:plain

たぶん途中にある表をグラフにしたら同じものになるのでしょうけど、でも、無い、と。せっかく作ったのにサムネイルだけに使って本文には載せないものなのでしょうかね。(電通のようなプロだからこその作戦なのでしょうか)

サムネイルで気を引いたのだから、その画像は見せてほしいと思います!!

 

ちなみに、このエントリーのサムネイル画像は【私たち、無料です。】フリー素材アイドル MIKA☆RIKAからいただきました。あえて記事には載せていません。