2011/05/09

let地獄

OCaml の let と let rec はなぜ別扱いになっているのか、決定版、もしくは OCaml 暦十何年だったか忘れたけど仕事で Haskell を一年使ってみた

Schemeなんかもっとヒドい。letとlet*とletrecがあったところに最近letrec*が増えた。そのうえマクロだがand-let*があったりlet-valuesがあったりlet1があったりrlet1があったり。誰だSchemeはシンプルな言語だなんて言った奴は。

まあ、本質的に必要なのはletとletrecだけで、それを統合できない(したくない)理由はOCamlのそれとほとんど同じ。もうひとつScheme特有な事情を挙げると、マクロがあるために「変数を確実にシャドウする手段」が必要ってことがある。 (aif <test> <then> <else>) で、<test>を評価して真だったらその値を暗黙の変数itに束縛して<then>を評価する、なんて非健全なマクロを書いた場合、その展開は束縛フォームを挿入するが (簡略のためlegacy macroな表記で):

 `(let ((it ,<test>))
    (if it ,<then> ,<else>))

<test>の中にitが含まれていたら、それは確実に外側のitを参照してもらわないと困る。「再帰参照があったらletrecとみなす」みたいに勝手に切り替わっちゃうとまずい。

let* に関しては、意味的には単なるネストしたletの構文糖衣であって、OCamlみたいにネストしたletをインデントを深くせずに書けたのなら不要だったろう。 let* の存在理由って、letを重ねるとインデントが深くなりすぎるってだけだもの。

letrec* の立ち位置は微妙。機能としてletrec*はletrecの厳密バージョンであって、正しいプログラムであればその中のletrecをletrec*に無条件に置き換えても動作する。だから、本来ならば、letrecの定義を現在のletrec*のように修正した方が綺麗だったんじゃないかと思われる。

そうした場合、「letで評価順が決まってないのにletrecでは決まることになり不自然だ」とも考えられなくはないが、そもそもletはlambda式のごく単純な構文糖衣であって、その評価順が決まっていないのは関数適用で引数の評価順序が決まっていないからだ。letrecはそれが単純な構文糖衣であるような該当するナニカは無いので、どこかに義理立てする必要もない。letrecのひとつの定義は最初にローカル変数を全部未定義値に束縛してからset!してゆく、というものだが、その定義を使ったら自然に評価順も決まってしまう。

R6RSでletrec*が導入された経緯って何だったかなあ。

Tags: Programming, Scheme

2011/05/05

藻から油

オイル産生藻、だんだん収率が上がってきたってニュースはちょくちょく 目にしていたけど、ハワイでもベンチャーがやってるらしい。

Kona company starts algae-to-oil production

The Big Island company is harvesting up to one ton of algae a month in ponds at its 6-acre facility at Keahole Point. The company estimates it will be able to grow up to 60 tons of algae capable of producing 3,800 gallons of oil per acre per year.

1エーカー1年で3800ガロンってどうなんだろう。

今6エーカーで1トンの藻を栽培してるとある。60トンまで栽培できるっていうから 同じ比率でいくとすると360エーカー。 http://en.wikipedia.org/wiki/Barrel_(unit) によれば油は42ガロン＝1バレルだそうだから 360*3800/42 ≒ 33,000バレル。原油だと今1バレル$100くらいか、 それと同じくらいだとすると年間$3.3M。これじゃペイするの苦しそうだけど。 取れる成分の関係でもっと高く売れるとかかなあ。 あるいは、本格稼働が始まったらもっと重さ当たり面積を稼げるという ことかも (最後の数字が「重さ当たり」になってないところがよくわからない)。

それでも、去年のBPのメキシコ湾原油流出では塞ぐ直前でも一日に53,000バレル漏れてたっていうから、藻の数字が数倍程度上がったとしても、掘り出すのとは規模が桁違いだなあ。 ハワイの年間消費量はここによれば4百万バレル/年。上の計算の桁が合ってれば1%くらい、影響を及ぼすにはあと一桁は上がって欲しい感じか。

Tag: 時事

2011/05/05

クレジットカードの支払い、期日の一週間以上前にチェックを送ってたんだけど、「期日過ぎても支払われてないよ」ってアラートメールが飛んできた。カスタマーサービスに電話。

• 27日にチェック送ったんだけど
• まだついてないねー。今まできちんと払われてるんで、今回の分はペナルティ無しにするよ。次のstatementにlate feeは記載されるけど、その分戻しとくから。
• クレジットスコアに影響無い?
• 無い無い。でも30日過ぎてまだ入金されてなかったらクレジットビューローに連絡がゆくよ
• そりゃ嫌だな。念のため改めて払っとくことできる?
• 今、電話でも支払えるけど手数料が$14.99かかるよ。インターネットならタダだよ。

というわけでネットから支払っといた。 前に送ったチェックはキャンセルしといた方がいいかな。

そういや昨年の州税も、「予定納税の一回分が払われてないよ」って通知が来て、でもチェックはちゃんと送ってて全てクリアされてるからその旨レターにして送ったんだけど、その後連絡がない。後からがつんとペナルティが来たりしたら嫌だから確認しとくか。

一応、チェックを現金化する時は受取人の名前が合ってるか、 その受取人の裏書きが無いとだめなはずなんだけど、 時々、郵便物を掠め取って勝手に現金化しちゃって捕まる人のニュースなんかを 見るんだよな。ああいうのは裏書きを偽造してるんかね。

Tag: 生活

2011/05/04

ピアノレッスン

一人で練習していてもどうも完成度が頭打ちになって進歩が無いなあと ここしばらく感じていたので、レッスンを取ってみることにした。 (らむ太がピアノに興味を示したら一緒に取ってみるのもおもしろいかなと思ってたけどさっぱりなので。 彼は演奏よりもピアノのメカニズムに興味津々である。 そのうえらむ太の中では、親父のピアノは仕事と一緒、つまり「それが終わったら遊んでもらえるもの」と カテゴライズされてしまっているようだ…)

一人でさらっていると、どうも小手先で弾いているんではないかという感じが抜けない。 芝居で言えば「覚えた台詞を喋っている」という段階。 少し離れているとすぐに忘れるし、演奏中は綱渡りをしてるみたいなもので、 ちょっとでも足を踏み外すと止まってしまうのも困りものだ。 何とかこの先に行けたらいいなと思う。 忙しくなったら休まざるを得ないが、その可能性も込みでゆるゆるやろうかと。

んで今日が初レッスン。当面の目標として、今やってるKapustinを「仕上げる」 ところまでやりたいなと思ったんで、Op40-6を持っていってみた。 昨年録音してみたやつだけど、 どうもびしっと決まった感じがしないので。 家族以外の人前で弾くのは数年ぶりでめちゃめちゃ緊張した。

• Op40-6については、演奏上の留意点という意味でアドバイスできることはほとんど無いとのこと(数ヶ所サジェスチョンを受けたけど)。
• ランダムに間違えることについては、ひたすらゆっくりさらって完全に覚えるしかない。
• 止まることについては、曲を先行して頭の中で鳴らすと良い。
• リズム感については、 ゆっくり、拍を声に出して数えながら("One and two and three and four and ...") さらうと良い。
• ゆっくりさらう際に、アクセントなど楽譜の指示に気をつける。
• Sight readingについては、毎日訓練するしかない。比較的簡単で色々な調の 曲の楽譜をどかどか用意してどんどん弾いてく (一度弾いてしまったら初見にならないので)。 うまく弾けない調や和声進行があったら、同じ調や似た和声進行のものを探してやる。
• スピードについて。メトロノームを使ってスケールとアルペジオ(長短24調、短調はharmonic)。
• 一曲だけをさらっていてもある程度以上は弾けるようにならない。 色々な時代の色々な曲を並行してやるべき。
• 来週はOp40-6とあともう一つ、別の時代から易しめの曲をやってくる。

こう書き出すと基本的なことばっかりだな。でも基本のうちどれができてないかを 指摘されるのはとても役に立つ。拍を数えるのは盲点だった。確かに、ややこしいところに かかると拍がどっかいっちゃう。 あと、一度覚えちゃうと楽譜を見なくなる癖があるので、アクセントや表情記号が疎かになりがち。

少ない練習時間を有効利用するには、やる曲を絞らざるを得ないと思ってたんで、 色々並行してやるべきってのもなるほどなあと。回り道のようだがそれが近道だったりするわけだ。 あとは1日1時間程度の練習時間をどう割り振るかだなあ。

ただまあ、ピアノのことについて話せる人がいるというだけでもたいそう楽しい。

Tag: Piano

2011/05/02

速く動くコードの書き方

オリジナルはassertTrue(): How to write fast code、以下の翻訳は 速く動くコードの書き方 - Radium Softwareより。

「CPUというものは……」

彼は言った。

「ある一定の速度で動く。それは１秒間に決まった数の命令を処理することができるが、それ以上はない。１秒間に実行される命令の数には有限個の上限が存在するわけだ。そうだな？」

「そうです」私は言った。

「つまり、コードを速く動かす方法なんでものは存在しないんだ。命令を速く実行する方法が無いんだからな。唯一あるのは、マシンがやることを少なくするということだけだ。」

彼は強調するために間を置いた。

「速くするには」彼はゆっくりと言った「少なくしろ」

まあ正論だけど、 現代においては「遅いのはただただCPUが待ってるから」ってことも 多々あるからなあ。それもトロい別コンポーネントを待ってるってだけじゃなくて、 速いCPU同士がお互いの足を踏み合ってるとか。

「CPUが実行できる有限個の上限」に達すること自体が、かなり難しいゴールなわけで。 (部分的にCPU-boundなボトルネックを見てるだけなら別だけど)。 マシン(あるいはその集合)を各コンポーネントからなるチームと考え、 「いかにチームワークを良くするか」ってとこも重要だよなあ。

とは言え、既に答えがわかっているなら計算せずに答えだけ書いておけばコストはゼロ、 なのだから、大きな意味で、必要の無い計算をしないってのはやっぱり大前提か。 O(n)で済むところをO(n^2)使ってるとかは明らかに改善の余地ありだし。

ただ、コードの字面だけ見て「ここ無駄な計算してるから節約しよう」と 思っても実はCPUの待ちが増えるだけで効果無かったりとかよくあるから、 ひとつの規則を当てはめるのは難しい。

Tag: Programming