Ungewöhnliche ungültige Gleitkommaoperation

[Mikkey]

Der müsste auch eher so ausschauen:

Delphi-Quellcode:

var
  value: TDateTime;
  cmp: double;
  w8087: word;
begin
  try
    cmp := NaN;
    if cmp = 0 then cmp := 0;
    cmp := 0.1;
    value := 0;
    if value <= cmp then // hier müsste die Exception fliegen
      edit2.Text := 'less than 0.1 or equal to 0.1'
    else
      edit2.Text := DateTimeToStr(value);
  except
    on E:Exception do
      showMessage(E.Message);
  end;
end;

[Sherlock]

Ich würde gerne meinen Senf dazu geben, trotzdem oder weil die Sache aufgelöst wurde.
Ich vergleiche seit vielen Jahren Datumsfelder, bzw. prüfe, ob ein DateTime gefüllt/gesetzt ist. Noch nie ist mir sowas passiert. Vermutlich liegt es an meiner Unkenntnis von NaN (Ignorance is bliss). Ein DateTime behandle ich immer als DateTime. Einzig eine gelegentliche Abfrage auf >0 zum prüfen, ob das Ding gefüllt ist (bei mir gibts Gottlob keine Ereignisse vor 1900) erlaube ich mir, und bin noch nie in ein derartiges Problem gelaufen. Mir ist ehrlich gesagt immer noch unklar, was bei Dir eigentlich warum falsch gelaufen ist. Die Geschichte mit dem NaN würde aber an oberster Stelle auf der kurzen Liste der Verdächtigen stehen...wegen KISS und so

Sherlock

[Mikkey]

@ Sherlock:
Was würdest Du dann für eine Repräsentation von "nicht vorhanden" in einem Double-Wert verwenden, der als gültiger Wert beispielsweise zwischen -1E6 und 1E6 liegen kann. Früher wurde in dem System so etwas wie 1E32 dafür verwendet, was sich aber als besch^^^^^ungünstig herausgestellt hat.

[Sherlock]

Wie gesagt, ich bin in der glücklichen Situation kein Datum vor 1900 berücksichtigen zu müssen. Ich weiss ja nicht, was Du für eine Anwendung damit betreiben musst, aber bist Du sicher, daß das für Dich nicht gilt?

Sherlock

[Mikkey]

@ Sherlock:

Zitat von Mikkey:

Was würdest Du dann für eine Repräsentation von "nicht vorhanden" in einem Double-Wert verwenden, ...

Es geht nicht um das Date/Time-Feld, das könnte ich sogar als ungültig betrachten, wenn es unter 41000 liegt.
Der Fehler entsteht durch Vergleich eines Double (enthaltend NAN) mit 0.

[Medium]

Wenn mich nicht alles täuscht, werden bei Operationen mit NaNs (ja, Mehrzahl. Es gibt viele verschiedenen NaNs, die teils auch unterschiedliche Dinge besagen) in der FPU Flags verwendet, die ansonsten nicht mitspielen. Eventuell ist hier bei deinem Vergleich vorher ein solches gesetzt worden, da man aber dokumentiert hat, dass Vergleichen mit NaN böse ist, wird ggf. nicht mehr weiter auf diese geprüft. Bei nachfolgenden FP Operationen könnte dieses Flag dann zum Knall führen.
Wenn das so zutrifft (ich kann es im Moment nicht wirklich testen), dann finde ich einen kleinen Hinweis in der Doku für zu wenig. Da sollte dann eigentlich auch der Compiler mit einer Meldung kommen, wenn das Kompilat den Fall nicht anderweitig sauber behandelt.

[Popov]

Übrigens, ich hatte heute die Fehlermeldung "Ungültige Gleitkommaoperation" bei dieser Berechnung:
x := Round(637 - 3.6854775808e-4927); Rauskopiert und einzeln berechnet ergibt das dagegen keinen Fehler.

[Medium]

Jede Wette, dass dabei das selbe raus kommt wie bei x := 637; , selbst ohne das Round().

4927 lässt sich kaum in den 11 Bits des Exponenten eines Doubles darstellen, womit deine Zahl dort effektiv 0 ist. Der Exponent geht bei Double von -308 bis +308, ein Bruchteil deines. Demnach sollte dort eine denormalisierte Gleitkommazahl vorliegen, welche durchaus auch schon mal komische Dinge in der FPU tun. Je nach dem was um diese Berechnung herum ähnliches passiert ist, kann das durchaus schon sein.

Edit: Für einen Extended geht das, aber IMHO gibt es die doch auf 64 Bit CPUs gar nicht mehr. Was ist da los?

[Dejan Vu]

Zitat von Mikkey:

@ Sherlock:
Was würdest Du dann für eine Repräsentation von "nicht vorhanden" in einem Double-Wert verwenden, der als gültiger Wert beispielsweise zwischen -1E6 und 1E6 liegen kann. Früher wurde in dem System so etwas wie 1E32 dafür verwendet, was sich aber als besch^^^^^ungünstig herausgestellt hat.

Interpretation oder Kodierung allgemein (1E32 ist 'nicht vorhanden') zur Darstellung von Eigenschaften ist immer Murks. Immer. Du könntest dann auch '1234567' nehmen. Genauso blöd.

Ich würde mit Variants arbeiten. Dort kannst Du wunderbar mit dem als Zahl oder Datum nicht existierenden Wert 'nicht vorhanden' arbeiten, ohne irgendwelche Werte zu interpretieren. Variants haben explizite Konstanten (eigentlich sind das Funktionen, aber wie nicht veränderbare Konstanten zu behandeln), die da heißen 'Unassigned' und 'Null'. Damit hast Du deinen 'nicht vorhanden' Wert explizit dargestellt, kannst vor dem Zugriff prüfen etc.

Wenn Dir Variants nicht passen (es soll Leute geben, die rümpfen die Nase, weil Variants angeblich ultralangsam sind. Oder old school), dann verwende doch einen Record, so in etwa.

Delphi-Quellcode:

Type
  TDateTimeRec = Record
  private
    var
      fValue : TDateTime;
      fIsValid : Boolean;
    function GetValue: TDateTime;
    procedure SetValue(const Value: TDateTime);
  public
    Property Value : TDateTime Read GetValue Write SetValue;
    Property IsValid : Boolean Read fIsValid Write fIsValid;
  End;

{ TDateTimeRec }

function TDateTimeRec.GetValue: TDateTime;
begin
  if not isValid Then Raise Exception.Create('Datetime not valid');
  result := fValue;
end;

procedure TDateTimeRec.SetValue(const Value: TDateTime);
begin
 fValue := Value;
 IsValid := True;
end;

Allerdings sind Variants auch nichts anderes als Records...

Und: Ja, man muss ab und zu ein wenig mehr tippen, wenn man es richtig(er) machen will.