Hallo Fachwelt,
gibt es einen Grund,warum Currency nur für kaufmännisches Rechnen empfohlen wird? Gibt es irgendwelche Nachteile gegenüber long double? Bin dabei, ein Programm in BCB6 zu schreiben, welches math. Funktionen numerisch integriert,versuche daher Rundungsfehler möglichst zu vermeiden und frage mich,ob es nicht besser wäre Currency statt long double zu benutzen.
Hallo Fragewurm,
gibt es einen Grund,warum Currency nur für kaufmännisches
Rechnen empfohlen wird? Gibt es irgendwelche Nachteile
gegenüber long double? Bin dabei, ein Programm in BCB6 zu
schreiben, welches math. Funktionen numerisch
integriert,versuche daher Rundungsfehler möglichst zu
vermeiden und frage mich,ob es nicht besser wäre Currency
statt long double zu benutzen.
Wenn ich mich recht besinne, arbeitet Currency mit BCD.
Der Nachteil ist, dass dadurch die Operationen etwas langsamer als mit long double sind. Da aber dezimal gerechnet wird, gibt es keine Rundungsprobleme durch die Darstellung der Werte in binär. Gerechnet wird eigentlich genau so, wie du das mit Papier und Bleistift auch tun würdest.
Noch etwas zu den Rundungsproblememen.
Wichtig bei der Wahl des richtigen Zahlenformats ist also auch der Wert-Bereich der zu verarbeitenden Zahlen. Besonderes Augenmerk muss man dabei auch auf die Zwischenresultate legen.
z.B.:
10*10’000/5’000 sollte 20 ergeben.
rechnest du mit 16-Bit Integern wirst du je nachdem unterschiedliche Resultate bekommen:
(10*10’000)/5’000 ergibt etwas „lustiges“, bzw. unvorhersehbares Resultat, da (10*10’000) > 215 ist, und noch die Frage offen ist, was der Compiler hier für einen Code erzeugt (Wenn der Compiler intern mit 32Bit arbeitet stimmt das Resultat!!).
10*(10’000/5’000) liefert ein korrektes Resultat.
MfG Peter(TOO)
Hallo Fachwelt,
Hallo Sebastian,
ich wollte schon auf die Frage antworten, aber nachdem ich deinen Namen gesehen habe, muss ich anhand früherer Threads feststellen, dass du dich offensichtlich grundsätzlich nicht für Tipps und Hinweise bedankst oder auch nur sagst, ob es was genützt hat - bei soviel Unfreundlichkeit lasse ich es doch lieber gleich.
Gruss Reinhard
Hey, sorry Reinhard,
prinzipiell hast du ja Recht, die Nettikette ist bei mir in letzter Zeit wohl etwas kurz gekommnen. Das tut mir leid und das gehört sich auch nicht. Jedoch stimmt das so nicht ganz, diese Unsitte ist wirklich erst in letzter Zeit aufgrund von Diplomstress eingerissen.
Werd das wieder ändern…
Gruß
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Fragewurm,
wer nicht fragt bleibt ein Wurm…
gibt es einen Grund,warum Currency nur für kaufmännisches
Rechnen empfohlen wird? Gibt es irgendwelche Nachteile
gegenüber long double? Bin dabei, ein Programm in BCB6 zu
schreiben, welches math. Funktionen numerisch
integriert,versuche daher Rundungsfehler möglichst zu
vermeiden und frage mich,ob es nicht besser wäre Currency
statt long double zu benutzen.Wenn ich mich recht besinne, arbeitet Currency mit BCD.
Der Nachteil ist, dass dadurch die Operationen etwas langsamer
als mit long double sind. Da aber dezimal gerechnet wird, gibt
es keine Rundungsprobleme durch die Darstellung der Werte in
binär. Gerechnet wird eigentlich genau so, wie du das mit
Papier und Bleistift auch tun würdest.Noch etwas zu den Rundungsproblememen.
- Bei der Konvertierung der Zahlensysteme entstecht schon der
erste Fehler z.B.
- 1/3 kannst du nie genau als einen Dezimalbruch mit endlicher
Stellenzahl schreiben.- Eine Mantisse in binärer schreibweise ist manchmal nur eine
näherung an die Dezimalzahl. mit zwei bit hinter dem Komma
kannst du nur die Werte 0.0. 0.25, 0.5 und 0.75 exakt
abbilden, alle Anderen müssen angenähert werden. Mit einer
32-Bit Mantisse liegt der Fehler immer noch bei ca. 2.3
*1010, Wenn du also mit 1 Milliarde Euro rechnest,
hast du schon Fehler bei den Cent.
- Bei den Rechenoperationen gibt es dann folgende Probleme:
a. Überschreiten der Darstellbaren Ziffern:
double a,b;
a = 0.0;
b = 1.0
while (a != b)
{
a = b;
b += 1.0;
}
Praktisch wird diese Schlaufe beendet, mathematisch dürfte sie
nie beendet werden.
b. Die endliche Grösse der Mantisse ergibt die Anzahl gültiger
Ziffern. Je nach Rechenoperation wirkt sich das unteschiedlich
stark auf das Ergebnis aus. z.B. bei Additionen bleibt die
gültige Ziffernzahl praktisch erhalten, bei Multiplikationen
reduziert sie sich aber schon mit der Anzahl der Operationen,
und beim Potenzieren ist der Effekt noch grösser.Wichtig bei der Wahl des richtigen Zahlenformats ist also auch
der Wert-Bereich der zu verarbeitenden Zahlen. Besonderes
Augenmerk muss man dabei auch auf die Zwischenresultate legen.
z.B.:
10*10’000/5’000 sollte 20 ergeben.
rechnest du mit 16-Bit Integern wirst du je nachdem
unterschiedliche Resultate bekommen:
(10*10’000)/5’000 ergibt etwas „lustiges“, bzw.
unvorhersehbares Resultat, da (10*10’000) > 215
ist, und noch die Frage offen ist, was der Compiler hier für
einen Code erzeugt (Wenn der Compiler intern mit 32Bit
arbeitet stimmt das Resultat!!).
10*(10’000/5’000) liefert ein korrektes Resultat.MfG Peter(TOO)
Danke Peter, werd das erstmal mit Currency probieren und mal schauen, ob es von der Rechenzeit verantwortbar bleibt. Mal schauen…
Misteriös finde ich nur, dass sämtliche Fachliteratur(5 Bücher),in der ich dazu nachgelesen habe, Currency nur in Verbindung mit den Buchhaltern usw. bringt.Finde das ziemlich irreführend.
Danke und Gruß
Hallo Fragewurm,
wer nicht fragt bleibt ein Wurm…
Wer seinen Namen nicht in sein Posting schreibt, ist auch einer… 
Misteriös finde ich nur, dass sämtliche Fachliteratur(5
Bücher),in der ich dazu nachgelesen habe, Currency nur in
Verbindung mit den Buchhaltern usw. bringt.Finde das ziemlich
irreführend.
Buchhalter sind halt komische pingelige Typen, welche auch bei Milliarden-Beträgen Wert darauf legen, dass die Cent noch stimmen…
Allerdings ist deren ANliegen auch berechtigt, denn wenn ich 29Cent in der Kasse habe, dann eine Milliarde in die Kasse einlege und danach wieder herausnehme, müssen die 29Cent noch in der Kasse sein und dürfen nicht einfach irgendwo verschwinden !!!
Die unterschiedlichen Zahlenformate, scheinen für die meisten Programmierer ein Buch mit sieben Siegeln zu sein …
Wenn man z.B. die Temperatur mit einer Auflösung von 0.1° anzeigen soll, benutzen die meisten gleich FP. Besonders auf MicroControllern ist das nicht sehr effektiv, da diese meist keine FPU haben.
ALternativ rechnet man intern einfach in 100stel°C, mit einem 16-Bit Integer kann man damit den Bereich von -325°C bis +325°C darstellen, was für die meisten Anwendungen schon mehr als genügend ist.
Auch wenn man einen Integer durch 2.5 Teilen muss, geht das ohne FP: …(x*2)/5
…es geht halt nichts über das gute alte Bruchrechnen 
Man muss einzig darauf acht geben, dass man keine Überläufe bei der Multiplikation erzeugt.
MfG Peter(TOO)