けいさんへ 平均と一言でいっても相加平均、相乗平均など様々なものがありますが、今回の場合は実際の実行速度がどれくらいなのかという目安が分かれば良いため相加平均（算術平均）で問題ないと判断しました。 もちろん、判断を下すためには自作のTIMER関数の性質も把握する必要があるし、今回サイト上で結果を正式公開するにあたり「平均をとって問題ないのか」というのを十分な検証をするため3週間に渡り数千回の計測を行いました。 本来ならば平均値ではなく最頻値にすべきですが、（最頻値を採用するならば計測回数が10回では全然足らないのでこれは妥協策とはいえ）検証によって平均値と最頻値とはほとんど差異はないことが分かっているため問題はないです。 そして、れいさんが危惧しているようなとんでもなく大きなバラツキは1度も発生しませんでした。 （↓続く）

れいさんへ 「数学的に正しくても現実的には正しくない」というのはプチコン3号に処理に依存せず厳密に等間隔で刻めるタイマーがあったられいさんの考えたものを作ることができるけど現実的にはMAINCNTもMICPOSも厳密な意味での等間隔ではないためです。（MICPOSを使っている私の自作TIMER関数も同じ） したがって、そのやり方は最速値としては正しくありません。（最速値よりも速い値に収束する） 単に「バラツキの少ない値が欲しい」というだけであればれいさんの方法がベターですが、れいさんが求めている「最速」というのはそのレベルで考えていたのでしょうか？

コータさんへ 結局誤差を含んでいる値には代わりがないのでループ回数を減らせば誤差に左右されるため真の値からはどんどんずれていきます。（数学的には正しくても現実的には正しくない）

コータさんへ 正確に数字が出る場合は平均に踊らされないということが重要ですが、ループ回数を減らしてしまえば時間計測の誤差の方が大きくなるため今回の件に関しては無意味なんですよね。 れいさんは時間計測の誤差に関しては全く触れておらず、失礼ですがこの辺の認識が甘すぎると思いました。

れいさんへ 私が言いたいのはそれが実現可能なのか上辺のみの知識ではなく形にして欲しいということです。 そしてループ回数が少なくなるほど計測誤差が大きくなります。 プチコンの処理に依存しない正確な時間を計るカウンターがない限りは絵に描いた餅の状態です。 実際に美味しく食べている餅を目の前に「こちらの絵に描いている餅の方が美味いぞ」といわれても「それがどうした？」というのが本音です。 今回の結果がそれによって覆るというのならば話は別ですが、そういう趣旨でも無さそうなのでれいさんがここで一体何をしたいのかも分かりません。 ゲームを作ったこともない人が（制作者が十分満足しているのに）「このゲームはこうしたら面白くなる」とその人のトピで延々に語っているのと何ら変わらない気がします。

少し勘違いされていますが、例えば10秒間に1000万回実行できたとしてその1000万回のうちの最速を表示することは簡単なことではないですよ？ 10秒間の実行回数を10回測定してその中の最速というのはすでに最速ではなく「平均に近い数字」になっています。それならば、最初から「平均」として提示した方が分かりやすいでしょう。 個人的には「紛い物の最速」なんて要らないです。

その分布さえも正確に出せず、分布からどのように結論を導くかも人それぞれに分かれてしまうというのが個人的には難点に思います。 今回の結果では「乗算が除算より遅い」とか「INC AがA=A+1より遅い」と言っても「どれくらい遅いのか」というのが気になる部分だと思うのでその目安として提示しているにすぎません。 個人的にはこれが「正解に最も近い」と感じていますが、これが万人にとって正解というわけではなくれいさんにはれいさんの正解があることでしょう。 ならば、ここであれこれ言う間に自分にとって正解を「形」にする方がベターではないでしょうか？

そもそも、1ナノ秒単位になると回数をカウントする処理でさえ誤差の問題が発生します。 実際このレベルになるとFOR～NEXTのループでさえ回数と時間は比例関係にはありません。（500万回ループは100万回ループのちょうど5倍の時間ではない） プチコンの処理に依存しない正確なカウント方法がない限りは概ね正確な値を求めるのが精一杯です。 というか、今回書いたものは「ver.3.1.0はこういう傾向にある」というだけの話なのでそれを説明するには十分な精度で計測できていると私は思います。 上辺だけの知識よりも実際にどうなのかが重要です。

誤差の問題はループ回数である程度カバーできます。 したがって、8秒という時間制限がある以上は旧3DSよりもNew3DSの方がより正確な結果（安定した結果）を求めることが可能になります。 今回の結果よりも正確に測定したいのであれば不安定なMAINCNTLではなく内蔵時計を使い10000秒とか100000秒での実行回数を計測すると良いでしょう。（それでも計測誤差を考えると最低でも3回は試行しなくてはならない）

