Avec la sortie de Julia 1.0, c’est tout un écosystème qui doit se mettre à jour — notamment JuMP, un langage dédié (DSL) à l’optimisation mathématique totalement intégré à Julia. Il permet de transformer un modèle mathématique en un code extrêmement compact et proche des notations mathématiques (d’une manière similaire à AMPL, par exemple), tout en profitant de l’intégration à Julia et d’une excellente performance (contrairement à Pyomo, en Python).Le projet a débuté au MIT, tout comme le langage Julia, en tant que collaboration entre la Sloan School of Management et le Operations Research Center. Il n’était qu’une petite expérience pour voir les améliorations possibles dans le domaine des langages dédiés à l’optimisation mathématique, mais a fini par grandir au point de générer un écosystème à part entière (JuliaOpt), avec le développement d’autres paquets pour faciliter la modélisation, ainsi que de solveurs complets. Désormais, JuMP est utilisé de manière industrielle, par exemple pour organiser le ramassage scolaire à Boston (États-Unis), les horaires en entreprise ou encore les trains au Canada ; il a aussi gagné bon nombre de cours dans le domaine. Un signe de son utilité à la communauté, la fondation NumFOCUS (qui se concentre sur le calcul numérique au sens large) servira de sponsor fiscal à JuMP et à JuliaOpt : cette fondation (reconnue 501(c)3 aux États-Unis, c’est-à-dire sans but lucratif) gérera la réception des dons et l’émission des reçus, par exemple.
En peu de mots : la version 0.18 (l’actuelle) ne fonctionne qu’avec Julia 0.6, mais sera encore maintenue un certain temps ; la version 0.19 (la suivante) inclut des modifications très profondes dans la structure de JuMP et ne sera pas prête de suite. Cette dernière sera compatible tant avec Julia 0.6 que 0.7, afin de faciliter la migration du code. La version 0.18 devrait être rendue compatible avec Julia 0.7, mais les développeurs de JuMP n’estiment pas cet effort et n’envisagent pas d’y investir beaucoup de temps.
Les changements prévus consistent en un changement complet de la couche de communication avec les solveurs d’optimisation mathématique (comme CPLEX, Gurobi ou Mosek). Ainsi, MathProgBase (MPB) cédera la place à MathOptInterface (MOI). Les contraintes y sont spécifiées de manière beaucoup plus générique : la valeur d’une certaine fonction doit appartenir à un certain ensemble (quand MathProgBase utilisait des objets spécifiques pour chaque type de contrainte, sans réelle possibilité d’extensibilité : les contraintes linéaires, quadratiques, etc.). Le système de récupération du statut du solveur à la fin de son exécution a complètement changé, afin de représenter les possibilités aussi finement que possible (pour indiquer, par exemple, la raison pour laquelle le solveur s’est arrêté avant d’obtenir une solution optimale : a-t-il atteint la limite de temps ?). Tous les paramètres sont aussi passés sous la forme d’attributs, ce qui facilite l’ajout de nouveaux paramètres pour les solveurs sans toucher au code existant. Une fonctionnalité était attendue depuis longtemps : la modification de contraintes.
En pratique, cela veut dire que toutes les extensions de JuMP devront être complètement réécrites (et repensées). Pour l’utilisateur, cependant, les changements seront plus limités : la récupération du code de statut, l’accès aux valeurs duales, les fonctions de rappel (qui ne seront plus du tout implémentées par JuMP, de par la disparité entre les types de fonctions implémentées par chaque solveur — ce point sera le plus problématique). Cependant, les changements ne seront pas finis : les modèles purement non linéaires (c’est-à-dire sans structure supplémentaire, pour lesquels JuMP doit calculer par exemple des gradients à partir du code fourni par l’utilisateur) sont presque entièrement repris de MathProgBase.
Sources : JuMP and Julia 0.7/1.0, MathOptInterface and upcoming breaking changes in JuMP 0.19, Optimization modeling language JuMP joins NumFOCUS Sponsored Projects.