blocks|key|2942564|text|问题是从std::mt19937+(std::uint_fast32_t)的共域映射到float；如果当前的IEEE754舍入模式不是舍入到负无穷大(请注意，默认值是舍入到最近的)，则当精度损失时，标准描述的算法会给出不正确的结果(与其对算法输出的描述不一致)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2942565|带有种子的mt19937的第7549723个输出是4294967257+(0xffffffd9u)，当四舍五入为32位浮点数时，将得到0x1p%2B32，这等于mt19937的最大值4294967295+(0xffffffffu)，也四舍五入为32位浮点数。|2942566|如果该标准指定在从URNG的输出转换为generate_canonical的RealType时，向负无穷大进行舍入，则可以确保正确的行为；在这种情况下，这将给出正确的结果。作为QOI，对libstdc%2B%2B来说做出这样的改变是有好处的。|2942567|进行此更改后，将不再生成1.0；而是更频繁地生成0+<+N+<=+8的边界值0x1.fffffep-N+(根据MT19937的实际分布情况，约为每个N的2%5E(8+-+N+-+32)+)。|2942568|我建议不要在std::generate_canonical中直接使用float；而是在double中生成数字，然后四舍五入为负无穷大：|2942569|++++double+rd+=+std::generate_canonical<double,
++++++++std::numeric_limits<float>::digits>(rng);
++++float+rf+=+rd;
++++if+(rf+>+rd)+{
++++++rf+=+std::nextafter(rf,+-std::numeric_limits<float>::infinity());
++++}|code-block|syntax|javascript|2942570|这个问题也可能发生在std::uniform_real_distribution<float>中；解决方案是相同的，在double上专门化分布，并在float中将结果舍入到负无穷大。|2942571|entityMap^0|4|C|I|I|17|5|0|11|B|1V|7|2T|B|0|J|I|12|8|0|C|3|O|A|12|D|22|1|24|E|0|6|N|Y|5|17|6|0|0|A|11|1N|6|22|5|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1F|8|@$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]|$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1Q|8|@$9|1R|A|1S|B|C]|$9|1T|A|1U|B|C]|$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|N|3|O|5|P|7|1X|8|@]|D|@]|E|$Q|R]]|$1|S|3|T|5|6|7|1Y|8|@$9|1Z|A|20|B|C]|$9|21|A|22|B|C]|$9|23|A|24|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|25|8|@]|D|@]|E|$]]]|V|$]]

The problem is in mapping from the codomain of <code>std::mt19937</code> (<code>std::uint_fast32_t</code>) to <code>float</code>; the algorithm described by the standard gives incorrect results (inconsistent with its description of the output of the algorithm) when loss of precision occurs if the current IEEE754 rounding mode is anything other than round-to-negative-infinity (note that the default is round-to-nearest).

The 7549723rd output of mt19937 with your seed is 4294967257 (<code>0xffffffd9u</code>), which when rounded to 32-bit float gives <code>0x1p+32</code>, which is equal to the max value of mt19937, 4294967295 (<code>0xffffffffu</code>) when that is also rounded to 32-bit float.

The standard could ensure correct behavior if it were to specify that when converting from the output of the URNG to the <code>RealType</code> of <code>generate_canonical</code>, rounding is to be performed towards negative infinity; this would give a correct result in this case. As QOI, it would be good for libstdc++ to make this change.

With this change, <code>1.0</code> will no longer be generated; instead the boundary values <code>0x1.fffffep-N</code> for <code>0 &lt; N &lt;= 8</code> will be generated more often (approximately <code>2^(8 - N - 32)</code> per <code>N</code>, depending on the actual distribution of MT19937).

I would recommend to not use <code>float</code> with <code>std::generate_canonical</code> directly; rather generate the number in <code>double</code> and then round towards negative infinity:

<pre><code> double rd = std::generate_canonical&lt;double,
 std::numeric_limits&lt;float&gt;::digits&gt;(rng);
 float rf = rd;
 if (rf &gt; rd) {
 rf = std::nextafter(rf, -std::numeric_limits&lt;float&gt;::infinity());
 }
</code></pre>

This problem can also occur with <code>std::uniform_real_distribution&lt;float&gt;</code>; the solution is the same, to specialize the distribution on <code>double</code> and round the result towards negative infinity in <code>float</code>.

blocks|key|2730142|text|我刚刚在uniform_real_distribution上遇到了一个类似的问题，下面是我如何解释标准在这个问题上的简洁措辞：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2730143|标准总是根据数学定义数学函数，而不是IEEE浮点(因为标准仍然假装浮点可能不表示IEEE浮点)。所以，任何时候你在标准中看到数学措辞，它都是在谈论真正的数学，而不是IEEE。|2730144|标准规定uniform_real_distribution<T>(0,1)(g)和generate_canonical<T,1000>(g)都应该返回半开范围[0，1]内的值。但这些都是数学值。当你在半开范围[0，1]中取一个实数，并将其表示为IEEE浮点时，很大一部分时间它会四舍五入为T(1.0)。|2730145|当T为float+(24个尾数位)时，我们预计uniform_real_distribution<float>(0,1)(g)+==+1.0f大约会出现2%5E25次。My+brute-force+experimentation+with+libc%2B%2B+confirms+this+expectation.|2730146|template<class+F>
void+test(long+long+N,+const+F&+get_a_float)+{
++++int+count+=+0;
++++for+(long+long+i+=+0;+i+<+N;+%2B%2Bi)+{
++++++++float+f+=+get_a_float();
++++++++if+(f+==+1.0f)+{
++++++++++++%2B%2Bcount;
++++++++}
++++}
++++printf("Expected+%25d+'1.0'+results;+got+%25d+in+practice\n",+(int)(N+>>+25),+count);
}

int+main()+{
++++std::mt19937+g(std::random_device{}());
++++auto+N+=+(1uLL+<<+29);
++++test(N,+[&g]()+{+return+std::uniform_real_distribution<float>(0,1)(g);+});
++++test(N,+[&g]()+{+return+std::generate_canonical<float,+32>(g);+});
}|code-block|syntax|javascript|2730147|输出示例：|2730148|Expected+16+'1.0'+results;+got+19+in+practice
Expected+16+'1.0'+results;+got+11+in+practice|2730149|当T为double+(53个尾数位)时，我们预计uniform_real_distribution<double>(0,1)(g)+==+1.0大约会出现2%5E54次。我没有耐心来测试这个期望。:)|2730150|我的理解是，这种行为很好。一个声称返回数字“小于1.0”的分布实际上可以返回等于1.0的数字，这可能会冒犯我们的“半开放范围”的意义；但这是"1.0“的两种不同含义，看到了吗？第一个是数学上的1.0；第二个是IEEE单精度浮点数1.0。几十年来，我们一直被教导不要为了精确相等而比较浮点数。|2730151|无论您将随机数输入到哪个算法中，都不会关心它有时是否准确地获得了1.0。除了数学运算之外，你对浮点数没有什么可以做的，一旦你做了一些数学运算，你的代码就必须处理四舍五入。即使你可以合法地假设generate_canonical<float,1000>(g)+!=+1.0f，你仍然不能假设generate_canonical<float,1000>(g)+%2B+1.0f+!=+2.0f+--因为四舍五入。你就是无法摆脱它；那么为什么我们要在这个单一的实例中假装你可以呢？|2730152|entityMap|0|LINK|mutability|MUTABLE|url|https://wandbox.org/permlink/Culi50l3hCPLJMSD^0|4|P|0|0|4|10|15|T|40|6|0|1|1|3|5|N|1C|2A|1X|0|0|0|0|0|1|1|3|6|O|1C|0|14|3|36|3|0|W|3|2N|15|40|1C|0^^$0|@$1|2|3|4|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1B|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1J|8|@$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]|$9|1O|A|1P|B|C]]|D|@$9|1Q|A|1R|1|1S]]|E|$]]|$1|L|3|M|5|N|7|1T|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|1U|8|@]|D|@]|E|$]]|$1|S|3|T|5|N|7|1V|8|@]|D|@]|E|$O|P]]|$1|U|3|V|5|6|7|1W|8|@$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]|$9|21|A|22|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|23|8|@$9|24|A|25|B|C]|$9|26|A|27|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|28|8|@$9|29|A|2A|B|C]|$9|2B|A|2C|B|C]|$9|2D|A|2E|B|C]]|D|@]|E|$]]|$1|10|3|-4|5|6|7|2F|8|@]|D|@]|E|$]]]|11|$12|$5|13|14|15|E|$16|17]]]]

I just ran into a similar question with <code>uniform_real_distribution</code>, and here's how I interpret the Standard's parsimonious wording on the subject:

The Standard always defines math functions in terms of math, never in terms of IEEE floating-point (because the Standard still pretends that floating-point might not mean IEEE floating point). So, any time you see mathematical wording in the Standard, it's talking about real math, not IEEE.

The Standard says that both <code>uniform_real_distribution&lt;T&gt;(0,1)(g)</code> and <code>generate_canonical&lt;T,1000&gt;(g)</code> should return values in the half-open range [0,1). But these are mathematical values. When you take a real number in the half-open range [0,1) and represent it as IEEE floating-point, well, a significant fraction of the time it will round up to <code>T(1.0)</code>.

When <code>T</code> is <code>float</code> (24 mantissa bits), we expect to see <code>uniform_real_distribution&lt;float&gt;(0,1)(g) == 1.0f</code> about 1 in 2^25 times. <a href="https://wandbox.org/permlink/Culi50l3hCPLJMSD" rel="nofollow noreferrer">My brute-force experimentation with libc++ confirms this expectation.</a>

<pre><code>template&lt;class F&gt;
void test(long long N, const F&amp; get_a_float) {
 int count = 0;
 for (long long i = 0; i &lt; N; ++i) {
 float f = get_a_float();
 if (f == 1.0f) {
 ++count;
 }
 }
 printf("Expected %d '1.0' results; got %d in practice\n", (int)(N &gt;&gt; 25), count);
}

int main() {
 std::mt19937 g(std::random_device{}());
 auto N = (1uLL &lt;&lt; 29);
 test(N, [&amp;g]() { return std::uniform_real_distribution&lt;float&gt;(0,1)(g); });
 test(N, [&amp;g]() { return std::generate_canonical&lt;float, 32&gt;(g); });
}
</code></pre>

Example output:

<pre><code>Expected 16 '1.0' results; got 19 in practice
Expected 16 '1.0' results; got 11 in practice
</code></pre>

When <code>T</code> is <code>double</code> (53 mantissa bits), we expect to see <code>uniform_real_distribution&lt;double&gt;(0,1)(g) == 1.0</code> about 1 in 2^54 times. I don't have the patience to test this expectation. :)

My understanding is that this behavior is fine. It may offend our sense of "half-open-rangeness" that a distribution claiming to return numbers "less than 1.0" can in fact return numbers that are equal to <code>1.0</code>; but those are two different meanings of "1.0", see? The first is the mathematical 1.0; the second is the IEEE single-precision floating-point number <code>1.0</code>. And we've been taught for decades not to compare floating-point numbers for exact equality.

Whatever algorithm you feed the random numbers into isn't going to care if it sometimes gets exactly <code>1.0</code>. There's nothing you can do with a floating-point number except mathematical operations, and as soon as you do some mathematical operation, your code will have to deal with rounding. Even if you could legitimately assume that <code>generate_canonical&lt;float,1000&gt;(g) != 1.0f</code>, you still wouldn't be able to assume that <code>generate_canonical&lt;float,1000&gt;(g) + 1.0f != 2.0f</code> — because of rounding. You just can't get away from it; so why would we pretend in this single instance that you can?

I always thought random numbers would lie between zero and one, without <code>1</code>, i.e. they are numbers from the half-open interval [0,1). The <a href="http://en.cppreference.com/w/cpp/numeric/random/generate_canonical">documention on cppreference.com</a> of <code>std::generate_canonical</code> confirms this.

However, when I run the following program:

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

int main()
{
 std::mt19937 rng;

 std::seed_seq sequence{0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
 rng.seed(sequence);
 rng.discard(12 * 629143 + 6);

 float random = std::generate_canonical&lt;float,
 std::numeric_limits&lt;float&gt;::digits&gt;(rng);

 if (random == 1.0f)
 {
 std::cout &lt;&lt; "Bug!\n";
 }

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

It gives me the following output:

<pre><code>Bug!
</code></pre>

i.e. it generates me a perfect <code>1</code>, which causes problems in my MC integration. Is that valid behavior or is there an error on my side? This gives the same output with G++ 4.7.3

<pre><code>g++ -std=c++11 test.c &amp;&amp; ./a.out
</code></pre>

and clang 3.3

<pre><code>clang++ -stdlib=libc++ -std=c++11 test.c &amp;&amp; ./a.out
</code></pre>

If this is correct behavior, how can I avoid <code>1</code>?

Edit 1: G++ from git seems to suffer from the same problem. I am on

<pre><code>commit baf369d7a57fb4d0d5897b02549c3517bb8800fd
Date: Mon Sep 1 08:26:51 2014 +0000
</code></pre>

and compiling with <code>~/temp/prefix/bin/c++ -std=c++11 -Wl,-rpath,/home/cschwan/temp/prefix/lib64 test.c &amp;&amp; ./a.out</code> gives the same output, <code>ldd</code> yields

<pre><code>linux-vdso.so.1 (0x00007fff39d0d000)
libstdc++.so.6 =&gt; /home/cschwan/temp/prefix/lib64/libstdc++.so.6 (0x00007f123d785000)
libm.so.6 =&gt; /lib64/libm.so.6 (0x000000317ea00000)
libgcc_s.so.1 =&gt; /home/cschwan/temp/prefix/lib64/libgcc_s.so.1 (0x00007f123d54e000)
libc.so.6 =&gt; /lib64/libc.so.6 (0x000000317e600000)
/lib64/ld-linux-x86-64.so.2 (0x000000317e200000)
</code></pre>

Edit 2: I reported the behavior here: <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176</a>

Edit 3: The clang team seems to be aware of the problem: <a href="http://llvm.org/bugs/show_bug.cgi?id=18767">http://llvm.org/bugs/show_bug.cgi?id=18767</a>

Is 1.0 a valid output from std::generate_canonical?

我一直认为随机数应该在0和1之间，没有1，的，即它们是来自半开区间[0，1]的数字。std::generate_canonical的证实了这一点。但是，当我运行以下程序时：#include <iostream>#include <limits>#include <random>int main(){ std::m...

问1.0是std::generate_canonical的有效输出吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问1.0是std::generate_canonical的有效输出吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问1.0是std::generate_canonical的有效输出吗？
EN