我写了一个小代码,以确保可以从很大范围(例如)获得随机数。 [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的数字,但是指数较低的数字将变得极为罕见。