反発力の計算が14倍ほど速くなった、他。
GRINEditの中で一番重たい関数は反発力を計算している PL_Repulsion#applyなのだけど、ちょっと眺めて、ループの奥でやっている割り算が 定数での割り算なのであらかじめ逆数を求めて置いて掛け算するようにしたら5%早くなった。 そこで火が付いて、毎回頂点をIMassPointにキャストしてgetPositionしてたのを 先にキャストとgetPositionをすませて配列に入れておくようにしたら元の半分の時間に減った。 あとベクトルの計算を不定長のベクトルと見なしてforで回して計算していたのを、 長さ2のベクトル決めうちにしてインライン展開したら、元の実行時間の7%に縮んだ。 プロファイラ上のもたもたした画面で見ると早くなったのが実感でわかる。 まぁ、プロファイラをかけていることで、関数呼び出しのオーバーヘッドが増えているはずなので、 インライン展開による高速化の度合いは誇張されているだろう。 この高速化のせいで、反発力計算クラスはそのままでは3次元に対応できなくなったけど、 対応させるさほど難しくないし、その見返りとしてプログラム全体で見て30%の高速化になったのだったら 悪くない取引だと思う。
1746頂点の「全ての辺が8本のグラフ」の描画が5FPS以上で動く！ 実用的な速度で動かないグラフの例として入れたのに、ぎりぎり実用範囲内に入ってしまった。
物理法則を設計する上で大事なこと。 まず力が連続的に変化すること。 次に作用反作用の法則を入れること。 最後に、現実の物理法則はあり得る物理法則の一つに過ぎないので、 物理学的に正しい物理法則ではなく、得たい結果が得られる物理法則を選ぶべき。 この3つだろうか。 最初の項はちょっと正しくなくて、例えば壁に貼り付く物理法則の場合、 一定距離に近づくと急に力が発生するから連続的ではない。 だから正確に言うと「適切な長さの切り替え区間を挟まずに プラスの力とマイナスの力を切り替えてはいけない」 ということになるだろうか。 要するに「0以上はマイナス1、0未満はプラス1」なんて力は 0周辺で振動を起こすのでダメだということ。 たまに1ピクセル以上の振動を起こすソフトがあるけど、 それは物理演算の設計のミスだろう。 作用反作用がないと合計が0にならずに1方向に動いていってしまう。 例外はやっぱり壁に対する力で、壁は力を吸収しても自然に見える。 最後の物理法則は自由にデザインしてもいいという宣言は重要で、 GRINEditの反発力なんか半径の二乗分の一どころか、半径分の一でもない。 なぜかというと、うっかりこんな実装にしたら、 運悪くすごく近い位置に頂点が並んだが最後、画面の果てのそのまた果てまで吹き飛んでしまう。
プラグインシステムのおかげで新しい頂点や物理法則の実装が楽になったかも。 プラグインフォルダのinit.pyは自動的に発見されて実行されるので、 新しい何かを実装しようと思ったらまずtestフォルダの中にinit.pyを作る。 そしてそこで頂点や辺や物理法則をグラフに追加するコードを書く。 実行すると実装中の頂点とかが表示される。 でJavaのコードを修正して実行して、とやって完成したら、 そのinit.pyをtestFileIconVertex.pyとかに名前変更する。 そうするともう呼び出されなくなるけど、テストフォルダの中に テスト用のスクリプトが入っていることになる。 そのままにしていてもいいし、Jythonでその「新しい頂点」の機能を試すための 簡単なサンプルとしてsampleフォルダに移して置いてもいい。
新しいフローレイアウト用の物理法則を追加。今は強さ決めうちの方向も上下決めうちだけど、手で書いたちっちゃいツリーはちゃんと整形された。明日はもっと大きいツリーや、合流のある例、ループのある例を作ってテストだ。
