wenn ich einen float mit sich selbst vergleiche, ergibt der Ausdruck dann true, wenn es sich um eine "normale" Zahl (also nicht NaN, +-inf, IND o.ä.) handelt?

Sind operator== und operator!= beide definiert für diese Operation?

Aber Achtung: Ein solcher Vergleich könnte wegoptimiert werden, üblich ist daher:

bool my_isnan(double value)
{
    volatile double d = value;
    return d != d;
}

Kann ich irgendwie prüfen, ob der float irgendwas Nicht-Zahliges (also nicht nur NaN sondern auch inf, IND usw.) ist?

Ja. Aber hast du denn weder C++11 noch Boost noch eine C99-Standardbibliothek? Die haben das nämlich alle schon eingebaut.

Kann ich irgendwie prüfen, ob der float irgendwas Nicht-Zahliges (also nicht nur NaN sondern auch inf, IND usw.) ist?

!isfinite(x)

aus <cmath>

Sorry nochmal. Ich kriege gerade die einfachsten Dinge nicht gebacken (geschweige denn über Google gefunden). Ich gestatte euch Facepalms, Kopfschütteln und Augendrehen über mich.

Aber Achtung: Ein solcher Vergleich könnte wegoptimiert werden

Widerspricht das nicht der as-if-Regel?

SeppJ schrieb:

Aber Achtung: Ein solcher Vergleich könnte wegoptimiert werden

Widerspricht das nicht der as-if-Regel?

Bei Fließkommaoperationen wird dies auf härteren Optimierungsstufen (GCC z.B. ffast-math, ffinite-math & Co, muss man aber alles händisch aktivieren) auch mal ignoriert. Dann funktioniert die volatile-Operation (hoffentlich, ich habe es nicht getestet) immer noch. Bei nicht so harten Optimierungen sollte (wieder nicht getestet, nur geschätzt, dass es da sowieso nicht viel zu optimieren gibt) es trotz volatile ungefähr gleich schnell sein (die Pipeline wird eventuell nicht perfekt ausgelastet, weil volatile strenger ist, was Umordnungen angeht).

Natürlich ist der ganze Punkt dieser Optimierungen, dass sie den Fließkommastandard brechen dürfen, insofern ist das volatile bei genauerem Nachdenken doch eher unnötig, da man diese Optimierungen sowieso nicht nutzen kann, wenn NaN vorkommen kann.

-ffast-math führt allerdings zu nicht konformen Programmen. Um ehrlich zu sein, verstehe ich sowieso nicht, wieso jemand diese Option benutzen würde. Entweder ist sie performanceirrelevant, weil kaum entsprechende Berechnungen durchgeführt werden, oder aber das resultierende Programm ist mit hoher Wahrscheinlichkeit defekt.

Wenn Du zum Beispiel digitale Signale verarbeiten willst, dann kommt es häufig weniger auf die Genauigkeit in den letzten Kommastellen (die beeinflusst höchstens das Rauschen) an, als vielmehr um eine gute Performance. Da werden druchaus "entsprechende" Berechnungen durchgeführt, ohne dass das Programm dadurch gleich defekt ist. Insbesondere in Verbindung mit std::complex macht -ffast-math hierbei durchaus Sinn.