谈谈随机数的使用

在日常开发中,伪随机函数几乎是必不可少的一个函数。

大部分我们在使用这个函数时,就自然而然拿来用了,很少去思考用的对不对,反正他是随机的,并且也很难去验证(需要各种大量数据统计)。

所以即使概率看起来不太对,也可以安慰自己说,其实是统计的数据量不够。但有时候真的是因为我们误用了随机函数。

在《计算机程序设计艺术》卷2中,详细介绍了线性同余序列的生成算法。
下面就以线性同余算法为例,来分析一下,为什么随机函数还有可能被误用,他原本不就是随机的么?

在游戏开发中,一般都会设计有开宝箱环节,假设每个宝箱每次开出A的概率是30%,开出B的概率是70%,宝箱可以重复开。

我们的代码可能会这么写

    int open_box(box *b)
    {
        int n = rand() % 1000;

        return  n < 300 ? b->a : b->b;
    }

是的,这段代码就是开宝箱存在“垫刀”的根本原因。

我们来看一下线性同余(LCG)伪随机算法的定义:

Nj+1 = (A*Nj + B) (mod M)(j, j+1为下标)

其中A,B,M为线性同余序列生成常数。

LCG周期为M,A,B,M的关系限定如下:

  1. B,M互质
  2. M的所有质因子都能整除A-1
  3. 若M是4的倍数,则A-1 也是
  4. A, B, N0都比M小
  5. A,B是正整数

通俗点来讲就是,线性同余生成的[0,M)个数在统计学意义上,是等概率出现的。也就是说在足够多次随机以后,他们出现的次数是相同的。

咋一看,感觉上面的代码好像没啥问题。因为[0,M)是等概率出现的,因此rand()%1000之后的值,也是等概率出现的。

但是!我们忽略了一个事实,这段代码意味着。所有人的所有宝箱(甚至还有其他系统)共用了一个伪随机序列。

假设rand()%1000的伪随机序列是这样的:

900,1,300, 500, 299, 785, 556 …

我们来模拟一下多个宝箱交替打开的行为:

开宝箱1,rand()%1000返回的是900, 因此开出来的是B

开宝箱2,rand()%1000返回的是1, 因此开出来的是A

开宝箱1,rand()%1000返回的是300, 因此开出来的是B

开宝箱1,rand()%1000返回的是500, 因此开出来的是B

开宝箱2, rand()%1000返回的是299, 因此开出来的是A

如果宝箱1和宝箱2一直在以类似的顺序交替打开。即使开再多次,你也很难拍着胸脯说,宝箱1和宝箱2开出来的A,B概率分布是符合预期的。

毕竟你亲口告诉玩家,每个宝箱都有30%的概率开出来的是A,但是宝箱1却从来开不出A。

事情之所以会演变成这样。根本原因是,除了有一个伪随机序列之外,还有一个真随机事件,即玩家开宝箱的时机选择。

用软件工程的话来说,宝箱1和宝箱2通过一个全局变量(同一个线性同余序列)耦合在一起了,他们不是正交的。因此,开一个宝箱势必会影响另一个,所以它必然是错的。

还有很多类似的情况,比如一个技能的触发概率。我们本来告诉玩家的是每个技能以某种特定的概率触发,但是我们很可能做成了,以某种概率释放了某个技能。

在我们用随机函数之前,一定要先问问自己,所有使用rand()函数的地方其实是共用了同一个伪随机序列,这样真的没问题么?


2021/11/16补充:

经过这一年多来的观察, 除了"垫刀"的问题之外, 我们还习惯使用如1000, 10000之类的数字来代替100%的概率. 这就会产生一个现象, 就是1000或10000很可能和LCG公式中的M是有公约数的, 这会导致LCG的周期缩短, 其影响远大于"垫刀"产生的不良影响。在我们将接近1000或10000的质数作为100%概率的代表时,随机数的分布有明显改善。

发表评论

+ twenty one = twenty eight