今年は喪中ということもあって静かな年末だった。っていうか、ここ数十年、年末年始は初日の出を名目にして九十九里浜で焚火に耽っていたのに、今年は中心人物の一人が結婚して実家に帰ってしまったから静かなんだ。本人は否定すると思うけど。みんな大人になるとなかなか遊んでくれなくなるわけか。

なにはともあれ、遊び相手といったら彼だ。



なんで、こんなにいい男にいい相手がいないんだろう。

文字どおり十年ぶりに野球をした。大人はたまにキャッチボールをすべきだと思った。

体調（≒モチベーション）がようやく戻ってきた。体調（≒モチベーション）がもっとも悪影響するのは、人間のタスクスイッチだろう。少しくらい体調（≒モチベーション）が低下していても、ルーチン仕事はできますよ、でも、次々と要求とリソースが変化するような仕事の能率は極端に落ちる。

ところで、仕事で使っている簡単なテキストフィルタを Gauche で書き直し始めた（もとは、ほとんど Ruby 製）。こっちのほうが、メンテナンスのコスト（主にモチベーションの維持にかかるコスト）が低そうだから。
あと、ポートやモジュールやマクロのような、どちらかというと非SICPちっくな技術に対する練習も織り交ぜてみるのがねらい。マクロって、こんな場面でこんなふうに使うもの？

(define-syntax tag-case
  (syntax-rules (else)
    ((_ e0 (else e2 e3 ...)) (begin e2 e3 ...))
    ((_ e0 (e1 e2 e3 ...)) (if (equal? e0 e1) (begin e2 e3 ...)))
    ((_ e0 (e1 e2 e3 ...) c1 c2 ...)
     (if (equal? e0 e1) (begin e2 e3 ...) (tag-case e0 c1 c2 ...)))))

(define (tagged-line-filter tagged-line)
  (let ((tag (car tagged-line))
        (str (cadr tagged-line)))
    (tag-case tag
              ('column    (column-filter str))
              ('verbatim  (verbatim-filter str))
              ('table     (table-filter str))
              ('numbered  (numbered-filter str))
              ('itemized  (itemized-filter str))
              ('enumerate (enumerate-filter str))
              (else       (default-filter str)))))

ディヴィグ本だけだと、実用する、という側面がぴんとこない。やっぱり On Lisp か。はやく本にならないかなあ。


時間ないなあ。

ひさしぶりにトプカでたくさん飲み食いした。たぶん今年最後の夜トプカだろう。一年間お世話になりました。そして、なおさんのプロ意識には学ぶところが多すぎ。

いまさらだけど、統計ブームだよなあ。

ところで数学には2種類あって、役に立ちやすいのと、そうじゃないの（全然役に立たないやつは、ない）。統計は、限られたデータから全体の傾向について言及するときにウソをつかないようにする方法なので、バリバリの前者である。某新聞の一面がウソをつきやすいのは、統計ではなく経験や思想でモノを言いたがるからだ。ウソをつかれて、すました顔をされるのは心外なので、統計的な常識が世間の常識になってほしい。正確に言うと、統計的な常識には数学的な裏づけがあるものだということが常識になってほしい。
でも、経験や思想で（だけで）モノを言いたがる人には、「数学的」であるということの肝は伝わらないんだよなあ。数字で世の中を説明できるなんて思い上がってんじゃねえ若造が、とでも言いたげな顔で嘲笑される。数学では数字はあつかわないんだけど、説明するのもめんどくさい。ディスコミュニケーション。
とはいえ、統計の教科書だけを読んでると、確かに数字（と数式）だけで世の中を説明しているような印象をうけがち。実際、実験とか調査でデータを集めて魔法の手順や数式に当てはめれば、はいできあがり、というスタイルの統計の入門書も少なくないと思う。どういう場合にどういう手順や数式が使えるか、という情報も、ノウハウとして必要ではあるけれど、それはあくまでも「すでに数学的な正しさを正しいと納得できる人」向けの情報だよ。そうでない人、例えば、「最初の状態と状態を更新するルールが決まってれば、永遠の向こうで状態がどうなっているか断言できる」という話を納得できない人は、たくさんいる。「天気予報なんていい加減のきわみだ」と根拠なく主張する人がいっぱいいる。ところが、今日の天気が晴れであり、この惑星で晴れの日の翌日が晴れの確率はきっかり90%、雨の日の翌日が雨の確率はきっかり50%であるとわかっているなら、明日の天気が晴れの確率はだいたい86%だと断言できるし、それは数学的に正しい。
この天気予報の例は、Wikipediaの Examples of markov chain から取ってきた（計算めんどくさかったんで）。これを信じて晴れの日の翌日に雨が降ったら、最初に仮定した90%と50%という確率については疑ってもいい。しかし、86%が導き出されるプロセスには疑うところがない。この、疑うところがない、というのがポイントで、疑うところと疑わないところを見分けるために数学を学ぶべきだといっても過言ではないと思う。つまり、本当に学ぶべきは、統計で用いられる手順や数式ではなく、そこへいたる数学的な抽象化のプロセスだと思うわけ。
にしては、確率論って統計に比べてさげすまれてない？　統計という、数学的確からしさでデータを判断する考え方に触れる前には、数学的確からしさを納得できるだけの素養が必要で、それには確率を、「事象÷母数」みたいな素朴な認識を越えて理解しておく必要があるんじゃないだろうか。

とはいえ、かくいう自分も、10年前に勉強したことなんてぽろぽろ忘れている。そこで、確率を扱う Scheme のプロシージャでも書いてみようと思い出した。

probability.scm

例えばサイコロを1個ふるという単純すぎるイベントの確率空間は、このように作る。

(define dice6
  (make-probability-space
   (list 1 2 3 4 5 6)
   (lambda (w) (/ 1 6))))

dice6
=>
((1 . 0.16666666666666666) (2 . 0.16666666666666666) (3 . 0.16666666666666666) 
(4 . 0.16666666666666666) (5 . 0.16666666666666666) (6 . 0.16666666666666666))

こんな例でも、確率変数という考え方の便利さは感じられる。出た目が偶数かどうかを考えるとしよう。目が偶数かどうかは、ω∊{1,2,3,4,5,6}上のf(ω) = 0 or 1（0: 奇数, 1: 偶数）という確率変数f(ω)として表現できる。これを、Scheme のプロシージャとしてそのまま書くと、こんな感じ（「even-pv」の pv は、probability variable の気持ち）。

(define (even-pv w)
  (if (even? w) 1 0))

サイコロをふって偶数の目が出る確率は、直感では 0.5 のはず。これは、この even-pv という確率変数から、実際に以下のように導かれる（一般に確率変数は確率分布関数（離散の場合は確率空間だと思っていい）を導く）。

((lead-distribution even-pv) dice6)

=> ((0 . 0.5) (1 . 0.5))

平均や分散といった統計でおなじみの概念も、確率変数（確率空間）から導かれる。例えば分散はこんな感じ。

(variance dice6)

=> 2.9166666666666665

(variance ((lead-distribution even-pv) dice6))

=> 0.25

メモ

• まずは離散確率分布
  • 測度とか気にしなくて済む
  • 離散では確率空間≒確率分布だと思っていい
  • 積分より総和のほうがプロシージャを書きやすい
• 確率変数という考え方がポイント
  • 確率変数から確率分布が導かれる
  • 確率変数から平均や分散が導かれる
  • 確率変数は環をなす

SICPの2.4項では、複素数を扱うプロシージャをもりもり作る例を説明している。複素数には、直行座標で表現する方法(実部と虚部のペア)と、極座標で表現する方法(ノルムと偏角のペア)があるけど、複素数どうしの和なら直行座標のほうが扱いやすいし、積なら極座標のほうが扱いやすい(積をとるっていうのは回転しながら延び縮みすることだから)。そんなわけで、どっちかの表現だけでなく、両方の表現で扱えるようにしたい。
このように表現の仕方が何通りかあるデータを扱うには、一般にいくつかのやり方がある。一番単純なのは、各データ表現ごとに衝突しないような名前を付けて、かたっぱしからプロシージャを定義していく方法。しかしこの方法では、あるデータがどの表現を意図しているのかをつねに人間が意識していなければならない。そこで、もうちょっと進んだ方法として、データにタグを付けることにする。こうすれば、タグに応じて異なる処理をするようにプロシージャを定義したり、都合がいいような表現に変換してから処理をするようにプロシージャを定義したりできる。
もっと上手いやり方は、2.4.3で説明している Data-Directed Programing という考え方である。これは、データ表現ごとに都合がいいように定義したプロシージャを集めて、それをテーブルとして管理するという方法である。そして、必要なプロシージャは、このテーブルから取ってきて使う。この方法が単純なタグを付ける方法に比べて優れているのは、それぞれの表現ごとにプロシージャの名前を区別しなきゃいけないとか、データの形式を統一しなければいけないといった心配なく、ざくざくとプロシージャを生み出せる点である。そのため、多人数での開発も容易になるし、そもそも不統一な形式で表現されているデータを一括して扱うこともできるようになる。

そうだったのかあ。何人かで並行して開発するとか、データ横断的な処理を定義するっていうのは、こういうことだったのかあ。面白い。面白すぎるよ、SICP。

しかし、2.4.3 だけでは、肝心のテーブルの扱い方はわからないのでした。「Section 3.3.3 でわかるだろう」って、そりゃないよ。3.3.3 まで読み進むのに何週間かかるとおもってんだ。Exercise 2.73 以降が解けないじゃん。

とりあえず "The Little Schemer" の Chapter 10 を参考に、この節でテーブルへのデータやりとりに使われている put と get というプロシージャを模倣するプロシージャを作ってみた。

naive-get-put.scm

とりあえず、とりあえず。

喜ばしい

* "Joel on Software" の見本ができた
* PHSに待ち受け画面というものを設定してみた

これの3コマ目。

気が抜けたせいか、今週は6:30くらいまで起きられない日が多かった。そこで思い切っておかいもの。

National 生体リズム 光・めざましシーリング ASSA 洋風シーリングライト LBP58530K::
http://www.amazon.co.jp/exec/obidos/ASIN/B0000C9IYJ/

これで4:00起きの生活がいっそう定着できる。

配送されるのは来週末なんだけど、ようやく我が家の全室(といっても2部屋)に照明が設置されることになる。もう入居して5年になるってのにね。再来週からは、今まで居間兼寝室だけにあった照明を別の部屋に移設し、居間兼寝室の照明として、この目覚しライトを使用することにしようと思う。

ちなみに、上記のリンク先はAmazonだけど、ヨドバシカメラのポイントのみで入手した。だから、一昨日出たボーナスでは、さらに別なものを買えるよ。

今日の楽しかったこと

* 横浜トリエンナーレ2005

9月に入ってからちっとも余裕がなくて、ずっと行きそびれていた 横浜トリエンナーレ2005 。いよいよ閉幕が近くなったので、天気の良い日を見計らって出かけてきた。なにせ天気が良くないと、エントランスの紅白旗パタパタ（これもダニエル・ビュランの作品）がオモシロさ半分だから。今日は空も青かったし、風もそこそこあったので、かなり好条件だったと思う。





ダニエル・ビュラン以外に、特に個人的に楽しめた作品は次の2つ。作品名は忘れた。まあ、作品名はどうでもいいでしょ。

• 暗闇で青やオレンジ色に光るブランコ
  （ヴォルフガング・ヴィンター & べルトルト・ホルベルト）


実際に乗ることができる。座るところ全体が着色した透明のアクリル（ガラス？）で滑らかに造詣されていて、視覚の上での幻惑的な雰囲気だけでなく、乗って遊んでも心地よい。この写真みたいなブランコが4台、夜の移動サーカスみたいな会場に展示されている感じ。係のお姉さんはいるけど、基本的にどう遊んでも文句は言われない（独占するなど、ほかの人の迷惑になる行為は別）。5分くらい並んだけど、ネズミーランドの666倍は面白いので、2回も遊んでしまいました。押し付けられ管理されるのではない、本当に楽しいインタラクティブな作品だった。



• 2つの倉庫を結ぶワイヤーを綱渡りする動物たち
  （マーリア・ヴィルッカラ）


基本的には、ここにある写真と同じものだったと思う。気が付かないと、気が付かない。さりげなく完成度が高いのがいい。

ほかにも面白い作品がたくさんあった。できればもう一回くらい、じっくり見に行きたかったかな。ちなみに12月18日まで。

日替わりハピー

* Tさんと久しぶりにタマリンドにいって、タイカレーを食べたら、予想外にうまかった。昔みたいにご飯がぺちゃぺちゃじゃなかったのが、とくに。
* "Little Schemer" の Chapter 9 が飲み込めた。

で、"Little Schemer" の Chapter 9 は Y-combinator の話題なんだけど、「おまえら名前を付けずに再帰できるか？」という問いからスタートする説明はとても面白かった。で、Web をあちこち見てたら、Y-combinator について「名前を使わずに関数を再帰するための仕組み」だとして説明しているページがあった。そう言っちゃうのは、微妙に誤解だろ……（この本の影響じゃないと信じたい。）

僕自身の古い記憶と（いちおう数学基礎論が専門だった）、いまあちこち調べた部分をまとめると、Church って人が1階の記号論理体系におけるアルゴリズムの決定性を検証するのにλ算法ってのを発明して、それは基本的に変数の名前を置換したり関数を適用するだけで任意のアルゴリズムを定義するような仕組みなんだけど、そこで再帰的なアルゴリズムを定義するための道具として Y-combinator などの「適用しても関数を変化させない」ような関数を作ったって話（勘違いしていたら教えてください）。どうでもいいけど、そんな Y-combinator が話題として盛り上がっちゃうのは、それが Paul Graham の会社の名前であることと関係ないわけがない。

で、僕自身は、それが現実的にどんなアプリケーションで何の役にたつのかは知らない。動くコードとして見たのも、はずかしながら "Little Schemer" が初めて（基礎論の凡人はコンピュータなんて使わないんです！）。それでさらに調べてたら、Y-combinator は memoization に役立つみたいな話を発見。

Y overriding self-application ：
http://okmij.org/ftp/Computation/overriding-selfapplication.html

memoization かあ。年内には SICP の Chapter 3 に入りたいなあ。

数日前に読了した『ケルベロス第五の首』が重版していたらしい。草葉の陰からおめでとうございます。

訳者の柳下さんの日記（11/17に記載）
http://www.ltokyo.com/yanasita/diary/04112.html

日記を見ると、かなり重版修正が入っているもよう。そうなのかあ。いろんな意味で複雑だ（重版で修正って、読者の視点からすると複雑な心境であることを再確認）。それにしても、どこがそんなに変わったんだろう。明らかな翻訳ミスなのか、それとも表現に磨きをかけているのか。複雑な作品だけに、なんとか差分をWebに掲載してもらえるとうれしいんだけど……（それとも、すでに掲載されてる？）

状況
* hisashim：On Lisp を読んでいるところ
* shikano：ANSI Common Lisp を読んでいるところ

hisashim：mapcan おもしろいよな
shikano：破壊的ですよ
hisashim：いいんだよ、zip のフラットなのができるから

ANSI Common Lispの100ページ（日本語訳のほう）には、mapcanの定義が載っている。

(compose (curry #'apply #'nconc) #'mapcar)

mapcan が破壊的なのは、nconc が破壊的だからだと思うんだけど、だったら nconc を append にすれば、非破壊型の mapcan ができるの？

(define (my-mapcan fn . ls) 
  (apply append (apply map fn ls)))

最後のは Scheme だけど、まあ想定どおりに動く。

さすがに毎日SICPばかりだと飽きるので、ちょっと気分転換に、ずいぶん前に挫折した問題に再挑戦してみる。問題は、8行×9列のマスに、下のようなクエスチョンマーク型の図形を9個描くというもの。

 ## 
  #
 ##
 #

 #

出展は、すぐ遊べるオンラインパズルというサイトで紹介されていた「九個の？」
http://www.geocities.jp/haayaa2000/puzzle/packing/nine_q.html

クエスチョンマークは90度ずつ回転して使ってもいいし、裏返しにして使ってもいい。つまり、以下の8種類の図形を、互いに重ならないように、8×9のフィールドに9個配置するパターンを探索する。

 ##   ##   #     #   ###         ###
  #   #              # ## #   # ## #
 ##   ##   #     #   
 #     #   ##   ##        
            #   #    # ## #   # ## #
 #     #   ##   ##   ###         ###

戦略としては、まず左から右に向かって各行を連結し、フィールドを 0~71 の整数からなる1次元のリストと見なす。そして、0~71 の整数を7つ組み合わせたリストとして、1つのクエスチョンマークを定義する。たとえば、上の8つうち、いちばん左のクエスチョンマークをフィールドの一番左上のマスから描き始めたパターンは、(0 1 10 18 19 27 45) と定義できる。とうぜん、あらゆる 7つの整数の組み合わせがクエスチョンマークを形作れるわけじゃないし、フィールドをはみ出すこともできないから、このフィールド上に描くことが可能なクエスチョンマーク（つまり長さ 7 のリスト）の種類は限られる。そこで、フィールド上でクエスチョンマークとして可能なリストをすべて洗い出し、そこから互いに交わらない 9 つのリストを取り出してくることができれば、問題がとけたことになる。

以前は Python でこの問題に挑戦していて、その時点で前半の「可能なクエスチョンマークをすべて洗い出す」ところまではすんなり解決していた。しかし、そのときは、その集合のなかから互いに交わらない 9 つの組み合わせを得る現実的でスマートな方法がわからなくて、挫してしまっていた。無謀にも、とりあえず9つの組み合わせをすべて求めてからfilterしようとしたりもしたんだけど、せいぜい4つの組み合わせを求めるまでが600Hz/512MのEDENマシンには限界だったようで、それ以上は仮想メモリもすべて枯渇して永遠に計算が進まず……むー（ちなみに、可能なクエスチョンマークは全部で208パターンある）。組み合わせを作り出しつつfilterするようにすれば、時間はかかってもとにかく解くことはできるだろうなあと妄想しつつ、get-combination を定義したりもしてみたんだけど。

いまになって再挑戦する気になったのは、Gaucheに combination-fo-each というプロシージャが用意されていたから。9つのクエスチョンマークの組み合わせを得つつ、それらが互いに交わらないか調べるのには、こんな get-distinct-n プロシージャを用意すればいいはず。

(define (distinct? sets)
  (= (length (apply lset-union = sets))
     (* (length sets) (length (car sets)))))

(define (get-distinct-n set n)
  (combinations-for-each 
   (lambda (s) 
     (if (distinct? s)
         (begin (display s) (newline))))
   set
   n))

可能なクエスチョンマークの集合を valid-list とすれば、

(get-distict-n valid-list 9)

あとは、計算が終わるのを気長にまちつつ、ぶログチェックでもしていればいいはず。ガーベジコレクションばんざい！



ただし、まだ計算終わってないので、結果は未確認。

ひとに仕事をお願いするときに最も難しいことのひとつは、「ダメな成果物をダメと伝えること」である。いまさら感が漂う標語だけど、ちょっと熟慮すれば、一言で片付けられる話でもないことがわかる。だから、たとえば後輩に、「ひとに仕事をお願いするときは、ダメなものをダメって言わなきゃダメだよ」みたいなことだけを言って悦に入っていても、得られる結果は少ない。むしろ、混乱や間違った結果を生みかねないだろう。

まず、「ダメな成果物」の定義があいまい。仕事を頼んだ相手がこちらの依頼に従わなかった場合は、「要求に従っていない」ことをもって「ダメ」を定義できる。ところが現実には、こちらの要求を明白に示せない仕事を依頼することが多い。そもそも、要求を明白に指示できる仕事なら、ひとに頼まない。自分で（コンピュータや機械を使って）やるか、さもなければ、出来合いのモノやサービスを利用すれば用が足りる。それ以外の仕事は、すべて明白に要求を示せない仕事だ。暗殺みたいな仕事のことはよく知らない。でも、「Aさんをやってほしい」とだけ依頼されて、勢いでたまたま傍らにいたBさんもやってしまい、しかも依頼主としてはBさんは別に殺してほしくなかった（深刻に困るわけじゃないけど）……みたいな状況で、依頼主から「オマエの仕事は中途半端だな」といってダメ出しされることは、暗殺者としての職業倫理にはどう響くんだろう？　
この例は、そんなに特殊じゃない。依頼する仕事が、製品やパッケージのデザインとか、コンサルとかリサーチとかシステム設計とかだったら、これと同じような場面がありえる。依頼するドメインに精通していないからコストをかけて外部に依頼するんだけど、精通していないドメインの仕事について明白な要求ができるか？ 本当は、依頼される側が、そのことを十分に承知しているべきなのかもしれない。

なんか話が散乱してきたけど、要するに、「ダメな成果物をダメと伝えること」という標語の複雑さの最初の困難は、本来は自分のドメインにない相手の仕事の何をもってダメとみなすかの見極めだといえる。

方法は三つある。一つ目の方法は、相手にダメ出しをする前に、自分が要求を明白に示さなかったことを後ろめたく思うこと。そして、表現できない不満を抱えたまま、相手の仕事を受け入れる。個人的な意見だけど、この方法には震度5以上で倒壊する恐れのあるマンションに入居する可能性があるため、おすすめできない。自分がダメという代わりに、いよいよまずくなってきてから周囲にダメ出しをしてもらう方法ともいえる。実は一番採用されている方法である。
二つ目の方法は、ダメ出しのためにダメ出しをすること。オレがダメだっていってるんだ文句あっか。ありませんので、以降のお付き合いはひかえさせていただきます。
三つ目は、僕にはこれしか思いつかないんだけど、相手に見合った対価を背負った上でダメということ。直接的に金銭を払うことも含むけど、それだけじゃなくて、「ダメ」が相手にとって意味あるようにすること。そうすれば、これはオレにとってダメなだけじゃなく、（オレにとってとは意味合いが違うかもしれないが）オマエにとってもダメであると納得させられるかもしれない。そのためには、相手が相手の仕事で果たしているのと少なくとも同程度の意義を、自分自身の仕事で持たなければならない。それが相手へのダメの説明につながる。ことが多い。相手のドメインにおける相手のスキルを自分が尊重し、自分のドメインにおける自分の立場やスキルを相手に尊重してもらい、相手の考えを尊重し、自分の考えを相手に尊重してもらうこと。「ダメな成果物をダメと伝える」には、実はこれだけの下地がなくてはいけなくて、その覚悟がなければ、黙って相手が一発でイイ仕事をしてくれることに期待するか、そもそも何もせず座っているしかない。

「ケルベロス第五の首」（ジーン・ウルフ 著, 柳下 毅一郎 翻訳）

帯には、「三つの中篇が複雑に交錯して織り成す謎と真実のタペストリー」って書いてある。これは嘘だと思ったほうがいいと思った。確かに、各部単位で読んでも、ひきずりこまれるような魅力がある。しかし、各部だけを読んだときの面白さが、全体を通して読んだときの面白さの1/3未満であるという理由で、これは長編だ。第三部にあたる「V.R.T」にいたって、それも250ページ目くらいから急激に、第一部と第二部で無造作に放置されていた設定がざくざくはまり出す。第一部と第二部は、それぞれ異なる文体ながら、いずれも丁寧に読むことを強いられる表現で埋め尽くされている。それを読み解いていく作業に伴うストレスが、自然と脳に作品世界のイメージをこびり付かせるんだけど、そうやって第一部と第二部を通じて自分自身がでっちあげたサント・アテナとサント・クレアという惑星系のイメージが、第三部のコラージュ的な記述にきれいに符合したり、あるいは欺かれてたことに気づいたりするのが、快感。その快感を、ひとつの作品としてうまく演出してある。ゆえに、ひとつの長編。
ただし、ほとんどの伏線は、第三部を読んでも、さらにいかようにも解釈できる。たとえば僕は、サント・アテナは地球からの侵略（という表現が適切かどうかはわからない）を二回迎えていると解釈したけど、もしかしたら事実は違うのかもしれない。事実があればね。そういう意味では、デビット・リンチみたいな伏線-回答の関係なのだといっていいと思う（もちろん、ジーン・ウルフのほうが前だけど）。

にしても、やっぱり国書刊行会は期待を裏切らないな。国書刊行会の本を買ったのなんて、何年ぶりだろう（そんな個人的な感傷はおいとけ）。

空耳アワーで Lisa Exdahl が！

出会いは奇なり。

昨日はうそを書いていました。
えたいの知れないリストから、どこにあるか分からないアトム（アトムって、実際にはあんまり使わない用語だね）を取り去る deep-rember というプロシージャを勢いで定義してみたんだけど、そんなに簡単な話じゃなかったようです。というわけで、訂正。

(define (deep-rember item list)
  (cond ((null? list) '())
        ((not (pair? (car list)))
         (if (equal? item (car list))
             (cdr list)
             (cons (car list) (deep-rember item (cdr list)))))
        (else
         (if (equal? item (caar list))
             (append (cdar list) (cdr list))
             (if (not (pair? (caar list)))
                 (cons (caar list) (deep-rember item (cons (cdar list) (cdr list))))
                 (deep-rember item
                               (append (caar list) (cdar list) (cdr list))))))))

こんなふうな結果が得られる（昨日の定義では、末尾の3が残ってしまう）。

gosh> (deep-rember 3 '(2 (1 4 ((((6))))) (3)))
(2 1 4 6 ())

リスト同士を繋ぐときに append を使っているのは、deep-rember の結果として得られるリストにできるだけ nil を残さないため。nil があると、昨日定義した deep-equal? で、null? を終端条件に使えない。
にしても、もうちょっと整理できないものか。

samefringe problem

Wilikiの shiroさんのところ でも、2005/11/15 に紹介されている。っていうか、そこで知った。

fringeや継続は使わないとして、与えられたリストをもぐもぐ下へ降りていきつつ、左から同値を検証していくのはどうだろう？　つまり、こんな感じ。

(define (deep-equal? list1 list2)
  (cond ((and (null? list1) (null? list2)) #t)
        ((equal? (deep-car list1) (deep-car list2))
         (deep-equal? (deep-rember (deep-car list1) list1) 
                      (deep-rember (deep-car list2) list2)))
        (else #f)))

deep-car と deep-rember は、勢いで定義すれば、例えば以下のように実現できる。もとのリストたちの構造を破壊しながらたどっていくのはご愛嬌。

(define (deep-car list)
  (cond ((null? list) '())
        ((not (pair? (car list))) (car list))
        ((null? (car list)) (deep-car (cdr list)))
        (else (deep-car (car list)))))

(define (deep-rember item list)
  (cond ((null? list) '())
        ((not (pair? (car list)))
         (if (equal? item (car list))
             (cdr list)
             (cons (car list) (deep-rember item (cdr list)))))
        ((null? (car list))
         (list (car list) (deep-rember item (cdr list))))
        (else 
         (if (equal? (deep-rember item (car list)) (car list))
             (append (car list) (deep-rember item (cdr list)))
             (append (deep-rember item (car list)) (cdr list))))))

（せめて(car list)くらいはローカルにバインドしようと思った……）

追記（2005/11/25）
間違っていたので、上記の deep-rember は修正。

SICPの図形言語



ようやくここまでたどり着いた。ひとつの通過点としてコードも晒しちゃう。大きくすると手がつながってないけど気にしない。

この図形言語が取り上げられている2.2.4項は、練習問題そのものは難しくない。たぶん、実際にグラフィックを描く面倒さを乗り越えることと、低レベルから高レベルまできっちり抽象化が分離されていることを味わうところがみそなんだと思った。

グラフィックを描く面倒さは、Gauche の OpenGL ライブラリがなければ乗り越えられなかったはず。着手したときは実際に図形を描かずに妥協するつもりでいたこともあって、segments をリストとして吐き出し、その segments のリストを OpenGL で描画しているだけのお気楽な実装です。したがって、SICP の説明に完全に準じたコードではありません。また、ベースになっている人型の図形（なんで wave なんだろう?）や繰り返しの回数もコードに埋め込んだ状態なので、別のものに取り替えたり、はじっこのへげへげのところをいっそう細かくしたかったりする場合は、コードに直接手を付ける必要があります。教科書の例題なので、むしろソースをコピペしてさくっと実行できるほうがいいと考えました。うそです。OpenGL は何度遊んでみてもかんどころがわからないので、gauche-gl のリファレンスマニュアルで紹介されている例をそのまま使わせていただいたんですが、その描画している部分をうまく分離できなかったというのが本当の理由です。

昨日と一昨日、Franz社と数理システムが主催のLispセミナーイベントで見聞きしたこと。
ただし、セミナーの要約ではなく、Franz社や数理システムの方と直接歓談する機会があって、そのときに伺った話を含めて自分勝手に都合よく解釈したもの。彼らが直接語った言葉ではないので注意してください。


JavaとRDBMSが有用なのは、やっぱり、金銭管理とか人管理とか在庫管理とか注文管理とかスケジュール管理とか、とにかくそういう「エンタープライズ」と呼ばれる領域だけらしい。現在のソフトウェア産業の中心は、その領域におけるソリューションを提供（提唱?）する行為で成り立っている。すくなくとも、そのように見える。そういうソリューションを提供するビジネスが実体以上に過大視されたのが90年代のITバブルで、それを膨らませていたのがJavaであり、RDBMSだった。すでにバブルの本体はしぼんでいる。じゃあ、マッチポンプだったJavaとRDBMSはどこにいったんだろう? もちろん、どこにもいってない。しぼんだとはいえ、エンタープライズな仕事は、未来永劫にわたって確実に存在する。対象はすでにRDB化されてるし、それを扱う技術への需要が減ることはない。安くはなるだろうけど。もうなってるのか。
エンタープライズな領域でのソフトウェア産業のいくすえは、個人的にはどうでもいい。自分がそこで仕事をしていないからどうでもいい、という投げやりな話ではなく、単にどうでもいい。なぜなら、ここで気にかけておくキーワードがあるとしたら、それは「エンタープライズ」ではなく、「領域」のほうだから。エンタープライズは、ソフトウェアによるソリューションを必要とする問題領域のひとつである。つまり、ほかにも問題領域はたくさんあって、バイオインフォマティクス、法律や特許のような知識情報ベース、自律システムのインテリジェントな制御、その他、僕の知らないたくさんの問題領域で、それぞれに問題がゴマンとある。これらの問題に対しては、かならずしもJavaやRDBMSは使えない。正確にいうと、適しているとは限らない。もっと正確にいうと、適していない。
関係を正規化してちょいといじれば解が出てくるような問題でなければ、RDBMSは有効ではない。複雑な構造のデータはツリーで表せることが多いので、たいていはXMLになるだろう。Javaなら、XMLでもライブラリがいっぱいあって便利だね。けど、たくさんの問題領域ごとにツリーは異なるし、既存のライブラリで単刀直入に扱えるようなツリーじゃない場合はどうすればいい? そもそも、その領域で問題を解決する適当なツリーが見当もつかないような場合は? 見知の複雑なデータ構造を暗中模索しながら効率よく開発するようなマネができるのか?
そこでLispですよ。これほどツリーを扱いやすい言語はないし、どんなに複雑な構造のツリーでも言語そのもので容易に扱うことができる。そのデータ構造を扱う処理を含め、どうせみんなS式なので、カットアンドトライで見知の構造に挑むのも辛い仕事じゃない。そして方針さえきまってしまえば、あとはマクロにするなりコンパイルするなりして、さらに開発効率を上げたり、実行速度を突き詰めたりすることができる。さらにLispでは、Prologのような関係プログラミングのテクニックを採り入れることもできる。これは、複雑な関係を内包したデータ構造を扱うのにうれしい（ちなみに、先日発行された "Reasoned Schema" は、一冊まるごと関係プログラミングの話題）。Allegro Common Lispなら、Allegro Prologとして、すでに関係プログラミングの仕組みが用意されてさえいる（セミナーでは感動もののデモを見ることもできた）。
Lispと同じことをJava（やその他の言語）ではできない。できるにしても、超人的な何か（スキルとか忍耐とか偏狭とか）が必要になる。一方、その他の言語にできることはLispにもできる。サポートとかドキュメントとかライブラリの量とか、そういう社会的なメリット/デメリットについても、少なくともACLなら数理システムの技術サポートが得られるし、提供されている機能も多い。また、Lispのドキュメントやライブラリは決して少なくない。解説書も、これからがんばります。とにかく、他の言語にあってLispにないと積極的に言えるメリットはない。この非対象性が、あえてLispを使う理由だと思う。つまり、もはや「なぜ Lisp を使うのか」ではなく、「なぜ Lisp を使わないのか」ってくらい。
最後にもうひとつ、Lispには重要なメリットがある。それは、世界的な標準仕様があること。RubyやPythonのようなスクリプト言語がビジネスとして成功しない最大の理由は、実はこれなのかもしれない。

結局僕がHDDの換装ですか、そうですか。ようやく終わりましたよ。

1. 新HDDをプライマリ、旧HDDをセカンダリに接続して、knoppixを起動。新HDDが/dev/hda、旧HDDが/dev/hdbとして認識される
2. /dev/hda を fdisk して再起動（/dev/hdb と基本的に同じ構成にしとくほうがトラぶりにくいかも）
3. 各パーティションを、旧HDDと同じファイルシステムでフォーマットする（mkfs.ext2 および mkswap）
4. パーティションごとに dump/restore する。以下は /dev/hdb1（旧HDDのパーティション）を /dev/hda1（新HDDのパーティション）に dump/restore する例。これをパーティションごとに繰り返す。
   1. rw で新HDDのパーティション /dev/hda1 をマウント
   2. マウントした /dev/hda1 の直下に移動

   3. dump -0f - /dev/hdb1 | restore xf -

   4. umount
5. ふたたびknoppixで再起動
6. 新HDDでブートするように設定

   1. install-mbr /dev/hda1

   2. /dev/hda1 を rw でmountして、そこに移動して、chroot して、lilo
7. knoppix の CD-ROM を抜いて再起動すれば、新HDDで稼働する

install-mbr のことがすっかり頭になくて小一時間悩んだあげく指摘されて解決したことは秘密。

TODO：あとでちゃんとまとめること。

信じられないモチベーションといったら、ショスタコービッチもそうだ。党から創作活動を制限されていたジダーノフ批判以降の約4年間、ひたすら机の引き出しの肥やしにするために、24のプレリュードとフーガ、弦楽四重奏第4〜5番、バイオリン協奏曲第1番といった超傑作をこっそり作り続けてたんだから。もちろん、その間は収入もほとんどないわけで、ただ自分のためだけの作曲に労力を投入していたことになる。こう書くと、そのへんの道端やWebで「作品」を発表している自称アーティストやブログロガーと変わらなくなっちゃうな。ショスタコービッチの場合は、発表することはもちろん、作っていることさえ禁じられている状況なわけで、「オレを認めて欲しい」という欲求が一切介入しないところで高度な創作活動を続けていたところがすごい。あこがれる。
溢れてくる何かを信じられる人が本当に羨ましい。羨ましいんだけど、個人的に共感を感じてしまうのは、むしろドビュッシーのようなタイプである。こちらは着想を得ても、なかなか作品に仕上げられない。自分のやってることについて悩みまくって、ようやく形が見えてきても、また悩み始めちゃう。家の外で政情が不安定になったりすると、もう落ち着かない。結局、残せる作品の数は多くないけど、それでも圧倒的に傑作ばかりだから、やっぱりすごい。あこがれる。
ようするに、あれか。モチベーションの発現や維持はともかく、とにかく脳と手を動かせと。

また Hitchhiker's Guide を見ながらワインが一本あく罠。
昨日今日と、ひさしぶりに人間らしい休日を過ごした気がする。

バルトークは6つの弦楽四重奏を残しているが、第一作を書きはじめたのが作曲を始めて間もない1908年、第六作が死ぬ数年前の1939年だから、ほとんど一生書き続けてたことになる。ところでバルトークが作曲を始めたのは1904年らしい。この1904年ってのは、世界中でものすごいことが起こり続けた年だったのね。もっとも、こういう共時性は確率としてみればさほど意外ではない。生まれた月日が同一の人がいる確率が、数十人程度集めるだけで100%にかなり近くなるのと同じ程度の意外性。そんなことはどうでもいいんだ。
さっき知ったんだけど、実は彼は死ぬ直前に、第七作目の弦楽四重奏を書き始めていた。なんでそんなに弦楽四重奏が書きたかったんだ? あるいは、なんでそんなに涌いてくるんだ? 作曲家が抱くモチベーションなんてそもそも想像できないけど、弦楽四重奏を書きたいというモチベーションはさらに想像できない。だけど、すくなくとも第一作から第六作を聴いていて感じるのは、苦労して作曲している気がまったくしないことだ。イメージが涌き続けて、涌き続けて、涌き続けて困るっていう雰囲気。これがブラームスなんかを聴いてると、頑張ってる感とか使命感みたいなのが滲んでくる場面がしばしばある。ぼくは交響曲を作らなければならないのです、っていう意気込みみたいな。
意気込んでいい仕事ができる人もうらやましいけど、涌いてきて困る意欲でいい仕事ができる人はもっとうらやましい。両者の違いはなんなんだろう。ただの性格の違いなのか、っていうか、性格の違いって何?

仕事をこなすときのモチベーションには、「部屋のハエを始末したい」と等価なモチベーションと、「ハエのいない部屋に移りたい」と等価なモチベーションの、2種類があるように思う。いずれのモチベーションも、うるさいハエ（五月蝿い蝿）を何とかしたいというメタモチベーションから帰結するものだけど、それぞれのモチベーションに従ったときの帰結は異なる。「部屋のハエを始末したい」の帰結は、よくて職人（ハエをハシでつかむとか）か、せいぜいエアロゾルのラインを見張る労働者だろう。
こういう場面では必ず注釈が必要なので、いちおう断っておくけど、ここでラインの労働者を揶揄するつもりはまったくない。ただ、「ハエのいない部屋に移りたい」とは決定的に異なるモチベーションで従事する労働のひとつに、工場のラインを見張る仕事があると思うだけだ。だから、金曜の定時直前に上司の仕事をくらった秘書を例に採用したっていいし、出荷直前に致命的なバグ報告を受けたプログラマを例に採用したっていいし、印刷所への入稿ぎりぎりで大きな修正を迫られた編集者（！）を例に採用したっていい。でも、そんな切羽詰ったシチュエーションじゃないほうが一般的なわけで、たぶん、工場のライン労働は、そのイメージがつかみやすい仕事のひとつだと思う。

「部屋のハエを始末したい」モチベーションの最大の特徴は、対処すべき対象が目の前に見えていて、それにエネルギーを割けばいいことがはっきりしている点だ。ハエさえ片付ければ、すべてが終わる。さらに、もうひとつ副次的な効能もある。それは、自尊心にやさしいことだ。だって、ハエを追っている（つまり仕事をしている）ことは他人の目からみても明らかだから。そのため、このモチベーションに従って仕事をしていると気分がいい。仕事の結果も、100％気分がいい。だって、もう目の前にハエは飛んでないんだもん。
ところが、しばらくするとまた別のハエが飛んでくる。必ず。そもそも、最初のハエが部屋に入ってこられたのと同じ経路で、ハエはたえまなく侵入してくる。同様に、ラインの現場でも、今日のノルマが終わったら明日の生産分が待っている。ハエを追い払った後で純粋に安穏とできる期間は、業種によっても違うけど、自分の経験では、せいぜいビールを何杯か飲むあいだだ。あるいは、こうやってたわごとを書き連ねているあいだだ。もちろん、現実には仕事がなくなったらそれはそれで困るわけだけど、そのうち永遠にハエを追い続けるというイテレーションに嫌気がさして、いま飛んでいるハエを始末したいというモチベーションだけでは精神を継続できなくなるだろう。っていうか、僕には無理。

「ハエのいない部屋に移りたい」というモチベーションが魅力的に感じられるのは、そのときだろう。実際にはもっと早い段階で自分が部屋を出る可能性も考えるだろうけど、その思いつきが仕事に対するモチベーションになるかは別の問題だ。
どうして別の問題なのか。部屋の外にはもっとたくさんのハエがいることを知っているから？　それもあるかもしれないね。しかし、もっと根本的なのは、それがどういう仕事を駆動するかが異なるからだと思う。何が言いたいかっていうと、「ハエを始末したい」というモチベーションにより駆動される仕事が（自分にも他人にも）わかりやすい形をとるのに比べて、「ハエのない部屋に移りたい」というモチベーションにより駆動される仕事は、ずっと複雑な対応を求められるってこと。だいたい、別の部屋にハエがいないのかどうか知らない。ハエよりずっとやっかいなものがいるかもしれない。そもそも別の部屋があるかどうかも知らない。部屋があるにしたって、どうやってそこにいけばいいのかも知らない。どうすれば別の部屋の状況を知ることができるのかさえ知らない。こういう、何から手をつければいいのかさえ分からない問題への対処は、どう考えても相当分かりにくい仕事だ。つまり、このモチベーションが駆動する仕事は、「ハエを始末したい」というモチベーションにより駆動される仕事とは異なる。あえて色のついた表現をつかうなら、よりクリエイティブな仕事って言ってもいいと思う。ハエを始末しないことがクリエイティブなのではない。このモチベーションによって駆動される仕事をしているときでも、部屋のハエは始末しなければならない（でなければ破滅するわけで）。

もしかしたら、この部屋にやってくるハエの数を減らすことも可能かもしれない（これは、侵入してくるハエを選別するという意味だ。この部屋では、ハエが一匹も入ってこない状況は破滅を意味する。破滅してから部屋の外に出ることもできるけど、一般には無謀だね）。自分に関していえば、ハエを選別しつつ、別な部屋の探索を続けるべきだと痛感しているきょうこのごろ。

久しぶりにチキンカレーを作った。ほかのことをする気力もなかったので、レシピをまとめておいた。ついでに、だいぶ前に作ったグリーンカレーのレシピも整理した。我が家以外の人の舌にあうかどうかはわかりませんが。

チキンカレーで使うタマネギペースト
http://sidebrake.hp.infoseek.co.jp/onion-paste.xml

チキンカレー
http://sidebrake.hp.infoseek.co.jp/chicken-curry.xml

グリーンカレー
http://sidebrake.hp.infoseek.co.jp/green-curry.xml

ネガドンを見に池袋にいったんだけど、19:00ころに当日券を買って、係のお姉さんに「整理券とかはないの？」って聞いたら、「今日は立見は出ないと思いますよう」みたいなことを言われたので、ノンキに晩ご飯を食べてジュンク堂で本を買って戻ってきたら、30分前には長蛇の列ができて立見になってた。劇場のお姉さん、Webでの前評判とオタクのクチコミ効果を知らなかったとみえる。にしても、この人達のなかで立見は辛すぎる……と思って、当日券を払い戻して帰ってきた。

しゃくなので、家でまた Hitchhiker's Guide を見る。今日一緒に昼飯を食べた A はトリシアに似てる。どうでもいいが。

昨日（いうまでもなく祝日）の夜、仕事から帰って一息ついて、ご飯食べて21:00過ぎにウイスキー飲んでたら、郵便局の配達の人がamazon.comの箱をもってやってきた。ここ1カ月くらいの間に少なくとも5回は不在通知を置いて帰るというイテレーションを経て、ようやく日中に来ても留守なことを学習されたらしい。（ちなみに、amazon.comの荷物は、どんなに大きくても普通の定形外郵便物として配達されるので、再配達を除いて時間指定はできない。）

こうしてついに The Hitchhiker's Guide to the Galaxy が我が家にやってきた。アメリカ版DVDは特典の少ないバージョンしか出ていないので、イギリス版を買うか、おそらく特典てんこ盛りで発売される日本版を待つか悩んでたんだけど、イギリス版はPALだし、やっぱり待つこともできなかったので、さっさとアメリカ版を購入してしまって日本版が出たら出たでまた買えばいいか、と思うことにした。オトナってすばらしい。

とにかく、これからはイルカミュージカル見放題なわけですよ。ありがたいことにアメリカ版にもイルカミュージカルだけを切り出した特典クリップは付いているし、しかもこれ、画面の下に歌詞が流れるようになってるんだよね。うまく説明できないけど、海外の子供用番組のミュージッククリップによくある、歌に合わせて歌詞の上をキャラクターが飛び跳ねながらなぞっていくやつ。デズニーアニメでやられるとうざい仕掛けだけど、歌詞がシニカルなこともあって、「おまえらよく分かってる」とイルカをほめてあげたくなる。イルカ！　そういえば配給はデズニーだったっけか。
ほかの特典としては、映画ではカットされたシーンがいくつか収録されている。よくある特典クリップではあるけど、原作の有名な場面で映画版にはなかったワンシーン（"Hitchhiker's Guide"の「地球」の項目のくだり）も含まれているので、そのへんに不満があった人は購入する価値があると思う。ただし、カットされた理由もなんとなくわかるんだけどね。
あと、「もうひとつの映画版カットシーン」といいながら、おふざけで撮影されたと思われる映像も2編入っているけど、これらはジョークがブリティッシュすぎでよくわかんない。ついでに「無限不可能性ドライブ」ボタンも付いているけど、これは2、3回遊んだらあきるね。

タイピング時のヘンな癖に気が付いた。"1" を入力するつもりで "a"、"2" を入力するつもりで "s" を入力しがち。しかも！　"2" と "s" は形が似ていやがるので、画面を見ている場合でも発見が遅れる。で、そのまま評価すると "ERROR: unbound variable: s" とかいわれて焦るわけよ。
qwerty 配列の弊害か。

商売を見れば、貪欲に広い市場へリソースを投入するのは当たり前。でも、その広い市場で勝つことにメリットを見いだせないとしたら、どうよ。もっと大義あるやり方でもって、今の市場で食っていくだけの道を選びたくない？　本当は大義みたいな漢臭い表現は使いたくないんだが、ここでは「大義」が重要。本当に「食っていくだけ」じゃ、まったくモチベーションにならない（あしからず、これは「食っていく」ことさえ難しい世界の最貧層を非難する表現ではありません。この国で年収400万未満で生きることにだって、言い知れないやりきれなさがある）。つまり何がいいたいかというと、大衆市場には商売上のうまみはあるが、どのみちつらい仕事なら、より洗練された市場の顧客を選びたいってこと。その選択もまた一つの価値であるということ。もちろん、何を洗練されていると見なすかは、オレ判断でお願いいたします。
いや、業務として割り当てられれば何でもするし、何でもしてきたんだけどね。だから、そんなに片意地なことをいっているつもりはなくて、あくまでも個人的な価値をどこにおくかって話。

この12月にかけての仕事は、ひさびさの Real Work

素数の魅力を説明してほしいといわれた（一部編集）。そんなこといわれてもなあ。「素敵な数」なんだから魅力的にきまってるじゃん。

ヘンなやつは、付き合っていて楽しい。いわゆる「底が見えるやつ」は面白くない。そうはいっても、まるっきりとっつき悪いやつと付き合う気にもならない。ある程度までは自分の常識に即していて、それなのに「そんな一面もあったのかよ……」と呆れさせてくれるのがいい。わけの分からなさがちょうどいいと、魅力を感じる。
たぶん、素数には、そういう「ちょうどいいわけの分からなさ」がある。「10」にはない魅力が、「23」にはある。

ついでにいうと、一番魅力がないのは「42」だ。

ひさぶりに強烈に楽しい打ち合わせだった。参加いただいた方々、長時間お疲れさまでした。

朝4時に起きるようになったので、エスプレッソメーカーを買ってみた。

Bialetti MOKA EXPRESS
http://www.bialetti.it/it/catalogue/scheda.asp?id_cat=24&pag=1

安い、うまい、簡単。
実際に使ってみるまで知らなかったんだけど、これって紙のフィルターとか一切不要なのね。ポット全体が2つに分かれて、その間に漏斗形のパーツがあるという構造なんだけど、ポットの下半分に水を満たし、漏斗部分に極細挽にした豆を入れたら、あとは火にかけるだけ。5分と待たずにポットの上部にエスプレッソコーヒーがたまる仕組み。
豆は、 やなか珈琲店 で焙煎して挽いてもらった。家の近くにも会社の近くにもあって、前を通るたびに香りにやられていたので、先週末の土曜日、休出したついでに意を決して入ってみた。ブレンドが店内で飲めることがわかった。しかも150円。しかも濃厚。

朝コーヒーを飲むなんていう習慣はなかったけど、やってみるとクセになる。自分で淹れるのがポイントかな。淹れてるときの香りがたまらない。実はこれ、中国茶でも同じで、あれもサービスしている本人が実は一番の役得なのだ。相手へのサービスが本人にとって喜びになるってのは、仕事の本質じゃないだろうかね。

こうやって話にオチを付けたがるのはよくない。

携帯デバイスの必要性について議論になると、いつも出てくる意見。「ケータイでいいじゃん」
ちがうんだよ。最低でも qwert じゃないとやなんだよ。qwert が人間工学的にどうこうとかの議論はおいとくけど、とにかくあのケータイの文字入力は、どんなに予測入力があっても、表現を制限したり特殊化したりすることをデバイスによって（暗に）強いられている。たぶん。あれで十分だと思っているのは、実情は思わされているだけで、単に他の選択肢がないから十分だと感じるにすぎない。擬素数を疑わずに素数判定をしてるみたいなもんだね。ちょっと違うか（ぜんぜんちがう）。
以前は、ケータイの文字入力でも結局は人間のほうが慣れちゃうからいいんじゃね、と楽観視してたけど、やっぱりダメだということに気づいた。自分が慣れたくないからダメなんじゃなく、表現の多様性のためにダメだ。qwertにも、いや、そもそもテキストデータ化にも表現の多様性を縮退させる傾向があるかもしれないけど、だからってデバイスの制限によって縮退が加速させられていいのか？
表現の多様性と利便性（コミュニケーション可能性）はどこかでバーターする。とにかく多様ならいいってものでもない。その点、書き言葉、つまりテキストデータのみで扱える範囲の表現は、歴史的にもいろいろあって（右翼：法令とか公文書とか←→左翼：俳句とかジョイスとか、そのたもろもろ。宗教の教典もこの軸では左翼だね）、あるいは共同体における教育とか文化の後ろ盾もあって、比較的センスがいいところでバランスできる手段だと思う。まあ、このバランスだって、そういう歴史とか教育とか文化に基づいているからという意味でしかセンス云々を語ることはできないけど、それはそれでしかたないっしょ。だって表現は、歴史とか教育とか文化に基づくコードの塊を抽象化するものなんだもの。

なんで TeX には両方向の斜め矢印 がないんだ。

\def\neswarrow{\ooalign{{$\nearrow$} \crcr {$\swarrow$}}}
\def\senwarrow{\ooalign{{$\searrow$} \crcr {$\nwarrow$}}}

根本から勘違いしている可能性があるけど、

|- _T ( x=y <-> y=x )　（ただしT はTheorem）
∵ |- _T ( x=y -> x=x -> y=y -> y=x )

この理屈が成立するには、p を T における述語として、 |- _T ( p₃xxy -> y), |- _T ( p₃yxy -> x ) となるp₃ が必要だと思うんだけど、これって自明なの？（少なくとも僕にとってはムズカシイ。）　「式中に1度しか出現しかない元を抽出できる」、さらには「式中である性質を持つ元だけを抽出できる」なんて、直感的には定理になるとは思えないんだけどねえ。

モチベーションの大小は、細かいところで静かに積み重なり、結果として大きな影響をもたらします。それが分かっていたって、結局コントロールできないんだけどさ。

問題のある部分は日中に会議があることで、そこでのプレゼン（みたいな何か）がむやみに長い。自分が知っていることを話すのではなく、相手が聞きたいことを予測して話すのがプレゼンです。あと、他人の仕事を引き受けすぎという根本的な問題もある。

ところで昨日は交通博物館に行った。これはまさにあれだ、ノスタルジーとメカニカルと金属の融合。

映画「銀河ヒッチハイクガイド」を観にいった。そもそも映画化を知った瞬間から、B級な出来に仕上っているに違いないと思いつつどうしても期待しちゃっていて、しかも、期待感でいっぱいになった脳が実物に接触すると、たいていがっかりする。そんなわけで、六本木に着いたころには、帰りにどうやって残念感を補填しようかなあとまで考えていた。
なのに、拍子抜けするくらい面白かった。オープニングから泣きそうになる。僕は、このオープニングの10分くらいを観るためだけにでも、もういちど映画館にいくね。DVDも買っちゃうんだから。
関心したのは、必ずしもマニア向けになっていないところ。2時間の興行映画としてシナリオや演出が相当ねられていて、これなら前提知識なしでも楽しめるはずだ。何よりテンポがいい。テンションのメリハリがはっきりしている。だから、笑いながら見ているうちに気が付いたら佳境で、もうじき終わりなのが残念でならない。もっと新しい景色をみせてください！ ともあれ、続編へのフリもあったので期待しちゃおう。あと、Zooey Deschanelがむやみにかわいらしいことを付け加えておく。

原作を粗筋だけでも知っている人は絶対に劇場で観とくべきだと思う。むしろ、ふつーの人に見てもらいたいなあ。一般ウケしといたほうが続編の企画も通りやすいだろうから。だいたい、ろくにマスコミで宣伝していない気がするし、都区内で六本木でしか上映してないってどういうことよ。実際、今日も観にきてるのは明らかにソレっぽい人たちばかりで、土曜日のデートのダシにこの映画を選んでるような人たちは見当たらなかった。

Journalという単語が気になりだしたら止まらなくなってしまったので、タイトルを k16's note に変更します。ちなみに、これは報告ではなく、将来のための記録です。
最初にlivejournalを使っていて、さして気にもとめずにlivejournalでのデフォルトのタイトルを引きずってきたけど、どう見てもこれはjournalではない。しいていえば大学ノートに書きためておくような何か。

よろしくお願いします。のタイプミスがはげしい。

丁しく尾根有g氏
丁しく尾根sマス。
よろしくお願いしまう
よろしくお願いします。
丁しく尾根貸しあしまう。
よろしくお願いします、

メールの文末にこういうのを見つけたら、てんぱってるなと思って見過ごしてやってください。それにしても丁しく尾根がってるな。

同僚（っていうか先輩）のhsashimさんと歩いていると、よく「今すれちがった女性は鹿野さん好みじゃない？」ってふられるんですが、歩いているときに周りの人のことは見てないんです、すみません。で、そう返事をすると「どうせオマエは奥さんのことしか考えていないんだろう、この幸せボケが」とののしられる。

仮説1：僕は本当に幸せボケである
この仮説は半分正解で半分間違え。好きな奥様と暮らしているのは確かに幸せだが、それだけでボケていられたらブログロで心の排泄などしないのである。

仮説2：僕はただ単に周りの人を見ていない
自分ではこの仮説が正解だと思ってた。なぜなら、どこを見ているか意識しながら歩くと、決まって目の前の道路だけを見ていることに気が付くから。しかし冷静に思い返すと、昨日まで歩いてきた道路の景色を断片でも覚えているか？　そんなことないわけで、むしろ通行人のこととか、見かけた車のこととか、町並みのことを覚えている。だから、僕は道路を「見て」はおらず、周りの人を「見て」いる。じゃあ、なんでhisashimさんが声をかけてきたときに、その指し示す女性を認識していないんだ？

仮説3：hisashimさんが妄想している、または枯渇している
ありえないとは言い切れない。しかしこれ以上考察を続けると人的被害が出かねないので思考中止。

仮説4：hisashimさんとは趣味が違う
人間は見たいものだけを見るので、彼が見ているものを僕が見ていないのは不思議ではない。でも、普段話している限りでは、そう大してズレているわけでもなさそうなんだけどなあ。


いずれの仮説も満足できる答えではないし、どうやって検証したらいいのかもわからないので、おしまい。

結局、レンズを買ってしまった。

TAMRON：AF18-200mmF/3.5-6.3 XR　Di II LD Aspherical [IF] MACRO (モデルA14)
http://www.tamron.co.jp/lineup/a14/index.html

シグマのと散々迷い、ヨドバシカメラでも決意が二転三転しながら、最後はゴールドポイントのパーセンテージでタムロンに決めた。だって27%もポイント還元だよ（昨日限り）。不純かもしれないけど、それだけ甲乙つけ難い製品だということ。技術力のあるメーカー同士が切磋琢磨している製品のユーザは幸せだね。
で、さっそく自宅で適当に何枚か撮影してみた。インドアばっかりでごめんなさい。



さすがに200mm側だと手ぶれを抑えるのが大変。かといってD70の内臓ストロボを使おうにも、弱すぎて役に立たず。もっとも、どのみちフラッシュは使わないので、個人的には問題にならない。カメラを押さえつけて撮影するのみ。
写りは文句なし。芸術的というより工芸的だ。こういうのは好き。D70レンズセットの18-70mmと、18mm側で条件を同じにして撮り比べてみると、気持ち暖かい色見になる気がする。ただ、これはカメラのちっちゃい液晶画面で見比べたときの話で、Photoshopで開くと大差ない。あと、タムロンのほうが画角が正確っぽい。
何よりこのクラスのレンズの魅力は、ボディのサイズにあると思う。なにせ、D70レンズセットの18-70mmと変わらないわけで、もう積極的にこの18-70mmを使う理由がなくなってしまった。というわけで、これからはこっちを常用することにしよう。

某所で知った「象られた力」（飛浩隆）を読む。そうとうおもしろい。4本の中編が収められていて、うち1本の「デュオ」以外は未来の宇宙を舞台に展開されるしっかりしたSFである。だから、必然的に設定や小物には趣向が凝らされているし、それに成功している。つまり、オタク的に面白い。その魅力は、現代を舞台にした「デュオ」にも溢れていて、それだけでも満足な一冊だった。もっとも、設定や小物が魅力的なのは、単にアイデアというよりも、その作中での生かし方の巧妙さにあるんだろう。ありきたりかもしれないネタを気持ち良く予想外の方向に引っ張っていってしまうストーリーと描写。
そういう、新しい世界を見せてもらう心地よさに加えて、いずれの作品にも個人的に共感できる視点があり、それも楽しむことができた。巻末の「解説」には「形と力の関係が云々」と書いてあるけれど、むしろ各作品に通底しているのは、力の背景にあるのが「個人」なのか「個人を越えた存在」（「死者」とか「宇宙」）なのか、その決定不能に抗している主人公（たち）を描くことなんじゃないだろうか。問題に対峙する主人公（たち）の解や行動は各作品ごとに異なっていて、その描き分け方が、うまい具合に魅力的なキャラクターづくりに貢献している。そういう意味では、この4本を選んできたのは正解だったと思う（ほかを読んだことはないけど、なんとなく）。
最後に表題作である「象られた力」の重箱をつつきたいわけですが、宇宙全体で活躍する建築家のハバシュの作品は、シジック以外の星系にもあるんじゃないだろうか? だとすると、シジックの歌が本編のような解釈をされることには無理があるような気がするんだけど…… それとも、リットン&ステインズビー協会がうまいことやってるんでしょうか。

新婚のK宅へ。ひがなうだうだ過ごし、夜になってから多摩川の土手でひとしきり花火を燃やした。家庭用花火の火薬の匂いには、一日に対するノスタルジックと、季節に対するノスタルジックと、人生に対するノスタルジックとがごちゃまぜになっていて、無条件にはしゃぐにはつらい瞬間がある。だから、みんなが楽しんでいるのを端で見ているので十分なんです。それなら、はしゃげる。

金曜日は飲み友達（あえて）数名でトプカへ。思わず誕生日をお祝いしていただき、本当にありがとうございました。翌日は久しぶりに頭痛で目が覚めました。花を頂いたり、予期せぬ豪華なプレゼントを頂いたり、うれし恥ずかしなポラロイドを撮っていただいたりしましたが、何よりああして一緒に楽しむ機会をつくっていただいたことがたまらなく嬉しかったです。これからいろいろあると思いますが、末永くよろしくお願いします。

いただいたプレゼントたちの一部。




ジムの写真はこちらからお楽しみください。
http://www.flickr.com/photos/k16/sets/966783/show/

どうやらSICP第1章の趣旨を勘違いしていたっぽい。しかも2重に。
いただいたコメントで紹介されている記事（Scheme:末尾再帰で木をトラバース）を読んで気が付いた一つ目の勘違いは、末尾再帰で書くことにより必ずしも効率がよくなるわけではないということ。それを意識してSICP第1章を読み直すと、確かにそんなことは書いてない。それどころか、式の処理モデルとインタプリタの実装とは別のはなしだって強調されてる。
もう一つの勘違いは、末尾再帰とiterativeなプロセスの混同。正確にいうと混同していたわけではなく、末尾再帰で書くことでiterativeに書いたことにもなると思いこんでいた。どっちも、勘違いの程度としてはたいしてかわらないので、いいわけにもならない。
結局、SICP第1章の目的は計算プロセスをより深く理解することであって、coolなプログラムを書くことではないんだろう。

以上を踏まえて、両替問題のiterativeバージョンに再挑戦。アイデアは、前回の項和を求めるプロシージャをiterativeに書こうというもの。このアイデアそのものは同じだけど、すこし頭がすっきりしたので問題がクリアに見えるようになった。

まず、一般に f の項和を求めるプロシージャが次のようにiterativeに書けることを確認。いちおう末尾再帰になっている。

;; Iterative sum
(define (sum f a z)
  (define (sum-iter i summed)
    (if (> i z)
        summed
        (sum-iter (+ i 1) (+ summed (f i)))))
  (sum-iter a 0))

(sum (lambda (x) x) 1 10)
=> 55

これを、先日の両替問題におけるsumに応用すると、次のようになる。

;; change coin iterative
(define (d k)
  (cond ((= k 1) 1)
        ((= k 2) 5)
        ((= k 3) 10)
        ((= k 4) 25)
        ((= k 5) 50)))

(define (cc-iter a k)
  (define (sum i summed)
    (if (= i (- k 1))
        summed
        (sum (+ i 1)
             (+ summed (cc-iter (- a (d (- k i))) (- k i))))))
  (cond ((< a 0) 0)
        ((= k 1) 1)
        (else (sum 0 1))))

(define (count-change-iter a)
  (cc-iter a 5))

(count-change-iter 100)
=> 292

これは、末尾再帰ではない。けど、iterative （だよね？）。

電波をインターネッツで公開することの是非についての考察。

もやもや を具体的な姿で示すことと、具体的な姿を もやもや にすることは、単純な逆変換というわけではない。前者は具象化と呼ばれ、後者は抽象化と呼ばれる。これらは確かに逆変換なのだけど、それが単純でないといっている理由は、変換が準同型でないからだ。もやもや →姿→ もやもや で戻ってきた もやもや は、一般には最初の もやもや とは次元が違う。この、もやもや の次元に、順序をつけよう。順序のつけ方は任意だけど、「その もやもや の意味を評価できる第三者の数」に応じて、＞ または ＜ または ＝ を適用することにする。第三者は人間とは限らない。また、意味の定義はここでは与えない。この順序を、 もやもや のモデルを集合と見なしたときの包含関係により定義しても同じことである。
たとえば。
いまここで、自分の頭に漂っていた もやもや1 を、「多次元のもやもや」みたいな言い方で姿ある形に書き下した。これは、もやもや1 を具象化したことに相当する。さらに、順序をつけることで、書き下した概念を改めて もやもや2 に変換した。なお、もやもや1 は（定義により）そのまま日本語で説明することは不可能だが、もやもや2 は書き表せる。書き表せる、ということは、最初の もやもや1 に比べて、意味を評価できる第三者の数が明らかに多くなったと考えてよい。つまり、もやもや1≦もやもや2（等号は、もやもや2 を評価できるのが依然として自分だけの場合に成立する）。

うーん、どうでもいい。こういう「それっぽい」ことを書くのはやめてください、という声が内側から聞こえるが、電波でも書けば もやもや の次元があがるんだよ。だから書くことにした。

SICP-第1章の両替問題の効率化（末尾再帰化）に悩んでいたら昼休みが終わってしまった。どうでもいいけど、こういう徒労を繰り返しているうちに人生が短くなっていくからちゅういしろ。あと、これから書くのは答えじゃないからちゅういしろ。

まず、変数と関数をいくつか用意する。

• a：総額
• k：コインの種類
• d：コインの種類に応じて金額を返す関数
• f：両替問題を解く関数

SICPでの考え方は、次のとおり。
f ( a , d ( k )) = f ( a - d ( k ), d ( k )) + f ( a , d ( k - 1))

これを式変形していくと、次を得る。
f ( a , d ( k )) = ∑_i=0→k-1 { f ( a - d ( k - i ), d ( k - i ))} + f ( a , d ( 0 ))

最後の項は定義により 0 だから、結局 f についての項和が得られる。この和をダイレクトにSchemeで書くと、次のようになる。

(define (d k)
  (cond ((= k 1) 1)
        ((= k 2) 5)
        ((= k 3) 10)
        ((= k 4) 25)
        ((= k 5) 50)))

(define (sum-cc cc a k)
  (cond ((< a 0) 0)
        ((or (= a 1) (= k 1)) 1)
        (else (+ (cc (- a (d k)) k)
                 (sum-cc cc a (- k 1))))))

(define (cc a k) 
  (sum-cc cc a k))

(define (count-change a)
  (cc a 5))

これは結局SICPの例と等価だよな。sum-ccだけ見れば普通の総和計算のコードなので、頭を捻って継続引き渡しスタイルで書くとかすれば、「見た目」は末尾再帰にできそうな木がする。それに、もうちょっとSICPを真面目に読み進めれば、∑を末尾再帰で書くヒントが書いてありそうな木がする。でも、評価の順番を書き下していけば結局SICPの例と同じ木になるわけで、そんなんじゃちっともうれしくないね。このあたりでいつもつまずく。SICPの第1章で主張しているのは、計算プロセスをrecursiveからiterativeにすれば計算機コストの面ではうれしい、って話だと思うんだけど、それってアルゴリズム（っていうか問題の解法）の話じゃないんだよねきっと。かといってプロシージャの表現の話でもないし。
ところでiterativeの訳語って逐次的？

晒されているアホな環境を抜け出して次のステージに行くには、アホを威嚇射撃しつつ自分の道をゆっくり進むしかない。（Joel On Software―射撃しつつ前進）

今日の訓示。コミュニケーションのコストは相手のプロパティによって決定する。だからといってコミュニケーションから逃げてはいけない。

万年筆のインクを買いに銀座へ。明治屋でサミュエル・アダムスを開けてもらって歩行者天国で飲む。仲町商店街の阿波踊り大会をのぞきにいく。家に買えって肉を焼く。強火で30秒、肉の暑さに応じて弱火で15秒〜30秒。今日はいろいろ休み。

技術を習得するっていうのは、溜め込んだ知識や情報や経験に横糸を通していくことだと思う。っていうか、昔、徹子の部屋でそんなことを言っているのを見て、なるほどなあって思った。知識や情報や経験は、それぞれ独立あるいは未分化の状態で縦糸としてぶら下がっている。そこに横糸を通すことで、ばらばらだった縦糸を結合し、あるいは未分化だった縦糸のうち関係のあるもの同士を編みこんでいく。
縦糸と横糸は卵と鶏で、常に縦糸が先に垂れていてくれるとは限らない。もちろん縦糸が先の場合は多い。たとえば母国語なら、環境が縦糸をいやおうなく用意してくれ、成長してから文法を学んだり文学に触れたりすることで横糸が通る。ところが外国語の場合はどうだろう。現地で生活することにより母国語と同じプロセスで外国語を習得できる場合もあるけど、はじめに横糸を通すほうが習得しやすいって面もあるんじゃないだろうか。つまり、文法を学ぶことで言語としての構造とノリを俯瞰し、それを横糸にして、単語やイディオムや定型句を縦糸として結びつけていく方法。高い金と時間を使って駅前留学できる人にはお勧めしないが、闇雲に縦糸を垂らす余裕がない貧乏人には悪くないアプローチだと思う。コンピュータプログラミングとか数学とかも同じ傾向があるよね。そういう抽象度の高い技術ほど、横糸の役割が重要になる。ただし、横糸に縦糸をぶら下げただけでは出来上がる絨毯が歪になるので、必ず改めて横糸を通し直さなくちゃいけない。そして、再び縦糸を結んでいく。以下くりかえし。
いずれにしろ、技術を習得すべく努力している場合には、自分がいま縦糸と横糸のどちらのステータスにあるのかを意識してトレーニングにあたるのが懸命だろう。そうでないと、あまりにも非効率だから。当然、教材や講義にも縦糸を垂らすのに向いたやつと横糸を通すのに向いたやつがあるわけだが、縦糸用の教材や講義で横糸を垂らそうとしても徒労に終わる。これはつまり、教材や講義を提供する側も、その教材や講義が縦糸なのか横糸なのかを意識すべきだということ。提供者と受益者の意図が合致しないほど不幸なこともない（自分で書いていて耳が痛い）。

何でこんなことを書いたかっていうと、このページを読んだから。

解法網羅型参考書の効果的な使い方::
http://www003.upp.so-net.ne.jp/chief/reference.htm

via. プログラミングのための線形代数 - なんでも:: 2005-09-03 (Sat) 00:31:00

解法網羅型参考書は、横糸であって縦糸ではない。それを意識して使えば非常に便利なものだと思う。ちなみに、『プログラミングのための線形代数』も横糸だと思う。

オレ機能仕様を満たそうとがんばってたら、ブログロのことすっかり忘れてた。そして、その間に一つの命題を発見した！

命題
睡眠時間を減らすと、仕事の能率が上がる場合がある。

しかもこの命題は簡単に証明することができる。証明には以下の2つの補題を使う。

補題1
睡眠時間を減らすと、人間的な感覚が鈍る。

補題2
ある種の仕事は、人間的な感覚をもって挑むには苦痛すぎる。

この命題の例外もまた容易に見つかる。例外は、機械的な作業や事務仕事以外の、本当の仕事だ。注目すべきは、この例外を上手く捉えた場合、それにより睡眠不足に陥るので、結果としてあらゆる仕事が上手く回るという点である。これなんて宗教？

やっぱり結婚式ってのは、はたで見てるぶんには面白い。あと、友人の娘はかわいい。

はしゃぎすぎた

朝、Debianサーバ（昨日までの仕事のデータが全部入っている）の障害が発生する。同時に、ローカルの作業用PCでは、Firefoxが原因不明で固まり続ける。まったく、これでどうやって仕事をしろというんだい。まあ、ようやく復旧したので、これからガンガン仕事を再開するぜ。

しかしサーバの障害は、自分が修理から戻ってきたマシンの再設定をサボっていたことも原因なわけなので、ご迷惑をおかけした皆様にはお詫び申し上げます。
もちろん、ほんとの原因は、この春に申請した代替機がクライアントマシンとして転用されてしまったことにあると主張したい。

この土日、一日を小さな単位に分割して生活するという試みをした。つまり、学生と同じ生活を意識的に心がけてみた。学生時代のように単位時間で区切ってパラレルに複数の勉強や作業に励み、それらを数ヶ月以上のスパンで継続することで、有意義に休日を過ごしたい。9時から18時までをこの単位で区切れば、だいたい4～5サイクルくらいになる。ってことは、週に8～10単位の仕事（労役ではない）をパラレルに無理なく進められるってことだぞ。画期的だ。ちなみに、昨日の日曜はこんな感じに割り振った。午前中を中国語と教科書を読むのにあてて、午後は昼寝とCいじりという感じ。

起床後、朝食をとりながら中国語の復習（30分）
↓
エウレカセブン（30分）
↓
掃除しながら中国語ヒアリング（1時間）
↓
プリキュア（30分）
↓
中国語（1時間30分）
↓
確率論の教科書を読む（2時間）
↓
メール書いたり（30分）
↓
昼食、昼寝（1時間30分）
↓
なぜかCプログラミング（3時間）
↓
ディナー（2時間）
↓
Cの続きをやって、終身（1時間）

社会人になってやってきた仕事っていうのは、（そう遠くない）納期までに終わらせるような成果仕事が中心だった。そのため、どうしても、例えば今日から10日間はこの仕事にかかりきりにならなきゃいかん、ってことになる。これが精神的につらい。しかも、その仕事で得ることができる知見は、その仕事を納品した後で再び繰り返されることが少ないから（しばらくは見たくもない！）、自分のなかで蓄積されづらい。
一方、学生のころは、毎日の日中が1時間30分～2時間に区分されていた。少なくともタテマエでは、その間は一つの講義や演習に集中する。各単位の境界は15分から20分の小休憩で区切られていて、連続する単位でまったく異なる内容の講義や演習に参加することも多い。そして、そのパターンが少なくとも数ヶ月は継続し、その間に得られた知見は、高々テストに通る程度には蓄積される。いちおう断っておくけど、テスト前にだけ詰め込みするようなケースは想定していない。
今になって考えてみると、人間が集中力を維持できる時間の限界は経験的にも2時間くらいだから、この区分はかなり効率的だったんじゃないだろうか。だいたい、人間は同じことを延々とやっていると飽きるし、飽きれば効率は悪くなるし、効率が悪くなれば出来はひどくなるし、フラストレーションもたまるし、仮に最初は面白かったものでも、だんだん苦痛になってくる。そうすると、一段落ついてから再び同じ物事に取り組むのを身体が拒否するようになる。再開しようとすると強烈な眠気や肩の痛みに襲われて、うだうだしたり、身体の不調を愚痴ったりして、一日が終わってしまう。そして自己嫌悪。今日はちっとも進まなかったから明日はがんばるぞう、と思っても、明日はむしろ今日やらなかった分だけ仕事が滞っているわけで、今日以上に気力が出ることはありえない。
ちなみにこれは、とくに生産的な活動のように、脳を酷使する仕事にいえる傾向だ。不都合なことに、ゲームとかWebとか、非生産的な活動ほど延々と続けることができたりする。可処分時間は仕事の密度にかかわらず一定だから、こういう拒否反応が出るようになると、可処分時間を埋めるべく、ゲームとかWebとか、とにかく何か後で後悔しがちなことに精を出してしまう。

そこで今日からは、会社での仕事時間も集中力の維持できる細かい単位で区切ってみることにした。単位は1時間30分。続けて同じ仕事をする場合でも、1時間30分経ったら必ず小休止を入れる。1サイクルの間は、できるだけ割り込み的な仕事（メールの返信とか）は割けて、次のサイクルで処理する。
こうすれば、午前中2サイクルと午後3～4サイクルになるわけだが（もちろん残業なんてものは考慮しない）、こうして単位を区切ることで、作業時間の見積もりもつけやすくなるはずだ。今週中に終わらせるためには1サイクルでこれだけこなさなければならないけど、それは物理的に不可能だから、あきらめる。とか。あきらめないでダラダラ続けても、アウトプットは同じですから！

今日の敗因。（1）午前中が割り込みの作業でつぶれた。（2）午後、集中してきたところで、腰砕けするユーザー対応が発生した。（3）昼休みに別なことに熱中しすぎた。
ウエブサーフインが敗因に含まれていないので個人的にはよしとする。

Joelさんは Painless Functional Specifications のなかで、ソフトウェアを開発するのにあらかじめ機能仕様（技術仕様書ではない）を整理することが重要だと強調している。とくに再三にわたって強調しているのは、コードを書く前に機能仕様書をまとめることで「いらん機能盛りだくさん」に陥るのを回避できる、という側面だ。ソフトウェアの話はこれでおしまい。

自分自信の機能仕様書を書くのはどうだろうと思った。人間だってひとつの機械であるとか、そういうしょっぱいことを言うつもりはない。ただ、ほら、どうも今の自分は「いらん機能盛りだくさん」になってる気がするし、いらん機能の追及で社会へのリリースが遅れたのも事実だし、いま現在だって新しいバージョンのロードマップが描けてない。これはきっと、いわゆるひとつの ゴンゾー だ。

さっそくJoelさんにならって、オレ機能仕様書を書いてみよう。

---

概要

この仕様書では Keiichirou Shikano（以下K）の次期バージョン（以下K2）に理想とされる機能についてまとめる。実現可能性とは異なる場合がある。実現可能性については別に考察する、っていうか、あとから勝手に思い知れ！＞自分
したがって、この仕様書は完成版ではない。実現可能性に応じて随時更新される。この仕様書が完成するポイントは K 自身で決めるものとする。

シナリオ

K2 の生活。奥様や両親といった容易に特定できる個人とのシナリオではない。これはあくまでもマクロな社会における仕様書なんだから。

シナリオ1：勤め先

K2 は遅刻や居眠りはしない。基地外じみたミスをすることもあるが、たいていの仕事はソツなくこなす。一見するとくそマジメっぽいが、付き合いはそれほど悪くない。ただし、群れるのと馴れ合いが嫌いなので、体育会系の付き合いは丁重にお断りする。どちらかというとリベラル寄りに物事を考える。（ここまでは旧バージョンと同じ。好ましかったと思われるポイントをいじる必要はない）
K2の最近の仕事は、特殊な商品のトレードを支援するシステムの開発とメンテナンスである。これはソフトウェア製品ではなく、だからエンドユーザへのサポートもいらない。会社の別な人間が、このシステムを使って収益を上げてくれる。このシステムにはちょっとした数学が応用されており、それは K2 にも理解できる程度の本当にちょっとした原理に過ぎないのだけど、素晴らしい成果をあげてくれる。

シナリオ2：オフ

K2は17:00前には帰宅する。ミニマルな再生装置で音楽を聴く。休日にはビリヤードに出かける。奥様と食事に出かける。子どもがいるかもしれない。ピアノをひく。シーズンオフになると友達と人気のいない山や海や温泉へいく。年に数回は台湾に行ってお茶を買い込んでくる。気が向いたら小さなスポーツカーでドライブに出る。

サポートしないこと

このバージョンでは以下の機能はサポートしない：

• 18時間労働、および、おかしな企業への雇用
• ひきこもり、または、モラトリアム
• ネクタイ、印鑑、形骸化した書類仕事、請負
• 理論数学（いまさら研究者は目指さないこと）、ビジネス理論（MBAとか）、IT系
• 英会話スクール、通信教育
• 日本で子育て
• マンション購入

フローチャート

現在の仕事をきちんとやりつつ資産運用
　　↓
並行して、未熟な技術のリハビリと習得（数学と英語とコンピュータサイエンスと中国語）
刺激メモ：必要ならUSへ行くことも検討すること
　　↓
転職または起業

現在の仕事と資産運用

やるべきこと、やりたいことが残っているので、数年は転職しない。しかし給料は少ない（少なすぎる！）ので、その間にきちんと運用して資金を用意する。

未熟な技術のリハビリと習得

旧バージョンの K には、知識はそこそこあるものの、技術力が決定的に足りない。K2の開発では、これまでの知識偏重な勉強を改めて、意識的にトレーニングに勤めること。数学とか英語は技術ですから！（学生の頃にこれに気づいてればねえ。へたに講義の理解が速くてテストでも成績を取れてたもんだから、訓練サボって他の学部の授業ばっかり受けちゃったり、専門外の専門書ばっかり読んじゃってた。いまの時代はインテリで食ってけるもんじゃない）
現に、あえて文法学習を避けて例文の暗誦ばかり続けてきた中国語は、このところ日常の場面でも自然に口をついて出るようになってる。同様なこころがけをもってしてリハビリと技術の洗練を続けること。

睡眠時間について

仕事と並行していろいろやるためには睡眠時間を減らすしかない。睡眠時間もトレーニングできるので、4時間30分を目標に段階的に減らしていく（毎月30分ずつ縮めていく。冗談じゃないよ）。今のところ、それまで23:00-6:30だった睡眠が23:30-5:30くらいまで短縮できている。一日10時間も寝てる場合じゃない。

未解決のリスク

• 年齢
• 金

刺激メモ：いまのままでも十分にリスキー

---

Joelさんの言いつけどおり、軽口を混ぜて書いてみた。

クレジットカードの申し込みをした。前に申し込んだときは、まっとうな社会人として認められていなかったことが判明（自業自得）。今度もだめだったらどうしよう……まあ、その場合は、その信用のなさを武器にして東京スター銀行のマスターデビットに申し込もう。

で、すっかりクレジットカードを持った気分になって、昼休みに amazon.com で Wish List とか作ってたら、いつの間にこんな時間！　でもなんだか楽しいなあ。

自分は、精神が不安定でそこはかとない不安に駆られているときに、愚痴りながら出口を探しているような気がする。例えば日記を書いているうちに、そこはかとない不安だったものがだんだんと形を持った不安として構成されて、場合によっては気が晴れる。もちろん、壁が大きすぎることに気づいて打ちひしがれる場合もある、っていうか、そんなことのほうが多いわけだが。

精神が健全で集中力を維持できる状態にあると、日記を書く必要がなくなってきちゃう。でも、それじゃあ日記を開くたびに愚痴ばかり再現されるわけで、まるでウルトラネガティブな人間に見えてしまう。読むほうも滅入るやね。

さてどうしたものだろう。

ところで、ギャンブラーの破産の問題に悩んでいるわけです。

• 所持金 z で勝負を開始


• 1回勝ったら所持金が +1


• 1回負けたら所持金が -1


• 所持金が a になったら勝利、0 になったら負け

一連のゲームの結果を ω_z とし、その上の確率分布を p(ω_z) とすると、∑ p(ω_z) = 1 （z で始めるゲームの全体は 1）なのかどうか？　そうあってほしいんだけど、ゲームが無限に続く確率が 0 じゃない場合は違うらしい。どうして？
実際には、ゲームが無限に続く確率が 0 であることは簡単に証明できるんだけど、ゲームが無限に続く確率≠ 0 だと確率分布の総和が 1 にならないことが証明できない。
ちなみにこれはシナイの確率論の教科書に出てくる問題で、この本には、ゲームが無限に続く確率≠0 だと確率分布の総和が 1 にならないことが当たり前のように一行で書かれている。現役の頃は、そういう説明不足の教科書を読むと劣等感を感じたものだ。でも、いまは感じない。むしろ、こういう行間を埋めながら読むのが楽しい（えーと、上の話はまだ埋まってないんだけどさ）。楽しくてしょうがない。
あと、あんまり関係ないけど、この本は誤植がぼろぼろ見つかるので軽い優越感すら感じる。これは職業病か。にしても、この本は本当にクリティカルな誤植が多いのでがっかりです。ロシア語から英語に翻訳されるときに誤植が多発したんだろうなあ。

結局また愚痴じゃん。

世間はクールビズだけど、僕はもともとネクタイしない。屈辱的だから。そこで、世間の先を行くべく、シャツの裾をズボンの外に出したままで仕事をすることにした。今までも、タイムカード区間の外側では確率1でシャツの裾を出した生活だったんだけど、ここだけの話、会社にいる間は暗黙のプレッシャーに負けていた。もう負けない。まあでも、来客時なんかはそれなりの格好をしますよ。

ところで、このまま例えば5年間今の生活を続けたら、後悔する可能性のあることが2つあるということに気がついた。

設計と実装は楽しいけど、全体のスケジューリングと孤独で非能率的なバグ潰しはうげーって感じ。でも、それとは正反対の人もいて、そういう人と組んだときの仕事は最高に気持ちいい。もうそんな環境は夢なんだろうな。
そういえば会議と事務手続きとへつらいが好きな人もいる。彼らの数を減らそうって話だったんだろうね。全国的に却下されたようなので、僕の周りで達成されることもないんだろう。

僕はCDを生成して音楽を聴くことが多い。自分が利用できる環境でもっとも音楽を楽しめる方法がCDだから。金があればLPがいい。
CDプレーヤーは、もう10年以上 CDP-XA5ES をだましだまし使っている。あちこち機械的にガタがきてるんだけど、とくに不満もないんだよねえ。よく言えばフラット、悪く言えばシャリシャリな音の印象（この傾向はスピーカーの直前までの全ての機材について当てはまる）。
アンプは 自作 。真空管アンプだけど、全段差動プッシュプル という新しめの回路で、「真空管」というキーワードからイメージされる甘ったるい感じの音はしない。そういう回顧主義で真空管を使っているわけではないんです。球は 6EM7 で、写真では何社かの製品が混在しているけど、現在は Sylvania に統一した。たぶん材料費は6万円かかってない。
スピーカーは FOSTEX の FE-85K というユニットを E82 というハコに無理やりはめたもの。実売合計はペアで1万5000円くらい。ちなみにスピーカーケーブルは某所でもらったアクロテックの6N-S1040なんだけど、これってたぶんもう手に入らないんじゃなかったけ？

さて、オタク話はこれくらいにして、墓場にまで持っていくであろうCDを2枚だけ。

When Did You Leave Heaven / Lisa Ekdahl
Lisa Ekdahl はスウェーデンのシンガーソングライターで、このCDは彼女が Jazz のスタンダードを歌ったもの。舌っ足らずの英語とバックのトリオのからみが完璧。選曲も完璧。とくに Lush Life 。脳内でも日々再生しまくり。

Images / Debussy / Jacques Rouvier
さすがにもう絶版かもしれないので、リンク先の商品が別物である可能性大（ドビュッシーの『影像1』『影像2』『忘れられた影像』『版画』『ピアノのために』が収められていて、演奏は Jacques Rouvier で、レーベルが DENON で、という条件で絞ったら、これしか見つからなかった）。『影像』も『版画』もいろんな人が演奏したいろんな版があるけど、個人的にはこれが一番しっくりなじむ。やっぱり脳内でも再生しまくり。

いずれも、すでにスコアが頭に浮かぶくらい聴きまくってきた。だから、実際に再生していないときでも、気が付くと脳内でリピートがかかっていたりする。それでも聴き飽きず、ことあるごとにCDを引っ張り出してくるのは、たぶん好きな女の子の姿を想像しているだけでは満足できないのに似ていると思う。実物に会いたいし、そうでなくても写真くらいは見たい。それもピンボケしてないやつ。だから、好きな音楽については「聴く」という経験を渇望するし、どうせ聴くなら予算とスペースの許す限りベストな状態を聴き直したい。というわけで、あえて再生方法も強調してみたのでした。

もちろん、この2枚以外にも好きなCDや曲はたくさんある。でも、墓場まで持っていくほど好きかっていうと、今のところはこの2枚に限られそう。

どんな音楽を聴くのかという質問に答えるのにいつも苦労する。耳にするきっかけがあって、気に入れば、なんでも聴きます。でも、そんな答えで納得してくれる人は少ないんだよね。
この質問に直面する機会は2つに大別されると思う。もっとも多いのは、単にその場の会話をつなぐための話題として尋ねられる場合。今日は暑かったよねえ、と同じ目的なので、相手が期待するであろう返答をしておけばいい。つまり、真剣に答える必要はない。
困るのは、この質問にそれ以上の意味合いをかぶせてこられる場合だ。僕らの社会における「お前が日々聴いている音楽はなにか？」という質問には、中東において「お前の神はなんだ？」と詰問するのと同じ役割が持たされている。それで殺されることはないだろうが、答えによっては、質問者との関係が決定してしまうこともあり得る。宗教が自爆テロを可能にするような意味で音楽が重要な意味を持っている人間もいるってことがいいたいんじゃない。そういうとりたてて極端な話ではない。
個人が属するコミュニティは暗黙のうちに区分されている。もちろん主観的に。そして、多くの人にとって、コミュニティ間の境界は意外に厳格に守られていたりする。だって、自分と興味を異にする人とは話もしないし、それ以前に話をするきっかけもない。70年代生まれの自分が、ZEPPELIN をリアルタイムで生きてきたはずなのに耳にしたこともないオトナと打ち解けられる？
実際には打ち解けられる。それは、別にもっと面白いことを共感できるだろうから。だいたい、僕は別に ZEPPELIN のフリークでもないし。ただ、リアルタイムで音楽を生きてこられた人が羨ましいのは事実だけど。なんか話が曲がりだしたな。ようするに、人間は(少なくとも僕は)、聴いている音楽でも暗黙のコミュニティ境界を引いている。それだけじゃないし、そんなのはむしろコミュニティを決定する因子としては極小だけど、0には収束しない。
だから、「お前の favorite な音楽なにか」という質問にナーバスにならざるを得ないことがある。彼らに対しては真剣に回答しなければならない。しかも慎重に。でも、いつも精神誠意回答できるわけじゃないんです。なぜなら、耳にするきっかけがあって、気に入れば、なんでも聴くから。「どうやって音楽を聴いてるの？」って質問なら答えやすいんだけどなあ。しかも個人的には、音楽の種類よりも、音楽に対する態度のほうが重要だと思う。何に重要かなんて知らないけどね。

他人のメールリテラシを嘆きながら、確信的に8Mのファイルを添付してメールを送る。こりゃあ、HM氏にダブルスタンダード野郎呼ばわりをされてもしょうがないね。

今週は弊社の公開メール宛にやってくるメールを自分の作業用PCでさばかなければいけない。スパムの多さにうんざりするのは想定内なので一向にかまわない。Thunderbird のジャンクメール機能はけっこう優秀だし、ちょっとした中国語の勉強にもなるんだなこれが。ただ、某所のメールリテラシの低さをいやおうなしに見ることになってイライラするのがつらい。ふだんこの作業をしている（させられている）方の心痛も察せられて、ますます嘆かずにいられない。しかし嘆いたのは一瞬で、たんたんと転送だけこなす覚悟をした。ロボット。
最後の一文はロボットに対する差別ではないので左の方々にはくれぐれも誤解をしないようにしてください。

昨日の続き。

かといって、「次の景色」がまったく見られない状態が続くと、やっぱりフラストレーションになるわけですよ。だから、映画やゲームやマンガやアニメのような比較的安直に「次の景色」を見せてくれる媒体に逃避する。『バイオハザード』とか。
元気なときは、数学や物理の教科書を読んで「次の景色」を楽しめるようなときもある。しかし、基地外みたいに仕事して帰ってきた後なんかでは、概念や数式を「景色」に変換する処理が脳内で追いつかず、「次の景色」どころか「今の景色」すら見えない。目隠しをして、さらにガラス黒塗りの車に揺られている感じ。うんうん言いながら読み進めても、なんとか目隠しの隙間から覗ける景色さえもが絶望、みたいな。
数学書ほどでないにせよ、小説（というか文学）も、「次の景色」を提示してくれる媒体のなかでは脳や身体や時間にコストがかかる部類だと思う。そんなわけで、読まない。「もう小説には飽きたYO」とかいってうそぶく。おのずと書店の文芸書のコーナーから遠ざかる。小説のレビューとかWebで見かけてちょっと読んでみても、やっぱり小説はコストと満足とが平衡しないなという重い気分になって、さらに別の作品に手を伸ばすこともない。面白い小説に対する意欲がわかないから、情報が指数関数的に少なくなり、新しい小説を読む機会が消失して、もうすっかり小説に興味がなくなる。
この傾向は、「小説を読まない」という状態だけを見るなら、単に嗜好の問題で片付く話だろう。しかし、もともと好きだった「小説を読む」という活動が、脳や身体や時間へのコストから萎縮しているとすれば、そういう精神状態に問題があると自覚しなきゃだめでしょ。

この週末、『ラス・マンチャス通信』という小説を読んで、この傾向から脱却できそうな気がした（これが本題）。この小説が小説に「次の景色」を渇望できる心理状態を思い出させてくれたのか、そういう心理状態になったタイミングでこの小説を読むことができたのか、その辺りは不明だけど、とにかくいようにおもしろかった。そんなわけで、次に読む小説を物色中。

学生のころは狂ったように読み物をあさったけど、この5～6年の間に新たに読了した小説は5冊に満たないはずだ。読む時間がないほど忙しかったわけではなく（そういうときもあったけど）、絶対的な読書の分量が減ったわけでもない。単に興味がなかった。
おそらく、この不毛時代の最初に読んだ小説は、『百年の孤独』の新しいほうの翻訳じゃなかったかと思う。もともと好きな小説で、旧訳はさんざん読んでたけど、新訳が出たのでそっちも読んだ。馬鹿みたいにおもしろいことを再確認した。僕が読みたいのは、こういう「現実のはじっこのほうの世界」観なんだとしみじみ思った。つまり、自分にとって小説のページをくるためのモチベーションは、中学生が自転車でひたすら遠くまで走りたがるのと同じ「次の景色が見たい」という素朴な感傷なんじゃないか。で、いったんそんな気がすると自己暗示にかかってしまい、何を読み始めても先に進むモチベーションが維持できなくなってしまう。だって、『百年の孤独』以上に「次の景色」を提示してくれる作品なんて滅多にないんだもん。

ある人が『好きな言葉は四文字熟語』というとき、その人が本当に四文字熟語が好きだとすると、四文字熟語は四文字熟語ではないから、実は四文字熟語が好きではない。一方、四文字熟語が好きではないとすると、四文字熟語は四文字熟語でないから、やっぱり四文字熟語が好き（ハイチュウ率）。この『四文字熟語のパラドクス』は、命題中の「四文字熟語」を「四字熟語」に言い換えると解決する。しねえよ。基礎論すっかり忘れちゃったなあ。蒸しあついなあ。ウナギ食べたい。

いまさら気が付いたしょうもないこと。Scheme と Haskell では fold の動作が違うんですね……
どちらもこんな風に書くわけだけど（Haskellの場合は foldl）、

fold proc 種 (x_1 x_2 ... x_n)

これが Scheme では

proc (x_n ... (proc x_1 種)...)

と評価されるのに対し、Haskell では

proc (...(proc 種 x_1) ... x_n)

とみなされる。

「種とリストの要素のどちらを先に proc に渡すか」が正反対なので、除算みたいな可逆でない演算の場合に思い悩む。

gosh-rl> (fold / 128 '(8 4 2))
0.03125

Hugs.Base> foldl (/) 128 [8,4,2]
2.0

この例では Haskell のほうが感覚にマッチするなあ。Scheme で Haskell と同じことがしたい場合には無名関数を使うしかないのかしらん。

gosh-rl> (fold (lambda (x y) (/ y x)) 128 '(8 4 2))
2

なんでこんなことが気になったかというと、情報処理学会誌6月号の Haskell の数当てゲームの記事に、0～9 の自然数からなるリストを各数字が各桁に対応する1つの自然数に移す関数 pack: (a b c ..) → abc.. が foldl で実装されていたから。こんなやつ。

Hugs.Base> foldl (\ x y -> 10 * x + y) 0 [1,2,3]
123

上記のような理由で、これをそのまま Scheme に置き換えても期待した結果は得られない。

gosh-rl> (fold (lambda (x y) (+ (* 10 x) y)) 0 '(1 2 3))
60

lambda 内の x と y を逆にすればいいだけなんだけどさ。

会社のDebianサーバがいかれて復旧で一日が終わってしまった。せっかく台風なのに。それにつけても本業がちっとも進まないのはなぜだろう？

台風がくるというので定時に帰宅してみた。そしたら、きた。それにしても汚い屋根だ。
まったく関係ないけど、先々週に東北地方を車で廻ったときに撮ったストーンサークルの写真をいつの間にか自分でFlickr!に上げていたみたい。

依然として調子が悪いな。目をつぶると意識は鮮明なんだけど、目を開けていると倒れそう。というわけで、早いけど帰宅して寝る。

三河島駅前に「若松」という居酒屋がある。毎日のように店の前を通るたび、やきとりと鰻の香にため息をついてきた。なんとなく入る機会もなく、この地に移り住んで5年目、今日初めて店に入ってみた。
店内は休日の18:00すぎだというのにすでに満員状態。かろうじて空いた6人がけの座敷に相席で、念願のやきとりやら鰻やらを注文した。5年間毎日予想してきたとおり、焼がうまい。とりたてて高価な素材をつかっているわけではないのに、焼の上手さで何を頼んでも期待をうらぎらない。しかも安い。
こういう居酒屋が目の前にあるのは素晴らしいことだけど、いかんせん奥様としか利用する機会が持てないのが残念なところ。このあいだも、ちかぢか結婚する友人が東東京に越したいと言ったところ、相手に強行に反対されたらしい。東東京は恐いんだって。むべなるかな。きょうび東京の西のほうが文化的だと思われてるからな。しかし、自分の偏見では、東京は東のほうにこそ文化がかたまっていると思うんだけどなあ。

くそ暑いので献血センターですずやかに読書でもしようと思ったら、血小板を200ml抜いたところで貧血を起こしてしまった。看護婦さんが3人で処置してくれたのですぐに回復したけど、手は痺れるし、意識はふらつくし、早めに気持ちが悪いと申告してよかった。看護婦さんの話しを統合すると、どうやら暑さで脱水ぎみになったらしい。あと、個人的には、最近あんまり肉々しいものを食べてないことも理由のひとつだと思う。そこで、とりあえず帰りがけに吉野屋で牛焼肉丼。

スターウォーズ エピソード3を見にいったら、コルサント→モンテカルロみたいな連想が働いてしまって、長方形が重なるかどうかを面積の差で解決する問題（参照）ってモンテカルロで解けるじゃん。

(use gauche.uvector)
(use srfi-27)
(use math.mt-random)

;; make random vector
(define (make-random-vector! n)
  (mt-random-fill-f64vector! (make-random-source) (make-f64vector n)))

(define (ith-random randoms i)
  (f64vector-ref randoms i))

(define (ith-random-pair randoms i)
  (list (ith-random randoms (* 2 i))
        (ith-random randoms (+ (* 2 i) 1))))

;; rect as ((x0 x1) (y0 y1))
(define (point-inner-closed? point closed)
  (and (< (car closed) point) (< point (cadr closed))))

(define (pair-inner-rects? pair rects) ; not cps !
  (let ((rect (car rects)))
       (if (null? (cdr rects))
           (and (point-inner-closed? (car pair) (car rect))
                (point-inner-closed? (cadr pair) (cadr rect)))
           (or (pair-inner-rects? pair (list rect)) 
               (pair-inner-rects? pair (cdr rects))))))

;; monte-carlo
;; area as '(rect1 rect2 ...)
(define (monte-carlo area n)
  (let ((randoms (make-random-vector! (* 2 (+ n 1)))))
    (let f ((i 0))
      (if (> i n)
          0
          (if (pair-inner-rects? (ith-random-pair randoms i) area)
              (+ (f (+ i 1)) 1)
              (f (+ i 1)))))))

;; main
(define times 10000)
(define rect1 (list (list 0.0 0.2) (list 0.0 0.2)))
(define rect2 (list (list 0.1 0.3) (list 0.1 0.3)))

(define s1 (monte-carlo (list rect1) times))
(define s2 (monte-carlo (list rect2) times))
(define s1-and-s2 (monte-carlo (list rect1 rect2) times))

(display (< s1-and-s2 (+ s1 s2)))

=> #t

これなら長方形を実数で指定できる！　ハエを殺すのに焼夷弾を持ち出すみたいな話だってのはわかってますって。

Haskell と継続について。いただいたコメントによるとモナドで継続を実現できるんですね。Haskellのコードで理解するのはつらいので、ここを読み返してみた。

f: x→y により実行される計算の継続は、f': x→((y→k)→k) となるような f': x→M(y) と見なせる。ここで M はモナド則を満たす。という理解でいいのかな。

にしても、これがHaskellのプログラミングで意味があるのかどうかは、あいかわらずよくわからない。実際に Haskell でプログラミングしているわけじゃないので、わからなくて当然といえばそれまでなんだけど、応用を生み出す妄想力の欠如を我ながら痛感するところ。ところで、あちこちで「Haskell では遅延評価があるから無理に継続引き渡しにしなくてもいい」って言及されているのは、まるで継続と遅延評価とが同じ概念の2つの表現みたいに読めてしまうから、いけないと思う。実際には、評価の順番が問題視されなければ継続引き渡しで処理が最適化されるわけじゃないってだけのことだと思うんだけど、僕のほうが勘違い？

だらだらとWebを見ながら、howm形式でばしばしメモるためのBookmarklet。Firefox1.0.4でのみ動作を確認。改行が便宜的なものであるのはいわずもがな。

javascript:
var pageTitle=document.title; 
var pageURL=document.URL; 
var userSelection=document.getSelection(); 
function nomdic(cc){if(cc<10){cc='0'+cc};return cc}; 
var nowDate=new Date(); 
var yyyy=nowDate.getFullYear(); 
var mm=(nowDate.getMonth()+1);
var dd=nowDate.getDate(); 
var hh=nowDate.getHours(); 
var min=nowDate.getMinutes(); 
var ss=nowDate.getSeconds();
var howmName=yyyy+'-'+nomdic(mm)+'-'+nomdic(dd)+'-'+nomdic(hh)+nomdic(min)+nomdic(ss)+'.howm';
var howmDate=yyyy+'-'+nomdic(mm)+'-'+nomdic(dd); 
var openWin=window.open('',howmName,'innerWidth=600,innerHeight=400,scrollbars,menubar'); 
openWin.document.writeln
(howmName + '<br/>= ' + 'URLメモ ' + pageTitle + '<br/>' +  '['+howmDate+']' + ' &lt;&lt;&lt;  '
+ pageURL + '<br/><br/>' + userSelection); void(openWin.document.close());

本当は、$HOME/howm/以下へ自動的に吐き出したいんだけど、javascriptだけでは無理で、XPCOMを使うしかないっぽい。それにしてもこういうのを書くと生気を吸われるきもち。

今年栽培している唐辛子は、やたらにでかい。奥様は、実はこれはシシトウだと言い張ってるけど、スーパーで売ってる並のシシトウよりでかい。で、唐辛子の種類をいろいろ調べたら、でかいのもあるらしい。きっといまに赤くなるに違いない。ところでピーマンって、フランス語の唐辛子(piment)が語源だったのね。

Joelさんの「ハンガリアン表記を見直そうぜ」というコラム。
Joel on Software : Making Wrong Code Look Wrong

えらく誤解されてるような気がするけど、最後まで読むと、要するにこういう主張でしょ？

• 変数や関数には一貫した意味のわかる名前を付けようね


• 一行ずつ目でバグをつぶせるから（本来の）ハンガリアン記法は意外にお勧め

ハンガリアン記法にまつわる憎悪はひどいから、この主張は rant にしたって誤解されやすいよ。本人も確信犯だと思うけど。まあ、個人的にはハンガリアン記法にうらみもないし、プロのコーダでもないから、その宗教論争はとくにどうでもいいや。

むしろ、彼がハンガリアン記法を持ち出してきた理由付けがちょっといけてると思った。つまり、ここではコーディングスタイルが対象なんだけど、人間の認識力が何か対象に意味を見出せるようになるには没入経験が必要ってとこ（ところで多分に鹿野による拡大解釈が入っているから本文を読んだほうがいいと思う）。彼のパン工場のバイト経験もそうだけど、何でも最初に接したときには混沌であることしか認識できない。とにかく混沌を相手にもがいているうちに、そのうち認識が意味を持つようになる。認識のフィルタができるとも言える。プログラミング言語だけでなく、自然言語はもちろん人間関係でも同じ。で、Joelさんのノリは、そうやって認識できるようになったら（モノホンの）ハンガリアン記法がけっこういけるんだよ、というように読める。クサヤとかフナズシが癖になるのと似てるかも。それじゃあだめだよどんな人でも読みやすいコードにしなけりゃっていう反論はあり得る。ただし、Joelさん自身が「読めねー奴はどうやったて読めねーから論外」という言い方もしている？ので、やっぱりこれは rant なんだろう。

労働が限界生産力と限界不効用の均衡だけで決定する時代がうらやましい。って、最近こんな愚痴ばっかり。労働者である自分の限界不効用は超過してるし、企業が自分に求める限界生産力は超えていると思うけど、もはやいずれも実質賃金とかけ離れている。
要するに、ここのところ感じているのは年収の問題だということに気がついた。しかも、今後年収が増加する希望もない（これは業界の問題というより弊社の問題）。
これまでもうすうす気が付いてたけど、先月からいろいろあって、はっきりした。ひとつには父親の死がある。生涯にわたって年収300万円で幸せなのは、あくまでも不測の事態が起こらない世界の話だ。こう書くと、不測の事態に備えるために保険に入りましょうって言われる。長谷川京子や矢田亜紀子はかわいいけど、生命保険は勘弁してください。保険は年収300万円の労働者にやさしいとはいえない。社会保険も不公平の塊だし。いずれにしたって、むー。
コドモが生まれたらどうするか、というのも、同じ意味で年収300万円にやさしくない不測の事態だと思う。要するに、自分以外の身内（この場合は奥様と生まれてくるコドモ）に生じる不測の事態を乗り切るには、どうあがいたって現金がいる。
これら（自分以外の身内に起こる不足の事態）に比べれば、あとはマイナーな問題。人生を豊かに暮らすためには資金が必要なんだとか、自分は現金が欲しいんじゃない正当な評価が欲しいだけなんだとか、老後の安泰だとか、生きる意味だとか。
こうなったら業務時間中にデイトレーディングにいそしむか、それとも、もっとストレートに副業をするか。でもそんな余裕はないのです。

アジアンランチ 。ずいぶん前から会社の近くに車が止まるようになって、気になってた。いつも行列で、しかも並んでるのが女の子ちゃんばっかりだったので、むしろネガティブに気になってたんだけどね。女の子ちゃん向けのジャンクフードはカドが取れたやつが多い。雰囲気だけのアジア料理は勘弁ならなくて、むしろ徹底的にジャンクなものを食わせてほしいんですが。
で、このアジアンランチは良心的だと思った。ご飯が日本人好きするベタベタであることを除けば、カレーや炒め物は最低限のジャパナイズに抑えてあるように思う。にしても、粘着な米が好きな日本人って多いよなあ。僕はササニシキが好きだったんだけど、ササニシキってすでに入手困難な希少種じゃない？　スーパーに置いてある玄米はコシヒカリとあきたこまちだけ。まあ、あきたこまちはおいしいからいいけど。ところで我が家で炊く米が100%玄米なのは、単にそのほうが旨いからであって、健康志向とは何の関係もありません。

ところで、親がコシヒカリばっかり有り難がって食わせるから、オトナより種族としてブランド志向が強いコドモらはしょーもない発想をするようになるらしい。

なんで、お米を全部有名な「コシヒカリ」とかにしないの？

Ans. それは、コシヒカリが好きじゃない人もいるからです。

今月の初めに八ヶ岳に登ったんだった。

• 白河原から横岳


• ツクモグサ


• 爆裂火山口

ツクモソウが咲いているのは珍しいらしい。

いや、別に攻めているわけでも否定しているわけでもなくて、人様から金銭をいただくということの重みを痛感してもらいたいだけなんです。

昨日早く帰って何となくテレビを見ていたら、サラリーマンの給与所得の平均が440万円というデータが紹介されていた。で、今日は住民税の超過分を支払いに郵便局に行って、長い待ち時間を自分の所得明細を眺めながら過ごしてたわけですよ。マーマーマーマーお金がない♪
なきそうになった。冷静に考えると平均の80%にも届いてない。さすがは斜陽産業。

• 自分の意思で始めた個々のプロジェクトは面白いし、心身ともに糧になっている。たぶん社会的意義もある


• 業界/会社の収益構造が崩壊しているので、あきれるくらい頭の悪そうな仕事も襲い掛かってくる。しかもその仕事は社会や地球環境にとって悪。決定的に

これで儲かってれば、まだジレンマを無視してでも働けそうなんだけどなあ。でも実際にはそうじゃない。前の会社を辞めたのも似たようなジレンマだったっけ。給料は圧倒的によかったけど、あの会社には心底付き合いきれないと思った。結局ジレンマで辞めたんじゃなく、ジレンマが崩れて辞めたってことか。

ところで「マーマーマーマーお金がない」は kin-dza-dza に出てきた唱だと信じてたんだけど、この映画を見た人の誰もがそんな唱はなかったと言って冷たい目で見るのはなぜだろう。

いっかい掴みかけた継続引き渡しの概念を失いそうだったので脳内を保守。お題は、"A Gentle Introduction to Haskell" で紹介されている Haskell の quicksort を Scheme に移して、さらに末尾再帰に書き直すこと。そもそもの Haskell のコードはこれ。

quicksort  []           =  []
quicksort (x:xs)        =  quicksort [y | y <- xs, y<x ]
                        ++ [x]
                        ++ quicksort [y | y <- xs, y>=x]

まずは同じものをSchemeで。

(define (quicksort ls)
  (if (null? ls)
      '()
      (append (quicksort (filter (lambda (x) (> (car ls) x)) (cdr ls)))
              (list (car ls))
              (quicksort (filter (lambda (x) (<= (car ls) x)) (cdr ls))))))

Haskell の表記に比べると filter とか出てくる辺りが痒い。けど仕方ない。とにかくこれを末尾再帰にしてみる。

(define (quicksort/cps ls k)
  (if (null? ls)
      (k '())
      (quicksort/cps (filter (lambda (x) (> (car ls) x)) (cdr ls))
        (lambda (ls-lower)
          (quicksort/cps (filter (lambda (x) (<= (car ls) x)) (cdr ls))
            (lambda (ls-upper) (k (append ls-lower (list (car ls)) ls-upper))))))))

Haskell では継続を安直に捕まえられないのだろうか？
やっぱり集合を扱う際には最初の Haskell のコードが一番しっくりくる。集合論のノリで問題を解きたい場合は Haskell の考え方のほうが扱いやすいのかもしれない。Scheme でも Haskell チックに集合を定義できるマクロを用意すれば同じなのかな。でも、可算無限集合が出てくるたびに delay で関数を定義し直すのはいやだな。

所用で早く帰ったところ奥様が夕ご飯を食べていないというので、日暮里の吉野屋に入った。あいかわらずこの店はレベルが高い。味もそうだけど、店員のレベルも高い。僕はいつも七味唐辛子を振る際に容器のネジ蓋をはずして使うんだけど(そのままだと口が小さくてたくさん出ないから)、今日は手がすべって蓋を味噌汁の中に落してしまった。そんなイリーガルな使い方をしている自分のほうが悪いのに、「火傷とかしてませんか」といって手際良く蓋を回収してくれる。プロだね。支払のときも、980円の会計に300円の株主優待券を4枚出したら、「優待券はおつりが出ないから」といって、ちゃんと1枚を戻してくる。「万札しかないから4枚払いますよ」といっても、笑顔で奥に行って9920円の釣銭を用意してきてくれる。味噌汁こぼした客が優待券で会計するという時点で店によってはいやな顔をするだろうし、吉野屋は万札を受け取ると必ず奥に持って行かなければならないので、そもそも万札を出す客自体が面倒なはずだ(しかも80円の支払に万札！)。ただでさえ夕食どきで忙しいってのに。
こういう店がある限り、この会社に投資して正解だと思う。そして吉野屋さん、素晴らしい接客をしてくれた日暮里店Mさんの時給を上げてあげてください。

長方形が重なるかどうかの問題（参照）。数式は陰気臭いからコードにしろという圧力があったのでがんばった。結局、3時間以上かかった。ほとんどの時間を長方形の表現に悩んだ気がする。で、まあ自然数の直交グリッドに沿ったものだけでいいじゃんということにして、あきらめました。有理数の直交グリッド（つまりコンピュータディスプレイ）までなら同じノリで解決できると信じる。だって定積分ってそういうノリだし（ようは言い訳）。でも、一般のHausdorff空間で解決しろといわれているわけでもないし、そもそも長方形が定義できない空間じゃ意味ないしね。

(use srfi-1)

;; 長方形は対角線の端点（にあるマス）で定義: ((x0 y0) (x1 y1))
;; ただし、 右上がりの対角線で定義 i.e. x0 <= x1, y0 <= y1
(define-syntax rect?
  (syntax-rules ()
    ((_ rect ...)
       (and (and (<= (caar rect) (caadr rect)) (<= (cadar rect) (cadadr rect))) ...))))

(define (expand-x from-ls to-ls)
  (let ((xfrom (car from-ls)) (xto (car to-ls)) (yfrom (cadr from-ls)))
    (map (lambda (x) (cons x yfrom))
      (let f ((xcurrent xfrom))
        (let ((xnext (+ xcurrent 1)))
          (if (> xnext (+ xto 1))
              '()
              (cons xcurrent (f xnext))))))))

(define (expand-rect-diag from-ls to-ls)
  (let ((x-ls (expand-x from-ls to-ls)) (yfrom (cadr from-ls)) (yto (cadr to-ls)))
    (let* ((ycurrent yfrom) (ynext (+ ycurrent 1)))
      (if (> ynext (+ yto 1))
          '()
          (append x-ls 
                  (expand-rect-diag (list (car from-ls) ynext) to-ls))))))

(define (expand-rect rect-with-diag)
  (let ((from-ls (car rect-with-diag)) (to-ls (cadr rect-with-diag)))
    (expand-rect-diag from-ls to-ls)))

;; 長方形からなる領域の面積（=マスの数）
(define-syntax sumup-rect
  (syntax-rules ()
    ((_ e1) (length (expand-rect e1)))
    ((_ e1 e2 ...) 
     (length (lset-union equal? (expand-rect e1) (expand-rect e2) ...)))))

;; 2つの長方形が交わってるかどうか
(define (intersect? rect1 rect2)
  (if (rect? rect1 rect2)
    (< (sumup-rect rect1 rect2) (+ (sumup-rect rect1) (sumup-rect rect2)))))

できたかな？

(define rect1 (list '(0 0) '(3 2)))
(define rect2 (list '(3 3) '(4 4)))
(define rect3 (list '(1 1) '(4 4)))

gosh-rl> (intersect? rect1 rect2)
#f
gosh-rl> (intersect? rect1 rect3)
#t

そうそう。ようやく Gauche-readline の存在を知りました。画期的です。横田さん、ありがとうございます。

hisashim さんが 長方形Aと長方形Bが一部でも重なるかどうかを判断する条件式 に 挑戦してた 。数式なら5分でいいよ。コードに落とすには1時間以上かかると思う（あくまでも自分のスキルの限界）。

  長方形A, Bの面積を|A|, |B|とする。

  |S| =def ∫(x,y) {(x, y) ∈ A ∪ B} dxdy

  |S| ＜ |A| + |B| ⇒ A と Bは交わる

位相をかじったことがある学生ならこういう思考になりそう。ちなみに上記の判定式では、AとBがぴったり接触している場合を「交わらない」と見なしている。

ちょうしにのって、何年か前にシベリアのバイカル湖で撮ったスナップもスキャニングしてみた。これは OLYMPUS PEN F + E Zuiko 38mm F2.8（いわゆるパンケーキ）で、TRY-X。ネガはきずきずだったので、ちょこっと修正。あとは Web 用に解像度を下げている。

わけあってスキャナー（EPSON GT-X800）を購入した。フラットヘッドなのに4800dpiで35mmのポジフィルムがスキャニングできる。そこで、昔とったポジを取り込んでみた。そのままだと150MバイトあってFlickr!に上げられないので横800ピクセルまで圧縮しているけど、それ以外の画像処理はとくにしていない。



前景の山脈の尾根から滲む空気感。やっぱりポジフィルムって圧倒的に情報量が多いのね。ちなみにこのときの撮影機材は、PENTAX SPF + MC FRECTAGON 35mm だったと思う。

結局、遅延評価バージョンを書いてみた。

; lcar, lcdr, ltake は "Gauche リファレンスマニュアル" の例を流用
; http://www.shiro.dreamhost.com/scheme/gauche/man/gauche-refj_90.html#SEC94
(use srfi-1)

(define (lcar lis)   ;; lazy car
  (car (force lis)))

(define (lcdr lis)   ;; lazy cdr
  (cdr (force lis)))

(define (ltake lis n)  ;; lazy take
  (if (<= n 0) '() (cons (lcar lis) (ltake (lcdr lis) (- n 1)))))

(define (lfilter pred ls)  ;; lazy filter. i know it's not cps.
  (if (pred (lcar ls))
      (cons (lcar ls) (delay (lfilter pred (lcdr ls))))
      (lfilter pred (lcdr ls))))

(define (integers-above num)
  (let mkls ((x num))
    (delay (cons x (mkls (+ x 1))))))

(define primes
  (let prime-list ((ls (integers-above 2)))
    (cons (lcar ls)
          (delay (prime-list (lfilter (lambda (x) (> (modulo x (lcar ls)) 0)) (lcdr ls)))))))

gosh> (ltake primes 25)
(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97)

お膳立てが多いけど、primes プロシージャに関しては Haskell バージョンと同等になったと思う。

情報処理学会誌2005年4月号の『関数プログラミングの妙味』（PDF）という記事を読んでいたら、素数を求めるこんな Haskell スクリプトが紹介されていた。

primes = sieve [2..]
  where sieve (s:ss) = s:sieve (filter (\x -> x `mod` s > 0) ss)

Main> take 25 pimes
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79,83,89,97]

日本語はおかしな和田さんだけど、これはなんだかかっこいい。Scheme でも同じことがしたい。

(let prime-list ((ls '(2 3 4 5 6 7 8 9 10 11 12)))
  (if (null? ls)
    ()
    (cons (car ls)
          (prime-list (filter (lambda (x) (> (modulo x (car ls)) 0))
                              (cdr ls))))))

=>(2 3 5 7 11)

遅延評価が当たり前の Haskell と違って無限リストを自然に扱えないのがつらいところ。というわけで delay を使ってみる。とりあえず自然数全体の集合（リスト）はこんな感じかな。

(define int-inf
  (let mkls ((x 0))
    (delay (cons x (mkls (+ x 1))))))

『Gauche リファレンスマニュアル』の遅延評価の例にある "ltake" を使わせてもらえば、ゼロから始まる任意の長さの自然数列が得られる。

gosh> (ltake int-inf 20)
(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)

でも、これを最初の prime-list に組み込むのはめんどくさいな。そもそも、自然数列を得るだけなら遅延評価を使わなくてもいいような気がしてきた。というわけで

(define (primes-under num)
  (let prime-list ((ls (let mkls ((x 2)) 
                         (if (<= num x) '() (cons x (mkls (+ x 1)))))))
    (if (null? ls)
        ()
        (cons (car ls)
              (prime-list (filter (lambda (x) (> (modulo x (car ls)) 0))
                                  (cdr ls)))))))

=>(primes-under 100)
(2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97)

うーむ。かっこよさとしてはちゅうくらいか。遅延評価のサポート具合もプログラムの抽象化に大きく影響するらしい。

再び、HTMLをプレビュー目的だけに使うときの姑息なテクニックをはっけん。
今回は、img タグで埋め込んだ図が印刷したときにページで分断されてしまう問題を回避したい。CSS 2.0では page-break-inside:avoid というプロパティも用意されているんだけど、Firefox ではサポートされていないっぽい。少なくとも有効にならない。page-break-after:always は利くのにね。

<table><tr><td><img src="./fig/foobar.gif"/></td></tr></table>

ようするにtableのセル内では改ページされないみたい。

1年後にこのエントリを見て、あの頃は若かったなと恥じること。

「優秀な人たちはどこかでつながってる」は、僕らの生活している世界をモデルにすると証明可能な命題に思える。この命題の対偶を取ると、「どこでもつながっていない人たちは優秀ではない」。つまり、最初の命題が正しいと仮定すると、ヒッキーは優秀ではない。そうだったのか……

すばらしい。実のところ、折曲げポイントをどうやって見定めればいいのか、こっそり悩んでいたところ。スパイラルはだんだん小さくなっていくのがきれいなので、まず文字列を逆転させてから2〜10文字くらいの範囲で一番小さなループ(8文字で構成されるもの)が描けるか調べ、描けなかったらちょっとループを大きくして再挑戦し、描けたらその地点からもうちょっと大きなループに挑戦し……という戦略を妄想していたんだけど、最初に全探索で候補を探してから「きれいさ」に適ったものを見付けるという発想はまったくできませんでした。ある意味、富豪的プログラミング？

まったくパッキング(!=ハッキング)してない。どうしよ。

HTMLで日本語を両端ぞろえにレイアウトしたい。CSS2.0の text-align:justify で簡単に実現しそうだが、英語文化のCS技術がそのまま他国語ですんなり通用することはあり得ない。
なんで text-align:justify がダメかというと、そもそもは組版文化の違いに起因するようだ。奴らは、一行にアルファベットをレイアウトするとき、単語の間のスペースを調整して組版する。 だからtext-align:justify でも、当然のように単語間のスペースしか調整してくれない。そのため、日本語のような単語区切りのない言語の行幅を調整することはできない。
CSS 3.0では、text-justifyというプロパティが用意されるらしい。こいつは、CJKおよびハングルのレイアウトを調整できるような実装が求められそう。どうやらIEでは勝手に実装しているみたいだが、そんなものは使いたくない。
しかたがないので、こういう荒業しかないのか？

line.gsub! /(\w)/e, '\1 '

Webで情報を提供する場合には絶対に避けるべき方法だよなあ。明らかに問題がある。今は情報公開のためにHTMLを使っているのではないので、もうこれでいいや。

クランベリージュース（190cc缶）が近くの酒屋に110円で売っていたので飲んでみた。もっとすっぱいのがよかった。

肌寒いので、ユニクロのジャケット（3900円）を羽織ってきた。会社でTさん（20代女性）に、今日はおしゃれですわね、と言われた。いつもはそんなにダサいのかよ。

PowerPointで書かれたスライド達を一枚ずつgif画像として取り出したい。それ自体はPowerPointのメニューから［名前付けて保存］できるんだけど、日本語の「スライド1.GIF」みたいなファイル名で何百枚とかGIF画像ができるので萎える。しかもextensionが大文字だしい。この仕事には、Rubyしかないよね（Pythonでこういうのをサポートするツールもあるにはある）。

for i in `ls -A`; do ruby -e"old=ARGV[0]; new=old.gsub(/.*?(\d{1,2})\.GIF/, '\1.gif'); File.rename(old, new)" $i; done

これは備忘録ではなく、憤慨の記録でうｓ。

引き続きcall/ccに悩み中。Dibvig本の「3.5 内部定義」には、本文で定義したcalcというプロシージャをcall/ccを削除して定義し直せ、という練習問題がある。call/ccを使ったバージョンは以下のとおり。ちなみに、これは本文のオリジナルバージョンではなく、問題3.5.2の前半までに対する僕の回答。

; Dibvig-3.5.2-1
(define calc1
  (lambda (exp)
    (define-syntax complain
      (syntax-rules ()
        ((_ e1 e2 e3) (e1 (list e2 e3)))))
    (call/cc 
      (lambda (ek)
        (define apply-op
          (lambda (ek op args)
            (op (do-calc ek (car args)) (do-calc ek (cadr args)))))
        (define do-calc
          (lambda (ek exp)
            (cond
              ((number? exp) exp)
              ((and (list? exp) (= (length exp) 3))
               (let ((op (car exp)) (args (cdr exp)))
                 (case op
                   ((add) (apply-op ek + args))
                   ((sub) (apply-op ek - args))
                   ((mul) (apply-op ek * args))
                   ((div) (apply-op ek / args))
                   (else (complain ek "invalid operator" op)))))
              (else (complain ek "invalid expression" exp)))))
        (do-calc ek exp)))))

gosh> (calc1 '(div 2 3))
=> 0.6666666666666666

gosh> (calc1 '(div (div (div 3 2)) 2))
=> ("invalid expression" (div (div 3 2)))

エラー処理もうまくいっている。で、ここからcall/ccを削除したいんだけど、単純に次のようにしてはダメらしい。

; Dibvig-3.5.2-2
(define calc2
  (lambda (exp)
    (define-syntax complain
      (syntax-rules ()
        ((_ e1 e2) (list e1 e2))))
    (let ()
      (define apply-op
        (lambda (op args)
          (op (do-calc (car args)) (do-calc (cadr args)))))
      (define do-calc
        (lambda (exp)
          (cond
            ((number? exp) exp)
            ((and (list? exp) (= (length exp) 3))
             (let ((op (car exp)) (args (cdr exp)))
               (case op
                 ((add) (apply-op + args))
                 ((sub) (apply-op - args))
                 ((mul) (apply-op * args))
                 ((div) (apply-op / args))
                 (else (complain "invalid operator" op)))))
            (else (complain "invalid expression" exp)))))
      (do-calc exp))))

gosh> (calc2 '(div 2 3))
=> 0.6666666666666666

gosh> (calc2 '(div (div (div 3 2)) 2))
=> *** ERROR: operation / is not defined between ("invalid expression" (div (div 3 2))) and 2
Stack Trace:
_______________________________________

エラー処理がうまくない。一回だけエラー処理をしているけど、そこで抜けられていない。apply-opの再帰を継続引き渡しで書き直せばいいのかな？

なんだかやるせないのでCDを買った。たいていアタリハズレが大きいけど、今日はどれもアタリ。これだけアタリだとうれしくなる。
MESSIAEN: Preludes, et al
CANTELOUBE: Chants d'Auvergne
ADAMS: Grand Pianola Music, REICH:Vermont Counterpoint, Eight Lines
Mozart: Piano Sonatas
System of a Down: Mezmerize
Marilyn Monroe: I Wanna Be Loved By You
しかし、どれもアタリなのは、購入するときに冒険しないからともいう。Naxos の Messiaen はダブったし（弟に貸してたのを忘れてた）。結局好きなものばかり物色してればハッピーなのかもしれない。

そうか。リストに0があったときに掛け算を脱出しているのかどうかは、こうすればわかるのか。

gosh> (product/cps '(2 3 4 0 'a) 1)
0
gosh> (product/cps '(2 3 4 'a) 1)
*** ERROR: real number required: (quote a)

どうやら脱出はできているようだ。

継続がらみは悩ましい。Kent Dibvigでは、call/ccの最初の例として、次のような局所的脱出が挙げられている。

(define product
  (lambda (ls)
    (call/cc
      (lambda (break)
        (let f ((ls ls))
          (cond
            ((null? ls) 1)
            ((= (car ls) 0) (break 0))
            (else (* (car ls) (f (cdr ls))))))))))

(product '(2 3 4) => 24

これはつまり、リストの途中に0が出てきたら、その時点の継続を0に設定して返すというものだ。そうすれば残りの掛け算をせずにfの再帰から抜けられる、というのがメリットらしい。ここまではわかる。
わからないのは、単にリストの途中に0が出てきたら抜けるという動作をさせたいだけなら、次のコードでも一緒じゃないのか？ という点だ。

(define product
  (lambda (ls)
    (let ((ls ls))
      (cond
        ((null? ls) 1)
        ((= (car ls) 0) 0)
        (else (* (car ls) (product (cdr ls))))))))

もっとも、これだと末尾再帰じゃなくて気持悪いので、こうは改良したい。

(Define product/cps
  (lambda (ls k)
    (let ((ls ls) (k k))
      (cond 
        ((null? ls) k)
        ((= (car ls) 0) 0)
        (else (product/cps (cdr ls) (* (car ls) k)))))))

(product/cps '(2 3 4) 1) => 24

この三つ目のバージョンでは継続引き渡しを使ってるつもりなんだけど、このように末尾再帰で書けることをもってして継続のメリットだと主張されるならとてもクリアだ。となると、この例における call/cc のありがた味っていったい……

さらに、もう一つ、Kent Dibvigの継続の解説でさらに分からなくなることがあって困る。本の中では、最初のリストの掛け算を継続引き渡しで書き直す例も説明されてるんだけど、それがどうにも妙ちきりんなんだよね。

(define product/cps
  (lambda (ls k)
    (let ((break k))
      (let f ((ls ls) (k k))
        (cond
          ((null? ls) (k 1))
          ((= (car ls) 0) (break 0))
          (else (f (cdr ls) (lambda (x) (k (* (car ls) x))))))))))

(product/cps '(2 3 4) (lambda (x) x)) => 24

もしかしたら、こういう風に「自分自身を返す継続」を使うことが推奨されるのだろうか。それとも、単に僕の解釈が間違っていて、上記の3番目のバージョンでは継続引き渡しになっていないのだろうか。ああ、そもそも3番目のバージョンは「リストの途中に0があったらその時点で後続の掛け算をやめる」という仕様を満たしていないのかもしれないのか。Gauche に Chez Scheme のような trace があればなあ。どうやって作るんだろう。

一日を一生のつもりで生きろというのはやめてください。

一昨日のエントリのように文字列をうねうね曲げる。とりあえず1バイト文字バージョンで妥協。あとは、折り曲げるポイントを割り出すための仕組みが必要か。

; (fold-puts '("a" ("b" . "l") "c" "d" ("e" . "d") "f" "g"))
; =>
; edcb
; f  a
; g  
;
(use srfi-1)

(define culc-room-space
  (lambda (ls)
    (cons
      (if (>= (car ls) (cadr ls))
          (car ls)
          (cadr ls))
      (if (>= (caddr ls) (cadddr ls))
          (caddr ls)
          (cadddr ls)))))

(define count-direction
  (lambda (ls)
    (let f ((ls ls) (height+ 1) (height- 1) (width+ 1) (width- 1) (direction "u"))
      (if (null? (cdr ls))
          (cond ((equal? direction "l")
                   (list height+ height- (- width+ 1) width-))
                ((equal? direction "r")
                   (list height+ height- width+ (- width- 1)))
                ((equal? direction "u")
                   (list (- height+ 1) height- width+ width-))
                ((equal? direction "d")
                   (list height+ (- height- 1) width+ width-)))
          (if (and (pair? (car ls)) (dotted-list? (car ls)))
              (cond ((equal? (cdr (car ls)) "l")
                      (f (cdr ls) height+ height- (+ width+ 1) width- "l"))
                    ((equal? (cdr (car ls)) "r")
                      (f (cdr ls) height+ height- width+ (+ width- 1) "r"))
                    ((equal? (cdr (car ls)) "u")
                      (f (cdr ls) (+ height+ 1) height- width+ width- "u"))
                    ((equal? (cdr (car ls)) "d")
                      (f (cdr ls) height+ (+ height- 1) width+ width- "d")))
              (cond ((equal? direction "l")
                      (f (cdr ls) height+ height- (+ width+ 1) width- direction))
                    ((equal? direction "r")
                      (f (cdr ls) height+ height- width+ (+ width- 1) direction))
                    ((equal? direction "u")
                      (f (cdr ls) (+ height+ 1) height- width+ width- direction))
                    ((equal? direction "d")
                      (f (cdr ls) height+ (+ height- 1) width+ width- direction))
                    (else
                      (f (cdr ls) height width direction))))))))

(define make-room          
  (lambda (size)
    (do ((m (make-vector (car size)))
         (i 0 (+ i 1)))
        ((= i (car size)) m)
        (vector-set! m i (make-vector (cdr size))))))

(define puts-room
  (lambda (m)
    (do ((i 0 (+ i 1)))
        ((= i (vector-length m)))
        (print
          (let ((column (vector-ref m i)))
            (do ((i 0 (+ i 1)))
                ((= i (vector-length column)))
                (let ((char (vector-ref column i)))
                  (if (string? char)
                      (display char)
                      (display " ")))))))))

(define set-char-at!
  (lambda (room i j character)
    (vector-set! (vector-ref room i) j character)))

(define fold-puts
  (lambda (ls)
    (let* ((dirs (count-direction ls)) (m (make-room (culc-room-space dirs))))
      (let puts ((i (- (car dirs) 1))
                 (j (- (caddr dirs) 1))
                 (ls ls)
                 (dir "u"))
        (if (null? (cdr ls))
            (puts-room m)
            (if (and (pair? (car ls)) (dotted-list? (car ls)))
                (begin 
                  (set-char-at! m i j (caar ls))
                  (cond ((equal? (cdr (car ls)) "l")
                           (puts i (- j 1) (cdr ls) "l"))
                        ((equal? (cdr (car ls)) "r")
                           (puts i (+ j 1) (cdr ls) "r"))
                        ((equal? (cdr (car ls)) "u")
                           (puts (- i 1) j (cdr ls) "u"))
                        ((equal? (cdr (car ls)) "d")
                           (puts (+ i 1) j (cdr ls) "d"))))
                (begin
                  (set-char-at! m i j (car ls))
                  (cond ((equal? dir "l")
                           (puts i (- j 1) (cdr ls) "l"))
                        ((equal? dir "r")
                           (puts i (+ j 1) (cdr ls) "r"))
                        ((equal? dir "u")
                           (puts (- i 1) j (cdr ls) "u"))
                        ((equal? dir "d")
                           (puts (+ i 1) j (cdr ls) "d"))))))))))

しかしまたみにくいなあ。やたらにcondだらけ。屈折した文字列をディスプレイするのに必要なマスの大きさを求めるのと、実際に屈折させた文字列を書き出すところは、同じようなcondが続く。こういう場面で、きっとマクロを使うに違いない。
ところでこんなものを曝すことに第三者的な意義なんてありえない。だから、これは自身のモチベーション維持としての役割なんだろう。

きゅうじつにしなければいけないしごとは
                                    い
                                    み
  して、いつまでもいつまでもやる    の
  そ                          き    な
  。るなにちもきいらくてくおおがのもい
                              お                            
        てさらにくらいき      き
        っ            ぶ      ず
        なくながんかじんどんど、
                      に
              ますや  さ
              す  つ  い
              まてれまな
                  て
                  い
                  く
                  スパイラル

数年ぶりの知人から連絡がきて、その人間が勤めている会社のURLがわかると、つい採用情報をクリックしてしまう罠。サラリーマンでいる限り、どこも一緒だろ。

十年以上にわたって、この三日間ほど父親に話しかけたことはなかった。決していい父親ではなかったが、自分もいい息子ではなかった。それだけのこと。

『非決定性 選択公理』ってキーワードでGoogleしても電波は感じられないのか。むう。

肩こりがひどくて水海道（茨城）の病院にいったら、脳波を測定されて精神障害で強制入院させられそうになる。
という夢で目が覚めた。

眠たいという欲求は現実からの逃避を内包している。

なんのためにはたらいているのだろう。

* 自分のため
* 他人のため
* 社会のため
* 知人のため
* 会社のため
* お国のため
* 家族のため
* お客のため
* ひまつぶし

順不同ですあしからず。

逓信総合博物館へ収蔵品の写真を借りにいく。たいへん親切に対応していただきありがとうございました。

上野の科博は140分待ちの行列ができてたけど、ここは静か。それでも、普段と比べると多いらしい。みんな博物館にいくのはやめてください。どこもかしこも科博みたいになったらがっかりだ。

逓信総合博物館は、NTTとNHKと郵政公社という、並べるといい感じに何かが凝縮される3つの団体が共同で運営している。ただし、館内の展示はすっかり分断していて、通信と放送の融合なんていうキーワードとは無縁の世界になっている。企画展ではいろいろと協力するのかな。展示のおもしろさは、NTT > 郵政公社 >= NHK という感じ。なにせNHKのブースで印象的だったは、モニターにカードキャプターさくらを垂れ流してるコーナーだったから。

博物館が工夫すべきなのは、見た目の親しみやすさではないと思う。珍しいものを、「それがどういう意味で価値を持ち、単に珍しいだけじゃない」とわかるように展示してほしい。いかにも「わかりきったことだし努力しています」って言われそう。でも、展示物の脇の説明とか、博物館が提供してくれる解説が微妙に読みにくいと感じているのは、僕だけじゃないはず。ほかの展示物との関係をもっと明確に示してくれるとか、そういう工夫だけでもいいんだけど。
たとえば、『強構造化ダニエル式ラダー』と『非構造化リズ式ラダー』が展示されていて、『強構造化ダニエル式ラダー』の解説プレートに「『非構造化リズ式ラダー』の欠点を補って2150年にJ.ダニエルにより開発された」とだけ書いてあっても、『非構造化リズ式ラダー』が何なのか閲覧者にはわからないのがオチだ。『強構造化ダニエル式ラダー』の直前に『非構造化リズ式ラダー』が陳列してあったのかもしれなけど、そんなことはたいてい覚えてない。もし『強構造化リズ式ラダー』も置いてあったら、まちがいなく専門家以外には区別ができず、博物館を出た瞬間（それどころか展示物を見た次の瞬間）にすべて忘れてる。なんか書いてるだけでもこんぐらがってきたし。

つまり見せる工夫というのは、「見たい」需要が顕在化していないものを見せるための工夫であって、見たい人がたくさんいることがわかっているものを用意して客を寄せることではないのです。潜在的な需要をたたき出すための工夫という意味では、広告代理店とかでの研修をするのもよろしいのではないでしょうか。

実際には、必ずしも広告代理店が潜在的な需要のたたき出しに成功するわけではないので、無意味だと思う。ただ、同じ意識を持つことの役には立つかもしれない。

なんだか会社を出てから忙しい一日だったが、それは少なくとも不本意な仕事でないという一点で十分に虚しくない。虚しさと不本意の出現順は逆かもしれない。

奥様の実家へ向かう電車のなかでR5RS(鈴木さんの訳したバージョン)を読み出したら、止まらなくなった。なんていうかその、(1社内での)出世とか給料とかは本気でどうでもよくて、こういうことだけ考えていられないものかね。しかしこれは、一歩間違うと受動的な趣味の枠内に陥る。ぼくは漫画やアニメが好きですという青年男子の主張と何ら変わりない、という可能性はないだろうか。ある。あるんだよ。
反論：自分がいま社会に対して責任を持っているのは別の業務だから、そちらに時間を割く。ここでいう時間というのは、物理量ではないし、区分可能でもない。ヘンに何か始めると際限なく没頭することになり、社会的な責任を放棄せざるを得なくなるため、どうにかこうにかブレーキをかけている。
正論：とにかく資産がない。資産とは、一時的な貯金額ではなく、将来に対する不安の少なさを意味する。

新宿でケーキの食べ邦題、発体験。可もなく不可もないものが好きなだけ食べられるという意味では興味深い。あと、となりの女性がものすごい勢いでサンドウィッチを頬張っていたのが興味深い。

ところで今日は荒川区川の手祭りでもあった。例年通り、何ともいえないいい雰囲気の行事だよなあ。

夜になると鬱が晴れて仕事への意欲がわくが、ミスが増える。眠たいし。

キーボードは Happy Hacking Keybord Lite（2じゃないほう）と決めて、はや数年。4台をあちらこちらで使ってるけど、最近になって欠点が判明した。とくに前期に生産されたものに顕著なんだけど、本体が反りやすい。おかげで、打鍵のたびに微妙にカタカタいう。足が一本だけ短いテーブルの上で文字を書いているときと同じイライラ感。原因は、きっと背面の硬質プラスチック成型の難だろう。あらためて見るとタイ製と書いてある。

むかし、プラスチック製品の製造にかかわったことがある。実は、プラスチックの射出成型は想像するほど簡単じゃない。つまり、機械まかせにしてポコポコと安易に量産できるようなものじゃない。気温や湿度が変わるだけでも射出時の圧力や温度を調整しなければならない。しかも、プラスチックの成型可能な温度には下限も上限もあるから、この調整が製品の質を左右する職人技になる。さらに職人になると、コンディションに応じて材料や可塑剤の配合まで（同じ商品を作るときでも）変えてくる。
プラスチック成型職人の職人たる所以は、実際の成型段階での技にとどまらない。よく考えれば当然だけど、金型の設計段階から彼らの技が効いてくる。まず、そもそもプラスチックをうまく流せるように金型を作る必要がある。プラスチックは金型へと射出した瞬間に冷えて流れにくくなるから、可能な金型の形状は自然と限られる。また、金型から取り出した製品は冷えて縮まるため、金型本体は出来上がり寸法より微妙に大きく作らなければならない。縮み率は材料によってずいぶん違う。完成品の外見に対する配慮も必要だ。材料の流し込み口はどうしても最後にランナーとして残ってしまうため、どこから材料を射出すれば製品の目立たない位置にランナーをもってこられるかも考慮する。透明なパーツともなれば、一切のムラも許されない。そのために金型の成型面へメッキを施すこともある。
そこで、プラスチックの性質を知りぬいた技師の意見を取り入れて金型職人が金型を彫り、それで試しに成型してみて、部分的に削りなおしたり肉盛りしたりしながら金型を調整する。だから、CADで設計したものを自動旋盤で彫るだけじゃまっとうな金型はできない。

自分がプラスチック成型にかかわったのは国内の射出製造業者と金型業者だった。そして、彼らの職人技は、一言でいうとすごかった。びっくりした。これぞプロフェッショナル。しかも気負わない。

はて、何がいいたかったんだろう。

Haskell という不思議な名前は Curry Haskell さんにちなんだものだということを今さっき知った。Curry だって？ Curry-Howard の同型定理の Curry？

Curry-Howard
つまり、ここ数年間、同じところを回ってたってわけか。楕円軌道だったけど。

秋葉原のDYNAMIC AUDIOで 高田みち子 を買おうと思ったら売り切れだった。そんなに売れてる、これ。まさかね。SACD だし。

金曜日から脳内を仮想的な軟禁状態において切羽詰まった仕事をいくつか片付けていたわけだが、相手に渡してしまったらそれ以上の仕事はできないので、これで区切り。また今週末から似たような状況になることは目に見えているけど。

久しぶりに微かに陽のあるうちに会社を出て、奥様に電話をかけたら、たまらなく泣きそうになった。それで、苺屋でケーキを2つ買って帰る。

どうでもいいけど、自分が自分の結婚生活の多くの部分で依拠しているのは、もしかしたら Samantha Stephens の行動パターンではないかということに気が付いた。Darrin ではない。よく考えたらどうでもよくないことなので、またあとで書く。

今日も、ほぼ自分のことができなかった。かろうじて奥様と小一時間の散歩だけ。

今日も自分のことはなにひとつとしてできなかった。

北新宿のピッキヌー(タイ料理)に行って、いくつかの発見。

• パイマックルー(こぶみかんの葉っぱ)は、素揚げするとパリパリしてうまい。


• タイ料理に使われている唐辛子は、種が多くて本気で辛い。ハバネロを自家栽培している人間が言うんだから信じたほうがいい。もっとも今日は口内炎がいたかったというのもあるけど


• やっぱりホーリーハジルの香りは最高
• 
  
• マテ茶は生姜茶のような風味がする


• 新宿から日暮里までの自転車走行時間は、コンビニに寄っても40分


• 気が合うというのは、やっぱり重要だ

名前つきletの2重化という知恵をいただいたので、代入を葬ることができました。条件式も少し整理したので、これで少しはかっこよくなったかな。

(define prime-list
  (let ((primes '()))
    (lambda (upper-int)
      (let next-primes ((test-int 2) (primes primes))
        (let next-divider ((test-int test-int) 
                           (ls (reverse primes)))
            (cond ((null? ls)
                      (next-primes (+ test-int 1) (cons test-int (reverse primes))))
                  ((> test-int upper-int)
                      primes)
                  ((integer? (/ test-int (car ls)))
                      (next-primes (+ test-int 1) (reverse primes)))
                  (else
                      (next-divider test-int (cdr ls)))))))))

「test-int の除算チェックを √test-int までに制限」とかの工夫は、すぐにでも追加できそうな気がする。

名前付き let に興奮。って、おまえはその昔大学でλ式やったんじゃないの？ 学生のときにもっと勉強しておけばよかったっていう言葉の意味がわかりつつあるのは、きっと大人になったからなんだろう。いや、学生のころも、勉強はした。けど、抽象的な対象ばっかり扱っていたし、何より自分のコンピュータが買えなかったのが悔しい。あと、コンピュータ数学のゼミが体育会系で疎遠だったのも悲しい。

まあ、いいや。とにかく素数は避けられない。

(define prime-list
  (let ((primes '(2)))
    (lambda (upper-int)
      (let next-prime ((test-int 3) (ls primes))
        (if (< test-int upper-int)
            (if (integer? (/ test-int (car (reverse ls))))
                (next-prime (+ test-int 1) primes)
                (if (null? (cdr ls))
                    (begin (set! primes (cons test-int primes))
                           (next-prime (+ test-int 1) primes))
                    (next-prime test-int (reverse (cdr (reverse ls))))))
            primes)))))

(prime-list 91) =>
(89 83 79 73 71 67 61 59 53 47 43 41 37 31 29 23 19 17 13 11 7 5 3 2)

目下の問題

• ifがおおすぎ


• 代入をなんとかしたい。でも、こういう結果(判定ではなくリストを得る)を求める以上は無理かな


• リストの末尾を削るには reverse して car して reverse するしかないの？

上野公園の噴水は夜になるとオレンジにライトアップされる。今日は、その前で、どこかのカップルのシルエットが抱きあっていた。こういう光景をみて、オーシャンズ・イレブンのラストシーンしか思い出さないのは、正直がっかりだよ。

全然関係ないけど(自分のなかでは関係ある)、ぼくがもう一度みたいのは「宇宙船サジタリウス」だったということが突然判明した。人生の事象は p=1 で突然です。
小学生のころテレビ朝日で放映してたアニメなんだけど、長いことタイトルが思い出せなくて「悩ましかった」。ちなみに、このアニメに出てくる女性科学者はほんとうに悩ましいんですよ、hisashimさん。かばだけど。シマウマだったかな。DVD-BOXは初回限定生産で入手不能っぽい。ところで、自分の脳内でこのアニメと同列にあるのが、NHKみんなのうたで短期間だけ放映されていた「かにさん」という歌。どっちも、人生のしがなさが動物(またはカニ)の視点からえぐりだされていて、夢や希望をそぎおとされる感じ。こういうのを子どもに見せると、トラウマになるか、人生で大切なのは友情や努力なんだと勘違いするようになる。

奥様が出かけてるの忘れてた。しかたがないので、帰りに日暮里の「鶴」で塩ラーメン。ここのスープは、なんでこんなにきれいで飾りっ気なくって、うまいんだろう。胡椒を少し振ると、さらにすてき。

reverseもどきで一番頭が痛かったのは、与えられたリストの car をそのまま末尾に cons すると proper なリストにならないことだ。つまり、(1 2 3 4 5) => (5 4 3 2 . 1) になってしまう。そこで、今朝までのバージョンでは、まず最初にリストの car をリストにする処理を行っていた。(1 2 3 4 5) => ((1) 2 3 4 5) みたいにしておけば、((1) 2 3 4 5) => (5 4 3 2 1) が得られるという仕組み。これが気持悪い。そこで、名前付き let を工夫して、最初だけ空リストを頭にくっつけられるようにしてみた。この方法なら、本来の処理で cons が1つ減るというおまけ付き。

(define rvs
  (lambda (ls)
    (let fishy-rvs ((rvsed '()) (amari ls))
      (if (null? amari)
          rvsed
          (fishy-rvs
            (cons (car amari) rvsed)
            (cdr amari))))))

だいぶいい線にたどりついたんじゃないかな。

そうか、名前付きletを使えばいいのか。

(define rvs
  (lambda (ls)
    (let ((ls (cons (cons (car ls) ()) (cdr ls))))
      (let fishy-rvs ((ls ls))
        (let ((amari (cdr ls)))
          (if (null? amari)
              (car ls)
              (fishy-rvs
                (cons 
                  (cons (car amari) (car ls))
                  (cdr amari)))))))))

アルゴリズムは昨日のと同じ。しかし今度はletだらけで、やっぱりうざい。

reverseもどきのrvsプロシージャのメモ

(define fishy-rvs
  (lambda (tr)
    (cond 
      ((null? (cdr tr)) tr)
      ((null? (cdr (cdr tr))) (cons (car (cdr tr)) (car tr)))
      (else (let ((amari-tr (cdr (cdr tr))))
              (fishy-rvs
                (cons
                  (cons (car (cdr tr)) (car tr))
                  amari-tr)))))))

(define car2proper-list
  (lambda (ls)
    (cons (cons (car ls) ()) (cdr ls))))

(define rvs
  (lambda (tr)
    (if (list? tr)
        (fishy-rvs (car2proper-list tr))
        "it's not list!")))

なんかもっとかっこよくならないものか。

これはなんだろう。

gosh> (* 2.3 3)
6.8999999999999995
gosh> (* 2.33 3)
6.99

自分の要件だけ伝えられる人がうらやましい。自分の要件を主目的に位置づけられる人がうらやましい。この手の「うらやましい論理」は終点だから、ここいらで降車しないと。

雨が降ると上野公園の花見客が消えて素晴らしい。花見してたっていいんだけどさ、ブルーシートはHL派と一緒だからやめようよ。

さすがに疲れた。眠っても眠っても眠い。しかしこんなところでとまっているわけにはいかない。かといって、行き先もない。っていうか待ち時間たいくつ。

ところで、日本人としてはGaucheを使いたいわけですよ。そこで、とりあえずあいさつからはじめてみた。

#!/usr/bin/gosh

(use gauche.charconv)
(use text.tree)
(use text.html-lite)
(use www.cgi)

(define (main args)
  (write-tree
    `(,(cgi-header)
      ,(html-doctype)
      ,(html:html
         (html:head (html:title "jabber"))
         (html:body
         (html:p 4649)
         (html:p "おはいよう")))
      )))

一口メモ。Debian の gauche パッケージは UTF-8 でコンパイルされているので、スクリプトファイルもとうぜん UTF-8 で保存するわけだが、BOM（Byte Order Mark）付き UTF-8 だとバイナリファイルだと思われて実行されない。

魚屋でニシンを2匹買ったら、白子と数の子が一匹ずつ入っていた幸せ。

あいかわらず花見客がうっとうしい谷中へビールを買いにいく途中、日暮里で空き地にセールスマンがいた。ずいぶん前から気になってた東南角地の公園脇の空き家が更地になってたんだけど、全区画建築条件付きの事実上建て売りだった。もう、こういう癒着はむかつくのでやめてくれませんか。間取りなんてのは二の次でもいいんだけどさあ、どうせ基礎工事のいいかげんな業者とか使われちゃうんだから、購入する方としてはたまらないんだよ。消費者の利益にならない仕事ばっかりいつまでもやってんじゃねえ。ばか。土地なんて限られたリソースなんだから、てめえらの泡銭だけに目を眩ませて無駄にすんな。

父親が脳出血で入院したらしい。だいたい飲みすぎなんだと思う。この話でいちばんむかつくのは、ちょうど3月末に退職して保険が適用されるかどうか微妙というところだ。ちなみに2月には母親が入院してた。重なるもんなのね。

どうでもいいけど、今日の上野公園は特に酔っ払いだらけで気分がわるい。救急車も入ってた。ざまみろ。

無性にDACがつくりたいので A DAC of the Klones! をベースに何か作ることにした。TDA1543を9Vで動作させるってとこが、たまらなくぐっとくる仕様。8パラにする馬鹿もいるらしい。しかし9Vで動作させる以上、発熱の関係からこういう無茶は無理。っていうか、じっさいパラレルにすればクロックは鈍るわけで、そのへんはどうなのよ。これはつまり、曇った音とゆがんだ音のどっちかを選択するって話なわけだが、はっきり言ってゆがみはプラスになり得る【断定】。にもかかわらず、なまぬるい音（≒曇った音）のほうをいい音だと勘違いしちゃう人は多い。

高揚感は、アルコールよりも、むしろ環境に影響される。

それはそうとして、楽しいことはどうしてすぐに終ってしまうんだろう。

ぼのぼの

昨日うちにきた KM は健康食品メーカーに再就職するらしい。で、しばらく前から飲んでいるサプリメントを見せたところ、ずいぶんと興味津々だった。実はしばらく前から鬱状態が軽減している気がしたんだけど、それがどうやら気のせいだけではなかったらしい。鬱の患者は脳内の不飽和脂肪酸のうちオメガ3が極端にすくないらしく、どうやら毎日のんでいるサプリメントにはオメガ3が含まれるflaxseed oil(亜麻仁油)が入ってるんだと。ふうん。

久しぶりに友人 KM がきて、昼からビール。夜になってから出勤帰りの KS も呼んで、うちの冷蔵庫に 4 年間眠っていたドンペリ（ピンク）をついに開けた。この酒を飲むと、いつも、これから何かが始まるのではなく、長い惰性に終わりが到来した気分になる。今日、何が終わったのかは、ひみつ。

机の上のチューリップがしおれてた。

ところで PINK FLOYD の Live at Pompeii を途中まで見た。どうしてこの人たちがこんなにもバルトークに似ていることに今日まで気が付かなかったんだろう。それは、僕の世代にはこのバンドに対する時代性がないから。どんなものであれ古典に（不自由なまでの）思い入れを持てるということは、無駄に想像力がたくましいか、もしくは虚栄心が多いかだ。

上野公園は桜で込んでいるけど、それ以上に異常だったのは園内の科学博物館だ。酔っ払いとHL派を押しのけて信じられない行列ができている。2～3日前から、平日にもかかわらず8:30に行列が形成され始めていて、ちょっと気になってたんだけど、今日その謎が判明した。どうやら恐竜がいるらしい。そういえば先週、なんか長いトラックがやたらに出入りしてたな。にしても、どうして2005年にもなって恐竜で人が動かせるのかは相変わらず疑問だ。子供は恐竜が好きだろうと断定して連れて行く両親がいるからなのか、それとも子供は恐竜を好きなのか。どっちでもいいや。

やる気が減衰する要因には2種類あると思うんだよね。一方は、別の方向への関心の流入。もう一方は、周囲からの電波。これって電子回路と似てない？

I'm trying to give it up.

毎日のダース白と PEPSI Twist、計 257 円。

［戒］いかなるときも不得手な人の意見を信じてはならない。
ようするにTさんにだまされたわけだが、これは復讐か？ 昨日の復讐なのか！

また説教くさくなってしまいごめんなさい。

つまり受けがいいかどうか。そんな世の中に誰がしやっがた。まあ、本音いうとどっちだっていいんだけどさあ。仕事でやってる以上、相対的には悲劇に変わりないわけで。


というふうに憂えるのは90年代スタイル。21世紀になったらどうすればいい？

やんなきゃいけないことが多くて圧死しそう。
給料仕事ってのは、全部が全部自分自信にとって好ましいことではないから、ちゃんと休まないと。みたいなことを書くと、その日の糧にも困っている人はどうするんだということを言い出す奴がいるが、それとこれとは別問題なんですよ。この生物にとって「生きるか死ぬか」は個体に固有の問題ではなく、共同体のなかでしか意味を持たないから。かといって、人はパンのみで生きるわけではないという話でもなくて、要するに問題の質が違う。つまり、これは「僕の」問題であって、誰かが導いてくれるというのはアリ型迷惑です。

家で仕事のはずなんだけど、奥様と浅草に七味を買いに出かけた。ちょうど浅草寺で神輿のお堂下げに遭遇。



浅草寺の境内から、重量感のある 神輿が急な階段を斜めに降りてきて、蒼天の紫の段幕をくぐる。宗教感ありすぎ。外人大喜び。にしてもだ。お寺から神輿が出てくるって、教養のある外人には 理解できなそう。あと、神輿を担いでいるのは japanese gangster です（もちろん実際にはそうともかぎらない）って説明したらびびるかな。
毎年三社で担いでる KN によると、昨晩がお堂上げで、篝火のもと神輿が境内に搬入されたらしい。誘ってよ。

僕には何ができるのかなあ。と考えると、くさくさしてくる。

今日は基地外が多い。

吉野屋の異常な込みっぷりは株主として歓迎すべきことなのだろうか。にしても、千代田区の某店は質が低いなあ。煮詰まっちゃってるし、七味の柚子は少ないし（海苔ばっか）、サラダの補充はないし、会計間違えるし。ラインナップが複雑になってからというもの、間違えやすくなっていることはわかる。こっちも、サラダなどのオプションを気分で追加してるので、追い討ちをかけているかもしれない。しかし、豚丼並キャンペーン価格とポテトサラダで440円ってどういう計算なんだろう。気づかなかったほうも気づかなかったほうだけどさ。

数学、他国語、ビリヤード、コミュニケーション。抽象化されたものの扱いは、訓練でしか習得できない。

しらない間にこんなものが出ていた。 4722

47研究所の製品は（アンプしか聞いたことないけど）強烈に速い。ソースによっては聴いていて精神が参っちゃう。だから、ゆったりと午後の紅茶のお供に音楽を流すのはお勧めしない。聴くことを強要される。もちろん、仮にそれで耳障りだったら演奏や録音に問題があるからなわけで、たいていは、むしろ、音が抜けて気持ちいい。そんな47研究所のスピーカー（しかもフルレンジ）ですよ。価格は書いてないけど、どうやらペアで16万くらいっぽい。どうしようかなあ。どうしようかなあ。どうしようかなあ。

自転車の前輪ブレーキワイヤが切れた。直すの面倒だなあ。でも、直さないとかえって面倒なのだった。
どうでもいいが、このように面倒なことのバーターばっかりで生きているのは美しくない。いや、どうでもよくないぞ。つまり、より快適な道を選んで進むことは、終点が1つならcoolだけど、そうでなければ腐ってる。

猫とベトナム戦争
先月作った ARII の 1/144 F-4E PHANTOM
前から
上野公園の猫

今日、衝撃的な事実が判明した。なんと今シーズンの「あっさりショコラ苺」は終了したっぽい。というわけでチョコレートは冬の時代に。

競争の結果として品質が淘汰されるパターンと、リピーターへの依存の結果として品質が淘汰されるパターンがある。

印刷が終わらない。何もかも終わらない。終わらないほうがましなものってある？