hirax.net::Keywords::「動的」のブログ

■「線路」と「人生の方程式」　

　朝早くは晴れていたけれど、10時を過ぎる頃には雨と霧で包まれる。高原特有の、白い霧が風に早く運ばれていく。

√a = 18 旅路(ルート)の中では、人はいつも18(age)である。

　青春18切符をポケットに入れて、京都と東京の間を11時間かけてよく移動した。

河から海へ船が出て行く。後ろの港には船が帰っていく。風の流れがそのまま波を動かして、その波の上に立っている人たちがいる。風が吹くともっと潮の匂いが強くなる。

　安いPCでグリッド・システムを組むと、どうしても巨大なハードディスク領域ができあがる。そんな領域を有効活用しようと思うと、Gmailみたいなものになるのだろうか、と昔考えた。

　この方程式で使われている"="は、いわゆる等号"=="ではなく、代入の"="かもしれません。

　"=="が"="に変化した途端に、「人生の方程式」が「人生の定義式」に変わる。自らは決め得ない未知数を条件に応じて解くという行為が、能動的に何かを決めていくということに変わる。

　素直に言い換えれば、「旅路(Route)の中では、人は誰でも18(Age)になる」というコピー文そのままに変身します。さらに言い換えるなら、「すべての人を18歳の頃に戻す」ものが「旅路(Route)」なんだと、声高らかに宣言する力強い定義式なのかもしれません。

　荒木経惟が撮る青春18切符が好きだった。あるビルの回転ドアを出るとき、その回転ドアの対角線上には、ビルへ入っていく荒木経惟がいた。

　自分や他人のつまらない考えに沿った「道（Route）」の上を走り続けるのも、なんだかつまらなく感じられることがあります。そんな時には、そんなルートを外して色んなものを眺めてみるのも、少しだけは、良いのかもしれません。　

　"=="が"="に変化した時、 if 文で使われる「こんな場合には」という等号が、定義という意志と行動に変わる。

「決められたレール」は無いほうがいい。 　1995年 「青春18切符」冬

■「ネイティブ言語」の意外性　

　「DAPDNA」は、IP Flexのダイナミック・リコンフィギュラブル・プロセッサ「DAPDNA」だ。ダイナミック・リコンフィギュラブル（動的再構成）技術、つまり、チップの処理内容をns(ナノ秒)単位で切替えることで、多種機能を自由度高く比較的小規模なチップで実現することができるチップである。

　私は去年、日本ですごい異世界を発見してしまいました。手話です。ネーティブの人、つまり「ろう者」の先生から直接手話を習っているんです。福祉に目覚めたわけでは全然なく、それが言語だと知ったからなんです。
　　高野秀行

　このDAPDNAの統合開発環境には２種類ある。一つは、C言語のような「高級言語」を使う DFC Compiler で、もう一つが演算器をドラッグ･アンド・ドロップで繫げるGUI 形式の開発環境 DNA Designer だ。

　DAPDNAの紹介文書を眺めていると、”DFC Compiler ではC(風)言語で手軽・簡単に記述することができます””DNA DesignerはGUIを使った開発環境で、ハードウェアの能力を最大限に活用した細かなチューニングをすることができます”というようなことが書いてあった。一瞬、「おやっ？」と不思議に感じた。「C言語なら簡単・手軽で、GUIプログラミングではハードウェアの能力を活かしきるチューニングが可能だ」というフレーズに意外性を感じた。たとえば、「Windowsのアプリケーションを作るのに、APIゴリゴリのプログラミングより、GUI開発環境でプログラミングする方が、チューニングできる」と聞いて、「あれっ？」と感じるような意外性を感じたのである。

　言語が違うということは世界の見え方が違うということです。

　　高野秀行

　しかし、これは少し考えれば当然のことだ。行いたい処理を、「C言語」で記述した内容から演算器群を用いて自動生成するのと、演算器を回路図として記述するのでは、後者の方が「ハードウェアの能力を最大限に活用した細かなチューニングをすることができる」のは当たり前である。GUI開発環境上でドラッグ･アンド・ドロップされ、それらの繋がりが描かれた演算器群こそが、こういったチップの動きを一番素直に記述する「ネイティブ言語」なのである。並列化が進んだシステム上で動くものを作るときには、GUI言語こそがネイティブ言語と言えるのかもしれない。

　手話も、手話ネーティブもほんとに面白い。福祉の話題にしておくのはもったいなさすぎます。こんなに文字かなところに異世界があるんだから、一人でも多くの人に楽しんでほしい。

　　高野秀行

■Photoshopプラグイン開発環境(PDLS)再び　

　Photoshopプラグイン開発環境 Photoshop DLL Linking System (PDLS) のページを(旧Pukiwiki)のファイルを元に書き直しました。PDFの説明ファイルの2004/08/07版はこちらになります。また、サンプルソース・バイナリファイルはこちらです。

　AmetMultiのモットーは「ATOKから何でもできる」でしたが、PDLSのモットーは「Photoshopから（その人のレベルに応じて）何でもできる」でした。(Photoshopの規約は気にせず)Cを使ってネイティブ・プラグインを気軽に書くこともできれば、GUIを使った連続作業などで自動的にマクロ関数(プラグイン)をお手軽に作ることもできる。その人のレベルに応じて、ステップアップすることができるPhotoshopのプラグイン開発環境というわけです。

　マクロ関数やネイティブ・プラグインを組み合わせれば、さらにカスタムプラグインを作ることもできます。また変数を使ったり演算や数式処理も使えて、NEWやDELETEといったマクロを使い、局所領域に対してだけ演算を行うこともできます。そして、マクロプラグインには自動的にGUIをかぶせることもできるのです(GUIコードを書かなくても、ダイアログで変数設定などを実行時にすることができる)。

　また、表計算アプリとの連携や鳥瞰図表示のプラグインもついている……というテキトーな機能てんこ盛り、の環境です。Photoshop Elementなんかで使うこともできますので、画像処理で遊んでみたい人は一度使ってみても良いかもしれません。いつものように、SYSTEMコールもできるプラグインなので、つまりは何でもし放題のプラグイン環境です。使ったことのないPhotoshopユーザ（ないしはPhotoshopプラグイン互換の画像処理ソフトユーザ）は一度遊んでみると良いかもしれません。

■続・ブレーキングとコーナリングの荷重問題　

　「ブレーキングとコーナリングの荷重問題」で描いたような単純な「車モデル」はないだろう。しかし、これくらい簡単な模式図にしないと、その動力学を頭の中で追いかけることが難しかったりする。残念ながら、ここまで簡単にしてしまった「車モデル」では、すでに「現実」の車とはあまりに異なっているに違いない。しかし、単純なモデルでなければ全然理解できない……ということも、これまた哀しき現実なのである。

　上のようなモデルだと、たとえば、（上図の右下に描いたような）左コーナリング時には、右輪サスペンションには伸びる方向に働くようにして、その一方で、左輪サスペンションには、適度に縮むような制御をさせたくなる。そうすれば、左コーナリング時に、車から右に放り上げられるような心細い感覚を味あわないですむ。
　あるいは、ブレーキ制動時には、前輪サスペンションを縮まないように伸ばしつつ、後輪サスペンションは縮ませ、車が前に浮かび上がらないようにしたくなる。そうすれば、車から前前方に放り出されるような怖い状態になることもない。
　つまりは、サスペンションの動作を、その時々の状態に合わせて能動的に変化させるアクティブ制御（アクティブサスペンション）をかけたくなる。

　かつて開発が盛んだったアクティブサスペンションの能力は驚異的だったが、コストが高くなかなか製品化されない、という話を聞く。そのため、製品化されていたのは、たとえば、減衰力を能動的に変化させるというように簡易・省略化したセミ・アクティブサスペンションくらいだったりした。一度、フルアクティブサスペンションの車に乗って、その操縦感覚を体験したいものだ、と思う。

　ゲームセンターの体感カーゲームで、利用者が好きなように車の部品・構造・制御方式などを決めることができるようなものは無いのだろうか？あるいは、PCゲームではどうなのだろうか？もしあるのだとしたら、そんなゲームで遊んで見たい。

■「スペクトル操作Mathematicaライブラリ」で動画を作る　

　光スペクトル操作用のMathematicaライブラリで、スペクトル変化の動画を作ると、こんな感じになります。Map　も　spectorPlot　も　Table も addtiveMixtureSpector　も whiteLight も cyanFilter も・・・どれも「関数」です。addtiveMixtureSpector　や whiteLight や cyanFilter は「関数を返す関数」で、Map などは関数を引数にとる関数です。Mathematica でコードを書いていると、なぜか自然に関数を重ね合わせていくような書き方が気持良くなってきます。

Map[spectorPlot,
　Table[
　　addtiveMixtureSpector[
　　　{whiteLight,
　　　transmissionSpector[whiteLight,
　　　cyanFilter, 1.0]}, {1-r,r}]
　,{r,0,3,0.05}]]

　それで、今この瞬間の悩みはMathematicaで"spectorFitting[targetSpector_,usingSpectrum]"というような関数をどうやって書くか、ということです。targetSpector は、任意のスペクトルを表現する関数で、usingSpectrum は「スペクトルを表す関数群」で要素数は任意のリストです。usingSpectrumを使いtargetSpectorをどのように表現するかを、最小二乗近似で最適解をNMinimize で解くというのが、そんな関数を作るときの定番の手順なのだろうと思います。つまり、方程式と制約条件を動的に作成し、それをNMinimize で解いた結果を返す、という具合です。

　さて、この　spectorFitting という関数はどう簡単に書くことができるものでしょうか。Mathematicaは変数名と文字列を明確に区別する割に、見た目ではまったくその違いがわからないのが面白いところ（同時に苦労するところ）かも、と思ったりしたのです。