Bug with incremental equivalence preprocessing

[rkaminsk]

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

[BenKaufmann]

Interesting. Seems to be a regression introduced in version 3.2.0.
I'll try to look into it on the weekend.