Transcript META-INTERPRETERS AND META

META-INTERPRETERS AND
META-PROGRAMMING
Ivan Bratko
Faculty of Computer and Info. Sc.
Univ. of Ljubljana
BASIC META-INTERPRETER
% The basic Prolog meta-interpreter
prove( true).
prove( ( Goal1, Goal2)) :prove( Goal1),
prove( Goal2).
prove( Goal) :clause( Goal, Body),
prove( Body).
SIMPLE TRACING META-INTERPRETER
prove( true) :- !.
prove( ( Goal1, Goal2)) :- !,
prove( Goal1),
prove( Goal2).
prove( Goal) :write( 'Call: '), write( Goal), nl,
clause( Goal, Body),
prove( Body),
write( 'Exit: '), write( Goal), nl.
TRACING META-INTERPRETER WITH RETRY
% trace( Goal): execute Prolog goal Goal displaying trace information
trace( Goal) :trace( Goal, 0).
trace( true, Depth) :- !.
trace( ( Goal1, Goal2), Depth) :- !,
trace( Goal1, Depth),
trace( Goal2, Depth).
% Red cut; Dept = depth of call
% Red cut
trace( Goal, Depth) :display( 'Call: ', Goal, Depth),
clause( Goal, Body),
Depth1 is Depth + 1,
trace( Body, Depth1),
display( 'Exit: ', Goal, Depth),
display_redo( Goal, Depth).
trace( Goal, Depth) :display( 'Fail: ', Goal, Depth),
fail.
% All alternatives exhausted
display( Message, Goal, Depth) :tab( Depth), write( Message),
write( Goal), nl.
display_redo( Goal, Depth) :true
% First succeed simply
;
display( 'Redo: ', Goal, Depth), % Then announce backtracking
fail.
% Force backtracking
METAINTERPRETER FOR
PROLOG WITH CONSTRAINTS
solve( Goal) :solve( Goal, [ ], Constr).
% Start with empty constr.
% solve( Goal, InputConstraints, OutputConstraints)
solve( true, Constr0, Constr0).
solve( (G1, G2), Constr0, Constr) :solve( G1, Constr0, Constr1),
solve( G2, Constr1, Constr).
METAINTERPRETER CTD.
solve( G, Constr0, Constr) :prolog_goal( G),
% G a Prolog goal
clause( G, Body),
% A clause about G
solve( Body, Constr0, Constr).
solve( G, Constr0, Constr) :constraint_goal( G),
% G a constraint
merge_constraints( Constr0, G, Constr).
MERGE CONSTRAINTS
 Predicate merge_constraints:
constraint-specific problem solver,
merges old and new constraints,
tries to satisfy or simplify them
 For example, two constraints X  3 and X  2 are simplified into
constraint X  2.
GENERATING PROOF TREES
% Prolog meta-interpreter that generates a proof tree
:- op( 500, xfy, <== ).
% prove( Goal, ProofTree)
prove( true, true) :- !.
prove( ( Goal1, Goal2), (Proof1, Proof2)) :- !,
prove( Goal1, Proof1),
prove( Goal2, Proof2).
prove( Goal, Goal <== Proof) :clause( Goal, Body),
prove( Body, Proof).
EXPLANATION-BASED GENERALISATION
 EBG = Machine learning from one example only!
 Lack of examples compensated by domain theory
 Given:
 Domain theory (can answer any question)
 Operationality criteria
 Training example
 Find:
 Generalisation of training example +
 Operational definition of target concept (in terms of operational
predicates)
 Note: EBG can be viewed as a program compilation technique
 Inefficient program (domain theory)  Efficient specialised program