例えば50回や100回に1度しか出ないかもしれない真の値（っぽい値）よりも普通に実行時に出る値の方がよほど現実的ですね。

れいさんへ BASIC上で動作している限り様々な要因が絡んだ上での実行速度なので真の値なんてそもそも測定は不可能です。マシン語のような正確なサイクル数は求められないので遅いときと速いときの平均値がベターだと私は判断します。 平均である以上はある程度の回数をこなせばMICPOS命令の問題は緩和されます。 そもそもMAINCNTLでさえ安定していないため厳密な時間は測定は不可能です。 命令によってループ回数をわざわざ変えなくてもいいですよ。 New3DSならばほぼ500万回ループで実行可能でしたし。 れいさんが理想とする測定プログラムを自分で作ってその結果を報告してください。

長々と書きましたが私のサイトではこれより格段に詳細な計測結果の発表を行っています。 この結果を元にしてより速いプログラムを作れば大幅に高速化されるかというと実際は多重ループの内側でない限りは目立った高速化は難しいかもしれません。 しかも、乗算の速度やINC Aなどはこのバージョンに依存していると思うのでver.3.1.0に最適化するメリットはあまりないと思います。 やはり、高速化はアルゴリズムの改善などで行うべきでしょう。

10　文字列変数の速度 A$=""・・・419ナノ秒 A$=B$・・・426ナノ秒 （B$="1"*100000の場合） A$="1"*2・・・1390ナノ秒 A$="1"*10・・・1694ナノ秒 結果：演算速度は文字数に大きく左右される。ただし、代入処理は文字数の影響はほとんどない。

9　グローバル変数とローカル変数の速度 DEF内グローバル変数 A=1・・・274ナノ秒 A=A+1・・・374ナノ秒 ローカル変数 A=1・・・310ナノ秒 A=A+1・・・366ナノ秒 結果：DEF内は代入処理が遅いので結果としてDEF内では処理速度が遅くなる。 ただし、実際に自作関数が遅くなる要因はDEFそのものが3161ナノ秒かかっていることの方が大きい。

8　複数の演算子が使われている場合の速度 A=1+2・・・339ナノ秒 A=1+2+3・・・627ナノ秒 A=1+2+3+4・・・878ナノ秒 A=1+2+3+4+5・・・1128ナノ秒 結果：定数の加算でも1つ追加するごとに250ナノ秒くらい増になるため代入を減らすため式が複雑化するとかえって遅くなる場合がある。

7（続き） A=B[0]・・・1182ナノ秒 A=SIN(X)　595ナノ秒 A=SIN(RAD(X))　898ナノ秒 配列変数が超遅いため三角関数はあらかじめ計算した結果を配列変数から読み出すより普通に計算した方が速い 三角関数の演算は四則演算と比べるとかなり遅いため配列変数にあらかじめ計算した結果を入れておいてそのテーブルから読み出すという使用方法は昔のBASICではよく使われた。 しかし、三角関数の演算そのものは配列の読み出しより速くRADを使って度に変換しても配列変数の読み出しよりも速い。

7　配列変数の速度 A=A+1・・・345ナノ秒（16387ナノ秒） A[0]=A[0]+1・・・2451ナノ秒（29321ナノ秒） A=A+B（19070ナノ秒） A[B]=A[B]+A[C]（40394ナノ秒） カッコ内はプチコンmkIIの速度 結果：配列変数を使った処理は通常変数より7～10倍も遅い（比率でいえばプチコンmkIIより4倍くらい遅い）

6　変数の文字数による速度の違い A=A+1・・・345ナノ秒 AB=AB+1・・・345ナノ秒 ABC=ABC+1・・・345ナノ秒 ABCD=ABCD+1・・・345ナノ秒 ABCDE=ABCDE+1・・・345ナノ秒 結果：変数名の文字数による処理速度の違いはない これは仮想マシンコードへとあらかじめ変換されている影響と思われる。（注釈や改行による処理速度の影響もない）

5　定数と変数の演算速度の違い A=B+C・・・349ナノ秒 A=B-C・・・354ナノ秒 A=B*C・・・482ナノ秒 A=B/C・・・421ナノ秒 結果：変数の方がわずかに遅いけど乗算のみ定数より変数の方が速くなっている　 それでも乗算は逆数を除算で計算した方が速い。

4　四則演算の速度 A=B+5・・・345ナノ秒 A=B-5・・・343ナノ秒 A=B*5・・・559ナノ秒 A=B/5・・・402ナノ秒 結果：なぜか乗算だけ極端に遅い（ver.3.0.0では乗算は除算よりも速い）