listen to my digital heartbeat.

　GIMPというグラフィックソフトの自動処理機能を使いたいと思って、そのScript-Fuというマクロ言語について知りたいと思っていた。本屋にあった「GIMP入門」みたいな本やムックでは全く触れられていなかったので、WEB上で情報を探し、取り敢えずGoogleで一番上に出てきた「Script-Fu 青空教室」というWEB Pageを見てみた。

　で、わかったのは、Script-FuがSchemeというプログラミング言語に基づいていて、そのSchemeはかのLispから派生した言語だということ。Lispと言えば、BASICだのCだのといった「手続き型」のプログラミング言語とは全く異なる「関数型」の言語で…、正直ビビる。

　ところが、上述のWEB Pageを見ながら、GIMPに備わっているScript-Fu ConsoleというScript-Fuインタプリタを使って対話的に試してみると…、これが面白い。

　そう思ったのは、そもそも「インタプリタによる対話的実行」ってのが面白く（Rubyのirbを試してみたときもそうだった）、WEB Pageの内容も「Script-Fuを書くのに必要最小限の内容で、最初の敷居を思いっきり低く」というコンセプトで書かれていたせい、更にはSchemeという言語の仕様が驚くほどシンプルであるせいなんだけど、たぶんそれだけじゃあない。

　「関数型言語」と聞くと、「手続き型言語」とは全く異なる方向性のプログラミング言語を想像していたんだけど、CPUのできることを思い浮かべて、そこから（どんなプログラミング言語が可能か）言語仕様について考えてみれば、そんなにかわらないもののように思う（いや、そりゃもちろん違うけど…）。むか〜しの「はじめてのBASIC」だとか「はじめてのC言語」なんて入門書に載っていたプログラム例を知っている者としては、何ら違和感を感じない。

　もちろん、最近のプログラミング雑誌に載っている、オブジェクト指向言語やLight Weight Languageによるプログラム例とはまるっきり趣が違うんだけど、それって言語の方向性の違いというより、そこで行っている処理のレベルの違いではないか、と思う。

　最近の雑誌には、「たった数行で、（以前だったら大変だった）こんな処理が簡単にできます！」みたいな例がたくさん載っているんだけど、たった数行で何故面倒な処理が実現できるかと言えば、そういったプログラムの行っていることが（クラスの記述ではなく）「クラスの操作」であるからだ。

　それに対して、むかしのBASIC入門やC入門に書かれていたのは、処理の内実みたいなもので、今で言えば、クラスの中身の記述。僕は「プログラミング」というと、そっちの方がすぐに思い浮かんでしまうタイプなので、むしろ最近のプログラム例の方に違和感を感じてしまう。

　Lispと言えば、「カッコ」の多さがよく揶揄されているけど、それも納得。「繰り返し」って、同じことを直線的に延々と（加算的に）繰り返すか、レベルを変えて同じことを（乗算的に）繰り返すか、によって実現されると思うんだけど、Lispって乗算的な繰り返しに重きをおいているのかな、という印象（forすらないのに、関数の再帰的定義はできる、とか…）。たぶん「レベルを変える」仕組みが「関数」なんだろう。だから、「関数型」言語。

　まだよくわかんないけど、ひょっとしたら、関数の定義そのものをプログラムの実行中に動的に変えることができるんじゃないか、という雰囲気を感じて目が啓かれる想い。そういうことを現代のプログラミング言語で出来たとしてそれほど驚かないけど、Lispと言えばむか〜しからある言語なわけで。

　とにかく何か面白そう。ただし、深入りはしない予定（取り敢えず、あるフォルダ中に存在する全ての画像を開いて、ちょっとしたフィルターをかけて、サイズ変更して、ファイル形式を変えて、セーブして、閉じる、とか、そういうことが出来ればそれでいいんで…）。

　2年前の冬に買った、New BalanceのSN400(BK)という靴を普段履きに愛用している。所謂、スノトレだ。

　ところがだ。この靴、雪の上はまだしも、氷の上は無茶苦茶滑る。普通の冬靴よりも滑るように思う。

