ich möchte gerne durch gebrochne Zahlen dividieren.

Bsp: 56654 / 35.456
= 1597,86

Ist der Algo so richtig?




Moderiert von raziel: Code- durch Delphi-Tags ersetzt

Hi

gehts Dir um kaufmännische Rundung?

Gruß

Aga

Moin!

HeftCD hat folgendes geschrieben:

ich möchte gerne durch gebrochne Zahlen dividieren. [...] Ist der Algo so richtig? [...] markieren Delphi-Quelltext     1: x := value / value2;

Ja, der "Algo" ist soweit richtig...

Der Rest hat nix mit dem Teilen zu tun, ist aber dafür viel zu umständlich...

cu
Narses

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

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

uhps, hab den link vergesseni

www.delphi-forum.de/...oblemquot_73306.html

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

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

Wenns nur ums Rechnen geht, dann reicht x/y, ist doch klar.

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