研究: 2005年12月アーカイブ
PowerPointでTEXを使うプラグイン、texpointがなぜか使えません・・・。
TEXを書いて、いざBMPに出力しようとすると次のようなエラーを吐きます。
Shell command did not produce bitmap "画像のパス"
調べても載っていない、詳しい人に聞いても分からない。
仕方ないからノートパッドでTEX書いて、pdfにして画像にし、範囲選択で個別の画像に分ける。というとても遠回りな方法でやりました。
疲れた・・・。
以前のプログラムでは点が多すぎて処理がかなり重かったため、近くにある点などを排除して、データの最適化を行いました。
ちょっとスカスカになってしまいましたが、フレームレートは少し回復しました。
最適化の方法は、4次元の格子を用意してそれぞれの点がどのグリットの中に入っているのかを調べます。そして、既にそのグリットの中に点があったら、それ以上点を保存しないように、つまり一つのグリットに一つの点しか入らないようにします。
これが意外に難しかったです。なぜかと言うと、各座標100個のグリットの配列を取ったとしても2次元の場合なら100×100で10000個の配列ですみますが、4次元の場合だと実に100の4乗、1億=100Mもの配列を必要とします。もしint(4バイト)なんかで取ってしまうと全部で400Mバイトの配列になります。このぐらいならまだ最近のマシンだと大丈夫かもしれませんが、さらに200個とか取ろうとすると200^4=16億=1.6G、intだと6.4Gバイトです。
これを解決するために構造体のビットフィールドというものを使いました。具体的には
typedef struct
{
unsigned b0 : 1;
unsigned b1 : 1;
:
:
unsigned b30 : 1;
unsigned b31 : 1;
} BIT32;
このような構造体を用意し、これを使って配列を組むことで400Mバイトの配列でもその32倍の数の配列を確保できます。つまり100^4が800^4まで多くなるのです。もちろんこれはビットなので0か1しか保存できませんが、そこに点があるか・ないかということが分かればいいのでそれで十分です。
エノンマップの周期13のやつを表示してみました。aの範囲は -0.5 ~ 6.95 までで 0.05刻みになってます。これがとっても面白い結果になりました。
まずはすべての点を表示した画像を見てみましょう。

さすがに重いです。見て分かるようにFPSが1秒ぐらいになってます。でもすごい、山みたい。
じゃあ次はa = 6.95からどんどん値を減らして見てみましょう。
見てのとおり最初は周期が小さな時とあんまり変わりないですが、aの値が小さくなっていくにつれて点が近づいていき、次々に衝突していきます。そして、衝突後の変化が近い点であっても激しいものになっているので、こんなにも多彩なグラフになっているんだと思います。
a が近づいていくのは、2次関数の解での重解に近づいていくのと同じなんですが、その後の虚数解への散らばりぐらいを見ていると、まさに”衝突”って感じがします。すげぇ面白いっす!
4次元の透視投影を追加しました。言ってみれば、4次元の遠近法です。難しそうに聞こえますが、これも3次元の場合とほぼ同じで、座標軸が一個多いだけです。
こうやって4次元立方体と一緒に表示して動かすと、4次元で回転しているのがなんとなく分かります。
<操作方法>
右クリックしながらマウス移動:4次元の回転
左クリックしながらマウス移動:3次元の回転
右クリックしながら上/下矢印ボタン:点サイズ拡大/縮小
左クリックしながら上/下矢印ボタン:座標の縮小/拡大
左クリックしながら右/左矢印ボタン:点の増加/減少
実行できない人は.NET frameworkとか入れるといけるかもしれません。

















