答えはわかってるっていう問題は少なくない（実際、答えは42だ）。
問いをはっきりさせるのに抽象化が必要なんだと思う。

連番を作りたい。ようするに、こんな動作をするプロシージャintegがほしい。

gosh> (list (integ) (integ) (integ))
(1 2 3)

まあ、グローバル変数を破壊的に更新すればいい。

(define n 0)
(define (integ)
  (set! n (+ n 1))
  n)

でもそんなSchemeコードはいやだ。主に気分的な理由で。こういう問題にはcall/ccを使うのがオレブーム。

(define (integ)
  (let R ((n 0))
    (call/cc
      (lambda (k)
        (set! integ (lambda () (R (+ n 1))))
        (+ n 1)))))

しかしこれではcall/ccの意味がまったくありませんでした。すみません。以下で十分です。

(define (integ)
  (let R ((n 0))
    (call/cc
      (lambda (k)
        (set! integ (lambda () (R (+ n 1))))
        (+ n 1)))))

気を取り直して。応用。

(let R ((str "hello hello hello hello"))
  (rxmatch-if (rxmatch #/ / str)
      (space)
    (R (regexp-replace space str #`",(integ)"))
    str))

=> hello1hello2hello3hello"

Gaucheに用意されているregexp-replace-allという便利な関数と組み合わせると編集者にとってはプチよろこばしい。

gosh> (regexp-replace-all #/ / "hello hello hello hello" (lambda (m) (integ)))
"hello4hello5hello6hello"

ところでintegを次のように定義するとうまくいかない理由を昨日から考えているんだけど、わからない。これでもとくに問題なさそうなんだけど、(list (integ) (integ)) のように実行しても1つめの(integ)が評価されるだけ。

(define (integ)
  (call/cc
    (lambda (skip)
      (let R ((n 0))
        (call/cc
          (lambda (k)
            (set! integ (lambda () (k '())))
            (skip (+ n 1))))
        (R (+ n 1))))))

おれカネゴンさんの一言をきっかけに、ひさしぶりにコンサートに行ってきた。去年はひとつも行かなかったなあ。

東京都交響楽団 第638回定期演奏会　Aシリーズ
http://www.tmso.or.jp/j/concert_ticket/detail/index.php?id=3024

こちらで絶賛されている松村禎三の「ピアノ協奏曲 第1番」は聴いたことがなかったけど、生で野平一郎の協奏曲ソロが聴けるということで、すぐにチケットを手配。オネゲルの5番が「生で」聴けるというのも即決したポイント。ミヨーも聴いたことないけど、まあ、ミヨーのオーケストラ曲は僕にとってどれも似たような印象だからハズレはありえないだろう（これは賛辞です）。幸い（主催者側にとっては残念ながら）、席は豊富に残っていた。もう1週間前なのに。野平なのに。

当日、会場は予想どおり空席が目立つ。ぼくは3階だったので、開宴前に上からぼうっと下を見ていると、おじいさんが車椅子で会場に。よくみると松村禎三本人で、やるせなさがこみあげる。この演目だから客が入らないというより、たぶんぼくのような潜在的な客を逃しているのが大きいんだろう。実際、ぼくも公演の存在すら知らなかった。

演奏については、まず、この公演に足をはこぶきっかけを与えてくれた「新しい世紀のための音楽」のレビューを。

ぼくには、松村禎三の2曲はどちらも文句のつけどころがなかった。とくに「管弦楽のための前奏曲」では、CDで聴いて知っていた以上にピッコロ6本がからみあう迫力がすごくて鳥肌もの。「ピアノ協奏曲第1番」は、もう、やっぱり野平さんすげー。苦労している様子は少なくとも僕には感じられなかった。はじめて聴いた曲だけど、竹薮がざわざわしているようなピアノソロの冒頭になつかしい印象を受けるのは松村禎三本人がいっているところの「アジア的な群」というやつにアジアで生まれ育った人間として共感するのでしょうか。よくわかんないけど。とにかく、それからピアノが次第に高揚していって、気づいたらオーケストラがうねりながらからんでいる。自然科学的には風がふいて竹薮がざわめくはずなのに、竹薮がざわめくことで空気をゆらし風を巻き上げているみたいな。そういううねりが2回くらい繰り返され、冒頭のようなピアノソロのざわざわで静かに終わる。この協奏曲は、ほんとうにすごいや。その世界感をきちんと提示してくれた都饗と指揮の下野さん、野平さんの演奏ではじめて曲を聴くとができてよかった。この協奏曲はストラビンスキーとバルトークと前期ケ−ジの好きな全世界の人に心からおすすめ。

後半はミヨーとオネゲル。ミヨーは誰がやっても同じようにハッピーになると思うのでいいとして（これは賛辞です）、オネゲルの5番は最後になって管がちょっとばて気味に感じられた。第1楽章はとてもよかったけど、それも中盤で弦による主題を背景に木管がタリラータリラーってするとことか、だいぶ弦に潰されてしまっていた感じ。第3楽章のラストになると、みんなちょっぴりぐだぐだ。でもとてもよい演奏会だった。C席3500円でこれだけ楽しめるとは。こんな構成はあまりないだろうけど、都饗の定期演奏会はこれからもチェックするようにしよう。

常識なのかもしれないけど……

LaTeXのリストの体裁を制御する変数（『The LaTeXコンパニオン』の72ページに書いてあるやつ）のうち、リスト全体の上下のアキを制御する変数がなぜか3種類ある。

• \topsep
• \parskip
• \partopsep

この違いが本を読んでもよくわからない。本の解説によると、\topsepは「最初の項目と続く段落との空き」で、\partopsepは「環境が新しい段落を始める際に、\topsepに追加される余分な空き」で、\parskipにいたっては説明すらない。

経験的に知っていること。

\topsep

本文とリストの上下の余白の高さ。つまり、リストが入れ子になっているような場合には、\topsepの値がどうであろうと内側のリストの上下には余白ができない。

\parskip

リストの上側には、\parskipで指定したぶんだけ余分に空きができるようだ。下側には空きができない。入れ子のリストの内側でも同じ挙動。

\partopsep

リストの上下の余白の高さ。入れ子のリストの内側でも同じように余白ができる。

間違っていたら訂正したいので教えてください。

ついに歯ぐきに穴をあけてインプラントの支柱を埋め込んだ。抜歯は来週。しばらくまともなものが食べられないうえに感染症予防のための抗生剤でぼうっとする。でも明日は出社か。はたらきたくないよう。

奥様は仕事だし自転車にのる気力もない日曜なので、有限状態機械ごっこをしてひまをつぶす。とはいえ、遷移図を睨んでいても頭が弱くてちっとも理解がすすまないので、有限状態機械の動作を模倣する評価機をSICPの第4章を参考にしてつくってみよう。ザ 本末転倒。

(define (q0 input)
  (cond ((= input 0)
         (output 0)
         (transit! q0))
        ((= input 1)
         (output 0)
         (transit! q1))))
(define (q1 input)
  (cond ((= input 0)
         (output 1)
         (transit! q0))
        ((= input 1)
         (output 1)
         (transit! q1))))

(define (output b)
  (display #`"Output: ,b"))
(define (eval-in-current-state input state)
  (state input))
(define current-state q0)
(define (transit! q) (set! current-state q))

(define (fsm-loop)
  (newline)
  (let ((input (read)))
    (let* ((state current-state)
    (output (eval-in-current-state input state)))))
  (fsm-loop))

q0とq1は、いわゆる遅延機械。

gosh> 
(fsm-loop)



1

Output: 0

1

Output: 1

1

Output: 1

1

Output: 1

1

Output: 1

0

Output: 1

0

Output: 0

0

Output: 0

0

Output: 0

1

Output: 0

1

Output: 1

0

Output: 1

1

Output: 0
……

奥様が「お行」のピアノ曲を聞きたがっていた。「お行」ってなんだ、と聞くと、ロロロロロ……とかポポポポポ……とかで擬音化できるような曲だという。一般にピアノの音の擬音化は「ポロロン」みたいな感じなので、だいたいどの曲も「お行」なんじゃないのか? しかし、どうやら違うらしい。僕がいつも聞いているピアノ曲は、彼女にとってキョキョキョキョキョ……とかリリリリリ……なんだと。つまり「い行」か。

とりあえず彼女がイメージ先行で選んできた「お行」のCDはショパン。なんだ、そういうのでいいのか。つまり、比較的耳にやさしい音がほしいってことね。そこでブレンデル先生のモーツァルトのソナタを渡したら、案の定、求めていたものに合致したようだ。彼女の脳でキョとかリに聞こえるのは、きっとナンカロウとかメシアンなんだろう。たしかに鋭い音が跳ねっ返っているような雰囲気が「い行」に聞こえてきたよ。面白いのはドビュッシーなんかも「い行」系列にくくられていること。方法論は独自だけど結果的に納得できるカテゴライズがなされていることに驚く。その後の実験的な推測により、僕が聞きたい音と彼女が求めている音のぎりぎりの交わりは、シューベルトの後期ソナタ付近にありそうだということがわかった。

残念ながらうちには「お行」系列のまっとうなCDがたいへん少ないので、すこし補充するかなあ ← 結局CDが買いたい。

整数からなるリストを、指定した自然数の正値をスタートタグ、負値をクローズタグとみなしてグループにくくりたい。ただし、そのようなグループはリストは入れ子になっているかもしれない。

ようするに、こんなふうな結果を得たい。

gosh> test-list
(2 5 3 0 9 1 9 4 -1 9 4 2 1 0 1 9 -2 -1 5 1 -1 4 -1)
gosh> (group-between test-list 1)
(2 5 3 0 9 (1 9 4 -1) 9 4 2 (1 0 (1 9 -2 -1) 5 (1 -1) 4 -1))

condでグループにくくりながら再帰が基本的な戦略だけど、入れ子になっているかもしれないので工夫が必要になる。これには、一番内側にあるグループをくくり出すという操作を、指定した数がリストの表面に見えなくなるまで再帰すればよさそう。そこで、指定した数の正値が連続したら、いったんグループわけを始めたところに戻ってやり直すようにする。そこで call/cc ですよ。←関係ない（2007/5/18追記）

(define (group-between ls n)
  (define (group-most-inner ls)
    (cond ((null? ls)
            '())
          ((eq? (car ls) n)
           (call/cc
            (lambda (k)
              (let R ((first (list (car ls)))
                      (rest (cdr ls)))
                (cond ((null? rest)
                       (error "pair unmatched" n))
                      ((eq? (car rest) (- 0 n))
                       (k (cons (append first (list (car rest)))
                                (group-most-inner (cdr rest)))))
                      ((eq? (car rest) n)
                       (k (cons (car ls)
                                (group-most-inner (cdr ls)))))
                      (else
                       (R (append first (list (car rest)))
                          (cdr rest))))))))
          (else
           (cons (car ls)
                 (group-most-inner (cdr ls))))))
  (cond ((not (member n ls))
         ls)
        (else
         (group-between (group-most-inner ls) n))))

これを応用して、XMLやHTMLの文書から要素を取り出してくるのに使えそう。構造だけ欲しければsxmlにしてしまえばいいけど、元の文書の「見た目」を変えずに特定の要素だけいじるときには役立つかも。

男性の性欲は男性の自信と関係しているという説を最近きいたけど、ほんと? そういうもっともらしい意見を女性が信じちゃうと、性欲とかどうでもよくてとにかくかわいい女性が大好き、っていう人間が生きにくくなるので困るんですが。


みんな本当は性欲とかどうでもよくて、単純に女性と一緒にいると楽しくて、でも性的ないいわけがないと照れるから、しかたなく風俗とかいくんじゃないのか。風俗にいったことがないので推測しかできないけどさ、女の子どうしできゃっきゃって楽しそうにしてるのが羨ましくて羨ましくて、いっそのこと自分も女の子になって混ざりたいなあっていう男性の本音を歪めて提供するのがエロ産業なのではあるまいか。

自転車のタイヤのバルブカバーを盗まれた。走行に支障はないとはいえ、腹がたつ。この手の犯罪はとにかくたちが悪い。やられ損だ。仮に犯罪が発覚しても犯罪者にとってたいした不利にならない。社会的なリスクも対して大きくないから、倫理感がない限り手を染めるほうが得策なんだろう。古今東西、不条理な大人の制裁がない社会で中高生がいきがるのは、これが理由にちがいない。

ハムラビ法展でさえ、たかだか受けた犯罪と同じ報復（懲罰）しか認めない。これはフェアじゃない。最初に目を潰された被害者のほうは、そもそももともと目なんて潰されたくなかったわけで、たまたま犯罪に合うようなことさえなければ幸せに暮らしていられたはず。一方、目を潰すほうには選択肢がある。相手の目を潰したところで高々自分の目を潰されるだけだから、それを覚悟して犯罪により得られるメリット（遺恨を晴らすとか）のほうが大きければ、犯罪のほうを選択できるわけだ。ずるい。

復讐法で対等に扱うべきなのは犯罪そのものの程度ではなく、犯罪により被る被害の程度であるべきだ。だって、仮に自転車のバルブを盗んだやつが僕の前に現れてバルブを返してくれた上に「俺の自転車のバルブをお前が盗んでもいいぜ」と言ってきたとして、僕はそいつの自転車のバルブなんて全然盗みたくないし、それで僕の今の憤慨とか悔しさはとうてい補填できない。かといって、そこでそいつを殴りつけて今の僕と同等の憤慨を感じさせることに成功しても、それで僕は警察に捕まって刑事裁判を受けて刑に服し、いま以上の不快感を味わうことになる。それじゃあやっぱり不公平だ。どうする?

ポイントは、法律にのっとった刑罰の度合が比較的線形に緩やかに厳しくなるのに対し、僕が相手に与えることが可能な苦痛はより急峻に厳しくできるというところにある。だって、そこでカッとなってそいつを殺害したところで、いまみたいな事情なら極刑にはなりそうもない。つまり、相手を殺害するまで至れば、確実に僕のほうが被害の程度が小さくなる。どのへんに損益分岐点があるかはさだかじゃないけど、妄想ではタコ殴りにして半身不随にするところくらいになる気がする。その程度であれば、こっちも懲役10年程度でかつ残りの一生を棒にふるだろうし、相手も一生を棒にふるだろうから、きっとイーブンだ。被害の程度を平等にするという精神にのっとればそれくらいが妥当だってことだ、ざまみろ。どんな犯罪も、せめてそれくらい殺伐とした覚悟でやってもらいたいものである。

頭に血が登っているので適当なことを書いちゃったけど、「自転車のバルブの盗難」を「家族の傷害事件」とかにしたら、それほどふつーの人情とかけ離れていないような気がしてきた。もし家族がそのへんのガキから傷害事件を被ったら、僕は犯罪者と被害の程度が同じになるようにがんばるかもしれない。

現代音楽は抽象的だといわれることが多い。だからわけがわからんと。確かにそういう面はある。


とりあえず何が現代音楽か定義せずに話をすすめるけど、クラシック音楽のいいところは、作曲家のほかに演奏家という存在がコンテンツのオーソリティーとして認知されていることだと思う。音楽を聴くほうにしてみれば、たとえ作曲家の言っていることが強烈すぎてちんぷんかんぷんでも、あるいは稚拙すぎて退屈でも、演奏家というフィルターを通して楽曲に接することができる。ようするに、どんな曲でも演奏家しだいでコンテンツとして成立できるってことだ。Pollini や Boulez を見れば、ここまではあながち間違っていないはず。ただし彼らの演奏が秀でているのは、それが一般人ウケするようなフィルターだからじゃなくて、譜面を読み込んで忠実な解釈を徹底していることにある。だから楽曲の質が大きく影響しているはずなんだけどつまらない曲もキラキラしちゃうから不思議。閑話休題。


彼らのすごさはおいといて、技術書というコンテンツも同じことが言えなくちゃだめだよなあと思う。譜面と演奏の関係が、原稿と編集の間に成り立つのか、それとももっとメタレベルで技術と書籍の間に成り立つのかは知らない。たぶん両方なんだろう。

call/ccについておまえの知っていることを晒せと脅された。

まずこんな式を考える。

(begin 
  (print "hello")
  (print "goodbye")
  (print "hello again")
  (print "goodbye again"))

この式を評価すると、beginの中の環境で(print ...)という式が上からじゅんばんに評価される。結果的にこう出力される。

=>
hello
goodbye
hello again
goodbye again

Schemeでは、式の1つめの要素をオペレータとみなし、残りをオペランドとみなす。Schemeで式を評価するっていうのは、各オペランドを評価したものを引数として、それらをオペレータに適用することを意味している。

上記の例の(begin ...)という式を評価する場合、beginプロシージャに対してオペランドである(print ...)たちを評価したものが適用される。beginは引数として与えられた式を順番に評価していくプロシージャなので、まずどんな動作をするかというと、「(print "hello")を評価した。これから残りの(print ...)たちをbeginに適用する」。

で、この動作を記録にとっておくことにしよう。具体的にはスタックにつむことにする。

(print "hello")を評価した。これから残りの引数を評価する

同様に次の動作もスタックにつむ。

top    : (print "hello")と(print "goodbye")を評価した。これから残りの引数を評価する
bottom : (print "hello")を評価した。これから残りの引数を評価する

これを繰り返すと、beginの評価が終ったときのスタックの状態はこうなる。

top    : (print "hello")と(print "goodbye")と(print "hello again")と(print "goodbye again")を評価した。最後の式の値を返すよ
         (print "hello")と(print "goodbye")と(print "hello again")を評価した。これから残りの引数を評価する
         (print "hello")と(print "goodbye")を評価した。これから残りの引数を評価する
bottom : (print "hello")を評価した。これから残りの引数を評価する

じつはこの活動記録が「継続」を表している。で、スタックなので通常はいちばん上しか見えないけれど（つまり最後の式の値が返るだけ）、Schemeには途中を捕まえる方法がある。それがcall/cc。

(define c '())
(begin 
  (print "hello")
  (print "goodbye")
  (call/cc
    (lambda (k) (set! c k)))
  (print "hello again")
  (print "goodbye again"))

こうすると、call/ccを仕掛けた場所の継続、つまり、くだんのスタックの下から2番目を捕まえて、あらかじめ適当な値で定義しておいたcに代入できる。けっきょくcには、「(print "hello")と(print "goodbye")を評価した。これから残りの引数を評価する」という継続が代入される。そこでcを評価すれば、cは「これから残りの引数を評価する」つもりでまんまんなので、こうなる。

gosh> (c)
hello again
goodbye again

これを応用すれば、たとえば「(a b a c a d)というリストから、最後のaで始まる部分リスト(a d)を取ってくる」とか、「木構造を探索するのに、途中で分岐した場所から別の枝を探索し直す」とかできる。これらは「途中を忘れて覚えておいた場所からやり直す」という人生やりなおし機型の応用といえる。一方、「とにかくcall/ccを仕掛けた場所に戻れる」という性質を利用すれば、いわゆる局所脱出ができるようになる。具体的な例はディヴィグの本とか"Seasoned Schemer"とかを参照。そもそもこの記事は"Seasoned Schemer"のオレ解釈なわけで。

日本語の疑問文で「それとも」は、 or 条件だと見なしていいだろう。

Cさん：年賀状、出さないですよね？ それとも出しますか？
Kさん：うん

出すか出さないかしかないので、この問題の答えは常に true だ。コードにすれば一目瞭然。

(define send-card? (lambda () #f))  ; 出さないつもりでも……
(or (not (send-card?))
    (send-card?))

=> #t                               ; 答えは「うん」

ところが、実際にはこういう会話が成立する。

Cさん：年賀状、出さないですよね？ それとも出しますか？
Kさん：いや（出さない）

なんで排中率を放棄して false を返しているのか。
それは鳥頭だからであって、ひとつめの質問を忘れちゃってるだけだよね。

(call/cc
  (lambda (k)
    (or (not (send-card?))
        (k (send-card?)))))  ; 忘れた

=> #t                        ; ???

どうして call/cc で脱出せずに #t が返るの？

(define (trace ls)
  (call/cc
   (lambda (skip)
     (let R ((ls ls))
       (cond ((null? ls)
	      '())
	     (else
	      (call/cc
	       (lambda (k)
		 (set! trace (lambda () (k #f)))
		 (skip (car ls))))
	      (R (cdr ls))))))))

本当は好きなものを嫌いと言ってみることでアイデンティティを成立させようとしていた時期があったと思う。

たとえばクラシック音楽への興味は、メジャーな楽曲のメジャーなフレーズへの興味から入って、そのうちマイナーな作品の魅力に気づき、オレだけが知っている的な優越感とともにどんどんマイナーな作家/作品/演奏を指向していって、そのうちメジャーな作家/作品を否定するようになった。このメジャー否定は、小中学校の音楽の時間に超メジャーどころを強制的に視聴させられて感想文を書かされるような体験と調和して増幅した。もう、なんでこんな子どもっぽい曲を聴かなきゃいけないんだ、と。モーツァルト? ヴェーベルンでも聴かせろや。

で、高校生にもなるとクラシックなんかよりハードロックに目覚めるから、モーツァルトもヴェーベルンも忘れさる。モーツァルトを思い出すのはずいぶん年齢を経てからだ。そこで、なんでこれを否定してたんだろうと思って悲しくなる。モーツァルトを否定することで、オレはもっとディープな作品を聴いているんだという優越感を安直に手に入れようとしていたんだろう。

今思い出すと、本当はモーツァルトも好きだった。好きなものを好きと言えるようになるには、たぶんものすごい跳躍が必要だった。どこで飛んだか知らないけど、いまは自分の好き嫌いを社会とのかかわりでとらえなくてすむ場所にいる。生きやすい。

なんで突然こんな個人的なことを書きたくなったかというと、フジテレビで月曜日に放映している「のだめカンタービレ」が楽しくてしかたないから。自意識を一周してきて、ようやくこういうドラマを素直に楽しめるようになったんだなあ。

Allegro Common Lisp 2006 November Seminar (Japanese)。忘れないうちに3日間の印象を殴り書き。

Lispそのものに興味がある人たちと、むしろSemantic Technologyに興味がある人たちがいて、双方にとって有益なセミナーだったと思う。Franz Inc.と数理システムの皆さんには本当に感謝いたします。

いちばん興味深かったのは、Fritz（Franzの創業者）がGoogleに代表されるSyntacticな検索を明確に否定していたこと。非常に慎重な人なので、Googleのビジネスに対して不快感をあらわにしているのが意外だった。

そしてやっぱりAllegroGraphのすごさが印象的。というか、それを開発しているJansのパワーがすごい（懇親会では手羽餃子の油を背広に跳ね飛ばしてしまった。あらためてごめんなさい）。いくら理念的にSemantic Technologiesに利があるといっても、やっぱりRDFトリプルとして記述されたメタデータに対する操作を大規模なアプリケーションにまでスケールさせるのは困難なわけで、そのへんが軽量なスクリプト言語とXMLベースのWeb 2.0が成長した理由のひとつだろう。そういう事情をひっくり返してSemantic TechnologiesをWeb 3.0（そんなものがあるとして）の支柱にする鍵のひとつになりうるのかもしれない。まあ、そんな大仰なことを言わなくても、ふつうにRDBMSよりグラフのほうが直感的なデータベースは多いような気がする。実際、いままさに頭を悩ませている問題として、出版した書籍と著者や訳者とを管理できるようなデータベースがほしい。そんな出版社向けの汎用データベースをAllegroGraphで作るという夢を見た（著者と書籍の間に単純ではない関係があったりするので、ふつうの住所録を作るよりいくぶんたいへん）。

もうひとつの鍵はプレイヤーの数だと思うんだけど、これはちょっと悲観的にならざるをえない。Web 2.0でやっているのはSyntacticなデータから豊饒なWebアプリケーションを大人数でマッシュアップ（これって音楽業界のマーケティング用語じゃなかったの？）すること。Lispベースの技術でそれだけのジャンクなマンパワーを集められるかっていったら、たぶんできない。Lisp以外で同じことが実現できるようになるかっていたら、たぶんすぐにはできない。

でも、それでいいのかも。Fritzの不快感は「なんでもGoogle」という外野の風潮に対するものであって、それで満足する人はそれでいいけど不足があるならぜひ相談してくれ、という話だったんだと思う（かなりバイアスぎみ）。すでにSyntacticなキーワード検索というアプローチの限界が露呈している分野（バイオとIntelligence Agencies）はSemantic Technologiesに目を向けているし、ある程度大規模な組織の内部に閉じたアプリケーションなんかもSemantic Technologiesに目を向ける潜在的な市場になるとふんでいるらしい。まさに昨年のセミナーでは「Lispでなければ解決困難なほど複雑な問題も世の中にはたくさんある」と強調していたけど、その方法論をSemantic Technologiesに絞ってきたんだなあ、という印象だった。

なによりもFranz社は、Lispをビジネスとして成立させることに興味があって頼もしい。Fritzは2日目のパネルディスカッションで、Franz社が最後のLisp企業だと強く自覚しているように見えたけど、それにはすべての聴衆が素朴に好感を持ったと思う。Semantic! Semantic! っていっても、それはやっぱりビジネスマンとしての売り文句で、純粋に美しいテクノロジーが好きなんだろうなあ。

以下はどうでもいい話。

やっぱり懇親会ではSchemerの肩身が狭い。自分のようなTiny Schemerだとなおさら。でも楽しいのはなんでだろう。

いいかげんな英語でもいいから、話をしないとダメだ。

CLOSを勉強しないとダメだ。小出先生の発表で、「CLOS/MOPがメタ-メタ-…-オブジェクトを云々するのはラッセルのパラドクスにつながるから論理屋には絶対に理解できない」みたいな軽口があったけど、あれはどういう話だったんだろう？　それって単純に巨大基数に対応してるんと違う？

『Binary Hacks』のサンプルPDFでは川合史朗さんによる巻頭言が読めて、プロのプログラマにとって抽象化の壁に無自覚でいるのは致命的だ、と主張されている。もちろんこれはBinary Hacksの巻頭言なので、抽象化が下に有界であることを忘れないようにしないといけないよ、という警鐘と受け止めていいんだと思う。ぶっちゃけていえば、土台を固めろ。もしくは、土台を意識できるようになれ。

その手の抽象化の漏れを自覚することの大切さっていうのは、誰かが抽象化したものを使うときの落し穴を自覚することの大切さだといえる。川合さんの文章にある「箱庭の製作者のアイディアを抜ける」ことは、いわば誰かが手がけた抽象化の漏れを自分でふさぐことを指しているんだろう（勝手な解釈だけど）。

一方で現実の問題を解くうえでは、誰かが抽象化したものをてなずけるだけでなく、自分自身で何かしら抽象化っぽいことをしたい。そのときに求められる自覚は、当たり前だけど、『Binary Hacks』の巻頭言で示唆されている自覚とは別ものだ。もちろん、よりエグいレベルからの抽象化を自分でするなら、まさにBinary Hacksが必要になるんだろう。ただし、たとえばぼくにとっては『Binary Hacks』で扱っているような題材はとうてい自分の力だけでゼロから抽象化できるしろものじゃない。

もっとかわいらしい抽象化のためのHacksも欲しい。「箱庭の箱庭の箱庭を別の屋敷の箱庭にコピーして、さらにその中に自分で箱庭を作るときに抽象化を漏らしにくくするHacks」みたいなの。ちゃちな問題であっても抽象化っていうのはやっぱり強力なので、その無自覚に享受しがちなパワーに目がくらんで掘りがちな落とし穴は何か。そもそも落とし穴を作らないためのHacksは？

たぶん、それは数学なんだと思う。ふだん僕らは、直観的に確からしいと思ってあるアイデアをコーディングし、期待する答えが得られた時点で問題を解いたものとみなしている。問題を解くアプローチや道具を手に入れたところで満足しちゃっている。そのアプローチや道具が本当に適切なのかどうかを確かめるには数学しかない。

ありがちな例はハノイの塔だろう。ハノイの塔の解法を説明した記事は、数学っぽいおはなしでもよく目にする。「一番下の1枚だけ残して隣の棒に移動し、一番下の1枚をあまっている棒に移動して、移動しておいた残りをその上に移動しなきゃいけない」という説明。そんなふうな説明から「n 枚のディスクを移動するのにかかる工数を H(n) とすると、 H(n) = H(n-1) + 1 + H(n-1) 」という関係を導いてくる。1枚ずつディスクを移動するって操作を抽象化して考えることで問題の構造が見えてくるよね、みたいな。でもそれだけだと、どんなに工数がかかったとしてもそれくらいには抑えられるってことしかわかりませんから。もっと少ない方法があるかもしれない。

もちろん実際にはない。ただし、それは数学的帰納法で証明して、はじめて「ない」と断言できる。そして道具や解法の抽象化は、どこまでいっても具体的な事物が対象だからではなく、たぶんこういうところからのほうが漏れやすい。たぶん。

こういう抽象化を漏らさないための数学について、楽しい教科書がないものかなあと思う。ちょうど、深いところに抽象化された部分について『Binary Hacks』が果たすであろう役割に相当するような本が。数学の楽しいところや神秘的に見えちゃうところを取り上げて『Math Hacks』とかっていう方向もあるだろうけど、それは答えじゃないと思っている。むしろ、普通の数学と同等の内容を持つ教科書をプログラマ向けに企画することが直接の答えのひとつだと思っていたし、いまでも思っている。

あるいは、ここ1〜2年くらいだけど、 "SICP" や "Concrete Mathematics" こそがそういう本に違いないという確信も持つようになった（上のハノイの塔の落とし穴も"Concrete Mathematics"の冒頭で取り上げられている例がそのまんま）。つまり、抽象化することのパワーを解説や練習問題をとおして読者に伝えるような本で、しかも直観だけでなく数学的に証明可能な抽象化の道を示しているような本（証明が書き下されている必要はない。分かっていて省略するのと結果的に省略されちゃってるのは別）。しかも、"SICP" や "Concrete Mathematics" よりもっとミニマルな内容におさえたとっつきやすい本にできるはず。←いまこのへん

まあ、本があるだけじゃだめで、手を動かして訓練しないスキルは決して身につかないんですがね。数学に限らず。

部分から全体を推測することが統計の本質というより、全体がいい具合に推測できるように適切な部分を取り出したいというのが統計の本質なんだと思っていた。その際、全体については「何らかの確率分布にしたがう」という仮定を設定するので、その仮定が妥当である限り、おれカネゴンさんのような心配は不要なはず。もちろん、これは統計というものの全体についていえる話ではなくて、統計的推測といわれているものについての話です。

なんかよく分からないけど取ってきちゃった部分から全体を推測しようとする統計もある。その傾向が強くなるほど、数学とは離れたものになっていくような気がする。そういう需要もあるのでそういう分野もあり、やはり統計と名乗っているので、統計の教科書にのっているから数学により正しいことが保障されるといった妄想は妄想です。全体の傾向を分析するひとつの手段としてはありえると思うので批判したりするつもりはありません。

なんか、ちっとも確からしさのない脊髄反射的な文章になってしまい申し訳ありません。

0.999...は1かっていうのは、ゆっくり慎重に考えれば解けるクイズのような問題ではないし、定義でもないと思う。もちろん哲学でもない。とはいえ、哲学っていうのがいちばんしっくりくる表現なのかもしれないやね。「哲学が何か」なんて知る由もありませんが、雰囲気として。だって、ようするにそれを納得するかどうかだけがポイントだと思うから。定義なんだから納得しろっていう話じゃないよ。それなりに数学を勉強して経験していくと、そのうち、そう考えざるを得なくなるってこと。

虚数の概念とかもそう。虚（imaginary）という字面や、一方で「実」数という概念があったりするから混乱を引き起こしやすいと思うんだけど、別に虚数は空想上のモノでもなんでもない。虚数のimaginaryっぷりは、実数のimaginaryといい勝負だと思う。逆に言うと（逆だよね）、実数とかいっても名前ほどにはrealじゃなくて、たとえばπの実在っぷりを2次元アイドルの実在っぷり以上に強烈に感じられる人はすごいと思う。もういっかい逆に言うと、いろいろな場面で必然的に虚数が現れるのを目の当たりにすれば、そのうち必要に応じた虚数のrealさを納得できるようになるのではあるまいかと。

確かに、いつまでたっても納得できない人はいる。でもそれって、頭の良し悪しとかじゃなくって、単に納得したくないだけなんじゃないだろうか。あとは、訓練が足りないか。ある概念について納得するっていうのは、その概念を提示している記号の字面と日常的な正しさの感覚だけで到達できるような態度じゃないから、ある程度の努力とか歩み寄りは必要だと思う。

校正待ちですることがないので（後半はうそ）、Code Golf の "Switchboard" という問題に手をつけてみた。コードを短くすることはともかく、この問題は解法を考えるのが面白かった。いまのところ23位だけど、これが個人的なスキルの限界だと思う。

Scheme は受け付けてない。そうとはしらず最初は暢気に Scheme で書いたことはいうまでもない。しょうがないので Ruby で書き直したんだけど、"gets" だけで標準入力から1行読み取れるなんて。実用的にもほどがある。

おいしいとんかつの店は三河島の「山き（きは「七」を森のように重ねた字）」だよ！ このへん
どうもあんまり知られてないようなので、叫んでおく。

ヒレがびっくり。とんかつといえばロースだと信じてたのに、その常識を覆された。あと、メンチ。ヒレもメンチもそれまでどっちかっていうとバカにしていた料理だったけど、本当にごめんなさい。もちろんロースもうまい。
ただ、メニューが少ないし、キャベツに対する選択肢がソースしかないので、軟弱な人にはおすすめしない。地元ゆえのひいき目っていうのもある。それでも、普通の豚を普通のとんかつとして硬派に堪能したいなら、絶対におすすめ。普通なのに、軽くびっくりするんだよね。外食にはびっくりが必要だと思う。しみじみうまいだけなら家で食うさ。

店内の色紙によると、阿佐谷の「かつ源」という店からのれんわけしたようだ。あんまり知られてなくて、いつも暇そうにしているので、ちょと応援したい。