Ich dreh durch! wie kann das sein - Problem beim Runden.

[Cyberstorm]

bei folgendem code kommt bei mir einmal 1.14 raus (obwohl 1.13 rauskommen soll) und bei der direkten variante 1.13 obwohl s1 und s2 beide male 2.26 ist und das der gleiche verdammte aufruf ist *Grml*.
bei allen anderen zahlen die ich damit so runde hat das super geklappt nur bei dieser konstellation nicht :-/. wenn man z.b. a[5] durch 0.82 und dafür a[6] durch .021 ersetzt klappts wieder?
ich dreh durch...

Delphi-Quellcode:

uses math;

procedure TForm1.Button1Click(Sender: TObject);
var
  s1, s2: double;
  i: Integer;
  a: array[0..6] of double;
begin
  s1:=0;
  s2:=2.26;
  a[0]:=0.20;
  a[1]:=0.27;
  a[2]:=0.22;
  a[3]:=0.27;
  a[4]:=0.27;
  a[5]:=0.81;
  a[6]:=0.22;
  for i:=0 to 6 do
  s1:=s1 + a[i];
  ShowMessage(FloatToStr(ceil((s1/2)*100)/100));
  Showmessage(FloatToStr(ceil((s2/2)*100)/100));
end;

[gmc616]

Ob ceil die richtige Funktion zum runden ist??
Warum nimmst du nicht round?

[Cyberstorm]

weil round nicht immer aufrundet (was ich will).
ceil schon.

Tritt bei euch diese Merkwürdigkeit denn auch auf????

[DGL-luke]

:shock:

Eigentlich sollte man nicht schon bei drei Stellen an die Grenzen der Double-Genauigkeit stoßen.

Hm. Hast du das selbe Problem wenn du Single oder Float(=Extended) verwendest?

Wenn du nicht mehr als zwei Nachkommastellen brauchst, kannst du Currency verwenden. der hat fixed-point decimals, ist also unbegrenzt genau auf drei stellen.

[OregonGhost]

Also, wenn man diese Zahlen da addiert und dann durch 2 teilt, kommt 1,13 raus. Wenn du das jetzt mal hundert nimmst, bist du bei 113. Wenn jetzt aufgrund der Ungenauigkeit 113,0000000001 da stünde, würde ceil doch korrekterweise auf 114 aufrunden, oder?

[Cyberstorm]

Zitat:

Zitat von DGL-luke

:shock:

Eigentlich sollte man nicht schon bei drei Stellen an die Grenzen der Double-Genauigkeit stoßen.

Hm. Hast du das selbe Problem wenn du Single oder Float(=Extended) verwendest?

Wenn du nicht mehr als zwei Nachkommastellen brauchst, kannst du Currency verwenden. der hat fixed-point decimals, ist also unbegrenzt genau auf drei stellen.

Danke! meine Rettung :-). Mit Currency funzt es wunderbar.

Zitat:

Zitat von OregonGhost

Also, wenn man diese Zahlen da addiert und dann durch 2 teilt, kommt 1,13 raus. Wenn du das jetzt mal hundert nimmst, bist du bei 113. Wenn jetzt aufgrund der Ungenauigkeit 113,0000000001 da stünde, würde ceil doch korrekterweise auf 114 aufrunden, oder?

super erklärung, nu hats geklingelt :-)

Danke Leute.
Und ein nachträglich "Hallo" erstmal.

[Achim Kalwa]

Zitat:

Zitat von Cyberstorm

bei folgendem code kommt bei mir einmal 1.14 raus (obwohl 1.13 rauskommen soll) und bei der direkten variante 1.13 obwohl s1 und s2 beide male 2.26 ist und das der gleiche verdammte aufruf ist *Grml*.
bei allen anderen zahlen die ich damit so runde hat das super geklappt nur bei dieser konstellation nicht :-/. wenn man z.b. a[5] durch 0.82 und dafür a[6] durch .021 ersetzt klappts wieder?
ich dreh durch...

Delphi-Quellcode:

var
  s1, s2: double;
  i: Integer;

Computer können nicht genau rechnen ;-)
Im Ernst: Statt dem von uns Menschen bevorzugten Zehnersystem rechnet der Computer ja im Binärsystem. Zahlen wie 2.26 oder 1.13 können in den Gleitkommatypen wie Single, Double, Extended nicht exakt abgebildet werden:
0.5 = 2 hoch -1 = 1/2
0.25 = 2 hoch -2 = 1/4
0.125 = 2 hoch -3 = 1/8
usw.

Versuche mal, 0.3 als Summe von Zweierpotenzen abzubilden:
0.3 = 1/4 + 1/32 + 1/64 + 1/256 = 0.30078125

Ein Dezimalbruch wie 0.3 kann nur näherungsweise im Binärsystem gespeichert werden, denn dort ist es eine Zahl mit vielen Nachkommastellen, u.U. unendlich periodisch. Durch die begrenzte Länge der Datentypen wird diese Folge von Nachkommastellen irgendwo abgeschnitten; die Zahl ist ungenau. Wenn Du nun diese ungenauen Zahlen addierst, dann addierst Du auch die Fehler.

Für Deine Aufgabe ist daher ein geeigneter Datentyp erforderlich; bei Geldbeträgen bis 4 Nachkommastellen ist "Currency" die richtige Wahl.

Weitere Infos:
http://de.wikipedia.org/wiki/Rechengenauigkeit

[alzaimar]

Ach Leute, einfach mit Double oder Extended rechnen (wobei Double eigentlich immer reicht). Dann das Ergebnis auf die gewünschte Genauigkeit runden, und zwar mit 'RoundTo'.

Bei den Float-Datentypen einfach immer im Hinterkopf haben, das man nicht auf Gleichheit prüfen kann. Um eine Zahl mit einer anderen auf Gleichheit zu prüfen, bildet man die Differenz und prüft, ob das Ergebnis < irgendein Grenzwert ist. Die Math-Unit stellt dafür einige Funktionen bereit: 'IsZero', 'SameValue' und 'CompareValue'.

[Cyberstorm]

Ja, danke auch an Dich nochmal für die Erklärung kalwados!
Leuchtet ein.