2012/07/28

模範解答と過剰適応

• なんで模範解答公開しないのだろう？ - 発声練習
• 入試問題の正解は公開されるべきか？ - Togetter

大学の入試問題の正解/模範解答を公開すべきかどうか、という話。

それぞれの立場でいろんな事情があるわけだけど、リソースの問題とか クレームが発生した時の問題とか、そういうものが全部解決できたとして、 大原則として模範解答は公開されるべきなのだろうか。

現在の入試の形態、つまりペーパーテストで、何らかの採点基準があって、 点数順に並べて合否を決める、ということを無条件の前提にすれば、 受験生のためにも、透明性の担保のためにも、公開された方が良いという結論になりそうだ。

けれど、そもそも入試の本来の目的とは何だろうか。 入学後の課程をこなせる基礎があるかどうかを見ること、 その大学での課程によりふさわしい応募者を定員の範囲内で選び出すこと、あたりだろう。

その方法として現在の入試の形態は唯一の方法ではない。全員面接して決めてもいいし、 事前に「作品」を提出させてもいい。現在のペーパーテストは たまたま現実的でそれなりに使える結果が出るから使われてるだけだろう。 試験で得られる点数は、間接的な指標、本当に知りたいことの極めて大雑把な近似値、 proxyにすぎない。

点数順に並べて例えば45点がボーダーラインになったとして、では46点と44点の人に どれほどの違いがあるかというと、実質的な差は無いだろう。 採点基準の揺れやら、「高校で習ってない範囲は減点されるかどうか」なんて違いで100点 満点中5点程度の差が出たとしても、それは入試というproxyを採用することによる誤差範囲に 埋もれる程度の話。極端な話、「±5点くらい完全にランダムなオフセットを加算してから 合否を決めます」くらい最初に宣言しておいた方が、点数にこだわる人が減って良いかもしれない。

ランダムなオフセットというのは突拍子もないアイディアではないと思う。 可塑性のある系で必要以上に厳しい基準を使うと、システムが過剰適応してしまうので、 適度に遊びを持たせるとか入力にわざとノイズを乗せる、なんてのは珍しい話ではない。 それで人生左右される方はたまったもんじゃ無いと思うかもしれないけど、 人生ってそんなもんだ。調子の良い時も悪い時もある。 外的な擾乱が自分に有利に働くことも不利に働くこともある。 目指すべきは、アウトプットの分布が系統的に向上してゆくことであって、 一発勝負に人生賭けて勝つことじゃない。 例えば「就活」の話で企業の採用をまるで入試の合否のように考えている人を見ると、 入試への過剰適応の害って既にかなり蔓延してるんじゃないかという気がする。

模範解答を開示すれば、確かに試験で点を取る/取らせることに最適化できるだろう。しかし 過剰適応の弊害が大きく出ている場合は、むしろそれは避けるべき最適化かもしれない。

(ただ、togetterまとめに出てる、「講評」というのは良いと思う。 これが正解、これが不正解、という話ではなくて、答えがオープンである問題に対して どうアプローチしてゆくか、というのに参考になるから。 現実の問題のほとんどはそういう、模範解答のないオープンな問題なわけだし。)

Tag: Career

2012/07/27

その例えはどうか

本論ではなく枝葉の部分なんだけど。

ビジネスマインデッドな行政官について(内田樹の研究室)

国会で「アメリカの州になります」と議決すればいいのである。

ハワイもテキサスもそうやって州になった。

日本が米国の51番目の州になるには、って話だけど、いや、国会で議決したってなるとは限らんでしょ。

ハワイが州になるかどうか決めた時には、既にハワイは米国自治領だったんで、州になるかどうかはその時点では国内問題。難しいのは州になるかどうかよりも、米国の一部になるかどうかという話の方。

で、もともとハワイが米国自治領になったのは、米国人地主がサトウキビの米国本土への輸出で他国との競争を有利にするために関税を避けたかったから (もちろん他にも色々な要素があるけど、関税の問題が大きなきっかけだった)。それでクーデターまで起こしてハワイ王朝を転覆させハワイ共和国にして、「さあ米国に併合してください」と言ったんだけど、連邦議会は承認しなかった (併合には2/3の賛成が必要だがそれに至らず。何度か提出しては否決されてる)。

数年後、米西戦争が勃発して、ハワイが太平洋でのスペイン植民地に対する戦略的拠点として重要になった時にどさくさにまぎれて併合が承認され、ハワイは自治領になる。

とうわけで確かにハワイが州になったのには経済的理由があるけれど、クーデターも戦争も忘れて「経済的合理性を追求したら州になるのがよい」という論にハワイを持ち出すのは、あまり筋の良い例えじゃないだろう、と思ったのだった。

Tag: Hawaii

2012/07/27

Milwaukee protocol

最近まで、狂犬病は、感染後ワクチンを打たずに発症したら例外なく助からなかった。 2004年、コウモリに噛まれて狂犬病を発症した15歳の少女が Children's Hospital of Wisconsin の医療チームによって救われ、 記録に残るうえで最初の生還者となった。その詳しい記事。

