プチコン3の標準 BG とスプライトの一覧を作ってみた #petitcom

3DS でゲームが作れる プチコン3号。結構本格的なゲームも作れるくらい性能も自由度も十分ありつつ、ちょっとしたゲームをひょいと作れる手軽さもあって、久しぶりに1画面プログラムなゲームとかちまちま作って楽しんでたりする。
でも、いわゆるベーマガ世代をターゲッティングしすぎていて、プチコンで初めてのプログラミング、みたいなことは厳しめ。確かにあの頃の放り出し感は忠実に再現出来ているが、今のお子様はチュートリアルのあるゲームに慣れているわけで。
せめて入門本があったら良かったのだけど。2月に書籍が出るっぽいが、「公式ガイドブック」という名称には正直あまり期待感がそそられない……。ターゲットのおっちゃん層にはハマるんだろう。


プチコンはスプライトや BG の絵のパーツ、効果音、BGM などを全部自分で作ることもできるが、デフォルトでけっこういっぱい登録されてもいるので、絵心を発揮しなくても手軽にゲームを作ることができる。が、標準のツールは残念ながら使い勝手があまり良くなく、「どのキャラクタにしよっかな〜♪」という楽しいはずの気分がたちまち曇る。
やりたいことは単純に「全部のキャラクタを見て、定義番号が知りたい」だけのことなんだけど、3DS の画面は狭くてデフォルト BG やスプライトを全部表示することができない。まあ、そんだけ十分多くの絵のバリエーションが用意されているという意味では朗報だけどね。


というわけで、デフォルトの BG とスプライト画像の一覧を作ってみた。ただスプライトは 16x16 より大きいものは縮小しており見にくい。このへんはどうすればコンパクトに見やすくできるか考え中。
キャラクタの定義番号は縦横を足した16進数の数字になる。例えばスプライトで方位磁石は &H63(10進数で 99) である。
横は 32個並んでいるので、右半分はさらに &H10(10進数で16) 足す必要がある。例えばスプライトでサイコロの1は &H119 となる。作っちゃったあとで失敗したーと思ったが、これ作りなおすの結構面倒なのでパス。


こいつを PC の大きい画面で見ると、「ああ、あんなゲームができそう……こんなゲームも作ってみたい……」とうっとりしてしまうこと請け合いである。*1
つか、これくらいスマイルブームさんが作って公式で公開してくれればいいのにね!

プチコン標準BG

プチコン標準スプライト

*1:かつて電脳倶楽部というディスク雑誌ではだれでも利用可能なゲーム素材を募集・配布しており、それを使ったゲーム作りの記事を書かせてもらったなあ。「冷蔵庫の中を見て作る料理を決める楽しさ」とかなんとか言って

プチコンで 3DS のゲームを作ろう #petitcom

3DS になんか見たことないゲームあるけど、おっちゃんこれなに?」

「これはゲームやない。プチコン3号や。プログラミングってわかるか?」
「学校で『スクラッチ』ってのちょっとだけやったことあるよ。自分で 3DS のゲームが作れるってこと?」
「 Scratch(スクラッチ) 知っとるんやったら話早いわ。そうや、好きなゲーム作れんで。性能も機能もそこそこちゃんとしてるし、Scratch よりゲームっぽいゲーム作れるわ。ちょこっとめっちゃいっぱいがんばったら」
「めっちゃいっぱい……じゃあなんかゲーム作って、おっちゃん」
「あほう! 『自分で作れる』って自分で言うたやろ。遊びたかったら自分で作るんや!」
「えー。教えてくれるんだったらがんばってみる」
「その意気や。ほれ、やってみ」
プチコン始めるっと。メニューみたいの出てきたけど」

「『Smile BASIC(スマイルベーシック)でプログラムを作る』やな」
「『作品を見る』とか『作品公開とダウンロード』とか、これってもしかして自分で作らなくても……」
「はよ『作る』押せや」
「おっちゃんこわい(涙目)。うわー黒い画面とボタンいっぱい出たーむりー」


「これは古き良き BASIC の起動画面やな。ベーマガ世代なら懐かしいて涙ちょちょぎれるとこやけど、子供らはそんなん知らんのやから、もうちょい今風にしてもええと思うねんけどなあ。言語仕様もなにかと……」
「おっちゃん、誰に向かって話してるの? ここからどうやってゲーム作るの?」
「お、おう。どんなゲームが作りたいんや?」
「うーん。ポケモンとか妖怪ウォッチみたいなやつ?」
「フィールドタイプの RPG か。いきなしハードル高いなあ。ま、ええか。何事も経験や。下画面の真ん中の下にある "SMILE"(スマイル) っての押してみ」
「このニコニコマーク? はい。なにこれ?」


「スマイルツールっつってゲームの音や絵を用意したり作ったりするツールやねんけど、『いちげんさんお断り』感ありありやわなあ。まあグチっててもしゃーないから、今は下の "SPDEF" ってやつ押したって」

「ちっちゃい絵がいっぱい出た。イチゴ? ミカン? サクランボ? あ、もしかしてキャラクタどれにするか選べるの?」
「そうや。これはスプライトや。自分で好きな絵ぇ描くこともできるけど、今回はもうあるやつから主人公を選ぼうか」
「スプライトってスクラッチにもあったよ! ゲームのキャラクタだね。でもサクランボで RPG 作れるかなあ……」
「それもシュールでおもろそうやけど、十字キーで下へ行ったら他にもいろいろあるで」
「探しにくい」
「言うたんな……」
「あ! これ! これにする」

「お姫さんが主人公か。そういう RPG 無いわけやないけど、珍しめやな」
「どうやって選ぶの? OK ボタンとかないけど」
「甘ったれんな。そのキャラクタの上に書いたある数字覚えて、プログラムの中にその数字を書くんや」
「マジ?」
「まじまじ。はい、数字写したったから」

姫
596,597,598,599	右
600,601,602,603 下(正面)
604,605,606,607 左
608,609,610,611	上
612,613 右(伏せ)
614,615 左(伏せ)

「なんかめんどくさい……」
「次はお姫さんを表示するプログラムを書こうか。まず右の "EXIT"(イグジット) か X ボタンを押してツール終了や。またキーボードの画面に戻るから、今度は左下の "EDIT"(エディット)っての押してみ」
「押したけど……なんか変わった?」
「上の画面にプログラムを作るモードに変わったんや。下画面のキーボードを押したら、上画面に文字出てくるから、とりあえず今はこの通りプログラム書いてみ。行の終わりは右下の ENTER(エンター) 押すねんで 」

ACLS
SPSET 0,600
SPOFS 0,200,120

「全然わかんない」
「後で説明したるし。でけたか? そしたら START(スタート) ボタンを押して、初のプチコンプログラム実行や」
「START っと……。あ! 真ん中にちっちゃいお姫様が出た!」

「出たやろ? じゃあプログラムの説明すんで。プログラムっつうのは……」
「ねえねえ、十字でもスライドパッドでもお姫様動かないんだけど。バグ?」
「動かすプログラム書いてないねんから動くかいな。なんで『バグ』とかそんな言葉だけ知ってるねん」
『都会(まち)トム』で言ってたから」
「なんやそれ? ゲーム作る小説? まあええか。説明すんで。プログラムっつうのはコンピュータに渡す命令を並べたもんや。3DS もコンピュータの一種やからな。コンピュータはプログラムの順番通りに命令を実行するんや」
「ふーん。じゃあさっきのプログラムは『お姫様を表示して』っていうプログラムだったんだ。でも『お姫様を表示して』って命令にはなんとなく見えないけど……。3行ってことは命令3つ? お姫様表示するだけにそんなにいるの?」
「お姫さん表示する専用の命令みたいんまであったら、命令の数どんだけいるねん。お約束の多い今どきのプログラムからしたら3行でも短い方やで。表示する前の準備とかもあるんやし」
「プログラムってめんどくさいね……」
「ほんなら1行ずつ見ていこか。1行目の ACLS は画面をきれいにする命令や。見えてる画面はもちろん、見えてへんところにも画面がいっぱいあったりするんや。プログラムを走らしたり終わらしたりしても、全部の画面を勝手にはきれいにしてくれへん。誰か別のプログラムがお姫さんの絵を書き換えとったら、全然違う絵になってバグなんか何なんかわからんハメになったりする。ACLS はそれを全部きれいさっぱり一番最初の状態に戻してくれるんや。とりあえずプログラムの最初には ACLS って書いとくもんやと思っといたらええ」
「エーシーエルエス……そんな読めない命令覚えられない……」
「そこらへんはしゃーないなあ。一応、オール・クリヤー・スクリーン(All CLear Screen) で ACLS やねんけど……そんなん言われても、みたいな顔せんでええから。要るもんはがんばって覚えるしかないけど、せいぜい数十いうところやからなんとかなる。そん中でもよう使う命令はさらに限られとるし。ほんまもんの英語やと何万語も覚えんならんこと考えたら余裕やで」
「……はーい」
プチコン3号のエディタは途中まで入力したらキーボードの上に命令の候補が出るんで、うろ覚えでもまあまあなんとかなるし。まあ実際にプログラミングしてみたら案外大丈夫なもんやで」

「プログラムの説明に戻んで。2行目と3行目は『スプライト』の命令や。SP で始まる命令はほぼ全部スプライトをどうこうするためのもんと思っといてええ」
「『スプライト』って、スクラッチでもあったよ。ゲームのキャラクタでしょ」
「そや。大ざっぱに言うたら、『スプライト』は絵があるキャラクタをうまいこと動かす仕組みや。敵とか味方とか弾とか魔法とか爆発とか、ゲームの中で動くものはだいたいスプライトとして作るんは Scratch(スクラッチ) でもプチコンでも全く一緒やな」
「じゃあさっきのプログラムはお姫様スプライトに書いてあったんだね」
「ん? あーちゃうちゃう。そこは Scratch とプチコンの決定的にちゃうとこやな。Scratch は基本的にスプライトにスクリプトを書く、つまりゲームのキャラクタそれぞれがプログラム持っとって、それぞれ勝手に動くっちゅう今どきのスタイルやねん。けど、プチコンは1個のプログラムが全部のスプライトを動かすっていう古いスタイルやねん」
「そう言われれば、スクラッチは猫のスプライトに『10歩動かす』って書いたら猫が動いて、犬に『90度回す』って書いたら犬が回るんだった。んー、でもプチコンはプログラム1個しかないんだったら、お姫様に『動け!』って言ったのに王様が動いちゃったりしない?」
「そこはスプライトに番号つけて区別するんや。番号は 0 から 511 までで好きに決めてええねんけど、まあ小さい方から使うといたらええ。今のプログラムではお姫さんは 0 番になってる。2行目の SPSET 0,600 は、0 番のスプライトに 600番の絵を SET(セット)するって命令や。さっきメモしたお姫さんの正面向いてる絵が 600 やったやろ?」
「じゃあ 600 を他の数字にしたら絵が変わるってことだね。じゃあ……プログラム書くには EDIT(エディット) だったっけ……で、600 を 123 に変えてみて、START(スタート) を押したら……わぁ、ピコピコハンマーになったー」
「3行目の SPOFS 0,200,120 は、0 番のスプライトを画面の左上から数えて右に 200、下に 120 行ったところに動かせって命令や。画面は横 400、縦 240 の大きさやから、これで画面のちょうど真ん中あたりにお姫さんが表示されるって寸法や」
「じゃあ 0番はお姫様で、1番は王様で、みたいに最初に決めとかないといけないんだ。忘れそう……」
「スプライトの番号割り振ったら、さっきお姫さんのキャラクタの数字メモったみたいに紙に控えとくんや。人間すぐ忘れるからな」
「プログラムって大変だね……。いちいちお姫様を 0 番とかしないで、600 番のお姫様を真ん中に表示、ってできないの? それなら命令1個でお姫様表示できそうだけど」
「お姫さんが1人しかおらんかったらそれでもええかもしれんけど、同じお姫さんが2人3人いたら困るやん。全部 600 番なって区別つかへん」
「お姫様が2人ってお姉ちゃんと妹とか、ほかの国のお姫様とか? そういうときは色とか変わるでしょ。ピーチとデイジーみたいに*1
「えーとじゃあ村人A、村人B、村人Cとか?」
「あー、おんなじ顔でおんなじ服で。それならいそう。シューティングゲームでおんなじ敵がいっぱい出てくるのとかもだね」
「あとお姫さんもいつも 600番の絵やのうて、右向いたら別の絵に変わるわけや。キャラクタとしてはおんなじお姫さんでもな。そこらへんも考えたら、キャラクタごとに『スプライトの番号』があって、SPSET でその番号がどんな絵になるかを決めるんが賢いんや」
「そして SPOFS は 0番のスプライトを真ん中に表示するんだね」
「ちょい違う。『左上から数えて右 200、下 120 に動かす』や。試しにこの3行目だけ削ってみ」
「あ。お姫様が一番左上に表示された。そっか、SPOFS がキャラクタを表示するんじゃなくて、SPSET のときにもう表示されてて、 SPOFS は移動なんだ。それなら名前を SPMOVE にしてくれればいいのに」
「OFS は OFFSET(オフセット) の略で、基準の位置からどれくらいずれてるかって意味やねん。MOVE(ムーブ)、つまり移動だと、今いる場所からの移動みたいに解釈できてまうんがイヤやったんちゃうか」
「SPOFS はスクラッチの『10歩動かす』じゃなくて『 x座標を 200にする』の方ってことかあ」
「おう、そうやそうや。プチコンでも画面上の左右の位置は x 座標、上下の位置は y 座標っていうんで、Scratch といっしょやな」
「右 200、下 120……つまり x 座標が 200 で y 座標が 120 は真ん中あたりってのはどうやってわかるの?」
3DS の上画面は横 400、縦 240 の大きさやねん」
「真ん中ならその半分の 200, 120 にすればいいんだね。じゃあ SPOFS 0,400,240 ってすれば右下に……あれー何にも表示されない」
「スプライトの左上を 400,240 に持っていってるから画面の外に行ってしまうんや」
「えーとどういうこと? ……ああ、ちょうどスプライトの大きさの分戻してあげればいいのか。ってスプライトって大きさどれくらい?」
プチコン3号のスプライトは大きさ変えれるから、ものによってちゃうけど、だいたいは縦横 16 や。お姫さんもな」
「それじゃあ 400 と 240 から 16 引いて…… SPOFS 0,384,224 ってすれば……右下に出た! なんとなく好きな場所に表示できそうにはなったけど、全然ゲームじゃないよ? スライドパッドでお姫様動かしたいんだけど」
「スライドパッドは STICK(スティック) って命令を使うんや」
「また新しい命令かー。さっきの SPSET とか SPOFS とかといっしょで、1番目の数字がナニナニで、2番目がコレコレみたいなことがまたあるんでしょ。そんなのいちいち覚えてられるかなあ」
「大丈夫。STICK って打って、キーボードの右上の『?』押してみ」

「なんか説明出てきた。ふーん、こうやって命令の説明見れるんだ。へー」
「スライドパッドで下にずらしてったら、使い方の例も出てるし、まあ完璧とは言わんけど、そこそこなんとかなるで」
「その説明がよくわからないんだけど……。"STICK [端末ID] OUT X,Y" ってどういう事?」
「『引数』のとこに説明あるやつは、好きな値とか変数とか式とか置き換えれるやつや。これやと『端末ID』と『X』と『Y』やな。[ と ] で囲まれとるんは省略できるいう印や」
「省略できるって言われても、省略した時としなかった時でどう違うのかわかんないよ」
「親切やと省略したらどうなるんか書いたあるんやけどな……。『ワイヤレス通信で他の端末の情報を取得する際に指定』か。つまり、指定せんで省略したら自分の本体のスライドパッドのんが取れるっちゅうこっちゃ。わかるやろ?」
「わ・か・り・ま・せ・ん」
「そやろうなあ。わかるやつしかわからんのんは説明としてはビミョウわなあ」
「わかんないけど、端末IDってのは省略しちゃっていいってこと?」
「まあ今はそうや」
「OUTは引数のところに無いんだけど」
「そういうんは命令の一部やからそのまま OUT(アウト) って書くんや。最初っから STICK OUT って命令やと思うといたらええわ」
「 X, Y は『変化量を受け取る変数』……変数ってスクラッチにもあった気がする。数字を入れて持っておける箱だよね。スクラッチだと変数のパーツを置いたら使えたけど、プチコンは?」
「初めて変数使うたときに勝手に用意されるんやが、それやと逆にわかりづらいやろうから、VAR(バー) って命令で箱を用意するもんやって覚えとく方がええかもな。X と Y って変数使いたいなら VAR X, Y ってどっか最初の方に書いといたらええ」
「じゃあ、お姫様の表示位置が 200 と 120 になっていたのを変数 X と Y にして、STICK OUT の受け取る変数にそれを使ったらいいってことかな」
「悪うない。やってみ」

