我写了一个小代码,以确保可以从很大范围(例如)获得随机数。 [0,10 ^ 36),因为稍后我将使用这些广泛的范围。

我的代码如下:

#include <iostream>
#include <cmath>
#include <random>
#include <chrono>

int main()
{   unsigned seed = std::chrono::system_clock::now().time_since_epoch().count();
    double expo = pow(10,36);
    std::uniform_real_distribution<double> dist(0,expo);
    std::mt19937_64 rng(seed);
    for (int i=0; i<10; i++)
        std::cout << dist(rng) << std::endl;
    return 0;
}

以下是输出示例:
6.75507e+035
4.01129e+035
6.85525e+035
8.85896e+035
3.1455e+035
3.04962e+035
5.48817e+035
3.54502e+035
2.24337e+035
2.23367e+035

如您所见,随机数实际上都非常接近给定间隔的上限。我尝试多次运行该程序,也将10的数字增加到100,但是随机数始终接近区间的上限(指数为35,有时为34)。

由于我使用了std::uniform_real_distribution,因此我希望有时也会有[0,1000]范围内的数字。我发现这不是一个统一的分布。这对我很重要,因为随机数不仅靠近上限端点,因为我稍后将在if语句中使用随机数:
if (random_number == 0)
    //do some operations

上限实际上将用作发生某种情况的比率。但是似乎随机数有时没有机会为零。

我不知道为什么会这样,真的很感谢任何想法或帮助。

(Eclipse 4.4.1,Windows 7)

最佳答案



不,他们不是。以这个为例:

2.23367e+035

请注意,在[0, 1e36]范围内,子范围[1e35, 1e36]是子范围[0, 1e35]的9倍,因此,如果分布均匀,则可以看到这些数字的频率是9倍。您会不时看到指数为34的数字,但是指数较低的数字将变得极为罕见。

10-07 19:12
查看更多