Open bneveu opened 3 years ago
C'est peut-être dû a l'heuristique lsmear. Je regarde.
Si c'est dû à lsmear, il faudrait qu'Ignacio prenne ça en charge
C'est peut-être dû au changement que j'ai fait dans lsmear. (passage de roundrobin à largestfirst quand lsmear ne s'applique pas) Je n'avais pas vérifié les problèmes sans contraintes. Je vais regarder.
Ce n'est pas dû a la bissection, mais a la recherche du loup. le uplo est optimal avant de bissecter. en 2.8.6, après une bissection, on trouve tout de suite le loup optimal. en 2.8.9, la première bissection est la même et il faut plusieurs bissections et la descente du loup est par paliers. Le problème vient-il de la linéarisation intérieure ? Y-a-t-il quelque chose de changé ?
Pas grand chose n'a changé je pense, à part l'interface du solveur linéaire (mais cela devrait être sans effet). Pour voir les différences, je te suggère de faire la commande suivante:
git diff ibex-2.8.6..ibex-2.8.9 numeric/ibex_LinearizerXTaylor.cpp
Tu verras apparaître directement ce qui a changé dans ce fichier entre les 2 versions. Il faudrait faire de même avec loup/ibex_LoupFinderXTaylor.cpp
pour comprendre ce qu'il se passe
Pour ackley5
Après la première bissection , la boîte est la même, after bisection 1([-32, 0] ; [-32, 32] ; [-32, 32] ; [-32, 32] ; [-32, 32] ; [-8.284590551355109e-07, 20.18381792462741]) les systèmes générés pour soplex sont différents : l'objectif est différent; (les bornes sont en contraintes et en partie en bornes en 2.8.9) les loups trouvés aussi sont différents
version 2.8.6 Minimize obj: -4.2762522877404074e-01 x0 - 1.7007721870033865e-16 x1 - 1.7007721870033865e-16 x2 - 1.7007721870033865e-16 x3 - 1.7007721870033865e-16 x4 Subject To C0_1 : 1.0000000000000000e+00 x0 >= -3.1999999998999999e+01 C0_2 : 1.0000000000000000e+00 x0 <= -1.0000000000000000e-09 C1_1 : 1.0000000000000000e+00 x1 >= -3.1999999998999999e+01 C1_2 : 1.0000000000000000e+00 x1 <= 3.1999999999000004e+01 C2_1 : 1.0000000000000000e+00 x2 >= -3.1999999998999999e+01 C2_2 : 1.0000000000000000e+00 x2 <= 3.1999999999000004e+01 C3_1 : 1.0000000000000000e+00 x3 >= -3.1999999998999999e+01 C3_2 : 1.0000000000000000e+00 x3 <= 3.1999999999000004e+01 C4_1 : 1.0000000000000000e+00 x4 >= -3.1999999998999999e+01 C4_2 : 1.0000000000000000e+00 x4 <= 3.1999999999000004e+01 Bounds x0 free x1 free x2 free x3 free x4 free
version 2.8.9 Minimize obj: -8.6601332126949870e-02 x0 + 8.6601332126938158e-02 x1 + 8.6601332126938158e-02 x2 - 1.7007721870033860e-16 x3 - 1.7007721870033860e-16 x4 Subject To C0_1 : 1.0000000000000000e+00 x0 >= -3.2000000000000000e+01 C0_2 : 1.0000000000000000e+00 x0 <= -0.0000000000000000e+00 C1_1 : 1.0000000000000000e+00 x1 >= 0.0000000000000000e+00 C1_2 : 1.0000000000000000e+00 x1 <= 3.2000000000000000e+01 C2_1 : 1.0000000000000000e+00 x2 >= 0.0000000000000000e+00 C2_2 : 1.0000000000000000e+00 x2 <= 3.2000000000000000e+01 C3_1 : 1.0000000000000000e+00 x3 >= -3.2000000000000000e+01 C3_2 : 1.0000000000000000e+00 x3 <= 3.2000000000000000e+01 C4_1 : 1.0000000000000000e+00 x4 >= -3.2000000000000000e+01 C4_2 : 1.0000000000000000e+00 x4 <= 3.2000000000000000e+01 Bounds -3.2000000000000000e+01 <= x0 <= -0.0000000000000000e+00 x1 <= 3.2000000000000000e+01 x2 <= 3.2000000000000000e+01 -3.2000000000000000e+01 <= x3 <= 3.2000000000000000e+01 -3.2000000000000000e+01 <= x4 <= 3.2000000000000000e+01 End
loup= 18.90911814411293
la perte de performance n'a pas lieu avec optimizer05 (qui utilise Optimizer04Config). ibexopt par défaut n'appelle plus les mêmes paramètres pour les problèmes sans contraintes ?
./optimizer05 ../benchs/optim/benchs-unconstrainedoptim/ackley50.bch acidhc4 xn lsmearmg bs 1 0 1.e-6 1000 1 optimization successful!
f* in [-2.57621162668,-2.57620905046] (best bound)
x* = (0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0 ; 0) (best feasible point)
relative precision on f: 9.99999999832e-07 [passed] absolute precision on f: 2.57621162625e-06 cpu time used: 0s number of cells: 0
../install/bin/ibexopt ../benchs/optim/benchs-unconstrainedoptim/ackley50.bch -a 1.e-6 -r 1.e-6 f* in [-2.57620905047,-2.57620905046] (best bound)
x* = (-0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0 ; -0) (best feasible point)
relative precision on f: 2.2064753965e-14 [passed] absolute precision on f: 5.68434188609e-14 [passed] cpu time used: 0.612000000001s number of cells: 100
Il y avait une erreur dans mon message précédent (ne pas en tenir compte). optimizer05 avec les paramètres par défaut fait bien les mêmes calculs que ibexopt pour ackley50. et on en est au même point qu'avant noel , à savoir les systèmes envoyés à soplex sont différents en 2.8.6 et 2.8.9
avec la version 2.8.6 (avant nouveau wrapper linéaire et avec soplex3)
ibexopt par défaut résolvait tous les benchs ackley en 2 noeuds, maintenant le nombre de noeuds augmente avec la taille du problème
par exemple ackley30 2.8.6 relative precision on f: 0.000881536794811 [passed] absolute precision on f: 7.30317140097e-10 [passed] cpu time used: 0.003283s number of cells: 2
2.8.9 relative precision on f: 3.00183763066e-08 [passed] absolute precision on f: 2.48689957517e-14 [passed] cpu time used: 0.504000000001s number of cells: 156
ackley 100 :
2.8.6 relative precision on f: 2.88826519215e-11 [passed] absolute precision on f: 7.31116500675e-10 [passed] cpu time used: 0.030932s number of cells: 2
2.8.9 relative precision on f: 3.2420720993e-14 [passed] absolute precision on f: 8.20676859803e-13 [passed] cpu time used: 27.6720000001s number of cells: 1010