hirax.net::Keywords::「実装」のブログ

■「男と女のデート大戦略（アルゴリズム）」をプログラムで語る　（初出：2006年03月26日）　

　「サイエンス・ウォーカー」で「科学なデート」で、「理系ウンチク話」をデートの時に喋るのは、デート成功のために有利なのか・それとも不利なのか？どっちなんだろうか？と書いてみました。

　すると、その後、「本人が楽しそうに話してたら、何が楽しいと思ってるかを伝えようとしたら、きっと受け手も楽しい。けれど、相手に楽しさを伝える前に自分を賢そうに見せたり自分の知識をひけらかしたりしたがる人だと、受け手はあんまり楽しくない」「友達だって、恋人だって、飲み会だって、一方通行の会話（話？）だと楽しくない」「(理系話題に慣れていない)聴き手に合わせて上手く説明したり、話をアレンジできる機転が（話し手に）ない場合には、理系ウンチク話をしない方が良いかも」なんていう意見を頂きました。

　その言葉を眺めながら、私はふと「相手に合わせて上手く理系ウンチク（あるいはそれ以外）を話すデート作戦」をキッチリ考えてみたくなったのです。…「ゴリゴリ理系っぽく」論理的に考えてみたい、と思ったのです。

　そこで、試しに、「男と女の間のデート戦略アルゴリズム」をプログラム言語で考えてみることにしました。例えば、

try {
    if (he.talksAbout(rikei)) { 
        she.likes() 
    }
} catch (Java.she.Exception jse) { 
    she.talksAbout(DISLIKE); 
    he.chagePolicy('otherWay');
}

という感じです。

　実際に、行動をプログラムで実装してみれば、デートの作戦・考え方や、自分が予想する相手の対応がすっきり、明確に見えてくるような気がします。そして、何より、そんな作業はとても面白そうです（あくまで、理系的には、ですが）。

　「男と女のデート大戦略（アルゴリズム）」をプログラムで語る、オープン・ソースの「デート」支援　というのも結構楽しく役に立つかもしれません。「誰もが活用できるデート戦略（アルゴリズム）」や「（いさまざまな）例外・エラー処理に対してどのように対処するか」を、さまざまな言語でオープン・ソース開発する、というハウ・トゥー本なんていうものがあっても、面白いのではないでしょうか。

　さらには、もしかしたら、いつの日か「男プログラム」と「女プログラム」がデート試行をすることで、アルゴリズム・実装の「性能・効果比較」をすることができるようになり、その結果として、汎用的な一般最適アルゴリズム（戦略）すら、できあがったりする時代が来たりするかもしれません!?

■Rubyで"tail"　

　ファイル末尾を表示するコマンドtailをRubyで色々なやり方で（そして最適なやり方で）実装しようというRuby: フィルタコマンド/tail

　tail コマンドって知っています? Unix 系のシステムでは、ファイルの終りだけを表示するコマンドとして使用されています。
　 実現方法の考え方(アルゴリズム)の勉強にとてもいい課題になっています。 最初は基本的なアプローチで、できたら大きなファイルでもうまく動くような方法を考えてみてください。

■正規表現と「美しいコード」　

　しばらく前のことだったと思う。正規表現の書き方の話題になり、「美しいコード」とか「目的に対する実装のバランス」といった話になった。

　その時、「コンパイル(NFA->DFA)にどの程度の時間がかかるか」という観点からのアドバイスを受けた。これまで、そういった基本的なことを考えたこともなかったので、今さらながら、そのアドバイスを消化するために、正規表現とNFA・DFAについて、さらってみた。

　DFA:Deterministic Finite Automaton=決定性有限オートマトン、やら、NFA：Nondeterministic Finite Automaton=非決定性オートマトンといった文字列を眺めながら、こんなワクワクさせられる面白いことを、なぜ今まで楽しむことができなかったのだろうと、そんなことを切実に感じさせられた。

　なお、オートマトンの日本語訳は、自動機械であって、自動羊肉ではないらしい。

■「すること」を考えることと、「その実装」を考えることと、「大量生産する」こと、と　

　「目から鱗」という言葉があります。そんなことを感じた時のひとつに、「（実装の仕方はわかるけれど）、何をどう作るかという根本的ななことは、私にはわからない」という言葉を聞いた時があります。その言葉を発したのは、あるMachカーネルのOS日本語版作成をカリフォルニアで作成した人でしたから、その言葉を聞いた瞬間少し意外に感じました。けれど、その人が何を言っていたか、少しだけ、わかるような気もしました。それは、「すること」を考えることと、「その実装」を考えることは必ずしも同じことではない、ということです。あるいは、そのふたつを同時に行うことができる人も（まれには）いるけれど、多くの場合は、その片方しかできないということでした。

　「すること」を考え・作り出すためには、今ならば、数学か物理を自由に扱うことができないといけないようにも想像しますし、「その実装」を考え・作り出すには、（ある程度の数学と）プログラミング能力が必要とされるような気もします。そのどちらか片方が難しい・簡単ということはないのだろう、と想像します。それぞれのことが「できる」ようになるためには、きっとかなりの時間を必要とすることなのだろうと思います。それは、（設計から製造までの各過程をできる人の比率こそ違うかもしれませんが）機構・機械システム作成でも言えることかもしれません。

　自分が何をしたいのかということと、世の中が何を求めているのかということと、そして、自分が何をできるのか、という３つの力のバランスで、そんなコックリさん的な解として、どんな道を選ぶかが決まるのだろうか、と思います。かといって、そんな三体問題には一般解はないわけで、結局のところ、自分の気持ち次第というのが本当のところ、かもしれません。

　何にせよ、作りだしたものがすべて、というひとつの基準で判断されることなのかもしれませんが…。

■何かを作る時の「円グラフ」　

　iPhone用のビデオカメラ・ソフトにソフトフォーカス効果を実装してみました。口径の大きなレンズを使った時のような被写界深度が浅い映像にさせる、という処理を書いてみました。テスト用に撮影した動画のひとつが、下に貼付けたものになります。

　「ぼかし処理」くらいなら簡単に実装できるだろうと思いつつコードを書き始めたのですが、意外なほど時間がかかってしまいました。時間がかかったのは、丸め誤差や端部処理をどう扱うかを決めるまでに試行錯誤を繰り返してしまったからです。使った時間を円グラフで描くなら、半分が「作り方の概略を決める作業」で、もう半分が「単純だけれど（作り終わる）先が見えなくなりがちな実装作業」でした。そういえば、昔そんなソフトウェアを実装したときも、速度と不連続性のバランスを帳尻合わせすることに苦労したのですが、そんなことを、コード書きとテスト作業をするまですっかり忘れていたことに気づかされたのです。

　何かを作る時、「かかった時間の内訳円グラフ」を作ったなら、一体どんなものになるのだろうか、と考えます。そして、その円グラフを”まぁまぁ”の範囲で予想できるようになりたいものです。・・・それを言い換えれば、自分が作り上げたいと思うこと、それを作るために必要になるだろう作業をすべて”まぁまぁ”の範囲でできるようになりたいと夢みてる・・・のだろうか、と思います。