忍法ミカン隠れの術! これで後はにぎやかフルーツどもが勝手に当たるのを待つだけ。 必勝だぜ って、ミカンより先にめぐり姫様に当たるし… めぐり姫様もう少しダイエットを。

ぐはっ 3点ってたしかに点数っぽく見えるww IMEが「三点」にしてくれないから…って漢数字でも点数にみえるか。 文字数制限きつくてとにかく短く書くことしか考えてなかった すまんorz

今回もおもしろいな！ みかんがこんなに頼もしいなんて。 みかんの逆のほうがビックリだけど…なかなか難しい問題だと思う。 今の操作法だと、操作は楽だが、みかんを当てようとすると敵に向かっていかないといけないので、勇気が必要。 逆の操作法だと、操作は大変だが、敵から逃げていれば勝手にみかんが当たる。 ゼルダをイメージしてるようだし、 今の操作方法に変更になったのは「勇気をもって前に進め」的なめぐりメッセージが含まれているのではないだろうか。

あれ。文字と絵と同時に投稿はできないのか。せっかく書いたのに…。 長さの計測とか、電圧の測定みたいに、「大きくなる誤差」も「小さくなる誤差」も同じような確率で起きるような計測だと、↑の右絵みたいに、「ガウス」分布になる。左右対称で正しい値は真ん中。たくさん測定して平均求めると正しい値が出る。 ベンチマークなんかは、「実行に最低限必要な時間」は決まっていて、それに「割り込み等にかかる時間」が加わるので、左絵みたいに、左右非対称の「冪っぽい」グラフになる。 平均は最頻よりも大きい側にあって、たまに遅い値がでちゃうから、収束が悪い。 最速と最頻はすぐ隣にあるので、最速を見ると誤差が少なく収束が速い。

おちゃめ氏が「最速より速い値に…」っていうのはこれのことだろうと思うが…問題にならない。 おちゃめ氏もやってるように、「命令の実行時間」を測る時には「空ループの実行時間」を引いて求めることになる。 「空ループ」も「命令を含めたループ」も、同じように「最速」で見れば、 それぞれの計測時間が最大489usec短く出てしまっても引き算するので消える。

3DSで音関係は内部のDSPが処理してる。 サンプリングされた音のデータはDSPからCPUにバッファをかまして少しずつ送られてきてる。 負荷を減らすために、サンプリングのたびに送るんじゃなくて、16点程度をまとめてからCPUに送るような仕組みになってる。 DSPのサンプリングは32728HzでCPUと全然違うし、バッファで一度蓄えられたりするので、 MICPOSで時間を計る場合、この「まとめて送る」のが精度を決めてて、16/32727=488.9usec程度になる。 タイミングによってはバッファにたまってる分を数えちゃうので、最大488.9usec、平均249usec短く数えてしまう。

最悪ケースでも長くならないようなキューとか割り込みとかの技術はちょっと前まで一大研究分野になってたと思う。 そういうの使うと平均でもある程度はでるんだけど、最悪を気にするならきちんと分布でみたほうがいい。 べき遅延問題は最近だとネットワークや並列コンピューティングで問題になってて。 ネットワークは正常なのに永遠に返事が来ないなんて最悪ケースもある。 プチコンみたいなブラックボックスの場合。 個々の命令の速度の測定は最速のパターンで調べて、それを組み合わせて最速のアルゴリズムにする。 そのアルゴリズムの実際の速度は、実際に組んでみて実行時間の度数分布をみる。 最悪ケースを対処したいなら度数分布から統計的に許せる速度を推計して使う。 ってのが王道かな。

「ですわよね」 お嬢様の語尾がむりあるよ まぁ表現の自由とかめぐり先生の自由に比べたらどうでもいいんじゃないかね たこわさい食べたいけど

まぐろのさしみはあったがたこわさは無かった。 表示法違反だ からっぽも見つけた これまた終わりないパターン？

5/1 7:14現在、ハカセの公開キー倉庫 共感数109 すごいよね。さすが公式。さすが公開キー倉庫。 ではここで、ヒライ氏のアルカナストーンを見てみようね。 共感数143 大切なことなのでもう一度。 共感数143

いや使いまくりだろ。 プログラムしてるとあれもしたいこれもしたいってなってくるんだよ。 で、そうすると大抵メモリか速度かどっちかが足りなくなる。 おちゃめ氏の言うように根本的にはアルゴリズムなおして対応するんだが、無理な場合もある。 そういうときは限界までチューニングするんだよ。 BadAppleも、旧3DS対応のために限界までいろいろやったぜ？ 最終的にいろいろあきらめたけども。

全然理解してない…orz ループが少ないほうが誤差が大きいというのはガウスや正規分布の場合なんだってば。 数学的に正しいなら現実でも正しいし。 まぁ俺の説明能力の限界もあるし、ここはそういう説明するのに適した場所でもないし、仕方ないね。 とりあえず、俺の方法で計った結果はこんな感じ。 A=1 241.6 +- 1.5 nsec A=B 276.1 +- 2.4 nsec A=B/5 367.1 +- 3.0 nsec A=B*5 443.1 +- 4.2nsec 割り算の方が早いのは変わらん。

おちゃめ氏の言う、「平均に近い数字」というのから、きちんと「最速の値」が出る。 少なくとも「たくさん測ると一定の値になる」数字が出る。 分布から逆に計算すれば、「最速の値」ですら出せる。 ところが、「平均」を使ってしまうと、たくさん測っても一定の値にならない。 割り込み等の間隔よりも十分に長い間隔で測定すれば冪分布にからずれるので、 平均もある程度収束するようにはなるが、とても長い時間が必要になる。

そこで別の手法を使う。いろいろあるけど、たとえば「最速」を選ぶ方法。 最速は割り込み等遅延の影響がなかったとき。 「100回実行」したときに一回も割り込みが起きないのはめったにないかもしれないが、少ないことはある。 たくさん繰り返せば、必ず収束する。 「100回実行」を10000回やって最速を求める、というのも 「100回実行」を100回やって最速を求める、というのを100回やって最速を求めても、大体同じになる。 さらに、そこから、 「n回実行」をm回やって最速を求めた時の結果を予知できる。 これが重要。 n=1にすれば 「1回実行」した時の最速が求まる。

よくあるガウスや正規分布の場合なら、 「10000回実行にかかった時間/10000」のバラツキは 「100回実行にかかった時間/100」のバラツキの1/10になるんよ。 だから、たくさん測れば測るほど、バラツキが減る。 ところが冪分布だと、「たまたまたくさん割り込みはいっちゃった回」の影響が大きくて、たくさん測ってもバラツキが減らない。 （たくさん測ると「たまたま」が入る確率が上がって、その結果バラツキが小さくならない。） 100回実行の結果を3つ比較した時、10000回実行の結果を3つ比較した時で、差があまりなくなってしまうということ。 それでこの手のベンチを平均で処理してるとみんなおちゃめ氏のように「バラツキが大きい」ということになる。

んー…。なんというか、ぶっちゃけ、その理解が間違ってるんだよ。 だから必要以上に「平均」にこだわってるんだと思うんだけど。 ここで説明すんの大変だし別に間違ってても悪いわけじゃないでまぁいいかとも思ったが 仕事したくないから説明してみるかね。 ある命令1個実行するのに、最低限必要な時間をA秒とするでしょ。 実際にはその命令の最中に割り込みが入ったり、中でキューイングされたりして遅くなる。 割り込みはいくつもあるし、時間もいろいろだけど、とりあえず独立で確率p、時間はB秒とすると。 A秒で終わる場合（たくさん）、A+B秒で終わる場合（確率p）、A+2B秒で終わる場合(p^2)… となって、頻度分布とったら冪分布になる。 実際には割り込みの最中にも割り込み入るんで、もっと裾野広い分布になる。 続く。

「冪分布だ」って話を聞いても「これが正解に最も近い」と思うんならまぁそれでも。 命令の実行速度は重要だけど必要な時に調べればいいだけなんで貴重な公開キー一つつぶしてまでコード出すほどは興味ないかな 俺の言ってるのは最速を求めるだけなんで平均より簡単だし。

だからさ。 こうしたほうがより「良い値」がでるんじゃね？って言っているだけで、十分でないなんて言ってないぜ？ 結論を否定しているわけでもないし。 ズレがあるのももう散々話してるし、わかりきったことだし。 世界にはたくさんの人がいて、いろいろなことしてるからね。 その「精一杯」っていうのが、「平均」を前提に考えるからであって、分布を考えれば「より良い値」を出せるっていう話、そういう方法が既出だよっていう話をしているんよ。 まぁそれを「上辺だけの知識」と思うのならそれでもいいけども。

数値微分っつーのもあるんでそういうの興味あるならぜひ。 微分後の式は出せないけど、グラフを描くことはできて、ゲームでも利用されてる。 グラフ描くのが面倒なんだよね 一つ作っておけばちょっと数式見るときに楽かと思って俺も数式表示するプログラム作ってみたことあるんだけどグラフが面倒で。