Using Automatic Memoization as a

Software Engineering To ol in

RealWorld AI Systems

James Mayeld Marty Hall

Computer Science Department Science Applications International Corp

University of Maryland Baltimore County Broken Land Parkway Suite

Baltimore MD Columbia MD

mayeldcsumb cedu hallcsumb cedu

Tim Finin

Computer Science Department

University of Maryland Baltimore County

Baltimore MD

nincsumb cedu

April

Abstract

Memo functions and memoization are well known concepts in AI programming They have b een dis

cussed since the Sixties and are often used as examples in intro ductory programming texts However the

automation of memoization as a practical software engineering to ol for AI systems has never received a

detailed treatment This pap er describ es how automatic memoization can b e made viable on a large scale

It p oints out advantages and uses of automatic memoization not previously describ ed describ es the com

p onents of an automatic memoization facility enumerates p otential memoization failures and presents

a publicly available memoization package CLAMP for the Lisp programming language Exp erience in

applying these techniques in the development of a large planning system are briey discussed

Track Enabling Technology

Subtrack Software Engineering

Words

Corresp ondence Please address all corresp ondence to James Mayeld Computer Science Department

University of Maryland Baltimore County Baltimore MD Voice Fax

Email mayeldcsumb cedu

Intro duction

Memo functions and memoization are well known concepts in AI programming They have b een discussed

since the Sixties and are often used as examples in intro ductory programming texts However

the automation of memoization as a practical software engineering to ol for AI systems has never received

a detailed treatment This pap er describ es how automatic memoization can b e made viable on a large

scale It p oints out advantages and uses of automatic memoization not previously describ ed itemizes the

comp onents of an automatic memoization facility enumerates p otential memoization failures and presents

a publicly available memoization package CLAMPCommon Lisp Automatic Memoization Package for

1

the Lisp programming language We will also briey discuss our exp erience in applying these techniques in

the development of the Signature Management System SMS a decision supp ort system that provides

submarine crews with situational awareness and op erational advice in order to reduce detectability

The term memoization is derived from the term memo function which was coined by David Michie

It refers to the tabulation of the results of a set of calculations to avoid rep eating those calculations Auto

matic memoization refers to a metho d by which an ordinary function can b e changed mechanically into one

that memoizes or caches its results We place the decision ab out which functions to memoize in the hands

of the user this contrasts with the approach of Mostow and Cohen which tries to automatically infer

which functions should b e memoized These two approaches to automatic memoization are not incompatible

although as Mostow and Cohen p oint out the latter approach is not a practical to ol

Memoization is particularly apt for AI applications Rapid prototyping is a hallmark of AI programming

Automatic memoization allows the programmer to write certain functions without regard to eciency while

b eing assured of reasonable p erformance By allowing the programmer to avoide these eciency concerns at

the outset automatic memoization facilitates the kind of exploratory programming used in the development

of most AI systems

The principle of memoization and examples of its use in areas as varied as logic programming

functional programming and natural language parsing have b een describ ed in the literature In

all of the cases that we have reviewed the use of memoization was either built into in a sp ecial purp ose

1

Throughout this pap er we use the name Lisp to refer to the language Common Lisp as describ ed in Steele

computing engine eg for rulebased deduction or CFG parsing or treated in a cursory way as an example

rather than taken seriously as a practical technique The automation of function memoization as a practical

software engineering technique under human control has never received a detailed treatment In this pap er

we rep ort on our exp erience in developing CLAMP a practical automatic memoization package for Common

Lisp and its use in a largescale AI pro ject

By means of illustration consider the divideddierence algorithm dd which is shown in pseudoco de in

Figure This algorithm is used to determine co ecients of interp olated p olynomials The algorithm which

is a standard one in numerical metho ds is taken directly from Numerical Mathematics and Computing

The application itself is not particularly imp ortant it is the runtime b ehavior of the algorithm that is

of interest to us here The call tree for the divided dierence algorithm dd forms a network rather than

a tree thus a recursive call to dd with particular arguments may b e rep eated many times during a single

computation For example a call to dd with low and high will generate one recursive call with low

and high and another recursive call with low and high each of these will in turn make a recursive

call with low and high Memoization of dd causes each calculation to b e p erformed only once and

stored in a table thereafter each rep eated recursive call is replaced by a table lo okup of the appropriate

value

Figure compares the p erformance of memoized and unmemoized versions of a Lisp implementation of

the divided dierence algorithm using f n cosn and the rst n natural numb ers as arguments Since

a single function call on n p oints generates two recursive calls on n p oints the unmemoized version has

n 2

time complexity After memoization the rst invo cation requires n time since no subsequence

2

of p oints is calculated more than once and there are n n subsequences Subsequent invo cations take

nearconstant time

This algorithm for divided dierence is typical of a large class of algorithms which have very elegant

recursive denitions which are simply unusable for most real problems The conventional resp onse to this

situation is to manually rewrite the algorithm in a dynamic programming style Of course such manual

rewriting of the co de takes eort and involves the risk of intro ducing new bugs An attractive alternative

is to use an automatic memoization package to convert the elegant but inecient recursive algorithm into a

divideddifference algorithm

ddpoints array

low arrayindex

high arrayindex

fn function

begin

if low high then

return fnpointslow

else return ddpoints low high fn

ddpoints low high fn

pointshigh pointslow

end

Figure The divided dierence algorithm for determining co ecients of interp olated p olynomials can b e

elegantly written using recursion and made ecient through the use of automatic memoization

n Unmemoized Memoized Memoized

rst run subsequent runs

Centuries

Figure This table shows the b enets of memoization on a Lisp implementation of dd The time complexity

n 2

is reduced from to n for initial runs and to nearconstant time on subsequent ones

useful one This is attractive of course only if such a package can address the practical problems faced in

real application

In the next section we describ e the some of the asp ects and uses of automatic memoization not previously

describ ed in the literature Section three compares the use of automatic memoization to the alternative of

rewriting co de by hand Section four describ es the general comp onents that should b e present in any

automatic memoization facility Section ve presents problems inherent in the use of memoization and the

various ways to address them Section six describ es our exp erience in using automatic memoization in in

the development of SMSa large decision supp ort system

Uses of Memoization

There are four main uses of automatic memoization Two of these involve the avoidance of redundant

calculation rst within a single function invo cation and second across invo cations The third use of

automatic memoization is as a precalculation to ol while the fourth is as a timing and proling to ol These

are not conjectured uses but ones which we found to b e eective in many situations in a large realworld

AI application We discuss each of these uses in more detail in the following subsections

Rep etition within a Function Call

The most common use of memoization is to avoid the rep etition of subcalculations within a single function

call In the divided dierence example presented ab ove there were many rep eated recursive calls within a

single function invo cation This typ e of rep etition is common For example a simple recursive backtracking

parser may parse the same constituent many times during a single parse thus its p erformance is p o or

Norvig has shown that such an algorithm can obtain the p erformance of chart parsing or of Earleys

algorithm through the application of memoization

Thus we can view memoization as a technique to automatically convert a recursive algorithm into one

that has the same b ehavior as a dynamic programming algorithm rather than determining the prop er

order in which to construct subpieces memoization of a simple solution can typically achieve the same

p erformance Again through automatic memoization one can in many cases achieve the b enets of a

dynamic programming approach without rewriting the control structure or intro ducing new data structures

to hold the intermediate results

Rep etition over Time

In a team programming environment dierent sections of a system written by dierent programmers may

access the same function Alternatively in an interactive system the user may invoke calculations at dierent

times that make use of some the same pieces In these cases there is no central routine which could manage

the calling sequence to avoid rep etition of the calculations The only alternative to automatic memoization

in such cases is to have the routine in question manage its own data structures to cache previous results

Persistence

The preceding subsections showed that memoization can eliminate the rep eated invo cation of exp ensive

calculations These two applications of memoization are useful when it is feasible to p erform the rst

invo cation of a function at runtime Memoization is also useful when even the rst invo cation is to o

exp ensive to p erform at runtime

Use of functions that are to o exp ensive to calculate at runtime is usually done by building a sp ecial

purp ose data le and storing in it the results of an oline execution of the exp ensive routine Then

the function in question is mo died to access that le Automatic memoization provides a metho d to

precalculate a function without the overhead of a handcrafted solution In such situations automatic

memoization eliminates the need for the programmer to know which ranges of values are stored in the data

le and which must b e calculated To achieve p ersistence of an exp ensive function the function is memoized

and then run oline on the cases of interest The contents of the hash table are then saved to disk The

saved le is later used to seed the hash table for the function when it is reloaded

There are two additional advantages of this typ e of memoization b eyond providing the ability to pre

calculate a function First it allows the elimination of functions from the runtime system in cases where

all p ossible inputs to the memoized function are precalculated Second the input values to the memoized

function are determined automatically That is the programmer do es not have to sp ecify the range of

p ossible inputs to the memoized function In fact this solution works even if the programmer has no idea

which input values will b e used

Timing and Proling

Finally automatic memoization can also used as a proling and timing to ol Many programming language

systems provide a proling facility whereby the user can see the time that a toplevel function sp ends in

various lowerlevel routines This is imp ortant for directing optimization eorts However these prolers

generally require signicant overhead For example a fullymetered Lisp run on a Symb olics Lisp machine

can take thirty times longer than an unmetered run This do es not include the time required to load

the metering system The exp ense of metering is worth the eort for imp ortant cases and is a valuable

software engineering to ol In smaller cases however automatic memoization provides a quick but rough

metho d for determining which routines to optimize Rather than running the fully metered system users

interactively memoize certain functions then rep eat the original test case twice If the timing for the second

case improves only by for example ve p ercent then for that test case no amount of optimization in the

routines in question will provide more than a ve p ercent sp eedup If on the other hand a great sp eedup is

seen then the memoized functions are go o d candidates for optimization

Alternatives to Automatic Memoization

There are three alternatives to automatic memoization for eliminating rep eated calculation handcrafted

memoization dynamic programming and development of a new algorithm First memoization need not b e

automated Memoizing a routine by hand could conceivably result in minor eciency gains over automated

memoization Second in some cases an ordering can b e found for the calculations to b e p erformed such

that full memoization is not needed For example in Volume Seminumerical Algorithms of his The Art

of Computer Programming Knuth presents a straightforward metho d for calculating divided dierences

in the prop er order to get the same p erformance as the rst invo cation of the memoized version presented

in the Intro duction Finally a new algorithm for a given task can b e sought that do es not require rep eated

calculations

Automatic memoization is not a substitute for nding the prop er algorithm for a task However when

the ma jor b enet of the development of a new algorithm is a savings in rep eated calculations automatic

memoization of an existing algorithm has several advantages These advantages also recommend automatic

memoization over the other approaches describ ed ab ove They fall into three categories quality of solution

ease of use and additional uses of memoization

Quality of solution

Automatic memoization usually leads to short clear implementations b ecause the co de to implement the

eciency improvement do es not app ear in the b o dy of the function b eing improved Furthermore if the

function to b e memoized has already b een written and debugged the use of automatic memoization do es

not risk the intro duction of bugs into the function to the same degree that developing new co de for the task

do es This last p oint is esp ecially imp ortant in the development of large complex system where there is

a natural reluctance to change routines that have already b een tested and veried esp ecially if that will

require changes in multiple places in the co de Furthermore b ecause it is simple to switch back and forth

b etween the memoized and unmemoized versions it is easy to compare the p erformances of the two versions

Ease of use

In most languages automatic memoization can b e implemented so that it is simple to memoize and unmemoize

functions None of the alternatives to automatic memoization can b oast such a light load on the programmer

Again this ease of use dep ends in part on avoiding the requirement of writing debugging and eventually

maintaining new co de This ease of use is esp ecially imp ortant in articial intelligence applications b ecause

the design of such applications tends to change rapidly and frequently

Additional uses

While the alternatives to automatic memoization mentioned ab ove eliminate rep eated calculations they do

not in general provide the other b enets of automatic memoization ie p ersistence of cached values and

usefulness as a timing and proling to ol It would b e p ossible of course to build in some of these features

such as a p ersistent cache mechanism However the automatic memoization approach requires us to do this

only oncein the general memoization facility

The result of these b enets is that automatic memoization oers signicant practical advantages in

building real systems Hall and Mayeld describ e some of these advantages in more detail as they applied

to the development of the SMS system

Comp onents of an Automatic Memoization Facility

Based on our exp erience in developing and using CLAMP we have identied characteristics that any au

tomatic memoization facility should have Automated memoization of some sort can b e implemented in

most languages Languages that provide the user with an interactive runtime environment such as Lisp

Dylan and ML must have either runtime function name resolution or a patchable co de segment to allow

automated memoization Languages that are strictly compiled such as most implementations of C must

b e augmented with some sort of prepro cessor to allow automated memoization

Three typ es of control functions make up a useful memoization package memoization and unmemoization

functions cache control functions and statistics rep orting functions We will discuss each in turn

Memoization Control

First the system must provide the user with a variety of metho ds to easily memoize and unmemoize functions

These metho ds should allow b oth absolute control over memoization eg memoize a function unmemoize

a function unmemoize all functions and also if p ossible temp orary memoization commands eg treat

a function as memoized while evaluating a particular expression treat a function as unmemoized while

evaluating a particular expression

It is imp ortant to allow the programmer to exp eriment with the eects of memoization in the context of

his or her program It is not always obvious what impact memoizing a function will have For example at

rst glance the Hailstone function shown in Figure lo oks to b e a go o d candidate for memoization but

2

exp erimentation shows no b enets from doing so

2

Of course some careful reasoning will also lead a programmer to the same conclusion but not all programmers will have

defun Hailstone n

cond n

evenp n Hailstone n

t Hailstone n

Figure The Hailstone function app ears to b e a go o d candidate for memoization but it is not

Cache Control

Second the system must provide metho ds to control individual memoization caches b oth for a single session

and across sessions Most imp ortant is the ability to explicitly clear a cache thereby forcing all function

return values to b e recalculated Persistence is provided by allowing the user to instruct that a cache b e

saved to disk and in a later session to instruct that such a saved cache b e read from disk Ease of use

concerns dictate that these metho ds b e activated by referring to the name of the memoized function and

not to the name of a disk le or to some other internal data structure

Data Control

Finally the memoization package should provide routines that rep ort statistics collected while a memoized

function is running These statistics should include the numb er of times a memoized function is called and

the numb er of times that such invo cations result in the return of a cached value The user should also b e

allowed to reset these statistics in preparation for a new run

Memoization Failures

A ma jor advantage of automatic memoization is its transparency However an overlytransparent view can

lead to problems While some asp ects of these memoization failures have b een discussed in the literature

notably by Mostow and Cohen most have not Instead we learned them the hard way in using the

the time and exp erience to do this typ e of analysis

evolving CLAMP system through the exp eriences of AI programmers using the facility over the course of

several years in developing the SMS system

The most common criticism of automatic memoization that we hear from programmers who have not

used it is that the use of a technique that cannot guarantee correct results after its application is out of

the question This complaint is unfounded As a counterexample a technique that is widelyused by C

programmers is function inlining through macro expansion Such macro expansion is not guaranteed to

pro duce the correct results in all cases However b ecause the programmer controls when macros are applied

the technique can b e used protably It is for this reason that we advo cate programmer control over the

selection of functions for memoization In the following subsections we describ e the p otential pitfalls we

have encountered in making decisions ab out which functions to memoize

Cache Consistency

Memoization is used to avoid recalculation when a function is invoked with arguments it has seen previ

ously Direct changes to the function should result in the memoization cache b eing ushed automatically as

presumably it will then contain incorrect values This situation is relatively easy to detect More dicult

to detect is the alteration of one or more of the subfunctions that the memoized function calls There are

several ways to alleviate this problem The b est metho d would b e for each memoized function to keep a list

of all functions in its call tree and require that the cache b e ushed when any of those entries is mo died

This could not b e done automatically at runtime without the use of sp ecial data structures in the unmem

oized functions this capability is unlikely to b e adopted in most programs In many cases a prop er use of

mo dularity will indicate how far changes are likely to propagate Since the user always has access to a list of

the currently memoized functions a warning to check the list whenever changes are made is often sucient

This is a tradeo One of the goals of an automatic memoization facility is to provide to ols that are easy

for the programmer to adopt If using memoization requires invasive changes to unmemoized routines this

goal will b e compromised

However this problem is addressed within a single session it is usually not a problem across sessions

Runtime changes to functions usually o ccur during development If caches are not saved to disk the

memoized routines will once again calculate correct values the next time the system is loaded

Caches that are saved to disk present a much more serious problem In some senses such caches are

no dierent from normal data les and the same problems of outdated versions apply No fully automated

solution will guarantee consistency short of a system builder that forces recalculation of all saved values

whenever there are changes in any co de on which the function dep ends This is not an unreasonable option

during development since the memoization facility makes it easy to save entries Oline calculations can

b e p erformed at regular intervals However there is still an incentive to limit these calculations since their

timeconsuming nature is what led to saving the tables to disk in the rst place

One way to limit the likeliho o d of inadvertent use of obsolete values semiautomatically is to p erio dically

recalculate memoized values First the programmer sp ecies a p ercentage of the entries that are to b e

recalculated on loading the hash table andor a p ercentage of times where the memoized function will invoke

the original function even though its arguments have b een seen b efore In each case these recalculated values

are compared to the original ones a warning is given if the results are not identical Loadtime recalculation

may not b e p ossible of course since all the routines needed for a calculation may not b e available when the

function is dened Similarly runtime recalculation may not b e desirable even with a very low p ercentage

sp ecication if the system is counting on a given level of p erformance Even if b oth techniques are used

they do not guarantee that all obsolete values will b e found Thus these techniques should b e used as a

complement to other software engineering techniques such as explicit maintenance of dep endencies rather

than as a replacement for them

NonFunctions

Memoization only works for true functions not pro cedures That is if a functions result is not completely

and deterministically sp ecied by its input parameters using memoization will give incorrect results The

numb er of functions that can b e memoized successfully will b e increased by encouraging the use of a functional

programming style throughout the system

Mo dication of Results

Inherent in the idea of memoization is that data is stored rather than calculated anew each time a function

is called Thus memoized functions can return results that share structures even if the unmemoized version

always creates new structures Even without memoization op erations that mo dify function results are

dangerous from a software engineering p ersp ective A common problem is that such routines will work ne

when rst written but will make subsequent mo dications dicult However in some cases they can lead to

eciency gains with care programmers can use them to sp eed up the functions that can really b enet from

their use Unfortunately the transparent view of memoization breaks down when used with such routines

For instance supp ose that function RawData returns a newlycreated list of numb ers It is called by the

function NormalizedData which destructively removes the maximum and minimum entries from the list

b efore returning it Prior to memoization this might b e p erfectly safe After memoizing RawData however

each subsequent retrieval of supp osedly identical data values might in fact receive a shorter list Avoiding

this problem not only requires the user of memoization to know how the function to b e memoized works

but also how it will b e used by other functions This is often a dicult task an easier approach is to tighten

the standards on when mo difying op erations are allowed and to require increased do cumentation for those

functions that truly need to use them

Compiler Optimization of Recursive Calls

Some compilers will optimize the co de they output by converting tailrecursion to iteration Such optimiza

tion eliminates the recursive function call but not the work required to calculate the functions result Since

memoization relies on explicit function calls to activate its tablelo okup such optimization will bypass the

memoization pro cess To avoid this problem the compiler must b e instructed not to eliminate tailrecursion

in memoized routines Compilers that do optimize tailrecursion usually provide an appropriate compiler

directive for use by the memoization machinery

A more subtle optimization is sometimes made by compilers for languages that resolve function names

at runtime Such compilers will often bypass the name resolution pro cess for direct recursion When

memoization is implemented by binding the memoized function to the original function name this once

again results in a circumvention of the memoization tablelo okup The function will still return correct

results but the computation savings provided by memoization will b e lost It is less common for a compiler

3

to give the user explicit control over this kind of optimization

Note that this problem can eliminate some but not all of the advantages of memoization Although

the results of the optimizedaway recursive calls will not b e cached the results of the toplevel calls will b e

cached In the terms of the use categories describ ed in Section the b enets of repetition within a function

cal l are lost but those due to repetition over time are not

Recognizing Call Equivalence

Memoization is p erformed by doing an exact match on the argument list using the Lisp function equal by

default If function Foo is dened as

defun Foo key Bar Baz

and is memoized all of the following will b e treated as distinct even though the parameters have identical

values in all cases

Foo

Foo Bar

Foo Bar Baz

Foo Baz

Foo Baz Bar

Similarly one can have counterintuitive results when the arguments are oating p oint numb ers forgetting

that for instance is not equal to and is not equal to even though the function

may treat them as identical The solution adopted by the SMS program is to intro duce wrapp er functions

that take keyword arguments oating p oint numb ers etc canonicalize the arguments into some common

form then pass them on to an internal function that takes only required arguments in the standard format

It is this internal function that is then memoized

3

Common Lisp compilers have the notinline directive for this although we discovered in the course of developing CLAMP

that the commercial Common Lisp system we were using failed to follow that directive

Cache Value Representation

In the current system the routines that save data to disk do so by printing the representation of the ob ject

using format directing the output stream to a le This means that Lisp ob jects whose print representation

cannot b e parsed by read cannot b e saved to disk Some ob jects such as CLOS instances and structures

allow the denition of a custom print function and this can sometimes b e used to save them to disk But

this is not a general mechanism and sp ecialpurp ose co de will need to b e written in those cases

Exp erience and Evaluation

The Signature Management System SMS is a decision aid for submarine crews that provides situational

awareness and op erational advice to help the ship reduce its overall detectability It has b een develop ed

over the last ve years under ARPA funding at the Johns Hopkins University Applied Physics Lab oratory

JHUAPL Outside of APL team memb ers have come primarily from industry with eight corp orations

and two universities on the development team The system combines a variety of representations including

framesob jects pro duction rules mathematical mo dels and pro cedural co de Ab out is written in

Common Lisp with the remainder in C it runs on UNIX platforms

The automatic memoization system was used in the SMS program by at least six Lisp develop ers from

three dierent companies Permanent memoization ie uses other than proling remains in the re

leased system in places However use as a rstcut proling to ol was one of the most common uses of

memoization All four uses describ ed in Section were used extensively by multiple programmers

SMS Magnetics Mo dule

Figure gives timing statistics for a magnetics mo dule used in the Signature Management System timed

after various uses of memoization were put into eect Ignoring the b enets when the user asks for the same

display at dierent times which is in fact quite common Figure gives a summary of the time b enets of

memoization on the rst time invo cation of the toplevel display which is shown in Figure Times are in

seconds and are conservative approximations Similar results were obtained with other mo dules

asp ect Time sec Sp eedup

unmemoized original

conventional optimization

rep etitions over time

dynamic programming

saved lo okup tables

Figure These gures show the cumulative eects of the dierent asp ects of automatic memoization on a

magnetics mo dule used in the Signature Management System

SMS Detectability Planning Display

Given the diverse uses of memoization by various programmers on the SMS program we attempted to

estimate the overall contribution of memoization to the system For instance Figure shows a display

used as an aid to planning submarine op erations in the SMS system It shows the predicted probability of

detection of the submarine for various choices of heading and sp eed drawn on a p olar plot with the angle

theta indicating heading corresp onding to due north and the radius r corresp onding to sp eed Each

rtheta pair arc in the display is co ded with a color indicating the cumulative probability of detection for

the sub if it were to op erate at the indicated course and sp eed

This display is used as a highlevel to ol in planning and thus includes highly summarized information

It presents a single numb er for probability of detection which is a comp osite of all the p otential detection

metho ds or signatures The user frequently is interested in the contribution of individual signature com

p onents to this comp osite Since the probability of detection of each comp onent is memoized b efore it is

combined into the comp osite any comp onent corresp onding to a p oint on the display can b e retrieved almost

instantly Taking advantage of this the display of Figure can b e maintained with virtual ly no additional

computation

Whenever the user moves the mouse over the comp osite detectability display Figure the corresp onding

sp eed and course for the p oint under the mouse is calculated Then the individual comp onents are calculated

with their relative values shown in the bar charts Due to the eects of memoization the comp onent values

Figure The toplevel display from the SMS submarine planning system shows the predicted probability

of detection of the submarine for various choices of heading and sp eed drawn on a p olar plot with the angle

indicating heading and the radius corresp onding to sp eed Each arc is color co ded to indicate the cumulative

probability of detection for the sub if it were to op erate at the course and sp eed

can b e calculated and graphed as quickly as the user can move the mouse

The system was run from this display in the default mo de and then with all memoization turned o

The results given in Figure show a x improvement in sp eed and a x improvement in the amount

of temp orary memory garbage allo cated Benchmarks are notoriously misleading and in many places the

co de would have b een written dramatically dierently if memoization had not b een available Nevertheless

the results are illuminating esp ecially since they represent improvements over the original baseline system

Since the computation of this summary display represents the nal highlevel computation of the entire

system it is a reasonable way to measure the contribution of the use of automatic memoization

Conclusions

Automatic memoization is a p owerful to ol that allows many simple but inecient algorithms to b e made

useful in practice Beyond this basic advantage though automatic memoization provides other signicant

advantages to the articial intelligence programmer These advantages include the ability to add p ersistence

to a memoized function and the ability to p erform timing and proling studies rapidly These advantages

far outweigh the p otential pitfalls of automatic memoization in articial intelligence applications b ecause of

the prevalence of a rapid prototyping approach in such pro jects

Source co de for the CLAMP system is available via anonymous FTP ftpftpcsumb cedu or by email

via a request to hallcsumb cedu CLAMP is also available on the Internet Lisp archives at CMU and

Thinking Machines and is part of the CMU AI CDROM

Acknowledgements This work was supp orted in part by the Advanced Research Pro jects Agency under

JHUAPL sub contract L The authors thank VJ Benokraitis AAI Corp oration Lien T Duong

AAI Corp oration J Paul McNamee AAI Corp oration Peter Norvig Sun Microsystems and David J

Scheerer The Johns Hopkins Applied Physics Lab oratory for their helpful comments b oth on the LISP

implementation and on earlier versions of this pap er Thanks to John Aspinall Symb olics for suggesting

the use of the divideddifference example

Figure In the SMS system a bar chart shows the relative strength of each of the several comp onent

signatures which make up the overall probability of detection This comp onential analysis was trivial to

recover as a side eect of the decision to memoize the computation of the overall probability of detection

version time bytes consed

memoized sec

unmemoized sec

Figure Dramatic improvements in execution time and consing were obtained in the overall SMS system

References

Ward Cheney and David Kincaid Numerical Mathematics and Computing Bro oksCole

Thomas H Cormen Charles E Leiserson and Ronald L Rivest Introduction to Algorithms MIT

Press and McGraw Hill

SW Dietrich Extension tables Memo relations in logic programming In Fourth International Sym

posium on Logic Programming pages

J Earley An ecient contextfree parsing algorithm Communications of the Association for Computing

Machinery

Anthony J Field and Peter G Harrison Functional Programming AddisonWesley

Marty Hall and James Mayeld Improving the p erformance of AI software Payos and pitfalls in using

automatic memoization In Proceedings of the Sixth International Symposium on Articial Intel ligence

pages Megabyte Septemb er

B Homann Term rewriting with sharing and memoization In H Kirchner and G Levi editors

Algebraic and Logic Programming Proc of the Third International Conference pages Springer

Berlin Heidelb erg

M Kay Algorithm schemata and data structures in syntactic pro cessing In Proceedings of the Sympo

sium on Text Processing Nob el Academy

Donald E Knuth The Art of Computer Programming volume AddisonWesley

Donald Michie memo functions and machine learning Nature April

Jack Mostow and Donald Cohen Automating program sp eedup by deciding what to cache In Pro

ceedings of the Ninth International Joint Conference on Articial Intel ligence pages Morgan

Kaufmann Publishers Inc

Peter Norvig Techniques for automatic memoization with applications to contextfree parsing Com

putational Linguistics

Peter Norvig Paradigms of AI Programming Case Studies in Common LISP Morgan Kaufmann

F C N Pereira and S M Shieb er Prolog and NaturalLanguage Analysis csli Stanford CA

Guy L Jr Steele Common Lisp The Language Digital Press second edition

Gerry Sussman and Hal Ab elson The Structure and Interpretation of Computer Programs MIT Press

David S Warren Memoing for logic programs Communications of the ACM

David Wenstrand H Lee Dantzler Marty Hall David Scheerer Charles Sinex and David Zaret A

multiple knowledge base approach to submarine stealth monitoring and planning In Proceedings of the

DARPA Associate Technology Symposium June