Mathics 7.0 – Open-Source-Alternative zu Mathematica

 (github.com/Mathics3)
4 Punkte von GN⁺ 2024-12-09 | 1 Kommentare | Auf WhatsApp teilen
  • Mathics Core 7.0.0 bereinigt die Kern-Engine des Mathematica-kompatiblen Open-Source-Computersystems und legt die Grundlage für künftiges Lazy Loading integrierter Funktionen
  • Als neue integrierte Funktionen kommen unter anderem ComplexExpand, ConjugateTranspose und LeviCivitaTensor hinzu, mit Funktionen für Formeln, lineare Algebra und Erkennung reeller Werte
  • Lücken in der bestehenden Kompatibilität wurden geschlossen, etwa bei Range[], DirectedInfinity, Indeterminate, der Fehleranzeige in Graphics und Änderungen an $CharacterEncoding
  • Das Laden integrierter Funktionen wechselt von impliziten Import-Abhängigkeiten zu einem Modell, bei dem import_and_load_builtins() explizit aufgerufen wird
  • Enthält Unterstützung für Python 3.11 und SymPy 1.12 sowie Korrekturen rund um Quantity, SparseArray, Derivative, Exit[] und BaseForm

Release-Ausrichtung und interne Bereinigung

  • Mathics Core 7.0.0 enthält interne Strukturaufräumarbeiten, um künftig Lazy Loading integrierter Funktionen zu unterstützen
  • Python-Code und Stil wurden modernisiert, Typannotationen erweitert und mehrere Tippfehler korrigiert
  • Abhängigkeiten zu SymPy und Python wurden auf neuere Versionen aktualisiert
  • Außerdem wurde daran gearbeitet, die anfängliche Ladezeit zu verkürzen und den anfänglichen Speicherverbrauch zu senken

Neue integrierte Funktionen

  • In diesem Release wurden folgende integrierte Funktionen hinzugefügt
    • $MaxLengthIntStringConversion
    • Elements
    • ComplexExpand
    • ConjugateTranspose
    • LeviCivitaTensor
    • RealAbs, RealSign
    • RealValuedNumberQ

Verbesserungen bei Dokumentation und Testerzeugung

  • Mehrere Formatierungsprobleme in der PDF-Dokumentation wurden behoben
    • Der Abstand der Abschnittsnummern in Kapitel- und Abschnittsverzeichnissen wurde vergrößert
    • Der Abstand um Definitionen integrierter Funktionen wurde vergrößert
    • Tippfehler in der gesamten Dokumentation wurden bereinigt
  • Der Code für doctest-Ausführung und LaTeX-Dokumenterzeugung wurde überarbeitet und refaktoriert
    • Er erlaubt inkrementelle Updates integrierter Funktionen
    • Er wurde so bereinigt, dass duplizierter Code reduziert wird
  • In „Expression Structure“ wurde der Abschnitt Section Head-Related Operations neu hinzugefügt
  • Der PDF-Titel wurde von Mathics zu Mathics3 geändert, auch der Einführungstext wurde aktualisiert
  • Veraltete, nicht sichtbare und nicht lehrbezogene doctests wurden auf pytest umgestellt

Kompatibilität und für Nutzer sichtbare Verhaltensänderungen

  • *Plot zeigt während der Auswertung keine Meldungen an
  • Range[] verarbeitet negative di
    • Zugehöriger PR: #951
  • Die Unterstützung für DirectedInfinity und Indeterminate wurde verbessert
  • Graphics und Graphics3D werden mit pinkem Hintergrund angezeigt, wenn sie ungültige Primitives oder Directives enthalten
    • In der Mathics-Django-Oberfläche wird zusätzlich eine Tooltip-Fehlermeldung angezeigt
  • $CharacterEncoding kann innerhalb einer Sitzung geändert werden

Interne Implementierung und API-Änderungen

  • Aus Abs und Sign wurden eval_abs und eval_sign herausgelöst und zu mathics.eval.arithmetic hinzugefügt
  • Die maximale Anzahl zulässiger Ziffern in Strings wurde auf 7000 gesetzt
    • In Umgebungen wie pyston, in denen Python dies nicht automatisch anpasst, kann dies über die Umgebungsvariable MATHICS_MAX_STR_DIGITS angepasst werden
  • Die Implementierung von Vergleichen reeller Zahlen geht intern in die Implementierung von RealSign ein
  • Unter Python 3.11 steuert $MaxLengthIntStringConversion die maximale Größe von Literal-Konvertierungen zwischen großen Ganzzahlen und Strings
  • Das Laden integrierten Codes wurde von einem impliziten auf ein explizit angewiesenes Verfahren umgestellt
    • Diese Änderung soll künftig Lazy Loading integrierter Funktionen oder „autoload“ nach Art von GNU Emacs ermöglichen
  • Als neue API muss import_and_load_builtins() explizit aufgerufen werden
    • Zuvor war der Zeitpunkt des Ladens integrierter Funktionen abhängig von der Import-Reihenfolge implizit und unbestimmt
  • mpmath erhielt einen LRU-Cache

Bugfixes bei Quantity, SparseArray und mehr

  • Definitions ist mit pickle kompatibel
  • Die Unterstützung für Quantity-Ausdrücke wurde verbessert
    • Einschließlich Konvertierung, Formatierung und arithmetischer Operationen
  • Die Option Background von Graphics und Graphics3D funktioniert wieder
  • Probleme beim numerischen Vergleich von Ausdrücken mit String wurden behoben
    • Zugehöriges Issue: #797
  • Ein Problem mit Switch[] bei enthaltenem Infinity wurde behoben
    • Zugehöriges Issue: #956
  • Ein Problem mit Outer[] für SparseArray wurde behoben
    • Zugehöriges Issue: #939
  • ArrayQ[] erkennt SparseArray
    • Zugehöriger PR: #947
  • Die Ausnahme BoxExpressionError wird behandelt
  • Das Verhalten von Derivative bei der Auswertung von True, False und List[] wurde korrigiert
  • Korrekturen am Paket Combinatorica sind enthalten
  • Das nicht funktionierende Exit[] wurde behoben
  • BaseForm ist in $OutputForms enthalten

Unterstützte Paketversionen

  • Unterstützt Python 3.11
  • Unterstützt SymPy 1.12

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-09
Meinungen auf Hacker News

  • Ich beobachte dieses Projekt seit Jahren, und es entwickelt sich kontinuierlich gut weiter. Wenn man sich für Open-Source-Computeralgebrasysteme interessiert, gibt es viele ausgereiftere Lösungen, von klassischen Optionen wie GNU Octave oder Maxima bis hin zu modernen wie SAGEmath, Symbolics.jl und sympy.
    Die Bandbreite reicht von Bibliotheken für symbolisches Rechnen wie GiNaC bis zu „Batteries-included“-IDEs wie SAGEmath, und die Community ist ebenfalls aktiv. SAGEmath hat zum Beispiel die Web-Notebook-Oberfläche praktisch mitbegründet, die heute in verschiedenen Formen von Jupyter weiterlebt.
    Persönlich mag ich den Lisp-artigen Stil von Mathematica (MMA), aber was MMA stark macht, ist nicht nur der Core, sondern die riesige Bibliothek. Es gibt branchenweit führende Lösungen für grundlegende Themen wie symbolische Integration, 2D/3D-Grafik und die Finite-Elemente-Methode, dazu viele Spezialgebiete wie Bioinformatik.
    Mathics scheint den Core gut nachgebaut zu haben, aber natürlich fehlen all diese Bibliotheken. Die gleiche Logik gilt beim Vergleich von Matlab und seinen vielen „Toolkits“ mit einem numpy-Klon; allerdings hat der Python-Trend inzwischen viel neuen Code in die numpy-Welt gebracht, der in Matlab nicht läuft.

    • Ich stimme der Einschätzung zum Fortschritt zu. Dieses Projekt wirkt wie ein gutes Beispiel dafür, sich still und beharrlich in etwas hineinzuknien, das man mag.
      Als es vor etwa fünf Jahren erstmals auftauchte, dachte ich: „Die symbolische Evaluierungs-Engine ist wirklich gut gemacht, mal sehen, was daraus wird.“ Jedes Mal, wenn ich künftig Lust bekomme, ein neues Projekt zu starten, sollte ich an dieses Beispiel denken, bei dem ein altes Projekt weiter verfeinert wird.
    • Aus der Lisp-Ecke kommt man über Maxima leicht zu Common Lisp. Aus Performance-Gründen ist SBCL noch besser.
    • Vielleicht liege ich falsch, aber Octave, Matlab und numpy sehe ich nicht im selben Bereich wie Computeralgebrasysteme. Das sind alles auf numerisches Rechnen ausgerichtete Sprachen oder Bibliotheken, die eher dazu dienen, numerische Lösungen für Probleme zu finden, statt exakte symbolische Ausdrücke zu verarbeiten.
      Sie ergänzen sich gegenseitig und werden oft auch zusammen genutzt. Mathematica und Mathics scheinen beide Paradigmen zu unterstützen, aber dasselbe ist es nicht.

  • Sieht so aus, als basiere es auf sympy: https://www.sympy.org/en/index.html

  • Wenn man es nur privat nutzen will, kann man Wolfram Cloud kostenlos verwenden. Dateien werden wohl nach etwa 30 Tagen gelöscht. Wolfram Engine ist ebenfalls eine Möglichkeit, Mathematica kostenlos über die Kommandozeile zu nutzen. Nun ja, besser als nichts.

    • Man kann auch einen Raspberry Pi kaufen, bei dem eine Mathematica-Lizenz enthalten ist.
    • WLJS auf Wolfram Engine obendrauf macht ziemlich Spaß.

  • Eine einfachere Einführung zu Mathics gibt es hier:
    https://mathics.org/

  • Irgendwie habe ich das Gefühl, dass das in SageMath integriert werden könnte :D

    • Mir ist keine konkrete Bewegung bekannt, Mathics in SageMath aufzunehmen. Wenn ich raten müsste: SageMath wird vor allem von Forschungsmathematikern und Kryptografen entwickelt, daher ist Performance bei der Aufnahme von Komponenten oft ein zentrales Thema.
      Einer der Gründe, warum SageMath das größte Cython-Projekt ist, liegt darin, dass Cython es Sage ermöglicht, schnelle C/C++-Bibliotheken zu nutzen.
      Mathics scheint sich derzeit nicht ernsthaft um Performance zu kümmern. Man kann zum Beispiel in Mathics einen kleinen Mikrobenchmark wie "AbsoluteTiming[Sum[i, {i, 1, 100000}]]" laufen lassen oder die Roadmap lesen.
      Das ist natürlich in Ordnung. Für die Mathematica-Programmiersprache gibt es viele interessante Anwendungen, bei denen Performance nicht wichtig ist, etwa um bestimmte symbolische Operationen zusammen mit dem Ausdruck sorgfältig Schritt für Schritt nachzuverfolgen.
      Die Hauptmotivation der Sage-Entwickler ist aber Spitzenforschung in der Mathematik, und dort ist Performance fast immer sehr wichtig. Performance ist auch der Grund, warum Sage vieles mit ähnlicher Funktionalität selbst implementiert, statt einfach sympy zu verwenden. sympy priorisiert einfache Installation und kann deshalb relativ langsam sein; bei SageMath hat einfache Installation überhaupt keine Priorität.
      Die Mission von SageMath ist es, eine tragfähige Alternative zu Mathematica, Matlab, Magma und Maple zu sein, aber das hieß nie, ein Klon zu werden. Es bedeutet zum Beispiel nicht, Mathematica-Code direkt auszuführen, sondern eine Alternative zu bieten, mit der Forschung, die man sonst in solchen Closed-Source-Programmen erledigt hätte, auf Open-Source-Mathematiksoftware unterstützt werden kann.

  • Software Engineers tun alles, um keine Softwarekosten zu zahlen.

    • Ich habe eine Mathematica-Lizenz, finde dieses Projekt aber auch ziemlich cool. Ich bin ebenfalls Software Engineer. Ich wäre eher überrascht, wenn die Mathics-Entwickler keine Mathematica-Nutzer wären.
    • Es geht nicht um den Preis, sondern um Freiheit.
    • Manche Menschen schreiben Software für sich selbst und veröffentlichen sie sogar als Open Source.
    • Früher habe ich 20 Dollar für eine Debian-Sarge-Hülle mit drei DVDs und ein Handbuch im Zeitschriftenformat bezahlt.

  • Mathematica ist auf dem Raspberry Pi kostenlos verfügbar[1], und die meisten Universitäten haben eine standortweite Lizenz. Auch die „Home & Hobby“-Lizenz ist nicht so teuer: Das Abo kostet 195 US-Dollar pro Jahr, die Dauerlizenz 390 US-Dollar, und die Verlängerung nur 175 US-Dollar[2]
    Ehrlich gesagt: Wer sich fürs Tinkering interessiert, sich diesen Preis aber nicht leisten kann, findet auch eine gecrackte Version nicht schwer und sie ist auch nicht schwer zu installieren.
    Persönlich mag ich Mathematica – genauer gesagt die „Wolfram Language“ – ziemlich gern und zahle auch gerne für die Hobby-Lizenz. Ich finde nicht nur, dass sie ihr Geld wert ist, sondern sehe die Unterstützung von Mathematik-Software auch als einen „guten Zweck“, für den man Geld ausgeben kann.
    Außerdem geben Amateurfotografen häufig mehr für Tools wie Adobe CC aus, als viele Programmierer insgesamt für ihre Werkzeuge ausgeben, und ich verstehe nicht, warum. Ähnlich ist es, wenn man für diverse Abo-Dienste 20–40 Dollar oder mehr im Monat ausgibt, aber bei Lizenzkosten von 200–400 Dollar zögert.
    Allerdings verbringe ich in meinem Fall mehr Zeit in Mathematica als in fast jedem anderen Programm, das auf meinem Computer installiert ist.
    Trotzdem hat Open-Source-Mathematiksoftware weiterhin einen wichtigen Platz. Mathematica ist im Großen und Ganzen umfassend, hat aber in höherer Mathematik immer noch erhebliche Lücken.
    Besonders bei eher „nischigen“ Bereichen der Mathematik fällt es mir aus zwei Gründen schwer zu glauben, dass es sie vollständig abdecken wird. Erstens sinkt der Return on Investment drastisch, je fortgeschrittener oder esoterischer ein Gebiet wird. Zweitens hat die Wolfram Language bereits mehr als 6000 eingebaute Funktionen; Hunderte weitere hinzuzufügen, um etwa Gruppentheorie umfassend zu unterstützen, ergibt nicht wirklich Sinn.
    Man könnte das über Pakete unterstützen, aber ohne First-Class-Support im Kernel entstehen Performance-Kosten, und weil Nutzer gezielt danach suchen und es verwenden müssen, auch Kosten bei der Usability.
    Deshalb spielen Open-Source-Programme wie GAP, M2 und PARI/GP eine wichtige Rolle dabei, die Lücken der Wolfram Language zu füllen. In meinem Fall trage ich zu FOSS-Projekten genauso viel bei, wie ich für meine Mathematica-Lizenz ausgebe. Bei Projekten, bei denen finanzielle Beiträge nicht einfach sind, versuche ich, Zeit und technische Arbeit zu investieren, um sie zu verbessern.
    Ehrlich gesagt interessieren mich Projekte, die Mathematica-Funktionalität nachbauen wollen, nicht besonders. Natürlich werden auch solche Projekte weiterentwickelt und verbessert werden, und sie können Wolfram Research zumindest unter Druck setzen, die Grundfunktionen weiter zu verbessern. Aber vermutlich bräuchte ein solches Projekt 10 bis 20 Jahre, um zum heutigen Mathematica/WL aufzuschließen.
    [1]: https://www.wolfram.com/raspberry-pi/
    [2]: https://www.wolfram.com/mathematica/pricing/home-hobby/

    • Stephen Wolfram scheint auf HN ziemlich unbeliebt zu sein, aber für experimentelle Mathematik, das Lösen von Rätseln, schnelle Datenvisualisierung usw. ist Wolfram eine tiefgehende und schöne Sprache.
      Integrierte Notebooks, Dokumentation per Mouseover und – erstaunlicherweise – ein einziger riesiger Namespace mit Tausenden von Funktionen verbinden sich irgendwie zu einer einfachen und produktiven Erfahrung, die anders ist als alles, was ich bisher benutzt habe. Und das, obwohl ich normalerweise nicht einmal besonders auf „schwere“ IDEs stehe.

  • Einer der nervigen Punkte an Mathematica ist, dass alle Funktionen in denselben Namespace hineingestopft sind und es kein Overloading je nach unterschiedlichen Parametrisierungsoptionen gibt.

    • Ich weiß nicht, was mit Overloading gemeint ist. Funktionen können je nach Anzahl der Argumente problemlos unterschiedliches Verhalten haben. Zum Beispiel gibt es Fold mit 2 Argumenten und Fold mit 3 Argumenten, und Optionen können sie ebenfalls beliebig haben, wie Graphics, Graphics3D, Solve und Import/Export.
      Die einzige größere Duplizierung, die mir einfällt, sind die verschiedenen Plot-Funktionen.