Using AI Planning to Implement Algorithm Composition

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

1

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.

2

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

A Common BioPerl Call Sequence

3

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, even

though they might be convenient

Library user is expected to compose sequences of “fundamental” calls

4

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

5

Bridging the Gap

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

6

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?

7

PlannerInitial State

Goal State

Plan Actions

Plan User World

World is composed of objects Actions modify objects' properties and

relationships Planner deals with a symbolic model

A Domain-Dependent Planner

Simplified View of Planning

Operators

A Domain-Independent Planner

8

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

Traditional Planning Example

Initial state

on(B, table)on(C, table)on(A, C)

CB

A

Goal state

on(C, table)on(B, C)on(A, B)

C

B

A

These are properties.)Planner’s Input(

These are actions.)Planner’s Output(

These are properties.)Planner’s Input(

Planmove(A, table)move(B, C)move(A, B)

Actions in the planmodify a “world”of blocks

9

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

10

Why Planning Is Difficult

Too many states to enumerate Search intelligently using reasonable time &

space Danger that planner may not terminate

11

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

12

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

13

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

14

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

15

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);

BioPerl Call Sequence Revisited

16

Defining and Calling an AA

AA (goal) defined using the glossary...

algorithmsave_query_result_locally(db_name, query_string, filename, format) => { query_result(result, db_name, query_string), contains(filename, result), in_format(filename, format) }

17

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

18

DIPACS

Domain Independent Planned Algorithm Composition and Selection

Operators

Application Code

DIPACSPlanner

Domain-SpecificLibrary

ProcedureSpecifications

Initial State

Goal State

Plan

gcc

C or C++ Code

Binary (Actions)

0010101001000010

Run-TimeProgram State

(World)

DIPACSCompiler

19

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

20

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

21

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

22

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))

int a, b, c;...a = b;c = AA(...);

(:objects a b c – int(:init (equals a b))

23

Discover properties at the AA’s call point

Determining Initial and Goal States

(:objects x y z – int_array(:init (sorted y))

sorted(y)sorted(y)

sorted(y)sorted(y)

(:objects x y z – int_array(:init (sorted y))

sorted(y)sorted(y)

sorted(y)

y = sort(x)y = sort(x)

z = AA(y)z = AA(y)

...... ......

y = sort(x)y = sort(x)

z = AA(y)z = AA(y)

...... y[0] = 1y[0] = 1

24

Object Creation

Classical planning The world consists of a static set of objects Operators never create new objects

Extension to the programming world is needed1. Start with a “large enough” number of extra

objects

2. Create new objects on demand

25

Merging of Plan and Program Destructive vs. non-destructive call sequence The compiler choose based on live variables

analysis

int[] a, b, c;...a = sort(a);c = sort(b);...... = a;... = b;

sort is an AAdestructive

non-destructive

1. destructive_sort(a);2. a = nondestructive_sort(a);

int t[] = b;destructive_sort(t);c = t;

26

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 */ }

27

The Planning Language (User) Defining Abstract Algorithms

algorithm sort( x ) => { sorted( result ), permutaion( result, x ) }

algorithm stable_sort( y ) => { sort(y), stable( result, y ) }

28

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)))))

29

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)))

30

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))))

The Planning Language (Compiler)

31

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)

32

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 π

33

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

34

algorithm dummy();

Seq s = dummy();

algorithm dummy();

Seq s = dummy();

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

35

Questions?

36