Suchergebnisse

Zitat von Drahuverar: „richtig?“Ja. Das ganze ist ziemlich blöd, weil nicht definiert ist, wie die nicht gerundete Zahl dargestellt wird: Wert gleich kaufmännisch runden: 36,88499999999999 ==> 36,88 => zuerst auf 3 Nachkommastellen runden, danach kaufmännisch runden: 36,885 ==> 36,89

Zitat von Drahuverar: „36,8849 => 36,885 => 36,89“Diese Rundung wäre in meinen Augen falsch, deswegen sollte da der Input der internationalen Kaufmännisch-Währungs-Rundungs-Gesellschaft ( ) eingeholt werden.

Zitat von Snaptu: „wenn möglich auf die exakte Zahl zurückgegriffen werden“heißt dann ganz klar, dass die Zahl lediglich bei der Ausgabe gerundet wird, Floor und Ceil sind nicht vonnöten, es genügt .ToString("N2") oder ein äquivalentes Format: VB.NET-Quellcode (2 Zeilen) ----- Das müsste eigentlich im Finanzministerium zu erfahren sein. --- Zitat von Bundesfinanzministerium, Monatsbericht_BMF_0603_gesamt und andere: „Abweichungen in den Summen durch Runden der Zahlen.“

Zitat von Drahuverar: „Return Math.Floor(val * (10 ^ dec)) / (10 ^ dec)“Das kann auch vor die Hose gehen, da Du durch das Potenzieren numerische vom Arithmetikprozessor stammende Rundungsfehler erzeugst (in der 17. Stelle oder so).

Zitat von Snaptu: „weil allein Währungstechnisch die 3. Stelle schon garnicht existiert.“Nö. Bei Zinsen und Zinseszinsen wird mit mehr Stellen geerchnet.

@dive26 Wahrscheinlich hat noch keiner gemerkt, dass es Überladungen der Math.Round()-Funktion gibt, die sagt, wie gerundet werden soll: VB.NET-Quellcode (4 Zeilen)

@dive26 Ich habe das NUD auf 3 Nachkommastellen mit einem Increment von 0,001 eingestellt. Beim Runden werden ja alle vorhandenen Nachkommastellen berücksichtigt. Wenn Du das nicht willst, musst Du zunächst auf 3 Stellen und das Ergebnis weiter auf 2 Stellen runden.