続々々々・アルゴリズム

 
 私的には昨日のはまぁ妥協すべき点かなーと思ってたわけですが
 それは井の中の蛙の見解なのでした。
 
 
 Luciedさんの案
 
 三案目。この機能に素敵な愛称をつけていただいてます。
 ここまでお付き合いいただきありがとうございます。
 
 "再帰関数でできることはループでもできる"
 ということで全部ループの中に突っ込むことで、全ての変数をローカル変数とされています。
 
 
 Mr.tonkatiさんの案 
 
 いったん全ての味方のユニットIDを配列に入れて
 ForEach 味方の二段構造を再現することで処理されています。
 こちらも全てローカル変数。
 
 
 どちらも私の作ったものよりも上を行っているのは間違いないのですが
 せっかくなので雌雄を決すべく勝手に実験してみました。
 
 【計算時間一覧】
 

味方の数だんご (Luciedさん)接触改 (Mr.tonkatiさん)接触旧 (ハク)
20(集合) 260.652789.9199.60
20(10,10)134.201709.6104.35
10(集合) 90.45315.1073.50
10(5,5) 30.95153.9525.35
5(集合) 44.6556.2535.70
5(2,3) 14.2530.5011.25
3(集合) 28.1020.9022.80
3(1,2) 9.0513.807.15
2(集合) 48.2028.6038.90
2(1,1) 35.2525.3028.35

 ・ここでの計算時間は純粋に計算部分だけの時間(呼び出しからReturnまで、Talkは排除済み)です。
 ・それぞれを交互に20回ずつ実行し(だんご、接触改、接触旧、だんご、接触改…)、平均の時間を算出しました。
 ・環境の違いがあるため縦の比較はあまり信用できませんが、横の比較は信用できるかと思います。
 
 接触改の計算回数は味方の数の二乗に比例するため
 数が多い場合は非常に時間がかかりますが、
 数が減ってくると時間がうんと短くなっていきます。
 
 接触旧も割と好タイムをたたき出していますが
 そもそも欠陥があるため(昨日の日記参照)
 数がある程度〜かなり多い場合はだんご、少ない場合は接触改が有利と言えそうです。
 
 
 自分のシナリオで使えるいい方法ないかなーという何気ないボヤキから
 こんなところまで来てしまいました。SRC恐るべし。
 
 このたびはお付き合いいただきありがとうございました。
 私もまだまだだなぁと勉強させていただきました。
 また何かぼやいてたら、お相手していただければ幸いです。
 
  
 ====
 
 変数名を変えたりForを使わない等すればさらにいくらか計算が早くなると思われますが
 今回の比較はそういう小手先の工夫ではなくアルゴリズムそのものの計算時間の比較が目的なので
 既出のアルゴリズムに関してはこの結果で確定とさせていただきたいと思います。
 
 まだ出ていない他の方法を何か考えられたという場合には
 追って比較させていただきますので、遠慮なくお申し出下さい。