C# Genauigkeit von double

[Incanus]

Mit solchen Ungenauigkeiten kommst Du aber beim Programmieren nicht weiter. Da ist schon Präzision gefragt.
Aber jetzt kommst Du vorwärts?

 

[DeepComputer]

Ne, ist aber auch nicht so wichtig. Ich dachte, vllt kanns mir wer auf die schnelle erklären.

 

[Incanus]

Es wurde doch mehr als ausreichend und mehrfach erklärt.

 

[Phrasendreher]

Ich hau mal einen ausm real life raus:
Bei der Umsatzsteuervoranmeldung gebe ich u.a. meine Ein- und Ausgaben an;
die Beträge sind in Euro und Cent - also Euro plus zwei Nachkommastellen; es wird kaufmännisch gerundet.

Wenn ich im betrachteten Zeitraum den Firmenwagen zweimal fuer je exakt 20€ getankt habe, ist die MwSt. jeweils 3.19€ (kaufm. abgerundet, eigentlich eher so 3,1932773109243697478991596638655).
Ergibt 2x 3.19=6.38€ USt die ich an andere Unternehmen gezahlt habe.
Im nächsten Zeitraum tanke ich einmal für exakt 40€ - gezahlte MwSt. ist 6.39€ (eigentlich 6,3865546218487394957983193277311 - da wird kaufm. aufgerundet).
Diesen Betrag gebe ich also bei der UStVA an.
Fällt Dir was auf?

 

[DeepComputer]

Ja, der Datenverlust beim Runden! Und unser Lehrer hat uns das eben so "halb-binär" vorgerechnet wie das zustande kommt. Also irgendwie so, die Differnez 1 - 0.9989846 = x und x sieht binär so aus 1010 1111, weil an stelle 2^n der Rundungsfehler passiert. (zahlen frei erfunden) Und das ganze hat ja ein Muster dahinter. Also der Rundungsfehler ist ja immer der gleiche.
Irgendwie so hat er es uns vorgerechnet und das hätte ich gerne verstanden. Er hat daraus sozusagen ein Nullsummenspiel gemacht.

 

[Bonanca]

Irgendwie so hat er es uns vorgerechnet und das hätte ich gerne verstanden. Er hat daraus sozusagen ein Nullsummenspiel gemacht.

Wenn du das gerne verstehen würdest und mit den bisher geposteten infos nicht weiter kommst, dann musst entweder den genauen Sachverhalt schildern (nicht "also irgendwie so") oder ein konkretes Beispiel nennen können.

Sonst sind wir bei der Aussage aus Post #21.

 

[Raijin]

Wenn der Lehrer etwas erklärt hat, wird es auch Literatur dazu geben. Buch, Skript, Folien, what ever.

 

[Nolag]

Irgendwie so hat er es uns vorgerechnet und das hätte ich gerne verstanden.

Es ist eigentlich ganz einfach. Bei IEEE754 Fließkommazahlen mit doppelter Genauigkeit ist die Mantisse z.B. 52 Bit groß.

2⁵² = 4.503.599.627.370.496
1 / 4.503.599.627.370.496 = 2,22*10^-16

Das ist der kleinste Unterschied zwischen zwei Werten, der ohne einen Exponenten repräsentiert werden kann. Bei großen Zahlen muss dieser Wert mit dem Exponenten multipliziert werden, und der Rundungsfehler kann dann deutlich größer werden. Bei einem Wert in der Größenordnung von 1000000 ist die Auflösung entsprechend nur noch 2,22*10^-10

 

[BeBur]

Das ist der kleinste Unterschied zwischen zwei Werten, der ohne einen Exponenten repräsentiert werden kann. Bei großen Zahlen muss dieser Wert mit dem Exponenten multipliziert werden, und der Rundungsfehler kann dann deutlich größer werden.

Ich fand es sehr einleuchtend mir vorzustellen, dass die 52 Bit der Mantisse ja fix sind, aber bei großen Zahlen werden die ganzen Vorkommastellen ja mit rein geschoben in die Mantisse. Also bei einer Zahl mit 51 (Bit-)Stellen vor dem Komma bleibt nur noch ein Bit für die Nachkommastellen übrig.

 

[Andi_bz]

Ist es nicht, weil der PC die Nummer binär abspeichert und so eine Ungenauigkeit entsteht?

 

[Incanus]

Doch, aber da waren wir ja gestern schon .

 

[BeBur]

Ist es nicht, weil der PC die Nummer binär abspeichert und so eine Ungenauigkeit entsteht?

Beide Effekte spielen eine Rolle. In jedem Zahlensystem gibt es viele Zahlen, die sich nicht endlich darstellen lassen, z.B. 1/3 = 0,333....
Das sind aber im Dezimalsystem andere Zahlen als im Binärsystem. 1/10 = 0,1 lässt sich binär nicht endlich darstellen. Die IEEE754 Problematik kommt noch oben drauf.

 

[andy_m4]

In jedem Zahlensystem gibt es viele Zahlen, die sich nicht endlich darstellen lassen, z.B. 1/3 = 0,333....

Wobei es auch davon anhängt, wie man die Zahlen speichert. Das 1/3 kann man ja als 1/3 speichern und dann kommt man auch nicht in Probleme. Es gibt ja sogar in einigen Programmiersprachen explizit einen Support für z.B. rationale Zahlen. Mit denen kannst Du dann auch problemlos seitenweise rechnen ohne das Du in Rundungsprobleme läufst.

 

[RalphS]

Es sei denn, es gäbe ein π irgendwo in der Berechnung 😁

Gabs schon irgendwo einen Beweis oder sowas, daß (bzw daß nicht) eine beliebige, aber fixe irrationale Zahl in allen Zahlensystemen irrational ist?
Ansonsten bleibt notwendigerweise eine Berechnung mit zB π eine bloße Approximation, egal wie genau die numerische Repräsentation davon ist.

 

[KitKat::new()]

Es sei denn, es gäbe ein π irgendwo in der Berechnung 😁

Auch Pi kann man als PI Konstante in der Rechnung behalten ohne es numerisch aufzulösen.

Ansonsten bleibt notwendigerweise eine Berechnung mit zB π eine bloße Approximation, egal wie genau die numerische Repräsentation davon ist

Sin(2pi)=0

Stichwort symbolische Mathematik.

 

[RalphS]

Okay, wenn man komplette "∏-Arithmetik" implementiert und π als Faktor im Ergebnis beläßt.

Aber nur dann. Mit einem Symbol läßt sich nicht rechnen. Der Wert muß irgendwo dargestellt werden und π kann durch kein einziges endliches numerisches System (aka irgendein Rechner beliebiger Natur) exakt dargestellt werden.

Heck, das können nicht mal wir Menschen.

 

[KitKat::new()]

Okay, wenn man komplette "∏-Arithmetik" implementiert und π als Faktor im Ergebnis beläßt.

Aber nur dann. Mit einem Symbol läßt sich nicht rechnen.

Doch, Matlab kann das z.B. bzw. rechnet man mit einem Symbol genau so, dass es im Ergebnis bleibt (falls notwendig - manchmal kürzt es sich raus): https://www.mathworks.com/help/symbolic/performing-symbolic-computations.html

Der Wert muß irgendwo dargestellt werden und π kann durch kein einziges endliches numerisches System (aka irgendein Rechner beliebiger Natur) exakt dargestellt

Muss es ja auch nicht, eine Darstellung im Sinne von 1/3*pi ist doch auch möglich.

(Es natürlich oft eine numerische Repräsentation nötig)

 

[andy_m4]

Okay, wenn man komplette "∏-Arithmetik" implementiert und π als Faktor im Ergebnis beläßt.

Ja. Und das ist jetzt auch kein ungewöhnliches Vorgehen. Mathematikprogramme können das schon länger.

Mit einem Symbol läßt sich nicht rechnen. Der Wert muß irgendwo dargestellt werden und π kann durch kein einziges endliches numerisches System (aka irgendein Rechner beliebiger Natur) exakt dargestellt werden.

Muss er ja auch nicht. Klar willst Du vielleicht am Ende einen numerischen Wert haben. Aber dann (und nur dann) rechnest Du den eben aus und hast dann Rundungsfehler nur noch im Ergebnis und nicht in der Rechnung.