XorShiftによる乱数生成関数と速度の比較。 DEE3D4 XorShiftは32ビットと128ビット。 どちらも100000回で数百フレーム。 標準の乱数生成関数RNDは50程度。 標準の早い！ 乱数の優劣は調べてないが、XorShiftで速度が叶わないなら自前で作るメリットはかなり少ないっぽい。

Xorshiftは周期の長さや乱数の質は線形合同法よりも優れていますが、速度やリストの長さはそれほど優れているわけではないです。 私が作った疑似乱数ルーチンならば100万回で150フレームくらいなのででXorshiftよりも圧倒的に速いし短いです。（RND関数でシードが使えるプチコン3号では無意味だけど）

とりあえず結論的にはプチコン３号のRND関数で問題なさそうってことかな？　あるものが使えるのならとりあえずそれでOKですね。（興味としては存在しますが）

本当に大丈夫なのか、もうちょっと検証してみたいんですが… プチコンのアルゴリズムがわからないので プチコン上で検定しないといけなくて… 重くてやってられない！

でも精度が高いのであれば、すごろく的なやつやスロットなど、乱数の質が影響するケースでは有用かもしれないですね。 要は使い分けかな…。頑張ってください〜。

報告。 乱数そのもののチェックはまだおわってないけどRND(x)の実装は問題ありですね 例えばこんなの M=1879048192:C1=0:C2=0 FOR I=1 TO 10000 R=RND(M) IF A<M/2 THEN INC C1 ELSE INC C2 NEXT PRINT STR$(C1)+" "+STR$(C2) 大きい乱数を作って半分より大きいものと小さいものの個数を数えるだけ。 半分だから当然同じくらいの数になるはずだけど…

これは乱数を最大値でそろえるときにMODULOを使っているからですね。 よくあるダメな手法。 回避方法は2の累乗など2^32を割り切れる数値しかつかわないこと。RND(256)とかRND(1024)とか。 X=RND(400):Y=RND(200) みたいな乱数発生は厳密にはちょっとまずい