Hat diese Implementierung jedes undefiniertes Verhalten von frexp?

stimmen
0

Ich habe eine benutzerdefinierte Version von gebaut frexp:

auto frexp(float f) noexcept
{
    static_assert(std::numeric_limits<float>::is_iec559);

    uint32_t u;
    std::memcpy(&u, &f, sizeof(float)); // well defined bit transformation from float to int

    int exp = ((u >> 23) & 0xff) - 126; // extract the 8 bits of the exponent (it has an offset of 126)

    // divide by 2^exp (leaving mantissa intact while placing 0 into the exponent)
    u &= ~(0xff << 23); // zero out the exponent bits
    u |= 126 << 23; // place 126 into exponent bits (representing 0)

    std::memcpy(&f, &u, sizeof(float)); // copy back to f
    return std::make_pair(exp, f);
}

Durch die Überprüfung is_iec559ich dafür sorgen , dass floaterfüllt

die Anforderungen der IEC 559 (IEEE 754) Standard.

Meine Frage ist: Bedeutet das , dass die Bit - Operationen ich tue gut definiert sind und tun , was ich will? Wenn nicht, gibt es eine Möglichkeit , es zu beheben?

Getestet habe ich es für einige zufällige Werte und es scheint korrekt zu sein, zumindest auf 10 Fenster mit msvc kompiliert und auf wandbox . Beachten Sie jedoch, dass (absichtlich) Ich bin nicht den Rand der Bearbeitung von Fällen 0, NaNund inf.

Wenn jemand fragt , warum ich das tue: In Benchmarks fand ich , dass diese Version von frexpbis zu 15 mal schneller als std::frexpunter Windows 10. Ich nicht anderen Plattformen noch nicht getestet haben. Aber ich möchte sicherstellen, dass dies nicht nur funktioniert durch übereinstimmt und kann Bremse in Zukunft.

Veröffentlicht am 09/10/2019 um 18:58
quelle vom benutzer
In anderen Sprachen...                            

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more