Skip to content
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

User Guide (2.2.0) Example 3.13 #33

Open
rgrzywinski opened this issue Nov 5, 2021 · 2 comments
Open

User Guide (2.2.0) Example 3.13 #33

rgrzywinski opened this issue Nov 5, 2021 · 2 comments

Comments

@rgrzywinski
Copy link

(This isn't a question about the guide per se so I didn't submit it there. If there is a better place to ask this, please let me know!)

Example 3.13 in User Guide (2.2.0) reads:

person(jane). person(john).
day(mon). day(tue). day(wed). day(thu). day(fri).

available(jane) :- not on(fri).
available(john) :- not on(mon), not on(wed).

meet :- available(X) : person(X).
on(X) : day(X) :- meet.

If the availability of john is changed from a conjunction of negations to a disjunction then the encoding no longer returns the expected answer sets:

% available(john) :- not on(mon), not on(wed).
available(john) :- on(tue).
available(john) :- on(thu).

Specifically, the grounder removes all of the meet terms:

person(jane).
person(john).
day(mon).
day(tue).
day(wed).
day(thu).
day(fri).
available(jane):-not on(fri).

Is this expected? If so, why?

My second somewhat related question is about how not binds. If the last two rules are changed to the following:

% meet :- available(X) : person(X).
% on(X) : day(X) :- meet.
on(X) : day(X).
:- not available(X) : person(X).

then the expected results are not obtained. But instead if the two rules are changed to the following:

meet :- available(X) : person(X).
% on(X) : day(X) :- meet.
on(X) : day(X).
:- not meet.

then the expected results are seen. My assumption is that negation cannot be used as I intended and therefore the auxiliary predicate is necessary. Is there a way to perform the negation as in the first case?

FWIW: I would change 3.13 to use this last encoding so that it works with all cases.

Thanks in advance for any help or guidance!

@rkaminsk
Copy link
Member

rkaminsk commented Nov 5, 2021

The example is admittedly strange but clingo works alright.

Question 1

For a positive program clingo computes the minimal model:

person(jane). person(john).
day(mon). day(tue). day(wed). day(thu). day(fri).

available(jane) :- on(fri).
available(john) :- on(fri).

meet :- available(X) : person(X).
on(X) : day(X) :- meet.

Note that we can simply make meet false. Then nothing forces us to derive on and available. The solver correctly only reports facts over person and day.

Note that the predicates are recursive: available derives meet derives on derives available. If you are just learning ASP forget about such programs. This is not how typical programs are written.

Question 2

The not applies to each individual "head" of the conditional literal. Actually, in your example, you do not need the meet predicate and can simply write:

:- person(X), not available(X).

Your suggestion

Yes, your program is easier to understand. (Even though it has a different semantics.) I have not checked the section in the guide but probably we can replace it with your suggestion.

@rkaminsk rkaminsk transferred this issue from potassco/clingo Nov 5, 2021
@rgrzywinski
Copy link
Author

Thank you for the fast reply.

Thank you for your exposition on my question #1. I know ASP fairly well but I'm attempting to see if I can understand it from a "perturbation" standpoint (my background in physics causes me to do such nutty things 😊 ). When I perform some minimal change to the encoding, I want to understand the effects on the models. I had expected the largest delta to occur in the models when both rules were positive not when I made one of the positive. But, as you pointed out, the due to the minimal model semantics, as soon as you make one of the rules positive then it effectively "short circuits" all of the elements that would have been put there by the remaining negative rule. Again thanks for the proverbial smack in the back of my head.

As for my terrible excuse and a brain fart of a question #2, you ended up answering the root of what I was asking so thank you for that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants