> Hi, > > also ich rechne seit Jahren in meiner App mit 4 Stellen hinter dem Komma und > speichere diese Werte direkt als Double ab. > Das ging absolut problemlos,
Offensichtlich nicht :-) > bis das jetzt mit dem kaufmännischen > Runden-Problem bei sehr kleinen Beträgen unter 1 Euro auftrat... was aber ja > auch zu lösen war. Und was Du jedes Mal wieder hast - und nie genau weißt, an welcher Stelle. Daher ist es m.E. gesünder, man löst das einmal sauber und gut ist. > Alles in Cent umrechnen reicht mir bei meiner Faktura auch nicht, denn hier > werden 4 Stellen hinter dem Komma benötigt, in dem Fall müsste man alle > Euro-Eingaben mal 10000 nehmen um einen 4Stellen hinter dem Komma Wert in eine > Integerzahl zu wandeln. > Aber ehrlich gesagt sehe ich im Moment auch nicht genau, was mir das bringen > soll, ich müsste schon alle Werte intern mit 100000 multiplizieren und mit > diesen Werten dann auch rechnen, Ich bin froh, dass mein Steuerberater nicht so denkt, sonst wäre ich vermutlich jedes 3. Jahr für ein paar Monate im Knast :-) > sobald dann der Benutzer eine zahl angezeigt bekommt muss sie wieder geteilt > und formatiert werden.... Sie muss immer NUR bei der Anzeige formatiert werden - sonst nicht. a. > > Gruß > > Stefan > >> On 01.02.10 19:50, "Michael Kagerbauer" <realbasicli...@kagerbauer.net> >> wrote: >> >>> Hast du einige Funktionen / Beispiele wie du in deinem Fall vorgehst? >> >> Das ist von Fall zu Fall unterschiedlich. Letztlich kommt's auf die >> benötigte Genauigkeit an. >> >>> Der Ansatz in dieser Sache ist mir schon klar, allerdings erschliesst >>> sich mir noch nicht der Vorteil welcher sich daraus ergeben soll. Die >>> Genauigkeit bei Fließkommazahlen läßt sich unter anderem auch durch die >>> Anzahl der Nachkommastellen beeinflussen welche dann in der Datenbank >>> abgespeichert werden. >> >> Das Problem ist, dass Fliesskommazahlen NIEMALS *genau* sind. Sie enthalten >> immer eine gewisse 'Unschärfe' und zwar spätestens, wenn eine Division >> durchgeführt wird (die ja binär ist und daher mit einer endlichen >> Genauigkeit erfolgt). Daher ist beispielsweise 199.0/100.0 *ungefähr* 19,9. >> Da der Wert (für den Computer) aber binär ausgedrückt wird, ist's halt nicht >> *genau* 19,9. Das läppert sich u.U. im Laufe der Operationen zusammen. >> >>> Wenn wir das obige Beispiel nehmen und die 0.825 mit 1000 skaliert >>> werden, hat man als Ergebnis 825 welche als Integer in der Datenbank >>> gespeichert würden. Was machst du beim Anzeigen des Wertes beim >>> kaufmännischen Runden anders bzw. wie handhabst du die Berechnung? >> >> Solange Du Dich - wie in dem Beispiel - in einem bestimmbaren Wertebereich >> aufhältst, kannst Du die Unschärfen vermeiden, wenn Du den kleinsten >> möglichen Wert als ganzzahliges Minimum annimmst (daraus ergibt sich dann >> automatisch der Multiplikator). >> Das Ganze ist übrigens ein typisches Problem, wenn Du z.B. Lohnsteuerdaten >> mit unterschiedlichen Programmen berechnest. Da kann's schnell mal >> passieren, dass die Endbeträge um einige Cents auseinanderliegen. Brichst Du >> das Ganze auf Cents runter, vermeidest Du das grundsätzliche Problem, dass >> Deine Zahlen bereits unscharf gespeichert sind und ebenso verarbeitet >> werden. D.h. die Ergebnisse sind deutlich konsistenter... Den >> Fliesskomma-Wert verwendet man dann quasi nur bei der letztlichen Ausgabe >> (z.B. mit format(...)). >> >> a. >> >> >> > >
