2006年6月

私「完全数って知ってる？」

長男「知ってる。約数を全部足すとその数になる数」

私「そうだね。厳密に言えば違うけど」

長男「どゆこと？」

私「約数全部足すんだけれど、その数自身は除かなくちゃ」

長男「あ、そりゃそうだ」

私「完全数の例を知ってる？」

長男「んー、二つしか覚えていない。6と28かな」

私「そうそう。1+2+3=6だし、1+2+4+7+14=28だね。6と28のほかに496や8128も完全数だよ」

長男「へー」

私「ところで、奇数の完全数は存在するかな」

長男「ん？………………わからん」

私「はい。そうだね。奇数の完全数が存在するかどうか、人類はまだ知らない」

長男「ふーん」

私「でも、少し考えると、奇数の完全数が難しそうな理由はちょっとわかる」

長男「どゆこと？」

私「奇数ということは、2を約数に持たないよね。ということは2とペアになった約数、つまり元の数の半分も約数じゃない」

長男「そうだね」

私「完全数になるためには、約数を1から順に加えていってその数自身までたどり着かなきゃいけないんだけれど、「元の数の半分」という比較的大きな数を利用できないことになる。つまり、小さな約数をたくさんもってなければいけない。これはちょっとつらい。…っていうのはぜんぜん証明じゃないんだけれど、直観的な観測だ」

長男「はあはあ」

私「完全数かどうか調べるときに「その数の約数の和（ただしその数自身は除く）」を考えたよね」

長男「うん」

私「ではね、その数自身も含めて考える。「その数の、すべての約数の和（その数自身も含む）」を考えよう」

長男「はい？」

私「正の整数nに対して「nのすべての約数の和をs(n)」と表現することにしよう」

長男「ええと、はいはい」

私「たとえば、s(10)っていうのは、約数を全部足してs(10)=1+2+5+10=18になる」

長男「まあそうだね」

私「そうすると、完全数っていうのはs(n)=2×nになる数nのことだと言える」

長男「ふんふん」

私「それではここで問題です。「s(n)=n+1になる正の整数n」のことを、あなたはなんと呼ぶ？」

長男「え？　え？　どゆこと？　――あ、ああ、わかった！」

私「そう、それが正解。ちゃんと1が除かれるのが美しいよね」

問題

nを正の整数とし、s(n)を「nのすべての約数の和」とする。 このとき、s(n)=n+1になるnのことを何と呼ぶか？

「ティナからの手紙」を公開します。 ぜひ、ご感想をお寄せください。

• ティナからの手紙 (2006年)

以前の「ティナ」はこちらにあります。

• ティナ (2005年)
• 心の物語

はちこさんの日記にあった「無神論者との対話」が良かったのでご紹介。

• 無神論者との対話

今日は父の日なので、実家の父に電話。 お父さんありがとう、というと、 父は電話口ですっごく嬉しそうな声を聞かせてくれた。

毎日のように本を書いて、10年以上が過ぎました。 それだけ時間と労力をかけていると、 本に書く「内容」以上に、本を書く「方法」についても思うことがたくさんあります。 今日はその一つをシェアしましょう。

それは、本はトップダウンに書けないということです。

本全体のテーマを決める。つぎに各章の内容を考える。 全部の内容が決まったら、さらに詳細な内容を考え、節ごとにブレークダウンする。 全体の節が出来たところで、いよいよ本文を書き始める。 こんな風に、まっすぐな流れで詳細化が進み、その結果として最後に完成する――というふうには進まないのです。

本全体のテーマを決め、各章の内容を考える。まあここまではよい。 その次の有効な一手は、 「さらに詳細な内容を考える」ことではなく、 「本文をいきなり書いてみる」 ことではないかと思っています。 本文の一部分を、完成原稿のつもりで書いてみる。 ラフなスケッチではなく、この部分だけ出版してもかまわないというレベルまできちんと書いてみる。 書いてみようとする。

