Rechnen ohne Float

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Gehe zu Seite Zurück 1, 2

	Midimaster	Sa, Jul 23, 2011 12:45 Antworten mit Zitat
@havocktoxx Eben! In der Finanzmathematik darf man keine Rundungsfehler haben. Stell Dir vor, Du schreibst eine Buchhaltung-Software und am Ende des Jahres fehlt in der Bilanz 1 Cent.... Da kann sich die Buchhaltung hinsetzen und tagelang suchen, denn ein Fehler von 1 Cent wird immer als möglicher Beleg für einen schwerwiegenden Buchungfehler betrachtet. Volkswirtschaftlicher Schaden! Außerdem würde so "Geld verschwinden". Die Bank bucht dir 5x die 1000.09 Cent auf Dein Konto, worauf dort 5 Cent zu viel stehen?!? Woher sollen die jetzt kommen? das bei 10.000.000 Bewegungen täglich und die Bank ist nach 2 Jahren ruiniert... Und noch was gegen FLOAT: Es handelt sich hier nicht um "Rundungsfehler wie nach einer Mutlipikation mit Prozent", sonder wirklich Rechenfehler der Maschine. Rundungsfehler gibt es auch bei INTEGER. Nur wird hier durch die Rückführung zur INTEGER ein eindeutiger Betrag erzeugt, der vielleicht nicht dem wirklichen Ergebnis entspricht, sich aber eben Finanzmathematisch weiterverarbeiten läßt. Hier noch mal mein Beispiel in einer anderen Variante, dass Dir zeigen wird, es ist keine "Rundungsfehler, wie du ihn definierst" BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] a#=200009 For i= 1 To 50 sum# =sum# + a# Next Print sum# b%=200009 For i= 1 To 50 sumb% =sumb% + b% Next Print sumb Wie Btbn schon ausführt, es ist ein Problem des Zahlensystems: Zahlen auf der Basis 2^n lassen sich eben nicht verlustfrei in Zahlen auf die Basis 10^n überführen.

Midimaster

Sa, Jul 23, 2011 12:45
Antworten mit Zitat

@havocktoxx

Eben! In der Finanzmathematik darf man keine Rundungsfehler haben. Stell Dir vor, Du schreibst eine Buchhaltung-Software und am Ende des Jahres fehlt in der Bilanz 1 Cent....

Da kann sich die Buchhaltung hinsetzen und tagelang suchen, denn ein Fehler von 1 Cent wird immer als möglicher Beleg für einen schwerwiegenden Buchungfehler betrachtet. Volkswirtschaftlicher Schaden!

Außerdem würde so "Geld verschwinden". Die Bank bucht dir 5x die 1000.09 Cent auf Dein Konto, worauf dort 5 Cent zu viel stehen?!? Woher sollen die jetzt kommen? das bei 10.000.000 Bewegungen täglich und die Bank ist nach 2 Jahren ruiniert...

Und noch was gegen FLOAT: Es handelt sich hier nicht um "Rundungsfehler wie nach einer Mutlipikation mit Prozent", sonder wirklich Rechenfehler der Maschine.

Rundungsfehler gibt es auch bei INTEGER. Nur wird hier durch die Rückführung zur INTEGER ein eindeutiger Betrag erzeugt, der vielleicht nicht dem wirklichen Ergebnis entspricht, sich aber eben Finanzmathematisch weiterverarbeiten läßt.

Hier noch mal mein Beispiel in einer anderen Variante, dass Dir zeigen wird, es ist keine "Rundungsfehler, wie du ihn definierst"

BlitzBasic: [AUSKLAPPEN]

a#=200009
For i=  1 To 50
	sum# =sum# + a#
Next 
Print sum#

b%=200009
For i=  1 To 50
	sumb% =sumb% + b%
Next 
Print sumb

Wie Btbn schon ausführt, es ist ein Problem des Zahlensystems:

Zahlen auf der Basis 2^n lassen sich eben nicht verlustfrei in Zahlen auf die Basis 10^n überführen.

	Noobody	Sa, Jul 23, 2011 13:44 Antworten mit Zitat
Midimaster hat Folgendes geschrieben: Zahlen auf der Basis 2^n lassen sich eben nicht verlustfrei in Zahlen auf die Basis 10^n überführen. Doch, das geht absolut verlustfrei. Umgekehrt allerdings gibt es allerdings einige Dezimalzahlen, die nicht durch eine endliche Binärzahl darstellbar sind (Ganzzahlen gehen aber trotzdem ohne Probleme). Die Konvertierung ist aber das kleinere Problem bei Geldrechnungen (Konvertierungsfehler sind durch Runden behebbar), viel mehr ins Gewicht fällt die begrenzte Anzahl an Genauigkeit bei Floats bzw. Double. Float kann gerade mal 7 Dezimalziffern darstellen, bei Double sind es knappe 16. Das heisst, die Zahl 123456789 würde in Float als 123456700 herauskommen, was bei Geldbeträgen eher unerwünscht ist. Der Weg über Integer (oder besser Longs) ist also empfehlbar, wenn man die Rechnungen richtig herum macht (so wie Der Eisvogel es schon beschrieben hat). Mit Double sollte man auch noch durchkommen, da einem mit zwei Nachkommastellen für Cents und einer Nachkommastelle für Rundungsfehler immerhin noch 12-13 Dezimalstellen für den Eurobetrag übrigbleiben, was ja ausreichen sollte, wenn man nicht gerade mit sehr vermögenden Kunden arbeitet.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Sa, Jul 23, 2011 13:44
Antworten mit Zitat

Midimaster hat Folgendes geschrieben:

Zahlen auf der Basis 2^n lassen sich eben nicht verlustfrei in Zahlen auf die Basis 10^n überführen.

Doch, das geht absolut verlustfrei. Umgekehrt allerdings gibt es allerdings einige Dezimalzahlen, die nicht durch eine endliche Binärzahl darstellbar sind (Ganzzahlen gehen aber trotzdem ohne Probleme).

Die Konvertierung ist aber das kleinere Problem bei Geldrechnungen (Konvertierungsfehler sind durch Runden behebbar), viel mehr ins Gewicht fällt die begrenzte Anzahl an Genauigkeit bei Floats bzw. Double. Float kann gerade mal 7 Dezimalziffern darstellen, bei Double sind es knappe 16. Das heisst, die Zahl 123456789 würde in Float als 123456700 herauskommen, was bei Geldbeträgen eher unerwünscht ist.

Der Weg über Integer (oder besser Longs) ist also empfehlbar, wenn man die Rechnungen richtig herum macht (so wie Der Eisvogel es schon beschrieben hat). Mit Double sollte man auch noch durchkommen, da einem mit zwei Nachkommastellen für Cents und einer Nachkommastelle für Rundungsfehler immerhin noch 12-13 Dezimalstellen für den Eurobetrag übrigbleiben, was ja ausreichen sollte, wenn man nicht gerade mit sehr vermögenden Kunden arbeitet.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun