Re: [Python-de] numpy.float64(x) == float('nan') für alle x
On 2014-10-30, Christopher Arndt wrote:
Am 30.10.2014 um 14:19 schrieb Bernd Nawothnig:
np.float64(-57.9) == float('nan') True
Ich kann deine Ergebnisse mit Python 3.4.2 und Numpy 1.9.0 nicht reproduzieren (Linux x86_64).
Dieselbe Architektur, strange. numpy 1.9.0 verwende ich auch, Python ist die Version von Ubuntu 14.04, also 3.4.0 (keine Ahnung, warum die das nicht für nötig halten, zu aktualisieren).
Welche Versionen, OS und Architektur benutzt du?
#v+ bernd@bernd:~$ uname -a Linux bernd 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux #v- Numpy habe ich aus den Quellen lokal gebaut (gcc 4.8.2), allerdings mit Compilerflag -ffast-math. Klar ändern sich dadurch die Ergebnisse etwas (sollten genauer sein, als IEEE vorschreibt), aber deswegen können doch nicht beliebige Gleitkommawerte == NaN sein, oder? Dasselbe tritt auch auf, wenn ich np.NaN statt float('nan') verwende. Witzigerweise funktioniert np.isnan zwar auf arrays, aber nicht auf Einzelwerten: #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.
import numpy as np a = np.array([1.7, float('nan'), 37.9], np.float64) a array([ 1.7, nan, 37.9]) np.isnan(a) array([False, True, False], dtype=bool) np.isnan(np.NaN) False np.isnan(float('nan')) False
#v-
Bernd -- no time toulouse
Hallöchen! Bernd Nawothnig schreibt:
[...]
Numpy habe ich aus den Quellen lokal gebaut (gcc 4.8.2), allerdings mit Compilerflag -ffast-math. Klar ändern sich dadurch die Ergebnisse etwas (sollten genauer sein, als IEEE vorschreibt), aber deswegen können doch nicht beliebige Gleitkommawerte == NaN sein, oder?
Also das Verhalten von NaNs wird definitiv durch -ffast-math geändert, und darauf basiert ziemlich sicher dein Problem, aber die Art, in der das hier geschieht, verstehe ich jetzt auf Anhieb auch nicht. Tschö, Torsten. -- Torsten Bronger Jabber-ID: torsten.bronger@jabber.rwth-aachen.de oder http://bronger-jmp.appspot.com
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
Bernd Nawothnig wrote:
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,
Nein, es tut viel mehr. Ausserdem bildet lesen der Dokumentation: | -ffast-math | Sets […] -ffinite-math-only, […] | -ffinite-math-only | Allow optimizations for floating-point arithmetic that assume that | arguments and results are not NaNs or +-Infs. Bastian
On 2014-11-01, Bastian Blank wrote:
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,
Nein, es tut viel mehr. Ausserdem bildet lesen der Dokumentation:
| -ffast-math | Sets […] -ffinite-math-only, […] | -ffinite-math-only | Allow optimizations for floating-point arithmetic that assume that | arguments and results are not NaNs or +-Infs.
Oh, in der Tat, das erklärt dann das Verhalten. Danke! Bernd -- no time toulouse
participants (3)
-
Bastian Blank -
Bernd Nawothnig -
Torsten Bronger