もちろん、ちゃんとは書けないわけですけれど、 書いてみようとする。 そうすると、いろんな発見があります。 実は、その発見がないと、本全体の方向性は決まらない。 もっとも具体的で、もっとも詳細な「本文の執筆」で何かを確かめなければ、 全体の構成を定めることができない（ある程度までは可能だけれど、限界がある）。

ソフトウェア開発プロセスのことをわかっている人なら、 ウォーターフォールではなく、細かいイテレーションといえばピンと来るでしょうか。 それととても似ている。

設計が全部終わってからコーディングに入るのではない。 全部の構成が決まってから本文の執筆に入るのではない。

実際にコーディングしなければわからないことがたくさんある。 それと同じように実際に本文を執筆しなければわからないことがたくさんある。 コーディングしてみて得られた知見をフィードバックしなければ、ちゃんと設計できないのではないか。 本文を執筆してみて得られた知見をフィードバックしなければ、構成は定まらないのではないか。

思うに、ソフトウェアも、本も、想像以上に複雑で大きなものであり、 人間が誤りなく全体の設計を前もって行うというのは不可能なのではないか。 設計が不要だとか、コードがすべてだという気持ちはさらさらないけれど、 「コードを書かずに行う設計には何かしら本質的な限界がある」 とは言えそうだ。

テストのないコードの信頼性が低いように、 コードのない設計の信頼性は低いのではないか。

要するに、人間の能力はそれほど高くない。 「ソフトウェアは、私たちの想像よりもずっと複雑」 なのではないか。わたしはそんなことを考えています。

バグがとれない―― 設計がまずいから。 きちんと設計してから作らないから。 時間がないから。開発者が少ないから。 仕様変更が多すぎるから。 …開発の現場ではこういう言葉がよく飛び交うと思います。 そのとき、 「ソフトウェアは、私たちの想像よりもずっと複雑」 ということをちょっと思ってみてください。 口に出さないまでも。

あれ？　本を書く話をするんじゃなかったっけ？

本を書くこととソフトウェアを作ること。共通点は多くあります。 どちらも、人間が管理できないほどの「複雑さとの戦い」なのですからね。

水曜日も淡々と仕事。 6月中に仕上げるべき別の仕事に移る。 調べ物をしたり、書いたり、判断したり。 すぐに片付くトドちゃん（なつかしー）とそうでないトドちゃんが居て、 まずは片付くものをどんどん片付ける。 どんどん片付けるモードのときは、優先順位など考えず、どんどん進むのだ。 で、一通り片付いたところで立ち止まり、自分のモードを切り替え、よく考える。 考えた結果「まだ解決できていない問題(open issue)」を箇条書きにして作業ログに残しておく。 解決できていないといっても、心づもりはある。 まず、

• その部分を全面的に新規書き直し
• 現状のまま

という両極端があり得る。 現実的な解答はこの両端の間のどこかにあるはず。 いま「ぼんやり」と考えている現実的な落としどころをいくつか作業ログに残す。 うん。これが現在の自分ができる最善。あとは、未来の結城さんにお任せしよう。よろしくね！

長男と二人でお風呂に入る。

私「《鳩の巣原理》って知ってる？」

長男「知らなーい。…ん？　あ、知ってる知ってる。鳩が10羽居て、巣が9個だったら、どこかの巣には鳩が二羽以上いるっていうの」

私「そうそう。よく知っているね。でも、それは巣が有限だったらね」

長男「どゆこと？　…ああ、無限なら違うのか」

私「たとえば鳩が無限羽いるとしよう。1, 2, 3, ...と番号を付けるよ。巣も無限個ある。1, 2, 3, ...と番号を付ける」

長男「ふんふん」

私「鳩が自分の番号と同じ巣に入っていれば、鳩と巣はぴったりだ。空いている巣はない」

長男「そうだね」

私「そこで鳩さんに言う。『みなさーん、《自分の番号プラス1の巣》に移ってくださーい』って。そうすると、鳩は隣に移る」

