タイトルはあえて狙ってみた。うん、エセ整備士あたりがツッコミを入れてくれるかもしれないし、何のことか分かってくれないかもしれない。まぁそれはどうでもいいんだが（ぉ

今研究で組んでるプログラム中に、3次元配列が出てくる。まぁはっきり言って扱いづらいし、見た目にもあんまりよろしくないってことでベクトルをクラスにして、それを2次元配列とした隠蔽メンバを持ち、2次元配列として扱えるようにインデクサを持たせたクラスを作成。稀にベクトルにアクセスしたいときが出てくるので一応ベクトルクラスにもインデクサは持たせてある。

まぁベクトルの内積やら2乗ノルムといった信号処理で頻出する処理は関数を用意したからあまりベクトルの値を直接参照することはないようには作ったつもり。とはいっても全部自分が使うプログラムだからあんまり対外的なことを考えてもしかたないんだけどなーと思ってしまうこともないことはない(苦笑)

けど、どうカプセル化しようが根本的に３次元配列であることに違いは無く。
それを複数まとめて処理したいクラスが出てきちゃったんだから当然その３次元のクラスを配列で処理する訳で。
で、それらのベクトルをFFTした複素数を保持する処理が必要になっちゃって。別にクラス化するほど使い回すもんでもないから複素数型を用意して受け皿として使ったのだけれど・・・。

3次元の構造を持つクラスを配列として用意したものに対する受け皿。
３次元＋1次元。

4 JI GE N !!!

いや～まさか信号処理やってて4次元配列を扱う羽目になるとは夢にも思わなかった(笑)

C#ではRectangle ArrayとJugged Array（綴りあってたっけな？）の両方が扱えるけど、FFTのライブラリが受け付けてたのが1次元のComplex型配列だったため
Complex[,,,][]
といったJugged Arrayを保持するRectangle Array型にせざるを得ない妙な実装に＾＾； いや、全部Jugged Arrayにして
Complex[][][][]
にしてもよかったのだけど、初期化が面倒やな～と。4重ループなんて回したくないからなぁ。

まぁ今回に限り、実装の関係上次元が1つ下がって3次元で問題なくなったんだけど。2次元めが要素1個しかないから複数個持たせる必要が無く、受け皿としては３次元で事足りるよと。

今回のプログラムはもう拡張性やら汎用性は一切合切無視で決め打ちだからってことでかなり雑に組んでるからなぁ。いやまぁどのみち拡張性に耐えうる構造にしたらめっちゃ冗長性が増えて見にくさ爆発することが目に見えたから端っからそんなこと投げ捨てただけなんだけど(笑)

ふむ、けど共通化できるメソッドくらいはありそうだな。インターフェースクラスくらいは用意出来そうか。最近ようやくインターフェースクラスを用意する価値が分かってきつつあるからなぁ。まぁ自身がそれを活かした実装が出来るようになるまではもう少し掛かりそうだけれど＾＾；

ふむ、そうなるとインターフェースクラスをやたらと継承する羽目になりかねないなぁ・・・。いやまぁそういうもんか？ Javaでそれがなんか問題になってたような・・・。まぁそれはある意味宿命か。

う～ん、今回こそは見やすさ重視で！と思って組んでたんだけどなぁ・・・。

いやある意味見やすいか、拡張性なんて考えずに理論式そのまま打ち込んでるものなw ロジックだけを追いかけるならまだましな構造になっている・・・と信じたい(苦笑)

要は自分が後から見直して見やすい構造になっていてほしいなってところ。学部時代に組んだCやらC++のプログラムを見てちょっと卒倒しそうになったOrz 特にC++はひどかったなぁ・・・。確かにオブジェクト指向に挑戦し始めたほんっとの最初だったってのもあるけれど、今見るとどういうロジックで組もうとしたのか見て取れない（ぉ

命名規則もひどいしな・・・。形から入ることは決して悪いことでは無いということを再認識(苦笑) 困ったことに今C++で組めと言われたら組めそうにないんだよなぁ・・・。今組んでるプログラムをC++に移植しようなんてかるーく思ってたけど、C++ややこしすぎる・・・。これならCに移植する方が楽なんじゃなかろうか・・・？

大体、実行速度を求めるならD言語という手段もある。あっちの方がC++よりもC#に近いと思うから移植はしやすそうだ。C/C++のライブラリが使えるのかどうかは疑問やけれど、検討の余地はあるかも。

とりあえず、C++だけはもう触りたくない、そう思った今日この頃でした（ぇ