　気温がプラスに転じれば雪は融けるが、夜になると凍りつくので危険だ。次の日中再びプラスに転じると、ツルツルに凍った歩道上にいくつもの水たまりが出現するのだ。

　今日も散歩の途中、何度か転びかけた。一度なんか、水たまりの中に頭から突っ込むところだった。あまりの滑りっぷりに正直頭にくる。だって、走っているわけではないのだ。ゆっくり歩いているだけなのに！

　雪の上での滑らなさと、氷の上での滑りやすさのギャップがもの凄く大きい。そこんとこだけ要注意。


※　現在のラインナップからは既に外れているようだ。

　天気が良かったので、散歩ついでに「クラーク亭」の移転先を探しに出た。

　わりとすぐに見つかった。「クラーク亭」という大きな看板がビルから突き出ていて、正面に回らなくても見えるのだ。北16条西4丁目。公園の横。ビルの1階。


　行き方としては、北大通りを北上し、ディナーベルのある角（信号のある角）のところを右にまがる（大塚眼科病院のところ）。次の信号の手前。

　今日はステーキを喰らう正当な理由がなかったので、店の位置だけ確認して帰ってきた。店内をのぞき込んだり、帰りかけてから住所表示を確認するためにまた戻ったりと、すっかり不審人物。

　白っぽい雰囲気の内装でした（あれが油でギトギトに…、なるのかなぁ…）。

　1ヵ月振りに『コーヒープリンス1号店』、第4話より…。






　今日の一言韓国語は、「양다리（ヤンダリ）」＝「両脚」。「二股をかける」の「二股」の意のようです。

　以前、プログラミング初心者向けの「データ構造とアルゴリズム」みたいな本で、「モンテカルロ・シミュレーションで円周率πを求める」という例題を見たことがある（『Visual Basicによるはじめてのアルゴリズム入門』（河西朝雄　1999年　技術評論社）ではないかと思うのだが…）。

　原理は簡単で、正方形の板に向かってひたすらダーツを投げる、というもの。その正方形を単位円の描かれた第一象限と見なして、円の内側にある穴の数と外側にある穴の数の比からπを算出するのである。

　正方形の一辺の長さをrとすると、面積はr²。1/4円の面積はπr²/4だから、全ての穴の数に占める、1/4円の内側の穴の数の比率は、π/4。4倍してやれば、πが求まる。


　r = 1とすればプログラムは簡単で、0〜1の実数の乱数xとyを生成し、x² + y² <= 1だったら円の内側、else 外側。

　1万回投げれば、3.13〜3.16の値が出る。1万回なら投げて投げれないことはない。

　半年ほど前、ショックな出来事があった。それまでずっと正しいと信じていたアルゴリズムが間違いであることが判明したのだ。

　コトの発端は、このブログにもたま〜にコメントを書き込んでくれる木公さんのブログで、ある確率を求めるために始めたモンテカルロ・シミュレーション。そこで行われていた「ランダマイズ」処理。

　「ランダマイズ」ってのは、要するに、トランプの「シャッフル」みたいなもので…（後から考えてみれば、この程度の理解しかしていなかったことが間違いの原因だったのだが）。例えば、0から9の数字の書いてある10枚のカードがあるとして、これが1列に並んでいる。これをデタラメに並べ替えるような処理。

　僕がいつもやっていたのは、次のようなやり方。

　まず、SeatNo[]という「席順」を管理する配列にあらかじめ0〜9の数字を入れておいて（初期状態では、0〜9の順に並んでいるということ）、
for (i = 0; i < SeatNo.Length; i++)
　　SeatNo[i] = i;

　次に、ある位置に置いてあるカードとその位置とは異なる位置に置いてあるカードとの入れ替えを、全ての位置について1回ずつ行う（方式1）。
for (i = 0; i < SeatNo.Length; i++) {
　　do {
　　　　r = rnd(0, SeatNo.Length);　　　　
　　} while (i == r)
　　swap(SeatNo[i], SeatNo[r]);
}
ここで「rnd(x, y)」というのは、x以上y未満の整数の乱数を返す関数。

　「何かdo-while文が嫌だなぁ〜」という気分のときは、「『自分自身と入れ替える』（結局入れ替わらないが）ってのもアリにしよう！」と、
for (i = 0; i < SeatNo.Length; i++) {
　　r = rnd(0, SeatNo.Length);　　　　
　　swap(SeatNo[i], SeatNo[r]);
}
こうしていた（方式2）。

　アイデアのモトにはまさに「トランプのシャッフル」がある。目の前にトランプを1列に並べて、これとこれ、これとこれ、とデタラメに選んでは入れ替えていく。ところが、木公クンの調査によると、このやり方では「ランダマイズされていない」という。

　上のやり方で、もしちゃんとランダマイズされているのだとしたら、ランダマイズ後の各SeatNo[]には0〜9が等しい確率で入っているはずである。初期化してはランダマイズ、初期化してはランダマイズ、という処理を嫌になるほど繰り返せば、各SeatNo[]には平均して「4.5（0〜9の平均値）」に近い値が入っているはずである。そうなってないなら、何かが間違っている、ということである。

（ところで、関係ないけど、プログラミングの本を読んでいると、上の「嫌になるほど繰り返す」みたいな表現を「文学的表現」と呼ぶ人がときどきいる。一種のお世辞のつもりなのか、「文学」に対する揶揄なのか、あるいは単にバカなだけなのかよくわからないが、いずれにせよ、その著者自身の文章表現力の乏しさみたいなものが表われてしまっているように思う。）

　そこで、実際に上の（偽）ランダマイズ処理を1000万回行って平均値を求めてみると…、


確かにランダムになっていない（笑）。それどころか、綺麗にバイアスがかかってる（涙）。この「中央より後半で膨らむ」形は、並び替えるカードの枚数に依存せずに現れる。

　考えてみれば、「ランダマイズ」というのは、単に「シャッフルする」ことではなく、文字通り「ランダム」にしないといけない。つまり、現在の状況（並び替え前のカードの並び方）に依存せずに、生じうる全ての事象（「並び方」）が等しい確率で生じるような方法で並び替えなければ「ランダマイズ」とは言えない。ところが、僕は「デタラメに入れ替える処理を何回も繰り返せば、『ランダム』になるだろう」という程度にしか考えていなかった。逆に言うと、僕の「トランプのシャッフル」では、トランプの並び方はランダマイズされていないんですね。ランダマイズされているという前提で賭ければ、当然負ける。

　よ〜く考えてみれば、上のやり方で「ランダマイズされていない」のは当たり前で、方式1だと9¹⁰＝3486784401通りの「並び替え」パターンが生じうるし、方式2だと10¹⁰＝10000000000通りの「並び替え」パターンが生じうる。ところが、そもそも10枚のカードの「並び方」のパターンというのは、10!＝3628800通りしかない。そして、9¹⁰も10¹⁰も10!で割り切れない、ということは（ということは！）、これらの方式の「並び替え」では、各事象の生起確率に偏りがある、ということである（割り切れたとしても「各事象の生起確率が等しい」ことの保証にはならないが、割り切れていなければ絶対にダメである）。

　例えば、ABCという3枚のカードがあるとして、この3枚のカードの「並び方」のパターンは、ABC、ACB、BAC、BCA、CAB、CBAの6通り（＝6!）しかない（まさに「順列」）。今、ABCの順で並んでいるとして、これを方式1で並び替えると生じる結果は、何とACB、BAC、CBAの3通りしかないのだ！　生起頻度は、ACBとBACが3回ずつ、CBAが2回で、全部足すと当然8回（＝2³）。方式2で並び替えると、8通りの「並び方」全てが生じるが、生起頻度は、ACB、BAC、BCAが5回ずつ、ABC、CAB、CBAが4回ずつ、と偏っている（全部足すと27回（＝3³））。