VAR X,Y         ' 変数 X と Y を用意(無くても動く)
ACLS
SPSET 0,600
STICK OUT X,Y   ' スライドパッドの値を X と Y に入れて
SPOFS 0,X,Y     ' お姫様を X, Y の場所に表示

( ' から後ろはコメントだから入れなくていいよ)


「できた! START! ……できてない……どうして……?」
「いろいろ惜しいなあ。どんなふうになった?」
「えー。動かない」
「プログラミングで一番大事なんは、そこでただ『動かない』って言うんやなくて、『どんなふうに動かないか』をちゃんと見ることなんや」
「うーん。でも本当にただ動かないだけだよ」
「何が?」
「お姫様が」
「どこから?」
「左上?」
「どこへ?」
「え? えーと、どこへって言うか、スライドパッドで動かした通りに動かない」
「画面を見て他に何か気づかへん?」
「うーん……お姫様のところになんかちかちかしてて、文字も重なって出てるような…… OK かな、これ。ってあれ? OK って、プログラム動いてない時に出てなかったっけ?」
「つまり、お姫さんがスライドパッドを右にずらしたら右、下にずらしたら下に動いてほしいのに、左上から動かへんし、よう見たらそもそもプログラム終わっとる」
「そうそう。って、そらうごかへんわー」
「おう、ノリ良うなってきたやないか。そしたらまず『プログラム終わっとる』をどうにかせなな」
「スクラッチだったらプログラム勝手に終わったりしないのに……」
「そこは Scratch とプチコンの大きい違いやなあ。Scratch は『すべてを止める』パーツを置くか、自分で停止をクリックせん限り動き続けるんや*2。なんでか言うと Scratch はそれぞれのスプライトにプログラムが付いてて、メインのプログラムっちゅうもんがないねん*3。けど、プチコンはメインのプログラムが最後まで走ったら終わってまうんや」
「でもプログラムって上から順番に実行するんだから、いつかは最後まで行っちゃうよね?」
「ループしたら最後まで行かへんよ」
「ループ? 同じ命令を繰り返すやつがスクラッチにあったけど、それ?」
「そうや。今やりたいんは『スライドパッドの通りにお姫様を動かす』をずっと続けることやから、それをループしたらええ。そしたらプログラムも終わらへんでずっと動いてくれるっちゅうわけや」*4
「スクラッチだと『ずっと繰り返す』みたいなコの字のパーツでループにしたいところを挟むんだったけど、プチコンだとどうするの? コの字とか書けないのに」
「方法はいくつかある。BASIC らしいループ言うたらやっぱし GOTO(ゴウトゥ) 使うたやつやねんけど、Scratch のループ知ってるんやったら WHILE(ホワイル) と WEND で挟む方がええやろうな。WHILE の後にはどこまで繰り返すかの条件を書くんやけど、1 書いたら『ずっと繰り返す』んや」
「そうしたら、ええと、こう?」

WHILE 1      ' ループ開始
VAR X,Y
ACLS
SPSET 0,600
STICK OUT X,Y
SPOFS 0,X,Y
WEND         ' ループ終了

「うわお。やりすぎや。変数用意するのとか、画面消すのとかは繰り返さんでええから」
「そっか繰り返したいところだけ WHILE と WEND で囲えばいいんだね」
「あとは、そやな、ループが一目でわかるよう、先頭に空白を入れて少し下げると見やすなる。Scratch でコの字になっとるんもそのイメージやな」

VAR X,Y
ACLS
SPSET 0,600
WHILE 1      ' ループ開始
  STICK OUT X,Y
  SPOFS 0,X,Y
WEND         ' ループ終了

「こう? うーんでもやっぱり動かない……」
「全然変わらへんか?」
「うん、一緒……いや、OK って出ないから、プログラム終わらなくなった」
「一歩前進やな」
「でも結局動いてないし」
「実は全然動いてないんやなくて、見てわかるほど動いてないだけなんやけどな……」
「えーなにそれ」
「どないするんがええかな。試しにSPOFS に渡す X と Y を 100倍とかしてみるか。プログラミングで掛け算は × やのうて * や」
「プログラム書き替えたくても、 EDIT を押しても何にもならないんだけど……」
「え? ああ、そうか。まだプログラム実行中やから、START 押していっぺん止めて EDIT や」

  SPOFS 0,X*100,Y*100

「こう? じゃあまた START で実行っと。……動いた! お姫様が動いた!」
「完成か?」
「違う! なんか変! これじゃない! でも動いた!」
「そやなあ、たとえ期待通りでなくても動くと嬉しいねん。おっちゃんにもそんな時代が……」
「おっちゃんはどうでもいいから、これどうしたらちゃんと動くの?」
「プログラミングで大事なんはなんやった?」
「『どんなふうに動かないか』。えーと動いてはいるんだけど……スライドパッドを動かしたら、そっちの方にすーっと動いて欲しかったのに、今はスライドパッドを動かした分だけ左上から離れて、スライドパッドを離したらまたもとの左上に戻っちゃう」
「他には?」
「なんか動きが変。思った方向に行かないことがあるっていうか……わかった! 横はいいんだけど、縦が逆だ。スライドパッドを上に入れたらお姫様が下に動く。左右は普通なのに……」
「動きの方はスライドパッドの仕様やろうな。3D のゲームで考えたら、上は『上に進む』やなくて『前に進む』なんやろ」
「そっか。じゃあ 2D のゲームの時は、受け取った Y のプラスマイナスが逆だと思えばいいんだね。離すと元に戻っちゃうのは?」
「STICK OUT でもらえるんは『変化量』やで。そん時のスライドパッドが真ん中からどれくらいずらされてるんかが X と Y に入ってて、その場所にお姫さんを表示してるんやから、そら離したら元に戻るわいな」
「うーん…… X と Y はお姫様の今いる場所のつもりなんだけど……」
「そしたら別の変数を使わなな。STICK OUT で受ける方は DX と DY ってしてみたらどうや」

  STICK OUT DX,DY
  SPOFS 0,X,Y

「あー。そういうこと。いやでもこれ START しなくても動かないってわかるよ!?」
「スライドパッドを右入れたらどうなって欲しい?」
「右に動いてほしい」
「変数で言うたら?」
「変数……横は X か。DX が大きくなったら X が増えてほしい。そっか X に DX を足せばいいんだ」

  X+DX

「惜しい! それやと X と DX を足し算しただけで、足した数がどっかいってまうんや*5。もっぺん X に『代入』せな」
「だいにゅう?」
「とりあえず先に正解を見とくか。X に DX を足すってプログラムはこう書くねん」

  X=X+DX

「XイコールX足すDX? どういうこと? DXがゼロじゃないとダメだよね、これだと」
「このイコールは等しいって意味やなくて、さっきも言った『代入』やねん。 X+DX の結果を変数 X に入れるっちゅうことや。イコールやなくて矢印やったら直観的にわかりやすかってんけどな*6。こんな感じに」

  X <- X+DX    ' ※注:プチコンでこう書いたらエラーになります

「変数イコールがあったら右の計算を左の変数に入れるってことなんだ。あ! スクラッチで『変数を○にする』ってのがあったけど、あれといっしょ?」
「そや。言葉やと勘違いしようがなくてええな。代入って言葉は中学になったら数学で習うんやけど、それはプログラミングの代入とは意味違うねん。んで、かなわんことに高校ではプログラミングは数学なんや。センター試験でプログラミングが狙い目やとかどっかで吹き込まれた生徒がのこのこ来たりするんやけど、そうゆうんはたいてい数学の代入とプログラミングの代入の区別が付かんでえろう難儀したわ……*7
「おっちゃん。ねえ、おっちゃん! これでいいの?」
「ん? お、おう。んーいや、STICK OUT の縦はプラスマイナスが逆やったこと忘れてへん?」
「あ、そうか。じゃあ Y=Y+DY は Y=Y-DY に変えて……」

VAR X,Y,DX,DY
ACLS
SPSET 0,600
WHILE 1
  STICK OUT DX,DY
  X=X+DX
  Y=Y-DY
  SPOFS 0,X,Y
WEND

「スタート! ……消えた? パッドを入れたらお姫様が……」
「あー……。ええとな、プログラムはほぼ合うてんねんけど、速すぎて見えてへんねん」*8
「ああ、知ってる。動体視力ってやつだよね?」
「なんぼ目ぇ良うても見えへんわ。そのくらい速すぎるから、ちょい遅うする命令があるねん。プチコンではループに VSYNC(ブイシンク) って命令を入れとくと、60 分の 1 秒に 1 回ループが回るよう調整してくれる。60 分の 1 秒いうんはハードウェアの都合っちゅうのもあるんやけど、ゲームにちょうどいいスピードなんで、基本いっつも VSYNC って入れるもんやと覚えといたらええ」
「VSYNC ってどこに入れたらいいの?」
「描画のタイミングとか『処理落ち』*9とか、細かいこと言い出したらいろいろあんねんけど、とりあえずループの最後に入れとき。難しいことは難しいことができるようなってから覚えたらええから」

VAR X,Y,DX,DY
ACLS
SPSET 0,600
WHILE 1
  STICK OUT DX,DY
  X=X+DX
  Y=Y-DY
  SPOFS 0,X,Y
  VSYNC     ' 1/60秒に1回ループ
WEND

「動いた! 動くよ! パッドでお姫様が思ったとおりに動く!」
「いつもゲームしとるだけの 3DS で、短いとは言え自分で作ったプログラムでキャラクタ動かせるんは、楽しなるよなあ」
「……でも全然ゲームじゃない」
「そらしゃーない。ちゃんとゲームにしよう思ったらこっからまだまだまだまだかかるわ」
「わかるけど……」
「よっしゃ、そしたらおっちゃんがこれをゲームっぽくしたろ。まだ知らん命令はできるだけ使わんで……。……。でけた」
「はや!」

VAR X,Y,DX,DY
ACLS
SPSET 0,600:SPCOL 0
SPSET 1,269:SPCOL 1:SPOFS 1,100,160 ' 宝箱 その1
SPSET 2,269:SPCOL 2:SPOFS 2,200,160 ' 宝箱 その2
SPSET 3,269:SPCOL 3:SPOFS 3,300,160 ' 宝箱 その3
WHILE 1
  STICK OUT DX,DY
  X=X+DX
  Y=Y-DY
  SPOFS 0,X,Y
  IF SPHITSP(0)>=0 THEN BREAK  ' 宝箱に当たったらループを抜ける
  VSYNC
WEND
SPSET 1,268 ' ふたが開いた宝箱に変える
SPSET 2,268
SPSET 3,268
SPSET 4,24  ' ダイヤモンドを表示
SPOFS 4,100,140

「中身の説明は後でしたるし、ちょい遊んでみ」

「宝箱?」
「そのうちの1つに近づくと……」
「開いた! ダイヤ出た! わーい」

「プログラムのどこが変わっとるかわかる?」
「んー、最初と最後に SPSET とかが増えてる?」
「スプライトの1番から3番が宝箱で、4番が宝石に使うてる。最初の SPSET のかたまりで宝箱(269)を置いて、最後の SPSET らへんで開いてる宝箱の絵(268)に変えたり、宝石(24)を置いたりしとるわけや。まだ知らん命令はできるだけ使わんようにはしたけど……」
「最初の SPSET のとこ、一行が結構長いね。んーこれってもしかして命令つなげてる?」

SPSET 0,600:SPCOL 0
SPSET 1,269:SPCOL 1:SPOFS 1,100,160 ' 宝箱 その1
SPSET 2,269:SPCOL 2:SPOFS 2,200,160 ' 宝箱 その2
SPSET 3,269:SPCOL 3:SPOFS 3,300,160 ' 宝箱 その3

「お、ようわかったな。プチコンは複数の命令を : (コロン) で区切って1行に書けるんや。コロンで分けたら、例えば宝箱1つ分の表示は 3つの命令でできてる」

SPSET 1,269
SPCOL 1
SPOFS 1,100,160

「これが3つ分だとだらーっと長くなりそう。だからつなげたんだね」
「まあそういう同じことの繰り返しを書く命令もちゃんとあるんやけど、今回は知らん命令を使わんようにしたかったんで、やめといてん」
「あれ? SPSET と SPOFS はお姫様を動かす時にもう使ったけど、SPCOL って初めて見る気がする」
「そやねん、こいつはまだ説明しとらん命令やねんけど、スプライトの衝突(しょうとつ)検知のために使わんわけにいかんかってん」
「スプライトのしょうとつ?」
「ループの中で VSYNC の前に入れた 1 行がそれや」

  IF SPHITSP(0)>=0 THEN BREAK

「なんかまだ見たことない命令ばっかり……」
「この一行は『お姫さんが宝箱にぶつかったらループを抜ける』って命令や」
「えーと、お姫様スプライトが宝箱スプライトに触ったらループを抜けて……ああ、最後の宝箱を開ける命令のところに行くんだ。なるほどー」
「 IF(イフ) と THEN(ゼン) は2つセットの命令で、IF の後ろの条件が成立したときだけ、THEN の後ろの命令を実行してくれるんや」
「スクラッチで『もし〜なら〜』ってパーツあったけど、あれと一緒だね。じゃあ IF の後ろの SPHITSP(0)>=0 ってのが、お姫様が宝箱に触ったっていう条件になるんだ」
「 SPHITSP はプチコンのスプライトの命令で、書き方で使い方が変わってちょい複雑やねんけど、 SPHITSP(0) って書いた場合は、0 番のスプライト、つまりお姫さんがぶつかったスプライトの番号が返ってくるねん。なんもぶつかってへんかったら -1 になるから、IF の条件のとこを SPHITSP(0)>=0 ってしといたら、『もしお姫さんが何かにぶつかったら〜』ちゅう命令になるわけや」
「 >= は ≧(以上)って意味?」
「ああ、そうそう。そうや。それも説明せなあかんな。プログラムでは等号・不等号や大小の条件はコンピュータで使いやすい記号になっとって、人間の記号とはちょっとちゃうねん。特に等号は == とイコール2個になるから注意や」

条件 プログラム
= ==
!=
> >
<=
>=

「えーなんでイコール2個……わかった! 代入とごっちゃになるから!?」
「おー賢いなあ。その通り。昔の BASIC(ベーシック) は条件の等号もイコール1個で書いとったもんやけど、それがようバグの原因になってなあ。ノスタルジーあふれるプチコンも、さすがにそこは真似せんかったちゅうわけや」*10
「スプライトがぶつかったらわかるってスクラッチにもあったかも……。でもあっちは『○○に触れた』の○○のところに、ぶつかったか調べる相手を選ばないといけなかったよ。プチコンは何とぶつかったか勝手に調べてくれるんだね」
プチコンも調べる相手を指定できるで。どっちもできる。便利やろ?」
「スクラッチシューティングゲームを作ると、敵いっぱい、弾いっぱいでスプライトがぶつかったかチェックできなくなって、弾の色でがんばってやったりしてたもん。プチコンのほうがたしかに便利かなあ」
「Scratch でシューティング作ったんか。たいしたもんやなあ。それやったらわかるやろうけど、ぶつかったか調べたい相手って、いつも全部のスプライトってわけやないねん」
「自分の弾と自分ってぶつからないよね」
「スプライトごとに衝突チェックするグループをつけたりできるんが、実は SPCOL って命令やねん」
「あー後で説明するって言ってたやつ」
「細かい使い方はややこいからやらんけど、とりあえず SPCOL 0 ってしたら、0番のスプライトは衝突チェックするようになるねん」
「だからお姫様と宝箱の番号で全部 SPCOL ってしてあるんだ」
「これで全部説明したんかな」
「THEN の後ろのBR……ってのがループを抜ける命令?」
「おっ、忘れるとこやった。そや。BREAK(ブレイク) って読むんや。ループを作る命令は今使うてる WHILE 以外にもあるんやけど、そのどれでも BREAK で抜けられるで。あ、GOTO で書いたループはあかんけどな。あと、ループの中にループがある入れ子の場合は一番内側のループから抜けるとかあるけど、まあそこらへんはぼちぼち」
「ねーねー、さっきから遊んでるんだけど、これ、ダイヤが入ってる箱決まってない? いつも左端なんだけど」
「おかしい思うたらプログラムを見てみーや」
「むー」

SPSET 4,24  ' ダイヤモンドを表示
SPOFS 4,100,140

「ダイヤを x 座標 100, y 座標 140 に表示……って、そりゃあ毎回おんなじに決まってるやん!」
「ときどきツッコミ良うなるなあ」
「おっちゃん、これじゃあさすがにつまんない〜」
「じゃあ今日は最後にそこだけなんとかしよか。プログラムで毎回違うことをさせたかったら『乱数』を使うんや。実際にプログラムを書くと……」

SPSET 4,24  ' ダイヤモンドを表示
R=RND(3)+1
SPOFS 4,R*100,140

「アールエヌディーってのが『らんすう』?」
「英語の RANDOMIZE(ランダマイズ) の略だから RND(ランド) って読むかな。こいつは……コンピュータ用のサイコロ? 呼ばれると中でサイコロ振って出た数字が返ってくるみたいなイメージや。普通のサイコロは 6 面やけど、RND は好きな面数選べんで。RND(3) のときは 0 か 1 か 2 が出る『3面サイコロ』や」
「 RND(3) なのに 3 は無いの?」
「 0 か 1 か 2 の『3通り』いうことやな。コンピュータは 0 から始まるほうが都合ええから。1 から 3 の乱数が欲しかったら RND(3)+1 ってするんや。『1から1000までのなにか適当な数』とかほんまのサイコロやと難しいけど、乱数やったら RND(1000)+1 でしまいや」
「 R=RND(3)+1 で、R に 1 か 2 か 3 の乱数が入って、x座標が R かける100, y座標 140 のところにダイヤが表示されるから、毎回違う宝箱のところにダイヤが出てくるようになるんだね」
「どうや、初めてのプチコンプログラミングは?」
「…………10回連続でダイヤ外した……」
「いやいや、ゲームやのうてプログラミングや」
「おもしろかったよ。全然違うのにスクラッチと結構いっしょで、今のところそんなに難しくないし……って、なんか終わったみたいに言ってるけど! 妖怪ウォッチみたいなの作りたいって言ったのに全然できてない!」
「いやいや、ゲーム作るの大変やってことはようわかったやろ。そんなんほいほいゲームできるんやったら、おっちゃん今頃大金持ちや」
「そうかー。おっちゃん、ゲーム買うお金なくて自分で作ってるくらいだもんね」
「そうそう。自分で作ったら金かからへんからなんぼでも遊べんで、ってなんでやねん! 今は大人やから欲しいゲームくらい買えるわ!」
「へー、おばちゃんに許してもらわなくても買えるようになったんだー。よかったねー」
「……お姫さんの右向きの番号とかメモったのに使ってなかったっけ。そこらへんはまた今度な」
「ほーい」



今年のお年玉駄文もちょっと遅れましたが、うちの子供たちのために書いたプチコン3号・チュートリアル。Scratch を知ってる設定は、実際うちの子たちがそうだから。
やっぱり間口の広さは Scratch が圧倒的。Scratch にある程度慣れて本格的なゲームを作るのは難しいとわかったあたりで、プチコンに移ってくる流れができたりすると楽しそうかな。

*1:マリオシリーズの姫。ピーチはピンク、デイジーは黄色のドレスをだいたい着てる

*2:さらに Scratch はキー入力や一部のイベントには止まってても反応します

*3:オブジェクト指向とかイベントドリブンとか、そういうキーワードが出てきてややこしいので説明しません

*4:Scratch も自分でループ書く必要はないけど、実は奥の見えないところでぐるぐる回ってます

*5:さらにプチコンは計算式だけの文を認めてないのでエラーになる

*6:実際、代入をイコールではなく矢印とかで書けるプログラミング言語もあります

*7:ちなみに英語では、数学の代入は substitution、プログラミングの代入は assignment と違う単語だったりします

*8:正確には、プチコンの描画のタイミングより速すぎて、描かれる前に画面の外まで移動してしまっているので、『速すぎて見えない』というより『速すぎて描くのが間に合わない』って感じ。そら見えへんわー。昔のコンピュータの BASIC だと、ウェイト無しで速すぎることはあっても見えないなんてことはなかったんだけどね……。技術の進歩はすごい。

*9:処理が多すぎてそもそも60分の1秒に間に合わないときにガクッとゲームのスピードが落ちること

*10:ノスタルジー的には不等号も <> が良かったかもしれない(笑)

「調査観察データの統計科学」3.1章 傾向スコアの数式メモ(後半)


前回に続いて、「調査観察データの統計科学」の 3.1章の後半を読む。
バランシングスコア b(x) を定義し、b(x) がバランシングスコアであることと、ある関数 g があって p(z=1|\boldsymbol{x})=g(b(\boldsymbol{x})) が成り立つことが同値である(特に十分である)ことを示した(p60)。


続いて本では、b(x) がバランシングスコアであり、かつ 2.5章の「強く無視できる割り当て」条件、つまり (y1,y0)⊥z|x が成立している時、(y1,y0)⊥z|b(x) が成り立つと言っている(p61)。
命題として書くと、


\boldsymbol{x}\bot z\;|\;b(\boldsymbol{x}) かつ (y_1,y_0)\bot z\;|\;\boldsymbol{x} ならば (y_1,y_0)\bot z\;|\;b(\boldsymbol{x})


となる。
これは、共変量 x を条件付けると割り当て z と潜在的結果変数 (y1,y0) が独立であるという「強く無視できる割り当て」条件について、バランシングスコアのもとでは「b(x) を条件付けると」に置き換えることができるということである。
共変量 x は一般に多次元であるのに対して、バランシングスコアはスカラーなので、「b(x) を縛ると」という条件は「 x を縛ると」よりもかなり緩いものになってくれていて、これがバランシングスコア(引いては傾向スコア)の嬉しさにつながる重要な性質だったりする。


さて本では、p61 の一番上の積分(期待値)を用いた複雑な式でこの命題を示そうとしている。式(3.2)と同様の計算ではあるのだが、こちらもそちらも「 x で期待値を取っているのに x が残る」という一見間違っているようにみえる式変形になっている。
実は一度 g(b(x)) に置き換えてから戻しているのだが、そのステップが省略されてしまっている。
式(3.2) の方は積分は必須なので避けられないが、p61 の方の命題は確率の乗法定理だけで示せる。丁寧にやるとちょっと数式長くなるんで、社内勉強会のスライドから抜粋。



長いが、一個一個は簡単な変形なので大丈夫だろう。
数式だけだとピンと来ないかもしれないけど、この関係式はグラフィカルモデルを描いたら明らかだったりする。



このグラフィカルモデルで、強く無視できる割り当ては (y1,y0) から z への矢印を切り、バランシングスコアは x から z への矢印を切る。すると、PRML 8章で言うところの tail-to-tail となり、b(x) で縛れば (y1,y0) と z は条件付き独立。一目瞭然。
というかこの絵を描いて、「なーんだ。じゃあ乗法定理だけで示せるはず〜」と上の証明を見つけた。


さて、こういう嬉しい性質のあるバランシングスコアの実例が「傾向スコア」である。


e_i:=p(z_i=1|\boldsymbol{x}_i) を第 i 対象者の「傾向スコア」と言う。
特に \boldsymbol{e}=(e_i) を単に「傾向スコア」と呼ぶ。


傾向スコア ei に対し、b(xi):=ei はバランシングスコアである。実際、関数 g を g(b(x)):=b(x) と置けば、g(b(\boldsymbol{x}_i))=e_i=p(z_i=1|\boldsymbol{x}_i) であり、前半で証明した「十分性」により b(x) がバランシングスコアであることがわかる。
実は、ここまで「嬉しい性質を持つバランシングスコア」なるものが存在するとは一言も言っていなかった。傾向スコアはバランシングスコアを構成することでその存在も証明したわけだ。他にもあるのだろうが、とりあえず知らない。

傾向スコア e_i:=p(z_i=1|\boldsymbol{x}_i) の真値はどう見ても分かりそうにないので、x_i と z_i から推定する必要がある。推定にはプロビット回帰やロジスティック回帰が使われることが多いということで、ロジスティック回帰の場合の説明が続く。
ロジスティック回帰のところは一般的な話なので大丈夫かな。強いて言えば exp の中に定数項が無いのがちょっと心配なくらいか。必要なら x_i がバイアス用の定数成分を持つことにすればいいんだろう。


というわけで、懸念があるとすれば「そもそもロジスティック回帰でいいの?」という部分だろう。
でも大丈夫。3.5章で、ロジスティック回帰モデルが傾向スコアの正しいモデルでない場合にロバストな推論を行うには、という話が出てくる。
えーとじゃあ「ロジスティック回帰モデルが傾向スコアの正しいモデルである」ってどういう状態? それがわかんなかったら、「正しくないからロバストな推定したい!」とすら思えないよね……。
というわけで、一番簡単な「ロジスティック回帰モデルが正しいモデルである例」でも見ておこう。


共変量 x は処置群 z=1 と対照群 z=0 とできっと異なる分布をしているはず(同じ分布なら無作為抽出と同等だから、めんどくさいことする意味ない!)。できるだけ単純にするため、x は一次元にしてしまい、処置群も対照群も同じ正規分布で、ただ平均がずれてるだけということにする。

  • p(x|z=1) = N(1,1)
  • p(x|z=0) = N(-1,1)


このとき、傾向スコア p(z=1|x) は


p(z=1|x)=\frac{p(x|z=1)p(z=1)}{p(x|z=1)p(z=1)+p(x|z=0)p(z=0)}


p(z=1) と p(z=0) がいるなあ。これも単純に p(z=1) = p(z=0) = 1/2 ってことにしよう。すると、


p(z=1|x)=\frac{p(x|z=1)}{p(x|z=1)+p(x|z=0)}=\frac{\exp(-(x-1)^2/2)}{\exp(-(x-1)^2/2)+\exp(-(x+1)^2/2)}
=\frac{1}{1+\exp(-(x+1)^2/2+(x-1)^2/2)}=\frac{1}{1+\exp(-2x)}


とロジスティック関数が登場。というわけでこの単純な例では、ちゃんとロジスティック回帰が真のモデルだとわかる。
一般的には、ロジスティック回帰は線形分類器であり、したがって完全に線形分離可能とまでは言わないものの、そこそこ分離できてないと当てはまり度はどんどん下がっていく。例えば上の簡単な例でも、p(x|z=1) = N(1,100) のように片方が大きい分散を持つだけで線形分離ではなくなる。
そうなってくると3.5章で説明されるような「二重にロバストな推定量」などが必要になってくるのだろう。

「調査観察データの統計科学」3.1章 傾向スコアの数式メモ(前半)

【追記】
社内勉強会資料を整えて公開しました。

【/追記】


みどりぼん(「データ解析のための統計モデリング入門」)を読み終わったから、というわけではないが、同じ岩波・確率と情報の科学シリーズの「調査観察データの統計科学」(星野崇宏)を読んでいる。

社内で週一開催している勉強会の自分の担当回でもこの「調査観察データの統計科学」を紹介。今は3章の傾向スコアの途中。
勉強会向けに資料も作っているが、closed ということでいろいろ遠慮なくやらかしており、そのままだとちょっと公開できない(苦笑)。どうせ傾向スコアまでいかないと内容無いので、3章終わったくらいに再構成して公開しようと思う。


最近は、社内のマーケティングなデータ解析っぽい仕事もしてて、先日開催された WebDB Forum 2014 の技術セッションでは「クラウドサービスにおけるユーザ動向予測について」といった発表をさせてもらった。資料は残念ながら公開できないのだが、概略を簡単に説明すると、BtoB クラウドサービスのように、利用できるデータに制限があってもデータ解析をするには、という感じの話。
そうした「いわゆるデータサイエンス」なお仕事をちょびちょびしていると、やりたいことの半分は「意思決定」なのだろうけど、もう半分は「施策の効果を測定したい」で占められるのでは、と思えてくる。ただしその「施策」もコストがかかるとなると、できるだけ効果の大きい(と希望的に推測している)ところを狙うことになるわけで。
そんな「無作為抽出した実験群」うんぬんが夢物語な状況でも公正な効果測定を行いたい。そういう欲張りな要件に、この本の言う調査観察研究が役立っちゃったりなんかするのかも? と、これが動機。


前置きが長くなったが、今日の本題。
そういうノリで読み始めた「調査観察データの統計科学」だが、この本の数式周りには「むむむ?」というツッコミどころがちょいちょいある。特に傾向スコアが導入される 3.1章は、わずか2ページちょっとながらこの本の中でも重要度が高いだろうと思われるので、ここの数式は疑問をなくしておきたい。
そのあたりをフォローするメモをまとめてみた。


まずバランシングスコアを定義する。
b(x) がバランシングスコアであるとは、\boldsymbol{x}\bot z\;|\;b(\boldsymbol{x}) が成立することとする(条件付き独立の記号が出ないので、縦棒一本で勘弁)。
なお Notaion は本の通りなので、新たに自前の記号を導入でもしない限りここでは一切説明しない。潜在的な結果変数が〜因果効果が〜ってやってたらキリないし。あくまで、「調査観察データの統計科学」を読んでて困ってる人向けのメモである。


続けて、「バランシングスコアは、関数 g を使って p(z=1|\boldsymbol{x})=g(b(\boldsymbol{x})) と表現できることが必要」とあって、式 (3.2) によってそれを証明しようとしているが、これは残念ながら証明になっていない。
A=B を証明せよという問題で、 A=B を使って「この等式が成り立つには A=B が必要である」と答え、「それは証明ではありません」と×される、という流れに身に覚えのある人もいるかと思う。それである。A=B を証明するのに A=B を使ってはいけない。
式 (3.2) を逆に見ると、p(z=1|\boldsymbol{x})=g(b(\boldsymbol{x})) を仮定して p(z=1|\boldsymbol{x})=p(z=1|\boldsymbol{x},b(\boldsymbol{x})) つまり \boldsymbol{x}\bot z\;|\;b(\boldsymbol{x}) が成り立つことを示すことになら使える。よって、{}^\exists g\;\rm{s.t.}\;p(z=1|\boldsymbol{x})=g(b(\boldsymbol{x})) の十分性なら 式 (3.2) によって証明できる。


それを踏まえつつ、そもそもこの命題は何のためにあるのかというと、実は次ページで登場する「傾向スコア」が {}^\exists g\;\rm{s.t.}\;p(z=1|\boldsymbol{x})=g(b(\boldsymbol{x})) を満たしていることから、傾向スコアはバランシングスコアであることを示すのに用いる。つまりここで示すべきは必要性ではなく十分性の方なのだ。
というわけで、ここは式 (3.2) はそのままに、その説明を「バランシングスコアは、関数 g を使って p(z=1|\boldsymbol{x})=g(b(\boldsymbol{x})) と表現できることが十分条件である。というのも {}^\exists g\;\rm{s.t.}\;p(z=1|\boldsymbol{x})=g(b(\boldsymbol{x})) であるとき 式 (3.2) が成立するからである」とし、次のページに「先の証明から傾向スコアがバランシングスコアであることがわかる」という一文を追加すれば論理がつながる(後半は傾向スコアを定義したあとにもう一度説明するのでご心配なく)。


ちなみに、実はこの命題は必要十分で、本の脚注にて「十分条件については Rosenbaum and Rubin(1983)の定理 2 を参照」と付記されている。まあ上での指摘を入れれば、参照すべきは必要条件の方であることは言わずもがなだろう。
せっかく勧めてくれたので Rosenbaum and Rubin(1983) "The Central Role of the Propensity Score in Observational Studies for Causal Effects" の定理 2 を見てみると、必要性を示すのに背理法を用いていた。めんどくさい。
ここは「 x を止めたとき b(x) は一意に決まるので、p(z=1|x,b(x))=p(z=1|x) が常に成り立つ」ことを認め、一方で b(x) がバランシングスコアであることから p(z=1|x,b(x))=p(z=1|b(x)) でもあるので p(z=1|b(x))=p(z=1|x) が言える。よって g(b(x)):=p(z=1|b(x)) とおけばよい。これで必要性の証明になる。背理法とかいらない。かんたん。


この関係式 p(z=1|x,b(x))=p(z=1|x) は本には明記されていないが頻繁に使用されており、例えば先の式 (3.2) の中でもバッチリ使われている。
でも今「 x を止めたとき b(x) は一意に決まるので、p(z=1|x,b(x))=p(z=1|x) が常に成り立つ」とさらっと流そうとしたけど、これもし数学科の演習だったら見逃してもらえない。「それ本当に成り立つの?」「はい、明らかに……*1」「明らかなら証明できるよね?(にっこり)」と真正面から刺されて見事な窮地に陥る。
まったく細かいことであり、傾向スコアを使いたいだけなら無条件に認めても困らないのだろう。が、ここは「3.1章の数式から疑問をなくすメモ」なので、道筋くらいはきっちりつけておこう。


といっても、この「簡単で難しい関係式」が「難しげ」なのは記号 b(x) のせい、ただそれだけである。
b(x) は確率変数でもあり x の関数でもあるかのように都合よく使いまわされている*2。要は手抜き。普段はそうしてズボラしているが、何がどうなっているのか説明しろと言われ、手抜きのしっぺ返しを食らってる、って寸法だ。
これは確率変数と関数をちゃんと分離した記号を導入するだけで解消できる。


今、b は関数 b(x) を表す記号とし、それとは別に確率変数 B を p(B|x)=1 (B=b(x) のとき)、p(B|x)=0 (B≠b(x) のとき) と定義する*3。この記号の下で、今まで p(z=1|x,b(x)) と書いていたのは実は p(z=1|x,B=b(x)) のことだったのだ。これが p(z=1|x) に一致することは確率の加法乗法定理でさくっと出るので以下略。記法重要。


ここまででやっと1ページ進んだが、それなりの分量になってしまい。
3.1 の残りの1ページのためのメモは更に長いので、残りは別記事に切り分けることにする。
社内勉強会もこんな調子でやってるので、なかなか進まない(笑)。1回のセミナーで1行しか進まないとかまあよくある話なんである。数学屋さんは。

*1:ここで「本にそう書いてあったから」と答えたら退場

*2:確率論の公理で「確率変数とは関数である」的な話とは全く別なので混同しないように

*3:B の動く範囲(= b の値域)が離散ならこれでいいが、連続なら本来はディラックデルタ使って指示分布? を構成しないといけない。実際、傾向スコアは連続値をとる。が、計算が煩雑になるだけで本質的には全く変わらないので、理解を得る分にはこの定義で十分だろう

とりあえず plot だけでもしてみるのススメ #みどりぼん

10/21 に開催された「データ解析のための統計モデリング入門」(以下みどりぼん)読書会の最終回にのこのこ参加。主催の yamakatsu さん、参加者&発表者のみなさん、会場を提供してくださったドワンゴさん、ありがとうございました。
懇親会はちょっと断念した。無念。


最後なのでちょっと口はばったいことを言ってみる。
WinBUGS がインストールできなくて試せなかった的な話もあったが、参加された60人ほどの方たちでサンプルデータをとりあえず plot だけでもしてみたって人はどれくらいいただろうか。
みどりぼんにもちろん plot 図はもともと載っている。ただ(学習という面で考えると特に)残念なことに、全ての図に「正解」の点線や、「正解モデル」で推定した分布などが重ねられており、生のデータのものがない。

たいしたことではない。久保先生のサイトで配布されているデータを R で load して plot するだけだ。慣れてれば1分、慣れてなくてもまあ5分くらいの作業。
個人的には RData で配布されるのはちょっとめんどくさい。中を気軽に見れないし。50個の整数データくらいなら、テキストの方が扱いやすくて嬉しい。
というわけで、11章のデータをテキストにしたものを貼り付けておこう。これならコピペして5秒だ。

Y <- c(0,3,2,5,6,16,8,14,11,10,17,19,14,19,19,18,15,13,13,9,11,15,18,12,
       11,17,14,16,15,9,6,15,10,11,14,7,14,14,13,17,8,7,10,4,5,5,7,4,3,1)
plot(Y)

みどりぼんで見た「正解入り」 plot 図と比べて、ずいぶん印象が違う。本当は「正解」なんて知っているはずがないので、実際に目にすることができるのはこちらの方だ。
「正解」を知らないでこの図を見たとしたら、と考えると、正解以外の解釈の可能性がちらちらよぎらないだろうか。例えば「両端は外れ値だな!」とか。
ちなみに、このデータの平均値は 10.9 であるのに対し分散は 27.4 もある。みどりぼんが言うところの「過分散」が起きており、単純なポアソン分布ではモデリングできない → 階層ベイズで空間構造や! というのが 11章のストーリーなわけだが、両端の5点を外れ値とみなして捨てれば、平均 12.7、分散 16.3 と過分散はかなり抑えられる。図もこうなる。

おっとこれって右下のもう2点捨てれば……みたいな作為的な後出しジャンケンは統計の嫌うところではあるが、試してみるのも面白いと思うし、すぐに試せる(から、ここではこれ以上やらない)。

みどりぼんはいくつものモデルを紹介してくれているし、この本で紹介されていないモデルももちろんまだまだたくさんある。その数多あるモデルの中から、実際の場面ではどのモデルを使うべきか決めてくれる論理的な根拠というものは、残念ながら存在しない(せいぜい消去法。例:過分散だから生ポアソンは×)。だから、そこの判断は人間が適切にやるしかない。
データを見て、データに関する事前知識とすり合わせ、「ふむふむ、どうやら空間構造があるかも?(ドヤ」とか推測し、11章のモデルを使ってみるところにたどりつき、実際に試してみて、空間構造を入れた場合と入れてない場合とでナントカ IC を比べたりして、ビミョウな結果に「やっぱ外れ値かも……」とか凹んじゃうわけだ。
でもそれってモデルの上っ面の知識だけでできることだろうか。データを愛で、解釈やモデルを取っ替え引っ替えし、ハマった場合とハマらなかった場合のモデルの挙動に一喜一憂したことがなくてできることだろうか。


LT で berobero11 さんが「みんなもっと plot しよう! WinBUGS しよう!」(意訳)とおっしゃっていたとおり、ホントもっと plot しよう。
WinBUGS は確かにセットアップがいろいろめんどくさい(特に環境によっては)が、JUGS だって Stan だってある。
みどりぼんをせっかく最後まで読んだのだから、意義のあるものにして欲しいと期待。

「データ解析のための統計モデリング入門」6.6章 割算値はなぜダメなのか? #みどりぼん

昨日 7/29 の「第6回「データ解析のための統計モデリング入門」読書会」は参加しなかったのだが、ニコ生で中継してくださっていたので後半を聞くことができた。
6.6章「割算値の統計モデリングはやめよう」では、タイトルの通り観測データ同士を割り算するなと話しているわけだが、読んでいていろいろ疑問に思うところがあり。
読書会中継でちょうど 6.6 章以降を担当された 0kayu さんの発表を聞くことができたのだが、気になっていたあたりは特に質疑でも話題にならず残念。
というわけで、誰かがツッコミを入れてくれることを期待して自分の疑問をここに書いておく。


「データ解析のための統計モデリング入門」6.6章では統計モデルに観測データ同士の割り算値を持ち込むことを批判している。その理由として、

  • 比率にすることで元のスカラー値の情報が失われる
  • 値それぞれが分布を持っている場合、それらの割り算値の分布がよくわからない


があげられている。
が、前者は元の値をモデルから除かずに割り算項を加えるだけならいいとも言えるし、後者の理由なら直前の 6.5章で導入した交互作用項(つまり掛け算)もアウトなはずである。
つまり、上の2つではその理由付けには足りていないのではないか(それとも何か誤解してる?)のが疑問の1つ目。


6.6.1 では「ついつい割り算したくなるようなデータ」でも、オフセット項という「わざ」を使えば割り算を回避できるという話を具体例を交えて紹介している(どうしてここで「わざ」という言葉使いをするんだろうという疑問もあるのだが、さすがに枝葉末節かなとも思うので置いておく)。
しかし、紹介されている具体例を見ると、


\lambda_i=A_i\exp(\beta_1+\beta_2x_i)


という式で表現されている。これは要するに \mathbb{E}[y]/Aモデリングしているわけだ。
しかしそれと \mathbb{E}[y/A] を比べると、割り算がモデルに入ってしまう後者は「絶対ダメ」と言われてしまうほど本質的に違うものだろうか。


最も大きな違いは、y は整数値(植物個体数)なので、\mathbb{E}[y] ならポワソン分布でモデル化できるけど、調査地の面積 A で割った \mathbb{E}[y/A] はそういう訳にはいかない、という点にある。
0以上の実数値を扱う分布と言えば真っ先に思い浮かぶ1つはガンマ分布だが、図ったように みどりぼん 6.8 章はそのガンマ分布を使った GLM の話なわけで、これは試しにやってみろということだろう。


\mathbb{E}[y/A]=\exp(\beta_1+\beta_2x_i)


を、y/A がガンマ分布に従うとしてパラメータ推定したのがこちら。

d <- read.csv("http://hosho.ees.hokudai.ac.jp/~kubo/stat/iwanamibook/fig/binomial/data4b.csv")
(model.poisson <- glm(y~x, offset=log(A),family=poisson,data=d))
(model.gamma <- glm(y/A~x, family=Gamma(link="log"),data=d))
> (model.poisson <- glm(y~x, offset=log(A),family=poisson,data=d))

Call:  glm(formula = y ~ x, family = poisson, data = d, offset = log(A))

Coefficients:
(Intercept)            x
     0.9731       1.0383

Degrees of Freedom: 99 Total (i.e. Null);  98 Residual
Null Deviance:	    261.5
Residual Deviance: 81.61 	AIC: 650.3

> (model.gamma <- glm(y/A~x, family=Gamma(link="log"),data=d))

Call:  glm(formula = y/A ~ x, family = Gamma(link = "log"), data = d)

Coefficients:
(Intercept)            x
     0.9699       1.0516

Degrees of Freedom: 99 Total (i.e. Null);  98 Residual
Null Deviance:	    5.753
Residual Deviance: 1.863 	AIC: 192


上がオフセット項付きポワソン分布、下がガンマ分布。
AIC が出てるとついつい比べたくなるが、それはいくらなんでもダメに決まってる(ヒント:片方だけ連続分布)のでグッと我慢しつつ、推定された係数を見ると非常に近い値が得られている。
線形予測子をプロットしてみても、ほとんど差がないことがわかる(分布は描くのが面倒なので略)。

plot(d$x,log(d$y/d$A))
abline(model.poisson,col="red")
abline(model.gamma,col="blue")

赤がポワソン、青がガンマ。
「結果だけ」見ると、どちらかがどちらかより確実に良い悪いとは言えなさそう。


みどりぼん p133 には「このようにオフセット項を使うと、個体数平均は調査地の面積 A_i に比例する、といった仮定を反映させつつ明るさ x_i の効果を推定できます。個体数を調査地面積で割って密度にする、といった観測値同士の割り算は全く不要です」とあるが、割り算しないことがまるで目的化しているようにも読めて、個人的にはちょっと気持ち悪い。
ここでポワソンのほうがいいんだろうなと判断する根拠としては、ガンマ分布の方は y が整数値しか取らないことをモデリングできていないからであって、割り算が直接要因ではない、はず。


つまり割り算を避けるべき理由がまだいまいちよくわかってない。
おそらくは割り算値を導入した「全然ダメダメなモデル」をたくさん見てきたことから「割り算ダメ」という経験則が生まれたのだと思うのだが、もうちょっと納得できる理由付けはできるんだろうか、というのが2つ目の疑問。
「割り算を使った特徴を組み込む場合はその妥当性に注意をはらいましょう」くらいの言い方なら特に異論ないのだけど、任意の特徴についても「妥当性に注意をはらいましょう」は言えちゃうので、何も言ってないのに等しいか(苦笑)。


そもそも、「比率にすることで元のスカラー値の情報が失われる」という理由を持ち出すのなら、「割り算したくなる値」が目的変数にあたるこの例は適していない気がする。
そして「割り算したくなる値」が説明変数に来る場合は「オフセットわざ」が使えないのだが、その時はどうするのだろう(それでも割り算はダメ?)、というのが最後の疑問。

追記

「データ解析のための統計モデリング入門」6.6章 割算値はなぜダメなのか? #みどりぼん - Mi manca qualche giovedi`? に書いた疑問にコメント・フォローをいただいた。ありがとうございます。



ぶっちゃけると「割り算はダメ」も「割り算してもいい」も額面通りに信じるつもりはもともとなくて、「○○○○な場合は割り算は筋が悪い」くらいの話なのだろうな、と思っていた。みどりぼんはそこの「限定」がうまく表現できていないのかな、と。


現時点で確実に言えることは、割り算固有の話としては「0やその前後を含む分布が除数に来るような割り算はダメ」という算数レベルの常識くらい。
あとは「ヒストグラムや散布図(R で言う pairs)を描いてみて、これはヤバそうという場合は使わないでおきましょう」という、全ての特徴について言えることを守っておけば、割り算をあえて避ける理由はない(少なくともまだ言語化されていない)という理解で大丈夫そうな雰囲気。

ブートストラップの適切なサンプル数 -「データ解析のための統計モデリング入門」第5章 #みどりぼん

7/8 に開催された「データ解析のための統計モデリング入門」、通称「みどりぼん」の第 5 回読書会にのこのこ参加。主宰のやまかつさん、発表者&参加者の皆さん、会場を提供してくださったドワンゴさん、ありがとうございました。


今回は第5章、尤度比検定。
みどりぼんは、この前の回の AIC も含めたモデル選択について比較的ゆるふわな説明で、これはこれでありなんだけど、しっかりしゃっきりしたものも読んでみたいなあ(でも数式少なめでよろしく!)という人は、伊庭さんの「モデル選択とその周辺」がおすすめ度高し。


検定は(有用だろうけど)あんまり好きになれなくて、気分的な盛り上がりは今ひとつなのだが、知らなかったら好きも嫌いもないよね! ということでまじまじ手を動かす。
勉強会の質疑応答も、前回参加した第3回よりおとなしめだったかな。モデル選択って自明な例見せられても実感わかないよねー。


そんな中、パラメトリック・ブートストラップについて、p104 の脚注には「実はサンプルの個数は 10^3 ぐらいでは十分なサイズではありません」とあるが、適切なサンプルサイズはいくつ? そりゃあ増やすほどいいんだろうけどどこまで増やす? とかいう質問が上がっていた。
サンプルを増やすほど推定量の精度が上がる(=分散が下がる)ことは、直感的にわかるだろうし、事実その通りなのだが、残念なことに分散の下がり方は遅い。
実際、一番シンプルな問題として「サンプルの平均」を平均の推定量とする問題を考えるとき、簡単な計算ですぐわかるのだが、サンプル数を N 倍するとその推定量の分散は 1/N に、つまり標準偏差は 1/√N となる(分布の形が漸近的に正規分布に一致することを言うには中心極限定理が必要だけど、ここではそこまでの話は求めていない)。
つまり頑張ってサンプルを 100倍にしても精度は 10倍にしか上がらず、どこかでコストが見合わなくなるわけで、そこが「どこまで増やすか」の答えとなる。

と、いうのが机上のお話なわけだが、「1000 じゃあ足りないよね〜」と訳知り顔でうなずいている人たちは常にそういう事を意識してるかというと必ずしもそういうわけではなく、もっと単純に 1000 では足りない事を経験として知っているのだ。


みどりぼんの 5.4.1 では、パラメトリック・ブートストラップで 1000 個の逸脱度の差を得て、その分布の 95% 点を 3.953957 と推定するお話が出てくる。
ランダムサンプリングしている以上、実行するたびに得られる値は異なる(つまりこの推定値は確率変数)わけだが、さてはて、実際どれくらい結果に幅があるのだろうか。
コードが全て掲載されているのだから、実行して確かめてみればいい。

d <- read.csv("http://hosho.ees.hokudai.ac.jp/~kubo/stat/iwanamibook/fig/poisson/data3a.csv") 
get.dd <- function(d) {
  n.sample <- nrow(d);
  y.mean <- mean(d$y);
  d$y.rnd <- rpois(n.sample, lambda=y.mean)
  fit1 <- glm(y.rnd~1, data=d, family=poisson);
  fit2 <- glm(y.rnd~x, data=d, family=poisson);
  fit1$deviance - fit2$deviance;
}
pb <- function(d, n.bootstrap) {
  replicate(n.bootstrap, get.dd(d));
}


ここまで準備をしておけば、あとは quantile(pb(d, 1000), 0.95) と叩くだけで毎回異なる推定値が得られる。
ぜひ、答えを見る前に、みどりぼんの中の値 3.953957 と比べて、どれくらい推定値に幅が出るか予想してみよう。
テキトーでいいよ〜。




OK? では実際に5回実行して得られた5つの推定値がこちら。

> quantile(pb(d, 1000), 0.95)
     95% 
4.165724 

> quantile(pb(d, 1000), 0.95)
     95% 
4.312189 

> quantile(pb(d, 1000), 0.95)
     95% 
3.513216 

> quantile(pb(d, 1000), 0.95)
     95% 
4.064914 

> quantile(pb(d, 1000), 0.95)
     95% 
3.751253 


おそらく多くの人が「そんなに変わるんかー……」と目を丸くしてくれたのではと期待しているのだが、どうだろう。
これでもう次からは「1000 じゃあ足りないよね〜」といっしょにうなずく仲間入り。


ただし、みどりぼん 5.4.1 の目的は「逸脱度の差 4.5 の p 値が 0.05 より小さいか」を確認することだったのを思い出すと、上の推定値は最大でも 4.3 ちょっとと、p<0.05 という結論には影響ない。
つまり、今回の問題にとって必要な精度は 1000 サンプルでも確保できてそう(まあ、もう少しくらい精度高いほうが安心できるだろうけど)。
しかし逆に、もうちょっときわどい値だったら、例えば「逸脱度の差 4.0 の p 値が 0.05 より小さいか」という問題だったときに、1000サンプルで推定した値がたまたま 3.953957 で、「あーよかった、ギリギリ超えたから棄却できた!」なぁんて言っちゃうたら……。
そういったことを適切に判断することが一番大事で大変だったりする。