Rundungsfehler bei Division
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo SAP-Freunde,
ich stehe vor einem Problem und würde gerne wissen, warum sich SAP so verhält.
Folgende einfache Rechnung:
DATA: ergebnis TYPE salk3,
wert1 TYPE salk3,
wert2 TYPE salk3.
ergebnis = wert1 / wert2.
Funktioniert soweit ganz gut, wenn aber z.B. wert1 = 4,57 und wert2 = 992, dann kommt als Ergebnis = 0,00. Das ist aber definitiv falsch, weil 4,57 / 992 ergibt 0,0046 und wäre gerundet auf 2 Dezimalstellen eigentlich 0,01. Könnt ihr mir erklären, warum sich SAP hier falsch verhält? Wie kann ich das besser machen?
Vielen Dank schon mal für Eure Hilfe,
Daniel
ich stehe vor einem Problem und würde gerne wissen, warum sich SAP so verhält.
Folgende einfache Rechnung:
DATA: ergebnis TYPE salk3,
wert1 TYPE salk3,
wert2 TYPE salk3.
ergebnis = wert1 / wert2.
Funktioniert soweit ganz gut, wenn aber z.B. wert1 = 4,57 und wert2 = 992, dann kommt als Ergebnis = 0,00. Das ist aber definitiv falsch, weil 4,57 / 992 ergibt 0,0046 und wäre gerundet auf 2 Dezimalstellen eigentlich 0,01. Könnt ihr mir erklären, warum sich SAP hier falsch verhält? Wie kann ich das besser machen?
Vielen Dank schon mal für Eure Hilfe,
Daniel
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
also 4,57 / 992 ergibt 0,0046 und wäre gerundet auf 2 Dezimalstellen eigentlich 0,01.
Nein ist bei 2 Kommastellen 0,00 erst bei 0,0050 wird 0,01 erscheinen.
Besser wäre das Ergebnisfeld mit 3 Komma oder 4 Kommastellen zu definieren.
Gruß
Wolfgang
also 4,57 / 992 ergibt 0,0046 und wäre gerundet auf 2 Dezimalstellen eigentlich 0,01.
Nein ist bei 2 Kommastellen 0,00 erst bei 0,0050 wird 0,01 erscheinen.
Besser wäre das Ergebnisfeld mit 3 Komma oder 4 Kommastellen zu definieren.
Gruß
Wolfgang
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Normale Zuweisungen schneidet ABAP intern immer ab. Siehe dazu die Hilfe zum Zuweisungsoperator (=).
Kleiner Tipp:
Gleitkommaberechnungen am Besten mit dem Datentyp F (= Float) machen und dann z.B. mit der Funktion ROUND in die korrekte Darstellung bringen.
Dazu sollten ALLE beteiligten Variablen vom Typ F sein, sonst kann es bei komplizierteren Berechnungen zu unerwünschten Rundungen während der Rechenoperationen kommen.
lg ADT
Kleiner Tipp:
Gleitkommaberechnungen am Besten mit dem Datentyp F (= Float) machen und dann z.B. mit der Funktion ROUND in die korrekte Darstellung bringen.
Dazu sollten ALLE beteiligten Variablen vom Typ F sein, sonst kann es bei komplizierteren Berechnungen zu unerwünschten Rundungen während der Rechenoperationen kommen.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Dann aber hoffentlich richtig und nicht wie im ersten Posting beschrieben 
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wurde doch schon geschrieben: FLOAT und ROUND.schusterd hat geschrieben:was wäre denn der richtige Weg?
Bei vier Dezimalstellen passt es bei deinem Bespiel, es gibt aber genügend, die wiederum abgeschnitten würden (mehr als 4 Nachkommastellen beim Ergebnis).
Gruß Hendrik
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Echt? Was wäre denn dann die Ausgabe von folgendem Programm - mit Begründung? ( Bitte im Kopf simulieren bevor das im Programm einfach ausprobiert wird )a-dead-trousers hat geschrieben:Normale Zuweisungen schneidet ABAP intern immer ab. Siehe dazu die Hilfe zum Zuweisungsoperator (=).
Code: Alles auswählen.
REPORT.
*TYPES: my_type TYPE p DECIMALS 2.
TYPES: my_type TYPE i.
DATA: x TYPE my_type, y TYPE my_type, z TYPE my_type, result TYPE my_type.
x = 20.
y = 3.
z = 20.
result = ( x / y ) * z.
WRITE:/ result.Code: Alles auswählen.
my_type type p decimals 2.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Bin mir jetzt nicht ganz sicher, ab wann ABAP die "Basis" für die Berechnung festlegt: Schon von Anfang an (alles integer) oder erst am Ende (Zwischenschritte in Float).
Das Problem versuche ich stets zu vermeiden indem ich immer FLOAT verwende.
Im ersten Ansatz würde ich daher eher 133 und 133,33 als Ergebnis erwarten.
Die zweite Möglichkeit wäre 120 und 133,20.
Auch wenn meine Aussage mit dem = vielleicht nicht ganz korrekt war, unterstreicht das ja genau das Problem, das man bei Berechnungen aufpassen muss, mit welchen Datentypen man hantiert. Also am Besten immer alles in der größten Genauigkeit berechnen und erst ganz zum Schluss das Format festlegen.
Das Problem versuche ich stets zu vermeiden indem ich immer FLOAT verwende.
Im ersten Ansatz würde ich daher eher 133 und 133,33 als Ergebnis erwarten.
Die zweite Möglichkeit wäre 120 und 133,20.
Auch wenn meine Aussage mit dem = vielleicht nicht ganz korrekt war, unterstreicht das ja genau das Problem, das man bei Berechnungen aufpassen muss, mit welchen Datentypen man hantiert. Also am Besten immer alles in der größten Genauigkeit berechnen und erst ganz zum Schluss das Format festlegen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Die Basis wird vor der Berechnung festgelegt - aber das von dir erwähnte "Abschneiden" (auch in Zwischenschritten) stimmt gerade nicht sondern es wird gerundet.a-dead-trousers hat geschrieben:Bin mir jetzt nicht ganz sicher, ab wann ABAP die "Basis" für die Berechnung festlegt: Schon von Anfang an (alles integer) oder erst am Ende (Zwischenschritte in Float).
"Zwischenschritte in Float" gilt im Allgemeinen auch nicht sondern nur falls als Basis auch "Float" ermittelt wurde. Für "Basis" Integer wird alles in Integer gerechnet und für Basis vom Typ "P" gilt eine besondere Regel.
-->
140 bzw 133,33 wären die Ergebnisse
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
4250
Views
Views
6
Antw.
Antw.
7549
Views
Views
5
Antw.
Antw.
2947
Views
Views
1
Antw.
Antw.
2132
Views
Views
Division in Query mittels lokalem Feld
von peterlustig007 » 05.04.2007 09:06 • Verfasst in Sonstige Module
von peterlustig007 » 05.04.2007 09:06 • Verfasst in Sonstige Module
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1138
vor 2 Tagen von DeathAndPain 4 / 1138
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1138
vor 2 Tagen von DeathAndPain 4 / 1138