-
Notifications
You must be signed in to change notification settings - Fork 82
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
#delayed output #331
Comments
When a (recursive) rule with a head aggregate is grounded, its body is instantiated before its head is grounded. Thus, you get #delayed(n) :- Body. when the body has been instantiated and later #delayed(n) <=> Aggregate. when the head aggregate is completely grounded. Since this is often a source of confusion, I should probably store the partial rule, and then substitute the head aggregate and output it when the grounding is complete. I'll mark it as a future todo item. Since choice rules with exactly one element are a very common language feature, I implemented a specialized grounding algorithm for them that is both faster and does not need to delay grounding the head. |
many thanks for the clarification, Roland! best, |
I'll just reopen because I want to mark this as a future todo item. |
Hi @rkaminsk - do you have a way to read the ground output like this:
|
On some level I'm trying to investigate the distinction between the following pair of rules:
They have different groundings as hinted at in this discussion and knowing how to read the |
The
Note that clingo adds some seemingly unnecessary elements to the tuples. This is to support rules like
as they are for example supported by lparse (in a similar form). The set aggregate says that The two rules
and
have a different meaning. The first says that any number of actions might occur at a time step. The second that at most one action might occur at a time step. |
I understand that reading of the choice rules, but it raises the question of whether these are equivalent:
The lack of cardinality bounds seems to blur the distinction here. |
Yes, one could say they are strongly equivalent. Also including
Note that clingo is optimized for grounding the first version. You will notice the different output. Maybe future version will be extended to include the other variants. It depends on when I find the time to look into this. |
@rkaminsk thanks! This is interesting. I can take this offline but are there any rules of thumb performance-wise around choice rules (solver side) that you can maybe send me? |
When I mentioned performance, I was thinking of grounding. For the solver, all three versions of the choice rules should be equivalent. So, if the grounding is not too large, either version can be used. |
hello,
here is a simple example to illustrate my question:
p1.lp consists of
0 {a} 1.
Calling "clingo --text p1.lp" gives
#delayed(1). #delayed(1) <=> #count{0,a:a}
p2.lp consists of
{a}.
Calling
clingo --text p2.lp
gives{a}.
my question is: what does #delayed(1) <=> #count{0,a:a} mean in this example? and "#delayed" output in general as i encounter it on a regular basis when using n {....} m constructs but could not find anything about it online or in the Potassco user manual.
thank you in advance,
stas
The text was updated successfully, but these errors were encountered: