Giter Site home page Giter Site logo

chocoteam / choco-solver Goto Github PK

View Code? Open in Web Editor NEW
673.0 49.0 135.0 84.02 MB

An open-source Java library for Constraint Programming

Home Page: http://choco-solver.org/

License: BSD 4-Clause "Original" or "Old" License

Java 98.38% Shell 0.35% Python 0.52% HTML 0.02% TeX 0.55% ANTLR 0.12% Makefile 0.04% R 0.02% JetBrains MPS 0.01%
constraint-programming solver constraints csp copr constraint-satisfaction-problem java constraint-solver constraint-optimisation-problem

choco-solver's Introduction

logo

DOI

Discord Maven Central javadoc.io

Build codecov.io Total alerts Codacy Badge

Choco-solver is an open-source Java library for Constraint Programming.

Current stable version is 4.10.14 (02 Nov 2023).

Choco-solver comes with:

  • various type of variables (integer, boolean, set, graph and real),
  • various state-of-the-art constraints (alldifferent, count, nvalues, etc.),
  • various search strategies, from basic ones (first_fail, smallest, etc.) to most complex (impact-based and activity-based search),
  • explanation-based engine, that enables conflict-based back jumping, dynamic backtracking and path repair,

But also, facilities to interact with the search loop, factories to help modelling, many samples, etc.

Choco-solver is distributed under BSD 4-Clause License (Copyright (c) 1999-2023, IMT Atlantique).

Contact:

Overview

// 1. Create a Model
Model model = new Model("my first problem");
// 2. Create variables
IntVar x = model.intVar("X", 0, 5);
IntVar y = model.intVar("Y", 0, 5);
// 3. Create and post constraints thanks to the model
model.element(x, new int[]{5,0,4,1,3,2}, y).post();
// 3b. Or directly through variables
x.add(y).lt(5).post();
// 4. Get the solver
Solver solver = model.getSolver();
// 5. Define the search strategy
solver.setSearch(Search.inputOrderLBSearch(x, y));
// 6. Launch the resolution process
solver.solve();
// 7. Print search statistics
solver.printStatistics();

Documentation, Support and Issues

The latest release points to binaries and source code.

You can get help on our google group. Most support requests are answered very fast.

Use the issue tracker here on GitHub to report issues. As far as possible, provide a Minimal Working Example.

Contributing

Anyone can contribute to the project, from the source code to the documentation. In order to ease the process, we established a contribution guide that should be reviewed before starting any contribution as it lists the requirements and good practices to ease the contribution process.

And thank you for giving back to choco-solver. Please meet our team of cho-coders :

Supporting Choco with financial aid favors long-term support and development. Our expenses are varied: fees (GitHub organization, Domain name, etc), funding PhD students or internships, conferences, hardware renewal, ...

Donate

Download and installation

Requirements:

  • JDK 8+
  • maven 3+

Choco-solver is available on Maven Central Repository, or directly from the latest release.

Snapshot releases are also available for curious.

In the following, we distinguish two usages of Choco:

  • as a standalone library: the jar file includes all required dependencies,
  • as a library: the jar file excludes all dependencies.

The name of the jar file terms the packaging:

  • choco-solver-4.XX.Y-jar-with-dependencies.jar or
  • choco-solver-4.XX.Y.jar.
  • choco-parsers-4.XX.Y-jar-with-dependencies.jar or
  • choco-parsers-4.XX.Y-light.jar or
  • choco-parsers-4.XX.Y.jar.

The light tagged jar file is a version of the jar-with-dependencies one with dependencies from this archive.

A Changelog file is maintained for each release.

Inside a maven project

Choco is available on Maven Central Repository. So you only have to edit your pom.xml to declare the following library dependency:

<dependency>
   <groupId>org.choco-solver</groupId>
   <artifactId>choco-solver</artifactId>
   <version>4.10.14</version>
</dependency>

Note that if you want to test snapshot release, you should update your pom.xml with :

<repository>
    <id>sonatype</id>
    <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
    <snapshots>
        <enabled>true</enabled>
    </snapshots>
</repository>

As a stand-alone library

The jar file contains all required dependencies. The next step is simply to add the jar file to your classpath of your application. Note that if your program depends on dependencies declared in the jar file, you should consider using choco as a library.

As a library

The jar file does not contains any dependencies, as of being used as a dependency of another application. The next step is to add the jar file to your classpath of your application and also add the required dependencies.

Dependencies

To declare continuous constraints, Ibex-2.8.7 needs to be installed (instructions are given on Ibex website).

Building from sources

The source of the released versions are directly available in the Tag section. You can also download them using github features. Once downloaded, move to the source directory then execute the following command to make the jar:

$ mvn clean package -DskipTests

If the build succeeded, the resulting jar will be automatically installed in your local maven repository and available in the target sub-folders.

Choco-solver dev team

choco-solver's People

Contributors

alberthendriks avatar arnaud-m avatar arthurgodet avatar bernwaldl avatar chocotrust avatar cprudhom avatar dependabot-preview[bot] avatar dependabot[bot] avatar dimitri-justeau avatar eriknstevenson avatar fhermeni avatar gabrielhomsi avatar glelouet avatar helges avatar jbytecode avatar jgfages avatar jliangwaterloo avatar jlleitschuh avatar jsimomaa avatar mergify[bot] avatar mr-tl avatar mrtimoptim avatar mwahbi avatar njussien avatar paulk-asert avatar roberthilbrich avatar rojods avatar schmittjoaopedro avatar xela85 avatar xlorca avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

choco-solver's Issues

Associer les variables (et les vues) au Solveur

Pour éviter tout oubli, et parce que ca me semble nécessaire de l'imposer, toute variable créée doit être associée au solveur dès sa création. Il en va de même pour les vues.
Ainsi, en appelant solver.getVars(), on récupère l'ensemble des variables (ou assimilé) du solveur.

Se pose la question alors des variables créées mais non impliquées dans des contraintes. A vrai dire, je pense que c'est un faux problème, puisque ca ressemble plus à un problème de modélisation (et cela devra être capté par le modeleur, lorsqu'il sera présent), mais je soulève le point.

generic directories

En voyant la pull request de Cpru:

String outDir = "/Users/cprudhom/Downloads/OneAllDiff.csv";
String outDir = "/Users/chameau/Travail/2011-2012/Th�se JDB-2/tests/OneAllDiff.csv";

Je me suis demandé si on ne pouvais pas avoir un fichier qui contiennent les répertoires des contributeurs
donnant ainsi:
String outDir = getOutDir()+"/tests/OneAllDiff.csv";
getOutDir() étant un gros switch qui reconnait l'utilisateur et retourne le bon chemin...
C'est peut-être débile, mais si ça ne l'est pas, ça serait plus propre, non?

Aussi, je suis pour mettre les fichiers d'instances (lorsqu'il y en a) de benchs sur le serveur.
A un endroit tel qu'on puisse les mettre de côté lorsque l'on créera un .jar (pour ne pas l'alourdir).
Ca facilite le boulot lorsqu'on est plusieurs sur le même problème, et ça permet de lancer des tests (sur le serveur) sur
des instances de la littérature (vérifier qu'on trouve bien les optimum par exemple) qui sont trop grande pour les coder en dure.

Vos avis?

erreur Deltamonitor

Bonjour et bonne année,

Après 8h de tripatouillage de code et quelques surchauffes cérébrales j'ai fini par trouver un petit bug bien embêtant.
Il faut absolument implémenter la méthode unfreeze (le code avait été commenté pour le intdeltamonitor)
Donc unfreeze(){
first = last = delta.size();
}
Sinon on perd l'idempotence et c'est mal. J'ignore pourquoi ça avait été commenté, peut-être une étourderie mais en tout cas ça ne fonctionne pas sans.

a+

PS: on verra ça au retour de charles mais du coup la méthode unfreeze convient parfaitement pour le problème de la propagé initiale que j'ai signalé avant les vacances (il faut appeler l'unfreeze des FineEventRecorders après chaque propagation lourde => donc à la fin du exécute() des CoarseEventRecorders par exemple).

Quantic bug in AllDiff_AC

Il semblerait qu'il y ait un bug dans AllDiff_AC:

java.lang.IndexOutOfBoundsException: bitIndex < 0: -1
at choco.kernel.memory.structure.OneWordS32BitSet.clear(OneWordS32BitSet.java:251)
at choco.kernel.memory.structure.OneWordS32BitSet.set(OneWordS32BitSet.java:197)
at solver.constraints.propagators.nary.matching.Node.removeEdge(Node.java:96)
at solver.constraints.propagators.nary.PropAllDiffAC$RemProc.execute(PropAllDiffAC.java:168)
at solver.variables.delta.monitor.IntDeltaMonitor.forEach(IntDeltaMonitor.java:81)
at solver.constraints.propagators.nary.PropAllDiffAC.propagate(PropAllDiffAC.java:117)
at solver.recorders.fine.ArcEventRecorder.execute(ArcEventRecorder.java:106)

Je ne connais pas trop ce code mais en gros je crois qu'on supprime un arc de la "matchingstructure", qui n'existe pas
Si vous voulez je pourrais bientôt faire une petite pull request contenant entre autre le Test qui génère cette erreur...
J'essaie de la faire pour demain
a+

Simplifier les propagateurs binaires

Certains propagateurs binaires peuvent être supprimés puisque les vues permettent de les représenter plus simplement.
Cela permet d'avoir moins de code à maintenir.
Dans le viseur:

  • PropEqualXC, PropEqualXY_C et PropEqualX_YC => PropEqualXY
  • PropNotEqualXC, PropNotEqualXY_C et PropNotEqualX_YC = PropNotEqualXY
  • PropGreaterOrEqualXC, PropLessOrEqualXC et PropGreaterOrEqualX_YC => PropGreaterOrEqualXY

Si vous en voyez d'autre.
Du coup, cela aura un impact sur les contraintes (pris en charge dans le patch).

Cache de variables et consistence des noms

Salut

Cette semaine sur Choco, j'ai perdu une bonne heure à debugger un CSP. Le log de choco me remontait la violation d'une contrainte durant un awake et la violation me semblait incohérente avec mon code: d'après le nom des variables qui apparaissaient dans le message d'erreur, je n'avais jamais écrit une telle contrainte.

En fait le problème vient du cache qui est fait pour les variables constantes. Ce cache ne garantit la conservation du nom des variables:

IntDomainVar x = solver.makeConstantIntVar("x", 0);
IntDomainVar y = solver.makeConstantIntVar("y", 0);

Ici, dans la pratique, le nom de la variable y sera x.

D'un coup, debugger un CSP avec un message d'erreur qui ne m'indique pas la bonne variable n'est réellement pas pratique. Il me semble que cette situation est toujours présente dans Galak. Est-ce possible d'y remédier ?

Fabien.

Propagator Annotation

Dans la branche "annotations", j'ai annoté tous les propagateurs de Galak (présents à ce jour) avec le tag @propann.

A la compile, cela crée un fichier (./solver/target/generated-sources/apt/propagators.txt) qui reprend tous les propagateurs tagués et leur status.

Pour mémoire, voici le wiki du projet PropAnn.

NPE with getPropagationsConditions(int vIdx)

Hi

For my packing propagator, this method returns a mask depending on the variable index. In practice, if it is lesser than the number of bins, it returns the REMOVE mask.

The problem is that at this stage, the method cannot know about the number of bins as it is provided to the propagator constructor while the call to getPropagationConditions() is directly performed by the parent constructor, so too early.

Any hints to fix that ? I'm on the develop branch

Fabien.

Variable: Changer la structure de gestion des propagateurs

tout est dans le titre.
A ce jour, c'est une hash map (bouh) et je propose de la remplacer par une structure rappelant ce qu'il y avait dans choco:

  • un tableau de propagateurs
  • un tableau d'indice (de la variable dans le propagateur)

Cela permet de gérer entre autre le cas des variables apparaissant plusieurs fois dans un propagateur (ex. COUNT (V2, <V1, V2,V3>, dans magic series).
Ca m'aidera aussi pour les recordeurs.

IStateInt.add(int) should return the new value

Hi

IStateInt x ....
int val = x.add(7);

is much more friendly to write than

IStateInt x ....
x.add(7);
int val = x.get();

In addition, this is does not have any cost in terms of performance. Charles did that for me in the last version of Choco but it was not propagated to Galak

Thanks
Fabien

TimeComplexityComparators

Salut,

J'aime beaucoup la politique qui consiste à faire le point fixe sur les propagateurs qui ont une faible complexité avant de lancer ceux qui en ont une grosse. Pour cela je mets la PropagatorPriority à une valeur qui correspond en gros à ma complexité temporelle (unary,linear, quadratic...) mais ce n'est pas très précis car une complexité dépend d'un ou plusieurs paramètres, et ce ne sont pas toujours les mêmes d'un propagateur à l'autre. D'où l'idée de faire un petit langage pour définir au début mes paramètres et fonctions de complexité.
exemple j'ai un graphe à n sommets, m arcs et un tableau de i entiers tel que l'union de leurs domaine vaut d.
prop1 : log(n) + 5.m + i.d
prop2 : n.m
=> lequel est le plus rapide et doit donc être traité en premier?
De plus, ça inciterait les gens à marquer la complexité de leur algo ce qui n'est pas un mal.
On pourrait évaluer ces priorités (et donc trier les propagateurs) soit une fois au début de la recherche, soit au début de chaque noeud...

Pour aller plus loin (un peu trop je pense) on pourrait faire ce travail, par type d'événement.

Changer l'artifactID ?

Salut,

Pour l'instant, je suis obligé de faire cohabiter choco et Galak au sein d'eclipse.
Eclipse n'apprécie pas du tout d'avoir deux projets maven avec les mêmes groupID et artifactID.

Cela va vous sembler fou, mais on pourrait changer l'artifactID de Galak de "choco" à "galak" !

PROBLEME PROPAGATION INITIALE

Bonjour,

j'ai un gros soucis avec la propagation initiale de deux propagateurs A et B:

supposons que dès la pose de mon modèle, certaines de mes variables soient instanciées, elles ne vont pas générer d'INSTANTIATION EVENT, juste?
Du coup pour les traiter dans le propagateur B je dois itérer sur mes variables instanciées durant la propagation initiale de B.
Malheureusement j'ai propagé A avant B et la propagation initiale de A a générée de nouvelles variables instanciées, lesquelles vont à la fois apparaître dans la propagation initiale de B et dans les "requests" de B...??!!
Du coup je fais le boulot 2 fois et ça ne va pas du tout.
Il me semblerait qu'un propagateur ne devrait se réveiller qu'aux évènements qui sont postérieurs à sa propagation initiale, non?
Si c'est sensé déjà être le cas alors il me semble (je peux me tromper) que ça a été récemment cassé.
Sinon, ... pour quelles raisons n'est-ce pas ainsi?

Merci bien et bonne vacances!

new IntegerVariable

Ajouter 2 nouvelles variables entieres:

  • variable avec domaine dynamique
  • variable avec domaine tableau

Fix bug with restarts

Un petit bug pouvait se produire avec l'utilisation de restart en optimisation:

  • Le solver trouve une bonne solution
  • Il fait un restart (retour au noeud root)
  • Il pose sa cut (-1 sur l'objectif en minimisation, pour chercher mieux...)
  • Il propage
  • Il lance la search (OPEN NODE si aucune limite atteinte, CLOSE sinon)

Le problème est que si une limite (temps) est atteinte à ce moment là, le solver ne pourra pas restaurer la meilleure solution, en effet la search loop étant déjà au noeud root les domaines ne sont pas restaurés correctement et la cut rend irréalisable la meilleure solution.

Contre cela Charles à trouvé un patch: il faut faire un world push à chaque restart avant de propager la cut:

public final void restartSearch() {
restaureRootNode();
try {
objectivemanager.postDynamicCut();
propEngine.propagate();
nextState = OPEN_NODE;
} catch (ContradictionException e) {
interrupt();
}
}

devient

public final void restartSearch() {
restaureRootNode();
solver.getEnvironment().worldPush();
try {
objectivemanager.postDynamicCut();
propEngine.propagate();
nextState = OPEN_NODE;
} catch (ContradictionException e) {
interrupt();
}
}

Variables sans propagateurs

Dans certains cas, les variables n'ont pas de propagateurs, par exemple lorsque la variable est impliquée dans des contraintes via des vues.
Cela peut avoir plusieurs impacts non désirables, par exemple les stratégies de choix variables peuvent être erronées (ex: Degree d'une variable).

D'autre part, ca peut semblait perturbant, de prime abord, qu'une variable ne soit pas (directement) liées aux autres variables dans un CSP.

Idempotency on Constraints

Les propagateurs suivants doivent être revus pour être idempotents (ie. qu'ils ne doivent pas s'appeler eux-mêmes).

IntVar :

  • PropBoundGlobalCardinality
  • PropBoundGlobalCardinaltyLowUp

IVariableGraph:

  • PropRelation

BUG setPassive()

Il semblerait qu'il y ait un bug avec la fonction setPassive() des propagateurs
Le sample KTP_Graph_Bool permet de le constater sur le nombre de noeuds pour résoudre
le cavalier d'euler fermé en 14x14 :
modèle booléens, le setPassive de la contrainte PropBoolSum déconne...
Aucune piste pour le moment...

remove complex views

Après mûre reflexion, les vues portant sur 2 variables sont à bannir tant elles impliquent un développement ad-hoc (propagation dynamique).
Elles doivent être remplacées par la pose d'une variable intermediaire et de la contrainte correspondante.
Le domaine de la variable temporaire est calculée en fonction des domaines des 2 variables passées en paramètres.

Ainsi, on propose uniquement du sucre syntaxique.

[BUG] request filtering and delta

Il y a un bug dans la gestion des delta dans Galak, lors de l'application du filtrage:
Avant l'appel au filtrage, on mémorise freeze le delta (partagé) pour mémoriser les retraits de valeurs que l'on pourrait déclencher et qu'on veut garder.
Seulement, du coup, un propagateur qui supprime des valeurs et ne veut pas se réveiller sur celles-ci, les mémorise via ses pointeurs du delta....
Et le fameux booléen à passer en paramètre des modificateurs de variables n'a aucun impact.

Un exemple sera plus clair:

R1(V1, P1) la requête R1 porte sur la variable V1 et le propagateur P1.
On dispose de 4 indices dans une requêtes:
first: l'index de la dernière valeur déjà propagée (dans le delta)
last: index de la dernière valeur non encore propagée (toujours dans le delta)
frozenfirst et frozen last : pour ne pas perdre de valeurs supprimées au cours de la propagation de P1 (pour freezer le delta).

Avant le filtrage de R1,

first = 0; last = 3

On freeze les index:

frozenFirst = first; first = frozenLast = last

Donc, first = 3 et last = 3.
On propage, et P1 supprime des valeurs de V1 (disons 1 valeur) mais comme P1 en est la cause, R1 n'en est pas informé.
Puis on déclenche R2(V1,P2) qui lui aussi supprime des valeurs de V1 (disons 2 valeurs).
Comme P1 n'en est pas la cause, on informe R1 qui met à jour la valeur de last en se basant sur la taille du delta, ici last = 6.
Et au prochain réveil de R1, on va itérer sur les valeurs supprimées, de first à last, avec first = 3 et last = 6.
On obtient alors 3 valeurs au lieu des 2 attendues.

deux niveaux de CUSTOM_PROPAGATION

On veut pouvoir retarder la propagation lourde et traiter les évènements fins d'abord.
Cependant deux comportements sont possible (et il serait bien de les proposer les deux!)
quand un coarse est exécuté alors qu'il reste des fine qui sont schedulées :

  1. on promeut le coarse en FULL_PROPAGATION et on vire les fines
  2. on n'éxecute pas le coarse mais on le reschedule (attention à éviter le while(true) )
    ... on l'exécutera donc uniquement lorsque toutes les fines auront été traitées

Du coup on pourrait renommer CUSTOM_PROPAGATION en DELAYED_PROPAGATION

Etat d'un propagateur

Il me semble que le double état actif/inactif d'un propagateur n'est pas suffisant.
En vérité, un propagateur à 3 état:

  • pas encore actif : nouvellement créé, pas encore propagagé
  • actif : propag' initiale faite, pas encore entailed ou satisfait
  • inactif : ou plutot désactivé, le propagateur est satisfait ou entailed

Du coup, je propose de créer les 3 méthodes suivantes:

  • #isStateLess()
  • #isActive()
  • isPassive()
    (Les 2 dernières existent déjà à vrai dire).

todo : operation copy

la gestion active/passive des propagateurs est gérées par des opérations
Mais celles-ci ne sont pas prise en charge par l'environnement de copie...
Il faudrait y remédier d'une manière ou d'une autre

Incrementality + delta monitor : bug

Ce n'est pas un bug particulier, mais plutot la description d'un bug qui peut apparaitre et qu'il faut discuter.

Il peut arriver qu'une constrainte, C1, supprime une valeur d'une variable, V1, au cours de sa propagation.
Cette variable schedule alors ces recordeurs, sauf celui portant sur C1.
Puis, V1 est de nouveau modifié, par C2, et le recordeur de C1 est schedulé de nouveau.
Lorsqu'il se réveille sur la nouvelle modification de V1, il itére sur les valeurs supprimées, et redécouvre les valeurs qu'il a lui même supprimé!
On peut étendre ce cas à un cas plus complexe où V1 est modifié par C1 plusieurs fois (par ex. par différents recordeurs de C1 portant sur d'autres variables et schédulé plus tôt dans le moteur de propagation).

C'est donc problématique si la contrainte est incrémentale et que son incrémentalité repose sur le principe qu'elle ne peut pas se réveiller elle-même.

Il existe au moins 2 solutions:

  • avoir ce cas en tête en développant la contrainte -- ca peut vite devenir compliqué
  • avoir un delta monitor qui gére ce cas. C'est dit (et peut-être vite fait) mais ca implique que chaque recordeur mémorise toutes les valeurs non propagées (ie, on vire le delta de la variable et on en met un dans chaque recordeur). Je pense que ca va vite peter en mémoire et ajouter une (grosse) constante à la compléxité algo de la méthode de modification de variable.

Il y a peut-être d'autres solutions, que je ne vois pas pour le moment.

J'ajoute les 2 remarques présentes dans l'issue #66 :

  • certaines contraintes réagissent à la suppression de valeurs mais n'ont pas besoin de connaitre les valeurs supprimées (ex. PropElement). Il est peut-être judicieux de considérer ce cas;
  • dans la même veine, la promotion d'évenement perd la cause. Est-ce vraiment utile? Y'a-t-il des contraintes pour lesquelles c'est vraiment nécessaire?

Test tag

Il est nécessaire de tagguer tous les tests.
Parmi les tags existants:
@test(groups = "1s")
@test(groups = "10s")
@test(groups = "30s")
@test(groups = "1m")
@test(groups = "10m")
@test(groups = "30m")
@test(groups = ">30m")
@test(groups = "1h")

Constraint as plugin

En écho à la conversation de ce midi concernant l'intérêt de séparer les contraintes stables de celles en développement, je vois 2 approches:

J'ai une petite préférence pour la première propal, qui nous permet de faire un truc ad hoc.
Il y a sans doute d'autres possibilities, plus simple, que je n'ai pas encore rencontrer.

API Consistency when managing bounds

Hi

To retrieve a bound on a variable 'x', we have 'x.getLB()' and 'x.getUB()'. It's short, it's simple, it's great.

To update a bound on 'x', we have to use 'x.updateLowerBound()' and 'x.updateUpperBound()'. This is soooo verbose and not aligned with the getters. I would enjoy to have 'x.setLB()' and 'x.setUB()'.

It's the same for the instantiation process. On one side, you have 'x.getValue()', on the other side, you have 'x.instantiateTo()'.

BR
Fabien.

Recording solutions

Salut,

Sauf erreur de ma part, actuellement toutes les variables sont enregistrées lorsqu'une solution est sauvegardée.
Problème: pour les variables non instanciées, on enregistre par défaut le borne inf. Cela peut je pense conduire à des erreurs.

Je propose qu'on ne sauvegarde que les variables de décisions et qu'on lève une exception si l'une d'elle n'est pas instanciée.

Vos avis?

FZN parser improvments

Quelques idées d'amélioration du parser FZN (à compléter):

  • lazy creation des variables introduites par mzn2fzn pour éviter les bool2int
  • détecter les clauses à la lecture et poster 1 seul CNF

backjumping for optimization

En optimisation, lorsqu'une solution a été trouvé, au lieu de backtracker normalement,
on devrait remonter au noeud où l'on a pour la dernière fois modifié la borne (inf ou sup selon le critère d'optimisation) de l'objectif.
Proposition d'implémentation :
Dans la classe ObjectiveManager

  • ajouter un entier backtrackable pour désigner le monde à restaurer en cas de découverte de solution.
  • Le modifier via la méthode update.
  • Déclencher le backjumping lors de la découverte de solution, en ajoutant un searchMonitor à l'objectiveManager.

Reified + filter

La contrainte Reified devrait embarquer les propagateurs des contraintes et non pas les contraintes, on pourrait alors supprimer la méthode #filter() de Constraint.

Nettoyer les delta monitors après propagation

Dans le cas de l'execution virtuelle des recordeurs fins, les delta moniteurs doivent être de freezé.
Pour éviter toute incohérence, il faut s'assurer que le delta de la variable a été bien lazy clearé auparavant.

Les masques des propagateurs

Les masques de propagation interviennent à plusieurs endroits:

  • à quoi réagit un propagateur,
  • caractérisation d'une modification de variable,
  • caractérisation des modifications appliquées à une variable pour l'exécution d'un propagateur

Le treillis défini par Schulte est une base de travail mais il reste des questions:

  • le masque de modification d'une variable doit-il contenir les événements induits ou
  • ces événements induits doivent-ils être reconstruits dans le propagateur?

Dans le premier cas, on noie les informations, dans le 2ème cas on compte sur le développeur du propagateur.

Liste de recordeurs d'une variable

La liste de recordeurs d'une variable gére les 3 états d'un recorder (new, actif, passif).
Aujourd'hui, des tests sont insérés dans le code pour éviter d'activer 2 fois un element ou désactiver 2 fois un élément.
Or, ces tests sont faux, et le code peut être plus simplement écrit pour éviter ces tests inutiles (en évitant de réactiver un element déjà actif).

Réunions choco?

ReBonjour,

S'il est facile de déposer des idées sur le net, décider et faire l'est un peu moins...
Que pensez-vous d'organiser des réunions Choco régulièrement pour faire des points d'avancement, décider ensemble certains choix et nous distribuer les tâches? Nos échanges sur Github permettront de bien préparer ces réunions.
Je propose de commencer timidement avec une fréquence d'une fois par mois ce qui me semble être un minimum.
Si vous êtes tous d'accord on regardera nos disponibilités en début de semaine prochaine pour convenir d'une date.
bon weekend.

Autoriser le postCut

A ce jour, on ne fait que des post dynamique, on doit pouvoir faire un post statique "au cours de la recherche".

Ca a un impact sur la création des requetes, qui doivent être ajouté statiquement (en utilisant HalfBacktrackableList a la place de RequestArrayList qui est uniquement dynamique) et surtout qui doivent être crée "en retard" par rapport à actuellement.
Ca a un impact également sur le proapagation engine qui doit être reinitialisé.

Lier variables et propagateurs

A ce jour, attacher une variable à l'un de ses propagateurs a pour effet:

  • d'ajouter le propagateur dans la liste des propagateurs de la variable
  • de vérifier le masque de réaction du propagateur pour justifier de la création d'un delta avec mémoire (remplacant le fake par défaut qui ne fait rien)

Je propose de distinguer ces 2 étapes, à cause de vues.
Une vue dispose de sa liste de propagateur mais ne possède pas de delta. Elle se repose sur le delta de la variable qu'elle observe. Or, il faut s'assurer que la variable observée possède bien un delta quand la vue en requiert un.
Distinguer ces 2 étapes permet de le faire simplement.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.