Post by Lars Ericson on Jul 21, 2015 20:41:15 GMT -8
OK so if I look at the picture for Best Buttons & Lights or the picture for OneStep, I look for leaf goal node with the highest value. In the case of BBL I see (goal robot 100) and for OneStep I see (goal black 90) and (goal white 90) so I have a choice depending on my role.
The obvious thing to do from there is translate the GDL Lisp to ASP/Prolog format and then find a solution to (goal robot 100). I know this is discussed in the text with a first step of grounding everything and ASP is NP-complete in general but maybe we can get lucky and work on the rules directly without grounding them or time-stepping them. Worth a shot. Consider the rules for OneStep and suppose I am white. Let's try to work backwards by hand.
First, here is the full rule set:
(role white)
(role black)
(init o1)
(legal white a)
(legal white b)
(legal black a)
(<= (next o2)(does white a)(true o1))
(<= (next o3) (does white b)(true o1))
(<= (goal white 0) (true o1))
(<= (goal white 10) (true o2))
(<= (goal white 90) (true o3))
(<= (goal black 0) (true o1))
(<= (goal black 90) (true o2))
(<= (goal black 10) (true o3))
(<= terminal (true o2))
(<= terminal (true o3))
I know I don't care about any goal but (goal white 90), so I can discard these rules from the description:
(<= (goal white 0) (true o1))
(<= (goal white 10) (true o2))
(<= (goal black 0) (true o1))
(<= (goal black 90) (true o2))
(<= (goal black 10) (true o3))
That leaves me with a reduced rule set:
(role white)
(role black)
(init o1)
(legal white a)
(legal white b)
(legal black a)
(<= (next o2)(does white a)(true o1))
(<= (next o3) (does white b)(true o1))
(<= (goal white 90) (true o3))
(<= terminal (true o2))
(<= terminal (true o3))
I'm going to assume that role and terminal are formalities so I drop those rules as well giving:
(init o1)
(legal white a)
(legal white b)
(legal black a)
(<= (next o2)(does white a)(true o1))
(<= (next o3) (does white b)(true o1))
(<= (goal white 90) (true o3))
Now by hand I can reason as follows:
(goal white 90) requires (true o3)
(true o3) requires (does white b)(true o1)
(true o1) is satisfied by (init 01)
(does white b) is satisfied by (legal white b)
So (does white b) in step 1 is the solution. This seems like something an ASP engine could derive, with an input something like
goal(white,90,0):=true(o3,-1)
true(03,-1):= does(white,b,-2) && true(o1,-2)
CMODELS seems to be applicable, will look at this more tomorrow.
The obvious thing to do from there is translate the GDL Lisp to ASP/Prolog format and then find a solution to (goal robot 100). I know this is discussed in the text with a first step of grounding everything and ASP is NP-complete in general but maybe we can get lucky and work on the rules directly without grounding them or time-stepping them. Worth a shot. Consider the rules for OneStep and suppose I am white. Let's try to work backwards by hand.
First, here is the full rule set:
(role white)
(role black)
(init o1)
(legal white a)
(legal white b)
(legal black a)
(<= (next o2)(does white a)(true o1))
(<= (next o3) (does white b)(true o1))
(<= (goal white 0) (true o1))
(<= (goal white 10) (true o2))
(<= (goal white 90) (true o3))
(<= (goal black 0) (true o1))
(<= (goal black 90) (true o2))
(<= (goal black 10) (true o3))
(<= terminal (true o2))
(<= terminal (true o3))
I know I don't care about any goal but (goal white 90), so I can discard these rules from the description:
(<= (goal white 0) (true o1))
(<= (goal white 10) (true o2))
(<= (goal black 0) (true o1))
(<= (goal black 90) (true o2))
(<= (goal black 10) (true o3))
That leaves me with a reduced rule set:
(role white)
(role black)
(init o1)
(legal white a)
(legal white b)
(legal black a)
(<= (next o2)(does white a)(true o1))
(<= (next o3) (does white b)(true o1))
(<= (goal white 90) (true o3))
(<= terminal (true o2))
(<= terminal (true o3))
I'm going to assume that role and terminal are formalities so I drop those rules as well giving:
(init o1)
(legal white a)
(legal white b)
(legal black a)
(<= (next o2)(does white a)(true o1))
(<= (next o3) (does white b)(true o1))
(<= (goal white 90) (true o3))
Now by hand I can reason as follows:
(goal white 90) requires (true o3)
(true o3) requires (does white b)(true o1)
(true o1) is satisfied by (init 01)
(does white b) is satisfied by (legal white b)
So (does white b) in step 1 is the solution. This seems like something an ASP engine could derive, with an input something like
goal(white,90,0):=true(o3,-1)
true(03,-1):= does(white,b,-2) && true(o1,-2)
CMODELS seems to be applicable, will look at this more tomorrow.