blocks|key|910671|text|我不知道哪里出了问题(还不知道！)，但您仍然可以按如下方式按时间进行初始化，而不会碰到问题(从这里借来的)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|910672|#include+<ctime>
#include+<iostream>
#include+<random>
#include+<chrono>

using+namespace+std;

unsigned+seed1+=+std::chrono::system_clock::now().time_since_epoch().count();

default_random_engine+gen(seed1);+//gen(time(NULL));
uniform_int_distribution<int>+dist(10,200);

int+main()
{
++++for(int+i+=+0;+i+<+5;+i%2B%2B)
++++++++cout<<dist(gen)<<endl;

++++return+0;
}|code-block|syntax|javascript|910673|您也可以使用随机设备，这是不确定的(它从您的键笔画，鼠标移动和其他来源的时间信息，以产生不可预测的数字)。这是你可以选择的最强大的种子，但如果你不需要强有力的保证，计算机时钟是更好的选择，因为如果你经常使用它，计算机就会没有“随机性”(生成一个真正的随机数需要很多键击和鼠标移动)。|910674|std::random_device+rd;
default_random_engine+gen(rd());|910675|正在运行|910676|cout<<time(NULL)<<endl;
cout<<std::chrono::system_clock::now().time_since_epoch().count()<<endl;
cout<<rd()<<endl;|910677|在我的机器上生成|910678|1413844318
1413844318131372773
3523898368|910679|因此，chrono库提供了比ctime库更大的数量和更快的变化数(以纳秒为单位)。random_device正在产生不确定的数字，在地图上到处都是.因此，似乎ctime正在生产的种子可能在某种程度上过于接近，从而部分映射到相同的内部状态？|style|CODE|910680|我做了另一个程序，看起来是这样的：|910681|#include+<iostream>
#include+<random>
using+namespace+std;

int+main(){
++int+oldval+++++++++++=+-1;
++unsigned+int+oldseed+=+-1;

++cout<<"Seed\tValue\tSeed+Difference"<<endl;
++for(unsigned+int+seed=0;seed<time(NULL);seed%2B%2B){
++++default_random_engine+gen(seed);
++++uniform_int_distribution<int>+dist(10,200);
++++int+val+=+dist(gen);
++++if(val!=oldval){
++++++cout<<seed<<"\t"<<val<<"\t"<<(seed-oldseed)<<endl;
++++++oldval++=+val;
++++++oldseed+=+seed;
++++}
++}
}|910682|正如您所看到的，这只是输出到当前时间为止的每个可能的随机种子的第一个输出值，以及具有相同值的种子和先前种子的数量。输出的摘录如下：|910683|Seed++Value+Seed+Difference
0+10++1
669+11++669
1338++12++669
2007++13++669
2676++14++669
3345++15++669
4014++16++669
4683++17++669
5352++18++669
6021++19++669
6690++20++669
7359++21++669
8028++22++669
8697++23++669
9366++24++669
10035+25++669
10704+26++669
11373+27++669
12042+28++669
12711+29++669
13380+30++669
14049+31++669|910684|因此，对于每一个新的第一个数，就有669个种子给出了第一个数。因为第二数和第三数是不同的，所以我们仍然产生唯一的内部状态。我认为我们必须对default_random_engine有更多的了解，才能理解669的特殊之处(这可以被考虑到3和223中)。|910685|考虑到这一点，chrono和random_device库为什么运行得更好是很清楚的:它们生成的种子之间的距离总是超过669。请记住，即使第一个数字是相同的，在许多程序中，重要的是由不同的数字生成的序列。|910686|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cplusplus.com/reference/random/linear_congruential_engine/linear_congruential_engine/^0|1B|2|0|0|0|0|0|0|0|0|0|3|6|E|5|15|D|27|5|0|0|0|0|0|1X|L|0|7|6|E|D|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@$A|1J|B|1K|1|1L]]|C|$]]|$1|D|3|E|5|F|7|1M|8|@]|9|@]|C|$G|H]]|$1|I|3|J|5|6|7|1N|8|@]|9|@]|C|$]]|$1|K|3|L|5|F|7|1O|8|@]|9|@]|C|$G|H]]|$1|M|3|N|5|6|7|1P|8|@]|9|@]|C|$]]|$1|O|3|P|5|F|7|1Q|8|@]|9|@]|C|$G|H]]|$1|Q|3|R|5|6|7|1R|8|@]|9|@]|C|$]]|$1|S|3|T|5|F|7|1S|8|@]|9|@]|C|$G|H]]|$1|U|3|V|5|6|7|1T|8|@$A|1U|B|1V|W|X]|$A|1W|B|1X|W|X]|$A|1Y|B|1Z|W|X]|$A|20|B|21|W|X]]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|22|8|@]|9|@]|C|$]]|$1|10|3|11|5|F|7|23|8|@]|9|@]|C|$G|H]]|$1|12|3|13|5|6|7|24|8|@]|9|@]|C|$]]|$1|14|3|15|5|F|7|25|8|@]|9|@]|C|$G|H]]|$1|16|3|17|5|6|7|26|8|@$A|27|B|28|W|X]]|9|@]|C|$]]|$1|18|3|19|5|6|7|29|8|@$A|2A|B|2B|W|X]|$A|2C|B|2D|W|X]]|9|@]|C|$]]|$1|1A|3|-4|5|6|7|2E|8|@]|9|@]|C|$]]]|1B|$1C|$5|1D|1E|1F|C|$1G|1H]]]]

