ぼうメモ帳

2005-03-19

次期グラフシミュレータ(GraphSim3)に関する考察(6)

| 次期グラフシミュレータ(GraphSim3)に関する考察(6) - ぼうメモ帳 を含むブックマーク

6回目です.だれだれです.疲れてきたので,この辺で一回止めておきます.

前回は,4番目と5番目について検討した.今回は,6番目と7番目について述べる.

  1. 不必要なコンストラクタ
  2. 入出力関数でのポート指定
  3. 入出力データの扱いづらさ
  4. 無駄なtry{}catch{}構文
  5. InterruptedExceptionの記述
  6. ステートマシンの分かりづらさ
  7. DefaultFunctionalModule

ステートマシンの分かりづらさ

手続き型言語なので仕方がないといえば仕方がない問題点.ステートマシンを記述するためには,「ステートを保持する変数」+「switch-case」文を使って,ガリガリステートを記述しなければならない.これは,一般的な手続き型言語と同じ.

で,なぜ問題かというと,PCAの機能回路はステートマシンにより記述される場合が多い.とくに,ストリームの並び替えや,ストリームパターンマッチングなどが多い.どれくらい多いかと言われると数字を出せないので困るが,本当に割合的に多い.

割合的に多ければ,それらにマッチした記述方法を提供しても良いのではないかというのが,いまの考え.だから,ある特定のステートマシンについては,特化した記法を導入することで,ステートマシンの分かりづらさを解消しようと言うこと.

DefaultFunctionalModule

いちいちこれを継承するのがだるい.あと,継承してしまうことで,Java唯一の継承ルートを潰してしまうのが勿体ない.

どういうものが理想か.一番の理想は,Runnableのような機構を導入することだ.Runnableは,継承を消費することなく,Thread処理を記述することができる.では,なぜ現状ではそれを実現できないのか.一重に名前空間の問題である.read/writeメソッドをどこから引っ張ってくるのかという問題を解消できない限り無理.

Runnableを実装するクラスが単独で記述されるとき,外部の名前空間を用いない場合,もしくはインスタンスを生成した後に,何らかの方法で外部から情報を与えるようにプログラムを書く.それが面倒なときは,インナークラス,もしくは無名クラスとすることで,コンテキストに存在する名前空間アクセスする.

read/writeメソッドは,その動作はコンテキスト依存する.そのため,コンテキスト情報を何らかの方法で与えなければならない.現状では,それをDefaultFunctionalModuleが行っていると言うわけ.

これをなくすことができれば,継承ルートを空けることができて,ハッピーになれそう.だから,問題点.ここまで来ると,私の求める美しさにのみ依存した問題っぽい雰囲気もないことはないけど...

次期グラフシミュレータ(GraphSim3)(予告)

| 次期グラフシミュレータ(GraphSim3)(予告) - ぼうメモ帳 を含むブックマーク

まだまだ問題点は残ってるけど,言いたい事は言った.だから,次からは具体的な記述方法について考えてみることにする.すこし頭の中を整理して考えたいから,もう少し経ったらだけどね.

2005-03-14 実家にて,やっとネットにつながる俺

次期グラフシミュレータ(GraphSim3)に関する考察(5)

| 次期グラフシミュレータ(GraphSim3)に関する考察(5) - ぼうメモ帳 を含むブックマーク

5回目です.かなりだれてきました.

2回目に,問題点を挙げた.前回は,3番目の入出力データの扱いづらさについて検討した.今回は,4番目の無駄なtry{}catch{}構文と,InterruptedExceptionの記述について述べる.

  1. 不必要なコンストラクタ
  2. 入出力関数でのポート指定
  3. 入出力データの扱いづらさ
  4. 無駄なtry{}catch{}構文
  5. InterruptedExceptionの記述
  6. ステートマシンの分かりづらさ
  7. DefaultFunctionalModule

2005-03-09

次期グラフシミュレータ(GraphSim3)に関する考察(4)

| 次期グラフシミュレータ(GraphSim3)に関する考察(4) - ぼうメモ帳 を含むブックマーク

4回目です.少しだれてきました.

2回目に,問題点を挙げた.前回は,2番目の入出力関数でのポート指定の扱いづらさについて検討した.今回は,3番目の入出力データの扱いづらさについて述べる.

  1. 不必要なコンストラクタ
  2. 入出力関数でのポート指定
  3. 入出力データの扱いづらさ
  4. 無駄なtry{}catch{}構文
  5. InterruptedExceptionの記述
  6. ステートマシンの分かりづらさ
  7. DefaultFunctionalModule

入出力データの扱いづらさ

GraphSim2では,入出力データは,intを保持するDataObjectを用いて表現される.当時の私の考えでは,各機能回路群に合わせた基本データオブジェクトをDataObjectを継承して定義すれば良いと考えていた.しかし,その考えは甘かった.

画像処理用の回路を設計したとき,まずはアルゴリズム検証ということで,RGB888を1データとした機能回路群を設計した.ここまでは何事もなく順調に設計が進んで良かった.しかし,いざ設計したシステムを,PCA1上で動作させるためには,PCA1で扱えるデータ型である4ビット処理に変換しなければなりませんでした.

変換するときの方針を次のように立てました.

まず,各機能回路を,RGB888処理から4ビット処理に変換します.RGB888の計24ビットデータを,下位4ビットから6つに分割し,それに伴い処理も変更します.そして,各機能回路の入力側には,RGB888から4×6データへのエンコード回路を,出力側には,4×6データからRGB888へのデコード回路を置きました.

次に,対となるエンコード回路とデコード回路を取り除きました.これにより,エンコード回路とデコード回路を削除することができます.

これらを行う際には,もちろん毎回テストを行いました.

(続く)

続きです.上記の問題は,データ型に対する回路変換が必要なところです.当たりまえっちゃあ当たり前ですが,私が目標としているのは,構造を変えずに様々なプラットホームに対応できるようにするというものですので,データ変換のために無駄な機能回路を導入して構造を変えてしまう上記の流れは,納得いくものではありません.

この問題の解決策として,現在はデータの流れを指定するチャネルに,データを自動で変換のためのロジックを持たせることを考えています.

また,DataObjectは,intを保持するオブジェクトです.逆に言えば,intを保持しなければなりません.

昔,ネットワーク越しに文字列データを取ってきて,それをフィルタリングするような機能回路(コマンドラインシェルでのパイプのようなものを実現したかった)をモデリングしたことがあります.このとき,文字列を基本データとしたかったのですが,処理のためのデータ型がDataObjectを継承しなければならなかったため,かなり苦労したのを覚えています.DataObjectを入出力するのではなく,Objectを入出力しなければならないかなと感じました.

PCAのための機能回路には,多彩なビット演算を処理するものが多々あります.それらのビット演算を容易に記述することが難しいのも,DataObjectを利用してしまったときの弊害です.

まとめると,次期GraphSimでは,多彩なビット演算を容易に記述でき,かつ文字列などのプリミティブなオブジェクトも容易に扱え,しかもデータ型の自動変換をサポートできるような,基本データ型を設定したいと感じています.

269660