長男「ふむ」

私「そうすると、番号1の巣は空なんだけれど、他の巣はすべて一羽の鳩で埋まっていることになる」

長男「そうだね」

私「で、次に『みなさーん、《自分の番号×2の巣》に移ってくださーい』という。すると鳩たちは一斉にザザザザッと移る」

長男「あはは」

私「1番の鳩は2番の巣へ、2番の鳩は4番の巣へ、3番の鳩は？」

長男「6番の巣へ。偶数の巣だね」

私「そうそう。偶数番の巣はちょうど一羽ずつの鳩で埋まるけれど、奇数番の巣は空だ。今度は空の巣も無限個ある」

長男「…」

私「そこにカラスの群れがやってくる」

長男「？」

私「カラスにも番号は振られている。『自分の番号×2-1の巣に入ってくださーい』」

長男「奇数番？」

私「そうそう。1番のカラスは1番の巣に、2番のカラスは3番の巣に…めでたく鳩とカラスがぴったり巣に収まった」

長男「ふんふん」

私「そこにフクロウの一団がやってきて…」

長男「もういいよ」

私「これは何度も繰り返せる。ところで昔ゲオルグ・カントールという人がいて」

長男「あ、聞いたことがある。無限のことを考えたんだ。最後、病気になったんだよね」

私「そう。よく知っているね。カントールは、さっきみたいな番号が付けられる無限よりも、もっと《大きな》無限があることを見つけたんだ」

長男「ふうん」

私「ちなみに、番号を付けられる無限の話と、それよりも《大きな》無限の話は、お父さんの本の最後にちょっと出てくるよ」

長男「あのね。自分の子供に宣伝してどうする」

• 《お父さんの本》

追記：この続きをnowokayさんが。

• ふくろうは巣にたどりつけるのかな？

ωは奇数でしょうかね。偶数でしょうかね。

追記：はてなブックマークに「集合論者にとってはωは偶数なんですが。」というコメントが。そ、そうなんですか。解説お願いします。すごく知りたい！

追記：くるるさんに解説していただきました。ありがとうございます。これから読みます。

• なぜωは偶数か

読みました。理解しました。なるほど、なるほど。ところで、こういう拡張が意味があるかどうかわかりませんが、この定義だと、ω+1はどんな順序数でも割り切れないので「素数」ですよね！

火曜日も淡々と仕事。6月中に行うべきお仕事の1つが完了。感謝。

haskellグループの参加者が少しずつ増えている。 なんか楽しいな。

• haskellグループ
• Haskellの勉強 - 結城浩のHaskell日記

「理解できてもできなくても良いから、 とりあえず全ページには目を通す」 という気持ちで毎日ちょっとずつ読んでいた クヌース先生の第三巻もほぼ終わった。 次は何を読もうかな。

• 『The Art of Computer Programming Volume 3 Sorting and Searching Second Edition 日本語版』

結城は、家のあちこちに読みかけの本が置いてあり、 毎日少しずつ読んでいます。 上のクヌース先生の本もその一冊。 読むときには、鉛筆でがしがし書き込みしたり、 ページの端を折ったりしています。 そして折を見てその書き込みをコンピュータに移しています。 そんな風に進む読書はとても楽しい。

月曜日は淡々と仕事。 プリントアウトした原稿に書き込んだメモをコンピュータに移しながらいろいろ考える。

モノクロ画像がカラーに見える錯視です （目が疲れやすい人はご注意ください）。

(1) 下の「パールちゃんの画像」を表示します。

(2) ぼんやりしたパールちゃんの画像が表示されます。

(3) 中央に描かれた ＋マークを約10秒間じっと見つめます（目を動かさない）。

(4) 約10秒後、自動的にモノクロ画像に変化します。

(5) モノクロ画像になったはずなのに、目を動かすまでの間、ほのかな色がついて見えます。

• パールちゃんの画像

以下で紹介したページを参考にして作りました。

• モノクロ画像のお城がカラーに見える

追記：

なお、 Perlクイズのイラスト「パールちゃん」は 橋本礼奈さんに描いていただいたものです。

• 橋本礼奈画帖

先日のPerlish Hotlinks(ささださんによるインタビュー記事)でのイラストにも使わせていただきました。

• Perlish Hotlinks

2004年11月の日記ダイジェストを更新しました。

• 日記ダイジェスト
• 2004-11-15 - 日記を書く心がけ
• 2004-11-10 - 10年前、9年前、8年前、何をやっていたか
• 2004-11-07 - いつも喜び、絶えず祈り、すべてのことに感謝する人生
• 2004-11-07 - 『無限を求めて ― エッシャー、自作を語る』
• 2004-11-06 - 弱点の指摘が応援になる文化
• 2004-11-03 - ソースの品質を上げる方法
• 2004-11-02 - はてなの利用を一時停止
• 2004-11-01 - Knuth先生の。

この月もまた、 プログラマの数学を執筆している真っ最中ですね。

以下は書籍執筆の様子だけをピックアップしたものです。 少し長いのですけれど、読み返してみて、 わたしとしては得るものが多くありました。 やっぱり日記って良いですね。

• 2004-11-01 - 神さまを信頼して本を書く

「テキストとプログラミングの寡黙な情報集」として ご愛読いただいている www.textfile.org を「はてな」に引っ越しました。

• 旧: http://www.hyuki.com/t/
• 新: http://d.hatena.ne.jp/textfile/

これまで通り、よろしくお願いいたします。 いちおう、RSSは自動的にリダイレクトするようにしてあります。

www.textfile.orgは、 Webで見つけた興味深いページのクリッピングサイトです。 ときどき結城が淡々と説明を書くこともあります。

どうして「はてなブックマーク」にしなかったかというと、 「はてなブックマークライター」がないからですね。

追記：ん？ それPlaとか言われてるし。 …そうか！

月曜日は淡々と仕事。

手書きのメモをコンピュータに移し、メモのほうには×印を付けておく（コンピュータに移した印）。 それからコンピュータのメモを読み返し、整理する。 アイディアメモの中には、そのまま直接本文に組み入れられそうなものもあったので、試しに入れてみる。 意外にしっくり収まる。それはそうか。 思いついた時と場所が離れていても、「わたし」という一人の人のフィルタを 通ってきたものだからね。何らかの統一性・一貫性はあるんだね。

全体をPDFで出力してみて、読み返してみる。 なかなか楽しいなあ。 全体の手直しをしたり、細部をいじったりする。

どこかで、全体をぎゅうっと絞る必要はあるけれど、 まずは大きく広げてみよう。 独立なベクトルをたくさん詰め込んで、広い空間を張ってみよう。 全貌をつかんだ後に、主成分を見つけ出そう。

午前中は家族みんなで教会。

午後からお昼寝。

夕方から、奥さんと二人で生協にお買い物にいきました。 トマトと、パイナップルと、オレンジと、味付け海苔と、おせんべと、 牛乳を買いました。

帰ってきてから、HaskellのPreludeモジュールの関数を自作する練習をしていました。 まとめて書いていると、2004年末にHaskellの勉強をしていたころのことを思い出し、 勘が戻ってきました。ちょっとうれしい。

• Haskellの勉強 - 結城浩のHaskell日記

haskellグループも何人かがいろんな形で利用してくださっているようです。感謝です。 やはり、オープンにすると何かが起きるものですね。babieさんにもあらためて感謝します！

• haskellグループ

あ、誤植発見。

『The Art of Computer Programming Volume 3 Sorting and Searching Second Edition 日本語版』のp.443。「飛ばしよい」は「飛ばしてよい」の誤植。

今日も「作業ログ」を読み始めて仕事開始。 作業しながら作業ログを更新。 最後に作業ログに書き落としがないかどうか確認。 Subversionにcommitして一段落。 これが、今日の一歩。