RM MV里一些关于随机量的玄学？

灯笼菜刀王

ppspssss 发表于 2020-11-27 11:16
https://rpg.blue/thread-406406-1-1.html
印像中@灯笼菜刀王 老师 說过这个問題

没错,很早以前我就在纠结这个了, 实际上也得到很多人的指导

虽然各种随机方式可以均衡1000次1W次的样本, 然而,实际应用中难免要面对"某个阶段随机实在太接近"这种"很唯心"的结果,笑

其实, 哪怕像福利彩票那样的乒乓球现场摇点都难免出现连续的情况, 觉得"不够随机"也只是小样品范围内的结果而已,如果不想这样,就像你说的, 抽到两个接近的话就再抽一次之类的也是一种方法呗

这也是我采用"先打乱样品顺序,再随机抽一个出来"这种让人家说没太多意义的做法的原因,------"让自己安心点"


---------------
说个故事,  我曾经做了一个"武器破损率"的系统, 攻击敌人的时候有概率让武器损坏,  一开始是直接用 rand(100) < 损坏率 来判定的, 结果测试的时候, 3%的概率,理论上33次才会破损一次的概率, 让某个黑旋风连续破三把....,   于是,把随机样本增加一万倍,重置随机种子,增加随机节点, 更换随机位置........

结果, 那个黑旋风还是一样, 连续坏给你看

因此,我知道了, 这原因根本就不是样本多少, 而是脸

再怎么均衡的随机也扛不住黑旋风例亏或白面郎君整天受

所以, 现在改成了, 不直接消失而是先出现(损坏)的后缀, 然后在损坏判定生效的同时增加一个保护回合, 避免黑得透亮的家伙......

鼠曲草

随机数算法应该不会有那么大的问题吧。。
拿python试了一下，

确实会有一些偏差非常大的情况。可以考虑的方法是用shuffle打乱一个数组然后存储作为备用数。
但是是不是随机没啥需要讨论的。毫无疑问常见的语言都应该有一个设计得还行的随机器。然而随机器一个重要的要求是任意两次抽数的概率几乎是独立的，所以连续抽多个数，里面某个数出现n次的概率几乎是个二项分布。但如果从需求来看二项分布的概率还是太高了。所以如果你要求这种抽到一个数多次的概率很低，一般算法的随机器是没有这个功能要求的。
我想得到的解决方法有两个：
一是按我上面说的，在需要多次抽数时，生成一个长度至少超过你需要的类数的2~3倍的数组，用随机方法打乱数组（具体算法我就不知道了，python有这个函数可以参考），抽数时按顺序抽，用完了在生成。这样连续抽到2~3次以上某个数的概率被严格限制为0（除非你真到了第一个数组用完了又继续用第二个数组的时候有连续抽到4~6个数的概率，那只能说你赢了）。这种方法可以遍历数组，并且不怎么重复。能想到的隐患就是存储的数据可能会被恶意篡改。
二是用其他的特殊的随机算法。比如线性同余法使用迭代来计算下一个概率，你可以想得到，这种迭代算法一定有个周期，并且只有间隔一个周期时两个数才会重复。然而如果你自己写的话很可能会写出极为Naiive的算法，比起调用别人的函数还是差了一点。

SailCat

在早期的红白机直到PS2次世代的主机游戏中，几乎所有的随机数都是通过预置的“随机数表”来实现的

随机数表在FC、SFC上一般体现为一个随机打乱的256长度的表格（也可能更短），它覆盖了00－FF的所有数字，只是顺序有点错乱
一个典型的随机数表例如：
[0xB7, 0x97, 0x3A, 0x46, 0xBA, 0x86, 0x0C, 0xBF, 0xA3, 0xF1, 0xE0, 0x1C, 0x5F, 0x93, 0xF8, 0x94,
0x9F, 0x9A, 0xA1, 0x8E, 0x69, 0xE6, 0x92, 0xA5, 0x8D, 0x47, 0x8C, 0x54, 0x51, 0xEC, 0x79, 0x10,
0x4C, 0x0D, 0x87, 0xCD, 0x56, 0x2F, 0xF0, 0xEE, 0x31, 0xD1, 0x09, 0x8B, 0x07, 0x9C, 0xE4, 0x36,
0xB6, 0x35, 0x4B, 0xF4, 0xAB, 0xC2, 0x11, 0x33, 0xE5, 0x0E, 0x82, 0xC4, 0x55, 0x20, 0xD3, 0x23,
0x85, 0x7F, 0x9D, 0x4E, 0x19, 0x06, 0xB1, 0x39, 0x0A, 0xA2, 0x34, 0xBD, 0xE7, 0x03, 0x02, 0x2E,
0xB0, 0xB4, 0x22, 0xFC, 0x42, 0x4A, 0xE9, 0xDF, 0xC3, 0xBE, 0x2A, 0xDB, 0x62, 0xA0, 0xA6, 0x6F,
0x12, 0x91, 0x98, 0x3E, 0x6C, 0x66, 0xAC, 0xBB, 0xF9, 0x44, 0xF5, 0xC5, 0x27, 0xC9, 0xA8, 0x52,
0xED, 0x14, 0x6D, 0xEB, 0x1B, 0xD4, 0x80, 0x5B, 0xB2, 0x5C, 0x28, 0x4F, 0xDD, 0x99, 0xCB, 0x59,
0xC6, 0xB5, 0x0F, 0x45, 0xE8, 0xD8, 0x2C, 0x24, 0xD7, 0xC7, 0x43, 0x1F, 0x72, 0xEF, 0xE3, 0x5A,
0xD9, 0x2B, 0x96, 0xEA, 0x2D, 0x57, 0x16, 0x70, 0x9E, 0x5D, 0x04, 0x3B, 0x7B, 0x63, 0x5E, 0xA7,
0x1A, 0x17, 0xCC, 0x65, 0x67, 0xFD, 0x7E, 0xDA, 0x15, 0x58, 0x53, 0x38, 0x60, 0x21, 0x6B, 0x7C,
0x40, 0xCA, 0x81, 0x73, 0xC0, 0x41, 0x68, 0xDE, 0x00, 0xAF, 0x08, 0x3F, 0xF2, 0x1E, 0xDC, 0xCE,
0xB8, 0x75, 0x25, 0x05, 0xD5, 0x7A, 0xCF, 0xE2, 0x78, 0x18, 0x30, 0x29, 0x74, 0x32, 0x8A, 0x1D,
0xC8, 0x89, 0xFB, 0xF3, 0xFE, 0xD2, 0xA4, 0x26, 0x3C, 0xAA, 0x77, 0x6E, 0x88, 0xF7, 0x50, 0xB9,
0xA9, 0x13, 0xB3, 0xAD, 0x61, 0x90, 0x64, 0x84, 0x9B, 0x8F, 0xD6, 0x95, 0xE1, 0xFF, 0x83, 0x0B,
0x7D, 0x49, 0x37, 0xFA, 0xD0, 0xF6, 0xC1, 0xAE, 0x3D, 0x6A, 0x71, 0xBC, 0x76, 0x01, 0x48, 0x4D]

因为内存有限，FC上的许多游戏甚至只有几KB的数据量，能用0.25KB来放一个随机数已经很不容易了。因此游戏中的所有机制，但凡调用到随机数，都是从这个表里按指针来获取。
由于表只有一个写死了，FC又没有机内时钟且可以随时reset，就导致了出现了鼎鼎大名的“电源技”——即通过电源reset使得随机数指针回到开头，然后加载你的进度，只要分析汇编拿到内存中的表，并且知道哪些操作会调用随机数，调用几个，所有的随机数都是有章可循的。
FF1（最终幻想1）可以通过这个方法用1/201的机率杀掉最终boss——只要在最终boss前存档，再reset读档后，并且使用特定的攻击方式进行攻击即可。当然这个原因是因为FF1的程序逻辑本身有问题，随机数取到00会通过任何几率判定。

这个用随机数表的做法一直延续到了次世代的PS2，只是随机数表从写死在ROM里逐渐变成按电源即时生成（故此电源技依然一直有效），表也会有不止一个。
到了后来，才逐渐变成了采用随机数种子、即时生成随机数，不再查表的方式。

尽管遍历一个乱数表可以比较大程度的解决连续生成同一个数的问题，但当所需要的随机数并不是处于0-255的范围时，通过位运算进行限格的结果依然无法保证机率平均。
以上表其中一行为例：
0x40, 0xCA, 0x81, 0x73, 0xC0, 0x41, 0x68, 0xDE, 0x00, 0xAF, 0x08, 0x3F, 0xF2, 0x1E, 0xDC, 0xCE
如果需要的随机数只是0-7的范围，即对上面的数全部取&8的处理，结果是
0，2，1，3，0，1，0，6，0，7，0，7，2，6，4，6
可以看到，0出现了很多很多次，而5没有出现。
这种所谓的短期集中情况，其实是无解的，不论你用什么办法，比如空指针（取一个跳一个）或者其他办法，都解决不了，上表的取1跳1结果是
0 1 0 0 0 0 2 4
3 5 6 7都没有，0出现5次，随机个屁

想要解决这个问题，除了按你的取数周期和大小生成shuffle表之外，无任何其他解。但就算是如此，就属于你想要的随机了吗？

要知道，随机，随机，重点在于其不可预知和每件事互相独立的特性。某人抛硬币连续20次正面之后，下一次正面的结果依然是49.97%（反面49.97%，直立0.06%）。但如果生成了一个随机数，你就知道下面100%不会再生成同样的一个数，那这不叫真随机，这叫可以预知。尽管有些反直觉，但确实如此。
但随机数种子+即时生成随机数，内部依然是各种求余、移位和哈希算法，只要知道了种子和算法，所有的序列都是可以推定的，这依然不是真随机，而是伪随机。

为什么几乎所有语言，原生随机数都是0-1之间的数，且含0不含1？
原因是，随机数的哈希算法实际上是都是位运算，比如16位的哈希结果会在0b0000000000000000到0b1111111111111111（0~65535）之间。
但是第一，65535这个数字只有1、3、15、17、255、257、3855、4369、21845这9个约数，它不能被大多数你想要的随机范围整除。如果你用求余来进行随机范围处理，是没有办法保证机率均匀的（例如余以100，那0－35的机率会显著比36－99来得大）。
第二，0b1111111111111111不一定会被解释为65535，也可以是-1，而负数随机数对于大多数机率判定就是灾难了。
因此，语言的做法就是将其转换为浮点数，而根据大多数CPU的解释，这只需要解释为在最前面加一个小数点就行。
而在最前面加一个小数点，其结果就成了0b0.0000000000000000到0b0.1111111111111111之间。
前者是0.0，后者是多少呢，准确来说是0.9999847412109375。
由于所有浮点数乘法的原生取整算法都是向下取整，而后面这个数乘以50000之后依然高达49999.2，因此，16位浮点伪随机数在值域范围内，已经足以应付1~50000中任何一个机率区间的（长期均匀）随机性。

waywjwoy

我一般随机1~10都是判定采用的5（中间数）为中奖结果，因为3以下，6以上出现的概率极大，越是中间的数出现的概率就越小，MV的判定数值有点问题