Ungewöhnliche ungültige Gleitkommaoperation

[Mikkey]

@Klaus, Himitsu, Popov, Namenloser:

Das klingt zumindest nach Wegen aus der Krise , am Dienstag werde ich alle mal durchprobieren.

Was ich auf jeden Fall vermeiden muss, ist, den Fehler einfach nicht aufschlagen zu lassen, denn dann tritt er einfach später an irgendeiner Stelle auf (mit entsprechender Meldung "ungültige Gleitkommaoperation" an der Oberfläche.

[Mikkey]

Aalso:

Ich habe aufgrund der Tipps einiges durchprobiert: der Code sieht so aus (auskommentierte Varianten wurden entsprechend probiert):

Delphi-Quellcode:

class function TdlgKlimaSetup.DateTimeToEdit(value: TDateTime): String;
var
  P: PByte;     //H
  i: Integer;
  S: string;
  cmp: Double;  //P
  w8087: Word; //N
begin
  try
    w8087 := Get8087CW(); //N
    cmp := 0.1;
    //if IsNaN(value) or (CompareDateTime(value, cmp) = LessThanValue) then //K
    if value <= cmp then //P
      result := ''
    else
      result := DateTimeToStr(value);
  except
    on E: Exception do begin //H
      P := @value;
      for i := 0 to 7 do
        try
          S := S + IntToHex(P^, 2);
          Inc(P);
        except
          S := S + '**';
        end;
      ShowMessage(Format('ungültige Zahl: "%s" - %s - CW8087=%x', [S, E.Message, w8087]));//HN
    result := '';
    end;
  end;
end;

@Popov:
Auch der Vergleich mit der Variablen hat denselben Effekt. Die Einstellungen sind diese:
A=8 B=0 C=0 D=1 E=0 F=0 G=1 H=1 I=1 J=0 K=0 L=1 M=0 N=1 O=1 P=1 Q=0 R=0 S=0 T=0 U=0 V=1 W=0 X=1 Y=2 Z=1

@Himitsu:
Der Effekt ist derselbe, die Messagebox hängt als Grafik an

@Klaus:
Auch mit CompareDateTime wird dieselbe Exception ausgelöst.

@Namenloser:
Das ausgelesene Control Word ist $1372 (habe ich in der Messagebox mit ausgegeben).
Der Assembercode ist als Grafik wiedergegeben (copy/Paste klappt aus dem CPU-Fenster nicht). Ein Einzelschritt über den FLD von der markierten Stelle führt bereits nach "ntdll.KiUserExceptionDispatcher".

Beim Schreiben ist mir noch eine weitere Idee gekommen:
An den Anfang des Codes habe ich folgendes eingefügt:

Delphi-Quellcode:

    cmp := 0.1;
    Try
    if cmp < 0 then
      cmp := 0.2;
    except
      ShowMessage('Totaler Unsinn');
    end;

Damit erscheint diese Message-Box, aber der übrige Code läuft dann ohne Exception durch.
Jetzt hoffe ich noch, dass das CW etwas Hilfreiches aussagt.

[Mikkey]

Vielen Dank für die Unterstützung.

Zwar weiß ich immer noch nicht, warum der Fehler sich auf diese Weise bemerkbar macht, aber ich habe den Auslöser gefunden.
Zunächst hatte ich mit einer Codezeile, die den Fehler provoziert, die Stelle gesucht, die den Zustand herbeiführt.
Hier wurde eine mit NaN initialisierte Variable mit =0 verglichen.
Nachdem die Variable zuätzlich gegen NaN verglichen wird, tritt der nachfolgende Fehler nicht mehr auf.

Keine Ahnung, warum nicht bereits beim ersten Vergleich eine Exception fliegt, in der Hilfe steht lediglich:

Zitat:

Verwenden Sie NaN nicht in Vergleichsoperationen

[Klaus01]

.. es tut mit leid, aber der code wirft keine Exception..

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  value: TDateTime;
  cmp: double;
  w8087: word;
begin
  try
    w8087 := get8087cw;
    value := strToFloat(Edit1.Text);
    cmp := 0.1;
    if value <= cmp then
      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;

aber wenn Du schon den Übeltäter gefunden hast..

Grüße
Klaus

[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.

[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.