Microsoft Excel

Herbers Excel/VBA-Archiv

Informationen und Beispiele zum Thema MsgBox
BildScreenshot zu MsgBox MsgBox-Seite mit Beispielarbeitsmappe aufrufen

Nachkommastellen


Betrifft: Nachkommastellen von: AnBad
Geschrieben am: 10.09.2019 20:25:25

Hallo, Guten Abend!!

Ich habe in einer VBA-Zeile folgende Addition innerhalb eines Arrays:

arrEFB223(zz, 10) = arrEFB223(zz, 6) + arrEFB223(zz, 7) + arrEFB223(zz, 8) + arrEFB223(zz, 9)

Nun hatte ich mit der Weiterverarbeitung des Ergebnis Probleme hinsichtlich der Genauigkeit und zum Test diese Zeile angelegt:

MsgBox "Hier Null: " & arrEFB223(zz, 10) - arrEFB223(zz, 6) - arrEFB223(zz, 7) - arrEFB223(zz, 8) - arrEFB223(zz, 9)

Normalerweise sollte hier Null rauskommen, oder? Tut es aber nicht, sondern es bleibt ein Rest 15 Stellen nach dem Komma übrig.

Alle Zahlen werden als Variant/Double angelegt.

Was kann man tun? Wie darf ich das verstehen?

Viele Grüße und vielen Dank

Michael

  

Betrifft: AW: Nachkommastellen von: 1712359.html
Geschrieben am: 10.09.2019 20:59:51

Hallo Michael,

du musst ein Round() einbauen. Alle Berechnungen finden im binären Bereich statt, da kommt es zu geringen Differenzen. Google nach Fließkommaarithmetik.

Grüße Sigi

  

Betrifft: AW: Nachkommastellen von: 1712368.html
Geschrieben am: 10.09.2019 22:06:05

Hi, Sigi!
Vielen Dank für die Info und Tipp.
Habe also verstanden, dass es bei der Umwandling vom 10er System ins binäre und umgekehrt zu kleineren Fehlern kommt.
Jetzt frage ich mich, wie den "in" Excelzellen gerechnet wird. Dortige Eingaben werden auch binär umgewandelt und dann gerundet? Um in VBA die gleichen Ergebnisse wie in Zellen zu erreichen, sollte bis zu welcher Kommastelle in VBA gerundet werden? Round(Ergebnis, 14?)? Das müsste ja im Prinzip bei jeder VBA-Zeile mit Berechnung erfolgen? Oder sollte ich nach Möglichkeit Berechnungen mit VBA vermeiden?ß

Ach her je, wieder mal Fragen über Fragen...

vg und guten Nacht.

  

Betrifft: AW: Fragen über Fragen....und von: 1712371.html
Geschrieben am: 10.09.2019 22:44:17

Hi,

kannst du mit der Antwort von Sigi wirklich so gar nix anstellen?
Musst du auf die 14. !!! Stelle nach dem Komma wirklich ganz genau rechnen?

Bisher hat es doch bei vielen Millionen Excel-Nutzern (sogar beruflich!) ausgereicht.
Zumindest die Vorgesetzten waren mit den Ergebnissen bisher zufrieden.
(wenn nicht, würde es MS Excel wohl nicht mehr geben^^)

Also, zumindest ich verstehe dein Nachfragen nicht ganz.

Aber ok, vielleicht kommt ja noch was von Sigi.

Ciao + noch n schönen Abend
Thorsten

  

Betrifft: AW: Nachkommastellen von: 1712421.html
Geschrieben am: 11.09.2019 10:44:29

Hallo Michael,

Rechenoperationen finden im Binärsystem statt. Dazu werden alle Zahlen umgewandelt. Jedes Zahlensystem hat Vor- und Nachteile. So können nicht immer alle Zahlen im anderen System exakt (!) dargestellt werden. Sowohl in VBA als auch in Excel.

Das kennen wir auch im Dezimalsystem. Die Zahl ein Drittel (1/3) in Bruchschreibweise kann im Dezimalsystem nicht genau dargestellt werden. 1/3 = 0,333… oder gar 0,3334? Beides sind nicht ein Drittel.

Ich habe ein kleines Beispiel einer simplem Subtraktion. Das Ergebnis wird richtig dargestellt. Aber erst wenn du das Ergebnis mit 15 Nachkommastellen formatierst siehst du was wirklich drin steht!
Tippe folgende zwei Zahlen ein: 65 und 64,9. Subtrahiere = 65 - 64,9 und formatiere das Ergebnis auf 15 Nachkommastellen.

Ich habe Excel 2010 und 365 auf 32-Bitrechner. (Evtl. ist es mit 64-Bitrechnern nicht mehr so)

Grüße
Sigi

  

Betrifft: AW: Nachkommastellen von: 1712553.html
Geschrieben am: 11.09.2019 20:14:11

Hallo Sigi!


Nochmals tausend Dank. Ich habe das Problem soweit verstanden, denke ich.

Wo ich aber noch am Grübeln bin ist, in wie weit diese Ungenauigkeit eine Rolle für die Zahlen bei meinem VBA-Programm spielt.

Also nach dem Motto:

10.000 Einheiten x "Errechnete Eurozahl über 10 Rechenroutinen mit jeweiligen Fehlern"

führt zu einer merklichen Abweichung...? Und wenn ja, was macht man dagegen... Alle Ergebnisse runden? Ich denke mir jedoch, dass die Abweichung so gering sind und ohnehin in jedem Taschenrechner, Kasse, Excelprogramm vorkommen, dass Nichtbeachtung das beste Mittel ist, oder?

Schönen Abend Dir und allen Exelperten..

  

Betrifft: AW: Nachkommastellen von: 1712566.html
Geschrieben am: 11.09.2019 22:12:00

Hallo Michael,

die geringen Differenzen entstehen ja erst nach der 14./15. Stelle nach dem Komma. Normalerweise spielt das weder in VBA noch in Excel eine Rolle.
Aber falls du nach einer Rechenoperation das Ergebnis auf einen erwarteten Wert abfragst (Wenn, dann, sonst) und du erhältst nicht die erwartete Verzweigung, dann weist du wo du suchen musst und besser das Ergebnis runden solltest.

Grüße
Sigi

  

Betrifft: [gelöst] AW: Nachkommastellen von: 1713020.html
Geschrieben am: 14.09.2019 08:32:20

Hallo,

nochmals vielen Dank.

Hier meine Lösung und nochmals das Problem kurz umrissen:

Ich wollte auf verschiedene Zahlen eine weitere bestimmte kleine Zahl im Verhältnis nach jeweiliger Größe der verschiedenen Zahlen addieren. Das setzt natürlich eine Verhältnisberechnung ergo prozentuale Berechnung der Anteile voraus. Aufgrund dieser Prozentrechnung kam es aber wegen der Umwandlung binäres Zahlensystem zum zehner System und umgekehrt zu Ungenauigkeiten, welche sich bemerkbar machten.

Wie sieht meine Lösung aus? Wobei ich sagen muss, da die verschiedenen Zahlen eine best. fixe Zahl ergeben müssen, weiß ich also welche Betrag aufzuteilen ist, bzw. wie groß der Fehler ist:

Einfach eine Schleife einfügen und den aufzuschlagenden Betrag bzw. dann im zweiten, dritten Durchgang die Fehldifferenz erneut zu den verschiedenen Zahlen im Verhältnis aufschlagen. D.h. das Ergebnis wird sich mit jeder Schleife zum korrekten Ergebnis annähern.

Schönen es WE!

Michael

  

Betrifft: AW: Nachkommastellen von: 1712372.html
Geschrieben am: 10.09.2019 22:55:56

Hallo Michael,

Du vergleichst am besten nicht mit Null, sondern Abs(was Null sein soll)<1e-13
Siehe mein Excel Don't #8:
http://sulprobil.com/Get_it_done/IT/Excel_Fun/Excel_Don-ts/excel_don-ts.html

Viele Grüße,
Bernd P

  

Betrifft: Nein, Round() muss nicht sein :-) von: 1712373.html
Geschrieben am: 10.09.2019 22:58:18

Hi Sigi,
Sorry, ich spreche wider.
Viele Grüße,
Bernd P