Comments (12)
mmmh je ne suis pas tout à fait d'accord pour setLB et setUB (on ne modifie pas la valeur de l'attribut au sens des accesseurs ; on met à jour la borne inférieure de la variable au sens "contrainte"). Je serais alors plutôt favorable à updateLB et updateUB que setLB et setUB
c'est la même chose pour les instantations : d'un côté tu consultes la valeur de la variable (getValue) de l'autre tu poses un acte "contrainte" : une instantation, tu ne modifies pas la valeur d'un attribut.
Il me semble utile de garder ces distinctions en tête (mais je suis peut-être trop vieux jeu). Qu'en pensent les autres ?
Naren
Le 10 nov. 2012 à 11:38, Fabien Hermenier a écrit :
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.—
Reply to this email directly or view it on GitHub.
from choco-solver.
C'est parti pour le français donc.
update* me va aussi dans le sens ou c'est consistent.
Charles m'avait aussi exprimé un point de vue similaire. Je pense que notre différence d'opinion vient du fait que tu penses modèle contrainte, avec la terminologie qui va avec et tu veux que l'API reflète cette terminologie.
De mon côté, je pense développement: choco c'est un framework comme un autre.
Je veux connaître la sémantique de ces méthodes avec des termes du domaine de la PPC dans la documentation, mais à chaque fois que je dois utiliser des noms de méthodes qui changent un peu par rapport à l'habitude, je perds mes repères par rapport aux "normes" de programmation existantes (mais je suis peut-être trop vieux jeu :D).
Fabien.
from choco-solver.
Je comprends bien ton point de vue :) C'est pour ça que je me trouvais vieux jeu. La vraie question, comme tu le pointes, est de savoir si on veut "cacher" la mécanique contrainte ou pas. Cela ne me choque pas forcément de la cacher dans cette optique "choco est un framework comme un autre" ... comme pour beaucoup de choses le risque est la perte de compréhension intime de ce qui se passe ... mais si je suis capable de conduire une voiture sans savoir comment ça fonctionne, on peut se dire la même chose de la ppc :)
J'attends les avis des autres.
Naren
Le 10 nov. 2012 à 12:19, Fabien Hermenier a écrit :
C'est parti pour le français donc.
update* me va aussi dans le sens ou c'est consistent.
Charles m'avait aussi exprimé un point de vue similaire. Je pense que notre différence d'opinion vient du fait que tu penses modèle contrainte, avec la terminologie qui va avec et tu veux que l'API reflète cette terminologie.
De mon côté, je pense développement: choco c'est un framework comme un autre.
Je veux connaître la sémantique de ces méthodes avec des termes du domaine de la PPC dans la documentation, mais à chaque fois que je dois utiliser des noms de méthodes qui changent un peu par rapport à l'habitude, je perds mes repères par rapport aux "normes" de programmation existantes (mais je suis peut-être trop vieux jeu :D).Fabien.
—
Reply to this email directly or view it on GitHub.
from choco-solver.
En ce qui me concerne je suis contre "setXX" parce qu'il est possible que l'appel de méthode échoue.
Or, setXX sous-entend que l'action est directe.
Ca me dérange également que les utilisateurs ne soient pas conscients de l'aspect effet de bord.
Par contre, pourquoi pas updateLB au lieu de updateLowerBound, etc.
En ce qui concerne getValue() et instantiate(), c'est moins évident.
Par exemple, si la variable n'est pas instantiée, getValue renvoie la borne inférieure (ou une erreur si "-ea").
On pourrait imaginer un restrictDomainTo(), ou un truc du genre... (sans conviction).
from choco-solver.
Je suis d'accord avec Charles
et j'aime bien le: updateLB / updateUB
Pour la différence getValue() / instantiateTo
C'est vrai qu'il est un peu gênant d'avoir des noms si différent (différents entre eux, et des autres méthodes)
On ne peut pas mettre "updateValue" je pense car, avant l'appel de la méthode, la valeur n'était a priori pas définie...
pourquoi pas un "enforceValue(42)"?
from choco-solver.
ou proposer getInstantiation() (à la place ou en plus de getValue())
from choco-solver.
ça me paraît difficile : il n'y a pas réellement de "value" lorsque la variable concernée n'est pas instantiée : getValue renvoie alors la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)
enforceValue ou enforce n'est pas mal par contre
Naren
Le 19 nov. 2012 à 23:25, jgFages a écrit :
ou proposer getInstantiation() (à la place ou en plus de getValue())
—
Reply to this email directly or view it on GitHub.
from choco-solver.
Bonjour
De mon point de vue extérieur, getValue() / instantiateTo() ne me choque pas trop
Je trouve enforceValue() trop long (je me doute bien que c'est une valeur de par le parametre).
Pour enforce(), ca me choque un peu car c'est un mot que je ne verrais qu'à cet endroit dans l'API alors que instantiate est à plusieurs endroits il me semble (il n'y a pas un isInstantiated() dans CPSolver ?), c'est un mot de vocabulaire de base de la CP et je le retrouvais partout dans la doc de Choco.
A+
Fabien
----- Mail original -----
ça me paraît difficile : il n'y a pas réellement de "value" lorsque
la variable concernée n'est pas instantiée : getValue renvoie alors
la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)enforceValue ou enforce n'est pas mal par contre
Naren
Le 19 nov. 2012 à 23:25, jgFages a écrit :
ou proposer getInstantiation() (à la place ou en plus de
getValue())—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub .
from choco-solver.
Salut,
si je peux me permettre, c'est toi qui as lancé la discussion sur getValue/instantiateTo ... :) nous, on aime bien ;)
Naren
Le 20 nov. 2012 à 07:55, Fabien Hermenier a écrit :
Bonjour
De mon point de vue extérieur, getValue() / instantiateTo() ne me choque pas tropJe trouve enforceValue() trop long (je me doute bien que c'est une valeur de par le parametre).
Pour enforce(), ca me choque un peu car c'est un mot que je ne verrais qu'à cet endroit dans l'API alors que instantiate est à plusieurs endroits il me semble (il n'y a pas un isInstantiated() dans CPSolver ?), c'est un mot de vocabulaire de base de la CP et je le retrouvais partout dans la doc de Choco.A+
Fabien----- Mail original -----
ça me paraît difficile : il n'y a pas réellement de "value" lorsque
la variable concernée n'est pas instantiée : getValue renvoie alors
la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)enforceValue ou enforce n'est pas mal par contre
Naren
Le 19 nov. 2012 à 23:25, jgFages a écrit :
ou proposer getInstantiation() (à la place ou en plus de
getValue())—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub .
—
Reply to this email directly or view it on GitHub.
from choco-solver.
Tout a fait, mais je parlais également du getLB() vs. updateLowerBound()/updateLB()/et feu setLB()
Mais si setValue(), getValue() ne vous semble pas propre, je trouve que getValue()/instantiateTo() plus compréhensible et/ou court que getInstantiated()/setInstantiatedTo() ou restrictDomainTo(), ou enforceValue().
Fabien
----- Mail original -----
Salut,
si je peux me permettre, c'est toi qui as lancé la discussion sur
getValue/instantiateTo ... :) nous, on aime bien ;)Naren
Le 20 nov. 2012 à 07:55, Fabien Hermenier a écrit :
Bonjour
De mon point de vue extérieur, getValue() / instantiateTo() ne me
choque pas tropJe trouve enforceValue() trop long (je me doute bien que c'est une
valeur de par le parametre).
Pour enforce(), ca me choque un peu car c'est un mot que je ne
verrais qu'à cet endroit dans l'API alors que instantiate est à
plusieurs endroits il me semble (il n'y a pas un isInstantiated()
dans CPSolver ?), c'est un mot de vocabulaire de base de la CP et
je le retrouvais partout dans la doc de Choco.A+
Fabien----- Mail original -----
ça me paraît difficile : il n'y a pas réellement de "value"
lorsque
la variable concernée n'est pas instantiée : getValue renvoie
alors
la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)enforceValue ou enforce n'est pas mal par contre
Naren
Le 19 nov. 2012 à 23:25, jgFages a écrit :
ou proposer getInstantiation() (à la place ou en plus de
getValue())—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub .
—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub .
from choco-solver.
Ok sinon pour info je n'utilise jamais de getValue pour les variables graphes: je regarde si ma variables est instantiée et ensuite je prends une borne (en guise de valeur).
On pourrait faire la même chose pour les entiers ça règlerait le problème...
from choco-solver.
Je recommande POMME+SPACE ou CTRL+SPACE ;)
from choco-solver.
Related Issues (20)
- [BUG] Module descriptor seems overkill HOT 5
- `getGraphVal()` is missing from the Solution object.
- [Question] Excuse me, I want to quickly get the intersection of all variable solutions, how to do? HOT 1
- License change planned? HOT 2
- [BUG] Choco does not check for timeout during initialization phase HOT 2
- `Settings` object should become immutable once the model is setup HOT 2
- Add more Statistics (like peak depth) in Choco-Solver FlatZinc Frontend
- Reified global constraints are decomposed in Minizinc parser HOT 1
- Minizinc 2.8.1 compatibility issues HOT 7
- [BUG] MiniZinc/Choco 231102, `aaa1ae7b9`, `minimum_arg`, wrong solution HOT 1
- [BUG] MiniZinc/Choco 231102, `aaa1ae7b9`, `network_flow_cost`, missing solution HOT 1
- [BUG] MiniZinc/Choco 240130, `c90bf40a9`, reified count, missing solutions
- [BUG] MiniZinc/Choco 240130, `c90bf40a9`, `^`, missing solutions HOT 3
- [BUG] MiniZinc/Choco 240130, `c90bf40a9`, `count`, wrong solutions HOT 1
- [BUG] Cannot parser args correctly in fzn-choco HOT 1
- Lazy creation of variables
- [Documentation] Wrong specs in Implied and Reif constraints/propagators
- Makes it possible to create a constraint without a propagator
- [FEATURE] MultivaluedDecisionDiagram : Making the compact method optionnal
- [BUG] IsEntailed for InverseChanneling not working with negative bounds HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from choco-solver.