Single wert ist unterschiedlich obwohl gleich

[gammatester]

Zitat:

Zitat von himitsu (Beitrag 1405057)

Single = 7-8 signifikante Dezimalstellen, also im Wost-Case nur 7.
Die erste Signifikante ist von links die erste Nicht-Null.

0.68000000715

Selbst Schuld, wenn du einen Wertebereich haben willst, der nichtmals Ansatzweise in den Datentyp passt.
Und selbst wenn, dann sind auch innerhalb der Signifikanten Rundungsfehler möglich, vor allem bei gewissen unendlich langen Werten ala 2/3.

Und warum sollte 0.68 nicht in den Single-Bereich passen? Es ist nur nicht exakt darstellbar, ebenso wenig wie als Double oder Extended. Also ist das Gerede vom falschen Datentyp noch nicht mal 10% der Wahrheit.

Zitat:

Zitat von himitsu (Beitrag 1405057)

Single hat einen 8 Bit-Exponent und eine Mantisse von 23 Bit Länge, inkl. einem virtuellen Bit, wenn der Exponent 0 ist, also 24.
2^24 = 16.777.215 = nicht ganz 8 Dezimalstellen (nur 1. bis 7. können alles von 0 bis 9 sein)

Querfrage: Warum ist 0.000000000931322574615478515625 exakt als Single dastellbar, obwohl es 21 signifikante Stellen hat?

Wenn der Exponent 0 ist hat man subnormale Zahlen, und im Gegensatz zu Deiner Behauptung wird das signifikante Bit in dieser Situation gerade nicht versteckt!

Normalisierte Zahlen haben immer eine 24-Bit Mantisse bzw. Signifikand (falls Du Deine Info vom deutschen Wikipedia schau mal ins englische oder in den Standard IEEE754_2008 Tabelle 3.2).

[EWeiss]

Zitat:

Und warum sollte 0.68 nicht in den Single-Bereich passen?

Nun weil @himitsu es sagt.

Was ich nicht verstehe.. Warum hier der Compiler von Delphi wieder eine Extrawurst kreiert (Double oder Extended)
Definiere ich in C++ die gleiche Const dann gibt es so was nicht.

gruss

[bernau]

Für Gleitkomma-Datentypen verwende ich mittlerweile (fast) immer Funktionen aus der Unit System.Math

IsZero oder Samevalue oder compareValue ist da dein Freund.

[gammatester]

Zitat:

Zitat von EWeiss (Beitrag 1405068)

Zitat:

Und warum sollte 0.68 nicht in den Single-Bereich passen?

Nun weil @himitsu es sagt.

Was ich nicht verstehe.. Warum hier der Compiler von Delphi wieder eine Extrawurst kreiert (Double oder Extended)
Definiere ich in C++ die gleiche Const dann gibt es so was nicht.

gruss

C++ rechnet wohl immer double (aber legt mich nicht fest).

Delphi-32-Bit rechnet intern mit extended.

Delphi-64-Bit via SSE immer als double.

[EWeiss]

Zitat:

Zitat von bernau (Beitrag 1405069)

Für Gleitkomma-Datentypen verwende ich mittlerweile (fast) immer Funktionen aus der Unit System.Math

IsZero oder Samevalue oder compareValue ist da dein Freund.

Ja warum es einfach machen wenn es auch umständlich geht.
Bleibt unverständlich für mich.

Zitat:

C++ rechnet wohl immer double (aber legt mich nicht fest).
Delphi-32-Bit rechnet intern mit extended.
Delphi-64-Bit via SSE immer als double.

Jo..
Ich habe schon Anwendungen in Sharp, VBNet, Vb6, C++ geschrieben
Nirgendwo habe ich je solche Probleme mit Single gehabt.

gruss

[gammatester]

Zitat:

Zitat von bernau (Beitrag 1405069)

IsZero oder Samevalue oder compareValue ist da dein Freund.

Das sind genau die Routinen für Leute, die keine/wenig Ahnung haben. Nach der simplen Methode liefert iszero(Planckkonstante)=true oder iszero(Gravitationkonstante)=true. Außerdem ist iszero für solche Feautures wie sinh(1e-20)=0 verantwortlich, wohingegen sin(1e-20) richtig = 1e-20 ist.

Delphi-Quellcode:

{$apptype console}
uses
  Math;
const
  g: single = 6.67e-11;
  h: extended = 6.63e-34;
begin
  writeln(iszero(g));
  writeln(iszero(h));
  writeln(sinh(1e-20));
  writeln(sin(1e-20));
end.

Code:

TRUE
TRUE
 0.00000000000000E+0000
 1.00000000000000E-0020

Man kann iszero etc richtig verwenden, aber dann kann man auch gleich seine Kenntnisse in die richtige Formulierung stecken. (Wer weiß schon auswendig, welche Default-Toleranz benutzt wird?)

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1405071)

Ich habe schon Anwendungen in Sharp, VBNet, Vb6, C++ geschrieben
Nirgendwo habe ich je solche Probleme mit Single gehabt.

Und mit welchen Typen?

Je feiner der typ auflöst, also je größer er ist, um so kleiner werden die Problembereiche und so schwerer wird es sie zu treffen.



Beim Unwandeln dieser Werte in eine Textdarstellung sollte man niemals mehr als die signifikanten Stellen umwandeln, da alles danach quasi "zufällig" ist und diesen Rundungsfehler potenziert darstellt, je weiter man dahinter schaut.

Bei Vergleichen, vor allem Gleich, Kleiner-Gleich und Größer-Gleich, aber auch bei Kleiner und Größer muss man eben auch diese Rundungsfehler mit einbeziehen, was eben IsZero oder CompareValue machen (Delta).


Wer unbedingt genaue Werte braucht, muss auch die passenden Typen verwenden, wie z.B. Currency, BCD oder Dergleichen.


@gammatester: Wer mit solch kleinen Werten arbeitet, muß eben entweder das Delta anpassen oder eine andere Vergleichsmethode verwenden.

[EWeiss]

Zitat:

Beim Unwandeln dieser Werte in eine Textdarstellung

Welche Textdarstellung sorry ich sehe keine.

Delphi-Quellcode:

procedure RenderScale(WinHandle: HWND);
var
  bDone: BOOL;
  K, ID: Integer;
  CountMax: Integer;
  x, x1, y, y1, w, h: Integer;
  nScale: Integer;
begin

  bDone := false;
  CountMax := FaceList.Count - 1;

  ID := ID_FACE;

  for K := 0 to CountMax - 1 do
  begin
    if (ID <> gnFocusID) then
    begin
      rScale := gSprFace.GD_GetObjectScale(ID);
      if (ID = nHoverID) then
      begin
        if (rScale < 1.0) then
        begin
          bDone := true; // Wird hier true geschaltet und bleibt True wenn Single wert nicht stimmt.
          rScale := rScale + SCALE_STEP;

          if (rScale > 1.0) then
          begin
            rScale := 1.0;
            bDone := false;
          end;
          // Flare Animation
          gSprFace.GD_GetObjectBound(ID, w, h);
          nScale := (w - round(w * rScale)) div 2;

          gSprFace.GD_SetObjectVisibility(gnFocusFlare, true);

          gSprFace.GD_GetObjectXY(ID, x, y);
          x1 := x + 63 - nScale;
          y1 := nScale + 10;
          gSprFace.GD_SetObjectXY(gnFocusFlare, x1, y1);
          // Weiter mit ID
          gSprFace.GD_SetObjectScale(ID, rScale);
        end;
      end
      else
      begin
        if (rScale > SCALE_DEFAULT) then // stimmt dieser wert nicht dann ist bDone immer true und löst ein Repaint des gesamten Container aus. 
        begin
          bDone := true;

          rScale := rScale - SCALE_STEP;
          if (rScale < SCALE_DEFAULT) then
          begin
            rScale := SCALE_DEFAULT;
            gSprFace.GD_SetObjectVisibility(gnFocusFlare, false);
            bDone := false;
          end;

          gSprFace.GD_SetObjectScale(ID, rScale);
        end;
      end;
    end;
    dec(ID);
  end;

  if (bDone) then
    gSprFace.GI_UpdateWindow(WinHandle, false); // Hier Problem wenn Single wert nicht stimmt = 35% CPU Auslastung.
end;

Zitat:

Und mit welchen Typen?

Beatwortet sich von selbst mit Single natürlich.
Wie der Compiler das innerhalb berechnet kann mir letztendlich egal sein.
Die dort verwendeten Compiler scheinen es richtig zu verstehen, Delphi hingegen nicht! (Extra Wurst halt) ;)

gruss

[gammatester]

Zitat:

Zitat von himitsu (Beitrag 1405076)

@gammatester: Wer mit solch kleinen Werten arbeitet, muß eben entweder das Delta anpassen oder eine andere Vergleichsmethode verwenden.

Sag ich ja: Wenn man keine Ahnung hat benutzt man die Default-Werte und macht (wie Borland/Emba beim sinh) haarsträubende Fehler. Wenn man weiß, wo die Probleme sind, dann braucht man diese Routinen nicht.

Im übrigen ist 1e-20 geradezu erschreckend groß im Vergleich zu 1e-300 oder 1e-4000.

[EWeiss]

Zitat:

Zitat von gammatester (Beitrag 1405078)

Zitat:

Zitat von himitsu (Beitrag 1405076)

@gammatester: Wer mit solch kleinen Werten arbeitet, muß eben entweder das Delta anpassen oder eine andere Vergleichsmethode verwenden.

Sag ich ja: Wenn man keine Ahnung hat benutzt man die Default-Werte und macht (wie Borland/Emba beim sinh) haarsträubende Fehler. Wenn man weiß, wo die Probleme sind, dann braucht man diese Routinen nicht.

Im übrigen ist 1e-20 geradezu erschreckend groß im Vergleich zu 1e-300 oder 1e-4000.

Sorry das ich das jetzt sage.. Eigentlich für mich egal.
Was zählt ist das ich eine Lösung wenn auch eine für mich unverständliche gefunden habe.
Ich bin nicht der Informatiker so wie ihr von daher zählt für mich das Ergebnis nicht das was dahinter steckt.

@gammatester
Danke nochmal für deine Hilfe und den Anstoß die Lösung zu finden.
PS: Interessant ist es aber trotzdem zu lesen.

gruss