Unterschiedliche Ergebnisse beim Runden

[Uwe Raabe]

Ich verwende in solchen Fällen immer die Routinen von John Herbster: ID: 21909, DecimalRounding (JH1).

Wenn man jetzt ein kleines Testprogramm hätte, das den Fehler reproduziert, dann könnte man auch sehen, ob er damit behoben wird.

[mensch72]

Ein Teil unseres Hauptgeschäfts ist der Finanzbereich, und speziell da gibt es von KundeZuKunde Unterschiede in den Vorgaben, wie die ".5er" Rundungsregel ausfallen soll.

Wir meiden "double" wie der Teufel das Weihwasser, heißt wir rechnen intern eh fast alles selbst mit einem eigenen 48..64Bit FixComma Typen mit eigenen überladenen Operatoren was(seit Delphi2007) problemlos funktioniert.
- wir bevorzugen und setzen als Defaulteinstellung für uns bei "exakt .5" die GERADZAHLREGEL. Bei ungenauen 0.5 knapp drüber oder knapp drunter runden wir auf oder ab.
- wir bieten eine externe Epsilon Anpassung, um den Bereich des "exakt .5" bei Bedarf selbst passend zu beeinflussen
- wir bieten optional auch eine statische Festlegung der Rundungsrichtung bei "exakt .5", also kann ein Kunde wenn er möchte da immer auf oder abrunden
- unsere Einstellungen gelten immer programmweit und ohne Beachtung und Kenntnis des Berechnungszwecks... kein Kunde kann sagen er möchte alles fürs eignene Haben aufgerundet und alles fürs eigene Soll abgerundet bekommen... auch wenn mindestens ein Konkurrenzprodukt sowas bietet weigere ich mich das auch so zu programmieren... wie man sieht ist "Rundung" also ein sehr komplexes und teils auch emotionales oder gar rechtlich durchaus relevantes Thema

[p80286]

ich habe mir mal hiermit beholfen:
integer:=trunc(fließkomma+0.5); Gruß
K-H

[Luckie]

Also das:

Code:

0.5 rounds to 0

ist ja mathematisch falsch. Wie kommen die auf die Regel zur nächsten geraden Zahl zu runden?

[Uwe Raabe]

Zitat von Luckie:

Wie kommen die auf die Regel zur nächsten geraden Zahl zu runden?

Dieses sogenannte Banker's Rounding soll die Gleichverteilung der Ergebnisse gewährleisten. Andernfalls würde das Aufrunden ja tendenziell bevorzugt. Mit dem Banker's Rounding hält man den Summen-Rundungsfehler statistisch in engeren Grenzen.

[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.

[Thomas Feichtner]

Hallo,

für das kaufmännische Runden verwende ich folgende Funktion:

Delphi-Quellcode:

function  xRound(e: Extended; d: Integer ): Extended;
var
  nWert1: Extended;
  nTemp1: Currency;
begin
  { Zuerst Zahl multiplizieren, damit diese als Currency arbeiten kann
    damit bei xRound(2.51 * (100 - 74.5) / 100, 4) = 0.6401 auskommt und nicht
    0.64 }
  // Wenn Grenzwerte überschritten werden, wird geschützt gearbeitet
  if (d>4) or (abs(e)>999999) then begin
    try
      nTemp1 := e * IntPower(10, d - 1);
    except
      Result := e;
      exit;
    end;
  end
  else begin
   nTemp1 := e * IntPower(10, d - 1);
  end;

  if nTemp1 < 0.0 then
    nTemp1 := Trunc(nTemp1 * IntPower(10, 1) - 0.5 ) / IntPower(10, 1)
  else
    nTemp1 := Trunc(nTemp1 * IntPower(10, 1) + 0.5 ) / IntPower(10, 1);
  nWert1 := nTemp1 / IntPower(10, d - 1);
  
  Result := nWert1;
end;

[jaenicke]

Lustig wird es, wenn man Geräte wie einen Fiskaldrucker ansteuert. Da muss man dann nämlich exakt genauso runden wie der es tut.

[Luckie]

@Uwe: Danke. Aber ich hätte das mathematische korrekte Runden als Standard gewählt.

[Benedikt Magnus]

Zitat von Luckie:

@Uwe: Danke. Aber ich hätte das mathematische korrekte Runden als Standard gewählt.

Dieses merkwürdige Runden ist das "mathematisch korrekte" (was sowieso nur eine Definitionssache darstellt), vor allem im statistischen Bereich ist das sehr wichtig, aber auch überall sonst sorgt es dafür, wie Uwe bereits beschrieben haben, dass die Rundungen in größerem Kontext unverzerrt bleiben.
Das kaufmännische Runden, die Juristen nennen es "Bürgerliches Runden", ist lediglich die einfachere Variante, die dann eingesetzt wird, wenn die Verzerrung durch das häufigere Aufrunden irrelevant ist oder in Kauf genommen wird. Sprich vor allem im kaufmännischen und schulischen Bereich.
Ich muss zugeben, dass ich die mathematisch korrekte Variante vor dem Statistikteil meines Studiums auch nicht kannte. Ist aber auch nicht die einzige mathematische Methode, die man jahrelang "salopp" beigebracht bekommt und erst dann richtig, wenn man sie wirklich braucht.