(株)スリーディーCTO加納裕のBLOGです

"Real-Time Rendering 3rd edition(2008)"の7章"Advanced Shading"に、"Half Vector versus Reflection Vector"という3ページの記述がありました（pp.249-251）。このタイトルからピンときました。これは私が以前読んで驚いた、SIGGRAPH2004スケッチの内容ですね。このスケッチのタイトルは、"Experimental Validation of Analytical BRDF Models"。

本書で引用している論文は、2005年Eurographics Symposium of Renderingのものですが、著者は同じなので同じ内容でしょう（タイトルもほぼ同じ）。どのような内容かと言うと、「スペキュラ計算においてはhalf vectorを使うべきで、reflection vectorは現実に即さないので使ってはダメ」ということです。

これは説得力があります。というか、もう勝敗は決しちゃったかも。もしもreflection vectorをお使いの方、速やかにhalf vectorに移行されることをお勧めします。以前は私も両者は同じようなものだと思っていたのですが、状況によっては全然結果が違うんですね。ビックリです。

私は古本が好きで、昔は神保町の古本屋街をふらふらと散策したものでした。絶版本を探して買ったこともありました。でも、今では古本屋さんは商売が難しくなっているようですね。高価な専門書もなかなか売れる時代ではないようですし...

こんな時勢でのBOOK･OFFの成功は、驚嘆に値します。うまいシステムを作り上げたと思うのですが、古本でうまく商売ができているのであれば、それは見事の一言。

自宅の周囲にも、BOOK･OFFは2件あります。車で行くところと、最寄駅近くです。神保町の古本屋さんとは趣は違いますが、古本であることに変わりはないです。重宝しております。買いもしますが、結構売りさばきました。

今回の日本VR学会大会（奈良先端科学技術大学院大学、2008年9月24〜26日）では、座長を仰せつかりました。初日（24日）14:45からの、「アート＆エンタテインメント3[1C5]」というセッションです。お引受けはしましたが、確か質問が無いときは、代わって質問をしなければなりませんね（それもツボを突いたものであるとベター）。ですから、ボ〜と聴いているわけにはいかないのです。質問がドンドン出てくれるとありがたいのですが...質問が無いときは、学校みたいに質問者を「指名（＝つまりアテる）」することはできないのでしょうか。これまで参加した学会では、そのような光景は見たことがありませんので、たぶんダメなのでしょうね。

"Real-Time Rendering 3rd edition(2008)"がやっと到着。ホントは夏休みにでも読みたかったのですが、なかなか配送されてこなかったのでした。でも、夏休みは殆どありませんでしたので、早く着いても同じでしたけれど。

三版のトピックは、一言でいうとライティング関連ですね。二版の6章"Advanced Lighting and Shading"が、7章"Advanced Shading"、8章"Area and Environmental Lighting"、9章"Global Illumination"の三章に拡大されたという印象です。BRDF関連や、Precomputed関連など、二版（2002年）以降急速に研究が進んだ題材を取り入れたのでした。ちょっと読み応えありそう。

それから、GPUを含めたハードウェア周りも勿論更新されていますが、この辺は書籍としては書きづらいところでしょうね。何と言っても、陳腐化しやすいですからね。

逆に更新の少ないところは、既にほぼ確立された分野。例えば、"Transforms"、"Polygonal Techniques"、"Curves and Curved Surfaces"、"Acceleration Algorithms"、"Intersection Test Methods"、"Collision Detection"などです。でも、二版ではモノクロだった図が、殆どカラーになっていますので、見ていて楽しいです。綺麗ですよ。

上記「ライティング三兄弟（7〜9章）」の内容は、読んだらレポートします（読めたら）。

計測データをM次元列ベクトルとして、それがN個あったとすると、それらをまとめた行列Xは、MxNのサイズです。さて、PCA（Principal Component Analysis）を適用するには、共分散行列を求める必要がありますが、これは

XX^T --- (1)

と書けます（正規化などは無視）。サイズはMxMです。三次元空間上のデータを処理するような場合、式(1)は3x3行列になりますから、固有値の計算は簡単ですね。

ところが、逆の場合はどうでしょう。つまり、計測データNはそれほど多くないものの（例えば10〜100のオーダ）、計測するベクトルの次元Mが膨大（例えば数万〜数百万のオーダ）という場合。この状況では、式(1)をそのまま適用すると、とんでもないサイズの行列を処理するハメになります。

ところが、式(1)を逆にしてやると、

X^TX --- (2)

式(2)は計測データ数のサイズの正方行列（NxN）となって、しかも式(1)と式(2)の固有値は同じになるのです。だったら、式(2)で計算した方が断然ラクですね。

この辺の事情は、金谷先生の「これなら分かる応用数学教室（2003）」219ページから詳しく書かれてあります。興味ある方はご参照ください。

PCA（Principal Component Analysis）が、三次元どころか、非常に高い次元のデータに適用される事例がある、という話題の続きです。

