Problem mit RoundTo((100*0.01),0)

[RavenIV]

Zitat von peschai:

@DelphiKlaus&Angos
Natürlich habt ihr hier recht, das digitale Speichern von Gleitkommazahlen hat dieses Problem grundsätzlich.
Das Verhalten hier ist aber, daß trotz identischen Typen (alles Double) hier ein unterscheidliches Verhalten/Ergebnis auftritt.
Ich hätte weniger ein Problem wenn dieser DigitaleFehler identisch aufgetreten wäre.
Codegear muss hier ein identisches Verhalten sicherstellen!

Warum muss das CodeGear machen?
In anderen Programmiersprachen gibt es dieses Problem sicher auch.

Für die richtige Verwendung von Double ist der Programmierer zuständig.

[peschai]

@RavenIV
ok nocheinmal etwas deutlicher:
Weil es hier um pure Codegear funktionen geht. Es geht hier nicht um den von uns geschriebenen Sourcecode.
Anders formuliert tritt das problem INNERHALB der codegear math.RoundTo Funktion auf:

Delphi-Quellcode:

function RoundTo(const AValue: Double; const ADigit: TRoundToRange): Double; 
var 
  LFactor: Double; 
begin 
  LFactor := IntPower(10, ADigit); 
  Result := Round(AValue / LFactor) * LFactor; 
end;

"Round(AValue / LFactor) * LFactor;" liefert hier unterschiedlich Ergebnisse.
Wenn im besagten Fall für AValue von Aussen "100.0" oder "Staedteouble=100.0" übergeben wird, so ist das Ergebnis für das Beispiel weiteroben unterschiedlich, was natürlich fatal ist!

[Medium]

Immer das selbe mit den Floats. Es gehört mMn zu den absoluten Grundlagen zu wissen, wie son ein Ding intern ausschaut, und was die Grenzen und Implikationen davon sind. Wenn ich aber etwas verwende, wovon ich gerade mal weiss, dass es das gibt, dann darf ich mich auch nicht wundern, wenn damit Probleme auftreten.
Es ist imho nicht an CodeGear Programmierer über die Bedingungen bei Floats aufzuklären, oder Nichtwissen abzufedern, sondern die Pflicht des Programmieres sich mit den Dingen genau auseinanderzusetzen, die er verwendet. Und dass Floats Ungenaugkeiten nach sich ziehen dürfte hunderttausendfach im Netz dokumentiert sein, allein in der DP sicher schon zigfach. So eine bahnbrechende "Entdeckung" fand hier also ganicht statt

[zecke]

Da bin ich doch etwas überrascht, was ich hier losgetreten habe

Nun, es ist egal, was ich verwende (Double,Extended,Real), es kommt trotzdem jedes Mal das Falsche raus. Auch das Workaround von peschai hat nicht das Richtige geliefert (oder ich habe nicht recht verstanden was genau getan wurde, gut möglich). Ich mache es jetzt so, dass ich *1/100 mache, anstatt *0.01. Das liefert das richtige Ergebnis.

Ist ein halbes Jahr her, dass ich Delphi laufen hatte, demnach bin ich also nur Gelegenheits-Noob Programmierer Ich werde mich also nicht für ein kleines Tool zum Privatgebrauch über die einzelnen Typen informieren. Zeitlich eh nicht möglich.

Da es ja nun klappt, soll es für mich damit geklärt sein. Komisch ist es trotzdem. Aber das überlasse ich mal geschmeidig den Profis hier

Danke alle

[peschai]

Hallo Leute,
Das hier beschriebene Problem scheint immer wieder mit den bekannten Unzulänglichkeiten von Gleitkommazahlen (neudeutsch floats) verwechselt zu werden. Hier geht es um etwas anderes. Obwohl zweimal die selbe gleitkommazahl als deselben typ übergeben wurde, ist das ergebnis anders. und das darf nicht sein. Die Ergebnisse dürfen hier falsch (gleitkomma unzulänglichkeiten) sein aber nicht unterschiedlich (issue um was es geht)! Codegear hat dies ebenfalls erkannt.

Bin über die fixe Fehlerbehebung seitens CodeGear positiv überrascht.
"Issue" wurde dort erkannt und innerhalb eines Tages behoben.
Wenn ich mir allerdings die Versionsnummer anschaue, muss ich wohl die nächste Delphi-Version dafür erstehen .... ?

Zitat:

Report #: 61093 Status: Closed
Variable instead of value wrong result in math.RoundTo
Project: Delphi Build #: 11.0.2902.10471
Resolution: Fixed (Resolution Comments) Resolved in Build: : 12.0.0.12454
Comment: Issue no longer present in internal builds. Automated regression test checked-in.

[Medium]

Der Witz ist allerdings irgendwie, dass mein Delphi 7 mit Single, Real (=Double) und Extended bei allen 3 Vatianten genau das richtige Ergebnis liefert.

[peschai]

@Medium
Hast du vorher "SetRoundMode(rmTruncate);" gesetzt ?

[xZise]

Zitat von Medium:

Der Witz ist allerdings irgendwie, dass mein Delphi 7 mit Single, Real (=Double) und Extended bei allen 3 Vatianten genau das richtige Ergebnis liefert.

Ich kann das Verhalten nicht bestätigen:
Zuerst kommt 1 dann 0 raus.

MfG
xZise

[cruiser]

Zitat von zecke:

... Ich mache es jetzt so, dass ich *1/100 mache, anstatt *0.01. Das liefert das richtige Ergebnis...

ich weiss zwar nicht ob es der Compiler wegoptimiert, aber wäre ein einfaches /100 nichtschon alles was nötig ist? Einen Wert mit 1 zu Multiplizieren macht defacto keinen Sinn

[KLS]

Also mit Version 7.0 (Built 4.453) habe ich auch eine Anzeige von
100 , 1 , 1

Delphi-Quellcode:

uses math;

procedure TForm1.Button1Click(Sender: TObject);
var
  p7,staedte : real;
begin
  staedte := 100;
  p7 := RoundTo((staedte*0.01),0);
  showmessage(floattostr(staedte)); 
  showmessage(floattostr(RoundTo((100*0.01),0)));
  showmessage(floattostr(p7));
end;

Edit: hab (auch) SetRoundMode(rmTruncate) nicht gesetzt. Dann erhalte ich auch 100,1,0