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, 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.
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, sobald dann der Benutzer eine zahl angezeigt bekommt muss sie wieder geteilt und formatiert werden.... 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. > > >
