Ungewöhnliche ungültige Gleitkommaoperation

[Popov]

Meines Wissens nach (kann aber auch falsch sein) wählt Delphi für einer Konstante stets den kleinsten benötigten Variablentyp. Bei if value <= 0.0 then wäre 0.0 demnach Single, value Double, also 4 Byte gegen 8 Byte. Sollte jetzt nicht das Problem sein, denn Null ist Null, nur stellt sich die Frage ob value bis in den letzten Bit Null ist.

Was den try except Einschluss angeht, so weiß ich nicht ob das nötig ist. Negative Datumswerte wie hier ShowMessage(DateTimeToStr(-5683.458)); führen nicht zum Fehler. Evtl. wäre IsValidDateTime interessanter als gegen Null zu prüfen. Auf jeden Fall bringt try except an der Stelle wenig.

[Mikkey]

value ist bis in das letzt Bit 0

Zitat von Popov:

Auf jeden Fall bringt try except an der Stelle wenig.

Bitte entschuldige, aber was soll mir das jetzt bringen? Warum der Try/Except-Block da steht, habe ich bereits zweimal geschrieben. Ich finde es selbst unlogisch, dass ein Vergleich eines Double mit 0 ungültig sein soll.

Anscheinend gerät die Gleitkommalogik in irgendeinen komischen Zustand, der bei der ersten passenden Gleitkommaoperation in einer Exception mündet. Dieselbe Exception sorgt aber anscheinend für eine Bereinigung des Problems, so dass danach keine weiteren Exceptions fliegen.

[Popov]

Zitat von Mikkey:

Warum der Try/Except-Block da steht, habe ich bereits zweimal geschrieben.

Jep, hab nicht soweit gelesen.

Was passiert eigentlich wenn du das so machst?

Delphi-Quellcode:

var
  d: Double;
begin
  d := 0.0;
  if value <= d then

[Dejan Vu]

Also wenn ich die Zeichenkette 'Double' '=' und '0' sehe, werde ich mistrauisch und krame den ersten Satz heraus, den ich als Programmierer gelernt habe: Vergleiche Gleitkommazahlen nie auf Gleichheit und 0.0 ist nicht 0.0.

Ich denke, dein DateTimeToStr knallt hier, denn 0>0.0 (wissen wir ja, ne ) und dann wird versucht, daraus einen DateTime zu formatieren und das geht irgendwie in die Hose. Kann mich natürlich auch irren, und der Vergleich knallt.

Ich glaube, auch ein Wert von 0.1 (also irgendwie ein paar Minuten nach Mitternacht um die vorletzte Jahrhundertwende) ist ein legitimer Nix-Datum-Wert. Wieso also nicht einfach das hier versuchen if value < 0.1 then

[Mikkey]

@Dejan Vu:

Obwohl ich weiß, dass die Zahlen 0 und 1 exakte Repräsentierungen in jedem Fließkommasystem haben, hatte ich Deinen Vorschlag schon selbst ausprobiert - mit demselben Effekt.

Nochmal: Es ist nicht der DateTimeToStr, der knallt, sondern der Vergleich selbst! In Vorschlag von Himitsu was es der IntToHex.

Da nach dem ersten Knall kein weiterer folgt, vermute ich, dass das Problem nichts mit der Zahlvariablen zu tun hat, sondern mit dem Fließkommasystem selbst.

@Popov:

Kann ich aktuell nicht ausprobieren, erst am Di wieder. Bin aber felsenfest davon überzeugt, dass damit genau dasselbe passiert.

[Dejan Vu]

Zitat von Mikkey:

Nochmal: Es ist nicht der DateTimeToStr, der knallt, sondern der Vergleich selbst! In Vorschlag von Himitsu was es der IntToHex.

Das gips doch nich. Ich hatte gehofft, das Du dich geirrt hast. Mein Weltbild gerät ins Wanken.

[Klaus01]

.. vielleicht kann man zum Vergleichen auch compareDateTime verwenden.

Grüße
Klaus

[himitsu]

Und das zeigt auch nichts an?

Delphi-Quellcode:

var
  P: PByte;
  i: Integer;
  S: string;
begin
  try
    if value <= 0.0 then
      Result := ''
    else
      try
        Result := DateTimeToStr(value);
      except
        on E: Exception do
          ShowMessage('ungültiges Datum: ' + E.Message);
      end;
  except
    on E: Exception do begin
      P := @value;
      for i := 0 to 7 do
        try
          S := S + IntToHex(P[i], 2);
        except
          S := S + '**';
        end;
      ShowMessage('ungültige Zahl: "' + S + '" - ' + E.Message);
    end;
  end;
end;

[Popov]

@Mikkey

Kann es sein, dass du irgendwo eine spezielle Compilerdirektive nutzt? Mir fällt auf die Schnelle keine ein die zu der Fehlermeldung führen würde, aber wenn du schreibst, dass der Fehler nur einmal vorkommt, dann muss danach irgendetwas passieren, damit es kein weiteres Mal vorkommt. Vielleicht findet beim ersten Aufruf eine Bereichsprüfung statt, die beim weiteren Mal abgestellt ist.

Ich weiß, das Ganze ist etwas weit hergeholt, aber theoretisch möglich.

[Namenloser]

Ich würde mir mal den Wert von Get8087CW() ausgeben lassen. Außerdem, könntest du mal einen Breakpoint auf das begin setzen, in die Assembler-Ansicht wechseln und den Assembler-Code kopieren und hier posten? Und außerdem mal in der Assembler-Ansicht noch mal Anweisung für Anweisung durchsteppen und gucken, wo genau er abbricht.