Nullable oder NaN

[freimatz]

Hallo,
manchmal habe ich einen Wert als Double, manchmal aber auch nicht. Oft nehme ich dann ein Nullable<>. Könnte man bei einem Double nicht auch NaN nehmen? Das bedeutet doch Not a Number. Wäre eine Zuweisung mit NaN und eine Abfrage mit System.Math.IsNan zuverlässig?

[himitsu]

Natürlich.

NaN, Infinity und NegInfinity sind gültige Werte eines Float-Types.


(nur bezüglich Berechnungen und Vergleichen ala

Delphi-Quellcode:

=

... da kommt's drauf an, wie die FPU konfiguriert ist, also ob sie dann eine Exception wirft)

[Der schöne Günther]

Ich bin kein Freund von Dingen wie

Delphi-Quellcode:

NaN

bei einer Fließkommazahl oder

Delphi-Quellcode:

-1

für eine Ganzzahl um etwas wie "Wert ist nicht vorhanden" oder so zu signalisieren.

Wenn es wirklich etwas ist, das fünf Millionen mal aufgerufen wird und jede Millisekunde zählt - Dann meinetwegen. Aber in 99% der Fälle ist das bisschen Overhead für einen Typ wie

Delphi-Quellcode:

Nullable<Single>

für bessere Quelltext-Lesbarkeit gut investiert.

[Rollo62]

Ich nutze das schon, da wo es Sinn macht, und die Funktionen die damit arbeiten können kennzeichne ich deutlich als "NaN-Safe".

[freimatz]

Hoi, Danke für alle Rückmeldungen. Den akuten Fall habe ich jetzt anders gelöst. Es bleibt für mich aber schon interessant.
@Günther: Gerade das Nullable finde ich in manchen Fällen nicht so lesbar. Andererseits ist da deutlicher was damit gemeint ist.
Mehr als die Geschwindigkeit sehe ich den Speicherverbrauch. Ein Double benötigt m.W. 8 Byte. Ein Nullable vermute ich mal auf 4 mehr. Intern wird ein String missbraucht. Die Diskussion zu der Implementierung habe ich mal gelesen, geht wohl nicht besser. (Eine native Implementierung von EMB wäre wohl besser aber nicht zu erwarten.)
Wenn man nun ein Array von 10000 Vektoren (x,y,z) hat, dann ist das schon relevant.
@Rollo: wo es Sinn macht ... hast Du ein Beispiel?

[himitsu]

So gesehn ... Warum soll man es kompliziertet/aufwändiger machen, wenn es NaN bereits gibt und es keinen Grund gibt es nicht zu benutzen?

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1517414)

Ein Double benötigt m.W. 8 Byte. Ein Nullable vermute ich mal auf 4 mehr.

Bei Win64 dann schon 8...

[himitsu]

Zitat:

Zitat von freimatz (Beitrag 1517414)

Die Diskussion zu der Implementierung habe ich mal gelesen, geht wohl nicht besser.

Jetzt, mit den CustomManagedRecords, schon.

Früher konnte man nur mit LongString, Interface oder Variant halbwegs "einfach" arbeiten, da mit automatischem Speichermangement/Initialisierung und Referenzzählung, bzw. automatischem CopyOnWrite.

[Rollo62]

Zitat:

Zitat von freimatz (Beitrag 1517414)

@Rollo: wo es Sinn macht ... hast Du ein Beispiel?

Ich nutze das z.B. für simple Messages mit ausschliesslich primitiven Typen, wo das Messaging von Nullable-Records oder anderen Inkarnationen zu aufwändig wäre.
Da könnte man man bei Bedarf auch beim Sender von einem Nulable in ein entsprechendes NaN-Integer wandeln und am Empfänger wieder zurück.

Jedenfalls nutze ich das auch dort wo nicht nur Kommunikation innerhalb der eigenen App in Frage kommt,
sondern es mit anderen Apps/Geräten im Netzwerk kommunizieren muss, unter Umständen mit ganz anderen Programmiersprachen.
Simple Typen wie Integer gehen da eigentlich immer sind in der Regel direkt lesbar und sind leicht zu konvertieren.

[Dennis07]

Was für ein Nullable überhaupt?
Das aus Spring4D oder gibt es in Delphi inzwischen ein richtiges in der RTL?

[Stevie]

Gibt noch keines in der RTL - aber auch andere Bibliotheken haben ihre Nullables.
Ich hab gerade mal in develop eingebaut, dass man ab Delphi 11 über die Spring.inc einschalten kann, dass ein Nullable<T> das "Custom Managed Record" Feature nutzt und den "HasValue" State in einem Boolean speichert.

[freimatz]

Und bei Double als NaN? :mrgreen:
Danke! :thumb:

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1517456)

Und bei Double als NaN? :mrgreen:

Nein, weil
a) abhängig vom Typ T die interne Semantik des Nullable<T> nicht ohne einen gigantischen Aufwand geändert werden kann
b) "Kein Wert vorhanden" nicht dasselbe ist wie "es gibt einen Wert, aber der ist NaN"

[himitsu]

Und bei Variant als NULL?

Wobei dort "kein Wert" ja eigentlich EMPTY ist. :stupid: