Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## potassco-users

 [Potassco-users] unexpected behavior of grounding From: Peter Skočovský - 2012-06-29 08:11:13 Attachments: Message as HTML Hello! I have run across another cases of unexpected behavior of Gringo and I would like to know what is the expected behavior in this cases. First is that Gringo admits an unbound variable in aggregate in some cases, even though the manual says that any variable in an aggregate must be bound either globally or in a condition. For example: 1{a(1..3)}. p :- 1{a(X)}2. When I feed this program to `gringo -tV`, it expands the second rule to p:-1#count{a(3),a(2),a(1)}2. This seems like the literal a(X) in the aggregate is expanded into its possible instances. Which is in the contract of grounding, but not described in the manual. This, of course, cannot work if the aggregate containing an unbound variable enables derivation of further possible values for this variable. For example, when I feed program: p(1). p(N+1) :- N={p(X)}. into gringo, it ends with error saying that variable X is unsafe. Until now I thought that safeness of variables is defined by their bounding in positive literals or conditions (as described in the manual). How is safeness determined when the variable is unbound in an aggregate? When can I be sure that this is not allowed? The second case is when there is a pooling with more than 2 terms in the #sum aggregate (or any aggregate with []). For example: a(6). q :- 3[a(1;d;ee;6)]. I would guess that this program does NOT infer q, because there is only one literal true in the aggregate: a(6). However, `gringo -tV` says that the second rule is grounded to: q:-3 #sum[a(6)=1,a(6)=1,a(6)=1,a(ee)=1,a(6)=1,a(ee)=1,a(d)=1,a(1)=1]. Why are there suddenly 4 copies of a(6) ? How does the pooling actually work? I would mainly like to know what is intended behavior of grounding. Are these bugs, or deprecated cases, or are they for backward compatibility. Or is this intended behavior? If it is not, what is intended behavior then? How will be grounding changed in the future? I would need to know this, because I am currently working on one ASP debugging approach withing the project M&MDASP. I need to find out what are the active instances of a Gringo rule under some interpretation. So I kind of need to simulate grounding as Gringo does it. I do not need to match the Gringo's behavior completely for now. But we would like to support some sensible subset of Gringo's behavior (or the intended behavior) in the future. So I would like to also ask what development do you expect in this area? Best wishes! Peter
 Re: [Potassco-users] unexpected behavior of grounding From: Roland Kaminski - 2012-06-29 10:47:08 Attachments: signature.asc On Friday 29 June 2012 10:11:06 Peter Skočovský wrote: > Hello! > > I have run across another cases of unexpected behavior of Gringo and I > would like to know what is the expected behavior in this cases. > > > First is that Gringo admits an unbound variable in aggregate in some cases, > even though the manual says that any variable in an aggregate must be bound > either globally or in a condition. For example: > > 1{a(1..3)}. > p :- 1{a(X)}2. > > When I feed this program to `gringo -tV`, it expands the second rule to > > p:-1#count{a(3),a(2),a(1)}2. > > This seems like the literal a(X) in the aggregate is expanded into its > possible instances. Which is in the contract of grounding, but not > described in the manual. > This, of course, cannot work if the aggregate containing an unbound > variable enables derivation of further possible values for this variable. > For example, when I feed program: > > p(1). > p(N+1) :- N={p(X)}. > > into gringo, it ends with error saying that variable X is unsafe. Until now > I thought that safeness of variables is defined by their bounding in > positive literals or conditions (as described in the manual). How is > safeness determined when the variable is unbound in an aggregate? When can > I be sure that this is not allowed? This is an extension to what is described in the guide. If the first atom of an element of a lower/upper bound body aggregate is non-recursive, then its variables do not have to be bound by domain predicates. Currently, I am working on loosening restrictions there further. In fact, I have already a prototype that would accept your second program; though the grounding would not halt if no stop criterion is specified, e.g.: p(N+1) :- N={p(X)}, N < 10. > The second case is when there is a pooling with more than 2 terms in the > #sum aggregate (or any aggregate with []). For example: > > a(6). > q :- 3[a(1;d;ee;6)]. > > I would guess that this program does NOT infer q, because there is only one > literal true in the aggregate: a(6). However, `gringo -tV` says that the > second rule is grounded to: > > q:-3 #sum[a(6)=1,a(6)=1,a(6)=1,a(ee)=1,a(6)=1,a(ee)=1,a(d)=1,a(1)=1]. > > Why are there suddenly 4 copies of a(6) ? How does the pooling actually > work? This is a bug that has already been fixed in the most recent gringo version. We have a mailing list where we post release announcements. Maybe you want to subscribe there too. It is very low traffic: potassco-announce@... Regards, Roland