Clarify if singleton base domain means "specified" #165
Comments
miatauro-NASA
added a commit
that referenced
this issue
Dec 4, 2014
Closing a singleton base domain now marks the variable as specified. This seems inconsistent with a previous commit to distinguish specified variables from variables with singleton base domains, but that commit didn't touch Variable::handleRestrictBaseDomain, which does specify variables whose base domain gets restricted to a singleton. This should be clarified and made consistent. See issue #165. Made the beginning of the ConstraintEngine::ChangeType enumeration and the DomainListener::ChangeType enumeration into line. See issue #166 Added initializers to the EquivalenceClassCollection constructor, which caused some random test failures sometimes.
miatauro-NASA
added a commit
that referenced
this issue
May 27, 2021
Closing a singleton base domain now marks the variable as specified. This seems inconsistent with a previous commit to distinguish specified variables from variables with singleton base domains, but that commit didn't touch Variable::handleRestrictBaseDomain, which does specify variables whose base domain gets restricted to a singleton. This should be clarified and made consistent. See issue #165. Made the beginning of the ConstraintEngine::ChangeType enumeration and the DomainListener::ChangeType enumeration into line. See issue #166 Added initializers to the EquivalenceClassCollection constructor, which caused some random test failures sometimes.
miatauro-NASA
added a commit
that referenced
this issue
May 27, 2021
Closing a singleton base domain now marks the variable as specified. This seems inconsistent with a previous commit to distinguish specified variables from variables with singleton base domains, but that commit didn't touch Variable::handleRestrictBaseDomain, which does specify variables whose base domain gets restricted to a singleton. This should be clarified and made consistent. See issue #165. Made the beginning of the ConstraintEngine::ChangeType enumeration and the DomainListener::ChangeType enumeration into line. See issue #166 Added initializers to the EquivalenceClassCollection constructor, which caused some random test failures sometimes.
lsylusiyao
pushed a commit
to lsylusiyao/europa
that referenced
this issue
Oct 25, 2022
Closing a singleton base domain now marks the variable as specified. This seems inconsistent with a previous commit to distinguish specified variables from variables with singleton base domains, but that commit didn't touch Variable::handleRestrictBaseDomain, which does specify variables whose base domain gets restricted to a singleton. This should be clarified and made consistent. See issue nasa#165. Made the beginning of the ConstraintEngine::ChangeType enumeration and the DomainListener::ChangeType enumeration into line. See issue nasa#166 Added initializers to the EquivalenceClassCollection constructor, which caused some random test failures sometimes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Commit f67a5f1 claims that specification must be explicit, but tests remain for a case where a domain becomes specified through restriction of the base domain, and Variable::restrictBaseDomain can cause a variable to become specified. The behavior needs clarification and the code brought into line with that.
The text was updated successfully, but these errors were encountered: