Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add bisector option in ibexopt #540

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

cyrilbouvier
Copy link
Contributor

Backported code from qibex branch of @bneveu 's repo: https://github.com/bneveu/ibex-lib/tree/qibex

This code add a bisector option in ibexopt.

Notes:

  • I was not able to check that it does not change the default bisector
  • once this PR is merged, ibexlib must do major revision (bumps its version to 3.0) as some attributes were added in classes, which is an incompatible API changes
  • maybe the case where a wrong bisector is given should be improved. Currently ibexopt --bisector idonotexist bchfile uses the default bisector and output
...
  bisector: idonotexist
...

@gchabert
Copy link
Contributor

Désolé, je ne suis pas favorable à l'ajout de cette nouvelle option.
ibexopt (contrairement à optimizer04 par exemple) est conçu pour être l'optimiseur par défaut utilisable par un non-expert en optimisation globale.
Toutes les options actuellement définies dans ibexopt sont des options qui sont compréhensibles par l'utilisateur et qui "concernent" l'utilisateur, c.a.d., des options qui sont relatives aux propriété des résultats qu'il attend (précision sur l'objectif, rigueur dans la satisfaction des égalités, etc.).
Là il s'agit d'une option relative au mécanisme de résolution, c'est très différent.

@bneveu
Copy link
Contributor

bneveu commented Mar 18, 2024

Je pense que c'est intéressant de pouvoir changer de bissecteur dans ibexopt , sans passer par l'optimiseur générique.
Le bissecteur par défaut est en effet le paramètre le moins robuste : par exemple, kall_congruentcircles_c71 n'est pas résolu avec le bissecteur par défaut lsmear en 7200s et est résolu avec smearsum en 78s.
C'est encore plus vrai pour les problèmes minlp.
Des optimiseurs comme SCIP ou gurobi sous AMPL donnent accès à de nombreux paramètres , dont certains sont algorithmiques, par exemple SCIP permet de paramétrer la bissection sur les variables binaires par le paramètre
branch:preferbinary (preferbinary)
0/1: whether branching on binary variables should be preferred

@gchabert
Copy link
Contributor

Oui, tu as raison; et on pourrait proposer dans l'aide une option --advanced qui indiquerait les paramètres algorithmiques, histoire de ne pas noyer l'utilisateur lambda.
Mais du coup, pourquoi ne pas avoir carrément un seul optimiseur?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants