Numerische Singularitäten in den Griff bekommen?

Infinity

Registriertes Mitglied
Hallo,

im vor einigen Monaten von mir erwähnten Buch Hawkings neues Universum geht es u.a. neben mathematischen, Koordinaten- und Krümmungssingularitäten auch um numerische Singularitäten.
Dort wird aus Hawkings Überlegungen, die von Vaas schriftlich auf Deutsch verfasst worden sind, gesagt, dass solche wegen der Genauigkeit von Errechnungen zustande kommen.

Es heißt:
So ist beispielsweise (1 + 10^-12) - 1 = 0, wenn man auf elf Stellen genau rechnet.
Demnach hieße es zwar (1 + 0) - 1 = 0, es folgt:
[..] Eine geschickte Umformulierung bekommt eine solche numerische Singularität jedoch in den Griff: (1 - 1) + 10^-12 ergibt auch bei elf Stellen Rechengenauigkeit noch 10^-12

Wie kann ich das nachvollziehen? Welche besondere Rolle spielen hier die Klammern?

Besten Dank und Gruß:
infiniti
 

Orbit

Registriertes Mitglied
Wie kann ich das nachvollziehen?
Indem Du es einmal auf beide Arten in Deinen Rechner eingibst. :)
Ein Kind, das noch nicht in Dezimalbrüchen denken und rechnen kann, kriegt's schon mit der numerischen Singularität zu tun, wenn in seiner Rechnung einfache Bruchzahlen vorkommen.
Orbit
 
Zuletzt bearbeitet:

Infinity

Registriertes Mitglied
Indem Du es einmal auf beide Arten in Deinen Rechner eingibst.
Wenn man 10^-12 auf elf Stellen ausrechnet, hat man doch den Wert 0 (0,00000000000)
Bedeutet beim ersten Zitat:
(1 + 0) - 1 = 0
Beim zweiten müsste es doch so heißen:
(1 - 1) + 0 = 0, und nicht = 10^-12.

Man hat doch praktisch den Wert 10^-12 nicht, weil man nur 11 Stellen hinter dem Komma ausgerechnet hat, also wird aus 10^-12 (0,000000000001) eine 0,00000000000.
 
Zuletzt bearbeitet:

Orbit

Registriertes Mitglied
infiniti
Es geht hier um Rundungsprobleme, welche mit der Kapazität des Rechners zu tun haben. Also nichts Weltbewegendes.
 

Infinity

Registriertes Mitglied
Um Berechnungen mit Computern geht es ja, das hab ich unter Numerik nicht mehr so sehr beachtet. Danke, Orbit ;).
 

Infinity

Registriertes Mitglied
Auch ich denke so. Bis ich bei so einigen mit einem gewissen Wissensstand ankomme, habe ich ein paar Stockwerke vor mir :D.
Da die Ferien bei uns vor der Tür stehen, kann ich mich nun ganz meinen Büchern widmen.

Gruß!
infiniti
 

exi

Registriertes Mitglied
Wenn man 10^-12 auf elf Stellen ausrechnet, hat man doch den Wert 0 (0,00000000000)
Bedeutet beim ersten Zitat:
(1 + 0) - 1 = 0
Beim zweiten müsste es doch so heißen:
(1 - 1) + 0 = 0, und nicht = 10^-12.

Man hat doch praktisch den Wert 10^-12 nicht, weil man nur 11 Stellen hinter dem Komma ausgerechnet hat, also wird aus 10^-12 (0,000000000001) eine 0,00000000000.

Hallo,

mir erscheint das Beispiel als an den Haaren herbei gezogen. Und die Verwendung der Klammern dient nur der Verwirrung. Die Klammern sollen davon ablenken, daß im ersten Fall 10^-12 numerisch aufgelöst wurde - aber im zweiten Fall in Exponentenform stehen bleiben durfte.
Numerisch, bei Ausführung mit einem Rechner auf 11 Stellen genau, werden beide Ergebnisse gleich sein: 0,00000000000

Der Unterschied kommt eigentlich erst dann zum tragen, wenn man zweierlei Maß anlegt. Einmal soll ein Computer unter Ausschluß der Exponentendarstellung rechnen. Dann soll ein Mensch zur Kontrolle unter Nutzung der Exponentendarstellung gegenrechnen.
Als Singularität würde ich das Problem nicht bezeichnen. Aber ohne Zweifel ist die begrenzt darstellbare Genauigkeit ein grundlegender Fehler jeder Simulation. Ohne Zweifel suggeriert die Begrenzung der darstellbaren Information Beziehungen die es in der Wirklichkeit dann doch nicht gibt.

tschüs
exi
 

ralfkannenberg

Registriertes Mitglied
Hallo,

mir erscheint das Beispiel als an den Haaren herbei gezogen. Und die Verwendung der Klammern dient nur der Verwirrung.

Hallo exi,

ganz im Gegenteil - das ist ein häufig gemachter Praxisfehler, den man in der Mathematik auch "Auslöschungseffekt" nennt und den selbst Spezialisten oftmals übersehen - so ist beispielsweise die elegante Berechnung der Standardabweichung mit "Anzahl Werte", "Summe" und "Quadratsumme" sehr auslöschungsgefährdet, weil im Zähler eine Differenz zweier Quadrate (im Wesentlichen Quadratsumme und Quadrat des Mittelwertes) steht und bei einer guten Messung sehr klein wird, da die Standardabweichung ja idealerweise klein sein soll.

Wenn man das programmiert, kriegt man da ehe man sich versieht, Wurzeln aus negativen Zahlen, weil eben bei dieser Differenzenbildung gerundet wird.

Durch geschickteres Klammern oder durch exaktes Rechnen - in diesem Falle genügen 2-Tupel mit Zähler und Nenner und entsprechend programmierten Rechenregeln (in diesem Falle die Bruchrechenregeln) kann man solche Auslöschungsphänomene umgehen; ein Trick bei der Lösung einer quadratischen Gleichung kann auch sein, eine Lösung (die mit dem "plus") und die andere mit dem Satz von Vieta.

Das Problem kann also dann auftreten, wenn zwei fast gleichgrosse Zahlen subtrahiert werden.


Diese Phänomene und was man dagegen tun kann werden in der Mathematik in der "Numerik" untersucht.


Freundliche Grüsse, Ralf
 

mac

Registriertes Mitglied
Hallo,

besonders bei sehr großen Unterschieden der hier zu verarbeitenden Zahlen ist es notwendig die (z.B. Summanden) vorher nach (absoluter)Größe zu sortieren und mit den kleinsten Zahlen zu beginnen, um diese eben nicht unter den Tisch fallen zu lassen.

Praktische Anwendung: Z.B. Simulation eines Kugelsternhaufens.

Herzliche Grüße

MAC
 

ralfkannenberg

Registriertes Mitglied
Hallo zusammen,

auch wenn das in diesem Zusammenhang etwas off-topic ist:

Auch wenn man exakt rechnet kann es passieren, dass das Ergebnis einer Summe von der Reihenfolge der Summanden abhängt.

Dies ist für die meisten überraschend und widerspricht der Erfahrung und solange man nur Summen mit endlich vielen Summanden betrachtet ist bei exakter Rechnung das Ergebnis natürlich unabhängig von der Reihenfolge der Summanden.

Dies ändert sich bei Summen - man nennt diese übrigens Reihen -, welche unendlich viele Summanden haben, die aber konvergent sind.

Wenn diese absolut konvergent sind, d.h. die Summe der Absolutbeträge konvergiert, hängt das Ergebnis ebenfalls nicht von der Reihenfolge der Summanden ab.

Es könnte aber sein, dass man zwei Teilsummen bzw. genauer: zwei Teilreihen bilden kann, von der die eine gegen +unendlich divergiert und die andere gegen -unendlich divergiert. Eine solche Reihe ist natürlich nicht absolut konvergent und in einer solchen Konstellation kann (muss nicht, aber kann) es passieren, dass das Ergebnis von der Reihenfolge der Summanden abhängt.

Das ist schon anschaulich irgendwo klar, denn es ist "heikel" (und insbesondere nicht definiert), wenn man +unendlich und -unendlich miteinander addiert.


Freundliche Grüsse, Ralf
 

exi

Registriertes Mitglied
Hallo Ralf,

ganz im Gegenteil - das ist ein häufig gemachter Praxisfehler, den man in der Mathematik auch "Auslöschungseffekt" nennt und den selbst Spezialisten oftmals übersehen - so ist beispielsweise die elegante Berechnung der Standardabweichung mit "Anzahl Werte", "Summe" und "Quadratsumme" sehr auslöschungsgefährdet, weil im Zähler eine Differenz zweier Quadrate (im Wesentlichen Quadratsumme und Quadrat des Mittelwertes) steht und bei einer guten Messung sehr klein wird, da die Standardabweichung ja idealerweise klein sein soll.

... wie ich bereits gesagt habe sehe auch ich die endliche Darstellbarkeit als Fehlerquelle bei (automatisierten) Berechnungen. - In diesem Punkt sind wir uns einig.

'infiniti', bzw. das Buch um das es ihm/ihr geht, verschweigt aber dass dann grundsätzlich mit unterschiedlichen Maßstäben gerechnet wird. Auch der Hinweis von 'UMa' geht in die Richtung, daß *stillschweigend* Äpfel mit Birnen verglichen werden: integer mit float, oder float mit double precission.
Zieht man dagegen (wie 'infiniti' und ich) beide Berechnungen unter Erhalt des Zahlentyps aus, dann entsteht die angebliche Singularität nicht. Dann wird die Differenz in beiden Rechnungen zu Null (auf 11 Nachkommastellen genau) oder bleibt in beiden Rechnungen 10^-12.
Von einer Singularität zu reden weil man in einem der beiden Rechenfälle einen impliziten cast (Typwandel) hinnimmt, im anderen Rechenfall nicht, halte ich für etwas übertrieben.

tschüs
exi
 

Infinity

Registriertes Mitglied
das Buch um das es ihm/ihr geht
Ihm :)

verschweigt aber dass dann grundsätzlich mit unterschiedlichen Maßstäben gerechnet wird
Es stimmt, es ist das dritte Buch, das ich von Hawking lese und musste desöfteren feststellen, dass er das eine oder andere verschweigt. Daher kann es bei manchen Sätzen ein wenig dauern, bis man sie begreift. Ich denke, er hat seine Überlegungen absichtlich kurz und knapp verfasst, denn seine Werke sollten nicht 400, 500 Seiten groß sein. Allerdings hätte ich mir gewünscht, dass er seinen darin enthaltenen bisherigen Lebenslauf (46 Seiten) weglassen und stattdessen mehrere Begriffe ausführlicher erklären würde. Man kann seine Biografie auch in anderen Büchern nachlesen.

Dann wird die Differenz in beiden Rechnungen zu Null (auf 11 Nachkommastellen genau) oder bleibt in beiden Rechnungen 10^-12.
Ja, aber wie es Orbit, ralfkannenberg etc. bereits auffassten, geht es hier um Numerik (Threadtitel), entspricht nicht ganz genau dem, wie wir beide es errechnen würden bzw. es erlernt haben (0 oder 10^-12).

Grüße!
infiniti
 

Ich

Registriertes Mitglied
Auch der Hinweis von 'UMa' geht in die Richtung, daß *stillschweigend* Äpfel mit Birnen verglichen werden: integer mit float, oder float mit double precission.
Du hast's nicht verstanden. Der Zahlentyp ist Fließkomma und bleibt Fließkomma. Double zum Beispiel.
Geh an den Taschenrechner und gib 1e-50 + 1 -1 ein.
 

Orbit

Registriertes Mitglied
Schön, dass ausgerechnet mein Lehrmeister auf dieselbe Idee kommt wie ich bereits im 2. Beitrag in diesem Thread. Dass ich so etwas auf meine alten Tage noch erleben durfte! :)
Orbit
 

ralfkannenberg

Registriertes Mitglied
Du hast's nicht verstanden. Der Zahlentyp ist Fließkomma und bleibt Fließkomma. Double zum Beispiel.
Geh an den Taschenrechner und gib 1e-50 + 1 -1 ein.
Deswegen ist es eben wichtig, mit exakten Datentypen zu arbeiten.

Dass manche der heutigen Programmiersprachen grosszügigerweise einen Integer bei Addition mit einer Fliesskommazahl den Integer ebenfalls stillschweigend umwandeln, "vertuscht" das Phänomen nur; man muss einfach sorgfältig darauf achten, ob man exakt rechnet oder gerundet rechnet.

Man kann übrigens auch Wurzeln (allgemeiner: algebraische Zahlen) exakt rechnen, ist aber nicht ganz trivial: Man rechnet dann mit den erzeugenden Polynomen, was nicht ganz einfach ist und muss zusätzlich darauf achten, dass eine Wurzel n.-ten Grades eben noch n-1 "Geschwister" hat, die dasselbe Erzeugendenpolynom haben.


Freundliche Grüsse, Ralf
 

Ich

Registriertes Mitglied
Deswegen ist es eben wichtig, mit exakten Datentypen zu arbeiten.
Nö, deswegen ist es wichtig, die Rundungsfehler nicht auch noch künstlich aufzublasen.
Ich bezweifle nicht grundsätzlich, dass man Simulationen auch mit exakten Datentypen laufen lassen könnte. Aber erstens ist das ein Riesenaufwand, zweitens irre langsam, drittens kriegt man höchstwahrscheinlich neue Fehler, die man kaum finden kann (siehe 1.), und 4. wird, von Spezialfällen abgesehen, die erreichbare Genauigkeit auch kaum besser sein.
Exakte Datentypen sind was für Banker und Mathematiker.
Dass manche der heutigen Programmiersprachen grosszügigerweise einen Integer bei Addition mit einer Fliesskommazahl den Integer ebenfalls stillschweigend umwandeln...
Die heutigen Programmiersprachen (z.B. C#) erlauben kaum noch implizite Umwandlungen. Die sind da nachgerade nervtötend stur, früher war alles viel besser. ;)
Man kann übrigens auch Wurzeln (allgemeiner: algebraische Zahlen) exakt rechnen
Man kann das auch bleiben lassen und die gesparte Zeit am Badesee verbringen.
 

exi

Registriertes Mitglied
Hallo zusammen,

grundsätzlich gehe ich davon aus, daß sich die numerische Singularität bei Verwendung exakter Datentypen in Luft auflöst. (Ich sagte bereits: in diesem Fall stört mich die Bezeichnung Singularität.)

Nö, deswegen ist es wichtig, die Rundungsfehler nicht auch noch künstlich aufzublasen.
Ich bezweifle nicht grundsätzlich, dass man Simulationen auch mit exakten Datentypen laufen lassen könnte. Aber erstens ist das ein Riesenaufwand, zweitens irre langsam, drittens kriegt man höchstwahrscheinlich neue Fehler, die man kaum finden kann (siehe 1.), und 4. wird, von Spezialfällen abgesehen, die erreichbare Genauigkeit auch kaum besser sein.
Exakte Datentypen sind was für Banker und Mathematiker.

.... also, wenn es hart auf hart kommt, dann stelle ich eine Zahl eben Ziffernweise dar! n Stellen vor dem Komma, m Stellen nach dem Komma, eine Stelle für das Komma. Für 10^-12 eben 13 Byte für die Ziffern und ein Byte fürs Komma. Und für 10^-50 einfach 51 Byte für Ziffern und ein Byte fürs Komma. Und falls ich beide multipliziere, dann beantrage ich weiteren Speicherplatz für jede neu entstandene Ziffernstelle.
Der menschliche Aufwand wäre gering. Die Routine (die mancher von uns im EDV-Labor schon mal gebastelt hat) müßte nur einmal bereit gestellt werden.
Maschinenaufwand wäre schon gegeben, aber das können wir bagatellisieren. Anstatt die Zahlen in 8 Byte zu pressen und Rundungsfehler mitzuschleppen, bräuchte man eben 10 bis 100 mal mehr Speicher - abhängig von der Zahl selbst - und wäre dafür frei von Rundungsfehlern. Der Zeitaufwand würde auch wachsen, vermutlich auch um den Faktor 100 bis 1000 (abhängig davon welche Operation man ausführt). Aber mittlerweile gibt es Arbeitsspeicher im Megabereich, Festplatten in der Nähe von Terabyte und die Taktraten liegen bei Gigahertz. Also wäre der Aufwand jetzt schon durch die Technik überholt.

Du hast natürlich darin recht, daß solch exakte Rechnungen nur etwas für Mathematiker sind. Aber die Fälle wo in der Astrophysik die numerische Anomalie zum tragen kommt, die ist mathematischer Natur. Und Astrophysiker sind durch die Bank hinweg verkappte Mathematiker.

tschüs
exi
 
Zuletzt bearbeitet:

ralfkannenberg

Registriertes Mitglied
.... also, wenn es hart auf hart kommt, dann stelle ich eine Zahl eben Ziffernweise dar! n Stellen vor dem Komma, m Stellen nach dem Komma, eine Stelle für das Komma. Für 10^-12 eben 13 Byte für die Ziffern und ein Byte fürs Komma. Und für 10^-50 einfach 51 Byte für Ziffern und ein Byte fürs Komma. Und falls ich beide multipliziere, dann beantrage ich weiteren Speicherplatz für jede neu entstandene Ziffernstelle.
Gut, dann mache das mal z.B. mit der Zahl 1/3.


Du hast natürlich darin recht, daß solch exakte Rechnungen nur etwas für Mathematiker sind.
Weisst Du eigentlich auch warum ? Um zu zeigen, dass sowas prinzipiell möglich ist. Wie "Ich" aber schon geschrieben hat wird man rechenintensive Rechnungen wegen des enorm höheren Rechenaufwandes nur in den seltensten Fällen exakt bewältigen können, d.h. da muss man halt ein bisschen denken und sich dann anderweitig behelfen.


Freundliche Grüsse, Ralf
 
Oben