towards a general framework for program generation in
TRANSCRIPT
Towards a General Framework for Program Generation in Creative Domains
Marc HullDepartment of Computing
Imperial College180 Queen’s Gate
LondonSW7 2RH
Simon ColtonDepartment of Computing
Imperial College180 Queen’s Gate
LondonSW7 2RH
AbstractChoosing an efficient artificial intelligence approach forproducing artefacts for a particular creative domain canbe a difficult task. Seemingly minor changes to the solu-tion representation and learning parameters can have anunpredictably large impact on the success of the process.A standard approach is to try various different setups inorder to investigate their effects and refine the techniqueover time.
Our aim is to produce a pluggable framework for ex-ploring different representations and learning techniquesfor creative artefact generation. Here we describe our ini-tial work towards this goal, including how problems arespecified to our system in a format that is concise but stillable to cover a wide range of domains. We also tacklethe general problem of constrained solution generation bybringing information from the constraints into the gener-ation and variation process and we discuss some of theadvantages and disadvantages of doing this. Finally, wepresent initial results of applying our system to the do-main of algorithmic art generation, where we have usedthe framework to code up and test three different repre-sentations for producing artwork.
Keywords: Automatic program generation, genetic pro-gramming, evolutionary art.
1 IntroductionFinding an efficient approach for producing artefacts ina particular creative domain is often more of an art thana science. Many general artificial intelligence techniquesexist that could potentially be used with varying degreesof success, but most are so complex that it can be dif-ficult to tell in advance which will perform better thanothers. They are also heavily dependent on the problemrepresentation used and a number of other parameters that
Permission to make digital or hard copies of all or part of thiswork for personal or classroom use is granted without fee pro-vided that copies are not made or distributed for profit or com-mercial advantage and that copies bear this notice and the fullcitation on the first page.
c©2007 Goldsmiths, University of London
can greatly affect their performance. Typically this can bealleviated by using knowledge of the problem to predictwhich search strategies will be most successful. However,in creative domains the problem may not be well-definedenough to be an accurate guide.
Our aim is to build a general, pluggable frameworkwhere problems can be expressed using a concise syntaxand tested with all of the different artificial intelligencetechniques written for the system. In this paper, we ad-dress the problem of how the user specifies a search spaceto our system. To cover a wide range of domains andlearning techniques, the representation used must be gen-eral enough to cover many different data structures, butnot too general as to include invalid solutions in the searchspace. To achieve this, we opted for a tree-based struc-ture, similar to those used in Genetic Programming, withimplicit type rules controlling the shape of the tree andexplicit constraints to disallow particular node patterns.In later work, we hope to concentrate on evaluating dif-ferent search strategies and attempting to define classes ofdomains for which particular techniques work best.
In section 2 we provide the background to our projectby describing existing genetic programming tools andsome of their applications to creative artefact generation,against which we compare our approach. In section 3we provide details of the framework in terms of how wesplit the specification of problems into three concise parts,which enables quick, flexible prototyping of different rep-resentations. In section 4 we describe how solutions aregenerated via an iterative two-stage process that employsexplicit user-given constraints about the nature of the pro-grams to be generated in order to avoid producing invalidsolutions.
To demonstrate the potential of the framework for pro-ductive generation of programs, we have implemented anevolutionary search mechanism where the user acts as afitness function (a standard approach), and we have ap-plied it to algorithmic art generation. Using the conciseproblem specification syntax we were able to quickly pro-totype three different representations for generating pro-grams that produce artwork when executed, namely colourbased, particle based and image based approaches. Fi-nally, in sections 6 and 7, we describe the future workplanned for the framework and summarise our conclu-sions drawn so far.
2 BackgroundGenetic Programming was first popularised by Koza’s1992 book (Koza, 1992) as a way to find programs thatoptimise a measure of fitness. By manipulating variable-length parse trees that represent Turing-complete pro-grams, it is sufficiently general to be able to representsolutions from many other machine learning techniques(Banzhaf et al., 1998). Many tools and libraries existfor using this technique to evolve programs or programfragments to perform particular tasks, e.g. DGPF (Weiseand Geihs, 2006), the Genetic Programming Engine1 andGALib2. Typically, these allow the user to specify a rep-resentation containing the ingredients (terminals and non-terminals3) to be used in the solutions. The user also sup-plies a fitness function that evaluates each solution, re-turning a numeric result indicating its suitability for per-forming the task. To start with, a set of random solutionsare generated using the given representation and these arethen evaluated by the fitness function to determine whichperform better than others. Roughly speaking, the bestperforming solutions are then combined with one anotherin an attempt to form new solutions that produce a highervalue when evaluated by the fitness function. This processis then repeated until the required minimum fitness valueis exceeded, at which point the solution with the highestfitness value is taken as the final solution.
In the pure GP approach, solutions can be constructedusing any combination of terminals and non-terminalsprovided in the representation. However, often this resultsin solutions being produced that are not valid in the con-text of the problem. A simple example is a problem thatrequires a permutation of values, where any solution thatcontains the same value twice would be invalid.
A standard GP approach would still allow such in-valid solutions to exist, but one remedy to this is to applyadditional constraints to the representation to explicitlyremove certain terminal and non-terminal combinationsfrom the search space. This then leads to the problem ofconstrained solution generation and variation, where thetechnique used for producing and altering solutions musttake the constraints into account in order to avoid invalidsolutions.
Several approaches for handling constraints in evolu-tionary techniques have been tested, with the most no-table being penalty functions, repair functions and de-coder functions. Penalty functions (Baeck et al., 1995)evaluate solutions against each constraint individually andsubtract a value from their fitness for every constraint vi-olated. Repair functions (as used in Michalewicz andNazhiyath (1995)) allow solutions that violate constraintsto be generated, but then modify these solutions in an at-tempt to find the most similar variant that passes all ofthe constraints. Decoder functions (as in Gottlieb andRaidl (2000)) are employed during the genotype to phe-
1A genetic programming library for the .NET framework(http://gpe.sourceforge.net/)
2A C++ library of genetic algorithm components(http://lancet.mit.edu/ga/)
3These are described as terminals and functions in Koza(1992), but we use the term non-terminal here to distinguishfrom functions in programs.
notype mapping phase and ensure that the solution geno-type maps on to a phenotype in which all constraints willalways be satisfied.
Constraint handling is particularly appropriate whenthe solution phenotype is a computer program in a high-level language, since such languages often impose manycomplex constraints such as scoping rules and type com-patibility upon their programs. Strongly Typed GeneticProgramming helps to alleviate some of these problemsby allowing the representation itself to be typed and thenmodifying the generation and evolution algorithms to onlyproduce type-safe trees (Montana, 1995). However, this isoften achieved by tying the GP system to a particular lan-guage, such that the rules of that language are implicit inthe representation (as in JGAP4).
Genetic Programming has also previously been usedto evolve programs that produce artefacts from creativedomains such as pictures and music. Machado and Car-doso’s NEvAr system (Machado and Cardoso, 2002) is awell-known generator of algorithmic art which evolves analgorithm for setting the red, green and blue colour com-ponents of each pixel in an image. Johanson and Poli haveapplied a similar technique to music generation (Johansonand Poli, 1998). Their system produces programs in a cus-tom language that describes how to play chords and whento pause between notes. Many other systems also use au-tomatic program generation to produce creative artefacts,however a full survey of these is beyond the scope of thispaper.
3 Framework DetailsOur aim is to provide a framework that is general enoughto accept problems from a wide range of different do-mains, yet concise enough to allow for quick prototypingand easy modification. We have chosen a variable-sizedtree representation to encode solutions, similar to thoseused in Genetic Programming, since this is sufficientlygeneral to also encode representations used in other ma-chine learning approaches. However, an overly generalrepresentation would include solutions in the search spacethat may not be valid solutions to the problem beingsolved. Hence, the framework must also allow users toeasily constrain their representations to remove invalid so-lutions for specific problems.
To allow users to specialise their representations, weuse a combination of node type constraints upon our parsetrees and logical constraints for removing unwanted nodepatterns. The former is based upon the constraints ofMontana’s Strongly Typed Genetic Programming system(Montana, 1995) and allows the type systems of program-ming languages to be respected. Meanwhile, the latterallows for constraints over node dependencies to be ex-pressed. This can, for instance, be used to enforce thatinstances of two node types may only exist together andnot independently. We have found this to be particularlyuseful for expressing relationships between function callsand function declarations when evolving programs.
Finally, we also provide a method for translating the
4An open-source, Java-based genetic algorithms package(http://jgap.sourceforge.net)
tree structure used internally to represent solutions intotext output, which is analogous to the genotype-phenotypemapping in Genetic Programming. In our experiments, weuse this to convert our solutions into programs, scripts ordata that can be accepted by other programs. We then usethe behaviour of these programs to evaluate the success ofthe solution.
To keep the roles of specifying the representation, im-posing constraints and compiling solutions to text sepa-rate, users provide each of these to our system in a sep-arate file. The following subsections explain how thesefiles work in further detail.
3.1 Representation File
Solutions in our current system are represented by treeswhose structure is specified by the user in the representa-tion file. At a basic level, this file allows the non-terminaland terminal node types of the tree to be specified, in asimilar way to most other Genetic Programming systems.However, these node types are also involved in typingconstraints that allow the structure of the trees to be con-trolled.
These typing constraints allow the terminals and non-terminals of the representation to exist in an inheritancehierarchy, such that groups of node types that are seman-tically linked (e.g. True, False, And, Or) can inheritfrom a common node supertype (e.g. Boolean) that rep-resents this link. Each non-terminal node type then speci-fies which arcs it has to each of its child nodes, and also in-herits any arcs declared in its supertypes. Each arc is alsoannotated with node types that restrict the nodes that canbe children of it. An arc annotated with a node type X willonly accept child nodes that are instances of the X type orany types that inherit from X. Additional features such asabstract node types, primitive types and multi-child arcsare also supported but there is insufficient space here todescribe them in detail.
The following shows an example of the syntax used tospecify a representation for simple numeric expressions.
representation NumericExpressions {abstract type NumericExpression;type Zero : NumericExpression;type One : NumericExpression;type Two : NumericExpression;abstract type BinaryOperator
: NumericExpression {NumericExpression left;NumericExpression right;
};type Add : BinaryOperator;type Sub : BinaryOperator;type Mul : BinaryOperator;type Div : BinaryOperator;
};
3.2 Constraints File
In addition to the implicit typing constraints provided inthe representation file, the user can also specify explicitconstraints upon the solution trees in the constraints file.
Since the system is not tailored to output in a specific lan-guage, this file can be used to add constraints that are spe-cific to the output language for this particular problem. Itcan also be used to add domain-specific constraints, whichin the case of program generation could remove a largeproportion of non-compiling and invalid solutions fromthe search space.
Constraints are currently expressed in a syntax that isbased upon first-order logic, but is tailored to expressingconditions about tree structures. The language includesand, or and not operators, which follow their traditionallogical semantics, as well as exists and all operatorsthat have special meanings. In particular, they only matchnodes at or within a particular part of the tree, and they canoptionally bind these matches to variables that are thenused in the evaluation of their sub-expressions.
The following shows how this syntax can be used toexpress the constraint that Div nodes cannot have Zeronodes for their right children in the representation fromSection 3.1.
constraint NoDivideByZero {all Div in root as divideNode (
not (exists Zero atdivideNode.right
))
};
3.3 Compiler File
Once a solution tree has been generated, the compiler fileis consulted for the transformations required to convert thetree into the specified output language. The user providesthese transformations as string templates for each nodetype which describe how nodes of that type should be rep-resented in the output. The string templates are specifiedin the Velocity templating language5, so that referencesto the compiled output of child nodes are represented byenclosing the child name between ${ and } delimiters.This also allows the templates to include control flow con-structs like for loops over node children.
The following gives the compiler code for translatingthe numeric expression representation from Section 3.1into C-style expression syntax.
compile Zero [|0|];compile One [|1|];compile Two [|2|];compile Add [|(${left})+(${right})|];compile Sub [|(${left})-(${right})|];compile Mul [|(${left})*(${right})|];compile Div [|(${left})/(${right})|];
4 Constraint HandlingIn section 2 we highlighted three existing methods forhandling constraints in evolution-based systems; penaltyfunctions, repair functions and decoder functions. For our
5An open-source, Java-based string template language(http://velocity.apache.org/)
system, we have tried a new approach to constraint han-dling, in which information concerning the constraints isused to guide the initial process of solution generation,then constraint-aware variation operators are used to pro-duce only valid children.
To guide the generation and variation operators, weuse an approach that attempts to determine whether thetree being modified violates the constraints either directlyor indirectly. A direct violation is where the nodes in thetree contradict at least one of the constraint conditions,whereas an indirect violation is where a partial tree6 re-stricts the possible nodes that can be placed to only thosethat will contradict at least one of the constraint condi-tions. To make this problem tractable, the constraint lan-guage was restricted to only a small number of operators,which allowed us to hard-code a number of routines thatwere able to reason about the constraints at the sacrifice oflosing Turing-completeness of the language. The follow-ing subsections cover the algorithms used for guiding thegeneration and variation of trees in further detail.
4.1 Solution Generation
Solutions are generated using an iterative two-stage pro-cess of checking which possible valid node instantiationscan be made and then choosing one based on knowledgeof previous good solutions. To start with, the generatorcomponent takes a partial tree as input, so to generate atree from scratch a root node must first be instantiated andpassed to the generator. As the first step, the generator setsall unset arcs to point to placeholder nodes and then addsall possible combinations of placeholder nodes and theirtype-compatible node types to a list of possible choicesthat can be made. The generation process then proceedsas follows:
• The tree constraints are evaluated with respect to thenodes currently in the tree to produce the constraintsthat must be satisfied by the remaining nodes to beadded.
• Each of the possible choices is checked against theconstraints and is removed if they would directly orindirectly violate them.
• If there is a placeholder for which there are no re-maining possible choices, the algorithm backtracks.
• Otherwise, one of the choices is picked at random, itsnode type is instantiated and its corresponding place-holder is replaced with the new node instance. Allalternative choices for that placeholder are then re-moved from the list of possible choices. All childrenof the new node are set to placeholder nodes and allcombinations of the new placeholders and their type-compatible node types are added to the list of possi-ble choices to be made.
• If there are no placeholders in the tree, the algorithmterminates, otherwise it repeats from step one.
6A partial solution tree is a tree where some branches end innon-terminal nodes rather than terminal nodes, and so some arcshave yet to be assigned child nodes.
4.2 Solution Improvement
Currently, we use minor variations on traditional GP tech-niques of crossover and mutation to produce new solutionsfrom previous ones, with the initial population generatedusing the above algorithm of constrained random genera-tion.
For crossover between two trees, T1 and T2, we ran-domly select a node N1 from the first tree which deter-mines its crossover point, but then we filter the nodesin the second tree by those that would form a type-compatible tree when interchanged with N1. A node N2
is then randomly chosen from this filtered list and the sub-tree rooted at N1 in T1 is swapped with the subtree rootedat N2 in T2. The tree constraints are then checked and,if violated, the swap is undone and N2 is removed fromthe list of filtered nodes and another node is chosen. Ifno valid replacement node for N1 can be found, a newcrossover point is chosen in T1. Mutation of a single treeis handled by randomly selecting a node N1, removingthe subtree rooted at N1 and then passing the tree to thegenerator to fill in the gap.
4.3 Violation Detection
In this approach, the ability to reason about the constraintsin order to predict which choices would directly or in-directly violate them has a large influence on the per-formance of the system. Currently, we preprocess boththe constraints and the representation in order to build upthe following meta-information that can be queried by thesystem in order to detect whether a violation has occurred:
• The Must Type Set of a node type contains itself andall of its supertypes.
• The Transitive Must Type Set of a node type is de-fined as the set of node types that must appear in asubtree rooted at a node of the given type.
• The May Type Set of a node type contains itself, allof its supertypes and all of its non-abstract subtypes.
• The Transitive May Type Set of a node type is definedas the set of possible node types and supertypes thatcan appear in a subtree rooted at a node of the giventype.
• The Shortest Terminal Length of a node type is theminimum number of arcs that must be traversed fromnodes of that type before a terminal node is reached.
A fixed set of rules are then used to determinewhether a violation has occurred. These rules con-tain a pattern part that is matched against parts ofthe constraints and a condition part that, based on thecurrent tree and the results of queries over the meta-data, returns whether or not the constraint can be sat-isfied. For example, one rule looks for constraints ofthe form exists NodeType in Subtree, whereNodeType and Subtree are variables, and will thencheck whether NodeType is within the May Type Set ofany placeholder nodes within Subtree. If it is not, thenthis rule has successfully determined that the constraint
can never be satisfied by any complete trees built upon thecurrent partial tree.
4.4 Evaluation
So far, we have tested our constraint handling approachon a number of small examples from very simple con-straints, such as asserting that a certain node type must ap-pear in all solutions, to complex ones based on node typeco-dependency. Although we do not have enough resultsto produce a full quantitative analysis of the approach, wehave noticed good performance in the face of complexconstraints where the space of valid solutions is sparse.Unfortunately, this is often hidden by poorer performancewhen faced with simple constraints (due to the overheadof the system) or combinations of constraints that are notcovered by our reasoning rules. This is partly because,when faced with a problem for which no rules exist, oursystem degenerates to an exhaustive search of the solutionspace, which can result in repeatedly taking paths that leadto dead ends.
However, one advantage that our system may haveover penalty-based approaches (which we intend to checkempirically) is that the destructive effect of mutation andcrossover is reduced by guaranteeing that offspring willalways be valid solutions. Such destructive effects (whenchildren have lower fitness than their parents) can lead tointrons and bloat in members of the population, which canhamper the evolutionary process (Soule and Foster, 1997).
5 Application to Algorithmic ArtTo test our system, we prototyped three different problemspecifications for generating different types of algorithmicart. The three types that we focused on were:
• Colour-based artwork, where the algorithm used toset the colour of each pixel in the picture is evolved,in a similar vein to NEvAr (Machado and Cardoso,2002).
• Particle-based artwork, where the algorithm usedto set the position and colour of 1000 particles isevolved and the particle trails are plotted over 100time steps.
• Image-based artwork, where the algorithm used toset the colour of each pixel in an image can also usecolour values from a source image.
A different problem specification was written for eachof the above types, but each one outputs code in a lan-guage based on Processing7, a scripting language usedby graphic artists that is tailored to providing high-leveldrawing operations. These scripts were then executed toproduce the resulting images.
5.1 Colour-Based Artwork
In this representation, the resulting programs loop overall pixels in the output image and set their hue, satura-tion and value based on some algorithm. The part of the
7See http://www.processing.org
program that loops over all the pixels is constant betweensolutions, however the algorithms used to set the hue, sat-uration and value of each pixel can vary. To allow forthis, the representation has node types for constructingfloating-point expressions which include constants (withinthe range 0.0 to 1.0 inclusive), simple mathematical func-tions (add, subtract, multiply, divide, sin, cosine and ran-dom) and variables (the x and y position, expressed asscreen proportions).
Since the representation is quite restricted, the typesystem in the representation is enough to ensure that allproduced solutions compile. However, there are still anumber of compiling solutions that we want to rule out,such as those that cause errors at runtime or produce pic-tures that we know will be judged badly. To remove thesefrom the search space, we added the following constraintsto the constraints file:
• There must be a variable somewhere in the solutiontree, where a variable is a reference to the x or y po-sition in the image or a call to random. All solutionsthat do not contain variables will always produce im-ages in which all pixels have the same colour.
• No constant representing the number one must everappear as an operand of a multiply expression. Anysolution that contains this combination could be sim-plified and so is redundant.
• All functions must contain at least one variable asone of their operators. This avoids constant sub-expressions that may create values outside of the de-sired range or may be more simply expressed as asingle constant.
The compiler file then specifies the mapping betweenthe node types and the corresponding scripting code thatdraws the image. All of the numerical expression nodetypes map to their expected operators, function calls orvariable names, while the root type maps to the code thatloops over the image and uses the generated expressionsto set the hue, saturation and colour components of eachpixel as shown below:
compile Main {|int width = 500;|int height = 500;|public void setup() {| size(width, height);| background(| hsv(0.0f, 0.0f, 0.0f)| );| for (float y=0; y<1;| y+=1/(float)height) {| for (float x=0; x<1;| x+=1/(float)width) {| float h = ${hue};| float s = ${saturation};| float v = ${value};| pixel(x, y, hsv(h, s, v));| }| }|}
};
Overall, the colour-based artwork problem specifica-tion consists of 130 lines of text spread across these threefiles which describes 29 node types, 5 constraints and 24compiler rules. With this, we could generate, crossoverand mutate solutions using the algorithms described inSection 4.1 and 4.2 and then compile and execute the re-sulting scripts and inspect the images generated. In figure1, we present some example images generated using thisrepresentation.
5.2 Particle-Based Artwork
The second representation to be tested used a simple parti-cle simulation as a basis for producing artwork. The gen-erated part of the solution is the algorithm used to controlthe position and colour of 1000 particles over time. Thestatic part of the solution creates the 1000 particles andthen plots their trails over 100 time steps. In addition tothis, a convolution is applied to the resulting image aftereach time step, the kernel of which can also vary. This hasthe result that lines drawn in early time steps will often ap-pear more blurred than those drawn in later time steps, sothat an impression of how the simulation has progressedover time can be seen in the resulting image.
The representation used here was very close to thecolour-based representation, except with the variablesnow tracking the position, colour, previous position, timeand index of each particle. Where the colour-based rep-resentation only evolved three numerical expressions, thisrepresentation evolves 12; six to initialise the position andcolour of every particle and six more to update the positionand colour of every particle in every time step, in additionto three constants that control the background colour ofthe image.
The constraints upon the representation are also morecomplex than those for the colour-based artwork, mainlydue to the additional variables that are only in scope forparticular parts of the program. For example, it makesno sense to reference the time step number or a particle’sprevious position in its initialisation expressions, so theseare explicitly disallowed in the constraints.
Overall, the particle-based artwork problem specifica-tion consists of 238 lines of text which describes 44 nodetypes, 6 constraints and 38 compiler rules. In figure 2, wepresent some example images generated using this repre-sentation.
5.3 Image-Based Artwork
The third representation to be tested used an existing im-age as input and could query this image for its hue, satu-ration and value components at any point, then use thesevalues in numerical expressions for setting the colour ofeach pixel in the output image. This allowed it to pro-duce image-filter style images by setting the output pixelcolours to some function of the source pixel colours. Itcould also produce warps of the source image by assign-ing the output pixels to pixels at different positions in thesource image based on some numeric function. Finally, itcould also evolve the kernel of a convolution filter to beapplied as a post-processing step. The result of this is thata range of images are produced, some of which obviously
contain the source image filtered in some way, and otherswhich merely use it as a source of semi-random values.
The constraints for this representation were very simi-lar to those of the colour-based representation, except thatadditional constraints were added to force all solutionsto use the source image colours somewhere in its com-putation of the output image colours. This ensured thatthe search space of this representation did not include thesearch space of the colour-based representation as a sub-set.
Overall, the image-based artwork problem specifica-tion consists of 171 lines of text which describes 34 nodetypes, 6 constraints and 28 compiler rules. In figure 3, wepresent some example images generated using this rep-resentation along with the source image used to producethem.
6 Future WorkIn section 5, we used the domain of algorithmic art to testthe usage of our framework for creative artefact genera-tion, where we were able to use simple problem specifi-cations to produce artworks of a similar nature to thoseproduced with bespoke systems. However, many of thedesign decisions made during the development of our sys-tem have been motivated by our interest in scaling it up tohandle much more complex problems efficiently. We arecurrently using the system in domains such as interactiveart and the generation of simple computer games and haveplans for 3D model and landscape generation.
Early results from these domains show that the evalu-ation of solutions is much more time-consuming than thatof the algorithmic art shown here. For interactive domainsin particular, the user must often try various input combi-nations in order to test for a response. We therefore be-lieve that it is important for the system to extract more in-formation from each evaluation. One way to achieve thisis to allow the user to drill down into each solution in or-der to target the specific parts that are performing poorly.The system could then refine these parts separately untilthey meet the user’s satisfaction, when they could be re-combined with the rest of the solution.
We also intend to investigate general ways of allow-ing our system to refine solutions semi-autonomously inorder to reduce the number of evaluations performed bythe user. This could be done by allowing users to specifytheir preferences to the system as a fitness function overthe phenotype, or a machine learning approach could beused to learn their preferences from the initial evaluationsmade during each session. By using a logic-based learn-ing method such as Inductive Logic Programming (Mug-gleton, 1991), this opens up the possibility of the user un-derstanding and altering the learned fitness function.
Finally, we acknowledge the that evaluation of sys-tems and the artefacts they produce is an essential as-pect of computational creativity which is missing from thework presented here and we aim to fill this gap. We arealready planning a number of studies for assessing boththe usability of our system and the appeal of the artefactsthat it produces. We are also looking into ways to quanti-tatively evaluate parts of our system where possible.
7 ConclusionsWe have presented the first description of our genericframework for automated program generation, anddemonstrated its usage in an evolutionary art setting. Wehave found that bringing constraint checking into the so-lution generation process can help weed out systemati-cally poor solutions and produce solutions faster than tra-ditional generate-and-test approaches. As we saw with theapplication to three separate art generation problems, ourframework enables rapid development of program genera-tion systems. This has helped us to quickly prototype, testand refine various representations for different programgeneration problems.
Our current implementation is lacking in a number ofareas that prevent us from applying it to solve more com-plex problems. Although the use of constraints helps torule out many bad solutions, we will need to supplementthis with more sophisticated constraints and a flexible fit-ness calculation mechanism. This is because, for morecomplex representations, we’ve found our existing con-straint language is insufficient for ruling out enough badsolutions to enable convergence on good solutions withina reasonable time. However, this work is ongoing, and weexpect to find a number of ways to address these issuesin order to allow us to test the system on a wide range ofdifferent domains.
AcknowledgementsWe would like to thank the anonymous reviewers for theircomments which have helped us to improve this paper.
ReferencesBaeck, T., Fogel, D., and Michalewicz, Z. (1995). Penalty
functions. Handbook of Evolutionary Computation.Banzhaf, W., Nordin, P., Keller, R. E., and Francone, F. D.
(1998). Genetic Programming: An Introduction.Gottlieb, J. and Raidl, G. R. (2000). The effects of locality
on the dynamics of decoder-based evolutionary search.In Proc. of the Genetic and Evolutionary ComputationConference 2000, pages 283–290.
Johanson, B. and Poli, R. (1998). GP-music: An interac-tive genetic programming system for music generationwith automated fitness raters. In Genetic Programming1998: Proc. of the 3rd Annual Conference, pages 181–186.
Koza, J. R. (1992). Genetic Programming: On the Pro-gramming of Computers by Means of Natural Selection.
Machado, P. and Cardoso, A. (2002). All the truth aboutNEvAr. Applied Intelligence, 16:101–118.
Michalewicz, Z. and Nazhiyath, G. (1995). Genocop iii:A co-evolutionary algorithm for numerical optimiza-tion problems with nonlinear constraints. In Proc. ofthe 2nd IEEE International Conference on Evolution-ary Computation, pages 647–651.
Montana, D. J. (1995). Strongly typed genetic program-ming. Journal of Evolutionary Computation, 3:199–230.
Muggleton, S. (1991). Inductive Logic Programming.New Generation Computing, 8(4):295–318.
Soule, T. and Foster, J. A. (1997). Code size and depthflows in genetic programming. In Proc. of the 2nd An-nual Conference on Genetic Programming, pages 313–320.
Weise, T. and Geihs, K. (2006). DGPF - an adaptableframework for distributed multi-objective search algo-rithms applied to the genetic programming of sensornetworks. In Proc. of the 2nd International Conferenceon Bioinspired Optimization Methods and their Appli-cation, BIOMA 2006, pages 157–166.
Figure 1: Evolved images - colour-based approach
Figure 2: Evolved images - particle-based approach Figure 3: Original and evolved images - image-based ap-proach