しかし、このようにバカ高い次元のデータを、ひとつのベクトルと見なしてPCAを適用するというのは、計算上は可能なのでしょうけれど、私としてはシックリきません。だって、次元以外の構造を考慮しないので、それこそ何でもアリになっちゃいますからね。大丈夫なのでしょうか。広く使われているので大丈夫なのでしょうね。

でも、便利は便利です。例えば、新しいイスを設計したいとしましょう。但し、世の中に出回っているイスと全く異なっては困るとします。その場合、様々な既存のイスデータ（＝頂点）を並べてひとつのベクトルと見なし、これにPCAを適用します。すると、何個かの「基底イス」が得られますから、この「基底イス」の線形結合で、それこそ無限個のイスが自動生成できるのです。最も、データの整合が必要で、詳細の取り決めが要りますけどね。イスならば何でも良いというわけではありません。

線形結合で思い出したのですが、「シュレーディンガーの猫」で、「生きた猫」と「死んだ猫」の線形結合云々、という論争がありましたね。あれは決着がついたのでしょうか？あ、これは全く違う話題ですね...

Principal Component Analysis（PCA：主成分分析）は、データ解析の上で必須のツールですね。これは勉強した方が良いかも知れません。いろいろと使えますよ。

当社業界でのPCA用途としては、三次元空間上に散らばったデータに対して、主要な軸を求めたりするのに使われます。例えば、Eric Lengyelの"Mathematics for Game Programming & Computer Graphics 2nd edition(2004)"、Chapter 7に典型的な事例があります。こういうのは直接的で分かりやすいですね。

ところで、PCAは三次元どころか、もっともっと大きな次元を持つ空間の解析にも使えます。以前から事例はあったのでしょうが、私が初めて明確に意識したのが、MatusikらによるSIGGRAPH2003論文、"A Data-Driven Reflectance Model"でした。これは、BRDFの膨大な計測データをコンパクトに表現する面白い研究なのですが、そこでBRDF計測データにPCAを適用しています。

この研究では、一回の計測で4,374,000個ものデータ（様々な角度でのRGB値）を得るのですが、これを4,374,000次元（！）の（列）ベクトルと見なします。104回の計測結果を行列X（4,374,000x104）にまとめて、ここからPCAの適用。先ず、X^TXを作ります。これは104x104の行列になります。これにsingular value decomposition（SVD：特異値分解）を適用して、その特異値の平方根が求めたい固有値となります。というか、なるそうです。私の浅学では、、X^TXの固有値がそのものという気がしているのですが、たぶん私が間違っているのでしょう。でも、似たようなものです。

他の有名な応用としては、顔の生成（face synthesis）がありますね。当社でも今、ちょっと似たような案件を進めています。

やはりプロジェクト管理は難しい！いろいろと気を付けていても、ちょっとでもスキを見せれば、問題が生じるのです。IT企業であればどこもお悩みと思いますが...もしかすると永遠のテーマ？

最近、そのような悩みを反映したかのように、関連本が次々と出版されています。そのひとつ、香村求氏の「IT赤字プロジェクトの立て直し・火消し対策（2007）」というのを読んでみたのですが、これで思ったことは、やはり特効薬（siliver bullet）は無いということ。真面目に必要なことを必要なだけやる。これだけです。でも人間は怠けものですし、ミスも犯すのです。

そんなグチを言っていても仕方がないので、少しずつでも善処しなければ。となると、やはりagile系でしょうか。Craig Larmanの"Agile & Iterative Development(2004)"に洗脳されて久しい私ですが（これは絶対に読んだ方がいいです！）、本書はあくまでも概論で、詳しいagileの方法論は書かれていません。というわけでもう少し勉強したくなった私は、amazonでいろいろと調査。

そして見つけたのが、Mike Cohnという人の、"Agile Estimating and Planning(2005)"です。本書はかなり読まれているようです。評価も本日（2008年9月1日）時点で、43人中35人が星5つです。というわけで購入。早く来ないかな。読後はご報告します。

"OpenGL ES 2.0 Programming Guide(2008)"が到着。400ページ強と薄いです。「400ページは厚いんではないの？」と言われると困るので、何と比べてかというと、所謂"Red Book"と"Orange Book"と比べてです。ちなみに本書は、"Gold Book"と言うらしいです。表紙の印象では"Gold Book"という感じではないですが。

ページ数からすると、以下の式ですね。

"Gold Book"＝("Red Book"＋"Orange Book")／4 --- (1)

内容はと言うと、これも式(1)のような感じです。贅肉がザクっとそぎ落とされて、エキスだけになったということでしょうか。Vertex shaderとfragment shaderの説明が主ではありますが、それ以外として、primitive assembly、rasterization、texture、fragment operations、など、シェーダからあぶれたところがところどころに載っている、という印象。

誠に簡潔ではありますが、さて、OpenGLとかシェーダとか知らない人が、本書だけでOpenGL ES 2.0をマスタできるかと言われると、何とも判断できません。何かしら不思議な本です。

ところで、OpenGL ES 2.0の特筆すべき仕様は、「固定」機能が省かれたことですが、この理由が3つ書かれてあります。そのひとつが、ISVにインタビューした結果。殆どのISVでは、「プログラマブル」と「固定」をミックスしないということでした。だから、「プログラマブル」に行くためにOpenGL ES 2.0を使うのであれば、じゃあ「固定」は必要ないよね、という論理です。

（2008年）6月2日から来日していたフランス人CG君のインターンシップが、昨日（2008年8月29日）終了。約３か月。テーマは「レイトレのGPU実装」です。彼はフランスでCPUのレイトレを実装した経験があったので、理論はちゃんと理解していました。でも、GPUについては殆ど初めてでしたので、シェーダなどを勉強しながら進めました。

結果は一応まとめられて、めでたしです。CG君は喜んでいました。彼の大学は、ESIEA（Ecole Superieure d'Informatique - Elecronique - Automatique）ということろですが、大学も今回のインターンシップ受け入れを喜んでくれていて、来年も打診されています。

ところで、CG君はフランス帰国後大学卒業なのですが、「その後どうするの？」と訊くと、まだ決めていないそうです。これがいつも理解できないんですよ。私の会ったフランス人は例外なくこんな感じです。その場で決めていく、というやりかたです（逆にその場で決められる、ということですね）。「日本では普通は進路は1年前に決めるよ、それが良いかどうかは分からないけどね。日本もフランスみたいにもっとフレキシブルの方がいいかもね」などと言うと、CG君は「フランスはフレキシブル過ぎて、それが良くないこともあります」ですと。ちゃんと客観的には見ているわけです。

しつこく先日（2008年8月22日）のKhronos日本会議の話題です。スミマセン。

会合が終わった後、Neil Trevettさん（KhronosのPresident）に、「SIGGRAPH AsiaでKhronosのミーティングあるんですか〜」などと尋ねたところ、「That's a great question!」などとなって、帰ろうとしていた参加者方々に、「SIGGRAPH AsiaでKhronosが会議をオーガナイズするので、製品のプレゼンに興味ある人いませんか〜？」と訊いていました。私の質問内容がgreatなのではなくて、言おうとしていたことを忘れていたので思い出させてくれてありがとう、ということです。それにしてもNeilさんは気さくな方です。

その時は、「プレゼンしたい！」という人はいらっしゃらなかったようですが（英語の問題ではないです、皆さんNeilさんへの質問は流暢な英語でペラペラやっていましたから）、では私がREMO ESでやろうかな、なんちゃって。本来奥ゆかしい私は、最近図々しくなっているんです（歳のせいでしょうか、気を付けないと）。Neilさんは「プレゼンされたいならメールください」とのことでした。

先日（2008年8月22日）のKhronos日本会合でも、OpenGL ES 2.0はひとつの重要な話題でした。既におおよその仕様は2005年に出来上がっていましたが、実際の製品（＝シリコン）となると、これからですね。まだまだ主流は1.1のようです。でも、興味の対象となると、やはり2.0でしょうか。

ところで、私もうっかりしていたのですが、OpenGL ES 2.0のフルスペックというのは、最近まで存在しなかったそうです。これはどういうことかと言うと、これまでのOpenGL ES 2.0のスペックというのは、（desktop） OpenGLのスペックに対して相対的に定義されていたのでした。私みたいにず〜とマンネリ的にOpenGLに関わってきたヒト（そして当社の多くのヒト）にとっては、これで何の問題もありませんし、逆に分かりやすかったのですが、一方、OpenGLのようなものをES 2.0で初めて身につけようとするヒトにとっては、これは不便です。

という当たり前の理由により、今回OpenGL ES 2.0のフルスペックというのがお目見えしたそうです。Jon Leechさんという方が書かれたそうですね。お疲れ様でした。

コンピュータで数値を求めるとき、数学の公式をそのまま使うことが多いと思いますが、コンピュータと数学で異なるところは、コンピュータの数値精度は「有限」であること。これを忘れてクリティカルな計算をすると、思わぬミスをしかねません。要注意！

最近購入したHammingの"Numerical Methods for Scientists and Engineers(1986)"の1章3節には、"Function Evaluation"と題して、いろいろと関連の話題があります。面白いので、そのひとつをご紹介しましょう。

二次方程式、

ax²＋bx＋c＝0 --- (1)

の解は、中学生でも知っているように、以下で表されます。

x＝(−b±√(b²−4ac))／2a --- (2)

コンピュータで計算するとき、式(2)をそのまま使う人が多いですよね。私もそうです。でも、殆どの場合は大丈夫なのでしょうが、係数a、b、cの関係によっては、精度上問題が起こることがあるのです。例えば、√の中が殆どb²が効いてくる場合（つまり、b²が4acに比べてかなり大きい場合）、√を外すと殆どbですから、bの符号と±の取り方によっては、前項のbと打ち消しあってしまい、結果の精度が悪くなりそうですね。

これを避けるためには、先ずx₁を以下のように求めます。

x₁＝(−b±√(b²−4ac))／2a （±はbの符号と逆を取る） --- (3)

式(2)を使いますが、分子はキャンセルされないように符号に注意します。式(3)でx₁が計算できたら、

x₂＝c／ax₁ --- (4)

として、もう一方の解を求めます。これは式(2)を使うよりも精度上安全と言えます。上記の本には、このような話題がいろいろ載っていて、数学とコンピュータの違いを痛感させられますよ。同じような事例に、

√(x＋1)−√(x) --- (5)

というのもあって、これもxが1に比べて大きい場合に同じ状況となりますが、うまく式の変形ができるのです。

朝日新聞の毎週日曜日に「おやじのせなか」というコラムがあります。私も父親ですので、気になって読んでいます。やはりというか、当たり前というか、父親の振る舞いは子供には影響を与えるらしいです。気をつけなければ...

先日（2008年8月24日）のコラムは小池百合子氏が登場。お父さんは、「石油製品を取り扱う小さな貿易会社を経営し、世界中を飛び回っていた」そうです。お父さんがそんな感じでなければ、小池氏もカイロ留学など考えなかったかも知れませんね。

氏がお父さんから学んだことというのが、「確実な情報をもとに戦略を練った上で、最後はリスクを取ること」だそうです。これは正にその通りです。情報を取ることを怠ってことを興すのは、単なるギャンブルですが、一方、将来のことでは不確実なことは必ずあります。そこはリスクを取るしかありません。充実した人生を送る上で、ひとつの大切な考え方だと思います。失敗もありますけどね...

先日（2008年8月22日）、Khronosの日本向け会合がNVIDIA社（溜池山王）にて開かれました。Khronosグループ代表Neil Trevett氏が、昨年に続き来日したのです。

私は昨年は都合がつかず、代わりに今はフランスに帰国したRBに行ってもらいました。ですから、今年は行きたいのです。でも、またまた先約の会合が社外であります。サボりたいのですが、怒られそうなので、先ずはTIくんに行ってもらいました。私は会合終了後（正確には中座）、30分遅れて到着。参加者は20人程度です。少人数ですが、多分専門家揃いですね。

内容は、先日のSIGGRAPHでの発表内容に準ずるものと思われます（SIGGRAPHには行っていませんので分かりませんが）。先ずは何と言ってもOpenGL 3.0ですね。続いて、COLLADAやOpenGL ESのアップデートが続きます。OpenCLも旬の話題でしょうか。

このような最新の内容を、Neilさんのように直接ベッタリと関わっている人から「生の声で」聴けるのは、何とも貴重な機会です。同じ内容でも、WEBで資料を見るのとは違うと思いますよ。決まったことの背景や、将来の不確実な動向についても、その人個人の意見として訊くことができますからね。

本日（2008年8月24日）で北京五輪は閉幕ですね。そこで、ひとつだけ北京五輪の話題を...

私は特に女子サッカーのファンではなく、北京五輪も、予選の初戦ニュージーランド、第二戦アメリカ、は観ませんでした。しかるに、第三戦のノルウェーは勝たないと予選でおしまい、ということで、どれどれと観てみました。

結果は5-1の記録的勝利。えっ、ノルウェーって、シドニー五輪優勝国なんですけど...というわけでギリギリで決勝トーナメントへ！

準々決勝の地元中国戦は観ませんでしたが、2-0で勝利。多分すごいアウェーだったんでしょうね。タフですね。遂にベスト4まで行ってしまった。メダルまであと一歩です。

準決勝のアメリカ戦はしっかりと観ました。先取点を取ったときは「もしや！」と思ったのですが、アテネ五輪優勝且つランク1位アメリカは、前半終了間際に逆転。ここは力の差です。後半の2点の追加点はアンラッキーで、遂に1-4となってしまいました。既に勝敗という意味では終わってしまったのですが、それでも終了間際に1点入れました！2-4って、スコアとしては悪くないですね。

最終戦は、3位決定戦のドイツ戦。ドイツはランク2位とのことですが、前半は日本が押していて、いつ先取点を取ってもおかしくない展開。でも後半1点取られてから、焦りからか、少し雑になってしまいました。追加点を取られて万事休す。

でも、良い試合を観させて頂きました。メダルには届かなかったものの、強かったと思います。

情報処理学会誌今月号（2008年8月）のミニ特集は、「コンピュータ将棋は止まらない」。この5月に行われた「第18回世界コンピュータ将棋選手権」で1位、2位となった「激指」「棚瀬将棋」が、アマ名人のおふたりに勝利した、ということでこの特集となったようです。ちなみにこのおふたりは、プロに非常に近い技量の持ち主だそうです。つまり、コンピュータもそろそろトッププロを破るのではないか、ということですね。

その真偽はともかく、「激指」「棚瀬将棋」の開発者（鶴岡氏／棚瀬氏）による技術解説は興味深いものでした。現状のコンピュータ将棋では、形勢判断のための評価関数を、自動学習するものとそうでないものの2通りがあるらしいのですが、「激指」は後者、「棚瀬将棋」は前者です。この両者の対戦では、「激指」が勝ったのですが、これはかなりいわくつきのもので、本特集を読んだ限りでは、実際には「棚瀬将棋」が勝っていた、という論調ですね。

この評価関数というのが、様々な特徴量を評価して、最終的にはあるひとつの値（＝先手後手の有利度）を算出するのです。まるでパターン認識であるかの如く。評価関数を自動学習させる場合、プロの指した手順を正解と見なし、それにより評価関数のパラメタを更新していくわけですが（つまり教師あり学習）、こうなってくると、強いんだけれどコンピュータ自身は何をやっているのか分からない、ということですね。この現状を「激指」の開発者は、「職人芸の活きる場所が、1つ1つ減っていく」と嘆いておられるのですが、時代は正にそのような方向へ...

先日のNHK「プロフェッショナル」で、羽生氏と森内氏の死闘ドキュメンタリーを観た私にとっては、トッププロとコンピュータ将棋は確かに技量が亀甲して来るのでしょうが、基盤にある思考様式はどんどんと違ったものになってきそうですね。片や人間の限界まで理解を深めた生身の棋士、片や強いけれど何も分かっていないコンピュータ。これは正にペンローズの理論通り...

でも待てよ、トッププロは局面をパターン認識するかの如く、右脳で考えるという実証実験がありました。ということは、もしかしたら今のコンピュータ将棋における最新技術（＝評価関数の自動学習）は、トッププロの思考回路を模倣している可能性も無きにしも非ず、ですね。自分でも何を言っているのか分からなくなってきましたので、この辺でおしまいにしますが、上記技術解説は面白いですよ。

Doverとはアメリカの出版社で、1941年に設立されました。知る人ぞ知る、良質の本が「何でこんなに安いの？」と驚きます。私もこれまで何冊か買いましたが、千円〜二千円台です。つい最近買った、Hamming著"Numerical Methods for Scientists and Engineers(1986)"は、721ページもありますが、約2,500円でした。凄いコストパフォーマンスだと思いませんか？表紙も綺麗ですし、私の好きなペーパーバックで、サイズも小さいので持ち運び簡単。私のお気に入りです。

何故こんなに安いかと言うと、基本的には古い本で絶版になったものを復刻したものだからだそうですが、真実は良く分かりません。上記のHammingの本にしても、初版は1962年のものです。ですから既に半世紀弱経っています。こんな古い本が今の役に立つの？というのがよく聞く批判意見。

でも待って下さい。今の世の中には、一年も持たない本が洪水のように出版されていますよね。そのような本はすぐに絶版となって、再度復活することはありませんが（このような本でも国会図書館は所蔵する義務があるのでしょうか？）、その点、Doverの本にはそのような危惧は無いのです。つまり、「時間」という厳格なフィルタに通されたということ。

上記Hammingの本以外では、Kreyszigの"Differential Geometry(1991)"というのを持っていますが、1,400円しませんでしたよ（今はもう少し上がっているようですが）。この本も名著というか、書き方が古くさいというか...手放せませんね。

とにかくDoverは私のお薦めです。皆さまも、半年で消えるような新刊に1,500円払うのであれば（私も結構払っていますが）、もっともっとためになる本が、Doverにはたくさんあると思いますよ。ところで、日本に対応する出版社はあるのでしょうか。もしや岩波文庫？

TCP/IPについてくどくどと書いていると、より一般のI/Oを扱うシステムについて言及したくなりました。出力（O）については入力（I）に比べて易しいでので（基本的には単に出力すれば宜しい）、入力のみを考えます。

入力についてはTCP/IPに代表されるネットワーク系もあれば、UBSなどに接続されたデバイスもあります。入力と言っても種類はたくさんありますね。何れにせよ、先ず検討するのは、「どのようにして入力を待つか」ということ。当たり前ですが、block readが基本です。如何なる場合でもnon-block read（busy waitとも言う）は反則。例外なし。では、デバイスがblock readをサポートしていない場合はどうすれば良いのでしょう？これは宿題にしておきますね。

安全で考えやすいという観点から言えば、各入力について、専用のスレッド（又はプロセス）を設けるのが良いでしょうね。その後で、まとめられるものがあって、且つその方が良いのであれば適宜そうする。

要点としては、入力待ちの時はCPUがアイドリング状態にあることが必須で、しかも入力が来たら直ちに入力を受け付けられることが大切です。この条件を満たすために、block read、専用スレッド、などを使うわけですね。このとき、スレッドの優先順位も重要ですね。どのようにスレッドがスケジューリングされるかは、ちゃんとOSのマニュアルを読んで理解しておきましょう。

書いていくといろいろありますが、ひとつだけ設計の指針を挙げろと言われたら、「ひとつまたは全ての入力デバイスが壊れていても、システムが何とか動作すること」ですね。これは全くの私見であって、反論はあるかも知れませんが、私の経験からすれば、このように作っておくと大変便利なのです。何故って、入力デバイスというものは、最初から全てが完全に動作することは稀ですし、大体、全てが揃わないことだってあります。ですから、様々な状況に対応できるように、できる限りロバスト（＝頑強）にソフトウェアを作っておくのです。ハードの問題で泣きを見るのは、常にソフト側ですからね。ヤワではいけません。

この意味は、あるデバイスが壊れていた時に「エラーを出して終了！」ということとは正対で、あたかもそのデバイスが正常に動作しているかのように見せる、ということです。エラーを出して終了させたところで、偉くも何ともないのです。例えば定期的にある情報を返すようなデバイスがあったとして、そのデバイスが壊れていたとします。例えば常に同じ情報が返ってしまうような場合ですが、そのようなときでも、どのようなエラーかを検知できることは当然ですが、あたかも同じ情報が「正常に」返ってくるかのように振る舞えると、何かと便利なのです。

Comer＆Stevens著、"Internetworking with TCP/IP volume III(1993)"に、TCP/IPを用いたサーバ形態には、以下の3つがあると書かれてあります。pp.123〜145です。

1) Iterative, Connection-Oriented Servers (TCP)
2) Concurrent, Connection-Oriented Servers (TCP)
3) Single-Process, Concurrent Servers (TCP)

面白いので、これについてちょっと調べてみましょう。アナロジ好きの私は、これをレストランに例えます。レストランでは、注文を取る人がいて、コックさんがいます。この関係で1)2)3)が説明できるのです。

1)というのは、お客さんが来たら注文を取りに来ますが、注文を取る人が料理もする、というもの。これのメリット／デメリットは明白です。余りお客さんが来ないレストランで、しかも料理にそれほど時間がかからないのであれば、何とかやっていけるかも知れません。でも、それからちょっとでも外れると、なかなか運営が難しいですね。評判悪くなりそう...まあ、極めてシンプルな形態が1)です。初心者向け。

さて、2)ですが、お客さんが来たら注文を取るところまでは同じですが、その注文に対し、専用のコックさんをアサインするというものです。ですから、どんどんお客さんが来ても、どんどん注文を受け付けることができて、コックさんがいる限りはうまく機能します。あ〜でもここでこのアナロジはちょっとムリがあることが分かりました。コックさんはそんなに都合よくいませんが、コンピュータでは、プロセスやスレッドで簡単にコックさんを生成できちゃいますからね。

ところで3)というのは何でしょう。3)はひとりの「スーパーマン」がいるというものです。この人は、どんどんお客さんが来ても、その瞬間に注文が取れて、しかも同時に料理も並行にこなしていくという、素晴らしい能力を発揮する人です。でも、勿論ひとりの人ですから、真の意味での並列処理はしていません。中華料理屋さんで、ラーメンとチャーハンを同時に作っていても、その過程では細かくタイムスライスでやっているはずですからね。1)との違いですが、1)も3)もひとりで全てをこなすのは同じですが、1)はお客さんが来たら、その人に料理を出すまでは、他のお客さん対応は一切しないのです（注文取りも含めて）。

いろいろと細かいところでムリはあるにせよ、レストランのアナロジは結構使えますよ。

（私のネットワークの知識）＝（TCP/IPの知識）＝（W. Richard Stevensの書籍）、ですが、少しだけ別の著者のものも読みました。それは、ComerとStevens（Richardではない）による、"Internetworking with TCP/IP volume III(1993)"というものです。実は、どのような理由で本書を必要としたのか忘れたのですが、とにかく読みました。私はかなり乱読気味なのです。

いろいろと書いてあるのですが、私のお気に入りの章は以下の3つ。

Chapter 10 Iterative, Connection-Oriented Servers (TCP)
Chapter 11 Concurrent, Connection-Oriented Servers (TCP)
Chapter 12 Single-Process, Concurrent Servers (TCP)

つまり！TCP/IPでサーバを実装する方式は、大きく3通りあるということです。これを読んだ時には私はワクワクしてしまって、全ての実装を試して、いろいろと比較したような気がします。本書はW. Richard Stevensの一連の書物のように有名でもなく、洗練されてもいませんが、少なくとも私の（ごくごく制限された）ネットワークの知識には、貴重なトッピングを与えてくれたと思います。

私は非ネットワーク技術者としては、TCP/IP（Transmission Control Protocol/Internet Protocol）は勉強した方だと思います。

