10
Excel 2010 - Rechenfehler
Habe mit Excel 2010 ein Berechnungsproblem! Startwert einer Subtraktion ist eine Festwert - Subtrahend ist auch ein Festwert! Nach einigen Berechnungen mit Zelle drüber minus Festwert entstehen Kommastellenwerte! Hier Zeile 22!
Bei großen Beträgen mit Zinsberechnung ist das nicht hilfreich!?
Hat Jemand eine Idee?
Bei großen Beträgen mit Zinsberechnung ist das nicht hilfreich!?
Hat Jemand eine Idee?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 309559
Url: https://administrator.de/contentid/309559
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
10 Kommentare
Neuester Kommentar
Moin,
was meinst Du mit Festwert, das kenne ich nur aus der BWL, meinst Du ganze Zahlen?
Hilfreich wäre auch eine genauere Beschreibung welche Zahlen Du von welchen rechnest.
Gruß
was meinst Du mit Festwert, das kenne ich nur aus der BWL, meinst Du ganze Zahlen?
Hilfreich wäre auch eine genauere Beschreibung welche Zahlen Du von welchen rechnest.
Gruß
Keine ganze Zahlen! Ich habe als Versuch 24,99000000000000000 minus 32 mal 0,760000000000000 vom Restwert abgezogen! Mit dem Taschenrechner ergibt das glatte 24,32, müssten als letzter Wert 0,6700000000 übrigbleiben. Da kam bei Excel aber in Zeile 22 der Fehler:
anstelle von 10,55 - 0,76 = 9,79 glatt und kam 9,78999999999998000000000?
anstelle von 10,55 - 0,76 = 9,79 glatt und kam 9,78999999999998000000000?
Moin ...
Ich glaube es wäre hilfreicher wenn du uns deine "geheime" Formel verraten würdest die du für die Berechnung(en) benutzt.
Also in etwa > Betrag - (x * Festbetrag) wenn ich das so richtig verstehe ....
VG
Ich glaube es wäre hilfreicher wenn du uns deine "geheime" Formel verraten würdest die du für die Berechnung(en) benutzt.
Also in etwa > Betrag - (x * Festbetrag) wenn ich das so richtig verstehe ....
VG
Ich habe da vor Jahren bereits Probleme gefunden und folgende Erklärung:
Erstmals am 21.Juli 1993 im PC-magazin erwähnt: Rolf Hansmann, EDV-Leiter bei Hoechst trat mit diesen Fragen an die Öffentlichkeit. Am 18.August 1993 erläuterte PC-magazin, dass erstmal 1989 ein grosser Reifenhersteller Rechenfehler dieser Art in Lotus Symphony entdeckte. Der EDV-Leiter eines Chemie-Unternehmens bemerkte aber, dass man von Excel als Unternehmensstandard wegen der hohen Kosten nicht auf ein anderes Programmpaket umstellen kann.
Die Fehler treten in der programminternen Fliesskommadarstellung auf, wenn sie nach dem IEEE-Standard arbeitet. Dabei werden Zahlen in eine Mantisse mit 80-Bit-Genauigkeit (entspricht 15 Stellen) und einen Exponenten zerlegt. Bei Nachkommastellen wird ein normiertes Verfahren verwendet, mit dem bestimmte Zahlen nur näherungsweise dargestellt werden können. Sie werden aus Komponenten zusammengesetzt, die von 0,5 ausgehend immer halbiert werden (0,25; 0,125 etc.). Dadurch rutschen viele Zahlen durch das Raster.
Weitere Beispiele:
Erstmals am 21.Juli 1993 im PC-magazin erwähnt: Rolf Hansmann, EDV-Leiter bei Hoechst trat mit diesen Fragen an die Öffentlichkeit. Am 18.August 1993 erläuterte PC-magazin, dass erstmal 1989 ein grosser Reifenhersteller Rechenfehler dieser Art in Lotus Symphony entdeckte. Der EDV-Leiter eines Chemie-Unternehmens bemerkte aber, dass man von Excel als Unternehmensstandard wegen der hohen Kosten nicht auf ein anderes Programmpaket umstellen kann.
Die Fehler treten in der programminternen Fliesskommadarstellung auf, wenn sie nach dem IEEE-Standard arbeitet. Dabei werden Zahlen in eine Mantisse mit 80-Bit-Genauigkeit (entspricht 15 Stellen) und einen Exponenten zerlegt. Bei Nachkommastellen wird ein normiertes Verfahren verwendet, mit dem bestimmte Zahlen nur näherungsweise dargestellt werden können. Sie werden aus Komponenten zusammengesetzt, die von 0,5 ausgehend immer halbiert werden (0,25; 0,125 etc.). Dadurch rutschen viele Zahlen durch das Raster.
Weitere Beispiele:
| = WENN(132.2-127.2=5;"Richtig";"Merkwürdig") | Merkwürdig | Richtig wäre die Antwort "Richtig", da das Resultat aus 132.2 - 127.2 = 5 ist. |
| = GANZZAHL(132.2-127.2) | 4 | Richtig wäre als Resultat 5 |
| = GANZZAHL((4.06-4)*100) | 5 | Richtig wäre die Zahl 6 |
| = 5.098 - 5 - 0.098 | 0 | Korrekt. |
| = 500.99 - 500 - 0.99 | 9.1038E15 | Richtig wäre die Zahl Null. |
Ok, ich kann den Fehler nachvollziehen, wenn ich entsprechend viele Nachkommastellen einstelle.
Bleibe ich bei weniger als X Stellen (X= keine Ahnung mehr, waren aber viele) dann kommt das nicht zu dem beschreibenen Verhalten.
Vermutlich stimmt ice.polars Erklärung. Wenn Du es genauer wissen willst, empfehle ich ein Ticket bei MS aufmachen.
@ashod
Er rechnet immer 0,760000000000000 vom ersten Wert ab, dann vom Ergebnis wieder 0,760000000000000 etc.
Und das macht er 32 Mal. Ist ziemlich verwirrend erklärt.
Bleibe ich bei weniger als X Stellen (X= keine Ahnung mehr, waren aber viele) dann kommt das nicht zu dem beschreibenen Verhalten.
Vermutlich stimmt ice.polars Erklärung. Wenn Du es genauer wissen willst, empfehle ich ein Ticket bei MS aufmachen.
@ashod
Er rechnet immer 0,760000000000000 vom ersten Wert ab, dann vom Ergebnis wieder 0,760000000000000 etc.
Und das macht er 32 Mal. Ist ziemlich verwirrend erklärt.
Moin,
die gleichen Ergebnisse - AUSSER bei der WENN-Formel - zeigt übrigens auch Open Office Calc.
Der Windows-Rechner unter W7 rechnet INT(132,2-127,2) und INT ((4,06-4)*100) richtig aus.
Gruß
Holger
die gleichen Ergebnisse - AUSSER bei der WENN-Formel - zeigt übrigens auch Open Office Calc.
Der Windows-Rechner unter W7 rechnet INT(132,2-127,2) und INT ((4,06-4)*100) richtig aus.
Gruß
Holger
Kaum zu glauben, ausser Open Office Calc rechnet nicht mit Gleitkommazahlen oder hat Tricks eingebaut, um die offensichtlichsten Schwächen auszubügeln.
Auch Microsoft zum Beispiel hat das Problem adressiert: https://support.microsoft.com/en-us/kb/78113 (" Excel 97, however, introduced an optimization that attempts to correct for this problem").
Libre Office wurde da auch getuned wie aus folgendem Post zu entnehmen ist: https://ask.libreoffice.org/en/question/8006/libreoffice-calc-calculatio ... ("inside calc we protect against a few common problems by some common techniques to deal with floating point errors. However this can only workaround some basic problems")
Ansonsten ist das Thema "uralt", siehe auch http://www.lahey.com/float.htm und weitere unzählige Artikel im World Wide Web.
Auch Microsoft zum Beispiel hat das Problem adressiert: https://support.microsoft.com/en-us/kb/78113 (" Excel 97, however, introduced an optimization that attempts to correct for this problem").
Libre Office wurde da auch getuned wie aus folgendem Post zu entnehmen ist: https://ask.libreoffice.org/en/question/8006/libreoffice-calc-calculatio ... ("inside calc we protect against a few common problems by some common techniques to deal with floating point errors. However this can only workaround some basic problems")
Ansonsten ist das Thema "uralt", siehe auch http://www.lahey.com/float.htm und weitere unzählige Artikel im World Wide Web.
Ganz simple Formel: Habe das Bild angehangen!
Moin Motorsegler,
diese Fliesskommafehler wirst du auch durch Ticketeröffnung nicht abstellen können.
Da hilft nur ein Workaround - rechnen mit Ganzzahlen.
Wenn dein Ausgangswert in Zelle $C$1 steht, dann füge in Zeile 2 folgende Formel ein:
Formel nach unten ziehen bis Zeile 33.
Ausgehend davon, dass du mit einer Genauigkeit von 2 Nachkommastellen rechnen willst (bzw. Excel mit dieser Genauigkeit rechnen soll), musst du halt alle Werte * 100 nehmen und zusätzlich noch mit der GANZZAHL()-Funktion auch für Excel zu einer Ganzzahl machen.
Die 76 in der Formel ist "abgekürzt" statt formell eigentlich
Nach Abziehen der letzten Rate (diese 0,67 Taler) bist du dann auch für Excel wirklich auf exakt 0 herunter.
Würdest du auf den überflüssig erscheinenden Zusatzschritt des Castens mit
Grüße
Biber
diese Fliesskommafehler wirst du auch durch Ticketeröffnung nicht abstellen können.
Da hilft nur ein Workaround - rechnen mit Ganzzahlen.
Wenn dein Ausgangswert in Zelle $C$1 steht, dann füge in Zeile 2 folgende Formel ein:
=(GANZZAHL($C$1*100)-(ZEILE(A1)*76))/100
Ausgehend davon, dass du mit einer Genauigkeit von 2 Nachkommastellen rechnen willst (bzw. Excel mit dieser Genauigkeit rechnen soll), musst du halt alle Werte * 100 nehmen und zusätzlich noch mit der GANZZAHL()-Funktion auch für Excel zu einer Ganzzahl machen.
Die 76 in der Formel ist "abgekürzt" statt formell eigentlich
GANZZAHL(0,76*100).Nach Abziehen der letzten Rate (diese 0,67 Taler) bist du dann auch für Excel wirklich auf exakt 0 herunter.
Würdest du auf den überflüssig erscheinenden Zusatzschritt des Castens mit
GANZZAHL() verzichten, dann wärest du statt bei 0 bei -1,88738E-15. Also minus 0 komma (vierzehn weitere Nullen) 118ebbes.Grüße
Biber
Selbst SQL-Server 2012 rechnet mit solchen Datentypen (real) so:
declare @real1 real = 0.76
, @real2 real = 24.99
, @i int = 0
while @real2 > 0
begin
print cast(@i as varchar(10)) + ' ' + cast(@real2 as varchar(10))
set @i = @i + 1
set @real2 = @real2 - @real1
end
Resultat:
0 24.99
1 24.23
2 23.47
3 22.71
4 21.95
5 21.19
6 20.43
7 19.67
8 18.91
9 18.15
10 17.39
11 16.63
12 15.87
13 15.11
14 14.35
15 13.59
16 12.83
17 12.07
18 11.31
19 10.55
20 9.79
21 9.02999
22 8.26999
23 7.50999
24 6.74999
25 5.98999
26 5.22999
27 4.46999
28 3.70999
29 2.94999
30 2.18999
31 1.42999
32 0.669994
REAL als Datentyp wird so beschrieben: Ungefähre Zahlendatentypen für numerische Gleitkommadaten. Gleitkommadaten sind Näherungswerte, deshalb können nicht alle Werte im Bereich des Datentyps exakt dargestellt werden. Hinweis: Das ISO-Synonym für real ist float(24).
, @real2 real = 24.99
, @i int = 0
while @real2 > 0
begin
print cast(@i as varchar(10)) + ' ' + cast(@real2 as varchar(10))
set @i = @i + 1
set @real2 = @real2 - @real1
end
Resultat:
1 24.23
2 23.47
3 22.71
4 21.95
5 21.19
6 20.43
7 19.67
8 18.91
9 18.15
10 17.39
11 16.63
12 15.87
13 15.11
14 14.35
15 13.59
16 12.83
17 12.07
18 11.31
19 10.55
20 9.79
21 9.02999
22 8.26999
23 7.50999
24 6.74999
25 5.98999
26 5.22999
27 4.46999
28 3.70999
29 2.94999
30 2.18999
31 1.42999
32 0.669994
REAL als Datentyp wird so beschrieben: Ungefähre Zahlendatentypen für numerische Gleitkommadaten. Gleitkommadaten sind Näherungswerte, deshalb können nicht alle Werte im Bereich des Datentyps exakt dargestellt werden. Hinweis: Das ISO-Synonym für real ist float(24).
| Datentyp | Bereich | Speicherung |
| real | - 3,40E + 38 bis -1,18E - 38, 0 und 1,18E - 38 bis 3,40E + 38 | 4 Byte |
