Diskussion:Auslöschung (numerische Mathematik)
Die Aussage, dass die Ausloeschung ein Spezialfall des Unterlaufs ist, muss wohl klar als falsch zurueckgewiesen werden. Richtig ist: Es kann bei der Subtraktion sowohl zu Ausloeschung als auch zu einem Unterlauf kommen. Daraus einen Zusammenhang zwischen beidem zu konstruieren, halte ich aber fuer falsch. Unterlauf tritt auf, wenn die Zahl zu klein wird. Soll heissen, wenn die Stellen des Exponenten nicht mehr ausreichen um die Zahl von der Null zu unterscheiden. Bei der Ausloeschung heben sich hingegen die verfuegbaren Stellen der Mantisse auf, sodass zur Berechnung eines Ergebnisses keine Information mehr vorhanden ist. Das falsche Ergebniss einer Ausloeschung ist aber sehr wohl darstellbar, sollange genuegend Exponentenstellen vorhanden sind, es also nicht zusaetzlich zu einem Unterlauf kommt. 13:41, 26. Jun 2006
Kann man Wikipedia dazu überreden, die Formeln im Text alle mit derselben Schriftgröße zu setzen? Ich krieg es nicht hin.
--Brf 09:55, 22. Nov. 2006 (CET)
- Nein, kann man nicht, da je nach Benutzereinstellungen das eingebundene LaTex (<math<) als HTML oder als PNG ausgegeben wird. Hat man den Standard eingestellt, werden einfache Formeln als HTML, komplizierte als PNG ausgegebn, was ein buntes Durcheinander im Text zur Folge hat. --87.166.245.63 00:05, 2. Nov. 2009 (CET) (aka Benutzer:Benji)
Algorithmus des Archimedes zur Kreiszahlberechnung
Also zumindest die erste Tabelle in Auslöschung_(numerische_Mathematik)#Beispiel:_Algorithmus_des_Archimedes_zur_Kreiszahlberechnung kann ich leider nicht nachvollziehen. Mittels Datei:C-AlgorithmusdesArchimedeszurKreiszahlberechnung.pdf habe ich folgendes Ergebnis erstellt. Die Vorletzte Zeile zeigt dabei am deutlichsten den Unterschied:
n sn an 2 2.000000e+00 2.00000000000000 4 1.414214e+00 2.82842712474619 8 7.653669e-01 3.06146745892072 16 3.901806e-01 3.12144515225805 32 1.960343e-01 3.13654849054594 64 9.813535e-02 3.14033115695474 128 4.908246e-02 3.14127725093276 256 2.454308e-02 3.14151380114415 512 1.227177e-02 3.14157294036788 1024 6.135914e-03 3.14158772527996 2048 3.067960e-03 3.14159142150464 4096 1.533981e-03 3.14159234561108 8192 7.669904e-04 3.14159257654500 16384 3.834952e-04 3.14159263346325 32768 1.917476e-04 3.14159265480759 65536 9.587380e-05 3.14159264532122 131072 4.793690e-05 3.14159260737572 262144 2.396845e-05 3.14159291093967 524288 1.198423e-05 3.14159412519519 1048576 5.992120e-06 3.14159655370482 2097152 2.996060e-06 3.14159655370482 4194304 1.498067e-06 3.14167426502176 8388608 7.490706e-07 3.14182968188920 16777216 3.746094e-07 3.14245127249413 33554432 1.873047e-07 3.14245127249413 67108864 9.424322e-08 3.16227766016838 134217728 4.712161e-08 3.16227766016838 268435456 2.580957e-08 3.46410161513775 536870912 1.490116e-08 4.00000000000000 1073741824 0.000000e+00 0.00000000000000
--Anonym 18:34, 24. Jan. 2010 (CET)
Auch in GNU_Octave zeigt sich eigentlich das Selbe:
function sn = AlgorithmusdesArchimedeszurKreiszahlberechnung(n)
if n==2
sn = 2;
else
sn = sqrt(2-2*sqrt(1-AlgorithmusdesArchimedeszurKreiszahlberechnung(n/2)^2/4));
end
end
octave:55> 2^(27-1)*AlgorithmusdesArchimedeszurKreiszahlberechnung(2^27)
ans = 3.16227766016838
octave:53> 2^(28-1)*AlgorithmusdesArchimedeszurKreiszahlberechnung(2^28)
ans = 3.46410161513775
octave:51> 2^(29-1)*AlgorithmusdesArchimedeszurKreiszahlberechnung(2^29)
ans = 4
octave:54> 2^(30-1)*AlgorithmusdesArchimedeszurKreiszahlberechnung(2^30)
ans = 0
--Anonym 18:43, 24. Jan. 2010 (CET)
Ich verstehe Deine Bedenken nicht: Die Ergebnisse Deines Programms konvergieren bis n=32768; danach schlägt Auslöschung zu und die Genauigkeit geht bergab. Wo ist Deine Frage= Brf 18:13, 28. Nov. 2012 (CET)==
Ohne mich jetzt genau damit auseinanderzusetzen nochmal kurz der Einwand von damals. Mein Programm hat
n sn an 8192 7.669904e-04 3.14159257654500 536870912 1.490116e-08 4.00000000000000
berechnet, während im Artikel
8192 7.353e-08 7.67e-04 7.67e-04 3.14159234553025 3.14159280755978 5.369e+08 0.000e+00 0.00e+00 0.00e+00 0.00000000000000 0.00000000000000
abgedruckt ist. Also bei einem -Eck liefert mein Programm , während im Artikel für der Wert 0 abgedruckt ist. Es können also nicht beide Rechnungen korrekt sein. Bei meiner Rechnung ist zumindest der Source-Code verfügbar und somit könnte jemand anderes mein Ergebnis bestätigen! --Anonym (Diskussion) 17:12, 25. Jan. 2014 (CET)
Vermeidung der Subtraktion?
Im Beispiel zur Auslöschung ist die Rede davon, dass man die Auslöschung vermeiden könne durch „Umformung der Formel in eine äquivalente Form ohne Subtraktion unter Anwendung von
”
Schaut man sich die Formel genau an, wird hier allerdings nach wie vor subtrahiert - nur werden eben die Quadrate subtrahiert und dann durch irgendwas geteilt. Ich will nicht bezweifeln, dass der relative Fehler durch diese Umformung geringer wird, bin mir aber selbst nicht sicher, woran es liegt. Vielleicht kann jemand, der sich damit auskennt, die Passage ja überarbeiten?
--Spasmus (Diskussion) 20:33, 2. Nov. 2012 (CET) Nein, weil das genau so stimmt - man muss nur weiterlesen: Es wird noch subtrahiert, ja, aber wenn man diese Formel dann in der Pi-Berechnung verwendet, hebt sich die Subtraktion im Zähler weg. Ist sie weg, ist auch die Auslöschung weg Brf 17:49, 28. Nov. 2012 (CET)==
relativer Fehler falsch
absoluter Fehler = 0,001111 - 0,001000 = 0,000111
relativer Fehler = absoluter Fehler / exakter Wert = 0,000111 / 0,001111 = 0,09990999099909990999099909990999 = 10,0 % != 11,1 % (nicht signierter Beitrag von 46.5.199.122 (Diskussion) 16:23, 17. Apr. 2014 (CEST))
- Hab’s korrigiert, danke für den Hinweis. -- HilberTraum (Diskussion) 09:19, 18. Apr. 2014 (CEST)