私がこれまで最も従事してきたシステムは、リアルタイムCG系（＝VR系とも言う）ですが、ここではネットワークはほぼ必須です。分散処理で、コンピュータを複数台使うことは普通ですからね（先日の上海の仕事では13台使いました）。専門がCG系なので、ネットワークはササッとうまくやらないといけないのです。ここで悩んでいては、本職のCG/VR系で悩めませんからね。でも、ネットワーク構成が稚拙では全体のスループットに多大な影響を及ぼすので、非専門とは言え重要なのです。

20年前は真のシロウトだった私が先ず勉強したのは、当時の定番教科書、W. Richard Stevens著"Unix Network Programming(1990)"でした。これはほぼ完読。本書は誠に素晴らしい本で、これまで私が読んだコンピュータ関連書籍（CG関連も含む）の中でも、疑いなくベストの一冊です。何度も読んだからボロボロになりました。仕事では重宝しましたよ。書いてあるとおりにやると、それこそ完璧に動作しましたから。今は当社の書棚で安らかに眠っています。

その後はStevensに入れ込んでしまって、"Advanced Programming in the UNIX environments(1992)"、"TCP/IP Illustrated, volume I(1994)"、"UNIX Network Programming, volume I(1998)"、"UNIX Network Programming, volume II(1999)"と読みました。でも、Stevensは1999年に亡くなりました！業界、いや人類にとって本当に大きな損失...

Kerninghan & Ritchieを読まずして「C言語を知っている」というのは説得力が無いですが、W. Richard Stevensを読まずして「ネットワークを知っている」というのもほぼ同じでしょうね。

やっぱりSIGGRAPH Asiaは行かなければ！2009年は横浜でしょう？というわけで、少しづつ調べています。私はシンガポールには行ったことはないので（Changi空港はあります）、土地勘が全くなし。先ずは会議場（Suntec convention centre）の場所を調べました。ここに近いホテルがいいな。

SIGGRAPH Asiaのウェブサイトでホテルの予約ができるのですが、かなり高いホテルで、ちょっと泊まれそうにありません。というわけで個別に当たることにしました。やはり会議場の近くはバカ高いです。ホテルの外観も、これは...という感じの高級感です。5つ星が並んでいるのです。

少し調べた結果、Orchard駅周辺が落とし所かな、何て思っています。でも、全然分からんです！SIGGRAPH Asiaに行かれる方で、シンガポールにお詳しい方、是非情報を頂けるとありがたいです！

性格を分類するMBTI（Myers-Briggs Type Indicator）によると、私はINTP（Introversion、iNtuition、Thinking、Perceiving）なのですが、これを調べたのはもう25年も前です。こんなに年月が経つと、こういうのも変わってくるかも知れませんね。

先日本屋さんをふらふらしていたら、「あなたの天職がわかる16の性格（2008）」という本を見つけました。16の性格と言えばMBTIですね。どれどれと立ち読み。

今見ても、I（Introversion）とN（iNtuition）に変わりはありません。でも、T（Thinking）とP（Perceiving）はちょっと分からないゾ。25年前も、Tはそれほど有意ではなく、逆のF（Feeling）に振れる可能性もありました。だからこれはどちらでも良い。問題は最後のPです。上記の本を見ると、どうも私は逆のJ（Judging）に変わったような...これは多分、25年前当時からの仕事の変遷によるものだと思います。幸か不幸か、私はかなり早くから物事を決めなければならない立場に追い込まれたのでした。その結果として、25年前のPが今はJになった模様。要するに歳を取ったということです。若い頃はいい加減で良かった...

というわけで、私は今はINTJ又はINFJなのでしょう。でも、どちらか決めたい！（もしやこれってJudging？）上記本には、INTJは「アイデアマン」、INFJは「理想家」と書かれてあります。そして、それぞれの能書きを読んで判明しました。私は間違いなく後者です。結論としては、今の私はINFJなのでした。

ロシア人数学者（だった）GNと、彼の今のプロジェクトについて良く話します。彼は話をしながら自分の考えをまとめていく、というタイプです。ですから私は時間がある限り付き合います。英語の訓練にもなりますし...でも彼の英語はアメリカ仕込み（アメリカ滞在8年）なので、聞きとれないところも多々あります。でも私はいい加減なので、そういうのは気にしない。推測でカバー。

彼の悩みの幾つかは、勿論最終的には解決しなければなりませんが、些細と思われるところもあり、大勢に影響ないので後回しでもいいじゃないかな〜何て思うこともありますが、数学者ですから厳密性を重んじるのかも知れません。確かにプログラミングは数学と密接な関係があるとは言え、思考のプロセスは少し違うのかも知れませんね。私は数学者ではないので、彼の思考は良く分かりません。

さて、彼は今既存のプログラムを改訂する作業をしています。ハードウェアがいくつも繋がるプログラムなのですが、そのひとつにD/Aボードに出力する部分があります。既存のものはひとつのポートへの出力ですが、今回の改訂ではそれを2つにします。何てことはありません。

ところで、既存の出力関数は、出力ポートが決め打ちなのです。関数内部でポートを指定している。これは設計としては多分よろしくなく、そのときはポートがひとつだけだとしても、将来の拡張を考えて、敢えてポートを引数として指定させる仕様の方が良いかも知れません。少なくとも私だったらそうしました。

それはさておき、ここで私はrefactoringについてGNにレクチャしました。どういうことかと言うと、既存の機能を保ったまま、この関数をポート指定できるように変えてやれば良いのです。ここでちゃんとテストすれば、後はこの関数を使って、ポートを指定できますからね。勿論口頭では英語の説明で不十分ですから、Martin Fowlerの適当な書物を読んで貰いました。

先日、協業路線を歩もうと意気投合した某社の方々と飲みに行ったのですが、某社社長Tさんが「ロシアが好き！」とのことで（理由は不明）、当社ロシア人技術者IGとGNを誘いました。彼らは何の疑問もなく来てくれる。社交的なのでした。私が有無を言わさず誘ったからかも知れないけれど。

飲み会をしていて、ロシアについての新しい発見がありました。例えば、あんなに広大な国土を持つくせに、中国やインドに見られる言葉の違いが殆どないとのこと。日本における標準語と関西弁の違い程度はあるらしいですが。

日本で働く外国人と話をすると、必ず出てくるのが年金の話題。これは難しい問題なのです。ところで、日本では、私が学生の頃は確か国民年金は加入義務がなかったような気がしますが、今では学生さんは義務化されていますね。この事情はロシアでは逆で、以前は学生さんはお金を払っていたらしいのですが、今は免除されているとのことでした。

徴兵制はあるらしいです。日本はありませんね。世界の国々を見ると、日本は珍しい方だと思います。

3日間の休みからBLOG復帰致しました。皆さまは如何お過ごしだったでしょうか。でもお休みのピークは今日（2008年8月13日）からのようですね。

ここのところ猛暑が続いています。こんな時は冷たいビールがおいしいですね。私も飲むのは好きな方で、この季節の楽しみのひとつ。

とは言え、私は一年半ほど前から自宅ではアルコールは一切飲んでいません。私が飲むのが嫌いではないことを知っている人は、この話をすると驚いて理由を訊いてくるのですが、特別な理由はありません。ただ自分で決めただけです。

以前は帰宅後必ず缶ビールひとつを飲んでいました。自宅で仕事をしている時も、飲んでいる方が良い提案書が書けそうな気がして...。それが、いつの間にかその前に缶チューハイが付くようになってしまって、更に週末は昼前に手を出すようになってしまった。もしやこれって、アル中の一歩手前？

休肝日を取った方が良いと言われたこともあって、それから「自宅では飲まない！」と決めました。1、2か月は少し辛くて、かなり我慢したのですが、その「禁断症状」が過ぎると、自宅に入るととたんに飲みたいと思わなくなりました。我慢をしているわけでは全くありません。でも、外では以前と同じように飲むのです。このような感じで現在に至っています。今は平均して週3、4日はアルコール無しですね。休肝日としては十分でしょうね。

これは自分でも不思議なんです。私は外での運動が好きで、この季節、暑い中ヘトヘトになって帰ってくることがあるのですが、そのような場合でも冷たいビールを飲みたいと思うことは、自宅では皆無です。でも外では事情が違って、サッカーの打ち上げなどでは大層おいしく飲めるのです。何故？自分でも分かりません。そのようにニューロンが再構成されたのでしょうか。

来週はお休みのところが多いと思います。当社の夏休みはある期間内に勝手に取るというものですが、やはり来週休む人が多いと思います。

私は例年通り特に浮いた話はありませんが、明日（2008年8月10日）から数日（期間未定）このBLOGをお休みします。皆様も楽しい夏休みをお過ごしください。

昨日（2008年8月7日）は歓送迎会でした。「歓迎」の方は、昨月入社したHSくんとGNです。「送別」の方は、今月退社し母国に帰るフランス人RB。

HSくんとGNは既に入社一か月経っていますので、既になじんでいます。RBはフランスでの職が決まったようですね。訊いてみると3D系だそうです。また一緒に仕事ができればよいと思います。

今年の日本VR学会大会は、奈良先端科学技術大学院大学で開催されます。会期は2008年9月24〜26日の三日間。私は今回は前半の2日間アテンド予定です。3日目は所用により横浜に戻らなければなりません。

事前登録するとき、「イブニングセッション」も申し込みました。「イブニングセッション」とは多分懇親会のことですね。通常懇親会は中日ですから、参加は可能です。というわけで、申し込み時は特に疑問なし。

その後、念のため確認すると、「イブニングセッション」は何と最終日で、しかもUSJであるんですと！残念ながらこれは行けません。というわけで、止む無くキャンセル致しました。