Using AI Planning to Implement Algorithm Composition

1
Using AI Planning to Implement Algorithm
Composition

• Context Sensitive Domain-Independent Algorithm
  Composition and Selection.Troy A. Johnson and
  Rudolf EigenmannPurdue University

2
Motivation

• Increasing programmer productivity
• Typical language approach increase abstraction
• abstract away from machine get closer to problem
• do more using less code
• reduce software development maintenance costs
• Domain-specific languages / libraries (DSLs)
  provide high level of abstraction
• e.g., domains are biology, chemistry, physics,
  etc.

3
A Common BioPerl Call Sequence

• Query a remote database and save the result to
  local storage

Query q bio_db_query_genbank_new(nucleotide,
ArabidopsisORGN AND topoisomeraseTITL
AND 03000SLEN) DB db
bio_db_genbank_new() Stream stream
get_stream_by_query(db, q) SeqIO seqio
bio_seqio_new(gtsequence.fasta, fasta) Seq
seq next_seq(stream) write_seq(seqio, seq)
5 data types 6 procedure calls
4
A Library Designers Problem

• Everything should be made as simple as
  possible, but not simpler
• Create useful fundamental building blocks
• Dont include redundant ones, eventhough they
  might be convenient
• Library user is expected to compose sequences of
  fundamental calls

5
A Library Users Problem

• Novice users dont know these call sequences
• procedures documented independently
• tutorials provide some example code fragments
• not an exhaustive list
• may need adjusted for calling context (no copy
  paste)
• User knows what they want to do, but not how to
  do it

6
Bridging the Gap

• Build (semi) automatic tools to help users
  specify what they want and get what they need.

7
Agenda

• A brief introduction to Automated Planning
• Algorithm Composition Using Planning
• Mapping composition to planning
• DIPACS
• Language, compiler and planner
• Limitations
• Where do we go from here?

8
Simplified View of Planning
Planner
Plan
Actions
Initial State
Goal State
Plan User
World
A Domain-Dependent Planner
A Domain-Independent Planner

• World is composed of objects
• Actions modify objects' properties and
  relationships
• Planner deals with a symbolic model

9
Traditional Planning Example

• Planners are not normally applied to software
  they traditionally solve problems like this

A
Actions in the plan modify a world of blocks
A
B
C
B
C
Initial state on(B, table)on(C, table)on(A,
C)
Goal state on(C, table) on(B, C) on(A, B)
Plan
move(A, table) move(B, C) move(A, B)
These are properties. (Planners Input)
These are actions. (Planners Output)
These are properties. (Planners Input)
10
Classical Representation

• The world is represented as states
• States are represented as a set of logical atoms
• Operators define a state-transition system
• precondition when an operator can be used
• effects what an operator does
• Planner finds a path through the system from the
  initial state to the goal state

11
Why Planning Is Difficult

• Too many states to enumerate
• Search intelligently using reasonable time
  space
• Danger that planner may not terminate

12
Simple Planning Algorithms

• Forward Search
• Start at the initial state and advance using the
  operators until you reach the goal
• Backward Search
• Start at the goal state and apply the inverse of
  the operators
• STRIPS

13
To Solve Composition Using Planning

• Initial state Calling context
• compiler analysis
• Goal state Abstract Algorithm
• user
• Operators Procedure specifications
• library author
• Actions Procedure calls
• World Program state

14
Is Planning Necessary For Composition

• Many possible actions
• libraries contain 10s 100s procedures
  (operators)
• each procedure has several parameters
• many live variables (objects) at a call site
• many ways to bind variables to parameters
• Ex 128 procs, 2 params each, 8 objs, 4 calls
• assume all objects params have the same type
• (128 82)4 252 potential plans

15
The Planning Solution

• Add an abstract algorithm (AA) construct to
  the programming language
• An AA is named and defined by the programmer
• definition is the programmer's goal
• An AA is called like a procedure
• compiler replaces the call with a sequence of
  library calls
• How does the compiler compose the sequence?
• it uses a domain-independent planner

16
BioPerl Call Sequence Revisited

• Query a remote database and save the result to
  local storage

Query q bio_db_query_genbank_new(nucleotide,
ArabidopsisORGN AND topoisomeraseTITL
AND 03000SLEN) DB db
bio_db_genbank_new() Stream stream
get_stream_by_query(db, q) SeqIO seqio
bio_seqio_new(gtsequence.fasta, fasta) Seq
seq next_seq(stream) write_seq(seqio, seq)
17
Defining and Calling an AA

• AA (goal) defined using the glossary...

algorithm save_query_result_locally(db_name,
query_string, filename,
format) gt query_result(result, db_name,
query_string), contains(filename,
result), in_format(filename, format)
18
Defining and Calling an AA

• ...and called like a procedure

Seq seq save_query_result_locally(
nucleotide, ArabidopsisORGN AND
opoisomeraseTITL AND 03000SLEN,
gtsequence.fasta, fasta)
1 data type, 1 AA call
19
DIPACS

• Domain Independent Planned Algorithm Composition
  and Selection

20
Challenges

• Ontological engineering
• Choosing a vocabulary for the domain
• Determine initial and goal states
• Object creation
• most planners assume a fixed set of objects
• Merging of plan and program

21
Ontological Engineering

• Glossary of abstractions for describing the
  preconditions and effect of library routines
• e.g. sorted(x), permutation(x, y), contains(a, b)
• not precise semantics
• Library author and user understand the properties
• via prior familiarity with the domain
• via the glossary

22
Ontological Engineering

• The compiler propagates terms during analysis
• meaning of properties does not matter
• The planner matches properties to goals
• meaning of properties does not matter

23
Determining Initial and Goal States

• Determine variables at AAs call point

int a, b, c ... a b c AA(...) (objects
a b c int (init (equals a b))
24
Determining Initial and Goal States

• Discover properties at the AAs call point

y sort(x)
y sort(x)
sorted(y)
sorted(y)
sorted(y)
sorted(y)
...
...
...
y0 1
sorted(y)
sorted(y)
sorted(y)
z AA(y)
z AA(y)
(objects x y z int_array (init (sorted y))
(objects x y z int_array (init (sorted y))
25
Object Creation

• Classical planning
• The world consists of a static set of objects
• Operators never create new objects
• Extension to the programming world is needed
• Start with a large enough number of extra
  objects
• Create new objects on demand

26
Merging of Plan and Program

• Destructive vs. non-destructive call sequence
• The compiler choose based on live variables
  analysis

destructive
int a, b, c ... a sort(a) c
sort(b) ... ... a ... b
sort is an AA
non-destructive
1. destructive_sort(a) 2. a nondestructive_sort
(a)
int t b destructive_sort(t) c t
27
The Planning Language (Librarian)

• Library procedures and their specifications
• Provided by the library programmer

procedure intnondestructive_sort( int array
) gt sorted (result) ,permutation(result,
array) time pow(array.length , 2) space 2
array.length / implementation /
28
The Planning Language (User)

• Defining Abstract Algorithms

algorithm sort( x ) gt sorted( result ),
permutaion( result, x ) algorithm stable_sort(
y ) gt sort(y), stable( result, y )
29
The Planning Language (Compiler)

• Generates extended PDDL
• Lisp-like syntax

( define (problem sort) ( objects input_array
- int_array) ( goal ( exists (?result -
int_array) ( and (sorted ?result)
(permutation ?result
input_array)))))
30
The Planning Language (Compiler)

• Generates extended PDDL
• Object creation non standard create

(action next_seq parameters (?stream -
Stream) creates (?result - Seq) effect
(forall (?q Query) (when (
stream_for_query ?stream ?q )
(query_result ?result ?q.db ?q.query)))) (action
insertion_sort parameters (?array -
int_array) creates (?array_at_ - int_array)
effect (and (sorted ?array_at_)
(permutaion ?array_at_ ?array)))
31
The Planning Language (Compiler)

• Generates extended PDDL
• Non deterministic effects non standard either

(action isalpha parameters (?ch - char)
creates (?result - bool) effect (either
(and (?ch alpha) (equal ?result t))
(and (not (?ch alpha)) (equal ?result f))))
32
The Planner

• Call sequences are (relatively) short
• High Branching factor
• Exhaustive search is infeasible
• Could not find good heuristic for forward search
• Use a modified version of STRIPS
• allow for backtracking (multiple plans)

33
STRIPS

• p? the empty plan
• do a modified backward search from g
• instead of ?-1(s, a), each new set of subgoals is
  just precond(a)
• whenever you find an action thats executable in
  the current state, then go forward on the current
  search path as far as possible, executing actions
  and appending them to p

34
Evaluation
Abstract Algorithm create solutions time (ms)
1 dummy Seq 32 300
2 save_query_result_locally Seq 1 3270
3 sort int 2 800
4 sort float 0 30

• Multiple plans require interactive compilation
• cache to store previous decisions

algorithm dummy() Seq s dummy()
35
Where Do We Go From Here?

• DIPACS is a proof of concept. Can we take the
  concept to the next level?
• language features loops, exceptions, OO
• scalability
• using existing libraries
• automatic inference of effects
• Different planning algorithm
• plans with branches
• forward search

36
Questions?