Entwickler-Ecke
Algorithmen, Optimierung und Assembler - Dividieren durch gebrochene Zahlen
HeftCD - Mo 18.06.07 23:14
Titel: Dividieren durch gebrochene Zahlen
ich möchte gerne durch gebrochne Zahlen dividieren.
Bsp: 56654 / 35.456
= 1597,86
Ist der Algo so richtig?
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9:
| function real_teilen(valueue1: real; value2: real): real; var x, y, z: real; begin x := value / value2; y := x * 100; z := int(trunc(y)); z := z / 100; result := z; end; |
Moderiert von
raziel: Code- durch Delphi-Tags ersetzt
Agawain - Mo 18.06.07 23:26
Hi
gehts Dir um kaufmännische Rundung?
Gruß
Aga
Narses - Mo 18.06.07 23:28
Titel: Re: Dividieren durch gebrochene Zahlen
Moin!
HeftCD hat folgendes geschrieben: |
ich möchte gerne durch gebrochne Zahlen dividieren.
[...]
Ist der Algo so richtig?
[...]
|
Ja, der "Algo" ist soweit richtig... :rofl:
Der Rest hat nix mit dem Teilen zu tun, ist aber dafür viel zu umständlich... :?
cu
Narses
Agawain - Mo 18.06.07 23:30
lach nicht Narses, meine Frage war nicht unbegründet
Gruß
Aga
//hier gucken
kmrd ist die ultimative Rundungsformel.
Alzaimar hat zwar gesagt, man müsse 0.5000001 in speziellen Fällen nehmen, aber habs heute mal bei mir getestet, bei mir hat er auch mit 0.5 richtig gerundet, vielleicht hat Alzaimar ja kein Intel Inside *duck und weg...aber natürlich bin ich ihm für den Hinweis dankbar...weil bei sonem *sch....kann man sich nen Wolf suchen
HeftCD - Mo 18.06.07 23:45
achso, nee, kaufmännisch muß nicht unbedingt sein.
hatte das gerade nur auf 2 stellen wegen der Übersichtlichkeit gerundet
56654 / 35.456
1597,8677797833935018050541516245
das muß einfach nur möglichst genau sein.
also 6-7 Stellen hinter dem Komma sollten schon stimmen
alzaimar - Di 19.06.07 08:21
Agawain hat folgendes geschrieben: |
l
//hier gucken
kmrd ist die ultimative Rundungsformel.
Alzaimar hat zwar gesagt, man müsse 0.5000001 in speziellen Fällen nehmen, aber habs heute mal bei mir getestet, bei mir hat er auch mit 0.5 richtig gerundet, vielleicht hat Alzaimar ja kein Intel Inside *duck und weg...aber natürlich bin ich ihm für den Hinweis dankbar...weil bei sonem *sch....kann man sich nen Wolf suchen |
Ich verwende 0.5 seit 25 Jahren oder noch länger 8) und habe die 0.50000001-Sch**** erst vor 3 Wochen zum ersten Mal erlebt. Ich hab meinen Augen nicht getraut. Da es um Kohle (Cent-Beträge) geht, habe ich dann die 0.500001-Krücke implementiert. Der Fehler tritt dann auf, wenn man z.B. MwSt-Beträge (gebrochen rational!) per Floating-Point addiert. Ein Ergebnis ist dann augenscheinlich 1234.55, aber in Wirklichkeit vermutlich sowas wie 1234.54999999999999999999999994. Irgendwie so. Er müsste also eigentlich nach oben runden, tut es aber nicht, weil das Ergebnis eben so 'krumm' ist.
Nicht umsonst gibt es den Currency-Datentyp, der damit locker fertig wird. Ob der aber auch in einer Addition korrekt rundet, muss ich mal testen.
oldmax - Di 19.06.07 09:47
Hi
Nun, wenn's nicht um's abrunden geht, warum nicht einfach nur
Result:=x/y;
??? oder hab ich da was falsch verstanden ?
Gruß oldmax
alzaimar - Di 19.06.07 09:51
Wenns nur ums Rechnen geht, dann reicht x/y, ist doch klar.
r2c2 - Di 19.06.07 13:24
Mal kurz zur Erklärung, warums zu "Rundungsfehlern" kommt:
Nach IEEE was-weiß-ich-wie-viel sind Foats folgendermaßen aufgebaut:
[Vorzeichen][Exponent][Mantisse]
Da es sich hier jeweils um Dualzahlen handelt, lassen sich malnche Zahlen nicht genau darstellen(0,4 z.B. Dezimal ist dieser Wert nicht periodisch. Binär hingegen schon).
Zusätzlich bietet die FPU mehrere Rundungsmodi(abrunden, aufrunden, RoundToNeartestEven und Trunc mein ich). RoundToNeartestEven entspricht am ehesten dem kaufmännischen Runden(aber nicht ganz). So wird 0,5 abgerundet, 1,5 aber aufgerundet. Zur nächsten Geraden Zahl hin eben.
Currency macht es hier einfacher. AFAIR ist das eine Implementierung von BCD-Zahlen(d.h. es wird intern nicht binär, sondern dezimal gerechnet(ICh nehm an das emuliert Delphi, k.a. hab momentan kein Delphi zur Hand und kann nicht nachgucken). Die Rundungsprobleme sollten hier also nicht auftreten...)
(Wenn ich mal entsprechend Zeit dazu hab, werd ich das vllt nochmal genauer untersuchen...)
Will man also unbedingt kaufmännisch runden, sollte man entweder Currency nehmen oder das Runden selbst in die Hand nahmen...
mfg
Christian
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!