2006/08/31

原稿を催促する側の気持ちが分かる人間は催促される側よりも少ないと思う。

YAMDAS現更新履歴 - 原稿を催促する人、締め切りを破る人
http://d.hatena.ne.jp/yomoyomo/20060831/deadline

「困るといわれても困る」になぜかとても理解があると勝手に自負している編集者としては、職場でほかの人がひたすら「原稿ください。こっちも困るんです」みたいな電話を繰り返していると、回線交換機を叩き壊したい衝動に駆られて困る。YAMADASさんが指摘しているように、そういう編集者は実際に「優秀な編集者」ではない。これはもう、編集者失格な僕がそう感じているんだから間違いない。

かといって、まったく催促がへたくそな僕のような編集者を雇っておくのは会社としては困るはずで、だから8月も最後の今日になると、「来年には発行する予定です」って報告している企画を上司に提示されて「この企画の進捗はどうなってるんだ」と絞られたりする。どうなってるんだといわれても困る。せっかく本を書くっていう儲からない(けど楽しい)仕事を引き受けようとしてくれている人達に「困るといわれても困る」内容のメールを出すのはしのびない。

それでも最後にはメールを書く。ほぼ定型文。1行目「進捗はどうでしょうか」 2行目「多忙のところお願いばかりで申し訳ありません。よろしくお願いします」 ただし、実際にはこの行間にちょっと何か具体的なことも書く。そして、そこに何を書いたらいいか分からなくて困る。ときには3日くらい困ってる。4日かもしれない。そして書いても出さないことがある。だってブログとか読むと忙しそうなんだもん。

オチがないけど、まあ原稿があって編集ができるんだから、僕もがんばらないといけないですね。

2006/08/29

家に帰ったらヤモリがいた。ちょっとかわいい。ヤモリがいる家はいいことがあるっていうし、殺害するのは思い留まる。でも、さすがに家の中を歩き回られるのはちょっといかがなものなので、外に誘導した。古いとはいえ都内のマンションの3階なのに……と思ったら、実は都市の建物に住んでいるものらしい。なにこの生活日記。

2006/08/27

いまだゴールが見えないSICP。ようやく第3章が終わった。思い返せば第2章を終えたのが今年の3月22日で、それから5ヵ月もかかってる。おそすぎ。まあゆっくりやります。

最後の問題は、また乱数とモンテカルロだった。ところで第3章では疑似乱数を線形合同法で求める方法が紹介されているので(226ページの注6)、Gauche に用意されているメルセンヌ・ツイスターを使っちゃずるいと思う。いや、べつに誰がずるいというわけでなく、それでは自分的に勉強にならないと思う。ってな大口を叩いてたところで、Knuth本を持ってないからWikipediaに載っている係数をひろってくるだけなんだけど。
(define (monte-carlo experiment-stream passed failed)
(define (next passed failed)
(stream-cons
(/ passed (+ passed failed))
(monte-carlo
(stream-cdr experiment-stream) passed failed)))
(if (stream-car experiment-stream)
(next (+ passed 1) failed)
(next passed (+ failed 1))))

;; ex. 3.81
(define rand-init 1)
(define (rand-update x)
(modulo (* x 1664525) 1013904223))
(define (random-numbers c)
(define (rands init)
(stream-cons init
(stream-map rand-update
(stream-delay (rands init)))))
(cond ((equal? c 'generate)
(rands rand-init))
((equal? c 'reset)
(lambda (init)
(rands init)))
(else
(error "Unknown argument" c))))

;; ex. 3.82
(define (random-numbers-in-range x1 x2 rand-init)
(define (normalize x)
(+ (* x (/ (- x2 x1) 1013904223)) x1))
(stream-map normalize ((random-numbers 'reset) rand-init)))
(define (estimate-integral P x1 x2 y1 y2)
(stream-scale
(monte-carlo
(stream-map P
(random-numbers-in-range x1 x2 1)
(random-numbers-in-range y1 y2 506952111))
0 0)
(* (- x2 x1) (- y2 y1))))

(define (P x y)
(<= (+ (square (- x 5))
(square (- y 7)))
9))
(define ex-3-82
(estimate-integral P 2 8 4 10))
(define (ex-3-82-pi howfar)
(/ (stream-ref ex-3-82 howfar) 9))

gosh > (ex-3-82-pi 1000)
3.1128871128871127
最初、x軸とy軸について同じ random-numbers-in-range を使ってたら、どうにも想定している結果よりかなり小さい値しか求まらない。そりゃあ y=x 上の点しか拾ってないんだから、よく考えれば当り前の話だった。結果的に初期値として選んだ 1 と 506952111 は適当で、あまり背景はない(1013904223の約半分)。これくらいオーダーを違くすれば、そこそこバラけるような。
Paul Graham は「ハッカーと画家」のなかで、熱狂的な没頭と妥協しないことの引き合いにダ・ヴィンチの「ジネブラ・ベンチの肖像」の背景に描かれた松を取り上げていた。今年の5月、実際にナショナルギャラリーで本物を目にすることができたんだけど、なるほど彼の言いたいことはよくわかる。美術史的な価値を頭からとっぱらっても、芸の細かさと力強さが同居している不思議な印象に脳味噌が食らいつかれる感じ。でもなんか「好き」っていう絵でもなかった。描いている本人の技量と作品の凄さはわかるけど、べつに欲しいかっていうとそうでもないなと。食傷する手合いの偏執狂っぷり。

今朝、三の丸尚蔵館が所蔵している伊藤若冲の「動植綵絵」を見てきた。

花鳥−愛でる心、彩る技 <若冲を中心に>
http://www.kunaicho.go.jp/11/d11-05-06.html

比較するのはおかしい気もするけど、ナショナルギャラリーでダ・ヴィンチを見たときの 23 倍くらい鳥肌が立った。技術が凄いとか描き混みが凄いとか、そういう評価を受け付ける段階はとっくに超越していて、もうなんて言うか、小鳥がかわいい。そんなことしか言えない。まさにクールなアイデアとホットな実装。とにかくクールなアイデアとホットな実装。

ちなみに、上野の東京博物館でもプライスコレクション展として若冲が何点か来日してるけど、若冲に興奮するなら三の丸尚蔵館のほうがいい。タダだし。プライスコレクションのほうは1300円くらい取られる。それでも、若冲の一番有名な作品であるグリッドぞうさんとかが見られるので、こっちはこっちでおすすめ。さらにガラスケースなしで長沢芦雪のキチガイじみた大作を直に見られることを考えると、むしろ1300円は安いのかも。

にしても、なんで小中学校の歴史の授業で伊藤若冲という日本画家のことを教えてくれなかったですか? ぶっちゃけ、藤原なんとかが娘を天皇に嫁がせたとか、徳川なんとかが犬を大事にしたとか、あるいは、わらじを懐で温めると出世できるとか、そういう話は今になって思い起こすとすべからくどうでもいい。若冲や芦雪の作品のほうが、よっぽど歴史の授業で学びがいがあったであろうネタだ(美術の授業では絵を描くものだ)。まあ、教師が教えたいことと教えられることしか学ぶ機会がないのが小中学校だから、どうしようもないって言ってしまうとそれまでなんだけど。

2006/08/26

抜歯から3ヵ月以上たったので、いよいよインプラントの検討を始める。いつも治療してもらっている歯医者さんでは外科治療はやらないとのことで、今日からは紹介してもらった別の歯医者さんに行く。"My Job Went to India"(来月日本語版を出しますよ)でいうところの「スペシャリスト」がヘンに頭に残ってたせいか、おかしな緊張具合で初診に出向いた。でも杞憂だったみたい。

結局、まだベースになる歯茎の下の骨が十分再生していなかったので、さらに3ヵ月経過を見ることに。ふだんは大学病院に勤務していて診療が月2回だけで、再来月までしか診療日が決定していないとのことなので、あらためて来月か再来月に予約すること。

2006/08/25

僕の仕事は書籍の編集で、編集者っていうと赤ペン片手に原稿を読んで校正記号を入れたり著者の家に原稿を取りにいったりしてる人っぽいけど、実際にはそんなことはやらない。というか、できない。ただ、まあ、そうじゃない方法ではあるけど本を作ってる。だから何も後ろめたいことはないはずなのに、業界的には「校正記号を入れる人」とか「著者に原稿催促をしまくる人」みたいな項で編集者が定義されているので、僕はどこからどう見ても編集者じゃなくなっちゃって、軽い自意識のゆらぎがおきる。

自己防衛のために、編集者(とくに技術書の編集者)を定義し直してみる。まずは直感的に思いつく技能の列挙から。

* 技術に対する感覚が技術者と乖離していない
* 書籍に対する感覚が読者と乖離していない
* 日本語に対する感覚が日本人と乖離していない
* 業務に対する感覚が他業種と乖離していない
* チームに対する感覚がチームの他のメンバーと乖離していない

というわけで、勝手ながら以下の表現をもって編集者の定義とさせていただきます。
Def
任意のAについてAに対する感覚がAの担い手と乖離していない

明日からは、この定義にのっとってがんばりたいとおもいます。よろしくお願いします。


ついでに、こうはなりたくないと思う編集者(とくに技術書の編集者)の特徴も並べてみた。あくまでも僕がなりたくないというだけで、特定のモデルがいるわけではないし、今の自分がそうではないというつもりもない。

* 一次資料と報道とうわさと広告が脳内でいっしょ
* っていうか、そもそも技術に興味がない
* 日本語なので原稿の意味はわかるような気がする
* 自社ルールとオレルールを信じている
* なによりスケジュールと手続きが大事
* はんこが好き
* 声が大きい
* キモイ
* バカ
* 左
* ●●●
* ●●●●●●●

2006/08/20

先日、Gauche のストリームと MIT Scheme のストリームがじゃっかん違う?と書いたんだけど、すみません僕が Gauche のドキュメントをちゃんと読んでなかっただけでした。具体的にはこのページ。

stream-delay
http://www.shiro.dreamhost.com/scheme/gauche/man/gauche-refj_158.html#IDX2975
"As a rule of thumb, any stream-producing functions should wrap the resulting expression by stream-delay."

これまで「Streamは遅延評価で実現する」という程度の認識しかなかった。それが SICP の "3.5.4 Streams and Delayed Evaluation" まで読み進んだところ、実際にはもっと込み入ってたってことがわかった。あいかわらずこの本は教科書としてスキがなさすぎ。つい鼻息が荒くなる。

で、そういう認識であらためて Gauche のドキュメントを見返すと、生成した stream を評価する順番を調整する stream-delay がちゃんと用意されてたってわけですよ。いっしゅん Gauche のわなかと思ったけど、ドキュメントを全部読んでないのと理解が甘いのが悪かっただけ。

Ex. 3.56 に当てはめると、
(define (merge s1 s2)
(stream-delay
(cond ((stream-null? s1) s2)
((stream-null? s2) s1)
(else
(let ((s1car (stream-car s1))
(s2car (stream-car s2)))
(cond ((< s1car s2car)
(stream-cons s1car
(merge (stream-cdr s1) s2)))
((> s1car s2car)
(stream-cons s2car
(merge s1 (stream-cdr s2))))
(else
(stream-cons s1car
(merge (stream-cdr s1)
(stream-cdr s2))))))))))

(define S (stream-cons
1
(merge (stream-scale S 2)
(merge (stream-scale S 3)
(stream-scale S 5)))))

gosh> (stream->list (stream-take S 100))
(1 2 3 4 5 6 8 9 10 12 15 16 18 20 24 25 27 30 32 36 40 45 48 50 54
60 64 72 75 80 81 90 96 100 108 120 125 128 135 144 150 160 162 180
192 200 216 225 240 243 250 256 270 288 300 320 324 360 375 384 400
405 432 450 480 486 500 512 540 576 600 625 640 648 675 720 729 750
768 800 810 864 900 960 972 1000 1024 1080 1125 1152 1200 1215 1250
1280 1296 1350 1440 1458 1500 1536)
ちゃんと求まる。

ついでに、347ページの微分方程式を解くプロシージャは次のようにすればいい。(そのまま Gauche で試すと 「stream-map に渡す y がstreamじゃねえ」と言われて実行できない)
(define (solve f y0 dt)
(define y (integral (delay dy) y0 dt))
(define dy (stream-map f (stream-delay y)))
y)

2006/08/11

がやがや町に広まった「ハウルは女の子の心臓を食べる」といううわさは、ハウルたち自身が荒野の魔女から身を隠すために衆目を遠ざけるべく意図的に流したものだ。

「Lispはカッコが多いから超むずい」とか「Haskellはモナドとかわかんないと入出力もできないから超むずい」いううわさも、コミュニティが市場原理から身を隠すために衆目を遠ざけるべく意図的に流しているものなのかもしれない。

出版社は市場原理の一部だけど、その内部にはソフィーのように市場原理に呪われてる奴らもいるってことで。

2006/08/10

放置していた Martha Argerich の新作(フランク、ドビュッシー、シューマンのバイオリンソナタ)をようやくプレーヤーにかけたんだけどさあ、なにこれ。あいかわらず聞いてるこっちが汗出てくるよ Argerich ねえさん……フランクの4楽章の3:45付近で誰かがうなってるんですが、あなたですか? びっくりするのでやめてください。

2006/08/07

もう数年前から考えていること。

できることは基本に忠実に対処し、できないことは工夫して対処する

この態度、間違ってますから。少なくとも外国語→母国語の翻訳で望ましい態度は、まったく正反対。

できることは工夫して対処し、できないことは基本に忠実に対処する

仕事で技術文書の英→日翻訳を発注すると、最初の態度をとってくる翻訳者がとても多い。技術翻訳の場合、ほとんどの翻訳者は当該の技術分野について知識や経験がない。たいていは興味もない。そんなわけで、自分が意味のわかる英文は逐語的に訳して済ませてしまい、意味がわからない英文が出てくると意訳しようとする。意味が分からない英文の意訳って定義上不可能なんだけどね。それこそ逐語的に訳してくれればいいのに。自分が原文の意味をとれてないなら、絶対に意訳しようとしないでほしい。技術がわからなくて訳せない箇所は「訳せません」でいいし、文意に自信がないならせめて英文法に忠実な逐語訳をしてくれるとチェックが助かります。

一方、論文でもない限り技術文書にも日常的な英文は相当含まれていて、発注する側としてはそういう箇所は普通の日本語の文章のように訳してほしいんだけど、これがうまくない。例えば英語の文章には日本語の文章より指示代名詞が多いけど、それをそのまま訳してきたりする。

Becky did not hesitate to ask him it in the shop because she had wanted it.
なぜならベッキーはそれが欲しいと思っていたので、その店で彼にそれを求めることを躊躇しませんでした。

勘弁してください。「ベッキーはその店で前から欲しがっていた○○を彼にねだりました」とか、それなりに普通の日本語に意訳してもらいたいからこそ翻訳を依頼してるわけですよ。○○は、たぶん文脈からわかるでしょう? 適切に補ってよ。普通の日本語で「それ」っていうか?

もちろん、そういうのを求めるなら相応のコストを払えという主張に耳を貸さないつもりはないです。個人的には。

もちろん、すべての仕事について「できることは工夫して対処し、できないことは基本に忠実に対処する」べきだとは思ってないです。むしろ、できないなら手を付けるな、というべき仕事もあるし。とはいえ、その「手を付けない」という対応こそが、その分野での「基本」なのかもしれなくない?

もちろん、上記は特定の業務に対する愚痴ではないです。

もちろん、例に使った "Becky..." の英文は僕の作文なので英語としてへんちくりんな可能性があります。

2006/08/02

LaTeXで、ページの残りが少なかったら次に続く要素を改ページしたい。
あくまでも自分用のメモ。
% ページの残りが指定した数値より少なかったら改ページを促す
% \ifnoroomthenpagebreak{20mm} とか
\def\estimate@restpage{%
\dimen@\vsize \advance\dimen@ -\pagetotal%
\advance\dimen@ -\pageshrink%
\advance\dimen@ -\pagedepth%
\advance\dimen@ -\pagestretch
\advance\dimen@ -\pagefilstretch%
\advance\dimen@ -\pagefillstretch%
\advance\dimen@ -\pagefilllstretch}%
\newcommand{\ifnoroomthenpagebreak}[1]{%
\estimate@restpage%
\ifdim\dimen@<#1%
\ifdim\dimen@>7pt \pagebreak\fi\fi}

\estimate@restpage で「残りページのつもりの値」を見積もってるんだけど、なんかどうしても1行分だけ残っちゃうみたいで、次のページの先頭付近が「残り 6pt くらい」だと見なされてしまう(場合がある)。その補正が最後の「> 7pt」。高さが 7pt しかない行はあんまりないので、この \ifnoroomthenpagebreak コマンドで改ページされなくてもどのみちこの位置では改ページされる可能性が高い。だから実用上は意図どおりの結果が得られることになる。とはいえ、このあたりの挙動がいまいち不明なので、そのままどんな場合でも安心して使うことはできないと思う。

にしても、一連の値「\pageほにゃらら」についてのドキュメントはどこ?(そもそもLaTeXのドキュメントが……)
結局参考になったのは、TRALICSというLaTeXからXMLへのコンバータのドキュメントだった。

TRALICS : a LaTeX to XML translator (P)
http://www-sop.inria.fr/miaou/tralics/doc-p.html

どうでもいいけど、こっちはXMLからLaTeXへのコンバータを作るのに精一杯なわけで、LaTeXからXMLを吐き出すなんて気が遠くなる。