Unterschiedliche Ergebnisse beim Runden

[Ghostwalker]

Zitat:

Zitat von Luckie (Beitrag 1378732)

Moment. So habe ich es in der Schule gelernt. Ab 0,5 und drüber wird aufgerundet, da runter abgerundet. Und nicht auf die nächst gerade Zahl.

Eventuell sollten wir Begriffe definieren. Mathematisch, wie oben beschrieben. Kaufmännisch und dieses Bänker runden.

Mathematisch, siehe oben, wie in der Schule gelehrt.

Über diese verschiedenen Rundungsverfahren habe ich mir schon immer den Kopf zerbrochen. :roll:

[KLUGSCHEISSMODUS ON]
Alle drei sind mathematisch korrekte Rundungsmethoden.

kaufmännische Rundung: Alles incl. 0.5 wird aufgerundet.
technische Rundung: 0.5 und darunter wird abgerundet.

mathematische Rundung (bankers rounding):

.00 bis .49 wird abgerundet
.60 bis .99 wird aufgerundet
.51 bis .59 wird aufgerundet

.50 wird derart gehandelt,das die beizubehaltende Zahl zur nächsten geraden Zahl gerundet wird.
Bsp dafür:

2.25 wird zu 2.2
2.35 wird zu 2.4


Letzteres ist bereits auf Prozessor-Ebene so implementiert (zumindest bei x86) und wird standardmäßig
von den entsprechenden Sprachen incl(Delphi....schon seit Turbo Pascal-Zeiten) so für Rundungen verwendet.

https://de.wikipedia.org/wiki/Rundung
[/KLUGSCHEISSMODUS OFF]

und hier mal meine Routine für alle drei Methoden:

Delphi-Quellcode:

TYPE
   TRoundMethod = (rmKfm,rmTec,rmMat);

function RoundDirect(zahl:extended;dezimalstellen:Byte;methode:TRoundMethod=rmKfm):extended;
var
  hlp,hlp2,di : Extended;

begin
  di := Power(10,dezimalstellen);
  hlp := trunc(zahl*di);
  hlp2 := (zahl*di)-hlp;
  case methode of
     rmKfm : if (hlp2 >= 0.5) then hlp := hlp+1;
     rmTec : if (hlp2 > 0.5) then hlp := hlp+1;
     rmMat: begin
               if (hlp2 > 0.5) then hlp := hlp+1
               else
               begin
                 if (odd(trunc(hlp))) then hlp := hlp +1;
               end;

             end;
  end;
  result := hlp/di;
end;

[Luckie]

Zitat:

mathematische Rundung (bankers rounding):

.00 bis .49 wird abgerundet
.60 bis .99 wird aufgerundet
.51 bis .59 wird aufgerundet

.50 wird derart gehandelt,das die beizubehaltende Zahl zur nächsten geraden Zahl gerundet wird.
Bsp dafür:

2.25 wird zu 2.2
2.35 wird zu 2.4

Und genau so habe ich es in der Schule im Matheunterricht nicht gelernt. Da wurde mir beigebracht, dass 0,5 immer aufgerundet wird und nicht zur nächsten geraden Ziffer. Also wird in der Mittelstufe im Matheunterricht das technische Runden gelehrt?

[samso]

Zitat:

Zitat von Luckie (Beitrag 1378762)

Und genau so habe ich es in der Schule im Matheunterricht nicht gelernt. Da wurde mir beigebracht, dass 0,5 immer aufgerundet wird und nicht zur nächsten geraden Ziffer. Also wird in der Mittelstufe im Matheunterricht das technische Runden gelehrt?

Die Vermittlung mehrere Rundungsverfahren würde euch verunsichern. :wink:

Die Wahl des Rundungsverfahrens hängt doch von der Anwendung ab. Wenn der Schlüssel ins Schloss passen soll, ist es günstiger bei der Berechnung abzurunden, damit es am Ende nicht klemmt.

[Jasocul]

Zitat:

Zitat von Luckie (Beitrag 1378762)

Also wird in der Mittelstufe im Matheunterricht das technische Runden gelehrt?

Das nennt sich"kaufmännisches Runden" oder auch "bürgerliches Runden" und reicht für den Alltag völlig aus. Da es eine sehr einfache Form der Rundung ist und i.d.R. für den Alltag völlig ausreichend ist, wird diese auch in der Schule unterrichtet. Ich meine mal gehört zu haben, dass es dafür sogar eine DIN-Norm gibt. Die Abweichungen im kaufmännischen Bereich sind zu vernachlässigen. Deshalb wird diese Rundung auch bei Rechnungen, Steuererklärungen, ... verwendet.

Die andere Form der Rundung spielt insbesondere bei Statistiken eine Rolle, da dadurch die die Ergebnisse weniger verfälscht werden. Daher wird es auch verzerrungsfreie Rundung genannt. Ich glaube dass es auch bei der Vermessung und Navigation eine Rolle spielt, aber das ist schon so lange her, dass ich mir nicht mehr ganz sicher bin. Der Einsatz ist daher eher im mathematisch-technischen Bereich zu finden.

[Luckie]

Belassen wir es dabei. Wenn ich es mal brauche, kann ich mich ja noch mal informieren. :roll:

[mensch72]

..."ist ja mathematisch falsch. Wie kommen die auf die Regel zur nächsten geraden Zahl zu runden?"...
also wir habe das Runden von ".5" per "GeradZahlRegel" schon in der Schule in Mathematik so gelernt und dann überall in Physik, Chemie, E-Technik uws. angewannt.
Bei uns nannte man die ersten 10Jahre die Schule "POS" ala "Polytechnische-Oberschule", und zumindest Mathematik und Naturwissenschaften wurden da garnicht so schlecht und sogar fast politikfrei gelehrt.

Mathematisch und vor allem statistisch dient die "GeradZahlRegel" der Gleichverteilung der Rundungsfehler, was sich problemlos beweisen lässt.
Aber da es nunmal so ist, das es heute teils von Bundesland zu Bundesland und Schulart zu Schulart verschiedene Lehrstandards gibt und die Diskussion darüber müßig ist, haben wir unsere Software zentral einstellbar gemacht, da kann der Chef es sich so festlegen, das es so ist wie er es gelernt hat und/oder es für richtig hält:)

Das Grundsatzproblem der nunmal FPU und letztendlich doch binär basierten Fließkommatypen kommt ja immer noch dazu, und sollte VOR DEM RUNDEN beachtet werden... also erst mal die "gewollte Zahl" REKONSTRUIEREN, dann das Ergebnis wie es so schön heißt auf nötige und sinnvolle Genauigkeit RUNDEN.



Wen all das eigentlich garnicht interessiert, der nehme einfach "integer:=Round(double);" und es wird zu 99% etwas sinvolles heraus kommen.

[Amateurprofi]

Hallo Richard,
Es ist ja schön, dass du dein Problem gelöst hast, wie in #20 gezeigt, aber es wäre doch noch etwas schöner, wenn auch geklärt worden wäre, was eigentlich das Problem war.
Leider hast du auf die direkte Frage in #4 "Welche Typen haben Zahl und Multi?" nicht geantwortet.
In den Screenshots konnte man sehen, dass Multi den Wert 10 und Zahl den Wert 0.075 hatte, wobei interessant gewesen wäre, wie der Wert 0.075 entstanden war.

In den vielen Themen wurde leider meist an deinem Problem vorbei geredet, denn mit den unterschiedlichen Methoden des Rundens hatte das nichts zu tun.

Das Problem ist, dass Zahlen, die in dezimaler Schreibweise exakt dargestellt werden können, in binärer Schreibweise nicht exakt darstellbar sind.

Ich hab mal geprüft, wie die Werte X=0.075 und 10*X in der FPU aussehen, wenn vorher X unterschiedliche Typen hat.
In der nachstehenden Tabelle seht ihr jeweils den Typ von X, den Wert in der FPU in dezimaler Darstellung mit 20 Nachkommstellen und den Speicherauszug des Wertes in der FPU.

Code:

CPU interne Darstellung von X=0.075, wobei X den jeweils angegebenen Typ hat:
Single    0.07500000298023223880  00 00 00 00 00 9A 99 99 FB 3F
Real48    0.07500000000004547470  00 00 00 9A 99 99 99 99 FB 3F
Double    0.07499999999999999720  00 98 99 99 99 99 99 99 FB 3F
Extended  0.07500000000000000000  9A 99 99 99 99 99 99 99 FB 3F

CPU interne Darstellung von 10 * X=0.075, wobei X den jeweils angegebenen Typ hat:
Single    0.75000002980232238800  00 00 00 00 80 00 00 C0 FE 3F
Real48    0.75000000000045474700  00 00 80 00 00 00 00 C0 FE 3F
Double    0.74999999999999997200  00 FE FF FF FF FF FF BF FE 3F
Extended  0.75000000000000000000  00 00 00 00 00 00 00 C0 FE 3F

Man sieht sehr schön, dass wenn 0.075 in einem Double gespeichert war, in der FPU daraus ein Wert wird, der geringfügig kleiner ist.
Das Gleiche passiert auch bei dem mit 10 multiplizierten Wert, der dann, auf 7 gerundet wird, und zwar unabhängig davon, welche Methode der Rundung verwendet wird.

Die Tabelle wurde mit der nachstehenden Routine erstellt:

Delphi-Quellcode:

PROCEDURE TestRounding;
type TTBA=Array[0..9] of Byte;
PROCEDURE Store(Value:Extended; Typ:String; var S:String);
var I:Integer; T:String;
begin
   Str(Value:0:20,T);
   S:=S+#13#10+Typ+'  '+T+' ';
   for I:=0 to 9 do S:=S+' '+IntToHex(TTBA(Value)[I],2);
end;
const
   H1='CPU interne Darstellung von X=0.075, wobei X den jeweils angegebenen Typ hat:';
   H2='CPU interne Darstellung von 10 * X=0.075, wobei X den jeweils angegebenen Typ hat:';
   ZahlS:Single=0.075;
   ZahlR:Real48=0.075;
   ZahlD:Double=0.075;
   ZahlE:Extended=0.075;
var I:Integer; S:String;
begin
   S:=H1;
   Store(ZahlS,'Single  ',S);
   Store(ZahlR,'Real48  ',S);
   Store(ZahlD,'Double  ',S);
   Store(ZahlE,'Extended',S);
   S:=S+#13#10#13#10+H2;
   Store(10*ZahlS,'Single  ',S);
   Store(10*ZahlR,'Real48  ',S);
   Store(10*ZahlD,'Double  ',S);
   Store(10*ZahlE,'Extended',S);
   Clipboard.AsText:=S;
end;

[Uwe Raabe]

Zitat:

Zitat von Amateurprofi (Beitrag 1378827)

In den Screenshots konnte man sehen, dass Multi den Wert 10 und Zahl den Wert 0.075 hatte, wobei interessant gewesen wäre, wie der Wert 0.075 entstanden war.

Das ist nicht ganz richtig: In dem ScreenShot aus #1 hat Multi den Wert 100. Andernfalls wäre ja auch nicht 7,5 das erwartete Ergebnis.

Ansonsten hast du natürlich recht mit der internen Darstellung.

Das folgende Beispielprogramm demonstriert das (zumindest unter Win32):

Delphi-Quellcode:

program Project262;

{$APPTYPE CONSOLE}

var
  MultiS: Single;
  WertS: Single;
  MultiD: Double;
  WertD: Double;
begin
  MultiS := 100;
  MultiD := 100;
  WertS := 0.075;
  WertD := 0.075;
  Writeln('Single: ', Round(MultiS * WertS));
  Writeln('Double: ', Round(MultiD * WertD));
  Readln;
end.

Es lässt sich aber auch zeigen, daß die Verwendung der von mir vorgeschlagenen Unit das Problem löst:

Delphi-Quellcode:

program Project263;

{$APPTYPE CONSOLE}

uses
  DecimalRounding_JH1;

var
  MultiS: Single;
  WertS: Single;
  MultiD: Double;
  WertD: Double;
begin
  MultiS := 100;
  MultiD := 100;
  WertS := 0.075;
  WertD := 0.075;
  Writeln('Single: ', Round(MultiS * WertS));
  Writeln('Double: ', Round(MultiD * WertD));
  Writeln('Single JH: ', DecimalRoundSgl(MultiS * WertS, 0));
  Writeln('Double JH: ', DecimalRoundDbl(MultiD * WertD, 0));
  Readln;
end.

[Amateurprofi]

@Uwe,
Oh, das ist mir jetzt aber peinlich.
Na klar war Multi=100 gesetzt.
Ich hab noch mal die Tabelle auf Basis Multi=100 erstellt.

CPU interne Darstellung von X=0.075, wobei X den jeweils angegebenen Typ hat:
Single 0.07500000298023223880 00 00 00 00 00 9A 99 99 FB 3F
Real48 0.07500000000004547470 00 00 00 9A 99 99 99 99 FB 3F
Double 0.07499999999999999720 00 98 99 99 99 99 99 99 FB 3F
Extended 0.07500000000000000000 9A 99 99 99 99 99 99 99 FB 3F

CPU interne Darstellung von 100 * X=0.075, wobei X den jeweils angegebenen Typ hat:
Single 7.50000029802322388000 00 00 00 00 A0 00 00 F0 01 40
Real48 7.50000000000454747000 00 00 A0 00 00 00 00 F0 01 40
Double 7.49999999999999972000 80 FD FF FF FF FF FF EF 01 40
Extended 7.50000000000000000000 01 00 00 00 00 00 00 F0 01 40

[freimatz]

Zitat:

Zitat von mensch72 (Beitrag 1378719)

Ein Teil unseres Hauptgeschäfts ist der Finanzbereich, ...
Wir meiden "double" wie der Teufel das Weihwasser, ...

Das möchte ich nochmals unterstreichen. Bei Währungen verwendet "man" NIE, NIE (In Worten NIE) Fließkomma.