1.0 è un output valido di std :: generate_canonical?

Ho sempre pensato che i numeri casuali si trovassero tra zero e uno, senza1 , cioè sono numeri dell'intervallo semi-aperto [0,1). La documention su cppreference.com di std::generate_canonicalconferma.

Tuttavia, quando eseguo il seguente programma:

#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;
}

Mi dà il seguente output:

Bug!

cioè mi genera un perfetto 1, che causa problemi nella mia integrazione MC. È un comportamento valido o c'è un errore dalla mia parte? Questo dà lo stesso output con G ++ 4.7.3

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

e clang 3.3

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

Se questo è un comportamento corretto, come posso evitare 1?

Modifica 1 : G ++ di git sembra soffrire dello stesso problema. ci sono

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

e la compilazione con ~/temp/prefix/bin/c++ -std=c++11 -Wl,-rpath,/home/cschwan/temp/prefix/lib64 test.c && ./a.outdà lo stesso output, lddrese

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)

Modifica 2 : ho segnalato il comportamento qui: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176

Modifica 3 : il team di clang sembra essere a conoscenza del problema: http://llvm.org/bugs/show_bug.cgi?id=18767

Il problema è nel mapping dal codice di std::mt19937( std::uint_fast32_t) a float; l'algoritmo descritto dalla norma fornisce risultati errati (incompatibili con la descrizione dell'output dell'algoritmo) quando si verifica una perdita di precisione se l'attuale modalità di arrotondamento IEEE754 è diversa dall'infinito da rotondo a negativo (si noti che l'impostazione predefinita è rotonda -a-più vicino).

L'output 7549723rd di mt19937 con il seme è 4294967257 ( 0xffffffd9u), che quando arrotondato a float a 32 bit dà 0x1p+32, che è uguale al valore massimo di mt19937, 4294967295 ( 0xffffffffu) quando anche quello è arrotondato a float a 32 bit.

Lo standard potrebbe garantire un comportamento corretto se dovesse specificare che quando si converte dall'output dell'URNG al RealTypedi generate_canonical, l'arrotondamento deve essere eseguito verso l'infinito negativo; questo darebbe un risultato corretto in questo caso. Come QOI, sarebbe bene per libstdc ++ apportare questa modifica.

Con questa modifica, 1.0non verrà più generato; invece i valori limite 0x1.fffffep-Nper 0 < N <= 8verranno generati più spesso (approssimativamente 2^(8 - N - 32)per N, a seconda della distribuzione effettiva di MT19937).

Suggerirei di non usare floatcon std::generate_canonicaldirettamente; piuttosto generare il numero in doublee poi arrotondare verso l'infinito negativo:

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

Questo problema può verificarsi anche con std::uniform_real_distribution<float>; la soluzione è la stessa, specializzare la distribuzione doublee arrotondare il risultato verso l'infinito negativo in float.

Secondo lo standard, 1.0non è valido.

C ++ 11 §26.5.7.2 Modello di funzione generate_canonical

Ciascuna funzione istanziata dal modello descritto in questa sezione 26.5.7.2 associa il risultato di una o più chiamate di un generatore di numeri casuali uniforme fornita gad un membro della RealType specificato in modo tale che, se i valori g _i Per prodotto gsono uniformemente distribuiti, la i risultati dell'istanza t _j , 0 ≤ t _j <1 , sono distribuiti nel modo più uniforme possibile come specificato di seguito.

Ho appena incontrato una domanda simile con uniform_real_distribution, ed ecco come interpreto la formulazione parsimoniosa dello Standard sull'argomento:

Lo standard definisce sempre le funzioni matematiche in termini matematici , mai in termini di virgola mobile IEEE (poiché lo standard fa ancora finta che il virgola mobile potrebbe non significare il virgola mobile IEEE). Quindi, ogni volta che vedi una formulazione matematica nello Standard, parla di vera matematica , non di IEEE.

Lo standard afferma che entrambi uniform_real_distribution<T>(0,1)(g)e generate_canonical<T,1000>(g)dovrebbero restituire valori nell'intervallo semi-aperto [0,1). Ma questi sono valori matematici . Quando prendi un numero reale nell'intervallo semi-aperto [0,1) e lo rappresenti come punto in virgola mobile IEEE, beh, una frazione significativa del tempo che arrotonderà per eccesso T(1.0).

Quando Tè float(24 bit di mantissa), ci aspettiamo di vedere uniform_real_distribution<float>(0,1)(g) == 1.0fcirca 1 in 2 ^ 25 volte. La mia sperimentazione a forza bruta con libc ++ conferma questa aspettativa.

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

Esempio di output:

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

Quando Tè double(53 bit di mantissa), ci aspettiamo di vedere uniform_real_distribution<double>(0,1)(g) == 1.0circa 1 in 2 ^ 54 volte. Non ho la pazienza di testare questa aspettativa. :)

La mia comprensione è che questo comportamento va bene. Essa può offendere il senso di "half-open-rangeness" che una distribuzione pretesa di restituire numeri "minore di 1.0" lattina in numero di ritorno fatto che sono uguali a 1.0; ma quelli sono due significati diversi di "1.0", vedi? Il primo è il matematico 1.0; il secondo è il numero IEEE a virgola mobile a precisione singola 1.0. E ci è stato insegnato per decenni a non confrontare i numeri in virgola mobile per l'uguaglianza esatta.

Qualunque algoritmo in cui dai i numeri casuali non ti importerà se a volte arriva esattamente 1.0. Non c'è niente che tu possa fare con un numero in virgola mobile tranne le operazioni matematiche e non appena eseguirai alcune operazioni matematiche, il tuo codice dovrà occuparsi dell'arrotondamento. Anche se si potrebbe legittimamente supporre che generate_canonical<float,1000>(g) != 1.0f, è ancora non sarebbe in grado di assumere che generate_canonical<float,1000>(g) + 1.0f != 2.0f- a causa dell'arrotondamento. Non puoi scappare da esso; quindi perché dovremmo fingere in questo singolo caso che puoi?