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

我一直认为随机数在0到1之间，而没有1，即它们是半开区间[0,1）中的数字。cppreference.com上的文件std::generate_canonical证实了这一点。

但是，当我运行以下程序时：

#include <iostream>
#include <limits>
#include <random>

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<float,
                   std::numeric_limits<float>::digits>(rng);

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

    return 0;
}

它给了我以下输出：

Bug!

即，它为我提供了一个完美的解决方案1，这会导致我的MC集成出现问题。那是有效的行为还是我这边有错误？这将提供与G ++ 4.7.3相同的输出

g++ -std=c++11 test.c && ./a.out

和铛3.3

clang++ -stdlib=libc++ -std=c++11 test.c && ./a.out

如果这是正确的行为，我该如何避免1？

编辑1：来自git的G ++似乎也遇到了同样的问题。我在

commit baf369d7a57fb4d0d5897b02549c3517bb8800fd
Date:   Mon Sep 1 08:26:51 2014 +0000

并与~/temp/prefix/bin/c++ -std=c++11 -Wl,-rpath,/home/cschwan/temp/prefix/lib64 test.c && ./a.out给出相同的输出，ldd产量

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

编辑2：我在这里报告了该行为：https : //gcc.gnu.org/bugzilla/show_bug.cgi?id=63176

编辑3：clang团队似乎已经意识到了这个问题：http : //llvm.org/bugs/show_bug.cgi?id=18767

问题在于从std::mt19937（std::uint_fast32_t）的共域到float;的映射。如果当前IEEE754舍入模式不是round-to-negative-infinity（除了取整到负无穷大）之外的其他任何值（请注意默认值为round），则当精度下降时，标准描述的算法会给出错误的结果（与算法输出的描述不一致）。 -最接近）。

带有您的种子的mt19937的7549723rd输出为4294967257（0xffffffd9u），四舍五入为32位浮点数时得出的0x1p+32结果为，等于0xffffffffu四舍五入为32位浮点数时mt19937，4294967295（）的最大值。

该标准可以确保正确的行为，如果它是指定从革联的输出转换到时RealType的generate_canonical，舍入将被向负无穷执行; 在这种情况下，这将给出正确的结果。作为QOI，libstdc ++进行此更改将是很好的。

进行此更改后，1.0将不再生成；代替边界值0x1.fffffep-N对0 < N <= 8将被更频繁地产生（大约2^(8 - N - 32)每N取决于MT19937的实际分布）。

我会建议不要使用float有std::generate_canonical直接; 而是生成in的数字double，然后四舍五入为负无穷大：

    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());
    }

这个问题也可能发生在std::uniform_real_distribution<float>; 解决方案是相同的，以专门化上的分布double并将结果舍入为的负无穷大float。

根据标准，1.0无效。

C ++ 11§26.5.7.2函数模板generate_canonical

从本节26.5.7.2中描述的模板实例化的每个函数都将提供的统一随机数生成器的一个或多个调用的结果映射g到指定RealType的一个成员，这样，如果由产生的值g _ig被均匀分布，则实例化的结果t _j，0≤t _j <1，如下所述尽可能均匀地分布。

我只是与遇到了类似的问题uniform_real_distribution，这就是我如何解释标准在该主题上的简约措词：

标准总是定义数学函数来讲数学，从来没有在IEEE浮点方面（因为标准还假装浮点可能不平均IEEE浮点）。因此，每当您看到标准中的数学措辞时，都是在谈论真正的数学，而不是IEEE。

标准指出，两者uniform_real_distribution<T>(0,1)(g)和generate_canonical<T,1000>(g)都应返回半开范围[0,1）中的值。但是这些都是数学值。当您在半开范围[0,1）中取一个实数并将其表示为IEEE浮点数时，很可能大部分时间都将其舍入为T(1.0)。

当T为float（24个尾数位）时，我们希望看到uniform_real_distribution<float>(0,1)(g) == 1.0f2 ^ 25倍中的1倍。我对libc ++的蛮力试验证实了这一期望。

template<class F>
void test(long long N, const F& get_a_float) {
    int count = 0;
    for (long long i = 0; i < 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 >> 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); });
}

输出示例：

Expected 16 '1.0' results; got 19 in practice
Expected 16 '1.0' results; got 11 in practice

当T为double（53个尾数位）时，我们期望看到uniform_real_distribution<double>(0,1)(g) == 1.02 ^ 54次中的大约1倍。我没有耐心来检验这种期望。:)

我的理解是这种行为很好。它可能会得罪我们的“半开放式rangeness”意义上，一个自称分配“小于1.0”在那些实际上回报号码可返回数等于到1.0; 但是这是“ 1.0”的两个不同含义，明白吗？首先是数学 1.0；第二个是IEEE单精度浮点数1.0。而且数十年来，我们一直被教导不要为了精确相等而比较浮点数。

无论将随机数输入哪种算法，有时都不能准确地计算它1.0。除了数学运算外，您不能对浮点数做任何事情，并且一旦执行数学运算，您的代码就必须处理舍入。即使您可以合理地假设，由于四舍五入generate_canonical<float,1000>(g) != 1.0f，您仍然无法假设这一点generate_canonical<float,1000>(g) + 1.0f != 2.0f。您只是无法摆脱它；那么为什么我们会在这个单一实例中假装您可以呢？