• Down to a prayer
• Buying time against rabies
• 'This is a miracle'

生還者が出たということは当時ニュースで読んでいたけど、 詳しい話は知らなかったのでついつい読みふけってしまった。 キリスト教系のサイトのようで若干神学的な言及もあるけど、 ドキュメンタリーとしても読み応えがある。

Milwaukee Protocolはこの時使われた治療手法。 狂犬病で死ぬのは、ウィルス自体が脳を破壊するわけじゃなくて、 ウィルスによって生じた炎症によって脳の機能がおかしくなるため。 そこで患者を人為的に昏睡状態におき、本人の免疫力がウィルスに勝てるまで強くなるのを待つ。 と、こう説明されるとナルホドと感心してしまうけれど、 前例が無い状態でこれをどうやって思いつき、どうやって決断したかっていうあたりを 前から知りたいと思っていたので、記事中できちんと触れられていて良かった。

この記事は2005年なので回復途上で終わってるけど、確か本人はその後大学も卒業したはず。

同様の治療法で(ワクチンを打たずに発症した段階から)回復したのは2011年の段階で5人 (US内で3人) らしい。助からなかった人の方がまだずっと多い。狂犬病クリーンな地域(日本とハワイは そうだけど、世界的には珍しい)以外で野生動物に噛まれたらワクチンは必須ですな。

• UC Davis Children's Hospital patient becomes third person in U.S. to survive rabies

Tag: Science

2012/07/25

ビート

ふとネットワークモニタを見たらちょっと面白い波形が出てた。 横軸、サンプル周期は1秒で、縦の破線は10秒ごと。

最初は2つのプロセスが少しずれた周期でアクセスしてビートが出てるのかと思ったけど、 この時LAN内でネットを定常的に使ってたのは動画ストリーミングしている1プロセスだけだ。

ビートの周期はおおざっぱに見て6秒くらい=0.17Hz。ナイキスト周波数が0.5Hzだから、 0.83Hzくらいの周期でバースト的に通信と休みを繰り返している、とかかな。 このLAN内のマシンにはtcで帯域制限をかけているので、帯域のクオータをオーバー→しばらく停止、 の繰り返しで振動しているのかもしれん。

Tag: Computer

2012/07/22

New programming jargon

yomoyomoさんとこ経由で知った Coding Horror: New Programming Jargonが面白かった。かなり「あるある」度が高い。

Right on! だと思ったのをいくつか。

Higgs-Bugson

イベントログやユーザの報告にわずかに散見される手がかりから、存在すると予想されているが、 再現するのが非常に困難なバグ。

Hindenbug

名前から予想されるとおり。データベースの下位層とかいじってるとこれは恐い。

Bloombug

「偶然に金を産み出したバグ」ああこういうバグに当たってみたいものだ。

Hydra code

直しても直しても新たな問題が出てくる。
だが安心して欲しい。 ヘラクレスは必ずヒドラに勝てることが証明されている (どんな手法を取っても、いずれヒドラの頭の数は0に収束する)。 但し、途中のヒドラの頭の数は膨大になるが。

Mad girlfriend bug

「なんでもないわ、平気よ」とテストもログも言うけれど、明らかに様子がおかしい。

Jenga code

これも聞いただけでどんなコードかぱっとわかる。できれば近寄りたくないものだ。

並べてみたらバグとひどいコードに関するものばかりになってしまった。

★ ★ ★

Higgs-Bugsonは最近まさしくこいつに当たったばかりなので個人的にツボ。

• かなり重い負荷テストの時にごくたまに見られるエラーログAとB (両者は別々のテストで、一見無関係のコンポーネントから出てる)。
• Aは気になるだけだがBはシステムをハングさせる。だが再現条件がわからない。
• エラーログから、複数プロセスがかかわる ファイルの作成と削除に関係するものであることが疑われるのだが コードを調べてもハザードは見当たらない。と、ここまでは当初私は知らなかったこと。
• 私が担当するコンポーネントで、ある負荷テスト時にたくさんエラーログCが出てくるという 報告があがった。こちらも開発環境で再現する小さなテストセットは作れなかったのだが、 理屈の上でハザードが生じる可能性を見つけた (あるプロセスから別プロセスに非同期で メッセージを送ってて、その処理される順序が入れ替わる可能性があった。入れ替わり自体は 仕様の範囲内なのだが、ある使い方と組み合わさると問題が生じる)。
• その理論を報告したら、上記AとBの事例を示され、「これももしかしてこのバグ?」
• そのつもりでコードを調べると、確かに理論上同じことが起き得る。
• 順序の入れ替わりを無くすパッチを作成、問題の負荷テストを流す→エラー見られず。
• だが「元のコードで確実に再現されるバグが、このパッチで治る」ことは示せてないので、 「バグの存在はほぼ間違いないが確定してはいない」←いまここ

Tag: Programming