次期グラフシミュレータ（GraphSim3）に関する考察（４）

研究

４回目です．少しだれてきました．
２回目に，問題点を挙げた．前回は，２番目の入出力関数でのポート指定の扱いづらさについて検討した．今回は，３番目の入出力データの扱いづらさについて述べる．

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

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

GraphSim2では，入出力データは，intを保持するDataObjectを用いて表現される．当時の私の考えでは，各機能回路群に合わせた基本データオブジェクトをDataObjectを継承して定義すれば良いと考えていた．しかし，その考えは甘かった．
画像処理用の回路を設計したとき，まずはアルゴリズム検証ということで，ＲＧＢ８８８を１データとした機能回路群を設計した．ここまでは何事もなく順調に設計が進んで良かった．しかし，いざ設計したシステムを，ＰＣＡ１上で動作させるためには，ＰＣＡ１で扱えるデータ型である４ビット処理に変換しなければなりませんでした．
変換するときの方針を次のように立てました．
まず，各機能回路を，ＲＧＢ８８８処理から４ビット処理に変換します．ＲＧＢ８８８の計２４ビットデータを，下位４ビットから６つに分割し，それに伴い処理も変更します．そして，各機能回路の入力側には，ＲＧＢ８８８から４×６データへのエンコード回路を，出力側には，４×６データからＲＧＢ８８８へのデコード回路を置きました．
次に，対となるエンコード回路とデコード回路を取り除きました．これにより，エンコード回路とデコード回路を削除することができます．
これらを行う際には，もちろん毎回テストを行いました．

（続く）

続きです．上記の問題は，データ型に対する回路変換が必要なところです．当たりまえっちゃあ当たり前ですが，私が目標としているのは，構造を変えずに様々なプラットホームに対応できるようにするというものですので，データ変換のために無駄な機能回路を導入して構造を変えてしまう上記の流れは，納得いくものではありません．
この問題の解決策として，現在はデータの流れを指定するチャネルに，データを自動で変換のためのロジックを持たせることを考えています．
また，DataObjectは，intを保持するオブジェクトです．逆に言えば，intを保持しなければなりません．
昔，ネットワーク越しに文字列データを取ってきて，それをフィルタリングするような機能回路（コマンドラインシェルでのパイプのようなものを実現したかった）をモデリングしたことがあります．このとき，文字列を基本データとしたかったのですが，処理のためのデータ型がDataObjectを継承しなければならなかったため，かなり苦労したのを覚えています．DataObjectを入出力するのではなく，Objectを入出力しなければならないかなと感じました．
ＰＣＡのための機能回路には，多彩なビット演算を処理するものが多々あります．それらのビット演算を容易に記述することが難しいのも，DataObjectを利用してしまったときの弊害です．
まとめると，次期GraphSimでは，多彩なビット演算を容易に記述でき，かつ文字列などのプリミティブなオブジェクトも容易に扱え，しかもデータ型の自動変換をサポートできるような，基本データ型を設定したいと感じています．