Access2k ändert Werte

und zwar munter und offenbar wild nach Schnautze…

Hai, Experten,

ich hab eine Tabelle (wie überraschend…) in der ist unter anderem ein „Geld“-Feld, Zahl, Double in das der Nutzer eine Zahl einträgt (noch ‚ne Überraschung), z.B. 161,01. In der Tabelle steht dann auch 161,01 (was mich in grenzenloses Erstaunen versetzt). An anderer Stelle wird diese Zahl mit einem anderen Datensatz verrechnet, in dem auch 161,01 steht. Einem von beiden wird das Vorzeichen verdreht, ich nehm‘ da die klassisch-mathematische Methode: *-1 (und die ms-Welt ist für mich wieder in Ordnung, es kommt -161,0099999… heraus). Also, in die Trickkiste gegriffen, und den Ausdruck aufgeblasen: ROUND(([Geld]*-1),2) (huch, er kann ja 'n Vorzeichenwechsel rechnen…); jetzt rechne ich noch in meinem jugendlichen Leichtsinn einfach +[Geld] aus dem anderen Datenstatz dazu - in der Schule lehrte man mich, daß da jetzt 0 rauskommt - Pustekuchen! Selbst der Wert, der unverändert aus der Tabelle gefischt wird lautet 161,009999999…
OK - ms - was erwarte ich eigentlich? Aber kann mir das hier trotzdem jemand erklären???

irritierten Gruß
Sibylle

… da hilft auch kein Säuseln, die INT Funktion kann Dich vielleicht etwas aufmuntern.

Dank Dir für die Aufmunterung (als Workaround ist übrigens ROUND besser geeignet), aber mich hätte der Grund dieses merkwürdigen Verhaltens interessiert…
Greetz
Sibylle

Ich bleibe bei meiner INT-Funktion . . .

Access „rounded“ nicht kaufmännisch.

Aufmunternde Grüße (alte deutsche Rechtschreibung)
Stephan

Hi Sibylle,
der Grund ist die Art, wie Zahlen im Computer dargestellt werden - es liegt hier ausnahmsweise nicht an Access. Du sprichst von Double-Zahlen. Bei denen wird intern die Mantisse getrennt vom Exponenten gespeichert, und zwar wird die Darstellung zuvor auf „Normalform“ gebracht. Dazu gibt es einen IEEE-Standard, der genau spezifiziert, auf welcher Art das passieren soll.

Die Folge ist, daß Dezimalzahlen, die für uns eine endliche Folge von Ziffern sind, im Computer leider eine periodische (binäre) Zahl ergeben. Die Darstellung 161,01 zwar mit dem Rundungsfehler darstellbar, aber bei Berechnungen pflanzt sich der Fehler fort.

Bei Google fand ich auf die Schnelle nur diesen Link, der dürfte aber erschöpfend sein:
www.uni-paderborn.de/cs/ag-rammig/www/courses/gti/Vo… datenpfad-2001-print_2.pdf

Übrigens bieten „ausgewachsene“ Programmiersprachen aus diesem Grund einen eigenen Datentyp „Currency“, „Long Decimal“ o.Ä., die eine andere Zahlendarstellung verwenden und bei denen (dieser) Fehler nicht passier.

Gruß

J.