Office: VBA rechnet ungenau

Hallo

wenn ich mit VBA eine einfache Rechnung durchführe und ausgeben lasse, sind leichte Fehler enthalten. Wie kann das sein??


die Rechnung ist
26,88 - 26,06

VBA bekommt hier 0,819999992847442 als Ergebnis raus
richtig wäre 0,82

Code:

Weiß jemand woran das liegt und wie man das beheben kann?

Gruß

:)

 

... vielleicht hast du die 2 Zahlen nur mit 2 Nachkommastellen formatiert?!

 

Hallo,

schau mal ins direkt fenster beim stop
Code:

 

Hallo xlph

daran kann es nicht liegen, das das Ergebnis mit den 2 Stellen nach dem Koma richtig ist und VBA sträng genommen falsch.


Hallo RalfP

Was soll ich nun genau machen? Ich habe den Code ausgeführt, dann hat er am stop gehalten und gelb markiert. wenn ich dann auf fortsetzen geklickt habe, hat er wieder das falsche Ergebnis ausgegeben.

Was für ein Direktfenster?

Gruß Faultier

 

wenn der text gelb markierte wird, wählst du im vba-fenster im menü, ansicht, direktfenster. oder strg+g drücken

debug.print schreibt dir was auch immer du möchtest in das direkt fenster
du kannst dort auch direkt befehle eingeben, bsp.
? activesheet.name [enter]

Ralf

 

...oh ja, falsch interpretiert.

Versuche es mit Double statt Single (oder Currency).

Versuche es mit .Value statt mit .Value2

 

Hallo Gruß,

hatten wir das Thema nicht schon einmal?
Wie sind die Zellen formatiert? Wieder als Währung? Werden die beiden Werte 26,88 und 26,06 per Formel ermittelt? Welches Ergebnis kommt heraus, wenn Du die Zahlen von Hand in die Zellen einträgst? Ändert sich etwas, wenn Du das Format auf Standard stellst?

Grüße
EarlFred

 

Hallo EarlFred

im Direktbereich sind nur die Werte enthalten, mit denen er rechnet und das sind die Werte, die ich oben genannt habe. Es erklärt sich mir immer noch nicht, warum er falsch rechnet?

Gruß Faultier

 

Hallo zusammen,

die Probleme die Computer (nicht Excel) mit dem Rechnen bei Fließkommazahlen haben, sind hier doch schon öfter erörtert worden. Da hilft nur zwischenzeitliches Runden. Wobei das nicht mit der Anzahl der Nachkommastellen beim Zellformat verwechselt werden Darf.

 

VBA (auch andere Programmersprachen) rechnen mit den vorhandenen Datentypen so genau wie möglich, wie es der einem Datentyp zur Verfügung stehende Speicherplatz nämlich zulässt. Dann gibt es Fließkomma-Zahlen, die sich binär von vornherein nur annäherungsweise darstellen lassen. Beispiel: Ein Drittel lässt sich weder binär (Basis 2) noch dezimal (Basis 10) exakt darstellen (dezimal 0,333...[Periode]...)). In einem Zahlensystem mit der Basis 3 ist es dagegen kein Problem, ein Drittel exakt darzustellen, das sieht dann nämlich genau so aus: 0,1.

Der Single Datentyp rechnet zum Beispiel mit 4 Byte (das sind 32 binäre Stellen bzw. Bits). Für die Darstellung von Gleitkommazahlen stehen dann eben entsprechend wenig Bits zur Verfügung. Will man genauer rechnen, muss man "breitere" Datentypen (z.B. Double oder Decimal) verwenden. Die belegen dann aber auch mehr Platz (mehr Bytes) im Speicher. Bei großen Datenmengen kann da einiges an Speicherbedarf zusammenkommen.

Der Default-Wert in Excel-Arbeitsblatt-Zellen ist Double. Da mag es sinnvoller sein, auch im VBA-Modul bzw. -Klasse für Zahlenwerte aus Arbeitsblatt-Zellen Double-Variablen zu verwenden. Das selbe gilt dann natürlich auch für Operationen (z.B. in Funktionen und deren Rückgabewert). Denn bei ausreichend vielen Nachkommastellen kommt es schon beim Einlesen eines Zellwerts in eine Single-Variable zu Abstrichen. Wenn man den Singlewert dann in eine Zelle zurückschreibt, hat die so implizit für Single passend gemachte Zahl schon nicht mehr ihren ursprünglichen Wert.

Denn um in den Single-Datentyp zu passen, schneidet das System einfach Stellen ab bzw es findet z.B. eine Annäherung an eine reelle Zahl statt. Nur wenn der Zellwert insgesamt größer als der in Single größtmögliche Wert ist, gibts einen sogenannten Überlauf-Fehler schon beim Einlesen - da hat man also immerhin einen Hinweis.

Kann man abschätzen, welche Ungenauigkeit man hinnehmen kann, dann man die Zahlen von vornherein auf z.B. 10 Stellen nach dem Komma runden. Zusammen mit Double reicht das dann für ausreichend genaue Berechnungen.
Welche Genauigkeit erforderlich ist, hängt vom Anwendungskontext ab.

Hier zwei URLs zum Thema:

Single-Datentyp
https://msdn.microsoft.com/de-de/lib...vs.100%29.aspx

Problembehandlung bei Datentypen-Ungenauigkeiten
https://msdn.microsoft.com/de-de/lib...vs.100%29.aspx

Viele Grüße
Al Rinat

 

Hallo Al Rinat

vielen Dank für die ausführliche Erklärung.

Gruß Faultier

 

Hallo Faultier,

gerne!

Gruß Al Rinat