Unexpected behaviour with incremental solving

[Mark Law]

Hi,

I'm getting some strange behaviour with both version 5.6.2 and the head of master. This is a simplified version of something automatically generated by our system, so apologies if the program looks a bit weird.

#program base.
#show n/1.
{ n(0..4)}.

c :- not n(3).

e1 :- not n(1).
e2 :- not n(2).

:- not n(0); not n(4).
:- e1; not n(3).
:- not n(4); e2. 

#program prg_1.

a :- e1, e2. 
:- not a.

#script (python).

def main(prg):
  prg.ground([("base", [])])
  print(prg.solve())
  prg.ground([("prg_1", [])])
  print(prg.solve())
#end.

If I take out the first solve (i.e. ground both programs and then solve), Clingo gives the expected solution. If I run it as above, Clingo returns unsatisfiable the second time. Is there something I'm missing, or is this a bug?

Thanks,

Mark

[Roland Kaminski]

@marklaw, thanks for the report and the nice and small example.

@BenKaufmann, this seems to be a bug in the preprocessor. Running the problem with --eq=0 and --eq=1 produces different results. The first one seems to be the correct one. The problem in aspif format is as follows:

1 1 1 1 0 0
1 1 1 2 0 0
1 1 1 3 0 0
1 1 1 4 0 0
1 1 1 5 0 0
1 0 1 6 0 1 -3
1 0 0 0 2 6 -5
1 0 1 7 0 1 -2
1 0 0 0 2 -4 7
1 0 0 0 2 -5 -1
1 0 1 8 0 1 -4
4 4 n(0) 1 1
4 4 n(1) 1 2
4 4 n(2) 1 3
4 4 n(3) 1 4
4 4 n(4) 1 5
4 1 c 1 8
4 2 e1 1 7
4 2 e2 1 6
0
1 0 1 9 0 2 6 7
1 0 0 0 1 -9
4 1 a 1 9
0

[Benjamin Kaufmann]

Thanks for the report 👍 Should be fixed in dev.