2011/08/24

ピアノレッスン11回目

バンクーバーから帰ってすぐに予想外に忙しくなってしまったので、 あまりちゃんとさらう時間が無かった。 それなりに継続してやってきた貯金が効いてる感じではあるが。

• スケール、アルペジオ MM=138 (アルペジオが追いついた)。 時々左右がばらけるのに注意。
• モーツァルトのイ短調ソナタK310全楽章通し。集中して弾けた。 時々左手が必要以上に大きくなるのと、早い箇所のトリルに改善の余地あり。あとはOK。

K310の2,3楽章はずっとやりたかったけど独力ではモチベーションが保てなくて 挫折してたんで、レッスンをきっかけに弾けてよかった。

次はラヴェルのソナチネに取りかかるが、来週までだとほとんど進まないだろうなあ。 うんと昔に譜読みはしてるから何となく覚えてはいるんだけど。

Tag: Piano

2011/08/18

Vancouver + Harrison Hot Springs

今年のSIGGRAPHはVancouver。せっかくなので家族で行って、 会議の後は車を借りてちょっとだけ内陸の方を旅してきた。 Vancouverは15年ぶりだけど、 綺麗な街だなあと思った印象はそのままだった。前回は4月で、山には雪が かなり残っててスキーも出来たんだけど、今回はさすがに遠くに霞んで見える 山肌の谷間に少し白いものが見えるくらい。

• 陽が昇る日中は結構暑いけれど、朝は結構寒い。曇ってると日中も寒い。 (ハワイ基準の「寒い」とは気温20度以下。) でもこのくらいなら、夏の間は暮らし良いかも。冬のことは考えたくないが。 在住の知人は雨ばっかりと言っていたなあ。
• SIGGRAPHで一番面白かったのは "Metropolis Procedural Modeling"。 Grammar basedなprocedural modelingを望む形に導くように制御するって 話はこれまで色々あったけど、どれも個別のテクニック (「スケッチ」に合わせて「木」を生やす」とか) だった。このペーパーでは、 確率的文脈自由文法で生成できるモデルなら何であれ制御できる。 問題を綺麗に抽象化してるのがカッコいい。 この人は他にもいろいろおもしろい研究をしてるなあ。 http://graphics.stanford.edu/~jtalton/research.php
• Vancouver近辺では、Capilano Suspension Bridge、水族館、Science Worldに行った。 らむ太は日本科学未来館では丸1日いて飽きないのでScience Worldが良いんじゃないかと 思ったんだけど、期待してたほどじゃなかったなあ。改装中で展示が縮小されてたせいもあるけれど、 パズル系の展示物などはまだらむ太には早すぎた感じ。結局KidSpaceで時間を費やしたが ああいうのならハワイにもあるしなあ。水族館とCapilanoのつり橋は良かった。
• SIGGRAPH後は、Vancouverから車で2時間程Fraser Riverを遡って Harrison LakeのほとりにあるHarrison Hot Springsへ。 名前のとおり温泉が出てるんだけど、 プールにするのはまあ文化の違いとして許せるが消毒の塩素がものすごくきつくて閉口した。 でも子供には受けが良くて結局ずーっとプールで遊びっぱなし。 周辺の山をハイクできるかと期待してたけど、これももうちょい大きくなってからかもなあ。ドライブしてても、普段見ない景色に興味を持つのは最初の10分で、後は早くホテルに戻って遊びたいとか言い出すし。
• 最終日。Vancouver国際空港から米国内へ飛ぶ時は入国審査を出発前にやっちゃうってのを すっかり忘れてて、入国審査の列でずいぶん待たされたおかげで空港内を走るハメに。 空港内は綺麗で子供が遊べるスペースも見えたんで、もっと余裕持って行けばよかった。

らむ太にとっては日本・ホノルル以外で初めての大きな旅行だったけど、 まだ違いを楽しむっていうふうではないなあ。 自分のいる環境についてある程度の知識と理解が無ければ、 違う環境に行っても何が違うかわからないわけで。 そうなるにはまだ3年くらいかかるかもなあ。

(追記2011/08/21 07:29:08 UTC): 大事な事を書き忘れてた。Vancouverはメシが旨い。 そこらへんの普通の店に入っても旨い。 USでは旨い店を選ばない限り旨くはないので、この違いは圧倒的で、 USから訪れた人々は皆一様に感心していたものだった。 (なお、日本も「そこらへんの普通の店が旨い」という点では素晴らしい国である…というかUSが駄目なだけか。) マーケットで買ったブルーベリーも素晴らしかったなあ。