I'm not sure what's going wrong (yet!), but you can still initialize by time as follows without hitting the problem (borrowed from <a href="http://www.cplusplus.com/reference/random/linear_congruential_engine/linear_congruential_engine/" rel="noreferrer">here</a>).

<pre><code>#include &lt;ctime&gt;
#include &lt;iostream&gt;
#include &lt;random&gt;
#include &lt;chrono&gt;

using namespace std;

unsigned seed1 = std::chrono::system_clock::now().time_since_epoch().count();

default_random_engine gen(seed1); //gen(time(NULL));
uniform_int_distribution&lt;int&gt; dist(10,200);

int main()
{
 for(int i = 0; i &lt; 5; i++)
 cout&lt;&lt;dist(gen)&lt;&lt;endl;

 return 0;
}
</code></pre>

You can also use the random device, which is non-determinstic (it steals timing information from your key strokes, mouse movements, and other sources to generate unpredictable numbers). This is the strongest seed you can choose but the computer's clock is the better way to go if you don't need strong guarantees because the computer can run out of "randomness" if you use it to often (it takes many key strokes and mouse movements to generate a single truly random number). 

<pre><code>std::random_device rd;
default_random_engine gen(rd());
</code></pre>

Running

<pre><code>cout&lt;&lt;time(NULL)&lt;&lt;endl;
cout&lt;&lt;std::chrono::system_clock::now().time_since_epoch().count()&lt;&lt;endl;
cout&lt;&lt;rd()&lt;&lt;endl;
</code></pre>

on my machine generates

<pre><code>1413844318
1413844318131372773
3523898368
</code></pre>

so the <code>chrono</code> library is providing a significantly larger number and more rapidly changing number (that's in nanoseconds) than the <code>ctime</code> library. The <code>random_device</code> is producing non-deterministic numbers which are all over the map. So it seems as though the seeds <code>ctime</code> is producing may be too close together somehow and thus map partly to the same internal state?

I made another program which looks like this:

<pre><code>#include &lt;iostream&gt;
#include &lt;random&gt;
using namespace std;

int main(){
 int oldval = -1;
 unsigned int oldseed = -1;

 cout&lt;&lt;"Seed\tValue\tSeed Difference"&lt;&lt;endl;
 for(unsigned int seed=0;seed&lt;time(NULL);seed++){
 default_random_engine gen(seed);
 uniform_int_distribution&lt;int&gt; dist(10,200);
 int val = dist(gen);
 if(val!=oldval){
 cout&lt;&lt;seed&lt;&lt;"\t"&lt;&lt;val&lt;&lt;"\t"&lt;&lt;(seed-oldseed)&lt;&lt;endl;
 oldval = val;
 oldseed = seed;
 }
 }
}
</code></pre>

As you can see, this simply prints out the first output value for every possible random seed up to the current time along with the seed and number of previous seeds which had the same value. An excerpt of the output looks like this:

<pre><code>Seed Value Seed Difference
0 10 1
669 11 669
1338 12 669
2007 13 669
2676 14 669
3345 15 669
4014 16 669
4683 17 669
5352 18 669
6021 19 669
6690 20 669
7359 21 669
8028 22 669
8697 23 669
9366 24 669
10035 25 669
10704 26 669
11373 27 669
12042 28 669
12711 29 669
13380 30 669
14049 31 669
</code></pre>

So for every new first number there are 669 seeds which give that first number. Because the second and third numbers are different we are still generating unique internal states. I think we would have to understand much more about the <code>default_random_engine</code> in order to understand what is special about 669 (which can be factored into 3 and 223).

Given this, it's clear why the <code>chrono</code> and <code>random_device</code> libraries work better: the seeds they generate are always more than 669 apart. Keep in mind that even if the first number is the same what matters in many programs is that the sequence of numbers generated by distinct.

blocks|key|907187|text|您使用的种子可能会引入偏差，如果使用不同的种子产生相同的结果，那么生成器本身就不会被正确地写入。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|907188|我建议用不同的种子进行测试，得出一个结论。|907189|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

the seed you are using could be introducing a bias, if using a different seed yields the same results then the generator itself is not properly written.

I would suggest testing with different seeds to draw a conclusion.

blocks|key|907216|text|使用std::default_random_engine就像说“给我一个惊喜！”在一家糟糕的餐馆里。唯一可以肯定的是，结果会很差--因为<random>提供的生成器都有缺陷--但是您甚至不知道必须处理哪些特定的缺陷。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|907217|梅森曲棍球可以是一个不错的选择，如果-只有当-它是适当的种子，其中就有摩擦。理想情况下，种子的每一点都应该以相同的概率影响生成器状态的每一点；正如您所发现的，在std::mersenne_twister_engine的常见实现中，情况并非如此。|907218|Mersenne通常是通过一个简单的PRNG的输出初始化的，而PRNG又被任何可用的熵所播种。这实际上将简单PRNG的种子熵扩展到了龙卷风的巨大状态上。标准的制造者为此目的深思熟虑地提供了seed_seq接口；然而，库似乎不包含任何适配器，用于将生成器用作种子序列。|907219|两个不同的播种概念之间也存在着差异。在生成器方面，种子函数应该接受传入的熵，并将其忠实地映射到生成器状态，确保在过程中不会丢失熵。在用户端，它是“获取这些数字并给出非常不同的序列”，其中‘这些数字’是{+1，2，3，.}或clock()输出。|907220|换句话说，种子熵是以一种不适合直接初始化生成器状态的形式提供的；小的种子差异给出了小的状态差异。这对于像Mersenne这样的大型滞后发电机或为std::ranluxXX生成器提供动力的滞后斐波纳契(+Fibonacci+)来说尤其有问题。|907221|一个位混合函数--一种双射函数，其中输出的每一位都以相同的概率依赖于输入的每一位--可以帮助使种子(如1、2、3或clock()+)的输出对于播种更有用。杂音散列混频器接近这个理想，实现了几乎完美的扩散(32位版本显示)：|907222|uint32_t+murmur_mix32+(uint32_t+x)
{
+++x+%5E=+x+>>+16;
+++x+*=+0x85EBCA6B;
+++x+%5E=+x+>>+13;
+++x+*=+0xC2B2AE35;
+++x+%5E=+x+>>+16;

+++return+x;
}|code-block|syntax|javascript|907223|这个函数是双射的，因此它根本不失去任何熵。这意味着你可以用它来改良任何种子，而不会使事情变得更糟。|907224|另一个快速修复--不需要做一个seed_seq+--是用依赖于(杂音混合的)种子的参数调用生成器上的discard()。然而，对像Mersenne这样的巨型发电机的影响是有限的，因为它们的状态演化非常缓慢，它们需要几十万次迭代才能从缺陷状态中完全恢复。|907225|entityMap|0|LINK|mutability|MUTABLE|url|https://code.google.com/p/smhasher/wiki/MurmurHash3^0|1W|8|0|0|0|0|0|25|7|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|19|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1B|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1C|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1D|8|@]|D|@$9|1E|A|1F|1|1G]]|E|$]]|$1|P|3|Q|5|R|7|1H|8|@]|D|@]|E|$S|T]]|$1|U|3|V|5|6|7|1I|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|1J|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]]|Z|$10|$5|11|12|13|E|$14|15]]]]

Using std::default_random_engine is like saying "Surprise me!" in a bad restaurant. The only thing you know for certain is that the result will be poor - since the generators provided by <code>&lt;random&gt;</code> are all deficient - but you won't even know which particular defects you have to deal with.

The Mersenne Twister can be a decent choice if - and only if - it is properly seeded, and therein lies the rub. Ideally, every bit of the seed should affect every bit of the resulting generator state with equal probability; as you discovered, that is just not the case in common implementations of std::mersenne_twister_engine.

Mersenne Twisters are normally initialised with the output of a simpler PRNG that has in turn been seeded by whatever entropy is available. This effectively stretches the seed entropy of the simpler PRNG over the huge state of the twister. The makers of the standard thoughtfully provided the seed_seq interface for this purpose; however, it seems that the library does not contain any adapters for using a generator as a seed sequence. 

There is also the discrepancy between two different conceptions of seeding. On the generator side, the seeding function should take the entropy that was passed in and map it faithfully onto the generator state, ensuring that no entropy is lost in the process. On the user side, it's "Take these numbers and give me wildly different sequences", where 'these numbers' is { 1, 2, 3, ... } or clock() output. 

In other words, the seed entropy is offered in a form that is not suitable for initialising generator state directly; small seed differences give small state differences. This is especially problematic with huge lagged generators like the Mersenne Twister or the lagged Fibonacci that powers the std::ranluxXX generators.

A bit-mixing function - a bijective function where every bit of the output depends on every bit of the input with equal probability - can help with making seeds like 1, 2, 3 or clock() output more useful for seeding. The <a href="https://code.google.com/p/smhasher/wiki/MurmurHash3" rel="nofollow">murmur hash mixer</a> comes close to this ideal, by achieving almost perfect diffusion (32-bit version shown):

<pre><code>uint32_t murmur_mix32 (uint32_t x)
{
 x ^= x &gt;&gt; 16;
 x *= 0x85EBCA6B;
 x ^= x &gt;&gt; 13;
 x *= 0xC2B2AE35;
 x ^= x &gt;&gt; 16;

 return x;
}
</code></pre>

The function is bijective, hence it does not lose any entropy at all. This means you can use it to improve any seed without any danger of making things worse. 

Another quick fix - without the effort of making a seed_seq - is to call discard() on the generator with a parameter that depends on the (murmur-mixed) seed. However, the effect on huge generators like the Mersenne Twister is somewhat limited, since their state evolves extremely slowly and they need hundreds of thousands of iterations for full recovery from deficient states.

Using the random class, and a seed of time(NULL) the uniform distribution always gives the same first output, even with different compilings, but after the first output behaves as you would expect a pseudorandom number generator to behave.

Is this by construction, or am I using it incorrectly?

MWE:

<pre><code>#include &lt;ctime&gt;
#include &lt;iostream&gt;
#include &lt;random&gt;

using namespace std;

default_random_engine gen(time(NULL));
uniform_int_distribution&lt;int&gt; dist(10,200);

int main()
{
 for(int i = 0; i &lt; 5; i++)
 cout&lt;&lt;dist(gen)&lt;&lt;endl;

 return 0;
}
</code></pre>

The first three times I ran this program I get outputs of:

<pre><code>57
134
125
136
112
</code></pre>

Before the second try I decided to delete empty line between <code>uniform_int_distribution</code> and <code>int main()</code> just to see if the seed was based on compile time, as you can see, that didn't matter.

<pre><code>57
84
163
42
146
</code></pre>

Just running again:

<pre><code>57
73
181
160
46
</code></pre>

So on my runs I keep getting <code>57</code> first, which of course isn't the end of the world, if I want different outputs I can throw away the first output. But it brings into question whether this is by design (if so why?) or if I am misusing the generator somehow (if so how?).

Pseudo random number generator gives same first output but then behaves as expected

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

使用随机类和时间种子(NULL)，均匀分布总是给出相同的第一个输出，即使有不同的编译，但是在第一个输出之后的行为就像您期望的伪随机数生成器的行为一样。这是建筑造成的，还是我用错了？MWE：#include <ctime>#include <iostream>#include <random>using namespac...

问伪随机数生成器提供相同的第一个输出，但随后的行为与预期相同。
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问伪随机数生成器提供相同的第一个输出，但随后的行为与预期相同。EN