2012/08/02
Stravinsky
録った。ストラヴィンスキーは初めて。最初、楽譜を見ながら音を拾ってった時はわけが わからなかったけれど、弾いてるとだんだん意味をなしてくるのが不思議。外国語の学習みたい?
ストラヴィンスキーのピアノ作品の中では、比較的アプローチしやすくて かつ「ストラヴィンスキーっぽさ」が味わえる小品ではなかろうか。
Tag: Piano
2012/08/01
狂犬病への免疫
数日前に狂犬病について書いたばかりだが、ペルーの一部の地域では、 狂犬病にかかってもワクチン無しで生き延びた人がそれなりに居るらしい。
Some Rabies Patients Live to Tell the Tale - ScienceNOW
- 過去数年、狂犬病の発生が報告された地域の住人から血液サンプルを取って調べたら、1割くらいのサンプルで、本人にワクチンを受けた覚えがないのに抗体反応が出た。
- 多くの人は自覚症状さえ無かった。
- 抗体が出た人には高齢の人が多かった。
- かなり弱い種類のウィルスに複数回晒されることで免疫を獲得したのかもしれない。
ブラック・ジャックのエピソードにでも出てきそうな話だなあ。
Tag: Science
2012/07/31
デジタル世代
らむ太に「へのへのもへじ」を教えたらたいそう面白がったのだが、 「あ、そういうのぼくもしってるよ」という。「書いてごらん」と紙を渡したらこう書いた：
(^_^)
Tag: 生活
2012/07/31
マニュアル無視?
ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認
ところが、A氏だけはマニュアルに従わず、自作の「更新プログラム」を利用してシステム変更を行っていた。A氏は今回の事故発生時だけではなく、以前から独自の作業手順を実行しており、上長もこれを認識していながら容認していた。
まあ結果的に事故が起きてるんだし過失は確かなんだけど、 「マニュアル無視の独自手順」っていうふうに取り上げるのに何となく違和感が。 これが工場の事故だったら確かに重大なんだろうけれど。
計算機システム管理の場合、マニュアル自体の変化が工場の工程などよりもずっと 高いし、設計/管理とオペレータの区別も曖昧だ。ある程度ベテランの オペレータになれば自動的にマニュアルを書く立場に立つんじゃないかってこと。 業界によってはwranglerとか呼ばれる、ほんとうにマニュアル に従ってオペするだけの人もいるけれど、自前スクリプトを書き始めた時点で もうマニュアルを書く側に足を突っ込んでると考えられるんでは。
工場の生産工程なら、マニュアルというか決められた工程というのは「固い」もので、 現場との齟齬が出てきたらそれを調査して上の方にエスカレートして、 偉い人が熟慮の上工程を設計しなおすか現場を教育しなおすかってことになるだろうけど。 計算機システムはもっとずっと柔らかくて、現場の「わかっている人」がどんどん マニュアルを書き換えるくらいで良くて、重要なのはその書き換えが複数人の チェックに晒されるレビュープロセスの方じゃないかと思う。つまり件のサーバ事故で ほんとにまずいのは「マニュアル無視を黙認」の方じゃなくて、作業のレビュープロセスの 方だったんじゃないかと。それがスムーズにいってるなら、 「実際に行われる作業＝承認を受けた工程＝マニュアルに書かれるべきこと」 という3者が自動的に一致するので、マニュアル無視ということが起き得ない。
「レビューを通さないと実行できないよ」っていうマニュアルを無視していたって 可能性もあるか。それだって、レビューを通さないと実行できないシステムを 作ってあれば良かったわけで、 やっぱり、「マニュアル」という規範が最初にあってそれに従う、っていう前提が 落ち着かないんだな。
ああ、もしかすると。プログラマにとっては「コード」が規範なので、 コードとマニュアル(自然言語で書かれた手順書)が乖離していたら おかしいのはマニュアルの方だろ、って反射的に思うのかもしれない。 仕様に対してはコードが従だけど、マニュアルに対してはコードの方が主なんじゃないか、と。 もちろんマニュアルからのフィードバックでコードや仕様が変えられることはあるけど、 主要な流れとしては。
(もちろん、「一人だけ勝手なスクリプト作られても他の人が理解できないよ」といった 個々の現場の事情はあるんだろうけど。それだってスクリプトをリポジトリに上げさせて 別の人がレビューしないと本番環境にチェックアウトできないとか、 全員に使わせる前提でなくても何とかなりそうな気はする。)
Tag: Programming
2012/07/28
模範解答と過剰適応
大学の入試問題の正解/模範解答を公開すべきかどうか、という話。
それぞれの立場でいろんな事情があるわけだけど、リソースの問題とか クレームが発生した時の問題とか、そういうものが全部解決できたとして、 大原則として模範解答は公開されるべきなのだろうか。
現在の入試の形態、つまりペーパーテストで、何らかの採点基準があって、 点数順に並べて合否を決める、ということを無条件の前提にすれば、 受験生のためにも、透明性の担保のためにも、公開された方が良いという結論になりそうだ。
けれど、そもそも入試の本来の目的とは何だろうか。 入学後の課程をこなせる基礎があるかどうかを見ること、 その大学での課程によりふさわしい応募者を定員の範囲内で選び出すこと、あたりだろう。
その方法として現在の入試の形態は唯一の方法ではない。全員面接して決めてもいいし、 事前に「作品」を提出させてもいい。現在のペーパーテストは たまたま現実的でそれなりに使える結果が出るから使われてるだけだろう。 試験で得られる点数は、間接的な指標、本当に知りたいことの極めて大雑把な近似値、 proxyにすぎない。
点数順に並べて例えば45点がボーダーラインになったとして、では46点と44点の人に どれほどの違いがあるかというと、実質的な差は無いだろう。 採点基準の揺れやら、「高校で習ってない範囲は減点されるかどうか」なんて違いで100点 満点中5点程度の差が出たとしても、それは入試というproxyを採用することによる誤差範囲に 埋もれる程度の話。極端な話、「±5点くらい完全にランダムなオフセットを加算してから 合否を決めます」くらい最初に宣言しておいた方が、点数にこだわる人が減って良いかもしれない。
ランダムなオフセットというのは突拍子もないアイディアではないと思う。 可塑性のある系で必要以上に厳しい基準を使うと、システムが過剰適応してしまうので、 適度に遊びを持たせるとか入力にわざとノイズを乗せる、なんてのは珍しい話ではない。 それで人生左右される方はたまったもんじゃ無いと思うかもしれないけど、 人生ってそんなもんだ。調子の良い時も悪い時もある。 外的な擾乱が自分に有利に働くことも不利に働くこともある。 目指すべきは、アウトプットの分布が系統的に向上してゆくことであって、 一発勝負に人生賭けて勝つことじゃない。 例えば「就活」の話で企業の採用をまるで入試の合否のように考えている人を見ると、 入試への過剰適応の害って既にかなり蔓延してるんじゃないかという気がする。
模範解答を開示すれば、確かに試験で点を取る/取らせることに最適化できるだろう。しかし 過剰適応の弊害が大きく出ている場合は、むしろそれは避けるべき最適化かもしれない。
(ただ、togetterまとめに出てる、「講評」というのは良いと思う。 これが正解、これが不正解、という話ではなくて、答えがオープンである問題に対して どうアプローチしてゆくか、というのに参考になるから。 現実の問題のほとんどはそういう、模範解答のないオープンな問題なわけだし。)
Tag: Career
Comments (0)