Mathics 7.0 – une alternative open source à Mathematica

 (github.com/Mathics3)
4 points par GN⁺ 2024-12-09 | 1 commentaires | Partager sur WhatsApp
  • Mathics Core 7.0.0 réorganise le moteur central de ce système de calcul open source compatible avec Mathematica et prépare le terrain pour un futur chargement différé des fonctions intégrées
  • De nouvelles fonctions intégrées comme ComplexExpand, ConjugateTranspose et LeviCivitaTensor ajoutent des capacités liées aux expressions, à l’algèbre linéaire et à l’identification des nombres réels
  • Des lacunes de compatibilité existantes sont comblées, notamment pour Range[], DirectedInfinity, Indeterminate, l’affichage des erreurs dans Graphics et la modification de $CharacterEncoding
  • Le chargement des fonctions intégrées abandonne les dépendances d’import implicites au profit d’un appel explicite à import_and_load_builtins()
  • La version inclut la prise en charge de Python 3.11 et SymPy 1.12, ainsi que des correctifs liés à Quantity, SparseArray, Derivative, Exit[] et BaseForm

Orientation de la version et réorganisation interne

  • Mathics Core 7.0.0 inclut une réorganisation interne destinée à prendre en charge à l’avenir le chargement différé des fonctions intégrées
  • Le code Python et le style ont été modernisés, les annotations de types ont été renforcées, et plusieurs fautes d’orthographe ont été corrigées
  • Les dépendances SymPy et Python ont été mises à jour vers des versions plus récentes
  • Des travaux ont aussi été menés pour accélérer le chargement initial et réduire l’utilisation mémoire au démarrage

Nouvelles fonctions intégrées

  • Les fonctions intégrées ajoutées dans cette version sont les suivantes
    • $MaxLengthIntStringConversion
    • Elements
    • ComplexExpand
    • ConjugateTranspose
    • LeviCivitaTensor
    • RealAbs, RealSign
    • RealValuedNumberQ

Améliorations de la documentation et de la génération des tests

  • Plusieurs problèmes de mise en forme ont été corrigés dans la documentation PDF
    • L’espacement des numéros de section a été augmenté dans les tables des matières des chapitres et sections
    • Les marges autour des définitions de fonctions intégrées ont été augmentées
    • Les fautes d’orthographe ont été corrigées dans l’ensemble de la documentation
  • Le code d’exécution des doctests et de génération de la documentation LaTeX a été revu et refactorisé
    • Il permet les mises à jour incrémentales des fonctions intégrées
    • Il a été réorganisé afin de réduire le code dupliqué
  • Une section Section Head-Related Operations a été ajoutée à « Expression Structure »
  • Le titre du PDF est passé de Mathics à Mathics3, et le texte d’introduction a aussi été mis à jour
  • Les anciens doctests non affichés et non pédagogiques ont été convertis vers pytest

Compatibilité et changements de comportement visibles par l’utilisateur

  • *Plot n’affiche pas de message pendant l’évaluation
  • Range[] gère les valeurs négatives de di
  • La prise en charge de DirectedInfinity et Indeterminate a été améliorée
  • Graphics et Graphics3D s’affichent avec un fond rose lorsqu’ils contiennent une primitive ou une directive invalide
    • Dans l’interface Mathics-Django, un message d’erreur en info-bulle est également affiché
  • $CharacterEncoding peut être modifié au sein d’une session

Implémentation interne et changements d’API

  • eval_abs et eval_sign ont été séparés de Abs et Sign, puis ajoutés à mathics.eval.arithmetic
  • Le nombre maximal de chiffres autorisé dans une chaîne est fixé à 7000
    • Dans les environnements comme pyston où Python ne l’ajuste pas automatiquement, il peut être configuré avec la variable d’environnement MATHICS_MAX_STR_DIGITS
  • L’implémentation de la comparaison de réels s’appuie désormais en interne sur l’implémentation de RealSign
  • Dans Python 3.11, $MaxLengthIntStringConversion contrôle la taille maximale des conversions littérales entre grands entiers et chaînes
  • Le chargement du code intégré passe d’un mécanisme implicite à un mécanisme à directive explicite
    • Ce changement vise à rendre possible à l’avenir le chargement différé des fonctions intégrées, ou un mécanisme « autoload » similaire à celui de GNU Emacs
  • La nouvelle API nécessite d’appeler explicitement import_and_load_builtins()
    • Auparavant, le moment du chargement des fonctions intégrées dépendait implicitement de l’ordre des imports et restait indéterminé
  • Un cache LRU a été ajouté à mpmath

Corrections de bugs pour Quantity, SparseArray, etc.

  • Definitions est compatible avec pickle
  • La prise en charge des expressions Quantity a été améliorée
    • Cela inclut les conversions, la mise en forme et les opérations arithmétiques
  • L’option Background de Graphics et Graphics3D fonctionne à nouveau
  • Un problème de comparaison numérique sur les expressions contenant String a été corrigé
    • Issue liée : #797
  • Un problème avec Switch[] contenant Infinity a été corrigé
    • Issue liée : #956
  • Un problème avec Outer[] sur SparseArray a été corrigé
    • Issue liée : #939
  • ArrayQ[] détecte désormais SparseArray
  • L’exception BoxExpressionError est gérée
  • Le comportement de Derivative lors de l’évaluation de True, False et List[] a été corrigé
  • Des correctifs pour le package Combinatorica sont inclus
  • Exit[], qui ne fonctionnait pas, a été corrigé
  • BaseForm est inclus dans $OutputForms

Versions de packages prises en charge

  • Python 3.11 est pris en charge
  • SymPy 1.12 est pris en charge

À lire aussi

1 commentaires

 
GN⁺ 2024-12-09
Avis de Hacker News

  • Je suis ce projet depuis quelques années, et il progresse régulièrement dans la bonne direction. Si vous vous intéressez aux systèmes de calcul formel open source, il existe beaucoup de solutions plus mûres, depuis les choix classiques comme GNU Octave ou Maxima jusqu’aux options plus modernes comme SAGEmath, Symbolics.jl ou sympy.
    Le spectre va des bibliothèques de calcul symbolique comme GiNaC jusqu’aux IDE « batteries incluses » comme SAGEmath, avec des communautés actives. Par exemple, on peut considérer que SAGEmath a pratiquement ouvert la voie aux interfaces de notebooks web, qui ont mené aujourd’hui aux nombreuses formes de Jupyter.
    Personnellement, j’aime le style assez Lisp de Mathematica (MMA), mais ce qui rend MMA puissant, ce n’est pas seulement son cœur, c’est aussi son immense bibliothèque. Sur des sujets de base comme l’intégration symbolique, les graphiques 2D/3D ou la méthode des éléments finis, il propose des solutions parmi les meilleures du secteur, et il couvre aussi beaucoup de domaines spécialisés comme la bio-informatique.
    Mathics semble avoir bien reproduit le cœur, mais il lui manque évidemment toutes ces bibliothèques. C’est le même raisonnement quand on compare Matlab et ses nombreux « toolkits » à un clone de numpy ; cela dit, l’écosystème Python a désormais amené dans le monde numpy beaucoup de nouveau code qui ne fonctionne pas sous Matlab.

    • Je suis d’accord sur les progrès réalisés. Ce projet me semble être un excellent exemple de personnes qui creusent discrètement et avec constance un sujet qui les passionne.
      Quand il est apparu il y a environ 5 ans, je m’étais dit : « le moteur d’évaluation symbolique est vraiment bien fait, voyons ce que ça donnera ». Chaque fois que j’aurai envie de lancer un nouveau projet, je devrais repenser à cet exemple de projet ancien qu’on continue à polir.
    • Côté Lisp, on peut passer facilement à Common Lisp depuis Maxima. Pour les performances, mieux vaut utiliser SBCL.
    • Je me trompe peut-être, mais je ne vois pas Octave, Matlab et numpy comme relevant du même domaine que les systèmes de calcul formel. Ce sont tous des langages ou bibliothèques centrés sur le calcul numérique, utilisés pour trouver des solutions numériques à des problèmes plutôt que des expressions symboliques exactes.
      Ils sont complémentaires et souvent utilisés ensemble. Mathematica et Mathics semblent prendre en charge les deux paradigmes, mais ce n’est pas la même chose.

  • Ça a l’air basé sur sympy : https://www.sympy.org/en/index.html

  • Si c’est seulement pour un usage personnel, Wolfram Cloud est utilisable gratuitement. Les fichiers semblent être supprimés au bout d’une trentaine de jours. Wolfram Engine est aussi un moyen d’utiliser Mathematica gratuitement en ligne de commande. Enfin, c’est mieux que rien.

    • On peut aussi acheter un Raspberry Pi avec une licence Mathematica incluse.
    • Avec WLJS par-dessus Wolfram Engine, ça devient assez agréable à utiliser.

  • Une introduction plus simple à Mathics se trouve ici :
    https://mathics.org/

  • Je ne sais pas pourquoi, mais j’ai l’impression que ça finira par être intégré à SageMath :D

    • Je ne suis pas au courant d’un vrai mouvement visant à intégrer Mathics dans SageMath. À vue de nez, c’est peut-être parce que SageMath est surtout développé par des mathématiciens chercheurs et des cryptographes, et que la performance est souvent une préoccupation centrale lorsqu’ils incluent des composants.
      L’une des raisons pour lesquelles SageMath est le plus gros projet Cython est justement que Cython permet à Sage d’exploiter des bibliothèques C/C++ rapides.
      Mathics ne semble pas, pour l’instant, se préoccuper sérieusement des performances. Il suffit par exemple de lancer dans Mathics un petit microbenchmark comme "AbsoluteTiming[Sum[i, {i, 1, 100000}]]", ou de lire sa feuille de route.
      Bien sûr, ce n’est pas un problème. Le langage de programmation de Mathematica a beaucoup d’applications intéressantes où la performance n’est pas essentielle, par exemple suivre soigneusement, étape par étape, certaines opérations symboliques avec leurs expressions.
      Mais la motivation principale des développeurs de Sage est la recherche mathématique de pointe, où les performances sont presque toujours très importantes. C’est aussi pour cette raison que Sage n’utilise pas simplement sympy et réimplémente directement beaucoup de fonctionnalités similaires. sympy privilégie la facilité d’installation, ce qui peut le rendre relativement lent ; dans SageMath, la facilité d’installation n’est absolument pas une priorité.
      La mission de SageMath est d’être une alternative viable à Mathematica, Matlab, Magma et Maple, mais cela n’a jamais voulu dire devenir un clone. Par exemple, il ne s’agit pas d’exécuter directement du code Mathematica, mais de proposer une alternative permettant de mener, sur des logiciels mathématiques open source, des recherches qui auraient autrement été faites avec ces programmes propriétaires.

  • Les ingénieurs logiciels feront n’importe quoi pour ne pas payer le coût du logiciel.

    • J’ai une licence Mathematica, mais je trouve aussi ce projet plutôt chouette. Je suis moi-même ingénieur logiciel. Je serais même surpris que les développeurs de Mathics ne soient pas des utilisateurs de Mathematica.
    • Ce n’est pas une question de prix, mais de liberté.
    • Certaines personnes créent des logiciels pour elles-mêmes, et vont même jusqu’à les publier en open source.
    • À l’époque, j’avais payé 20 dollars pour un boîtier de 3 DVD Debian Sarge et un manuel au format magazine.

  • Mathematica est fourni gratuitement sur Raspberry Pi[1], et la plupart des universités disposent d’une licence couvrant tout le site. La licence « Home & Hobby » n’est pas si chère non plus : l’abonnement coûte 195 dollars par an, la licence perpétuelle 390 dollars, et le renouvellement seulement 175 dollars[2]
    Honnêtement, pour quelqu’un qui s’intéresse au tinkering mais n’a pas les moyens de payer ce prix, une version crackée n’est ni difficile à trouver ni difficile à installer
    Personnellement, j’aime beaucoup Mathematica, ou plus exactement le « Wolfram Language », et je suis content de payer une licence pour un usage hobby. Non seulement je pense que ça vaut son prix, mais je considère aussi que soutenir les logiciels mathématiques est une « bonne cause » qui mérite qu’on y consacre de l’argent
    En plus, il est courant que des photographes amateurs dépensent pour des outils comme Adobe CC plus que ce que beaucoup de programmeurs dépensent pour l’ensemble de leurs outils, et je ne comprends pas pourquoi. C’est pareil quand on dépense 20 à 40 dollars par mois, voire plus, dans divers services par abonnement, mais qu’on hésite devant une licence à 200–400 dollars
    Cela dit, dans mon cas, je passe plus de temps dans Mathematica que dans presque n’importe quel autre programme installé sur mon ordinateur
    Malgré tout, les logiciels mathématiques open source ont toujours une place importante. Mathematica est globalement très complet, mais il présente encore de grosses lacunes en mathématiques avancées
    Il y a notamment deux raisons pour lesquelles il est difficile de croire qu’il pourra couvrir des domaines mathématiques plus « de niche ». Premièrement, plus on va vers des domaines avancés ou ésotériques, plus le retour sur investissement chute fortement. Deuxièmement, le Wolfram Language compte déjà plus de 6 000 fonctions intégrées ; ajouter encore des centaines de fonctions pour prendre en charge de manière exhaustive un domaine comme la théorie des groupes n’a pas vraiment de sens
    Cela pourrait être pris en charge sous forme de packages, mais sans support de première classe dans le noyau, il y a un coût en performances, et aussi un coût d’utilisabilité puisque l’utilisateur doit aller les chercher et les utiliser volontairement
    C’est pourquoi des logiciels open source comme GAP, M2 ou PARI/GP jouent un rôle important pour combler les lacunes du Wolfram Language. De mon côté, je contribue aussi à des projets FOSS à hauteur de ce que je dépense pour ma licence Mathematica. Pour les projets auxquels il n’est pas simple de contribuer financièrement, j’essaie de les améliorer en y consacrant du temps et des compétences techniques
    Honnêtement, les projets qui cherchent à répliquer les fonctionnalités de Mathematica ne m’intéressent pas beaucoup. Bien sûr, ces projets continueront à être développés et améliorés, et ils peuvent au moins mettre la pression sur Wolfram Research pour qu’il continue à améliorer les fonctionnalités de base. Mais pour qu’un tel projet rattrape le Mathematica/WL d’aujourd’hui, il faudra probablement 10 à 20 ans
    [1]: https://www.wolfram.com/raspberry-pi/
    [2]: https://www.wolfram.com/mathematica/pricing/home-hobby/

    • Stephen Wolfram semble assez détesté sur HN, mais pour les mathématiques expérimentales, la résolution d’énigmes, la visualisation rapide de données, etc., Wolfram est un langage profond et élégant
      Les notebooks intégrés, la documentation au survol de la souris et, étonnamment, un unique et gigantesque espace de noms contenant des milliers de fonctions se combinent somehow pour offrir une expérience simple et productive, différente de tout ce que j’ai pu utiliser. Et pourtant, je ne suis généralement pas fan des IDE « lourds »

  • L’un des aspects agaçants de Mathematica, c’est que toutes les fonctions sont entassées dans le même espace de noms, et qu’il n’y a pas de surcharge selon les différentes options de paramétrage

    • Je ne vois pas bien ce que vous entendez par surcharge. Les fonctions peuvent facilement adopter des comportements différents selon le nombre d’arguments. Par exemple Fold à 2 arguments et Fold à 3 arguments, et elles peuvent aussi accepter toutes sortes d’options, comme Graphics, Graphics3D, Solve ou Import/Export
      Les gros doublons qui me viennent à l’esprit se limitent à peu près aux différentes fonctions Plot