1.0 เป็นเอาต์พุตที่ถูกต้องจาก std :: create_canonical หรือไม่

ฉันคิดเสมอว่าตัวเลขสุ่มจะอยู่ระหว่างศูนย์และหนึ่งโดยที่ไม่ใช่1ตัวเลขจากช่วงครึ่งเปิด [0,1) documention บน 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 : G ++ จาก git ดูเหมือนจะประสบปัญหาเดียวกัน ฉันอยู่

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 : ทีมเสียงดังดูเหมือนจะตระหนักถึงปัญหา: http://llvm.org/bugs/show_bug.cgi?id=18767

ปัญหาอยู่ในการแมปจาก codomain ของstd::mt19937( std::uint_fast32_t) ถึงfloat; อัลกอริทึมที่อธิบายโดยมาตรฐานให้ผลลัพธ์ที่ไม่ถูกต้อง (ไม่สอดคล้องกับคำอธิบายของผลลัพธ์ของอัลกอริทึม) เมื่อการสูญเสียความแม่นยำเกิดขึ้นหากโหมดการปัดเศษ IEEE754 ปัจจุบันเป็นสิ่งอื่นที่ไม่ใช่แบบกลมถึงลบ - อินฟินิตี้ (โปรดทราบว่าค่าเริ่มต้นคือรอบ -to- ใกล้ที่สุด)

เอาต์พุต 7549723 ของ mt19937 พร้อมเมล็ดพันธุ์ของคุณคือ 4294967257 ( 0xffffffd9u) ซึ่งเมื่อปัดเป็นโฟลต 32 บิตจะให้0x1p+32ซึ่งเท่ากับค่าสูงสุดของ mt19937, 4294967295 ( 0xffffffffu) เมื่อปัดเป็นโฟลต 32 บิตด้วย

มาตรฐานสามารถตรวจสอบพฤติกรรมที่ถูกต้องได้หากมีการระบุว่าเมื่อแปลงจากเอาต์พุตของ URNG เป็นRealTypeของgenerate_canonicalการปัดเศษจะต้องดำเนินการไปยังอินฟินิตี้เชิงลบ สิ่งนี้จะให้ผลลัพธ์ที่ถูกต้องในกรณีนี้ ในฐานะ QOI มันจะเป็นการดีสำหรับ libstdc ++ ในการเปลี่ยนแปลงนี้

ด้วยการเปลี่ยนแปลงนี้1.0จะไม่ถูกสร้างขึ้นอีกต่อไป แทนค่าขอบเขต0x1.fffffep-Nสำหรับ0 < N <= 8จะถูกสร้างบ่อยขึ้น (โดยประมาณ2^(8 - N - 32)ต่อNขึ้นอยู่กับการแจกแจงจริงของ MT19937)

ฉันอยากจะแนะนำว่าอย่าใช้floatกับstd::generate_canonicalโดยตรง ค่อนข้างสร้างจำนวนใน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>; การแก้ปัญหาคือเดียวกันจะมีความเชี่ยวชาญการจัดจำหน่ายในและรอบผลต่ออินฟินิตี้ลบในdoublefloat

ตามมาตรฐาน1.0ไม่ถูกต้อง

C ++ 11 §26.5.7.2เทมเพลตฟังก์ชั่น create_canonical

แต่ละฟังก์ชันสร้างอินสแตนซ์จากเทมเพลตที่อธิบายไว้ในส่วนนี้ 26.5.7.2 จะแมปผลลัพธ์ของการเรียกใช้หนึ่งหรือมากกว่าของตัวสร้างตัวเลขสุ่มแบบสม่ำเสมอที่gให้มากับสมาชิกหนึ่งคนของ RealType ที่ระบุดังนั้นหากค่าที่_ฉันสร้างขึ้นโดยgมีการกระจายอย่างสม่ำเสมอ ผลลัพธ์ของการสร้างอินสแตนซ์ t _j , 0 ≤ t _j <1มีการกระจายอย่างสม่ำเสมอที่สุดเท่าที่จะทำได้ตามที่ระบุไว้ด้านล่าง

ฉันเพิ่งเจอคำถามที่คล้ายกันuniform_real_distributionและนี่คือวิธีที่ฉันตีความถ้อยคำที่ไม่เหมาะสมของ Standard ในหัวข้อ:

มาตรฐานกำหนดฟังก์ชันทางคณิตศาสตร์ในแง่ของคณิตศาสตร์เสมอไม่เคยอยู่ในรูปของจุดลอยตัวของ IEEE (เนื่องจากมาตรฐานยังคงแสร้งทำเป็นว่าจุดลอยตัวอาจไม่ได้หมายถึงจุดลอยตัวของ IEEE) ดังนั้นเมื่อใดก็ตามที่คุณเห็นถ้อยคำทางคณิตศาสตร์ในมาตรฐานจะพูดถึงคณิตศาสตร์จริงไม่ใช่ IEEE

มาตรฐานระบุว่าทั้งสองuniform_real_distribution<T>(0,1)(g)และgenerate_canonical<T,1000>(g)ควรคืนค่าในช่วงครึ่งเปิด [0,1) แต่นี่คือค่าทางคณิตศาสตร์ เมื่อคุณใช้เวลาเป็นจำนวนจริงในช่วงครึ่งเปิด [0,1) และแสดงเป็น IEEE floating-point, ดี, T(1.0)ส่วนที่สำคัญของเวลามันจะรอบขึ้นไป

เมื่อTใดfloat(24 mantissa bits) เราคาดว่าจะเห็นuniform_real_distribution<float>(0,1)(g) == 1.0fประมาณ 1 ใน 2 ^ 25 ครั้ง การทดลองพลังเดรัจฉานของฉันกับ 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.0ประมาณ 1 ใน 2 ^ 54 ครั้ง ฉันไม่มีความอดทนที่จะทดสอบความคาดหวังนี้ :)

ความเข้าใจของฉันคือพฤติกรรมนี้ดี มันอาจจะกลายเป็นความรู้สึกของ "ครึ่งเปิด 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- เนื่องจากการปัดเศษ คุณไม่สามารถไปจากมันได้ แล้วทำไมเราจะแกล้งทำเป็นว่าคุณทำได้?