Tags: Conference, 旅

2011/08/03

演者のエナジー (ピアノレッスン10回目)

今日もコンサートグランドでちょっと弾かせてもらう機会があり、 ラフマニノフの前奏曲Op23-5とカプースチンの練習曲Op40-2をリベンジ。 前回よりはかなり落ち着いて弾けたけど、まだ浮わついててミスが多い。

環境の違い、特に音の違いで集中力が削がれる、というのが大きいと感じた。 pでの音の出方がだいぶ違って、カプースチンの2番は冒頭からしばらく pで速いフレーズが続くものだから、調整しようとすると曲の方がすぽんと抜ける。 ラフマニノフの方はpで初めてもすぐ盛り上がるんで調整が楽。だけど中間部の 左手のアルペジオで同じような困難が。

「上がる」ことについて先生が面白い表現をしていた。 演奏のエネルギーが弱いと、環境に影響されて上がりやすい、というのだ。 これは芝居の経験からも、なかなか的を射た表現だと思った。

核になる表現がしっかりと根付いていればいるほど、外乱に対して 動揺しないし、また環境の変化に追従する余裕も産まれる。

たぶんエネルギーにも種類があって、どこで弾いても確実に同じように弾ける強くて固い エネルギー、観客の微妙な反応とうまくインタラクトして毎回違う演奏/演技を 見せられるしなやかな強さのエネルギー、などがあるんだろう。後者を目指したい ところだが、今はとりあえず少々のことで動揺しないだけの基礎体力をつけないと だめだな。

で、そういうのを鍛えるには、strangerに聴いてもらう機会を たくさん作るしかないとのことだ。 やっぱそうだよなあ、芝居も観客がいてナンボだからなあ。 先生の知人には、家の前を通りかかった見知らぬ人を呼び込んで 聴かせてたって強者もいるらしい。

演者のエネルギーという点では、芝居のノウハウを流用できるかもしれない、 という気がしている。マイズナーテクニックを学んでから、演奏にも 似たような手法が使えるかもしれないと思ってきた。マイズナー言う所の "text is a canoe" と同じように "notes are canoe" と言えるのではないか。

あと基礎練習はスケールが138のまま、アルペジオは132まで上がった。 重三度スケールはMM=48でE♭minorまで練習してるけど、(53)-(31)で小指を 越えるところがきつい。特に5が黒鍵で次の3と1が白鍵の時。

(追記 2011/08/05 11:46:35 UTC): 考えてみれば受かる当てが薄くても継続的に オーディション受けてるのは「見られる感覚」を忘れないようにするためで、 ピアノについても同じ姿勢でいる必要があるというのは当然かもしれん。 あと、スタニスラフスキーの "Public Solitude" がピアノでの 上がり防止/集中維持にも使えるだろうか。演奏は観客に向けてaddress されねばならないとするとちょっと違うか。考えてみる。

Tag: Piano

2011/07/19

動的型のメリットは「決断の遅延」かもしれない

Togetter - 「動的型言語のふわふわ感」 読んでて思ったんだけど。

静的型付けと動的型付けで何が一番違うかって考えてくと、「実行前に済んでること」と「実行時」とをどのくらい分けるか、というところに帰着するかもしれない、と思った。

静的型付けは実行しないでも型エラーをコンパイラが見つけてくれる、というのは、つまり実行する前にプログラムが出来上がっているってことを前提にしているわけだな。程度問題ではあるけれど、実行前のどこかの時点で線を引いて、その時点で分かっている情報の整合性を型という枠組みで保証しましょ、ってわけだから。

「実行する前にプログラムが出来上がっている」なんて当然じゃないか、と思うかもしれないけれど、本当にそうだろうか。

上のtogetterで、「Rubyでは 1 + "hoge" が実行時エラーになるけれど、それは型エラーなんだから実行前に捕まえられた方がいいでしょ」という議論があった。でも、それは型エラーじゃないかもしれない。単に、そういうケースへの対応を実行前にはまだ決めていなかっただけかもしれない。

cl-user(1): (defmethod plus ((x number) (y number)) (+ x y))
#<standard-method plus (number number)>
cl-user(2): (plus 2 3)
5
cl-user(3): (plus 1 "hoge")
Error: No methods applicable for generic function
       #<standard-generic-function plus> with args (1 "hoge") of
       classes (fixnum string)
  [condition type: program-error]

Restart actions (select using :continue):
 0: Try calling it again
 1: Return to Top Level (an "abort" restart).
 2: Abort entirely from this (lisp) process.
[1c] cl-user(4): (defmethod plus ((x number) (y string)) (format nil "~a~a" x y))
#<standard-method plus (number string)>
[1c] cl-user(5): :continue 0
"1hoge"

(Lispに詳しくない人向けの説明: (plus 1 "hoge") というメソッドは未定義なので実行時エラーで止まったけど、そのエラープロンプトから適切なメソッドを追加して実行を再開したので、ちゃんと呼び出し元に答えが返ってくる。)

もちろんこれは極端な例だ。何でもかんでも、実行エラーが出たらその場で直せばいいじゃん、というわけにはいかない。とりわけ、プログラムの作成者とユーザが別々であることが普通になった現代では。

けれども、「プログラムは実行前に完成しているべきである」という前提を疑ってみるのは無益ではないと思う。

例えばユーザによりカスタマイズ可能なプログラム。ユーザが入手した時点でプログラムは完結しておらず、ユーザの手によって使われながら(そのユーザにとっての)完成形へと徐々に進化してゆく、とみなすこともできる。もちろん、プログラム本体とユーザによるカスタマイズ部分を完全に分けて、前者はコンパイル時にがちがちに検査をかけ、後者を実行時に解釈する、という実装は可能だ。でもその分離は本質的なものだろうか? 単に「コンパイル時と実行時の間に線を引かなければならない」という実装上の都合でそうなっているだけかもしれない。

止まること無く走りつづけて、その時その時の状況に合わせてふるまいを変えてゆく必要があるプログラム、というのもある。これも極端な例としては実行中のサーバにランタイムパッチを当てるなんていうケースがあるが、そこまでアドホックな話でないにせよ、あらかじめ変更を見越して後から開発されてくるモジュールを柔軟に読んだり削除したりするようなアーキテクチャというのは考えられる。オンラインゲームで機能を追加してゆくとか ←実際の現場ではさすがに本番系のモジュールを実行中に入れ替えなんてやってないだろうけれど、それも単に今のプログラムというのがそのような実行時の動的変化を安定して扱えないだけだから、かもしれない。ゲームで言えば、プレイしながら振る舞いを調整したいってのもあるね。これも今は振る舞い部分だけ動的スクリプトにしたりするけど、それも本質的な分離ではなく、実装上の都合かもしれない。

思考の道具として、あるいは実行可能なアイディアとしてプログラムを見ることもできる。黒板にメモして、あちこち書き換えながらアイディアを発展させてゆくように、プログラムをあちこち書き換えながらアイディアを詰めてゆく。黒板との違いは、そのプログラムは動かせるということだ。そして、動かしている最中に新しいアイディアを得て、その場で書き換えて(最初から再実行するのではなく)実行を続行したい、というケースは十分考えられる。シミュレーションのように抱える状態が大きいものであれば特にそうだろう。もちろん、ポータブルな形で状態をダンプできるようにしといて、停止→ダンプ→書き換え、再コンパイル→リストア→続行、というワークフローをとることはできる。が、それはやっぱり実装の都合だ。

これらの例をもって、だから静的型付けはだめだ、と主張するつもりはない。現代のプログラムの圧倒的多数は、実行前にプログラムが閉じて完成していることを要請されているだろうし。上に挙げた例でもいちいち注記したように、アーキテクチャを工夫することでフェーズを分離し、静的型付け言語で実装することは可能だ。もちろん、可能だからといってそうすべきであるということにはならない。

動的型付けを好むプログラマが一定数いるのは、プログラマが触っている「開発途中のプログラム」というのがまさに「完成前に実行したい」ものだから、なのかもしれない。とりわけ、「何を、どう作るべきか」がまだ見えない状態でとりあえずデータをいじりながら発想を得たい、なんて時には。

Haskellerと話しているとまず型から考えるみたいで、ある意味「こうあるべき/こうあって欲しい」というイデアから演繹的にコードを導き出してるようにも見える。勝手な思い込みだけど。一方、手元にぐにゃぐにゃした不定形のデータがあってそいつをこね回したいって時には、最初に手をつける時に構造や意味を決めすぎないようにしないと話が進まない。動的型付けは、「この操作はこういう意味を持つ」と定義する決断を先延ばしにしていると言えるかもしれない。先に構造と意味を決めてからコードを書くのではなく、動くコードを書いてからその意味を考えて構造をいじる。こう書くとエンジニアリングとしてはかなり危なっかしい感じがするけれど、一般的に「なにかをつくる過程」だと思えばそれほど不自然な話ではない。

とはいえ、Lispプログラムだって実行前にわかってることはたくさんあるんで、わかってる範囲ではコンパイラに働いて欲しいんだな。動かしてこねこねしているうちに形が定まってきたら、そこでアノテーションを入れて静的検査を強化できたらなあと思うことはよくある。

Tags: Programming, Lisp, Haskell

2011/07/18

ソーシャルな評価と誤魔化しの防止

Why I will never pursue cheating again - A Computer Scientist in a Business School

大学のレポート課題で、webやら過去問の回答やらからのコピペにどう対応すべきか、という話。

最近は提出されたレポートをデータベースと照合して剽窃っぽいものを見つけてくれるソフトが あるけれど、それをかけたら出るわ出るわ。 結局、2割の学生が最終的に剽窃を認めることになったんだけど、 それを認めるまでの言い訳を聞いたりするのは大いなる時間の無駄。 微妙に課題用テンプレートを変えたりして「コピペしたらわかるよ」と周知しておいても、 明らかにバレるようなコピペをしてくる学生は後を絶たない。 厳しく取り締まっても学生による教員評価が下がるだけでいいことなし。

で、コピペしたいという動機の方を何とかできないか、と考えた。 個々に課題を完成させて教員に評価を仰ぐ形では、教員の目さえごまかせれば切り抜けられると 思ってしまう。課題の結果を公表させて相互に評価させる形にしたら、 剽窃バレは恥と認識されて、むしろみんなの良い評価を得るために オリジナリティを出す創造的な方向に情熱が向いたよ、ということだそうだ。

リサーチじゃなくて単なる体験談なので、本当にこれが有効な剽窃防止策になり得るのか という議論は弱いけど (結果が広く公表される世界でも剽窃は必ずしも無くならないし)、 オープンにすることと、相互評価を入れるってことは、まあ効きそうな気がする。

学生時代、プログラミングのコースのTAでレポートの採点をやってて、 ずいぶんコピペにお目にかかったけど、

• 最初から全員公開リポジトリで開発させる
• ちゃんとクレジットすれば他人のコードの一部をコピーして良い
• 評価は単一の尺度ではなく、オリジナリティ、性能、実装の工夫など いろんな尺度について相互評価も含めて行う

などとしておけば良かったかも。 公開リポジトリなら(裏で非コミットのコードをやりとりしない限り)誰が 誰のをコピーしたかわかるし、むしろちゃんとクレジットした上で コードを共有することは奨励されるべきだからなあ。

★ ★ ★

評価する人間の立場が増えれば増えるほど、 そして評価方法が成果に対して即時的、直接的であればあるほど、 誤魔化しが起こりにくくなる、という一般化はできるだろうか。 例えばPaul Grahamは仕事の成果を測るのに、何段階ものindirectionがある大企業よりも、 ユーザから直接の評価を受けるベンチャーの方がずっと正確だ、なんてことを言ってる。 大企業での採用は、その採否が良かったのかどうかを長期的に評価するのが難しい。 だから、採用の時だけ誤魔化せばいいという考えが起き得る。 Y Combinatorに参加したら、3ヶ月後には百戦錬磨の投資家の前でデモが認められないと ならない。そこに誤魔化しの入る余地はほとんど無い。

大学入試は、試験の点数を成果とすれば評価方法は即時的だけど、評価する人間の立場は少ない。 (立場というか、尺度と言った方がいいかなあ)。 政治家は、評価する人間は多いけれど、評価機会が数年に一度なので、個々の成果に対する 即時的なフィードバックが無い。 どちらも、誤魔化しの入る余地が大きい。

…とか。これがどのくらい一般的に適用できるかはわからんけども。 大勢に評価される環境であっても、一時の流行によって評価尺度が偏ることは 排除できないしなあ。

Tag: Career