-
Notifications
You must be signed in to change notification settings - Fork 16
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
[eprime-minion] Implement modulo #456
Comments
Should be identical to div, yes. |
@ozgurakgun should savilerow and conjure have the same modulo semantics? If not, which should I follow? For these models, conjure and savile row give drastically different numbers of solutions: (conjure: 21 solutions, savilerow 7)
(conjure: 60 solutions, savilerow: 1)
|
Conjure and Savilerow agree on the div tests that these were based on. |
Ignore the above: they agree with -S0! |
I was about to ask what options you are passing, because Conjure basically just passes these through. Stick to -S0 indeed. |
|
Is the simplifcation here to rewrite not equals expressions where the lhs and rhs domains are disjoint to true? |
Add modulo expressions, parsing, and conversion rules to Minion. The undefinedness semantics for modulo are similar to those for division: it requires a bubble rule, asserting that for x % y, y!=0, to make it safe. Due to their similarity, the test cases for modulo in this patch are based on the division ones. See also: conjure-cp#454 Closes: conjure-cp#456
Add modulo expressions, parsing, and conversion rules to Minion. The undefinedness semantics for modulo are similar to those for division: it requires a bubble rule, asserting that for x % y, y!=0, to make it safe. Due to their similarity, the test cases for modulo in this patch are based on the division ones. See also: conjure-cp#454 (implementation of division rules) Closes: conjure-cp#456
Add modulo expressions, parsing, and conversion rules to Minion. The undefinedness semantics for modulo are similar to those for division: it requires a bubble rule, asserting that for x % y, y!=0, to make it safe. Due to their similarity, the test cases for modulo in this patch are based on the division ones. See also: conjure-cp#454 (implementation of division rules) Closes: conjure-cp#456
Add modulo expressions, parsing, and conversion rules to Minion. The undefinedness semantics for modulo are similar to those for division: it requires a bubble rule, asserting that for x % y, y!=0, to make it safe. Due to their similarity, the test cases for modulo in this patch are based on the division ones. See also: conjure-cp#454 (implementation of division rules) Closes: conjure-cp#456
Add modulo expressions, parsing, and conversion rules to Minion. The undefinedness semantics for modulo are similar to those for division: it requires a bubble rule, asserting that for x % y, y!=0, to make it safe. Due to their similarity, the test cases for modulo in this patch are based on the division ones. See also: conjure-cp#454 (implementation of division rules) Closes: conjure-cp#456
don't feel like you have to do this in this PR, in fact you probably shouldn't, but we should first have:
in the metadata. we would store the int domain for all Atomic entries, and calculate the domain for all composite expressions. we can look into how SR calculates bounds to work out the domains. for example for mod and div. once we calculate the domain of both sides of note: SR's getBounds returns an IntPair but we should maintain a Domain since we will have more kinds of domains, not just ints. |
captured this in #461 |
Summary
Implement modulo operator and convert it to Minion. As with all other Minion rules, constraints targeting mod specifically should be provided in
minion_constraints
. These should include tests for neq, negated eq, and nested constraints.I imagine that this will work similarly to division (#454), and similar test cases could be used.
Tasks
Questions
The text was updated successfully, but these errors were encountered: