「T-/Random」の編集履歴（バックアップ）一覧はこちら
T-/Random - (2013/03/10 (日) 12:59:12) の最新版との変更点
追加された行は緑色になります。
削除された行は赤色になります。
戻る→[[トリガー情報の一覧]]
----
:※解説修正情報※|
●&font(12,b){2013-03-10：乱数の偏りについての記述・再度}
●&font(12,b){2013-03-09：乱数の偏りについての記述}
//●&font(12,b){日付：修正部分の概要}
----
//ほかページヘのリンクはLv0のみで。（Lv1～でリンクしようとすると煩雑になりそうなので）
*■Random【乱数】
:▼概要|
ランダムな数値を返す。
:▼情報・書式|
&b(){Random} ;Int型
-0～999の整数のどれかを無作為に返す。
-フレームごと・記述ごとにその都度ランダムな数値を返す。
--「Random=0」と「Random=Random」は計算上1/1000の確率で同じ。
----
**■Lv1-記述例・補足・注意点
:記述例|
[State 191, random intro]
Type = ChangeState
Trigger1 = !Time && Random < 200
Value = 194
-1000分の200の確率で194へChangeStateを行う。
:補足|
-基本的に「Random < xxx」といった方法で使う。
--「Random < 500」は毎フレーム50%。
-「( Random % 2 ) = 0」といった記述もある。%2=0で、1/2。
--上書き無しなら(Random%5)=0→(Random%4)=0→(Random%3)=0→(Random%2)=0→1&br()という確率記述で５個全てを約1/5の確率にできる。
--上書き有りの場合は1→(Random%2)=0→(Random%3)=0の順で良い、はず。
:注意点|
-Randomは記述毎で個別に乱数を返すため、&br()ランダムで処理の分岐させたい場合はVarに代入したりする必要がある。
--一律Random<500で処理を切り替えようとしようものなら、&br()全てごちゃごちゃに処理され、おかしなことになる。
--上記記述例同様、条件でChangeStateするなり、VarSetをしてVar()で対応するなりが必要。
-確率の条件式は、毎フレーム確率を判定するため長時間に渡って考えると確率は上がる。
--「Random < 500」は毎フレーム50%だが10F中1回でも当たればいいなら確率は99.9%に達する。
---50%→50%＋残りの1/2で75%→75%＋残りの1/2で87.5%→＋残りの1/2で93.75%→96.875%→…中略→99.90234…%
--「Random < 100」でも毎フレーム10%なので、10F中1回でもいいならなら約65%程度の確率になる。
:偏り|
-0～999の数値は、無視できる程度ではあるが偏りが存在する。[[外部・調査ファイル>http://www1.axfc.net/uploader/Sc/so/379370&key=random]]
-それぞれの数値が出る確率は0.1%だが、0.1007...%と0.0976...%で分かれているとの報告。
--分岐点は「''768前後''」（おそらく、767以下：768以上の分岐？）
-とはいえ、0.00X%程度の誤差であるため気にする必要はないかと。
-一応( Random % 100 )や( Random % 10 )などで使う数値を減らせばと偏りは限りなく少なくなる。
-偏りの原因
--乱数は基本15bit管理？で「0～''32767''」の数値から0～999の数値を作っているみたい。
--15bit最大値を1000で割った余り下三桁、''767''までが僅かに確率が高くなっているみたい？
--もしかしたら：マイナス含む16bitでマイナス値反転処理での処理かも
-数式(※Google電卓推奨)：推測する確率の偏り（16bitで反転含む場合も大差無し？）
--&nowiki(){ ( (1/( 2**15 -1 ) ) * 32 ) }=0.0009765923 ： 1/32767 * (32)の数値（1000で割れる最大整数）
--&nowiki(){ ( (1/( 2**15 -1 ) ) * 33 ) }=0.00100711081 ： 1/32767 * (32+1)の数値（+1は下三桁767の分）
--&nowiki(){ ( ( (1/( 2**15 -1) ) * 33 )*(767) + ( (1/( 2**15-1 ) ) * 32 )*(1000-767) }=1
--計算上、切りよく一番影響の大きい「Random<750（＝3/4）」が「約73.2%」になる程度のズレ。
:AI制作時の注意点|
-Randomの確率でAIの動作を制限する際はRandom<100でも全体がその程度なら確率はそこまで低くない。
--「Random < 500」以上の確率であればほぼ確実と思って良い程度。
--Random<100の行動でも5個書いてあれば、2F中に行動する確率は約65%。10Fもあればほぼ確実。
-ただ猶予の短いコンボなどであれば、そこまで確率は上がらない。
//----
//**■Lv2-細かいバグ回避
//注意点で書いたことを回避したい場合用。
//#endregion
//----
//#region(■Lv3-細かい応用)
//**■Lv3-細かい応用
//他の記述と組み合わせて使用する関係。
//#endregion
//----
//#region(■Lv4-バグ利用)
//**■Lv-4-バグ応用
//あやしい仕様を活用する関係。
//#endregion
//----
//**コメント
//細かい話し合い・確認が必要な場合に開放しましょう。
//#comment()
----
戻る→[[トリガー情報の一覧]]
----
:※解説修正情報※|
●&font(12,b){2013-03-13：乱数の偏りについてのRandom<750のこと削除}
●&font(12,b){2013-03-10：乱数の偏りについての記述・再度}
●&font(12,b){2013-03-09：乱数の偏りについての記述}
//●&font(12,b){日付：修正部分の概要}
----
//ほかページヘのリンクはLv0のみで。（Lv1～でリンクしようとすると煩雑になりそうなので）
*■Random【乱数】
:▼概要|
ランダムな数値を返す。
:▼情報・書式|
&b(){Random} ;Int型
-0～999の整数のどれかを無作為に返す。
-フレームごと・記述ごとにその都度ランダムな数値を返す。
--「Random=0」と「Random=Random」は計算上1/1000の確率で同じ。
----
**■Lv1-記述例・補足・注意点
:記述例|
[State 191, random intro]
Type = ChangeState
Trigger1 = !Time && Random < 200
Value = 194
-1000分の200の確率で194へChangeStateを行う。
:補足|
-基本的に「Random < xxx」といった方法で使う。
--「Random < 500」は毎フレーム50%。
-「( Random % 2 ) = 0」といった記述もある。%2=0で、1/2。
--上書き無しなら(Random%5)=0→(Random%4)=0→(Random%3)=0→(Random%2)=0→1&br()という確率記述で５個全てを約1/5の確率にできる。
--上書き有りの場合は1→(Random%2)=0→(Random%3)=0の順で良い、はず。
:注意点|
-Randomは記述毎で個別に乱数を返すため、&br()ランダムで処理の分岐させたい場合はVarに代入したりする必要がある。
--一律Random<500で処理を切り替えようとしようものなら、&br()全てごちゃごちゃに処理され、おかしなことになる。
--上記記述例同様、条件でChangeStateするなり、VarSetをしてVar()で対応するなりが必要。
-確率の条件式は、毎フレーム確率を判定するため長時間に渡って考えると確率は上がる。
--「Random < 500」は毎フレーム50%だが10F中1回でも当たればいいなら確率は99.9%に達する。
---50%→50%＋残りの1/2で75%→75%＋残りの1/2で87.5%→&br()→＋残りの1/2で93.75%→96.875%→…中略→99.90234…%
--「Random < 100」でも毎フレーム10%なので、10F中1回でもいいならなら約65%程度の確率になる。
:偏り|
-0～999の数値は、無視できる程度ではあるが偏りが存在する。
//リンク切れ:[[外部・調査ファイル>http://www1.axfc.net/uploader/Sc/so/379370&key=random]]
-それぞれの数値が出る確率は0.1%だが、0.1007...%と0.0976...%で分かれているとの報告。
--分岐点は「''768前後''」（おそらく、767以下：768以上の分岐？）
-とはいえ、0.00X%程度の誤差であるため気にする必要はないかと。
-一応( Random % 100 )や( Random % 10 )などで使う数値を減らせばと偏りは限りなく少なくなる。
-偏りの原因
--乱数は基本15bit管理？で「0～''32767''」の数値から0～999の数値を作っているみたい。
--15bit最大値を1000で割った余り下三桁、''767''までが僅かに確率が高くなっているみたい？
--もしかしたら：マイナス含む16bitでマイナス値反転処理での処理かも
-数式(※Google電卓推奨)：推測する確率の偏り（16bitで反転含む場合も大差無し？）
--&nowiki(){ ( (1/( 2**15 -1 ) ) * 32 ) }=0.0009765923 ： 1/32767 * (32)の数値（1000で割れる最大整数）
--&nowiki(){ ( (1/( 2**15 -1 ) ) * 33 ) }=0.00100711081 ： 1/32767 * (32+1)の数値（+1は下三桁767の分）
--&nowiki(){ ( ( (1/( 2**15 -1) ) * 33 )*(767) + ( (1/( 2**15-1 ) ) * 32 )*(1000-767) }=1
:AI制作時の注意点|
-Randomの確率でAIの動作を制限する際はRandom<100でも全体がその程度なら確率はそこまで低くない。
--「Random < 500」以上の確率であればほぼ確実と思って良い程度。
--Random<100の行動でも5個書いてあれば、2F中に行動する確率は約65%。10Fもあればほぼ確実。
-ただ猶予の短いコンボなどであれば、そこまで確率は上がらない。
//----
//**■Lv2-細かいバグ回避
//注意点で書いたことを回避したい場合用。
//#endregion
//----
//#region(■Lv3-細かい応用)
//**■Lv3-細かい応用
//他の記述と組み合わせて使用する関係。
//#endregion
//----
//#region(■Lv4-バグ利用)
//**■Lv-4-バグ応用
//あやしい仕様を活用する関係。
//#endregion
//----
//**コメント
//細かい話し合い・確認が必要な場合に開放しましょう。
//#comment()
----
