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.