A DOMAIN THEORY ABOUT GIFTS
% Figure 23.3 Two problem definitions for explanation-based
generalization.
% For compatibility with some Prologs the following predicates
% are defined as dynamic:
:- dynamic gives/3, would_please/2, would_comfort/2,
feels_sorry_for/2, likes/2, needs/2, sad/1,
go/3, move/2, move_list/2.
% A domain theory: about gifts
gives( Person1, Person2, Gift) :likes( Person1, Person2),
would_please( Gift, Person2).
gives( Person1, Person2, Gift) :feels_sorry_for( Person1, Person2),
would_comfort( Gift, Person2).
would_please( Gift, Person) :needs( Person, Gift).
would_comfort( Gift, Person) :likes( Person, Gift).
feels_sorry_for( Person1, Person2) :likes( Person1, Person2),
sad( Person2).
feels_sorry_for( Person, Person) :sad( Person).
% Operational predicates
operational( likes( _, _)).
operational( needs( _, _)).
operational( sad( _)).
% An example situation
likes( john, annie).
likes( annie, john).
likes( john, chocolate).
needs( annie, tennis_racket).
sad( john).
THEORY ABOUT LIFTS
% Another domain theory: about lift movement
% go( Level, GoalLevel, Moves) if
% list of moves Moves brings lift from Level to GoalLevel
go( Level, GoalLevel, Moves) :move_list( Moves, Distance),
Distance =:= GoalLevel - Level.
% A move list and distance travelled
move_list( [], 0).
move_list( [Move1 | Moves], Distance + Distance1) :move_list( Moves, Distance),
move( Move1, Distance1).
move( up, 1).
move( down, -1).
operational( A =:= B).
LIFTS
% Another domain theory: about lift movement
% go( Level, GoalLevel, Moves) if
% list of moves Moves brings lift from Level to GoalLevel
go( Level, GoalLevel, Moves) :move_list( Moves, Distance),
Distance =:= GoalLevel - Level.
% A move list and distance travelled
move_list( [], 0).
move_list( [Move1 | Moves], Distance + Distance1) :move_list( Moves, Distance),
move( Move1, Distance1).
move( up, 1).
move( down, -1).
operational( A =:= B).
GIFTS THEORY
gives( P1, P2, G)
likes(P1,P2)
would_please(G,P2)
feels_sorry_for(P1,P2)
would_comfort(G,P2)
P1=P2
needs( P2, G)
likes(P1,P2)
sad(P2)
sad(P1)
likes(P,G)
Training example
gives(john,john,chocolate)
gives( P1, P2, G)
likes(P1,P2)
would_please(G,P2)
feels_sorry_for(P1,P2)
would_comfort(G,P2)
P1=P2
needs( P2, G)
likes(P1,P2)
sad(P2)
sad(P1)
likes(P,G)
EBG AS PROLOG META-INTERPRETER
% ebg( Goal, GeneralizedGoal, SufficientCondition) if
% SufficientCondition in terms of operational predicates
% guarantees that generalization of Goal, GeneralizedGoal, is true.
% GeneralizedGoal must not be a variable
EBG, CTD.
ebg( true, true, true) :- !.
ebg( Goal, GenGoal, GenGoal) :operational( GenGoal),
call( Goal).
ebg( (Goal1,Goal2), (Gen1,Gen2), Cond) :- !,
ebg( Goal1, Gen1, Cond1),
ebg( Goal2, Gen2, Cond2),
and( Cond1, Cond2, Cond).
% Cond = (Cond1,Cond2) simplified
ebg( Goal, GenGoal, Cond) :not operational( Goal),
clause( GenGoal, GenBody),
copy_term( (GenGoal,GenBody), (Goal,Body)),
ebg( Body, GenBody, Cond).
% Fresh copy of
% (GenGoal,GenBody)
EBG, CTD.
% and( Cond1, Cond2, Cond) if
% Cond is (possibly simplified) conjunction of Cond1 and Cond2
and( true, Cond, Cond) :- !.
% (true and Cond) <==> Cond
and( Cond, true, Cond) :- !.
% (Cond and true) <==> Cond
and( Cond1, Cond2, ( Cond1, Cond2)).
WHY:
copy_term( (GenGoal,GenBody), (Goal,Body))
 Proofs of Goal and GenGoal follow the same structure
 They both must use the same program clause:
GenGoal :- GenBody.
 This is checked by matching:
(Goal :- Body) = (GenGoal :- GenBody)
 But, this check must be done without changing GenBody
 Therefore: copy_term( (GG,GB), ...) produces a copy (GG’,GB’), and
this is matched: (GG’,GB’) = (Goal,Body)
EXPLANATION-BASED GENERALISATION
 What is the logical relation between generalised goal GENGOAL
and derived operational condition COND?
 What is the role of the example in EBG?
 What is the difference between EBG and goal unfolding?
ABDUCTIVE REASONING
 Types of logical reasoning:
 deduction
 induction
 abduction
 Abduction useful for explanation, construction, planning, e.g.:
 patient’s symptoms
 systems failures
 Disease D causes symptom S; patient P has symptom S;
 So, infer that P has D
 Abduction considered as unsound rule of inference
FORMALLY
 Given a Theory and an Observation
 Find an Explanation, such that
Theory & Explanation |== Observation
 Compare with definition of ILP: given BK and Examples, find
Hypothesis such that:
BK & Hypothesis |-- Examples
 Discuss differences between abductive and inductive reasoning
% An example from Missiaen, Bruynooghe, Denecker 92
:- dynamic faulty/1, lamp/1, current_break/1. % Needed in SICStus by clause/2
faulty( L) :lamp( L),
broken( L).
% Device L faulty - doesn't work
% Device is a lamp
% Lamp broken
faulty( L) :lamp( L),
current_break( L).
% No electric current in lamp
current_break( L) :fuse( L, F),
% Fuse F connected to lamp L
melted( F).
% Fuse F is melted
current_break( L) :general_power_failure.
lamp( a).
lamp( b).
abducible( broken( Device)).
abducible( melted( Fuse)).
abducible( fuse( Device, Fuse)).
abducible( general_power_failure).
ABDUCING METAINTERPRETER
% abduce( Goal, Delta): Delta is a list of abduced literals
abduce( Goal, Delta) :abduce( Goal, [ ], Delta).
% abduce( Goal, Delta0, Delta):
% Delta 0 is "accumulator" variable with Delta as its final value
abduce( true, Delta, Delta) :- !.
abduce( ( Goal1, Goal2), Delta0, Delta) :- !,
abduce( Goal1, Delta0, Delta1),
abduce( Goal2, Delta1, Delta).
abduce( Goal, Delta0, Delta) :clause( Goal, Body),
abduce( Body, Delta0, Delta).
ABDUCING METAINTERPRETER, CTD.
% Now abduction reasoning steps:
abduce( Goal, Delta, Delta) :member( Goal, Delta).
% Already abduced
abduce( Goal, Delta, [Goal | Delta]) :abducible( Goal),
retract( index( I)), !,
% Lowest free index for new constants
numbervars( Goal, I, J), % Replace variables by Skolem constants
asserta( index( J)).
% Next free index
ABDUCTION, AUX. PREDICATES
:- dynamic index/1.
index( 1).
member( X, [X | L]).
member( X, [Y | L]) :member( X, L).
ABDUCTION, AUX. PREDICATES
USUALLY PROLOG BUILT-IN
numbervars( Term, N0, N) :var( Term), !,
Term = var/N0,
N is N0 + 1
;
atomic( Term), !,
N = N0
;
Term =.. [Fun | Args],
numberargs( Args, N0, N).
numberargs( [], N, N).
numberargs( [ Arg | Args], N0, N) :numbervars( Arg, N0, N1),
numberargs( Args, N1, N).
PATTERN-DIRECTED SYSTEMS
 Set of program modules executed in parallel
 Module’s execution triggered by patterns in their data environment
Data environment
 Similar to Blackboard Systems
EXAMPLE
 Greatest common divisor D of A and B:
while A and B not equal, do
if A > B replace A := A - B else replace B := B - A
D = A (or B)
 Pattern directed modules
ConditionPart ---> ActionPart
[ Cond1, Cond2, ...] ---> [ Action1, Action2, ...]
PATTERN-DIRECTED PROGRAM FOR GCD
:- op( 800, xfx, --->).
:- op( 300, fx, num).
[ num X, num Y, X > Y ] --->
[ NewX is X - Y, replace( num X, num NewX) ].
[ num X] ---> [ write( X), stop ].
% An initial database
num 25.
num 10.
num 15.
num 30.
TRACE OF THIS PROGRAM
 Data environment initially contains:
25
10
15
30
Trace execution here
 Program works for any number of numbers!
% A small interpreter for pattern-directed programs
% The system's database is manipulated through assert/retract
:- op( 800, xfx, --->).
% run: execute production rules of the form
%
Condition ---> Action until action `stop' is triggered
run :Condition ---> Action,
test( Condition),
execute( Action).
% A production rule
% Precondition satisfied?
% test( [ Condition1, Condition2, ...]) if all conditions true
test( []).
% Empty condition
test( [First|Rest]) :call( First),
test( Rest).
% Test conjunctive condition
% execute( [ Action1, Action2, ...]): execute list of actions
execute( [ stop]) :- !.
execute( []) :run.
% Stop execution
% Empty action (execution cycle completed)
% Continue with next execution cycle
execute( [First | Rest]) :call( First),
execute( Rest).
replace( A, B) :retract( A), !,
assert( B).
% Replace A with B in database
% Retract once only