L'objectif est de fabriquer des solveur de problèmes complexes (recherche d'ensemble solution avec fonction solution à beaucoup beaucoup de variable je suppose) à partir de la programmation par contrainte. Les langages à programmation par contraintes sont lents, c'est connu.
Juste un mot à ce propos. La programmation par contrainte, c'est une approche déclarative, en gros tu donnes des variables, exemple "entier a in [1..5], b in [10..12]]" et tu donnes des contraintes qui décrivent les solutions du problèmes (genre "a différent de b et a*a>2" ) dans un langage donné. Par exemple le sudoku peut se décrire par 81 variables dans [1..9] et quelques contraintes qui décrivent que les variables de la même ligne soient différentes, colonnes et les variables dans les carrés, soit un truc comme 27 contraintes du style "tous_différentes(A11,A12,...,A19) et ..."
Après le problème c'est pas tant que le langage soit lent qu'il soit plutôt générique et que tu peux décrire un paquet de problèmes différents, avec des caractéristiques différentes : beaucoup de solutions, pas de solutions, une seule solution, beaucoup ou peu variables par rapport aux contraintes, natures des contraintes, etc.
L'idée de la PPC c'est que tu décris ton problème et que tu laisse le solveur se débrouiller.
Malheureusement ça ne marche pas dans tous les cas et il faut parfois paramétrer le solveur dans le choix de ses algorithmes de résolution pour parvenir à une résolution efficace, ce qui nécessite un peu d'expertise dans le processus de résolution pour avoir une idée de ce qui peut marcher ou pas. Certain algo sont efficaces pour certaines forme de problème, dans d'autre cas ils sont trop couteux et ralentissent tout. Certaines heuristiques marchent uniquement dans certains cas, ...
L'idée ici c'est d'automatiser le tuning du solveur, le "adaptative" doit vouloir dire que ça doit se faire en cours de résolution. Genre le solveur teste un algo essaye de voir si ça a payé par rapport à autre chose, tente autre chose ... le tout idéalement sans faire intervenir l'utilisateur.
# Tuning automatique de paramètres
Posté par thoasm . En réponse au journal Le labo commun Inria-Microsoft. Évalué à 4.
L'objectif est de fabriquer des solveur de problèmes complexes (recherche d'ensemble solution avec fonction solution à beaucoup beaucoup de variable je suppose) à partir de la programmation par contrainte. Les langages à programmation par contraintes sont lents, c'est connu.
Juste un mot à ce propos. La programmation par contrainte, c'est une approche déclarative, en gros tu donnes des variables, exemple "entier a in [1..5], b in [10..12]]" et tu donnes des contraintes qui décrivent les solutions du problèmes (genre "a différent de b et a*a>2" ) dans un langage donné. Par exemple le sudoku peut se décrire par 81 variables dans [1..9] et quelques contraintes qui décrivent que les variables de la même ligne soient différentes, colonnes et les variables dans les carrés, soit un truc comme 27 contraintes du style "tous_différentes(A11,A12,...,A19) et ..."
Après le problème c'est pas tant que le langage soit lent qu'il soit plutôt générique et que tu peux décrire un paquet de problèmes différents, avec des caractéristiques différentes : beaucoup de solutions, pas de solutions, une seule solution, beaucoup ou peu variables par rapport aux contraintes, natures des contraintes, etc.
L'idée de la PPC c'est que tu décris ton problème et que tu laisse le solveur se débrouiller.
Malheureusement ça ne marche pas dans tous les cas et il faut parfois paramétrer le solveur dans le choix de ses algorithmes de résolution pour parvenir à une résolution efficace, ce qui nécessite un peu d'expertise dans le processus de résolution pour avoir une idée de ce qui peut marcher ou pas. Certain algo sont efficaces pour certaines forme de problème, dans d'autre cas ils sont trop couteux et ralentissent tout. Certaines heuristiques marchent uniquement dans certains cas, ...
L'idée ici c'est d'automatiser le tuning du solveur, le "adaptative" doit vouloir dire que ça doit se faire en cours de résolution. Genre le solveur teste un algo essaye de voir si ça a payé par rapport à autre chose, tente autre chose ... le tout idéalement sans faire intervenir l'utilisateur.