Fehler bei Berechnung

[Ratoncito]

Hallo,

in einer Tabelle habe ich ein Feld
Felddatentyp: Zahl
Feldgröße: Double
Format: Standardzahl
Dezimalstellenanzeige: Automatisch

In der Tabelle sind in 7 Feldern Werte eingetragen, von denen 2 jeweils 2 Nachkommastellen haben, alle anderen Felder sind 0.

In einer Abfrage werden Berechnungen durchgeführt. Rein mathematisch ist das Ergebnis 0, allerdings enthält das Feld den Wert
1,02140518265514E-14

In allen Feldern ist das Format Standardzahl eingetragen.

In einer Abfrage gibt es bei der Berechnung eine Formel:

Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert]/100)+Nz([Stueck]);Nz(0-([Nennwert]/100))+Nz(0-[Stueck]))

Hat jemand eine Erklärung?

LG - Wolfgang

[MzKlMu]

Hallo,
das ist kein Fehler, sondern normal. Das ist das typische Problem einer Fließkommazahl.

https://de.wikipedia.org/wiki/Gleitkommazahl.

1,02140518265514E-14 entspricht 0,0000000000000002140518265514 also (fast) 0.


Verwende statt Double den Datentyp Währung.

[Ratoncito]

Hallo,

danke für die Antwort, aber ist Währung richtig? Es handelt sich um Stück, bzw. um eine normale Zahl.

Bei allen Berechnungen die in diesem Fall gemacht werden, können eigentlich nur Werte mit 2 Nachkommastellen vorkommen. Daher verstehe ich nicht wo dieser extrem kleine Rest herkommen soll.

LG - Wolfgang

[MzKlMu]

Hallo,

Daher verstehe ich nicht wo dieser extrem kleine Rest herkommen soll.

Ließ den Artikel den ich verlinkt habe, dann weißt Du es. Das ist völlig normal, das hat auch nichts mit Access zu tun, das ist Mathematik. Das hat jedes Programm das mit Fließkomma rechnet und dein Taschenrechner. Auch Excel, nur nimmt man da eine höhere Genauigkeit (8 oder 16 bit).
Du kannst völlig problemlos Währung nehmen, musst nur das Währungszeichen entfernen.
Währung rechnet mit Ganzzahlen (macht die Komma erst weg und fügt diese beim Ergebnis wieder hinzu).

Und mir scheint, Währung passt auch, oder ist der Nennwert keine Währung ?

[Ratoncito]

Guten Morgen,

danke für die Antwort, aber ist Währung richtig? Es handelt sich um Stück, bzw. um eine normale Zahl.

Es ist das erste Mal, dass mir so etwas passiert. In der Tabelle gibt es noch zig andere Berechnungen, die alle korrekt angezeigt werden. Über Fließkommazahlen hatte ich schon mal etwas gelesen.

Ich bin davon ausgegangen, dass solche kleinen Reste dann vorkommen können, wenn es im Laufe der Berechnung ein Ergebnis gibt, bei dem die Nachkommastellen nicht ausreichen (z.Bsp. 1/3). Das ist hier nicht der Fall.

LG - Wolfgang

[MzKlMu]

Hallo,

Es ist das erste Mal, dass mir so etwas passiert.

Dann hast Du Glück gehabt oder es nicht bemerkt. Wenn Du diese Zahl 1,02140518265514E-14 als Standardzahl mit 2 Kommastellen formatierst, wird 0,00 angezeigt.
Und den Rest schleppst Du als Rundungsfehler mit. Der sich bei vielen Datensätzen summieren kann und zu Problemen führt. Beim Datentyp Single (wo viele meinen das reicht) wird das Problem noch größer.
Daher ist es unerlässlich sobald eine Währung ins Spiel kommt auch Währung als Datentyp zu verwenden.
Und der Nennwert ist doch Währung, oder nicht (hatte ich schon mal gefragt) ?

Um es noch mal zu sagen, das ist kein Access Problem, das ist reine Mathematik und das Problem hat jedes Programm das Fließkommazahlen verwendet.
Das ist systembedingt und ist kein Fehler.

[Ratoncito]

Hallo Klaus,

vielen Dank für Deine Antwort.

Ich hatte es schon 2 mal geschrieben, dass es sich um Stück, bzw. eine normale Zahl handelt. 

Es ist keine Währung!

In der Zwischenzeit habe ich mir die Tabelle bzw. die Abfragen nochmal genauer angesehen. Es gibt noch weitere Felder mit ähnlichen Problemen. Ich bin erst darauf aufmerksam geworden, als ich eine Abfrage mit >0 ausgeführt habe und dort ein Feld mit diesem kleinen Rest für ein überaschendes Ergebnis führte.

Im Moment habe ich mir damit geholfen, dass ich die Abfrage auf >0,00000001 geändert habe. Hilft mir im Moment weiter, ist aber sicherlich nicht korrekt.

Wie geht man korrekt mit diesem Problem um?

LG - Wolfgang

[MzKlMu]

Hallo,
ich fragte nach dem Nennwert. Und der Nennwert kommt doch in Deiner Formel vor.
Und das ist doch Währung, oder nicht ?

Wie geht man korrekt mit diesem Problem um?

Wie bereits erwähnt, Datentyp umstellen auf Währung.
Double ist da ungeeignet.

Eine Alternative wäre noch Dezimal.

[Ratoncito]

Hallo Klaus,

nochmal nein, es handelt sich nicht um eine Währung. Mir geht es um eine Anzahl oder Stück.

Kommt auch so in der Formel vor, Nennwert bzw. Stueck.

Wenn ich es richtig verstehe nimmt man überall dort, wo genau gerechnet werden soll, den Datentyp Währung und stellt am Ende auf Standardzahl?

LG - Wolfgang

[MzKlMu]

Hallo,
ich muss noch mal nachbohren.
Völlig unbeachtet Deiner Formel, was ist der Nennwert ?
Bitte beziehe Dich nur auf dieses eine Feld.

Nennwert bzw. Stueck.

es muss eher heißen Nennwert und Stück, beide Felder kommen in Deiner Formel vor.

Kann es eigentlich bei den Stückzahlen Dezimalzahlen geben, also z.B. 15,5 Stück ?

[Ratoncito]

Hallo Klaus,

ganz schön neugierig 

Dann mal genauer. Also im Prinzip hast Du recht, der Nennwert wird normalerweise in einer Währung angegeben.

Was ich aber benötige ist ein Bestand in einem Depot. Dort gibt es Anleihen die zu einem Nennwert gehandelt werden, und Fonds oder Aktien, die in Stück gehandelt werden. Die Kurse für Anleihen sind in Prozent, daher muss bei der Berechnung der Nennwert durch 100 geteilt werden.

Und jetzt die Formel:
Bestand: Wenn([tblKonto]![Art]=4;Nz([Nennwert]/100)+Nz([Stueck]);Nz(0-([Nennwert]/100))+Nz(0-[Stueck]))

[tblKonto]![Art]=4 das bedeutet es handelt sich um einen Kauf, daher für den Bestand Nennwert / 100 oder Stueck
im anderen Fall handelt es sich um einen Verkauf, daher 0- (Nennwert / 100) bzw. Stueck zur Verminderung des Bestandes.
Die Bildung der Summe erfolgt in einer weiteren Abfrage.

Zu Deiner zweiten Frage:
Ja, es gibt Dezimalzahlen

Ich bin mit den ganzen Abfragen nicht glücklich, bekomme es aber nicht eleganter hin. Im Moment bekomme ich die Berechnung des Depotbestands zwischen zwei Terminen nicht ermittelt und breche mir schon seit einigen Tagen die Ohren.

LG - Wolfgang

[MzKlMu]

Hallo,
also doch Währung.
Wie ich in #5 schon schrieb:

Daher ist es unerlässlich sobald eine Währung ins Spiel kommt auch Währung als Datentyp zu verwenden.

Stelle also den Datentyp auf Währung um, und Du bist den Fließkommafehler los.
Das ist ja der Sinn des Datentyps Währung, Fließkomma zu vermeiden.

[Ratoncito]

Hallo Klaus,

jein! 

Stueck ist eben nicht Währung. Und mir geht es eigentlich nur um die Zahl.

Und die Frage ist noch nicht beantwortet:
Wenn ich es richtig verstehe nimmt man überall dort, wo genau gerechnet werden soll, den Datentyp Währung und stellt am Ende auf Standardzahl?

Und wenn ja, wozu ist dann die Einstellung mit Fließkomma gut?

LG - Wolfgang

[MzKlMu]

Hallo,

Und wenn ja, wozu ist dann die Einstellung mit Fließkomma gut?

Das muss der Anwender entscheiden. Wenn man aus Länge und Breite die Größe eines Grundstücks ermitteln will, kann man sicher Double verwenden.

Natürlich ist die Frage beantwortet:

Stelle also den Datentyp auf Währung um, und Du bist den Fließkommafehler los.

Das Format ist egal bzw.muss auf einen passenden Wert eingestellt werden.
Wenn das Ergebnis eine Währung ist, dann Währung, eine Kommazahl als Standardzahl mit den gewünschten Kommastellen (maximal 4)

[Ratoncito]

Hallo,

leider muss ich nochmal auf das Thema zurückkommen. Ich bekomme das Problem nicht gelöst. Bei einer Abfrage auf "0" erhalte ich immer noch ein falsches Ergebnis.

In den Auswertungen geht es um eine Menge, die in Stück oder Nennwert angegeben sind. Dabei handelt es sich bei Nennwert nicht um eine Währung. Die Angabe einer Währung ist dabei lediglich eine weitere Information. So wie es sich bei Obst zum Beispiel um Äpfel oder Birnen handeln könnte.

Obwohl in allen beteiligten Feldern der Datentyp auf Währung eingestelltist, führt eine Abfrage mit "=0" zu einem falschen Ergebnis.

Es muss doch möglich sein, einfache mathematische Berechnungen mit einem eindeutigen Ergebnis auszuführen, und im Ergebnis auf "0" abzufragen. In diesem Fall 70 - 58,66 - 11,34 = 0

LG - Wolfgang