2012/01/14

グラフィックカードが壊れた

メインマシンの画面に突然ランダムに16x16ピクセルの黒い四角がばばばっと現れた。

マシン内の通気が悪くなってGTX470が過熱したかなと、 一度落として中を掃除。しばらく冷ましてから起動してみたが今度はこんな具合だ。

メモリの一部がいかれて、そこにフォントが展開されているのかな。 こういう壊れ方って、昔、マシンにメモリ保護が無かった頃に プログラムを暴走させてVRAMを壊した時の様子と似ていておもしろい。

とはいえこのままじゃ仕事にならないし、いつまた悪化するとも限らない。 部品箱を漁って古いパーツをやりくりして、とりあえず動くようにした。

ちなみにこっちは昔、GeForce6800のカードがおかしくなった時の スクリーンショット。テキストエリアが3角形でおかしくなってるのは、 2Dの表示エリアでもtriangulationのパイプラインを通るのかな。

Tag: Computer

2012/01/12

ピアノレッスン31回目

• 仕事がリリース前で立て込んでて激しく寝不足。子供を学校に送った後仮眠を取るが、レッスン前にさらう時間を取るか、もう数十分の仮眠を貪るか葛藤した。結局目をこすりながらウォームアップのスケールとアルペジオ、それにPasspiedを数回。手が動かない…
• でもそのおかげで、レッスンでは手が動いた。
• Passpied、四分音符=112で通し。この曲ははるか昔に挑戦して、暗譜して通せるところまではいったんだけど、どうしても左手のpのスタッカートが均一にならず途方に暮れたことがあった。今でも難しいけれど、今回はなんだかだいぶ弾けるようになってる気がする。半年ちょい、ほぼ毎日基礎テクニックをやっていたのが奏効してきているのかもしれない。
• Clair de lune。注意点「ソフトペダルは踏むなら下まで踏み切る。中途半端だと変な音になる」「19-24小節目のメロディもっとなめらかに」
• 来週は4曲通せるかな?

Tag: Piano

2012/01/09

知的なツール、努力の方法

数日前にHacker News経由で Inri137 comments on I'm not so smart as I thought I wasという Redditエントリを読んで感銘を受けたんだけど、そのエントリが 邦訳されていた。と思ったのだが、重要なポイントを外している。

• 「頭脳は関係ない」自信をなくした学生へのMIT卒業生のアドバイス
• Intelligence is Irrelevant: An MIT Alum’s Advice to a Struggling Student

下の英文blogエントリが元のRedditのポストを部分的に引用していて、 件の邦訳はその引用部分を訳したもの。 この英文blogエントリの引用が、元のポストの最重要部分を外した引用なのだ。

上の邦訳だけ読んだら、「プライドを捨て、助けを求めてもいいいから、とにかく頑張れ」ってアドバイスに読めちゃう。でもポイントはそういう精神論じゃないんだ。 オリジナルのポストにはもっと具体的でright onなアドバイスが書かれていて、 そこを省いちゃうのはあまりにもったいない。

オリジナルポストを書いた人はMITに入って、順調な滑り出しをしたかのように思ったのも束の間、 たちまちついてゆけなくなる。寮のとなりに、2年生ながら大学院の数学まで取っちゃうような 素晴らしく頭の良いRという先輩がいた。

I suffered through half a semester of differential equations before my pride let me go to R. for help. And sure enough, he took my textbook for a night to review the material (he couldn't remember it all from third grade), and then he walked me through my difficulties and coached me. I ended up pulling a B+ at the end of a semester and avoiding that train wreck. The thing is, nothing he taught me involved raw brainpower. The more I learned the more I realized that the bulk of his intelligence and his performance just came from study and practice, and that the had amassed a large artillery of intellectual and mathematical tools that he had learned and trained to call upon. He showed me some of those tools, but what I really ended up learning was how to go about finding, building, and refining my own set of cognitive tools.

微分方程式を学期半ばまで苦しんだ挙句、とうとうRに助けを求めた。 彼は私のテキストを一晩借りて内容を確認し (彼にとってはとうの昔にやったことで思い出さなければならなかった)、その後、私がひっかかっているところをひとつづつ、一緒に進みながらコーチしてくれた。 結局その学期はB+を取って、惨劇は免れた。ポイントは、彼が教えてくれたことは、「地頭の良さ」といったものとは何の関係もないことだったってことだ。学べば学ぶほど、彼の知性と成績は、単に彼が勉強と練習を積み重ねて、結果として大量の知的ツール、数学的ツールを装備しいつでも使えるようにしていることから得られたものだ、ということに気づいた。彼はそういったツールのいくつかを見せてくれたけれど、私が最終的に学んだのは、必要な知的ツールを探しだし、作り上げ、研ぎ澄ませて自分なりのツールセットを揃えて行く方法だった。

You got A's because you studied or because the classes were easy. You got a B probably because you were so used to understanding things that you didn't know how to deal with something that didn't come so easily. I'm guessing that early on you built the cognitive and intellectual tools to rapidly acquire and process new information, but that you've relied on those tools so much you never really developed a good set of tools for what to do when those failed. This is what happened to me, but I didn't figure it out until after I got crushed by my first semester of college. I need to ask you, has anyone ever taken the time to teach you how to study? And separately, have you learned how to study on your own in the absence of a teacher or curriculum? These are the most valuable tools you can acquire because they are the tools you will use to develop more powerful and more insightful tools. It only snowballs from there until you become like R.

君がAを取りつづけていたのは、勉強したからか、教科が簡単だったからだ。 それが初めてBを取ってしまったのは、理解することに慣れすぎて、ちょっと手強い問題に 出会った時に、どうすれば良いかわからなかったからだ。 多分君は早いうちに、新しい情報を素早く獲得して処理する、知的ツールをこしらえたんだろう。 けれど君はそれからずっとそのツールだけに頼ってきて、それがうまく使えなかった時に 代わりに使えるような良いツールを身につけることを怠ってきたんだ。 私もそうだったんだ。けれど私は、最初の学期で落第しそうになるまでそのことに気づかなかった。 誰かが時間をとって君に「勉強のやり方」を教えてくれたことはあるかい? それとは別に、教師や決められたカリキュラムが無い状態で、自分だけで勉強を進めるやり方 というのを学んだことはあるかい? これらは、身につけるべきツールのうちでもとりわけ 重要なものだ。これらのツールを使えば、さらに強力で深い洞察ができるツールを 開発することができる。そこから雪だるまのように膨れ上がって、いつかはRのようになれるんだ。

「努力しなさい」というアドバイスは全く、これっぽっちも役に立たない。 何について努力するかが重要なのに、そういうアドバイスは 「何について」という点を何も教えてくれないからだ。

問題を前にして、何が必要なツールかを考える。そしてその必要なツールを身につけるために練習する。 努力っていうのはその過程を単に後付けで評する言葉にすぎない。

(追記2012/01/10 09:50:07 UTC): okudaさんによる全訳。通して読むとなお良いです。

Tags: 学習, 教育

2012/01/08

道具によって育てられる

プロが道具にこだわることと、「弘法は筆を選ばず」とは矛盾しない。プロなら必要に迫られればどんな道具も使いこなせるだろうが、そういう道具を常用することは話が別だからだ。

プロの奏者によるこの一連のtweetが面白かった。

バイオリン名器の音色、現代モノと大差なし？…なわけない。

一応書いておくと、楽器ってのは、使っていくうちに奏者の体も変化していくものなのです。それを「楽器に慣れた」「この楽器の鳴らすコツをつかんだ」という感覚で表現したりしますが、感覚以上に奏者の肉体も物理的に変化しているのですね。

例えば、今自分が使っている１８Ｋの大変グレートな楽器。これを廉価版の普及モデルの他社製品にパッと持ち換えても、かなりな程度「現在の楽器と同じ音」がします。ですが、それをもって廉価版で十分、あるいは「楽器じゃない、腕だ」という単純な結論に達するかというとそれは違っていて（続く）

廉価版の楽器で半年、一年と本番を繰り返すうち、いつのまにか少しづつ「廉価版の楽器の音」になっていきます。そして、数年後、今度はパッと１８Ｋのグレート楽器を吹いても、「廉価版の音」がしてしまうのですね。これは、奏者の感覚以上に微妙な筋肉や神経のバランスなどが変化しているせいなのです

つまり、本当に良い楽器、あるいは相性のいい楽器というのは、文字通り奏者を「育てる」力があるのです。いっときの試演奏で楽器の真価が判断できない理由のひとつがまずこれです。

これは楽器だけの話じゃなく、「なにかをつくる」分野なら何であれ、道具との関係として一般化できそうだ。

相応のスキルのあるプログラマなら、どんな言語でもそれなりに書けるし、 どんな言語でも要請があれば使うだろう。けれど、それは 「言語なんてどうでもいい、関係ない」ということではないわけだ。

言語の場合、「微妙な筋肉や神経のバランス」には影響を与えないだろうけれど (記号の多い言語を使っていたらShiftキーを押す小指が鍛えられるかもしれないが)、 思考と発想のプロセスには確かに影響を与える。 言語の提供する色々な抽象化の仕組みは、思考のツールだ。 ツールが貧弱な言語ではそれを補うために余分な回り道を強いられたり、 設計が一般化できず不自然で特殊な解へと偏ったりする。

まあ何を使おうがどこかでは妥協の必要が出てくるのだけれど、 一時的に「わかって妥協」しているつもりが、常用することで 知らず知らずのうちに発想が制限されてゆく、ってことは、多分あると思う。

これは、単に言語が高機能であれば良いというだけではない。 「こういうインタフェースにすれば綺麗なんだけれど、 性能が出ないから仕方なく抽象度を下げてちょっと汚いインタフェースで妥協する」などというように、 言語処理系の実装にも密接に関わっている。

私自身、性能とインタフェースの綺麗さがトレードオフになったときに性能側に倒す 癖があると自覚している。でも本来、 「最も綺麗に書いたコードが最も速く走る」というのが理想であって、 Gaucheもできるだけそっちの方向に持ってゆこうとあれこれ考えている。 (0.9.3に入るgeneratorとlazy sequenceは、性能を損なわずに抽象度を上げられる 結構良い仕組みではないかと思ってるんだが果たしてどうだろか。)

関連するようなしないようなエントリ:

• 道具話
• プログラミング言語の進化

Tag: Programming

2012/01/05

実装者バイアス

Common Lispもツールは揃ってるんだけど、日常的に使ってると、どうも一段噛ませないと痒いところに手が届かない、ってことがよくある。Gaucheならすぐ届くのに。と思うんだけど、Gaucheでは自分の痒いところを掻けるような機能を自分で追加しているのだから、それは当然なのであった。

自分の作った言語が自分にとって一番使いやすくなるのは必然なのだ。 だから、自分の作った言語の使いやすさを自分で客観的に評価するのはとても難しい。 というより不可能ではなかろうか。

自分という特殊なユーザにオーバーフィッティングしてしまわないためには、 第三者からのフィードバックが欠かせない。 それも、デザインの根幹に触れるような機能よりも、 「どうもちょいとだけ面倒くさい/気持ち悪い/もたつく」といった些細なことがとても参考になる。

デザインの幹になる選択については、意図的な選択であったり、実装上避けがたい都合があることが多い。「見た目がとっつきにくい」とか「静的型が無いと使えないよ」とか「やっぱり遅延評価がデフォルトじゃなきゃ」とか言われても「そうですか」としか返しようがないしなあ。でも、ほんのちょっとしたこと、「この関数がこの型の引数も取ってくれたら1行減ってすっきり書けるのに」とか「ほんの3行で済む処理なんだけど何度も書いててめんどくさい」などといったことは、単に開発者が気づいてないだけ、って可能性が結構ある。

もちろん必要だからってどんどん入れてったら大きくなるばかりなのでどこかで線引きは必要で、一貫性のある線は開発者グループにしか引けないのだけれど、とりあえず声を上げてもらえるとありがたいのだ。

Tags: Programming, Gauche