2006-04-03
Jeff Orkin. 3 States & a Plan: The AI of F.E.A.R. Proceedings of the Game Developers Conference 2006. (slide)
通常，アクション系ゲームの NPC 制御には有限状態マシン (FSM; Finite State Machine) が用いられる。これに対し Jeff Orkin 氏は，プランニング・システム（自動計画システム） [Wikipedia] の有効性を指摘する。その内容は，氏が AI システムの設計を担当した "F.E.A.R." [whatisfear] の実例に基づいており，非常に分かりやすい。ちなみに，題名にある "3 States & a Plan" とは，有限状態マシン (FSM) の状態がたったの３つしかない ― あとは全てプランニングによって制御されている，という「驚きの事実」を表している。
プランニング・システムは，ロボット制御などの分野において古くから問題解決の手段として用いられているシステムであるとされる。 Orkin 氏が解説に用いている STRIPS [Wikipedia] というシステムを例にとってみても，考案されたのが 1971 年であるというのだから，かなり長い歴史を持つ分野であることが分かる。
プランニング・システムの基本的な仕組みは，ルール・ベース・システム（プロダクション・システム） [Sour] [Gamasutra] に近いものがある。「システムに対してルールとゴールを提示することにより，自動的に問題解決のパスを求める」というコンセプトにおいては，ほぼ同じものであるとも言える。実の所，浅学のためか，自分にはその違いを明確に指摘することが出来ない。
自分はこれまで，アクション系ゲームの NPC 制御にルール・ベースのシステムを用いるという解決法は，あまり実用的でないと考えていた。その理由としては，処理負荷の増加が予想されること，設計の複雑化が予想されること，等々が挙げられる。結局は，よく設計された FSM と，綿密に仕込まれたスクリプティングの組み合わせこそが，最もコスト対効果の高い結果を導き出すのではないだろうかと考えていた。
しかし Orkin 氏はこのプレゼンテーションにおいて，ルール・ベースのシステムが非常に高い柔軟性をもたらすことを説明している。説明には実際のゲームの映像などもふんだんに用いられており，説得力に富んでいる。たしかに，このレベルの複雑性と柔軟性の両立は，単純な FSM の積み重ねでは到達することの難しい領域なのではないかと思われる。
2006-04-04
Roberto Ierusalimschy, Luiz Henrique de Figueiredo, Walkdemar Celes. The Implementation of Lua 5.0. Journal of Universal Computer Science, 11(7), pages 1159-1176. 2005.
この論文では，スクリプト言語 Lua [lua1] の開発者自身が，その設計思想や実装手法について解説するとともに，その実装がバージョン 5.0 においてどのように変化したのかという点について述べている。その内容は， Lua 自体の設計の簡素さも相まって，非常に見通しが良く読みやすいものとなっている。
Lua はもともと組み込み向けの汎用的なスクリプト言語として開発された処理系だが，現在ではゲーム産業において多く用いられている [lua2] 。この状況については Lua の開発チームも強く認識しており，最近ではゲーム産業側から寄せられた要望に対して積極的に応じるという展開が生じている。例えば， Lua 5.0 において追加されたコルーチン (coroutine) や， Lua 5.1 において追加されたインクリメンタル・ガベージ・コレクションなどのフィーチャーは，ゲーム産業における需要を意識したものであることが述べられている。
Lua の設計思想の根底を構成するものは，何と言っても簡素かつ高速であること，そして高い移植性と，組み込みの手軽さを保つことにある。これらの思想が根底にあるがゆえに，余計な機能を次々と盛り込んでいく方へと進化するのではなく，純粋に組み込み向けの言語としての魅力を増していく方へと進化を遂げることができたのだと考えられる。例えば， Lua 3.0 まではパーサーの実装にコードジェネレータ (yacc) が用いられていたのが，後のバージョンにおいては手書きの高速・軽量なパーサーへと置き換えられている。これは，コードジェネレータを用いることによって得られる柔軟性（言語仕様の柔軟性）よりも，組み込み言語としての使いやすさを重視した結果であることがうかがわれる。
上記論文において Lua の実装手法について触れられている部分は，使用の際に役立つ情報も多く参考になる。例えば Lua 5.0 においては，テーブル構造（ハッシュテーブル）を配列として利用する場合に，特殊な最適化処理が適用されるようになっている。具体的には，テーブルのキーとして一定値以下の整数値が用いられた場合に，これを配列としての利用とみなし，本当に配列に格納を始めるというものだが，このような特殊な処理を施してまでも，「配列という言語仕様は追加しない」という姿勢を貫いている点は興味深い。
最後に， Lua 5.0 における内部的な変更点として，仮想マシン (VM) の基本設計の変更が挙げられる。 Lua 4.0 までは Java や CIL (.NET) のようなスタックベースの仮想マシンが採用されていたのに対して， Lua 5.0 からはレジスタベースの仮想マシンが採用されている。自分はこのような仮想マシンに関する知識が不足しているため，その有効性についてよく理解することができないが，レジスタベースの仮想マシンは Parrot VM [parrotcode] [Wikipedia] を始めとして昨今注目を浴びつつあり，バイトコードの効率化に寄与があるとされている。たしかに，提示された例を見る限りでは，スタック操作が多くの割合を占めるスタックベースのバイトコードよりも，直接にオペラントを指定することのできるレジスタベースのバイトコードの方が，処理の記述の効率に優れていることが分かる。
2006-04-05
Roberto Ierusalimschy, Luiz Henrique de Figueiredo, Waldemar Celes. The Evolution of Lua.
スクリプト言語 Lua の開発は，ブラジルの大学 PUC-Rio (Pontifícia Universidade Católica of Rio de Janeiro) において， Roberto Ierusalimschy 氏（助教授）， Luiz Henrique de Figueiredo 氏（助教授）， Waldemar Celes 氏（開発当時は博士課程生，現在はコンサルタントとして参加）の三氏が中心となって行われている。 PUC-Rio は，ブラジルはリオ・デ・ジャネイロに位置するカソリック系の大学であり，法学や工学の分野において高い教育水準を持つことで広く知られている [Wikipedia] 。
ブラジルでは 1977 年から 1992 年までの間，工業製品の輸入代替（国産化）政策の一環として，コンピュータ・ハードウェアおよびソフトウェアの市場に規制がかけられていた。その影響もあって，ハードウェアおよびソフトウェアを自らの手で作り出すべきとの見方が一般的のものとなっていたとされる。 PUC-Rio のコンピュータ・グラフィクス技術グループ (Tecgraf) は，そのような背景の中で産学連携の一翼を担い，基本ソフトウェアの開発や，対話的な画像プログラムの提供などを行ってきた。
Lua の前身となったデータ記述言語 "DEL" (data-entry language) は， 1992 年にブラジルの石油企業 Petrobras 社からの要請によって開発された。この DEL は，シミュレータに入力するデータを処理するための簡易的な言語であったとされる。
その後， Reberto 氏が PGM と呼ばれる岩相測定用のレポート・ジェネレータの開発に係わり始めると，これに特化された言語を新たに開発するという計画が立ち上がる。この言語は "Sol" と呼ばれることになる。 "Sol" とは "Simple Object Language" の略であるが，ポルトガル語で「太陽」を意味する語でもある。
Sol の実装は 1993 年の 3 月に一通り完了したものの，ついにリリースされることはなかった。 Roberto 氏らの興味は既に，これらの言語を強力な単一の言語によって置換することに向けられていた。この言語は "Sol" の次であることから "Lua" （ポルトガル語で「月」の意味）と名付けられることになる。
2006-04-07
Roberto Ierusalimschy, Luiz Henrique de Figueiredo, Waldemar Celes. The Evolution of Lua.
セマンティクスの面では， Lua と Scheme は高い類似性を持っている。（略）
Lua と Scheme の文法は大きく異なるため，その間にあるセマンティクスの類似性は明らかでない。しかし驚くべきことに， "Revised Report on the Algorithmic Language Scheme" [Scheme] の 1.1 章 ("Overview of Scheme - Semantics") について， "Scheme" を "Lua" に入れ換えてみると，不正確な点は次に挙げるものしかないことが分かる。（略）
Pascal 風の文法を始めとして手続き型言語としての体裁を持つ Lua が，関数型言語の Scheme との間に高い類似性を持つというのは，少し奇妙なことのようにも思われる。しかし，関数をファーストクラス・オブジェクト (first-class function) として扱うことができ，完全なクロージャ (closure) と構文スコープ (lexical scoping) と末尾再帰 (tail recursion) を備えており，無名関数 (anonymous function) の定義も許されているということを考えれば，関数型言語としての要素は十分なほどに備えられていると言える。
このような，手続き型言語と関数型言語の両面性（あるいは OOP も含めて三面性）を持つことが， Lua を「マルチパラダイム言語」たらしめている所以であると言える。例えば，マニュアルにある以下の例などは， Lua のマルチパラダイム言語としての片鱗を表している。
a = {}
local x = 20
for i=1,10 do
local y = 0
a[i] = function () y=y+1; return x+y end
end
テーブル a には 10 個のクロージャが格納される。クロージャ内部から上位スコープのローカル変数 x, y にアクセスを行っているが，変数 x はすべて同じインスタンスが参照されるのに対して，変数 y はすべて異なるインスタンスが参照されるようになっている。
このような「ネストされた関数から上位スコープのローカル変数を参照するケース」では，スコープを抜けた後もクロージャが生存する限りローカル変数を生かし続けなければいけない。 Lua ではこの問題を "upvalue" と呼ばれる特殊な参照の形式を導入することによって解決している。
2006-04-11
Defense Review の記事 [DefenseReview] によれば，米軍においてストライカー装甲車 [Wikipedia] に "Active Protection System" (APS) を導入する試験が進められている。ＴＶニュース [DefenseReview] では，これを「フォースフィールドのようなシステム」と形容している。たしかに，飛翔するロケット弾が目標の手前で突然爆発する様子は，まるで目標の周囲にフォースフィールドが張られているかのような印象を与える。
米軍が導入を進めているのは，イスラエルは RAFAEL 社によって開発された APS の一種である "TROPHY" システムであるとされる。 TROPHY システムは既に極めて実用に近い段階にまで達しており，試験では走行中の車輌に接近するロケット弾を迎撃することに成功している。
TROPHY システムは，実際には「フォースフィールド」ではない。解説記事 [DefenseUpdate] [Wikipedia] によれば，散弾を飛翔物に向けて射出する自動迎撃システムであるとされる。全方位をカバーするように配置されたレーダーユニットが飛翔物の接近を検出すると，コンピュータによりその弾道が解析され，適切なタイミングに適切な方向へ散弾が射出される。この散弾は迎撃対象に向けて密集されているため，周囲の兵士を巻き込んでしまう危険性は低くなっている。
TROPHY システムが主に迎撃の対象とするのは RPG (RPG-7) [Wikipedia] であるとされる。 RPG は比較的安価な兵器でありながらも，成形炸薬弾（HEAT 弾） [装甲研究室] を利用することによって，戦車や装甲車の脅威となりうる。従来はこれを "slat armor" [DefenceUpdate] と呼ばれる「柵」によって防御していたが，この「柵」は，輸送機による輸送の際に取り外さねばならないという欠点があった。また，榴弾を利用した RPG の攻撃に対しては無力であるという弱点もある。いずれの点も， TROPHY システムであれば克服することができると考えられている。
2006-04-12
TCP の基本仕様を定めた RFC 793 [RFC] には，次のような一節がある。
TCP の実装は，頑健性の一般原則に従うものとする： 己のなすことには慎重たれ，他人のなすことには寛容たれ。
この一節は，編者のジョン・ポステル (Jon Postel) [Wikipedia] の名を取って，「ポステルの頑健性原則」 (Postel's Robustness Principle) と呼ばれる。
この原則は，公開されたプロトコルやフォーマットを使用するうえで必要とされる心がけのひとつとして考えられている。
HTML 4.0-strict を記述せよ。 HTML 4.0-Tradisional を受け入れよ。 ― Tim Berners-Lee [w3.org]
しかし， BXXP (Blocks eXtensible eXchange Protocol) の設計思想を提示した RFC 3117 [RFC] においては，この頑健性原則は否定されている。
よく設計されたプロトコルこそ頑健である。
（中略）
反直感的ではあるが，ポステルの頑健性原則は，配備上の問題を生じやすい。何故だろうか？ 新たな実装が世に出るとき，その実装が直面するのは，既に存在する実装の一部分に限られがちである。もしこれらの実装が頑健性原則に従うとすれば，新しい実装に含まれるエラーは検知されないままとなってしまう可能性が高い。そして，新しい実装は広範の配備を見ずに，一部の配備を見るのみにとどめてしまう。この過程は様々な新しい実装において繰り返される。そしていずれは，「それほど正しくない実装」が，「初期の実装よりも寛容ではない実装」と遭遇することになる。その次に何が起こるかは，読者が想像できるであろう。
ポステルの頑健性原則は，一見すると「世の中をうまく動かすための真理」のように思えるが，実は問題の原因を内包した原則でもある。誤りを許容するという体質は，誤りの発見の機会を減らし，いずれ誤りをスタンダード化させてしまうというリスクを抱えている。究極に寛容なマークアップ言語であるところの HTML が，非常に扱いの難しい言語となってしまっていることを考えれば分かりやすいかもしれない。
他方で，全てが厳密に運用されれば問題は生じないとすることも難しい。この思想を実現するには，「利便性よりも規約を重視する」という禁欲的な理性が必要とされる。果たして一般のユーザは，少しのエラーも見逃さずに拒絶する実装と，少々のエラーは許容して何とか対処する実装と，どちらが「頑強である」と考えるだろうか？ 魅力のあるソフトウェアを作ることと，規約に関して厳密であることは，一部に背反する要素を抱えているように感じられる。
2006-04-13
Hacknot. Meeting Driven Development.
方法論は商売になる。人々は常に方法論を求めており，訴求力を持った方法論がそこに与えられれば，それはたちまち人々の間に広まっていく。ある方法論が人々に広まると，その流行は更なる錯誤 [Wikipedia] [辻野] を引き起こし，加速度的に信奉者を増やしていくことになる。
方法論の中には「ほにゃらら駆動開発」というような名の付くものがあるが [Wikipedia] ，これはまさにそのような訴求力を持つ方法論の例として挙げることができる。このような方法論は，複雑な事象を「ほにゃらら」という単一の要素に還元することが可能であるという，単純明快かつ非現実的な視点を与える。実際のソフトウェア開発は本質的に多変量を含んだプロセスであり，様々な抗力を打ち消すべく入念な推考のうえで調整を行っていかなければならない。しかし残念なことに，こうした視点は商売にならない。
このような「お手軽ワンタッチ方式」の思想は，多くは失望に終わる。しかし商売としては成功を続ける。それは，「○○ダイエットで簡単にヤセる！」とか，「○○ビジネスで素早く儲ける！」とかいうような商法が後を絶たないことを考えれば，分かりやすいかもしれない。
さて，ここまで読み進めれば，題名の "Meeting Driven Development" ― 「ミーティング駆動開発」が意味するところは，大体分かってしまうのではないかと思う。あとは Ed 氏のシニカルなジョークに目を通しながら，なぜ自分がそのような題名に興味を持ってしまったのか，その理由を考えてみると面白い。
2006-04-18
カーゴ・カルト・サイエンス
19 世紀末から 20 世紀にかけてメラネシア（オーストラリア北東の海洋部）の島々で発生した宗教運動に，「カーゴ・カルト」 (Cargo Cult) と呼ばれるものがある。日本語では「積荷信仰」と訳されることもある。
カーゴ・カルトの様式にはいくつかのバリエーションが存在するが，大方のところでは，「先祖の霊が汽船（あるいは飛行機）に乗り，様々な文明の品々を携えて到来する」と信じているという点で共通している [旅研] [Wikipedia] 。この信仰の背景には，太平洋戦争時に米軍が様々な物品をこの地方に持ち込み，退去時に遺棄していったという事実が存在する。この信仰は現在では廃れているものの，バヌアツの「ジョン・フラム運動」を始めとして一部では今もなお生き残っている [旅研] [Wikipedia] 。
物理学者リチャード・ファインマンは， 1974 年のカリフォルニア工科大の卒業式のスピーチにおいて，疑似科学（ニセ科学）の危うさを語る際に，カーゴ・カルトについて言及している [Feynman] 。
……南海にはカーゴ・カルトを信仰する人々がいる。戦争の間，様々な物品を積んだ飛行機が現れるのを見た彼らは，また同じことが起きて欲しいと考えている。そこで彼らは滑走路のようなものを仕立て上げて，その脇にかがり火を焚き，木の小屋の中に人を座らせ，頭にはヘッドフォンのような木片と，アンテナのような竹の串を立て ― 要するに彼は管制官なわけだ ― そして飛行機が訪れるのを待ち続けた。彼らは全てを正しく行っている。形は完璧だ。以前見たものと全く同じに見える。しかしそれは上手くいかない。飛行機は降り立たなかった。そのようなわけで，私はこれら（註：この直前に言及していた擬似科学について）をカーゴ・カルト・サイエンスと呼ぶ。彼らは，外見上の決まり事や，科学的な研究の形式を守ってはいるが，飛行機が降り立たない理由と同じ「本質的な何か」を見失ってしまっている。
疑似科学を信じる人々に，それがなぜ擬似科学なのか ― 何を見失っているがゆえに疑似科学なのか ― を教えることは，カーゴ・カルトを信仰する人々に，なぜいつまで経っても飛行機が降り立たないのかを教えるのと同じぐらい難しい。ファインマンは，その「本質的な何か」とは，学生生活を通して暗黙の内に身に付けていることが期待されるものであると説明するが，それを敢えて明らかな言葉によって表すとすれば，「科学的な誠実さ」 (scientific integrity) であろうと述べる。希望的な観測から生じる自己欺瞞を避け，常に客観的な視点から自己の理論を疑い続けることが，研究者にとって重要な姿勢であると説く。
カーゴ・カルト・プログラミング
恐らくはファインマンの「カーゴ・カルト・サイエンス」から派生した概念として，「カーゴ・カルト・プログラミング」と呼ばれる概念が存在する [JargonFile] 。カーゴ・カルト・プログラマ達は，あるコードの様式を，その本質的な意味を理解することなく，自らのコードに組み入れる。彼らは（あるいは「我々は」），その様式が過去にバグを退散させたのだから，自分達もそれを踏襲することによってバグを避けることができるに違いないと信じている。
彼らは，コードから goto 文を全て消し去れば，構造化プログラミングの神秘を携えたダイクストラが降り立つに違いないと信じているのかもしれない。あるいは，デザインパターンを用いれば，四人の偉人が編み出した設計の秘術を身に付けることができると信じているのかもしれない。あるいは，クラスのメンバ変数をすべて private にすれば，スコット・マイヤーズあたりの誰かが降臨して何かを与えてくれるに違いないと……云々。
しかしその実，彼らに何かの「積荷」がもたらされることは滅多に無い。それは，カーゴ・カルトを信仰する南海の住民の下に飛行機が降り立つことは二度と無かったという事実に似ている。彼らは先人が編み出した決まり事や形式を真似ようとするが，その恩沢を与るために必要とされる「本質的な何か」を見失ってしまっている。
では，その「本質的な何か」とは，一体何なのだろう？ それは恐らく個人の経験に根ざした，言わば暗黙知的なものであり，言葉にして伝えることは難しい。しかし敢えて明らかな言葉で表すとすれば，やはりファインマンの言うような「誠実さ」であり，自己欺瞞を避け，自己を疑い続ける姿勢なのだろうと思う。
2006-04-20
James Governor's MonkChips. "The Definitive Proof that Ruby on Rails is enterprise technology".
IBM が Ruby の達人を採用しているということは，すなわち Ruby はエンタープライズであるということだ。これは循環論法に見えるかもしれないけれど，実際のところ，他の人物や団体や何よりも，今もなお IBM こそが「何がエンタープライズで，何がエンタープライズでないか」ということを定義している。もし IBM が何かの分野を研究しているのならば，その分野は確実にエンタープライズにおいて用いられるようになるだろう。
IBM がサポートするならば，それはすなわちエンタープライジー (enterprisey) であるということなんだ。
アナリストの James Governor 氏は， Ruby 関連ブログを運営する技術者が IBM のトロント研究所に採用されたこと [ZenOfRuby] に触れ， Ruby (on Rails) がエンタープライズの領域に突入しつつあることを指摘する。
ここ数年の間，海外の記事において Ruby への言及を目にする機会が非常に多くなってきた。その多くは好意的な意見で占められている。 Rails のようなフレームワークが海外から登場したことは， Ruby コミュニティの熟成と国際化が本格的に達成されつつあることを象徴しているように思われる。
個人的には，これまで雑用のスクリプト言語として Python を使い続けてきた。 Ruby も候補には入れていたものの，コミュニティの大きさを比較した場合に，やはり Python の方が有利であるというのが一昨年までの状況だった。しかし，その状況も次第に変化しつつある。そろそろ別のバンドワゴンに乗り換える時期が来たように感じられる。
ちなみに，「エンタープライジー」 (enterprisey) という表現は， "The Daily WTF" への投稿 [DailyWTF] から発生したもので，新たなミームとして地味に広まりつつある [Wikipedia] 。
2006-04-21
「あらゆる問題に対して効果的な万能の探索アルゴリズムは存在しない」 ― David H. Wolpert および William G. Marcready が 1995 年に発表した "No Free Lunch Theorem" （以下 NFL 定理）は，この直感を数学的に証明した [NFL] [Wikipedia] 。 NFL 定理によれば，あらゆる評価関数について探索効率の平均をとると，その平均効率はアルゴリズムによらない。つまり，どのようなアルゴリズムも，全体で平均をとれば同じ効率を持つということを表している。
Image from Wikipedia
矢吹・伊庭氏の「No Free Lunch －理想の＊＊の探し方 －」 [矢吹] は， NFL 定理を平易な文体によって分かりやすく解説している。数学的に厳密な理解を望むべくはないものの， NFL 定理が証明しようとしていることの内容を，ある程度詳しいところまで知ることができる。
NFL 定理の影響を考える際に気を付けなければならないこととして，あくまでも，あらゆる評価関数の平均をとった場合の話であるということが指摘される。つまり，扱わなくてはならない評価関数の集合が，すべての評価関数の集合よりも狭い場合は， NFL 定理の前提が当てはまらない。その場合には，限定された条件に特化されたアルゴリズムを用いることができると考えられる。
余談だが， NFL 定理は進化論に対する反論の材料として用いられたことがある [NewYorker] 。インテリジェント・デザイン論者の William A. Dembski は， NFL 定理を拠り所として，自然選択による進化のメカニズムがランダム探索よりも優れた効率を持つことは無いということを示そうとした。その名も "No Free Lunch" という題名で書籍まで出している [Dembski] 。
しかし現在では，この Dembski による NFL 定理の適用は誤りであるとの意見が大勢を占めている [TalkOrigins] 。 NFL 定理の提唱者である Wolpert さえも Dembski を公に非難している [NewYorker] 。
NFL 定理は，どちらかと言えば究極的な結論を示したものであり，実世界の問題においては，評価関数が限定される可能性や，評価関数がなだらかな連続性を持つ可能性が高く，それらを活かすことによって効率を稼ぐことができると考えられる。進化論（および遺伝的アルゴリズム）の否定材料として NFL 定理を用いることのできない理由の一つとして，それが挙げられる。
2006-04-25
「サウンド＆レコーディング・マガジン」 [リットー] を読んでいると，時折，「ケーブルを換えると音質が変わる」というような記述を目にすることがある。ケーブルによって「音がクリアになる」，あるいは「音が柔らかくなる」，「音に締まりが出る」，等々，まるで温泉の効用のようにぼんやりとありがたい言葉が並ぶ。百歩譲ってケーブルによる音質の変化を認めたとしても，今月号などでは，「電源ケーブルで音が変わる」，「ファイルコピーで音が変わる」，「クロックジェネレータで音が変わる」等々の迷信めいた話がずらりと並んでおり，さすがにうんざりしてしまった。こうした記述を見るたびに，なぜか暗く陰鬱な気分になってしまう。
オーディオケーブルに関しては，ある程度の品質があれば，それ以上の工夫を凝らしたところで音質が変化することは無いと考えられる。ファイルコピー云々や「ＣＤを冷やすと音が変わる」等についても，たとえ電子的な部分で微量の変化があるとしても，それが音質に影響を与えることは無いと考えられる。これらは直感的に理解することができる。
しかし，これらの直感を科学的に証明するには，しかるべき実験手法と測定装置を用いた検証作業を行わなくてはならない。もちろん，自分のような素人にそれを行うことは不可能であるし，たとえ技術があったとしても，そのための手間と費用を捻出するには相応の覚悟が必要とされる。
他方で，「迷信」を広めるには，ほとんど何の労力も必要とされない。多少の自己欺瞞と，後に不名誉を被るかもしれないリスクを受け入れれば，あとはただ主観的な意見を述べるだけでそれを広めることができる。たとえそれがどんなにいい加減な内容であったとしても，それを信じたいと思っている人々がいる限り，その人々の間に「迷信」は広まっていく。
「迷信」の中には，それによって得られる変化があまりにも微量であるために，測定値に現れることは無く，人間の認知にのみ反映されるとする意見がある。もし仮に，その意見を受け入れたとしても，人間の認知に反映されるものである限りは，盲検法（ブラインド・テスト）によってその存在を実証することができる。盲検法によって実証が認められないものは，すなわち人間の認知に反映され得ないものであると考えることができる。そのようなものを「音質」として論じる意味はあるだろうか？
人間の認知を拠り所とする場合には，盲検法のような形式的な手法を用いなければ，容易に認知バイアスの罠へと捕らわれてしまう。人間の認知には非常に多くの落とし穴がある。 Wikipedia の "cognitive biases" カテゴリ [Wikipedia1] や "List of cognitive biases" [Wikipedia2] の項に目を通してみると面白い。これらの認知の「いい加減さ」が，「そうであってほしい」と願う心理と組み合わさると，それが詭弁や誤謬を生み出す。科学的なアプローチとは，個人の確信や推測ではなく，実験や観察によって得られる客観的事実を拠り所としなければならない [Wikipedia3] 。また同時に，それは反証を十分に受け入れられるものでなくてはならない [Wikipedia4] 。多くの「迷信」は，まさにその対極に位置する。
どういった文化的背景があるのかは分からないが，どうやらオーディオの世界というのは特殊な信仰の宿る世界であるらしい。第一線で活躍するプロの人々までもがそのような信仰に取り込まれてしまっているという哀しい現実が，自分を暗く陰鬱な気分にさせる。これらの信仰に対する科学的な考証・反証については，「オーディオの科学」 [志賀] が参考になる。自己防衛の材料として役立つのではないかと思う。
2006-04-26
人間が何かを「そうであってほしい」と望むとき，そこには大きな思い込みの力が働く。例えば，エクストリーム・プログラミング (XP) は，ソフトウェア開発の複雑なプロセスを，単純明快な実践（プラクティス）の繰り返しへと分解するが，これはソフトウェア開発を単純なプロセスとして捉えたいと願っている人々に対して，その願望が XP によって叶えられるという幻想を抱かせる。実際には XP も様々に複雑な問題を抱えているにも係わらず，「そうであってほしい」と望む心理が，それらの問題を覆い隠すための詭弁や誤謬を受け入れる状態を作り出してしまう。
このような詭弁や誤謬を見抜く判断能力は，理性や冷静さを必要とするのと同時に，個人の経験に根ざす部分が大きいと感じられる。これに似た話題として，立花隆氏が「メディア ソシオ－ポリティクス」 [日経BP] の第１回において，報道記者と判断能力の関係について次のように述べている。
記者は修羅場の中で、他社に抜かれるとか、誤報をする、ないし、誤報寸前の誤れる思い込みに陥るといった、手痛い失敗を何度か重ねてはじめて一人前になる。そのような失敗を重ねることで、はじめて、「ちょっと怪しい情報」のクレディビリティ判断が的確にできるようになる。ニュースバリューの判断が正しくできるようになる。
なぜ手痛い失敗が必要なのかというと、人間は本性上、このような判断において簡単に「思い込みによる誤り」を犯しがちだからである。人間は何かが「そうであってほしい」と思っているときは、そうである側に有利な証拠を無意識のうちに優先的に集め、その証拠価値の評価にあたっても、自分の願望に有利な方向にバイアスをかけて判断するのである。自分ではあくまで客観的に公正に判断したつもりでも、無意識のうちに、自己に有利に資する主観的判断を下しているものである。
このような客観性の欠如は人間の生来の特質であり，そこから逃れるには，失敗経験を基に本能的な警戒心を養うことが必要であると指摘される。ここで言う「本能的な警戒心」のように，個人の経験から生み出される知識は，いわゆる「語ることのできない知識」として分類されるものであり，記述によって伝えることが難しい。実践から経験を獲得し，その経験を反芻することにより，知識として吸収することが求められる。
前述のような開発方法論の話にしてみても，実際の現場にまつわる処々の問題を経験してみないことには，その裏に潜む誤謬を見抜くことは難しい。「形を身に付けなければ，形を打ち破ることはできない」とは古い言い回しだが，形を身に付ける過程の中に，形の限界を見抜くために必要とされる経験的知識が含まれていると考えると，言い得て妙であると感じられる。
2006-04-27
最近になって Google の Librarian Center （図書館司書向けのセクション）に "Downloads" のページが追加された [Google] 。現在このページでは， Google 検索の tips をまとめたポスターをダウンロードすることができる。
Google の検索機能については，もっと詳細にまとめられた cheat sheet が存在するが [Google] [Adelaider] ，こちらのポスターは非常に簡潔な構成にまとめられており， Google らしい洒落っ気の感じられるデザインとなっている。図書館の共用 PC の側に貼っておくような使い方が意図されているらしく，「使える人のための虎の巻」というよりかは，「使えない人のためのお助け帳」というような内容になっている。
実は，チルダ (~) による類語検索機能があることを，このポスターを見るまで知らなかった。例えば "~alcohol" で検索すると， "alcohol" と同時に "drug" や "drinking" なども引っかかるようになる。今のところ英語でしかサポートしていないようだが，便利な機能なので日本語でもぜひサポートしてほしいものだと思う。
上記 download ページには，他にも様々な素材を提供していく予定であると記されている。しばらくすると，また面白いものを見ることができるのではないかと思う。
2006-04-28
今年の初め，ヤマハは USB オーディオインタフェースを内蔵した 10 チャンネルミキサー "MW10" と， 12 チャンネルミキサー "MW12" を発売した [Yamaha] 。
ミキサーと USB オーディオインタフェースの組み合わせとは，いかにもありそうなアイデアだが，実際に製品として販売されたものは意外なほど少なかった。最近になっていくつかのメーカーからオーディオインタフェースを搭載したミキサーが発売されたものの，通信規格として FireWire を採用しているものが多い [Mackie] [Alesis] 。 USB での低レイテンシ入力に対応したものとしては，この製品がさきがけになるのではないかと思われる。
さすがに老舗メーカーの製品だけあって，低価格ながらも品質は高い。ツマミを適切に操作すれば，適切な反応が返ってくる。以前使っていた安物ミキサーでは，ボリュームをひねるだけでガサガサとノイズが混じったり，バランスを中央にしても左から音が出たりと，散々な状態だったためか，そのような何気ない品質の高さにもつい嬉しくなってしまう。
MW10 はマイク入力を４系統備えているが，うち２つはステレオライン入力と共用になっている。専用のライン入力と合わせると，計４系統のステレオライン入力を備えていることになる。この構成は，このクラスの製品群では比較的充実している方であると感じられる。 DTM の用途ではステレオライン入力が多くあった方が便利なので，この充実ぶりは非常に嬉しい。
回路構成は MW10 と MW12 で少し異なっている。 MW10 では，常にメインバスの信号が USB オーディオインタフェースに入力されている。 USB からの出力はテープ入力 (2TR IN) と合成されたのちに，メインバスに流すか，あるいはコントロールルーム出力 (C-R OUT) に流すか，どちらかを選択することができる。後者を使えば， DAW と外部音源の出力を合成して聴きつつ，外部音源の出力のみを DAW 上に録音するというような作業を行うことができる。
総じて感触は非常に良い。今までこのような製品がなぜ存在しなかったのだろうかと不思議に思ってしまう。 Windows 上での DTM を趣味とする人に広く薦められる製品ではないかと思う。