Updates

• 26. Februar 2020

Nachdem ich mir in meinem früheren Artikel zum Thema der Mathematik mit beliebiger Präzision in Java noch nicht sicher war ob es Sinn machen würde, mein Framework für die numerische Behandlung von Differentialgleichungssystemen auf die Option der Benutzung von BigDecimal als unterliegenden Datentyp zu erweitern, habe ich nun doch damit experimentiert:

Trotz meiner im früheren Artikel geäußerten Überraschung über das Fehlen jeglicher höherer Mathematik in Java im Datentyp BigDecimal prüfte ich das von mir geschaffene Framework für die numerische Behandlung von Differentialgleichungssystemen auf seine Konvertierbarkeit in den Datentyp BigDecimal.

Ich erkannte, dass ich höhere Mathematik tatsächlich nicht benötigte, so lange die zu lösenden Gleichungssysteme nur einfach genug waren und ich einfache Lösungsalgorithmen verwendete. Ich entschied mich, als Lösungsverfahren das (explizite) Eulerverfahren zu verwenden und die Experimente am Lorenz-Attraktor und dem Sprott-System M durchzuführen. Dazu plottete ich ausgehend von identischen Startzuständen jeweils 10000 Punkte der Trajektorien nach unterschiedlich vielen Iterationen.

Das System Sprott M zeigte erfreulich wenige Unterschiede zwischen beiden Verfahren - erst im letzten Bild sieht man einen qualitativen Unterschied - bis dahin waren die Unterschiede lediglich quantitativer Natur: Eine Schleife, die es bei x=0.5 und y=-1 und der Berechnung mit BogDecimal noch gibt, existiert bei der Berechnung mit doubles nicht mehr.

Sehr viel deutlicher (und früher) sind starke qualitative Unterschiede bei der gegenüberstellung der Berechnungen mit unterschiedlichen Datentypen am Lorenz-Attraktor zu sehen - dort treten bereits nach nur 100000 Schritten deutliche Unterschiede zu Tage.

Es sei abschließend noch angemerkt, dass für die Berechnungen mit BigDecimals die Genauigkeit ebenfalls eingeschränkt werden musste: Völlig alleingelassen stieg die Anzahl der Nachkommastellen, die für de Darstellung der Zwischenergebnisse benötigt wurde, immer weiter an, so dass die Berechnung schlussendlich zum Erliegen kam. Daher habe ich hier mit dem willkürlich festgelegten Wert von 100 Nachkommastellen bei der Benutzung von BigDecimal gearbeitet.

Ein weiterer Beleg für die unzureichende Qualität bei der Berechnung mathematischer Probleme mit dem Datentyp double - nicht nur mittels Java - zeigt sich bei der Berechnung der Differentialgleichung erster Ordung

mit

und dem Anfangswert

Hier sollte sich der Zustand (der Wert von x) asymptotisch dem Wert der Störung u annähern. Setzt man zum Beispiel

so sollte sich bei numerischer Lösung des Gleichungssystems der Wert von x langsam dem Wert 1 nähern. Behandelt man die Differentialgleichung aber mit dem Eulerverfahren mit einer festen Schrittweite von

so ändert sich der Wert von x ab Schritt 333 nicht mehr - er bleibt bei

stehen. Wenn aber gerade die 16. Stelle nach dem Komma für einen nachfolgenden Rechenschritt wichtig wäre - oder schlimmer noch: der Wert der Ableitung von x, der sich ja durch die Änderung von x von Zeitschritt zu Zeitschritt ausdrücken lässt - dann ist die gesamte Berechnung am diesem Schritt falsch.

Zum Vergleich noch die Werte an dieser Stelle bei der Berechnung mittels des Typs BigDecimal mit 100 Nachkommastellen (zur Darstellung schneide ich hier jeweils nach 20 Nachkommastellen ab):

Man sieht deutlich, dass die Berechnung nach dem 333. Schritt wegen der größeren Präzision weitergeht und auch den doch schon beachtlichen Fehler in Schritt 333.

Aktualisierung vom 26. Februar 2020

Screenshots

 

 

 

 

 

 

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )