Strange Attractors mit BigDecimal

26.02.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

Das Verhalten dieses Systems kann nun auch interaktiv mittels Jupyter erforscht werden: Mein Projekt auf GitHub zum Thema Nichtlineare dynamische Systeme enthält dazu ein Notebook, das direkt über diesen Link in MyBinder gestartet werden kann.

Artikel, die hierher verlinken

Van-der-Pol- und Chua-Systeme

26.02.2020

Ich wollte nach längerer Zeit wieder einmal in die Welt chaoticher Systeme eintauchen und habe mich dazu mit zwei Systemen beschäftigt...

Doppelte Genauigkeit in Java

03.08.2019

Ich berichtete hier bereits von den durch die Einschränkungen der Fließkomma-Arithmetik-Implementierungen in modernen Computersystemen zu beachtenden Ungenauigkeiten in numerischen Computersimulationen am Beispiel nichtlinearer dynamischer Systeme. Nach meinen ersten Versuchen der Shaderprogrammierung habe ich eine weitere Methode untersucht, dieser Ungenauigkeiten mit vertretbarem Aufwand Herr zu werden...

GC und beliebige Präzision in Java

24.11.2018

Das letzte Mal, als ich über Vor- und Nachteile der Durchführung mathematischer Berechnungen mit verschiedenen Datentypen schrieb, vernachlässigte ich einen Aspekt, dessen Einfluss und Wichtigkeit von der benutzten Programmiersprache und konkreten Implementierung abhängt:

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Mandelbrot-Sets mittels Shadern berechnen

    17.05.2019

    Nachdem ich in den letzten verregneten Tagen auf Youtube in den Videos von Numberphile versunken bin, hat mich eines davon angestachelt, mich selbst mit dem Mandelbrotset zu beschäftigen. Als ich dann noch Code fand, der behauptete, das auf einer Graphikkarte mittels Shadern berechnen zu können, war es um mich geschehen...

    Weiterlesen...

Neueste Artikel

  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...
  • bad-certificates Version 2.1.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern hat eine Erweiterung erfahren und verfügt über ein Partnerprojekt - beide sind nunmehr in der Version 2.1.0 freigegeben

    Weiterlesen...
  • SQLite als Geodatenbank

    Wie bereits in einem früheren Artikel beschrieben treibe ich derzeit Anstrengungen voran, die sQLshell attraktiver für Nutzer zu machen, die mit Geodatenbanken arbeiten.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.