![]() |
Unterschiedliche Ergebnisse beim Runden
Liste der Anhänge anzeigen (Anzahl: 2)
Hey Community,
ich stehe vor einem Problem, welches ich im Moment nicht verstehe. Ich möchte eine Zahl runden mit folgendem Code
Code:
Der Wert der sich aus der Multiplikation ergibt lautet 7.50000000000728
var i: Int64;
begin [...] i:= Round(zahl*multi); [...] end; Das sollte gerundet 8 ergeben. In i wird allerdings 7 gespeichert. Wenn ich aber den Ausdruck auswerte, erhalte ich 8. Im Anhang sind nochmal zwei Bilder. Mache ich etwas falsch? |
AW: Unterschiedliche Ergebnisse beim Runden
Hallo,
traue diesen "überwachten Ausdrücken" einfach nicht ... Wie oft ich da schon drüber gestolpert bin bei TDateTime. |
AW: Unterschiedliche Ergebnisse beim Runden
In einem neuem Projekt ergibt
Code:
i = 8.
var
i: Int64; begin i:= Round(7.50000000000728); Das soll mal einer verstehen :? |
AW: Unterschiedliche Ergebnisse beim Runden
Es ist auch ein Unterschied zwischen eine Berechnung und einer Konstante.
Welche Typen haben Zahl und Multi? |
AW: Unterschiedliche Ergebnisse beim Runden
Round(FesteGleitkommazahl) ist was anderes als Round(ZahlEinesTyps * ZahlEinesAnderenTyps).
Von welchem Typ sind zahl und multi? Vor dem Aufruf von Round werden die Zahlen, sofern sie von unterschiedlichem Typ sind, in einen "einheitlichen" Typ gewandelt, das kann dann schonmal schiefgehen bzw. nicht zum erwarteten Ergebnis führen. Wenn ich sowas auf die unelegante Art mache, dann sieht das ungefähr so aus:
Delphi-Quellcode:
Dadurch werden ggfls. Integerwerte erstmal in Gleitkomma umgewandelt, damit bei der Berechnung Nachkommastellen erhalten bleiben.
i := Round((zahl + 0.00) * (multi + 0.00));
Das kann so funktionieren, muss aber nicht. Wenns nicht anders geht dann eher sinngemäß sowas:
Delphi-Quellcode:
Und nein, das ist nicht elegant :-(
var i: Int64;
dZahl : Double; dMulti : Double; dGes : Double; begin [...] dZahl := zahl; dMulti := multi; dGes := dZahl * dMulti; i := Round(dGes); [...] end; |
AW: Unterschiedliche Ergebnisse beim Runden
Schau mal in der Hilfe nach, dort wird der Standard-Modus rmNearest beschrieben und zur besseren Erläuterung ein Link zu einem Blog bei Microsoft geteilt.
Zitat:
Grüße Mikhal |
AW: Unterschiedliche Ergebnisse beim Runden
Ich verwende in solchen Fällen immer die Routinen von John Herbster:
![]() Wenn man jetzt ein kleines Testprogramm hätte, das den Fehler reproduziert, dann könnte man auch sehen, ob er damit behoben wird. |
AW: Unterschiedliche Ergebnisse beim Runden
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 |
AW: Unterschiedliche Ergebnisse beim Runden
ich habe mir mal hiermit beholfen:
Delphi-Quellcode:
Gruß
integer:=trunc(fließkomma+0.5);
K-H |
AW: Unterschiedliche Ergebnisse beim Runden
Also das:
Code:
ist ja mathematisch falsch. Wie kommen die auf die Regel zur nächsten geraden Zahl zu runden?
0.5 rounds to 0
|
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
|
AW: Unterschiedliche Ergebnisse beim Runden
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; |
AW: Unterschiedliche Ergebnisse beim Runden
Lustig wird es, wenn man Geräte wie einen Fiskaldrucker ansteuert. Da muss man dann nämlich exakt genauso runden wie der es tut.
|
AW: Unterschiedliche Ergebnisse beim Runden
@Uwe: Danke. Aber ich hätte das mathematische korrekte Runden als Standard gewählt.
|
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
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. :-D |
AW: Unterschiedliche Ergebnisse beim Runden
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: |
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
|
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
Gruß K-H |
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
![]() ![]() ![]() ![]() 8086 = CPU (central processing unit) ![]() GPU (graphics processing unit) .... uhhh, Codename "Pascal" für nvidia GeForce 1000er Serie (GeForce GTX 1060, ...) Southbridge, Northbridge, Soundcard usw. Damals waren das noch einzelne Chips, aber Heute ist das ja oft nur noch ein Chip. Bei 7.50000000000728 muß man eben aufpassen, ob es auch in die Variable passt, bevor es gerundet wird und auch nach dem Runden. Wenn es nur das mathematische Ergebnis ist, aber der Typ das nur als 7.499999998 speichert, dann wird da eventuell anders gerundet. Also in einem Single sollte der Wert schonmal nicht gespeichert werden, da dort nicht genug signifikante Dezimalstellen existieren. |
AW: Unterschiedliche Ergebnisse beim Runden
Danke für eure zahlreichen Antworten.
Habe es jetzt folgendermaßen gelöst. Anstatt
Code:
so
var i: Int64;
begin [...] i:= Round(zahl*multi); [...] end;
Code:
var i: Int64;
d: double; begin [...] d:= zahl * multi; i:= Round(d); end; |
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
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. ![]() [/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; |
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
|
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
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. |
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
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. |
AW: Unterschiedliche Ergebnisse beim Runden
Belassen wir es dabei. Wenn ich es mal brauche, kann ich mich ja noch mal informieren. :roll:
|
AW: Unterschiedliche Ergebnisse beim Runden
..."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. |
AW: Unterschiedliche Ergebnisse beim Runden
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:
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.
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 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; |
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
Ansonsten hast du natürlich recht mit der internen Darstellung. Das folgende Beispielprogramm demonstriert das (zumindest unter Win32):
Delphi-Quellcode:
Es lässt sich aber auch zeigen, daß die Verwendung der von mir vorgeschlagenen Unit das Problem löst:
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.
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. |
AW: Unterschiedliche Ergebnisse beim Runden
@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 |
AW: Unterschiedliche Ergebnisse beim Runden
Zitat:
|
AW: Unterschiedliche Ergebnisse beim Runden
Dafür gibt es ja auch den Datentyp Currency.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz