Bug with incremental equivalence preprocessing
rkaminsk opened this issue · comments
The following aspif program is not solved correctly if equivalence preprocessing is enabled:
asp 1 0 0 incremental
1 0 1 1 0 0
1 0 1 2 0 0
1 0 1 3 0 0
1 0 1 4 0 1 5
1 0 1 6 0 1 7
1 0 1 8 0 1 5
1 0 1 9 0 1 7
1 0 1 10 0 1 4
1 0 1 11 0 1 6
1 0 1 12 0 1 8
1 0 1 13 0 1 9
1 1 2 5 7 0 1 3
1 0 1 14 1 1 2 5 1 7 1
1 0 1 15 1 2 2 5 1 7 1
1 0 1 16 0 2 14 -15
1 0 0 0 2 3 -16
4 6 q(0,0) 1 4
4 6 q(0,1) 1 6
4 6 q(1,0) 1 8
4 6 q(1,1) 1 9
0
1 0 1 17 0 0
1 0 1 18 0 0
1 0 1 21 0 1 -19
1 0 1 22 0 1 -19
1 0 1 20 1 3 6 10 1 11 1 12 1 13 1 -21 1 -22 1
1 0 1 24 0 1 -19
1 0 1 25 0 1 -19
1 0 1 23 1 2 6 10 1 11 1 12 1 13 1 -24 1 -25 1
1 0 1 26 0 2 -20 23
1 0 0 0 1 26
1 0 0 0 1 -11
1 0 0 0 1 -13
1 0 0 0 1 10
1 0 0 0 1 12
0
This program was grounded using the following program:
#script (python)
import clingo
def main(control):
# base
control.ground([("base",[])])
# solve
control.solve()
# add model and modified preference program
model = 'h(q(0,1),1). h(q(1,1),1).'
control.add("m1", [], model)
control.ground([("m1",[])])
control.ground([("preference", [])])
# solve
control.solve()
#end.
#program base.
#show q/2.
%#show h/2.
c(0..1).
1 { p(0..1) } 1.
q(C,P) :- p(P), c(C).
h(q(C,P),0) :- q(C,P).
#program preference.
:- h(X,0), not h(X,1).
:- not h(X,0), h(X,1).
:- #sum { -1,X : h(X,0); 1,X : h(X,1)} = 0.
Adding the preference program should make any program unsatisfiable. Compare
clasp bug.sm --eq=1
clasp version 3.3.3
Reading from bug.sm
Solving...
Answer: 1
q(0,1) q(1,1)
Solving...
Answer: 1
q(0,1) q(1,1)
SATISFIABLE
with
clasp bug.sm --eq=0
clasp version 3.3.3
Reading from bug.sm
Solving...
Answer: 1
q(0,1) q(1,1)
Solving...
UNSATISFIABLE
Interesting. Seems to be a regression introduced in version 3.2.0.
I'll try to look into it on the weekend.