Julia a une longue histoire avec les applications scientifiques, y compris l’optimisation mathématique. En effet, une couche de modélisation existe depuis des années — JuMP (Julia Mathematical Optimisation). Ce projet est d’ailleurs l’un des plus utilisés dans l’écosystème Julia, JuMP étant actuellement le neuvième paquet ayant le plus d’étoiles sur GitHub. La version 0.19 de JuMP vient de sortir. Elle marque un nouveau tournant dans l’histoire du projet, puisque presque tout le code a été réécrit — même si peu de choses sont visibles du côté utilisateur. Cette version est en cours de développement depuis plus d’un an. Le principal changement concerne la couche de communication entre JuMP et les solveurs d’optimisation : MathProgBase est remplacé par MathOptInterface. Cette nouvelle interface corrige bon nombre de défauts de conception mis au jour au fil du temps et permet, notamment, de supprimer des variables et des contraintes (chose impossible avec MathProgBase), entre autres. Cela signifie que le lien avec les solveurs doit être réécrit, ce qui n’a pas encore été fait pour tous les solveurs.
Le principal changement de syntaxe par rapport aux versions précédentes se montre ici : au lieu de créer un modèle d’optimisation avec Gurobi (par exemple) comme solveur, avec une ligne comme Model(solver=GurobiSolver()), il faudra préférer Model(with_optimizer(Gurobi.Optimizer)). Les codes de retour des solveurs ont aussi changé, pour mieux rendre compte de la diversité des informations disponibles.
Ce changement d’interface sert notamment à mieux gérer différents types de contraintes, coniques notamment. JuMP peut maintenant gérer n’importe quel type de contrainte sans besoin d’une syntaxe spécifique : de manière générale, une contrainte indique qu’une certaine expression doit prendre une valeur dans un certain ensemble. Cela signifie notamment la fin de certains raccourcis dans l’écriture : norm() n’est plus disponible, il faudra maintenant utiliser directement un cône de Lorentz avec SecondOrderCone. De manière générale, JuMP effectue aussi peu de conversions que possible, de telle sorte que le modèle entré par l’utilisateur soit exposé assez directement au solveur.
Bon nombre de nouvelles fonctionnalités font aussi leur apparition, principalement grâce à cette nouvelle interface : la suppression de contraintes et de variables, les modèles coniques mélangeant différents types de cônes (y compris puissance et exponentielle), la possibilité de donner des valeurs duales initiales, l’accès grandement étendu aux attributs offerts par le solveur (sans devoir utiliser l’API de bas niveau).
Les types des conteneurs ont été entièrement repensés, en favorisant la performance ou la possibilité de l’améliorer dans les versions à venir. La source principale d’inspiration a été AxisArrays. JuMP définit maintenant les types SparseAxisArray et DenseAxisArray, selon le type d’indexation possible (ces types correspondent respectivement à JuMPDict et à JuMPArray).
Cette version 0.19 n’est certes pas loin d’une première version finale pour JuMP, mais n’est pas non plus finie. Il manque une série de fonctionnalités, plus ou moins importantes selon les utilisateurs (et qui étaient disponibles auparavant), comme la génération de colonnes, l’accès direct au relâchement continu ou aux fonctions de rappel des solveurs (un mécanisme qui n’est plus générique, mais bien spécifique à chaque solveur) ou encore la réoptimisation rapide de programmes non linéaires. La performance lors de la génération des modèles peut être en deçà des possibilités des versions précédentes de JuMP, mais les développeurs sont au courant.
Source : les notes de version.