Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.Dominic(2008-06-23 05:05)
2.CheapestCheapOEMoem(2008-06-17 03:00)
3.NewDownloadCreativAdobOEM(2008-06-12 20:00)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
8月26日から読んでいた"The Elements of Style"(William Strunk Jr. and E. B. White)を読了。初版は1959年発行、以後約半世紀にわたり3度の改訂を経て、今なお英語の文章を書くときのバイブルと呼ばれ続ける名著である。全部で100ページちょっとの小さな本だが、Wataru's memoの2003年9月23日の文章「優れた英文だけを読むべし」にある言葉
優れた英文技術書の条件とは、情報が正確に誤りなく書かれていることはもちろんだが、英文として読みやすいものかどうか、「Comfortable English」であるかどうかが、最も重要な因子となる。日本語に訳すと「気持ちの良い英文」という意味になるが、この表現の背景には「学歴のあるアメリカ人は論点を簡潔かつ明快に表現することをcomfortable と感じる」という事実がある。
（Wataru's memo「優れた英文だけを読むべし」）
にある「Comfortable English」を実践するためのエッセンスが凝縮されていると言って良い。
力強い文章は簡潔である。図面に無駄な線が無く、また機械に不要な部品がないように、センテンスには不要な単語が入ってはならず、またパラグラフに不要なセンテンスが含まれていてはならない。だがそれは全てのセンテンスを短くし、詳細を省いて概略のみを述べよ、ということではない。書き手は文章中の全ての単語がきちんと「語る」ような文章を書かねばならない、ということである。
("The Elements of Style"23ページ、やさぐれ訳)
10年ほど前に読もうとしたときには10ページくらいで挫折してしまった（というかそもそも英語で文章を書く段階に達していなかった）が、今回は無事通して読むことが出来た。だが全部の内容を消化できたわけではなく、繰り返し読む必要がある、またそうする価値のある本である。
今さらながら白状すると、「セマンティクス」という言葉がずいぶん長い間理解できなかった。いや、「セマンティクス」を日本語にすると「意味」という言葉になるのは知ってたんだけど、それが何を意味しているのかはどうしても分からなかったのだ（ややこしいな）。
■ セマンティクスとシンタックス、そしてプログラミング
ある日のこと、「セマンティクス」は「シンタックス」と対にしてやると理解できることに気がついた。「シンタックス」は日本語では「文法」となるが、これが「セマンティクス」と反対の、あるいは補完しあう関係であるということに気がついたときに、僕の疑問は解けたような気がした。どういうことかと言うと…
例えばJavaでプログラミングをするとき、Javaコンパイラは「シンタックス」の間違いについてエラーを出してくれる。これは大抵コンパイラが出すエラーメッセージに従ってプログラムを直せばよろしい。さて、そのようにしてコンパイルエラーをやっつけ、いざ実行、となったときにプログラムが思ったとおりに動いてくれない。これは「セマンティクス」の誤りによって起きる現象だ。デバッグというのは「シンタックス」の間違いを取り除いた後になお、プログラムの中に潜む「セマンティクス」の誤りを解決する作業、と言える。僕らプログラマはセマンティクスの世界であーでもない、こーでもないと、日夜ジタバタしている、という次第。
とは言ったものの実は「セマンティクス」と「シンタックス」の境目はベルリンの壁（古いな）みたいにかっちりと決まっているわけではない。実は計算機で自動処理できるようなルールを決め、これを形式的な記法で記述することによって、「セマンティクス」の世界にあるものを「シンタックス」の世界に引っ張り込むことは（それなりに）可能なのだ。クラスやメソッド、関数などの型を宣言し、コンパイル時にそれをチェックするような言語では、ある程度までのセマンティクスの誤りはコンパイラが教えてくれる。プログラムを実行して初めて分かるようなたぐいの問題についても、事前/事後条件の記述(いわゆる「契約によるプログラミング」）、ZやVDMのような形式仕様記述言語による表現、果てはテスト駆動開発に見られるテストプログラムとアサーション、を使うことによって解決しよう、という試みは現在も盛んに続けられている。
■ 計算機と自動処理
ここでミソとなるのは、「計算機が自動処理できるような書式を使う」という点だ。プログラミング言語ではニンゲンがきちんと文法を決めることによって、そのような自動処理ができるようなお膳立てをしているし、HTMLでは「ここはタイトル」とか、「ここには画像が入る」とかいう処理を計算機ができるように、<H1>や<IMG>などのタグをテキストに埋め込んでいたりする。
さて、自動処理という言葉をここまで何気なく使っていたが、それって一体何だろうか、ということについて、少し考えてみたい。コンパイラやWebのアプリケーションなどを念頭に置きながらざっとまとめてみると、
といったあたりだろうか。これらはいずれも、文書の中に存在する特定のパターンを発見し、発見されたパターンに対してあらかじめ決められたルールを適用するという作業だ。これを一般化していくと、
という話になる。さらに誤解を恐れずに極論を言ってしまうと
ということになる。このような機械に本当に「意味」を扱わせることは出来るのだろうか？
■ Webの理想郷
ここで話をWebの世界に移すことにしよう。「セマンティックWeb」という言葉が出て久しいが、これをものすご〜く大雑把に捉えると、従来ニンゲンが単に読むものであったWeb上のテキストデータを、沢山のタグと沢山の（メタ）データで補強してやることによって、「パターンマッチング」と「ルールの適用」を自動的に出来るようにしよう、そうするといろいろと便利になるはずだ、世界をタグで埋め尽くして、それを足がかりにいろんなものを自動処理させてみたい、というお話であるように見える。
最大の問題の一つはWeb上の情報は人間が利用するように設計されているものがほとんどであり、それが仮に（ある程度）きちんと意味が定義されたカラムを持つようなデータベースから取り出された情報であったとしても、webを巡回しているロボットにはその構造が掴めない、という点である。人間の振舞いを再現するようにいかに機械を訓練するかというような、人工知能の問題はひとまず置き、セマンティックWebでは機械が処理できる形式で情報を表現するための言語を作るというアプローチでこの問題に対処することとする。
("Semantic Web Road map", やさぐれ訳)
さて、問題は「セマンティクス」つまり情報の意味を、どこまで自動処理可能な姿に変換、すなわち形式化できるか、いうお話になる。全てが形式化出来れば万々歳であるが、現実問題としてそのようなことはどうやら無理そうである。最終的にはどのあたりに落ち着くのだろうか？
Webの世界における計算機による処理の自動化の先達と言えば、Webサービスがまず最初に頭に浮かぶ。WebサービスはSOAP,WSDL,UDDIのという三つの要素を組み合わせることによって、その理想を実現しようとしている：
Webサービスの実現しようとする理想郷では、全てのソフトウェアアプリケーションが自己発見、および自己分類のためのメソッドを持っている。あるソフトウェアにおいて、必要とされる機能がもし無かった場合には、そのソフトウェアはUDDIを基盤としたサービスのレジストリ（注：電話帳みたいなもの）を検索し、そこで発見したWebサービスに自動的に接続することによって仕事を遂行する。
("Understanding Web service interoperability", やさぐれ訳)
だがこんな意見もある：
もしWSDLとUDDIが「あいまいさ」を持たない、きっちりと定義されたサービスにしか使えない、ということになれば、その適用範囲は人間の確認が必要ないような分野、例えば送料の計算、郵便番号の検索、トナーの再注文などといった、ビジネスのごく一部に限られることであろう。革命的というにはほど遠い。
("Web Services: It's So Crazy, It Just Might Not Work", やさぐれ訳)
僕の見る限り、現実はどうも後者に近いようだ。SOAPとWSDLはともかく、UDDIに関してはNTTコミュニケーションの"UDDI Registory"の検索結果などを眺めても、理想郷の姿はなかなか見えない。
セマンティックWebではRSSというキラーアプリケーション（？）が既に存在している分、状況は明るいように見えるが、Tim Berners-Leeが目指す世界は、そのはるか先にあるように見える：
ルーシーは携帯型Webブラウザを使って彼女のセマンティックWebエージェントに指示を出した。エージェントは直ちに、彼女の母のかかりつけ医のエージェントから処方薬の情報を参照し、母の保険が適用可能、かつ彼女の家から20マイル圏内にある、「最高」から「非常に良い」との評価を受けている病院を探し出した。
("The Semantic Web" Scientific American, May 2001, やさぐれ訳)
このような理想郷が実現する日は来るのだろうか？
■ 自然言語と機械翻訳
さて、タグの付かない、普通の文章の自動処理についてはどうだろうか。計算機に普通の文章を取り扱わせようというのは古くから研究されているトピックであるが、これについて非常にうまくまとめられた文書「形態素解析・構文解析入門」を見るとこのような記述がある：
現在、「言語学」という分野は、次の 5つの階層に分けられた諸分野全体のことをいう。最初のほうに出てくる分野はすでによく研究されており、下に行くほど問題のレベルが高くなっていき、まだ謎が解けていない部分が多くなってくる:
1. 音韻論 phonology
2. 形態論 morphology
3. 構文論 (統語論) syntax
4. 意味論 semantics
5. 語用論 pragmatics
(「形態素解析・構文解析入門」）
これを見ると「シンタックス」と「セマンティックス」が隣り合った階層にあることが確認できる。この文章を書き始めたときの直観はそれほど外れていなかったようだ。また、「セマンティクス」のその先にはコメント欄で嶋くんが言及してくれた"pragmatics"というものが控えていることも上のリストから見て取れる。
ここで話は少し横道にそれる。上のリストにある「形態論」を扱う処理としては、形態素解析というモノがあって、日本語を扱う研究では必ず最初の一歩として登場する作業だ。だが上の文を見ると、形態素解析はまだシンタックスの手前、当然セマンティクスを取り扱う段階のはるか手前ということになる。例年の研究室の卒論の中間発表などを見ると、形態素解析まで出来れば研究もマラソンで言うところの折り返し点まで進んだ…と言いたくなるようなのだが、実際のところはスタート地点から競技場を一周して、やっと道路に出た状態、と言うのが適切なようだ。残る道のりは40キロ以上、先は長い。
本論に戻ろう。「パターンマッチング」と「ルールの適用」しか出来ない計算機が、自然言語の「セマンティクス」、すなわち「意味」を扱うのはきわめて困難である、と僕は考えているが、その困難さを最もはっきり示してくれるのが機械翻訳ではないかと思う。一例として先にも引用した"Understanding Web service interoperability"の一文を"Excite エキサイト翻訳"で、日本語へ機械翻訳させてみると以下のようになる：
また、WSDLとUDDIが明白に記述することができるサービスに対して単に働く場合、それらは、人間の承認を要求しないビジネス問題のその小さな部分集合に制限されているでしょう--利己的な運送費用、ジップ・コードを調べること、再び整理するトナー。ほとんどない革命の材料。
かなり良い線を言っているとも言いたくなるが、まだ満足できるレベルと言うにはほど遠い。辞書からの語の選び方が適切でないだけだ、もっと沢山の辞書データ（パターンマッチング対象）ともっと良いアルゴリズム（変換ルール）があれば良い品質の翻訳は作れるはずだ、という意見もあるかもしれない。だが物量は質の代わりになるのだろうか？
ちなみに前述の嶋くんは現在カーネギーメロン大学のLanguage Technologies Institute (LTI)にいる。彼のblogからすこし引用してみよう。
LTIには多言語間横断のプロジェクトがたくさんあり、世界中の本を100万冊スキャンして巨大なオンラインデータベースを作るプロジェクトなんてものもあります。その名もThe Million Book Projectで、中国とインドにいるスキャン要員1000人が、毎日世界中の本をスキャンしているとか。それが実現すると、言語知識のインフラができ、質のいい機械翻訳や質問応答システムなんかに応用できます。
(Shima's 2004/08/30 「アメリカ初授業」)
LTIの機械翻訳に関する発表論文リストのごく一部だけを見ても、その量と歴史にはひたすら圧倒される。僕のような素人が口をはさむ余地などどこにもないな…と言ってしまいたくなるが、それでもなお、納得の行くレベルの文章を生成するシステムをその目で見ない限り僕は納得することは出来ないのだろう。当分は無理なのではないかな、と予想しつつ、その一方でそのようなシステムを前に、嶋くんが僕をヘコましてくれる日が近い将来に来るといいな、と僕は密かに思うのであった。
（おわり）
# あまぴょん [UMLの仕様書なんかは、SemanticsとNotationですね。さすがにSyntaxではないようです。 ]
# しま [プログラミング言語ではわかりませんが、自然言語ではsyntacsとsemanticsはきっちりと分けられるみたいです..]
# 福盛 [あまぴょんさん: そういえばUMLの仕様書で"Semantics"という言葉を目の前にしてう〜むわからんとひたすらう..]
# 福盛 [しまくん: pragmaticsの話は実は知りませんでした(ありがたい)。 改めてsyntax,semantics,..]
# たけちゃん [「あー、semanticsっていうのは、対象modelに依存するのよ」と書いてみるテスト。 ]
# 福盛 [「あー、そろそろ自らの無知をさらす領域に近づいてきたかも。『形式意味論 + モデル』あたりで検索した結果あたりから攻..]
# たけちゃん [「『形式意味論 + モデル』ではマトモなものは引っかからにゃい」と書いてみるニャー ]
# 福盛 [ウキーッ ちょっと近所を走ってきます(ぉぃ ]
"mciML"は先週に引き続き第9章の本文を読みつづける。Dynamic Programmingとかcode generator-generatorsとかFast Matchingとかいう新しいキーワードがドカドカ現れるがついて行けず。なんとか読み進めたものの頭には入っていなさそうな気配。現在は200ページあたり。
9月2日から読んでいた"Becoming a Technical Leader"(Gerald M. Weinberg)を読み終える（2回目）。4年ほど前に読んだときからすっかり忘れた部分もあれば、はっきりと記憶に残っている部分、そして憶えていないはずなのに無意識のうちに頭に焼きついていた（らしい）部分もある。
自身の姿を他人の視点で見ることは、麻薬中毒者には決して出来ないことであり、これが出来ない限り、良いリーダーとなることはできない。リーダーシップに対し幻想を抱くことも破滅的かもしれないが、自らの虚像に酔うのは最悪の中毒である。私はこの本を通じて、あなたがリーダシップに関して持つ幻想のいくらかを打ち破ることができるかもしれない。しかし自らの虚像を打ち破ることができるのはあなた自身しかいない。
("Becoming a Technical Leader" 273ページ, やさぐれ訳)
自分がひたすら有能であるとか、あるいは逆に自分はひたすら無能であるとか、そんな幻想を捨てて、ありのままにふるまうことが出来ればいいのに、と思い始めたのはいつからであったろうか。こんなところで自らの行動基準を再発見する、というのはなんとも不思議な気分である。
"mciML"は先週に引き続き第9章の本文読み。アセンブリコードの出力に関するお話がずっと続いているが、レジスタ割り当ては最後の最後（11章）までやらないらしい。そろそろx86アーキテクチャの命令セットの再確認もしておいた方がいいかな（結局ごく一部の命令だけで済ませてしまうのだろうが）。現在は208ページあたり。
バックエンドにはGCCを使う予定なので、アセンブリコードの記法はIntel形式ではなくAT&T形式になる。ということで"AT&T Syntax versus Intel Syntax"もチェック。「GCCでインラインアセンブリを使用する方法と留意点等 for x86」にも結構親切な説明がある。
今週の"mciML"は多忙につき一休み。新幹線で菅平に行ったり温泉に入ったりと大忙し（ぉぃ
9月12日から読んでいた"Where Wizards Stay Up Late: The Origins of the Internet"(Katie Hafner and Matthew Lyon)を読了。りょうせいさんの本棚経由で見つけた本である。現在のInternetの母体となったARPANETの、1969年の誕生から1989年の終焉に至るまでの20年にわたる物語がつづられているのだが、世界最初のルータ（と言っていいかな）であるIMP(Interface Message Processor)の開発の様子とか（ワイヤーラッパーとオシロスコープを手にハードウェアのデバッグをする人々の姿は迫力満点）、RFC(Request For Comment)という名前の由来とか、電子メールのヘッダのフォーマットをめぐって繰り広げられた大論争とか、TCP/IPの誕生の経緯とか、目からウロコな話が満載。なんと、村岡研のメンバーならば御馴染み（だよね？）のILLIAC IVまで登場する。
特にうれしかったのは、この本のおかげでRFC1、つまり世界最初のRFCをちゃんと読めるようになったこと。昨年初めてRFC1を見たときには何の話が書かれているのかさっぱり分からなかったのだが、この本を読んだ後改めて眺めてみると、文中に登場する人物や機械の名前を見ただけで「ああなるほど、そういうことだったのね」と、すんなりと頭に入るようになった。他の古いRFCについても同じようにスラスラと読める。こりゃ楽しい。まさに「大当たり」と呼ぶにふさわしい一冊。
9月22日から読んでいた"The Farthest Shore"(Ursula K. Le Guin)を読了。いわゆる「ゲド戦記」の第三巻に当たる本。今まで読んできた3巻のいずれも、登場人物の苦しむ姿に感情移入してしまうせいか、正直読むのがシンドイのだが、それでもやめられず、気がつくと一気に読み終えているというパターンであった。残るは"Tehanu"、"Tales from Earthsea"と"The Other Wind"。あと3回これを繰り返すのか…
"mciML"はアセンブリコード出力部の実装にやっと着手。本の中に断片的に登場するコード例を足がかりに、じりじりと書き進めていく。しかしコードが完成した時の規模が、まだ予想できないあたりが何かイヤなカンジ。ついでに"IA-32 Intel Architecture Software Developer's Manual"の巨大さにげんなり。今回の実装で必要となるのはせいぜいその中の2%くらいなので、ほとんどの部分は読み飛ばしてしまえば良いのであるが、ページをめくる、というかジャンプするだけでも一苦労なのであった。
# しま [The Elements of Styleは読まなきゃ読まなきゃと思っててずっと忘れてました！早速アマゾンで注文しま..]
# 福盛 [ぉ、ぜひ読みましょう。ついでなのでもう一つ紹介を… "The Elements of Style"は英文を書くときの..]