Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Sortie de JuMP 0.19, la couche de modélisation mathématique pour Julia
Avec un code entièrement repensé pour la flexibilité

Le , par dourouc05

46PARTAGES

15  0 
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.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 27/08/2019 à 14:07
Sortie de JuMP 0.20,
la couche de modélisation mathématique pour Julia s'approche d'une implémentation générique des fonctions de rappe

Julia est un langage de programmation orienté performance et calcul scientifique, mais ce faisant il a créé un environnement très productif pour la création de langages spécifiques (DSL) : Julia s'est ainsi créé une niche en optimisation mathématique, JuMP étant une couche de modélisation intégrée au langage de programmation (comme Pyomo en Python), mais avec une performance digne des meilleurs outils (comme AMPL).

La version 0.20 de JuMP vient de sortir, avec une série d'améliorations mineures, comme des corrections de défauts (tous assez mineurs), une documentation améliorée et des messages d'erreur plus précis.

En sus, JuMP dispose de fonctions pour créer un rapport de sensibilité du programme linéaire résolu (en exploitant la solution duale) : lp_objective_perturbation_range permet de récupérer la plage de variation des coefficients de l'objectif telle que la base courante reste optimale, lp_rhs_perturbation_range fait de même pour les membres de droite des contraintes. Ces fonctions ont des limites théoriques : si la base est dégénérée (plusieurs bases pour représenter la même solution), les intervalles indiqués seront bien plus petits qu'attendus. Voir la documentation.

D'autres fonctions font leur apparition, d'utilité plus spécifique. dual_objective_value permet de récupérer la valeur duale de l'objectif (souvent égale à la valeur primale, mais pas toujours, notamment quand l'optimalité n'est pas atteinte). raw_status renvoie le code de retour du solveur directement, sans traduction de la part de JuMP. set_parameter permet de changer les paramètres du solveur. set_objective_coefficient autorise les changements de coefficients de variables dans l'objectif, lors de la résolution d'une séquence de problèmes, avec un impact sur la performance moindre qu'un changement complet de fonction objectif. set_normalized_rhs, normalized_rhs et add_to_function_constant s'occupent de la partie constante des contraintes.

JuMP 0.20 s'appuie également sur la couche d'abstraction des solveurs MathOptInterface 0.9, qui apporte son lot de nouveautés, certaines étant nécessaires aux apports de JuMP 0.20 (comme l'attribut DualObjectiveValue). Les plus anciennes versions de Julia ne sont plus gérées, MOI ne fonctionne qu'avec Julia 1.0 au minimum. La fonction submit a fait son apparition pour soumettre des attributs au solveur, comme des solutions heuristiques ou des contraintes retardées, des notions très utiles pour l'implémentation d'algorithmes d'optimisation avancés et très efficaces (mais pas encore entièrement disponibles dans MOI). La fonction dual_set renvoie l'ensemble dual associé à un domaine, ce qui sert à dualiser efficacement des problèmes d'optimisation (notamment avec Dualization). En outre, l'infrastructure de test a été enrichie pour les dernières nouveautés, elle comporte aussi un module de test de performance des solveurs.

Sources : notes de version de JuMP et MOI.
7  0