On 2014-10-30, Torsten Bronger wrote:
Also das Verhalten von NaNs wird definitiv durch -ffast-math geändert, und darauf basiert ziemlich sicher dein Problem,
Tat es auch. Nach dem Rausnehmen das Flags und neu bauen verhält es sich jetzt korrekt.
aber die Art, in der das hier geschieht, verstehe ich jetzt auf Anhieb auch nicht.
Das geht mir ähnlich. Irgendein Bug scheint da schon vorzuliegen, entweder in numpy oder im gcc. Denn -ffast-math lässt doch lediglich die Rundung jedes Gleitkommazwischenergebnisses von 80 auf 64 Bit weg, welches IEEE 754 vorschreibt, was aber in so gut wie allen Fällen nicht nur unnötig sondern sogar unerwünscht sein kann, denn so wirft man unnötigerweise Genauigkeit weg. Deswegen hatte ich das Flag ja auch gesetzt. Und wer zwei Gleichkommawerte auf Gleichheit testet, macht bereits an der Stelle einen kapitalen Fehler. Aber trotzdem Danke für eure Antworten! Insgesamt hat mich das Nachforschen auch schlauer gemacht, was NaN und auch inf angeht. So war mein Vergleich mit NaN eh falsch. Auf NaN testet man grundsätzlich mit math.isnan() bzw. np.isnan(), denn es gilt ja: #v+ Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information.
float('nan') == float('nan') False #v-
bzw. aus der gcc Doku: NaN is unordered: it is not equal to, greater than, or less than anything, including itself. x == x is false if the value of x is NaN. Allerdings wird: In addition, <, >, <=, and >= will raise an exception when applied to NaNs. in Python anders gehandhabt: #v+
float('nan') >= float('nan') False #v-
Bernd -- no time toulouse