　では、どうすればちゃんとしたランダマイズになるかと言えば、これがまた信じられないくらい単純な話。「順列」の考え方そのもので、あるカードとの入れ替え相手を決めるときに、既に確定したカードを選ばないようにするだけでいいのだ（方式3）。
for (i = 0; i < SeatNo.Length; i++) {
　　r = rnd(i, SeatNo.Length);　　　　
　　swap(SeatNo[i], SeatNo[r]);
}
　どこが変わったかわかるだろうか？　「rnd(0, SeatNo.Length)」じゃなくて「rnd(i, SeatNo.Length)」。「0」を「i」にする。この1字の違いが大違い。上述の1000万回ランダマイズして平均値を求めてみる実験だと、どの位置の平均値も4.499〜4.501の間に納まっている（グラフを参照のこと）。このやり方だと、「並び替え」パターン数と「並び方」パターン数は一致するし、よ〜く考えれば、全ての「並び方」が1回ずつしか生起しないこともわかる。

　この間違いが何故それほどショックだったかという言うと、有史以来僕が書いたあらゆるプログラム（その中には研究の一環として書いた実験制御プログラムやコンピュータ・シミュレーションのプログラムも当然含まれる）で、方式1か方式2を使っていたから。しかも、自分で書いたプログラムだけでなく、他人にまで「ランダマイズはこうやる」と何の疑いももたずに広めていたのだ。それが間違いだったのである。

　半年経ってようやくショックは消えた。また、「ランダマイズ」という処理が単なる「シャッフル」とどう概念的に異なっているのか、よ〜く考えてみる機会を得て、「ランダマイズ」に対する洞察を多少なりとも深めることができたので、今となっては、まぁ良しとしている。やっぱり数学というもの、あるいは数学的素養というものは必要なものである。

　『フルスクラッチによるグラフィックスプログラミング入門』
　須崎　亮太郎・荻野　友隆・内村　創　（著）
　2004年
　秀和システム
　★★★★☆

　OSのAPIや既存のライブラリを使わずに一からグラフィックプログラムを書いてみよう！という本。WindowsAPIを鼻歌まじりに使えるプログラミング中上級者向け。サンプルプログラムはC++で記述されている（開発環境としては、C++BuilderとVisual Studio.NET 2003が用いられている）。

　数年前に本屋で見かけ、その心意気に惚れて買ってはみたものの、そのまま読まずにいた本。表紙の印象から、理系の大学教科書のようなお堅い本を想像していたが、読んでみると意外とオタク的なプログラミング本だった。

　構成としては、画面上にビットマップや図形を描画する方法を考えながらプログラムを開発していく「グラフィックプログラミング」パート（第3・4章）と、HDR画像、レベル補正・ガンマ補正、オプティカルフロー、ハフ変換、直交変換・ウェーブレット変換、等を扱っている「画像解析」パート（第5章）が、本書の中心となっている（おそらく、執筆担当者が違う）。これに、Windowsでのグラフィックプログラミングの基礎（第2章）や、各種画像ファイルを読み書きするライブラリ（第6章）、その他（第7章）の情報が付加されている。

　著者らは、主にゲーム開発や2D CGに関わっている、まだ若いプログラマのようだ。「図形の『内側』を塗りつぶす」ために「そもそも『内側』かどうかをどうやって判定するのか！？」とベクトルの内積・外積の話になったり、「色」について語るために視神経の錐体細胞・杆体細胞の話になったり…と、この紙数ならではの遠回りが楽しい。

　もともとコンピュータに興味をもったキッカケがコンピュータグラフィックスだったこともあり、Adobeのグラフィックソフトや3D CG・CADソフトを使って綺麗なCGを描きましょう、というのではなく、CGソフトそのものを自作してしまいましょう、というこの本のコンセプトにたまらなく惹かれてしまった。ちょっとした工夫でプログラムの高速化を実現したり、曲線を滑らかに表示するために様々なアイデアを絞り出していく様には大いに勇気づけられた。また、2次元画像の直交変換やウェーブレット変換の原理が腰が抜けるほど簡単なことにも驚いた。

　本書には余計な情報がたっぷり詰まっている（何と、使いもしないのにミニ「アセンブラ入門」の節まであるのだ！）。「車輪の再発明」も厭わず、というスピリットに共感できる人なら面白く読めるだろうと思う。

　本文540ページ程度。



→　Kota's Book Review
→　Terai, S. Web Page

　『見えてくる数学――受けたかったこんな授業――』
　小林　吹代　（著）
　2007年
　すばる舎
　★★★☆☆

　現役の中高生、あるいは、「大人のための数学再入門」的な本を求めている社会人を対象に書かれた、学校数学の本。取り上げられているのは、「負の数」「文字式」といった中1レベルの数学から、複素数、指数・対数、三角関数、確率といった高校レベルの数学まで（微分・積分、数列、行列、ベクトル、等は扱われていなかった）。

　全22章構成。各章10ページ程度で小気味よく進んでいく。著者は高校の数学のベテラン教師で、コツコツと書きためていた原稿を1冊の本にまとめたものが本書なのだとか。そのせいか、基本的には教える側の立場に立ちつつも、教わる側の視点から見た素朴な疑問のようなものが本書の内容に活かされていると思う。本書で何より著者が大切にしているのは「概念のイメージを伝えること」とされているが、むしろ（虚数や対数、三角比など）「こんなものが何の役に立つのだろう？」と思いがちな概念について、その苦い想いを汲み取ってくれた上で教えてくれていることの方が有難い。

　ククク、と笑いを押し殺しながら読んだような箇所はたくさんあったのだけど…、「やり直しの数学」みたいな本をわりとよく読んでいる僕としては正直モノ足りなかった。本書では、そのコンセプト上、学校数学の範囲の中で納得できればそれで良しとする雰囲気があって、学校で習う数学の背後に広がっているはずの数学的世界が見えてこないのだ。小学生向けの『はじめまして数学』シリーズ（吉田武（著）　大高郁子（絵）　2001〜2002年　幻冬社）、中高生向けの『生き抜くための数学入門』（新井紀子（著）　2007年　理論社）、大人向けの『数について』『式について』（「はじめからの数学」シリーズ）（志賀浩二（著）　2000年　朝倉書店）、『指数・対数のはなし』（森毅（著）　2006年　東京図書）、等が面白かったのは、学校教育のカリキュラムを離れて自由に数学的世界と現実の世界を行き来することで、数学的な「モノの見方」や「考え方」、更には「感じ方」というものまでが見えてくるように思えたからだ。そういう意味では、学校で習う「数学的概念のイメージ」だけが見えてくるだけではダメなのだ、たぶん。

　本文205ページ程度。



→　「１２　さんすう　３４　数学　５　Go!」
　（本書の母体とも言える著者のWeb Page）
→　Kota's Book Review
→　Terai, S. Web Page

　『Javaデザインパターン徹底攻略』
　日立ソフトウェアエンジニアリング（株）インターネットビジネス部　（著）
　2002年
　技術評論社
　★★★★★

　GoFデザインパターン解説書の体裁をとった「オブジェクト指向設計」入門。コンパクトにまとめられた良書だと思う。

　対象読者は、Javaの文法を一通り理解しており、プログラミングにも慣れてきた頃のJavaプログラマ。GoF本のデザインパターン23種類を順に取り上げ、各パターンの目的・効果・背景・サンプルプログラム・注意点を簡潔に述べていく。ただし、デザインパターンをすぐに使いこなせるように読者を導くことが本書の狙いではなく、デザインパターンを教材として「良いクラス設計とは何か」の指針を与えることに主眼を置いている。

　そのため、各パターンの解説では、そのエッセンスだけを簡潔に伝えることに注力されている。サンプルプログラムは全てJavaで記述されているが、どれも「Hello, World!」レベルなので、Javaプログラマでなくても内容を理解できると思う（巻末に、サンプルプログラムを理解するために最低限必要なJava言語仕様が25ページ程度にまとめられている）。

　開発の現場から生まれた本、という印象を受けた。各パターンの解説の最後に置かれた「注意点」が秀逸で、「そのパターンを用いる場合、何に注意しなければならないか」「そのパターンを用いない方がいいのはどのような場合か」「そもそも、デザインパターンを適用することで解決できるような問題はそれほど多くない」といった類の指摘に説得力がある。また、デザインパターン万能論とも言える数々の「誤解」について述べた最終章「デザインパターンの難しさを理解する」も面白い。

　本文190ページ程度。



→　Kota's Book Review
→　Terai, S. Web Page

　「エウレカ！」と初めて感じることができてから早2ヶ月半。「オブジェクト指向プログラミング」の本をいろいろ読み直してみて、自分が何故これまでオブジェクト指向をさっぱり理解できなかったのか、いろいろ理由がわかってきた。わかっている人には矛盾には見えないが、わかっていない人には矛盾して見える要素が、オブジェクト指向にはたくさんあるのだ。

　例えば、用語の使い方が著者によって微妙に異なる。「カプセル化」「継承」「多態性」と言えば、「オブジェクト指向三種の神器」だが、これほど基本的な概念ですら、著者によって使い方が違うのだ。

　例えば、「カプセル化」については、「データと処理を1つにまとめること」すなわち「クラスを定義すること」そのものが「カプセル化」だとする著者もいれば、「公開する必要のないデータや処理を隠すこと」すなわち「隠蔽」が出来て初めて「カプセル化」だとする著者がいる。わかってしまえば、どちらの言い分も理解できるのだが、たったこれだけの違いでも「全て」が理解できなくなってしまうのが、僕という人間だ（「全か無か人間」をなめんなよ）。

　「多態性」についても、「メソッドのオーバーライド」によって専ら実現されるという記述もあれば、「メソッドのオーバーロード」によって実現されるという記述もあり、更には、「1つのクラスから複数のインスタンスを生成できる」ことによって「多態性」が実現されるという記述もある。確かにどれも間違っていないが、こんなの僕に理解できるわけがない。

　いくらなんでも「継承」にはこんな混乱（？）はないだろうと思うかもしれないが、文字通り「スーパークラスを『継承』する」意味だけでなく、「インスタンスを生成すれば、クラスの定義が『継承』される」なんて使い方までされている（それでいて、むしろ「スーパークラスの継承」に近いと思う「インターフェースの実装」を「継承」と呼ぶ例はあまり見ない）。

　こんなのはちょっとした用語の振れに過ぎない。たぶん僕がオブジェクト指向を理解できなかった最大の理由は、オブジェクト指向の説明には、クラスを作る人の立場に立った説明と、クラスを使う人の立場に立った説明があることだ（これは、誰もがクラスを作る立場にも使う立場にもなるのだから、仕方ないことなのだが）。

　例えば、「『多態性』を利用してシステム開発が効率化できます！」というのは、クラスを使う人の立場に立ったものの見方。クラスを作る人の立場に立てば、その「多態性」を実現するために、手間が増えているはずである。

　反対に、「『継承』を利用すればシステム開発が効率化できます！」というのは、クラスを作る人の立場に立ったものの見方。「多態性」を実現しなければならない手間を「継承」を利用することによって減らすのだ。

　C++/JAVA系のオブジェクト指向の勘どころは、たぶん「データの処理はデータ自身にさせる」こと。そういう、自らの身の処し方を知っているデータをオブジェクトというわけで、そういうオブジェクトの連携作業でシステムを構築しようというのがオブジェクト指向。そのメリットを享受できるのは、木を見て森を見るべき立場にいる人。たぶんオブジェクト指向という「ものの見方」でシステムを見ることによって、全体を見やすくなるのだろう。

　それに対して、一本一本の木を植える立場にいる人にとってのオブジェクト指向のメリットは違う。クラスの継承ができるとか、内部の隠蔽ができるとか、どちらかと言うと実装技術によってもたらされるものなのではないかと思う。

　どちらも「オブジェクト指向の恩恵」には違いないのだろうけど、僕には全く違うものに見える。いや、これまでは、違うものに見えなかったので、混乱していた。「違うものに見える」ようになってきた、ということが、僕にとっては、オブジェクト指向がわかってきた、ということなのだ。