optimizer ends just before the precision

[bneveu]

pour les problèmes avgasa.nl et avgasb.nl (coconut2)
l'optimiseur s'arrête juste avant d'atteindre la précision, alors qu'il l'atteignait sans problème
dans la version précédente (avant la 2.8.3)

./optimizer04 ../benchs/coconutbenchmark-library2/avgasa.nl acidhc4 compo lsmearmg bs 1 1.e-7 1.e-6 1000 1

avant
f* in [-4.41217,-4.41216]
(best bound)

x* = (0.11705 ; 0.882951 ; 0.468337 ; 0.531664 ; 0.458245 ; 0.0291156 ; 0.615523 ; 0.0527881)
(best feasible point)

relative precision on f*: 1e-06 [passed]
absolute precision on f*: 4.41217e-06
cpu time used: 2.12885s
number of cells: 1116

version courante

unreached precision

f* in [-4.41217,-4.41217]
(best bound)

x* = (0.116764 ; 0.883237 ; 0.468386 ; 0.531615 ; 0.458045 ; 0.0292834 ; 0.614841 ; 0.0527545)
(best feasible point)

relative precision on f*: 1.00001e-06
absolute precision on f*: 4.41218e-06
cpu time used: 1.86912s
number of cells: 994

[bneveu]

visiblement, c'est dû à la derniere modif dans l'optimiseur sur compute_ymax, qui ne doit pas être correcte.

Pourquoi l'ancien code était incorrect ?

[gchabert]

Bon, j'ai peut-être été un peu trop vite ... mais voilà pourquoi j'ai modifié la formule du y_max.

Je me suis dit que l'erreur relative devait s'appliquer en sortie sur le uplo et non le loup.
Prenons un exemple. Supposons qu'on fixe rel_eps_f=50% et que l'optimiseur retourne uplo=0.5 et loup=1. On a bien une erreur relative de 50% pour le loup mais pour le uplo, c'est 100%.
Or, dans le pire des cas le vrai minimum peut valoir uplo donc la seule garantie que l'on a sur l'erreur relative en sortie, c'est 100%.

L'autre point de vue (l'ancien) est de dire qu'on détient au moins un point admissible pour lequel le vrai minimum n'est pas à plus de 50% de la valeur du critère en ce point (c.a.d le loup).
Maintenant que j'y repense, ça se tient aussi, sauf dans le cas extrême rel_eps_f=100%, mais c'est un détail j'imagine.

Comment vois-tu les choses?

[bneveu]

Je pense que les deux points de vue se tiennent.
Je ne sais pas si c'est précisé dans les autres logiciels, qui ont tous une précision relative
pour le critère d'arrêt (en pratique, quand elle est à 1.e-6, on s'en fiche).
Il faut juste être cohérent et si on change le calcul du y_max, il faut aussi changer
la fonction get_obj_rel_prec()

[bneveu]

Dans l'article JOGO de comparaison des logiciels, c'est loup-uplo/ |uplo |, ce qui te donnerait raison.
Je ne me souviens plus pourquoi j'avais choisi l'autre définition de l'erreur relative.

[bneveu]

Avec la nouvelle définition de l'erreur relative, la fonction compute_ymax peut descendre un peu trop
(un flottant ?) ymax et empêcher de trouver la solution optimale.
En remplaçant le return ymax par return (next_float(ymax)), il n'y a plus de problème.

[gchabert]

Mais la nouvelle définition de ymax est justement censée retourner une valeur + haute que l'ancienne, du coup, je ne comprends pas bien ce qui se passe.

[bneveu]

Non, dans le cas uplo et loup négatifs, on descend plus bas qu'avec l'ancienne formule.
Mais le test d'arrêt était différent, et ce n'est peut-être que par chance que le problème n'était pas apparu.
Le bug actuel est rare , il n'apparaît pour process.bch sur 100 essais optimizer04 et compo, en changeant la graine , qu'avec la graine aléatoire à 1.
Il est résolu avec la modif next_float , mais ce n'est peut-être aussi que par chance : en tous cas,
ce n'est pas grave d'un peu moins baisser le ymax , cette baisse n'étant qu'une optimisation.

/optimizer04 ../benchs/coconutbenchmark-library1/process.bch acidhc4 compo lsmearmg bs 1 0 1.e-6 1000 1
sans la modif du next_float
unreached precision

f* in [-1161.337673692271,-1161.336512354598]
(best bound)

x* = (1728.920765114857 ; 16000 ; 98.17682270878209 ; 3056.49229883983 ; 1999.999839460737 ; 90.61867323666336 ; 94.18860432222586 ; 10.41111901609738 ; 2.61638951039961 ; 149.5658129756776)
(best feasible point)

relative precision on f*: 1.000000000000797e-06
absolute precision on f*: 0.001161337673693197
cpu time used: 0.3376230000000002s
number of cells: 124
avec la modif du next_float

optimization successful!
f* in [-1161.337656553375,-1161.336495215718]
(best bound)

x* = (1728.920894839244 ; 16000 ; 98.13613651651634 ; 3056.492536760855 ; 2000 ; 90.61216882600508 ; 94.18649017762097 ; 10.41111832778659 ; 2.617797530706462 ; 149.5594705418629)
(best feasible point)

relative precision on f*: 9.999999996831661e-07 [passed]
absolute precision on f*: 0.001161337656185424
cpu time used: 0.3613270000000002s
number of cells: 132