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”, “Arabidopsis[ORGN] AND topoisomerase[TITL] AND 0:3000[SLEN]”); DB db = bio_db_genbank_new(); Stream stream = get_stream_by_query(db, q); SeqIO seqio = bio_seqio_new(“>sequence.fasta”, “fasta”); Seq seq = next_seq(stream); write_seq(seqio, seq); 5 data types 6 procedure calls

4. A Library Designer’s Problem • “Everything should be made as simple as possible, but not simpler” • Create useful fundamental building blocks • Don’t include redundant ones, eventhough they might be convenient • Library user is expected to compose sequences of “fundamental” calls

5. A Library User’s Problem • Novice users don’t 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 • World is composed of objects • Actions modify objects' properties and relationships • Planner deals with a symbolic model Operators Planner Plan Actions Initial State Goal State Plan User World A Domain-Independent Planner A Domain-Dependent Planner

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 B C 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. (Planner’s Input) These are actions. (Planner’s Output) These are properties. (Planner’s 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”, “Arabidopsis[ORGN] AND topoisomerase[TITL] AND 0:3000[SLEN]”); DB db = bio_db_genbank_new(); Stream stream = get_stream_by_query(db, q); SeqIO seqio = bio_seqio_new(“>sequence.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) => { 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”, “Arabidopsis[ORGN] AND opoisomerase[TITL] AND 0:3000[SLEN]”, “>sequence.fasta”, “fasta”); 1 data type, 1 AA call

19. DIPACS Plan • Domain Independent Planned Algorithm Composition and Selection Procedure Specifications Domain-Specific Library Operators DIPACS Planner DIPACS Compiler Goal State Initial State Application Code C or C++ Code Run-Time Program State (World) Binary (Actions) gcc 00101010 01000010

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 AA’s 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 AA’s call point y = sort(x) y = sort(x) sorted(y) sorted(y) sorted(y) sorted(y) ... ... ... y[0] = 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 sort is an AA int[] a, b, c; ... a = sort(a); c = sort(b); ... ... = a; ... = b; 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 int[]nondestructive_sort( int[] array ) => { 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 ) => { sorted( result ), permutaion( result, x ) } algorithm stable_sort( y ) => { 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@ - int_array) :effect (and (sorted ?array@) (permutaion ?array@ ?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 • π 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 that’s executable in the current state, then go forward on the current search path as far as possible, executing actions and appending them to π

34. Evaluation • Multiple plans require “interactive compilation” • cache to store previous decisions algorithmdummy(); 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?