Bioinspired Clustering and Sorting Algorithms

within the BEAST Framework

J. R. Shaw

Computing2008/2009

The candidate confirms that the work submitted is their own and the appropriate credit has been given

where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be considered

as plagiarism.

(Signature of student)

Summary

Bioinspired computing has provided a new paradigm for study in the field of Artificial Intelligence.

In which, research is conducted into biological phenomena in order to capture similar processes within

simulations or embodied implementations.

This project implements numerous swarm based algorithms in the areas of clustering and sorting

within the Bioinspired programming framework, BEAST [3]. Initial algorithms for clustering were

introduced by Deneubourg et al. [7], whereby swarms of ants were the inspiration for the clustering sys-

tem. An application of graph partitioning is also implemented to demonstrate the use of such techniques.

In order to control the algorithms a delicate balance of parameters is required. To enable users of

BEAST to experiment with these parameters a user interface is created within the system. Further, to

facilitate the study of formed structures an enhancement of the built in visualisations within BEAST is

constructed.

i

Acknowledgements

For support, advise and in-depth expertise in the subject of Bioinspired Computation I would like

to thank my project supervisor, Marc de Kamps. Marc’s enthusiasm for the solutions built during the

project has provided motivation and confidence.

In overcoming my fears of transition from word processor to LATEX and for providing technical sup-

port, I wish to thank my fellow student, Richard Senington. Additionaly, the LATEX template used for

this project was provided by Dr. Sarah Fores [10]. Details for general LATEXsyntax and structure were

found at [16] and BibTeX information at [8].

Lastly, I have had a great amount of moral support and leniency from my partner, Sarah Bound, for

what has been a testing year for the both of us.

ii

Contents

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Project Management 3

2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Schedule of Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Background Research 6

3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Sorting and Clustering in Swarm Intelligence . . . . . . . . . . . . . . . . . . . . . . 6

3.2.1 General Clustering Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.2 Sorting Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 Characteristics of Bioinspired Implementations . . . . . . . . . . . . . . . . . . . . . 9

3.3.1 Situatedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Applications of Sorting and Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4.1 Graph Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4.2 Sorting Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 The BEAST Software 13

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Simulation Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 Sensors and Sensor Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

iii

4.4 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.1 CMake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.2 wxWidgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4.3 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Methodology 19

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2 General Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2.1 Programming Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.2 Meeting Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.3 Documenting the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.4 Testing and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Design and Implementation 22

6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.2 Initial Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.2.1 Algorithm Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.2.2 Ants and Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2.3 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2.4 Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2.4.1 Coloured Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2.4.2 Sorting Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3 Iteration One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.3.1 A Review of Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3.1.1 Situatedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3.1.2 Situatedness with Colour . . . . . . . . . . . . . . . . . . . . . . . 29

6.3.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.4 Iteration Two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.4.1 Graph Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.4.2 Enhanced Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.4.2.1 Making the World 3D . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.4.2.2 3D Animats and WorldObjects . . . . . . . . . . . . . . . . . . . . 35

iv

6.4.2.3 Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Evaluation 41

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2 Evaluation of Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2.1 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2.2 Sorting with Colour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2.2.1 Non Situated Solution . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2.2.2 Situated Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2.3 Graph Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.3 UI and 3D World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.4 Project Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.5 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Bibliography 49

A Personal Reflection 51

B BEAST Source Mods 53

B.1 CMake Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

C The BEAST World Class 55

v

Chapter 1

Introduction

1.1 Motivation

This project has been devised in order to provide a learning aid for those studying Bioinspired artificial

intelligence, in particular, the study of clustering and sorting algorithms and to provide these examples

within the BEAST framework [3]. To improve the learning experience, simulations of clustering and

sorting should be presented in order to enable a level of user interaction and should abstract somewhat

away from users having to modify program code in order to modify algorithm characteristics. Emphasis

on the demonstrations of real-world applications of sorting/clustering to reinforce the importance of

such algorithms is to be made, in order to reinforce the relevance of the ideas presented.

1.2 Objectives

The objectives of the project are to:

1. Investigate and understand popular Ant inspired sorting/clustering algorithms and their potential

applications in order to implement them within BEAST.

2. Develop a method, or potentially many methods, that aid in experimentation with the algorithms,

with possible potential in educational fields. This would involve modification of algorithmic pa-

1

rameters as well as any other necessary features such as advanced visualisation whilst minimising

the need to modify existing program code.

1.3 Minimum Requirements

The minimum requirements are:

1. A BEAST simulation of a bioinspired clustering algorithm, providing a visualisation of the agents

performing the clustering operations.

2. Similarly, a BEAST simulation of a bioinspired sorting algorithm, providing a visualisation of the

agents performing sorting.

3. A user interface to the simulations in order to modify algorithm configurations (e.g. the number

of agents) with relative ease in comparison with having to refactor code within the simulations.

The possible extensions are:

1. BEAST simulations of a real world applications of the sorting/clustering algorithms which are

much greater in complexity, such as graph partitioning.

2. An evaluation of how successful sorting is on ’real world’ data such as generated database records.

3. A single software artifact extending the BEAST framework with which a user would have ac-

cess to, and manipulation of, numerous algorithms (possibly more than just sorting/clustering).

Extensibility will be key in having an architecture to allow the integration of new algorithms.

4. An enhancement of the built in visualisations within BEAST.

2

Chapter 2

Project Management

2.1 Overview

In order to plan time effectively, the project is split into several tasks to be completed in order to un-

derstand the problem, move on to building/evaluating a solution and write a final report within the time

available. This chapter attempts to create a general plan to be followed.

2.2 Schedule of Tasks

A number of fairly high level tasks have been generated in order to manage the project successfully.

These are presented next, with the corresponding Gantt chart shown in Figure 2.1.

(1) Preliminary Investigation: 20 Oct - 31 Oct The preliminary investigation involves general set-up

of BEAST [3] (both at home and University), which includes general API investigations and

review of example code. Initial background reading into the field of Ant inspired algorithms is

also to be carried out.

(2) Literature Review: 3 Nov - 12 Dec A review of literature involving Ant inspired clustering and

sorting algorithms.

3

(3) Algorithm Prototyping: 17 Nov - 12 Dec Running parallel alongside the literature review, poten-

tial clustering and sorting algorithms are to be prototyped in order to test feasibility within the

BEAST [3] framework and to further familiarise the author with the API.

(4) Research into Algorithm Applications: 15 Dec - 5 Jan Potential applications of the discovered sort-

ing and clustering algorithms are to be researched.

(5) Prototyping of Algorithm Applications: 22 Dec - 5 Jan Potential applications of the sorting and

clustering algorithm are to be prototyped to ensure feasibility.

(6) Software Iteration 1: 9 Jan - 4 Feb The purpose of this iteration is to enable the minimum require-

ments of the project to be completed. This involves completion of any clustering and sorting pro-

totypes developed and will tackle the issue of allowing some degree of user manipulation of the

algorithms.

(7) Software Iteration 2: 5 Feb - 27 Feb The purpose of this iteration is to enhance upon any built

artifacts by attempting to complete one or more of the possible project extensions.

(8) Software Evaluation: 2 Mar - 18 Mar Time is allocated here to evaluating any solutions produced.

Of particular interest will be the measure of success in implementing the Ant inspired algorithms

within BEAST [3].

(9) Writing the Final Report: 16 Feb - 15 Apr Writing of the final report.

Figure 2.1: Initial schedule. This shows the milestones of the mid-term report and the software demon-

stration.

Due to mitigating circumstances of a personal nature towards the end of November 2008 the project

had to be rescheduled. Further, due to important coursework load at this time, two to three weeks of

4

potential project work was not completed in favour of other deadlines. Additionally, as further expressed

in Appendix A, the time required to plan and write the final report was greatly underestimated. Further,

iteration 2 of programming had overrun, pushing the evaluation of the solutions further along in the

schedule. The final schedule is displayed in Figure 2.2.

Figure 2.2: Final schedule. This shows the milestones of the mid-term report and the software demon-

stration.

5

Chapter 3

Background Research

3.1 Overview

Within this chapter, the concepts and algorithms of ant inspired clustering and sorting are explored.

3.2 Sorting and Clustering in Swarm Intelligence

Bonabeau et al. [4] describe the general study of Ants in order to observe natural sorting and clustering,

in particular, with the clustering of corpses into cemeteries. These studies have been the footing towards

creating algorithms that simulate Ant behaviour. Further, the literature implies that the algorithms can

be applied to graph partitioning (see Section 3.4.1).

Numerous methods exist in the field of swarm intelligence in regards to sorting and clustering.

Generally, it has been found that the methods are probabilistic models where probabilities are calculated

to facilitate ant behaviour. Further, sorting and clustering algorithms appear to be very similar in style,

in that sorting differs from clustering simply by differentiating between objects.

6

3.2.1 General Clustering Algorithm

Deneubourg et al. [7] presents a rather generic and simplistic model of clustering. Methods presented

further in section 3.2 extend upon this method. Simply put, each ant (that is randomly wandering) in the

simulation has an awareness of objects to be clustered, therefore each ant can study the density of items

around itself. The probability of picking up an item Pp and the probability of dropping an item Pd are

modelled by

Pp =(

k1

k1 + f

)2

(3.1)

Pd =(

fk2 + f

)2

(3.2)

where k1 and k2 are constants and f is the fraction of perceived items around the item (ant) position

where the ant is picking up (dropping) the item. In basic terms, if f � k1 then Pp is high and vice versa

(3.1). Similarly, if f � k2 then Pd is low and vice versa (3.2). The general outcome of this is that the ants

will have a low probability of picking items up that are amongst large clusters and a high probability

of dropping objects when the ant is amongst a large cluster. Of course the complimentary properties

also hold, where probability is high of picking up items in a disparate location to other items and a low

probability of dropping items in the same scenario.

Of course, the behaviour of the algorithm can alter drastically with respect to constants k1 and k2.

For example, a large value of k1 with respect to any value of f would result in constantly high probability

of picking up an item thus no clustering would occur. It would be sensible to allow users of any such

simulation to modify these constants as appropriate.

Deneubourg et al. [7] suggests that f be simply calculated as NT where N is the number of items

encountered in the last T time units.

3.2.2 Sorting Algorithm

Bonabeau et al. [4] demonstrate that a sorting based implementation of the Deneubourg et al. [7] al-

gorithm is possible. For example, each type of item to be sorted has to have its own frequency to be

calculated separately, taking into account only the same type of item in calculations. Therefore, ants

7

will have to distinguish between world objects in calculating frequencies which results in less generali-

sation and a poor level of extendability. In further detail, an object orientated approach to constructing

ants would suffer in that an Ant object would have to be aware of the various item objects in the simula-

tion and their types, thus adding an item with new characteristics would require re-factoring of Ant code.

Lumer and Faieta [17] improve on this by introducing a measure of dissimilarity between items,

which is a value between 0 (objects identical) and 1 (objects non identical). The difference between two

world items is denoted by

d (oi,o j) (3.3)

where oi and o j are the items to be distinguished. This allows for items to be defined with varying

levels of difference, rather than simply having to define an item as the same or different. Of course, the

difference value should be normalised in some manner to be between 0 and 1 inclusive.

The value of f in 3.1 and 3.2 is adapted here to provide a more accurate judgement of the frequency

of perceived items. Here, f is replaced by f (oi) which represents the local density around object oi and

is defined as

f (oi) =

1s2 ∑o j ∈ Neigh(s× s) (r)

[1− d(oi,o j)

α

]if f > 0,

0 otherwise.(3.4)

where s2 is an s× s area around point r, Neigh(s×s)(r) represents all items in the s× s area around

r and α is a factor that determines the amount of differentiation between difference values. Note that

α has a deal of influence on the algorithm functionality, if it is very low (e.g. close to zero) then the

difference can become much larger etc. Object oi is the object of interest, either this is to be picked up

or it is being held already.

To demonstrate the calculation of f (oi), where oi is an object to be dropped, Figure 3.1 shows an

agent (smiley face) at position r on a grid world with a 3× 3 detection area. The world consists of

two item types, © (circle) and 4 (triangle), where the difference between two circles is zero and the

difference between a triangle and circle is one. The agent is holding a circular item to be dropped. Using

Equation 3.4 with α as 0.5, f (oi) becomes

8

f (oi) = 132

((1− d(oi,o1)

0.5

)+(

1− d(oi,o2)0.5

)+(

1− d(oi,o3)0.5

))= 1

32

((1− 0

0.5

)+(1− 0

0.5

)+(1− 1

0.5

)) (3.5)

Figure 3.1: Ant dropping an item

This implementation allows items to be differentiated in a simple manner, rather than calculating f

for each item type, which is a motivation for object oriented development and polymorphic items. Fur-

ther, it demonstrates that clustering is merely a special case of sorting when the difference value (3.3)

between all items is set to zero [4].

Figure 3.2 shows high level description of the Lumer and Faieta [17] algorithm as presented by

Bonabeau et al. [4]. Note that this implementation, along with other examples that have been re-

searched, use a grid like world in which only one item can lie in each square and the ants within a

simulation change to a randomly chosen neighbouring square on every time step.

3.3 Characteristics of Bioinspired Implementations

Brooks [6] compares and contrasts traditional AI approaches based on a Von Neumann architecture with

the relatively new computational AI concepts such as that of the Bioinspired field, whereby control is

9

/* Init. Parameters of the algorithm.

* k1 = 0.1

* k2 = 0.15

* alpha = 0.5

* s2 = 9

* tmax = 106 steps

*/For every item oj do

place oj randomly on gridEnd ForFor all agents do

place agent at randomly selected siteEnd For/* Main loop *//* t is a timestep */For t = 1 to tmax do

For all agents doIf ((agent unladen) and (site occupied by item oi)) then

Compute f(oi) and Pp(oj)Draw random real number R between 0 and 1If (R <= Pp(oi)) thenDrop item

End ifEnd ifMove to randomly selected neighbouring site not occupied by other agent

End ForEnd ForPrint location of items

Figure 3.2: A high-level description of the Lumer Faieta Algorithm [4]

distributed amongst agents and the system is potentially parallel. In building an AI based system, Brooks

identifies a number of concepts to adhere to, some of which apply more to physical implementations

rather than simulations. The next section discusses a feature of importance.

3.3.1 Situatedness

Situatedness is described as designing and implementing for the real world, or to simulate the world

constraints, in order to have an algorithm that may be embodied within a physical agent [6]. Agents

often have a direct and perfect access to the entire world, which would not be the case in a real world

situation.

10

3.4 Applications of Sorting and Clustering

3.4.1 Graph Partitioning

Graph partitioning involves sorting the vertices of a graph G, comprising of (V,E) where V is the set

of vertices and E is the set of edges, into clusters based on a particular criterion [11]. Each vertex is

represented by vi where i is the vertex number and E contains pairs of vertices, {vi,v j}, representing an

edge joining the vertices. In particular, the graph can be clustered in an Ant inspired style by having

vertices of a cluster located in relatively close space within the world and different clusters separated by

a relatively large gap [4].

In standard graph partitioning, the aim is to cluster vertices together based on how many neigh-

bours they share or alternatively, based on minimising edges that link separate clusters [4]. This is not

a trivial algorithm for a standard computer science approach. In fact, certain cases of the problem are

NP-complete [12].

Kuntz et al. [15] have developed a graph partitioning implementation by modifying the Lumer and

Faieta [17] algorithm discussed in Section 3.2.2. The algorithm modifies the differentiation value of

Equation 3.3 to compare two vertices vi and v j based on the number of shared neighbours, the higher

the number of common vertices between vi and v j the lower the difference value. This is presented in

Equation 3.6.

d (vi,v j) =|p(vi)4 p(v j)||p(vi)|+ |p(v j)|

(3.6)

p(vi) (and similarly for p(v j)) is defined further in Equation 3.7 which represents the set of vertices

that are adjacent (connected by an edge) to vertex vi. 4 is the mutual exclusion, or the union minus the

intersection ((p(vi)∪ p(v j))− (p(vi)∩ p(v j))), of the two sets.

p(vi) = {v j ∈V ;{vi,v j} ∈ E}∪{vi} (3.7)

Equation 3.6 simply replaces d (oi,o j) in the Lumer and Faieta [17] algorithm. On initialisation, the

graph is laid out much like normal objects, with a random distribution in the space available.

11

3.4.2 Sorting Data Sets

To enable sorting of data sets, one can embed data into world objects so that each object effectively rep-

resents a record of some information. This might, for example, be records from a supermarket for each

customers’ shopping in the last year and the objective is to sort customers together who have bought

similar items. A normalised (0 - 1) metric of difference must then be devised between data fields in

order to provide a value for Equation 3.3.

12

Chapter 4

The BEAST Software

4.1 Overview

This chapter provides a review of the underpinning software technologies of the project, in particular

the BEAST [3] framework and its dependencies.

BEAST [3] is a c++, object oriented program that provides a graphical user interface and interactive

front end to user-tailored simulations. Extensibility is generated through allowing programmers to ex-

tend existing classes to create agent based simulations. The BEAST source codes are downloadable in

source form and are freely available to those within the University of Leeds from

http://www.comp.leeds.ac.uk/ai23/assignments/beast.tar. The source files can be built within a linux

environment with the dependencies installed (see Section 4.4.1, 4.4.2 and 4.4.3).

4.2 Simulation Framework

The programmers interface to the BEAST software is provided by the Simulation Framework classes

as defined in the documentation [2]. The three major classes of relevance are Simulation, Animat

and WorldObject.

13

The Simulation class is sub-classed in order to set up the simulation parameters (such as max-

imum running time) and to add Animats and WorldObjects (see Figure 4.1). Each simulation also

contains a World object, which uses OpenGL [21] to draw the simulations in 2D on the screen. More-

over, the World class updates Animat and WorldObject locations on each timestep, handles all user

interactivity within the simulation, such as selecting of world objects, and processes collisions. In order

to run simulations, a configuration file, demos.cc, is modified to include class paths to Simulation

sub-classes, after which the application must be re-compiled.

Figure 4.1: The Simulation and World objects

The Animat instances represent any agents or creatures that will reside in the simulations, with the

WorldObject class providing a generalisation of Animat to be used as stationary objects, circular

by default, such as those that require clustering or sorting (see Figure 4.2). Both classes provide a

number of accessor/mutator functions to control properties, such as changing/accessing of size (radius)

and location within the world.

In more depth, the Animat class by default will provide an agent that sits still whilst the sim-

ulation runs. In order to facilitate movement, the Animat class provides a ’motor’ like abstraction,

whereby input can be given to a pair of wheels, one either side of the agent, to control movement (e.g.

equal input to both wheels results in a straight line direction). A method called Control() can be

overridden in order to set the motor state of the Animat on each time step. Another useful method

is OnCollision(WorldObject*) where, on each time step, all objects (Animat or WorldObject)

touching the Animat are passed via this method sequentially to it in order to perform advanced inter-

action. Figure 4.3 demonstrates the sequence of calls made to Animat and WorldObject classes in a

14

Figure 4.2: Creating an Agent and Object in BEAST

simulation for one particular timestep.

4.3 Sensors and Sensor Functions

BEAST provides a large and flexible system for the creation of sensors that can be utilised by the

Animat class [2]. The API provides the ability to choose a range and scope for the sensor, a definition

of what object type the sensor should be looking for and a mechanism for evaluating the items that are

detected to produce a single double precision output from the sensor. A class diagram is presented in

Figure 4.4 that shows the core sensor classes as well as a number of relevant classes used within the

project. In actuality, the sensor class hierarchy is much larger, providing much more functionality.

The Sensor class is instantiated within the Animat and then added to the Animat’s sensors prop-

erty. Each sensor object is simply a WorldObject and is treated as such by the World class. The

presented sub-class, AreaSensor, detects all objects located within its radius and does so on each

time step by implementing this logic within the Interact(WorldObject*) method (see Figure

4.3).

The SensorMatchFunction, added to the sensor, performs matches on objects in the world that

the sensor should detect through specifying the object type in the SensorMatchFunction template.

Specialising this, MatchKindOf goes a step further and will also match to any class that is generalised

from the template class at any lower level in the hierarchy, useful for building in extensibility to any

15

Figure 4.3: The update sequence at any particular time step

developed system.

SensorEvalFunction performs an evaluation upon all objects detected by the sensor in each

timestep, in which the Operator() method is called by the sensor for each matching type encoun-

tered and the Reset() method is called to re-initialise any accumulated data (if necessary) before the

next timestep. Sub-class EvalNearest keeps a tally of the closest item detected and EvalCount

simply retrieves the number of items within the sensor range.

Finally, the SensorScaleFunction scales any output from the SensorEvalFunction out-

put, where the specialisation ScaleAbs simply modifies the output by taking the absolute value.

16

Figure 4.4: Diagram of sensor classes

The three functional classes mentioned above inherit from unary and binary operator types, where

the object can itself be used as an operator. The Operator() method is inherited from the unary or

binary type to be called when the object is used in such a manner. On Interact(WorldObject*

other) (see Figure 4.3, remembering that a sensor is a WorldObject type), the process is simply if

((*MatchFunc)(other)) (*EvalFunc)(other, other->GetLocation()) and simi-

larly, when GetOutput() is called upon the instantiated sensor object the output is (*ScaleFunc)

(EvalFunc->GetOutput()) where ScaleFunc is the scaling function, EvalFunc is the eval-

uating function and MatchFunc is the matching function.

17

4.4 Dependencies

The BEAST framework is dependent on a number of packages, the major ones are discussed here.

4.4.1 CMake

CMake [14] is a build tool used to structure the build directories of the application and is required

initially to build the application from source code. A domain specific language is provided with CMake

to simplify the process of creating c/c++ makefiles and controlling code structures. CMake is further

used in this project to include wxWidgets [23] (see Section 4.4.2) header files within the build path

of the simulation framework in order to enable a UI to the simulations. The CMake language is not

discussed in any further detail in this report.

4.4.2 wxWidgets

wxWidgets [23] is a cross platform GUI library used for the windowing system of BEAST. wxWidgets

can be programmed in numerous languages, but is programmed in c++ within this project to enable a UI

that loads from within the BEAST application. The API for wxWidgets is very typical of standard GUI

toolkits, including classes such as wxFrame for stand alone windows, wxPanel for panels, wxButton for

buttons etc. The major dissimilarity of wxWidgets to taught systems experienced by the Author is its

low level nature, relying on the creation of event tables to map unique identifiers to events generated

by GUI components. The components of the wxWidgets system are mentioned further in the design

(Chapter 6).

4.4.3 OpenGL

OpenGL [21], the Open Graphics Library, is an industry standard programming interface to graphics

hardware, enabling the creation of optimised and advanced 3D and 2D applications. This, together

with a wxWidgets [23] canvas based window to enable OpenGL programming within the wxWidgets

windowing system, provides the ability for BEAST to render the 2D visualisations of the simulation

environments. OpenGL is used in the project in order to enhance the visualisations of agent simulations

(see Chapter 6).

18

Chapter 5

Methodology

5.1 Overview

This is a short chapter that discusses the methodology used by the Author in attempting to tackle the

specific nature of this project and, in particular, the manner in which a solution was implemented.

5.2 General Methodology

In planning and developing a methodology to follow it was concluded at an early stage that no detailed

review of industry standard methodologies need be investigated, nor does any one of these frameworks

need to be adhered to. A specialised and research based project undertaken by an individual for a rel-

atively short amount of time, whilst the individual undergoes various other time consuming tasks such

as University examinations, is unlikely to be a suitable candidate for any one solution to the issue of

software development and software project management.

A number of issues that the Author thought relevant to the project are:

1. Choice of programing style to suit the nature of the problem (Section 5.2.1).

2. Prioritising requirements in order to produce a solution (Section 5.2.2).

19

3. Techniques for documenting any solution produced (Section 5.2.3).

4. Testing and Evaluation decisions (Section 5.2.4)

More structured approaches to software development are not necessary within this project as they do

not provide the necessary flexibility required and are often too rigid. Furthermore, the project requires

little or no requirements analysis documentation because the requirements are simply outlined as the

project minimum requirements, and accepted algorithms become requirements in their own right. Any

user interaction developed is also likely to be minimal, in the region of simply modifying algorithm

parameters etc., and so does not require extensive requirements evaluations and HCI investigations.

5.2.1 Programming Style

Due to the powerful functionality of BEAST [3] and the ease of development provided, when investi-

gating potential clustering/sorting algorithms and any real life applications for that matter, one would

be best implementing a quick prototype to act as proof of concept. Each prototype would assess the

algorithm compatibility with BEAST and would remain as a software artifact to be used as a base for a

modified version at a later point in the project.

High fidelity and evolutionary prototyping is a chosen style of programming for the simulations,

where a relatively complete solution is produced as an initial prototype and modifications are made atop

of this. With a basic design, one can produce quick implementations of software for proof of concept

and for basic purposes. Floyd [9] describes the beneficial use prototyping in various situations, in which

experimental prototyping is described as an ideal process in order to assess the competence of a solution

and to judge whether it is possible with use of the proposed resources (in this case, the BEAST [3]

framework).

5.2.2 Meeting Requirements

Referring to the plan created in Chapter 2, it was decided to undertake the meat of the project devel-

opment in two iterations. The first iteration is in place in order to tackle the minimum requirements

of the project and also to perform a review of any initial prototypes of clustering and sorting created

during research. The purpose of the second phase is to undertake all, or at least one of the extended

requirements. These iterations are discussed in Sections 6.3 and 6.4.

20

5.2.3 Documenting the Solution

As a method for developing solutions and describing the final system, the UML (unified modelling lan-

guage) version 1.x is used due to the Author’s personal taste [18]. In particular, it is used to sketch out

conceptual ideas of more complicated parts of the solutions and fulfils the requirement of documention

references to any solutions produced.

Agile modelling [1] is used as a design style when creating the final software artifacts. This is not a

methodology in its own right, but is a set of principles for documentation and styles of communication

to be used with a specific methodology. This choice has been made due to the emphasis on working in

light weight and flexible environment, where carrying out certain phases of typical lifecycles in depth if

not required. Moreover, it is encouraged to iteratively modify diagrams as the project commences, even

during implementation, in order to take into account new features that may occur, which is suited to the

use of prototyping and to short timespan projects.

5.2.4 Testing and Evaluation

Evaluation of the solution will be based on criteria that are felt relevant to the project. Chapter 7 contains

the evaluation, where the criteria are made clear and the evaluation results shown.

In terms of testing the solutions produced, tests have been performed as development proceeds using

various methods. The functions that produce numerical output, required of the clustering and sorting

algorithms presented in Chapter 3 have been tested with particular scrutiny in the black-box testing

style. Due to the prototyping style of development, products of each prototyping iteration are evaluated

for success by visual testing and by providing test data, some of which is reproduced and demonstrated

in Chapter 7.

21

Chapter 6

Design and Implementation

6.1 Overview

As the heading describes, in this chapter the design and architecture of the completed software artifacts

are presented alongside examples of the finished solution. This includes initial prototypes and issues

therein and the software iterations performed as discussed in the Methodology (5).

6.2 Initial Prototypes

Initial prototypes were developed as proof of concept (see Chapter 5). Both clustering and sorting

were developed based on the described algorithms. Shown in this section - the modifications of the

original algorithms presented earlier, an extensible design for the simulations and the clustering/sorting

prototypes.

6.2.1 Algorithm Modification

The aforementioned algorithms of Chapter 3 have been modified in order to provide a sensible imple-

mentation within BEAST [3]. These modifications will therefore require additional development.

22

A large change from the suggested algorithms is that the local density calculation for f as described

in Section 3.2.2 be modified. This relies on an s× s (square) area to be specified as a local area around

each Ant agent in order to calculate the relative density of item types contained within the square.

Enforcing a grid within each simulation would be an unnecessary overhead, due to the requirement

that each Animat would have to move from square to square in each timestep and that items would

only moved from square to square. Agents should be able to move through the environment in a fluid

motion and at varying speeds if required. Additionally, item sizes should be able to vary from sim-

ulation to simulation without a modification of the size of grid columns and rows. Also, the built in

Animat/WorldObject controls and rendering within BEAST would not be used to full potential.

In order to provide a local density function that works in the simulations we must assume:

1. Items should be restricted to a particular shape, most likely a circle.

2. All items in a simulation must be the same size (radius).

The value of s2 or s× s in the simulations should be based directly on the number of items that the

Animat can detect, n. The detection radius of each Animat could be rad =√

n× i2r where ir is the radius

of the world items (all the same radius), yet a circle cannot tessellate to cover a plane thus the radius

could be as large as rad = 2ir√

n which effectively approximates an s× s grid area full of circles. In

Equation 3.4, 1s2 becomes 1

n and each Animat will have a circular detection area of radius rad replacing

the square s× s zone. The result is Equation 6.1, in which vec(oi) represents the vector location of oi

and items is the set of all items in the simulation, not including (oi).

f (oi) =

1n ∑o j ∈ {o j | o j ∈ items, ‖vec(o j)− vec(oi)‖ ≤ rad}

[1− d(oi,o j)

α

]if f > 0,

0 otherwise.(6.1)

6.2.2 Ants and Items

To provide extensibility, it was assumed that two main classes were required to provide useful base

classes for the simulations. In general, Ants sort Items, giving need for base classes of Ant and Item as

seen in Figure 6.1.

23

Figure 6.1: Extensibility classes of Ant and Item

Both Ant and Item objects maintain a two state system, where ants hold items or don’t and items

are held or are not. Furthermore, various methods are provided in order to access state and attributes

(e.g. GetMode()), or set state and attributes.

The core of the Item class is the virtual Difference(i : Item*) function, relating directly

to equation 3.3 to define the difference between two instantiations of the Item class. This function can

then be overridden to provide difference values for any item types as long as the output is normalised to

a value between 0 and 1 inclusive.

The Ant class provides important virtual methods, those that can be overridden by sub-classes or

that have been overridden from a parent class (denoted by the <virtual> stereotype). The Control()

function provides the motor input to the Ant, whereby a randomly distributed input provided to the

Animat base class left (random number 0 - 1, ranVal) and right (1− ranVal) controls (see Section 4.2).

From the OnCollision() function, with the Ant in mode NO ITEM a collided with Item (passed

24

into the function) will be picked if PickUpItem(l : Item*) is true. On call to the Control()

function, if the virtual function DropItem() is true and the Ant is in mode ITEM then the current

item is dropped at the Ant’s position. Both these functions should be overrided in order to provide the

logic behind the actions of any implemented clustering/sorting algorithm with relative ease.

The functions, PickUpItemAction() and DropItemAction can be overridden by subclasses

to implement special behaviour on these events. By default, PickUpItemAction() puts the newly

acquired item at a large negative position away from the detection radii of other ants.

Additionally, each Ant object records the number of timesteps that have passed. If this number

of timesteps passes the maximum number of timesteps (specified as variable maxTimeSteps and set

via SetTimeSteps(maxTime : int)) and the ant has dropped any item it had then the ant is

removed from the simulation. The purpose of this is to allow the final items to be dropped at the end of

the simulation, rather than each ant still effectively carrying them.

6.2.3 Clustering

Using the base classes for Ants and Items, presented in the prior section, it is quite simple to build in the

ability for a clustering Ant. The ClusterAnt class is displayed in Figure 6.2. The instance variables

of the class relate directly to parameters of the Equation 6.1 barring that of α , and radius relates to the

size of the detection area derived in Section 6.2.1.

Both overridden methods, DropItem() and PickUpItem(l : Item*), call

FractionOfPerceivedItems (l : Item*, v : Vector2D) in order to calculate the

value of f (oi), where item argument is oi and the 2D vector is either the location of the collided with

item or the location of the Ant when dropping an item. For simplicity, the Equation 6.1 can be applied

directly to sorting by replacing[

1− d(oi,o j)α

]with 1 directly. Therefore,

FractionOfPerceivedItems(l : Item*, v : Vector2D) simply deduces which items

in the world are within the detection radius, via simple vector subtraction, increments a counter for

every one that is and multiplies the result by 1n . Additionally, DropProbability(fraction :

float) and PickUpProbability(fraction : float) implement the Equations 3.2 and

25

Figure 6.2: A ClusterAnt Class

3.1 respectively, which are used to deduce whether or not the object should be dropped or picked up in

the same manner as the algorithm of Figure 3.2 describes.

RoomToDrop() : bool determines whether there is enough space to drop a held Item. This

is done simply by making sure each other Item in the world is no closer than the radius of the current

object through simple vector mathematics, based on the fact that the radii of each item is equal.

6.2.4 Sorting

In order to facilitate sorting, Items need to be defined that are dissimilar in some manner. Colour

provides a method of doing so, whilst also providing a visual queue. This section describes the design

of the coloured items and that of the sorting ants.

6.2.4.1 Coloured Items

Each WorldObject can have a specific colour, so a subclass of the Item class can be created in which a

random colour may be generated for each instance. The only other necessary modification is to override

the Difference(i : Item*) in order to provide a value of differentiation. This then simply

becomes the difference between the colour of a current item, I, and the other item passed into the

26

function, Iother, as shown in equation 6.2,

di f f =|Ired− Iotherred |+ |Igreen− Iothergreen|+ |Iblue− Iotherblue|

3(6.2)

where Ired (Iotherred) is the red component of the item, I, (Iother) RGB colour component.

6.2.4.2 Sorting Ant

The architecture of the SortingAnt (Figure 6.3) is very similar to that of the ClusterAnt (Section

6.2.3). In this implementation, due to the requirement to sort, Equation 6.1 is followed directly within

the

FractionOfPerceivedItems (l : Item*, v : Vector2D) function, where instance

variable alpha relates directly to α , area to n and radius to rad.

Figure 6.3: A SortingAnt Class

6.3 Iteration One

Iteration one relates directly to the software iteration 1 mentioned in Chapters 2 and 5, whereby the aim

is to complete the minimum requirements of the project. These aims, in particular are to review the

27

initial prototypes for completeness and create a UI to the clustering and sorting algorithm.

6.3.1 A Review of Prototypes

The developed prototypes were rather complete, each appearing to do the work required of them (i.e.

clustering and sorting), yet the solutions could be seen to be ’cheating’ somewhat due to not conforming

to the issue of situatedness as addressed in Section 3.3.1. The design to solve this is discussed next.

6.3.1.1 Situatedness

There is no simple way in which to gain Situatedness in a manner that provides extensibility in the same

sense as the algorithms presented earlier. Ideally, one would be able to incorporate the Difference(i

: Item*) function into the implementation, but this would suggest direct access to world items and

would not be truly situated. It was decided that in order to use BEAST [3] to its full potential the sensor

base, presented in section 4.3, should be used in order to solve the problem of situatedness. In this man-

ner, each Ant would be working purely from sensor like inputs rather than using a list of all Item objects.

The existing problem with the SortingAnt class is that each instance maintains a reference to a

list of all the items in the simulation. With this, the ant decides which items are within its range, whether

there is room to drop items based on the distance of the items and uses the items in range to calculate

the fraction of perceived items when picking up or dropping.

In order to solve the issue of finding room to drop, a sensor using the EvalNearest evaluation

class, the MatchKindOf matching function with with Item as a template and ScaleAbs were used

(see Section 4.3). EvalNearest simply retrieves the distance between the owner of the sensor and

the nearest object detected. If this distance is greater than the radius of the Item to be dropped, then

there is room to drop.

Solving the issue of performing the logic for sorting in a situated manner is more complex, and is

discussed in the next section.

28

6.3.1.2 Situatedness with Colour

As the Sensor class (see Section 4.3) provides a single numeric output (double precision number), the

sorting equation (3.4) and the difference equation (6.2) need to be re-arranged into components that can

in turn be easily retrieved from various Sensors. The amount of red, green and blue component detected

through the sensors is presented by equations 6.3, 6.4 and 6.5.

red = o1red +o2red , . . . ,+oCred (6.3)

green = o1green +o2green, . . .+oCgreen (6.4)

blue = o1blue +o2blue, . . .+oCblue (6.5)

In the above equations, oi is an object within the Ant detection area where C items have been de-

tected. The colour component of the item is denoted as oired for red and similarly for green and blue.

These equations represent the output from three sensors, one for each value of red, green and blue re-

spectively.

The final equation effectively replaces that of the original sorting equation (3.4) and is shown in

Equation 6.6. Value C is again the number of items encountered by the Ant, oired is the red component

for the item of interest (similarly for green and blue) and n is the total size of the Ant detection area

as discussed in Section 6.2.1. α has the same meaning as in Equation 3.4. One more sensor is thus

required, to count the number of items within range and produce the value of C.

f (oi) =1n

(C−|Coired− red|+ |Coigreen−green|+ |Coiblue−blue|

3α

)(6.6)

Figure 6.4 shows a sensor set-up that produces a ColourSensor class capable of retrieving one

of red3α

, green3α

or blue3α

(see Equation 6.6), depending on which colour is specified on creation of the object

(via the constructor). To be specific, it is the EvalColour class that sums over the specified colour

components of the detected objects, then divides its output by 3 when GetOutput() : double

is called by ColourSensor. It is the scaling class, ScaleByAlpha, that divides by α before the

output form the colour sensor is returned. In order to count the number of items detected, to generate C,

a similar sensor set-up is used, where ScaleByAlpha is replaced by ScaleAbs and the evaluation

29

class becomes EvalCount. These four sensors can be used to produce the values required in Equation

6.6.

Figure 6.4: Class diagram of a ColourSensor

6.3.2 User Interface

In terms of deciding on user interface style, two particular options were viewed as potential solutions.

The disregarded approach was to have a simple configuration file for both the clustering and sorting sim-

ulations, providing a syntactic interface to the simulations by modifying the parameters within the file.

A graphical interface approach was taken instead, whereby a new Simulation sub-class has been

created (named AntAlgGUISimulation) that, rather than start a simulation, starts a small GUI to

enable selection of algorithm type and modify parameters. The choice of GUI over config file is a purely

aesthetic one, and demonstrates the extensibility of the BEAST framework [3].

Figure 6.5 shows the implemented GUI. The general design is to separate default parameters from

those specific to each algorithm, thus the number of Animats and Items is in a separate component at

the top whereas each algorithm has a tab within the bottom section. Note that the GUI cannot be closed

and appears fixed above the existing BEAST application window, this enables the GUI to close itself

when a particular algorithm is started or when the simulation is changed.

30

Figure 6.5: User interface to the simulations.

In creation of the GUI, the difficulty is not in the layout or event processing, but in enabling wxWid-

gets [23] (Section 4.4.2) header files to be built alongside the simulations (to allow GUI programming)

and to halt the AntAlgGUISimulation on start-up to then restart it when the user has selected an

option. Changes to relevant CMake [14] (Section 4.4.1) build files are shown in Appendix B. The sim-

ulation is prevented from continuing by setting simulation timesteps to zero after which, on selecting

parameters and clicking the ’Start’ button the GUI adds the specified Ants and Items to the simulation,

calling its Init() function whereby the simulation is reset.

6.4 Iteration Two

The second iteration of the project addresses a number of the extended requirements, shown in Section

1.3

6.4.1 Graph Partitioning

The graph partitioning problem and algorithm presented in Section 3.4.1 requires little more work on

the part of designing a new ant. The SortingAnt class, shown in Section 6.2.4.2, can simply be sub-

31

classed whilst modifying the private instance variables to protected variables, allowing the sub-class to

modify them.

Figure 6.6 shows the architecture of the graph partitioning simulation. SortingAnt2 represents

the previous SortingAnt class but with protected variables. For the purpose of enhanced visuali-

sation, the Control() and PickUpItemAction() functions are overridden to re-position a held

item at the location of the ant at each time-step to enable the user to view the graph edges being manip-

ulated.

To represent nodes (or vertices) and edges of the graph, the Node class is utilised. Each Node

object holds references to other nodes in order to represent an edge, where Display() is overridden

from the drawable base class in order to draw the edges to neighbours on each timestep. To facili-

tate the partitioning of the graph, Equation 3.6 must be implemented within the Difference(i :

Item*) function, pseudocode for which is presented in Figure 6.7. GetDegree returns the degree of

the node (number of edges) and HasEdge(n : Node*) is true if the node has an edge reference to

the node n.

Figure 6.6: Classes for Ant based graph partitioning

Two views of the graph partitioning simulation are shown in Figure 6.8, where a randomly dis-

tributed graph is shown (Figure 6.8(a)) along with two GraphAnts carrying nodes (Figure 6.8(b)).

32

float Difference(otherNode):/** edges is a vector of nodes representing edges from this node.

* Functions called represent those within the Node class.

*/

degreeOfNode = otherNode.GetDegree()if degreeOfNode > 0 or edges.size() > 0 then{intersection = 0

for each nodeEdge in edges do{

if otherNode.HasEdge(nodeEdge)intersection++;

}

total = degreeOfNode + edges.size()symmetricDiff = total - (intersection * 2)

return float(symmeticDiff) / float(total)}

return 0.0;

Figure 6.7: Pseudocode for the Difference function within class Node

6.4.2 Enhanced Visualisation

Observations of the initial experiments have lead the Author to believe that the current method for

visualisation within BEAST [3] is not wholly suitable for the field of clustering/sorting. Two problems

are noted:

1. One cannot see cluster formations with great accuracy, as the small items used in simulations

often appear merged.

2. On attempting to select an item in a cluster the mouse accuracy is poor, leading to selection of

incorrect items and the accidental destruction of cluster formations.

A potential solution to this problem is to allow the ability to change between 2D orthographic projec-

tions and 3D perspective environments by abstracting the representation of Animats and WorldObjects

in BEAST [3]. The requirements of this modification are listed below.

33

(a) A randomly positioned graph (b) Two GraphAnts carrying nodes

Figure 6.8: Screenshots of GraphAnts at work

1. A 3D representation of simulations should allow for modification of camera postion through

mouse and keyboard interactivity (Sections 6.4.2.1 and 6.4.2.3).

2. Both Animats and WorldObjects should be rendered in 3 dimensions when required, allowing for

extensibility to further modify the 3D representation (Section 6.4.2.2).

3. Both Animats and WorldObjects should be at least selectable, and possibly adjustable, using the

mouse (Section 6.4.2.3).

The importance of having the functionality to select either Animats or WorldObjects within the

simulation has been emphasised because further implementations could allow for the Item class to

display information about itself on selection. Such information could be a numerical representation of

how well clustered it is or data representation of the item.

6.4.2.1 Making the World 3D

The World class, discussed in Section 4.2, is utilised by the BEAST [2] application to render the

simulation to which it belongs. A number of requirements are needed to enable the 3D visualisations:

1. A method of changing between 2D and 3D views.

2. A separate mechanism for 3D rendering.

34

3. An initial camera view.

4. Lights and lighting parameters to be used when rendering in 3D.

The initial requirement was met by modifying BEAST application source code in order to add the

option of choosing a 2D or 3D view, which in turn toggles the appropriate dimensionality in the World

class. This dimensionality is represented by an enumeration state within the class, which is used to facil-

itate the path of execution the class uses based on the rendering type. When the dimension is changed to

3, the world changes the projection matrix from orthographic to perspective and sets up the perspective

view.

Rendering is completed within the Display() function of the World class. In which, the

Display() function of all individual world objects is called in turn and other visualisations such

as selection indication are rendered. The 2D world is a pre-defined size in dimensions X and Y, thus

the world in 3D can be a simple abstraction of this where the Z dimension is positive upwards from the

world. In the third dimension render, the camera view is set, the floor of the world is drawn as a large

rectangle based on the original orthographic screen size and lighting is enabled.

Of course, these steps do not render Animats or WorldObjects in 3D, it simply creates the environ-

ment in order to do so. The next section handles the rendering of 3D objects within the world. A more

detailed overview of World class modifications can be seen in Appendix C.

6.4.2.2 3D Animats and WorldObjects

Creating an extensible architecture to allow for 3D Animats and WorldObject types to render in a generic

style, but also to provide extensibility, required investigation deeper into BEAST [2] documentation and

source code.

It is the Drawable class (Figure 4.2), base of all drawable objects, that provides the infrastructure

to enable extensible 2D rendering. On initialisation of Drawable, a display list is created in order to

optimise the rendering in the system. A display list is an OpenGL datatype that pre-compiles and stores

OpenGL instructions to improve code reuse and optimise rendering [22]. The display list contains the

contents of Draw(), a function containing the OpenGL rendering instructions for the drawable item,

35

which is overrided by base classes such as Animat to draw the circular creature. Another function of

importance is Render(), called on object creation to compile the display list.

Figure 6.9 shows the architecture of the classes that provide support for 3D simulations. Notice

that Animat3D and WorldObject3D inherit from Animat and WorldObject respectively, and

yet have the same class structure. It was decided that the source class structure should not be changed

at the Drawable level. The displaylist3D instance variable represents the index of the display

list containing the 3D OpenGL instructions contained in the function Draw3D(). The Render()

method, called for each object when updated by the world, chooses which draw style to use based on

which dimension the World class is in.

Figure 6.9: 3D Animat and WorldObject

Default WorldObject3D draw style is a sphere, due to the default WorldObject draw style

being a circle. Animat3D is slightly more advanced and is shown in Figure 6.10, where letter ’r’ in

the diagram represents the radius of the Animat object. The 3D Animat is simply a projection of the 2D

representation of the Animat into 3D, using a similar design, with wheels on either side and an arrow

atop to indicate the front. Figure 6.11 shows a comparison between the built in 2D drawable items and

the modified 3D.

6.4.2.3 Interaction

The World class already handles mouse interactivity in its existing form. A C structure type is used

within the class to record the state of the mouse, detailing button state and location of the mouse. Key-

36

(a) Front-on view of 3D Animat (b) Side view of 3D Animat

(c) Top view of 3D Animat

Figure 6.10: Schematics for the 3D Animat

board interaction is not handled, leading to the creation of a similar structure to record key state values.

Furthermore, the world class has been modified so that key events are passed into it from the underlying

application in order to update the keyboard interaction structure.

Bowman et al. [5, pp141-142] specifies three basic manipulation tasks for a 3D environment:

1. Selection - identifying a particular object from a set of objects and having feedback that the object

has been selected.

2. Positioning - Modifying the position of a 3D object within the world.

3. Rotation - Changing the orientation of some object.

The existing 2D world within BEAST [3] handles the tasks of selection, positioning and rotation.

The 3D implementation must handle at least selection in order to enable probing into data sets within

items. In [5, pp172-173] it is suggested that manipulations of individual objects in a 3D world is a

37

(a) Portion of 2D world containing Ani-

mats and WorldObjects

(b) 3D world using angled shot of the same

scene.

Figure 6.11: A portion of a simulation showing a 2D and 3D view

difficult task for users and is best handled via 2D controls within the 3D environment to modify separate

degrees of freedom (e.g. using 2D widgets such as scroll bars) or through providing separate ortho-

graphic plan-like views of the environment. Due to the built in 2D view of the environment in BEAST,

positioning and rotation of objects will be restricted to this view only.

In the 2D representation, the World class catches left mouse button events and attempts to map the

location of the click to being within or close to a particular object. The object is notified of its selec-

tion and on the next rendering cycle a translucent disk is placed under the item to indicate a successful

selection to the user. In orthographic 2D this mouse interactivity is simple, but in perspective 3D it

is no simple task. To simplify things, OpenGL [22] provides a specialised picking mechanism which

renders the scene in memory and based on an area defined around a mouse click can retrieve hits on the

objects within the scene. Program code to perform this action was based around source code provided

by Ruddle [20] from his module, advanced computer graphics, where the aim is to demonstrate picking

from several cubes.

In designing a system to enable travel around the 3D world, it was decided that a approach should

be taken in which a floating camera above the world looks at a particular position within the floor plane.

38

The user then controls the camera and look-at position, providing simple movement and rotation. Given

that the look-at vector is restricted to the plane of the floor area, controlling the camera becomes quite

simple. The basic set up is shown in Figure 6.12 and a shot of the implemented solution is shown in

Figure 6.13

By dragging the mouse left or right whilst depressing the right mouse button, the camera is spun

around the axis of rotation in the desired direction. The axis of rotation is simply the look-at vector

modified to have a positive Z component. Dragging the mouse upwards or downwards causes the world

to turn around the axis of world rotation, computed as the normal to the triangle formed by the camera

and the axis of camera rotation. The angles of rotation used are inversely proportional to the distance

between the camera and the look-at vectors, in order to make rotation slower when the camera is very

close to the floor.

The camera and look-at locations are modified simultaneously by pressing the arrow keys. The up

arrow simply increases the vectors of camera and look-at by a factor of the normalised difference be-

tween the two, keeping the Z component of each vector as it was previously. Similarly, decreasing the

vectors by the normalised difference value gives backwards motion. To strafe left (left arrow) and right

(right arrow) a similar process is undertaken, but by using the world axis of rotation as a direction (see

Figure 6.12).

Lastly, to facilitate zooming in and out, mapped to + and - keys respectively, the camera is sim-

ply moved along the direction between the look-at vector and itself. The vector used to zoom is the

normalised difference between the two, multiplied by some pre-determined movement factor.

39

Figure 6.12: A diagram displaying the camera system

Figure 6.13: A screenshot of the world from a high camera view. The look-at location is marked with a

cross to help user navigation.

40

Chapter 7

Evaluation

7.1 Overview

Within this chatper, the solutions produced throughout the project, and the style of the project itself will

be evaluated.

7.2 Evaluation of Simulations

In [13], a number of complex statistical evaluation criteria have been identified. For example, the

purity of clusters and inter-cluster variance are examined. This evaluation uses much fewer criteria, but

attempts to give a varied look at different aspects of analysing the solutions.

7.2.1 Clustering

Rather than simply present a number of images showing the success of clustering (or not) it was decided

that in this section a statistical approach should be taken. In clustering, the goal would be to produce

one cluster of all items, but this does not necessarily occur as the number of items increases. The graph

of Figure 7.1 shows timesteps against the average euclidean distance between every pair of items in the

simulation. 3 sets of results are shown, each averaged over 5 runs, where the number of items of each

41

results set is shown on the graph. The parameters used, shown in Figure 7.1, are those suggested by [7].

The average number of clusters generated for 100 items is 1, 200 items produces an average of 3.2

clusters and 300 items results in an average of 4.4 clusters. It would seem that the optimal number of

timesteps is around that of 106. As the number of items increases, the number of strong clusters also

increases, thus it is logical to assume that many strong clusters will exist due to the size of the local

density function of the ants. Increasing the size of the detection area causes less clusters, but the clusters

appear more dispersed in space.

Figure 7.1: Graph showing simulation timesteps against the average distance between each pair of items.

Three data sets are presented, representing average results for simulations with 100 items, 200 items and

300 items.

42

7.2.2 Sorting with Colour

Analysis of colour sorting is performed in this section. Both the situated and non-situated solutions are

presented.

7.2.2.1 Non Situated Solution

Bonabeau et al. [4] suggests an effective method of analysing the effectiveness of a sorting implemen-

tation. This is done by inspecting the distance in space of each pair of items (as ‖wi−w j‖) against

the difference (d(oi,o j)) of the pairs. To do this, a set of items needs to be generated to have a diverse

attribute space (e.g. many different values for d(oi,o j)). Figure 7.2 shows 100 items with randomly

distributed attributes in red and green colour space. The parameters are those suggested in [17].

The resulting scatter graph shows a correlation between difference in euclidean space and attribute

space. There is a strong cluster where the difference in both spaces is very low and vice versa. Some

items have been clustered in far space but have low difference, probably due to two strong clusters being

formed.

7.2.2.2 Situated Solution

As a short demonstration of the situated approach working, the clustering images of a particular run are

shown in Figure 7.3. The process results in two clusters as expected, yet the clusters seem quite sparse

in comparison to results found without using the sensor system within BEAST. Further work may have

to be done in order to fully test the output of sensors in comparison to the non-situated approach to

fully comprehend this phenomenon. Note that the situated solution runs at much slower speed that other

solutions, this is due to the four sensors used for each Ant and the need for BEAST to process each one

sequentially. Each sensor is passed all objects, putting approximately 4n more processing load on each

ant where n is the number of objects in the simulation.

7.2.3 Graph Partitioning

To test the graph partitioning algorithm, a simple test graph is used. The graph consists of 40 vertices

and is effectively two fully connected graphs, with no edge connecting the two graphs. The results are

shown in Figure 7.4, where parameters are suggested in [15]. The two test graphs are fully sorted into

43

Figure 7.2: A scatter graph showing, for each pair of items, ‖wi−w j‖ as a function of d(oi,o j) using

100 items, where k1 = 0.1, k2 = 0.15, α = 0.5, radius = 6.0 and n = 9

two clusters after 106 timesteps, where no edge joins the two clusters, as expected.

7.3 UI and 3D World

The UI interface built and the 3D world extensions are not undergone evaluation to any external scrutiny.

The reason for this in relation to the UI is the prerequisite that the user be able to understand the sorting

and clustering algorithms before exploring the simulations.

The observed benefits of the UI are the expendable design, allowing for more algorithms to be po-

tentially added in the tabbed panel and that it provides quicker accessability to the simulations than the

use of a simple configuration file. A negative point is the general lack of instruction when using it, where

in particular a description of the algorithms that are being modified should be built into the system as a

44

help function.

The purpose of the 3D world was to enable more detailed views of simulations and to provide a

more competent manner of selecting objects than the 2D view. These points have been achieved, and it

is felt that the interactivity style is intuitive whilst remaining simple. As a matter of taste and style, the

values used to determine rotation and movement of the camera may need to be tweaked to provide more

fluid motion.

7.4 Project Evaluation

One each of the clustering and sorting algorithms were implemented as in the minimum requirements,

with minor changes, within the BEAST environment. In building the simulations, a simple and yet ef-

fective architecture of Ant and Item classes were created, allowing for powerful extensibility should

future project students wish to implement similar algorithms. Each simulation type is shown to have

desireable properties and to perform the required tasks. Furthermore a simple GUI has been created to

enable a level of user interaction to the parameters of the implemented algorithms, which should be eas-

ily expendable by simply adding more algorithms to the tabbed pane towards the bottom of the window.

Although not all possible extensions to the minimum requirements were undertaken, those that were

have been successful. The graph partitioning solution provides a lively and intuitive visualisation of the

process. Further, the 3D world providing the ability to get up and close to world items provides the

ability to view clusters in much greater detail. The ability to select items in the 3D space would allow

for programmers to extend the Item class in order for the contents to be simply printed to the command

line.

7.5 Further Work

Having not met a couple of the extended requirements, it seems that future projects may be able to take

these tasks on-board in order to extend this project. For example, investigating the dynamics of sorting

real-world data, such as database records, could produce a project that implements far more efficient or

powerful algorithms using the simulations created in this project as a starting point.

45

Additionally, further work may wish to focus on the areas of particular flaw within this project,

which need to be improved. Greater time needs to be spent analysing the simulations produced in order

to justify that they perform as well as those in the literature. The interface systems built into the project,

both GUI and 3D visualisation, could benefit from extensive re-work. Taking the 3D visualisation im-

plementation for example, it may be that a future project would be completed in order to focus on this

aspect, improving rendering quality, interactivity style and extending it to include new features.

Relating to the idea of extending the 3D aspects of the new visualisation implementation, a fu-

ture project may wish to investigate as to whether it would be possible, or even worthwhile, extending

BEAST to provide simulations that use 3D space rather than operating in 2D. This would involve mak-

ing large changes to many underlying systems and may be too large a tasks for a project of this size if

the project aims to convert the entirety of BEAST.

Finally, it may be that the BEAST itself could be evaluated. In particular, how it performs as a

framework, with reference to example simulations created here and a number of others created by the

Student. In performing the evaluation, other frameworks of a similar nature should be compared and

contrasted. A popular system exists called StarLogo, created by Resnick [19], which is a powerful

extension of the popular turtle graphics application, Logo. StarLogo boasts full parallelism of agents

and simple programming API, whereas BEAST does not, and yet it is unlikely that StarLogo provides

such a massive selection of Bioinspired implementations, such as genetic algorithms, that are present

within the BEAST framework [2].

46

(a) Initial state of situated simulation. (b) Distribution of items at 500,000 timesteps.

(c) Distribution of items at 106 timesteps.

Figure 7.3: The situated solution to sorting, showing the algorithm at various timesteps using a set of

100 item types, randomly distributed between red and green colours. Uses k1 = 0.1, k2 = 0.15, α = 0.5,

radius of sensors = 4.5

47

(a) Initial state of graph partitioning simulation. (b) Distribution of nodes at 500,000 timesteps.

(c) Distribution of nodes at 106 timesteps.

Figure 7.4: The graph partitioning solution, showing the algorithm at various timesteps sorting two

individual fully connected graphs randomly distributed. Uses k1 = 0.1, k2 = 0.15, α = 0.5, n = 9,

radius = 6.0

48

Bibliography

[1] Ambler, S. W. Agile Modelling: Effective Practices for Extreme Programming and the Unified

Process. John Wiley & Sons, 2002.

[2] BEAST. BEAST - Bioinspired Evolutionary Agent Simulation Toolkit Documentation.

http://www.comp.leeds.ac.uk/ai23/BEAST/doc/index.html [accessed 14/04/2009], 2004.

[3] BEAST. BEAST: Bioinspired Evolutionary Agent Simulation Toolkit.

http://www.comp.leeds.ac.uk/ai23/BEAST [accessed 10/12/2008], 2008.

[4] Bonabeau, E., Dorigo, M. and Theraulaz, G. Swarm Intelligence. Oxford University Press, New

York, 1999.

[5] Bowman, D. A., Kruijff, E., LaViola, J. J. and Poupyrev, I. 3D User Interfaces: Theory and

Practice. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 2004.

[6] Brooks, R. A. Intelligence Without Reason. In The 1991 International Joint Conference on AI,

Sydney, Australia, 1991. IJCAI (International Joint Conferences on Artificial Intelligence).

[7] Deneubourg, J., Goss, S., Franks, N., Sendova-Franks, A., Detrain, C. and Chretien, L. The Dy-

namics of Collective Sorting: Robot-Like Ant and Ant-Like Robot. In J. A. Meyer and S. W.

Wilson, editors, Proceedings First Conference on Simulation of Adaptive Behaviour: From Ani-

mals to Animats, Cambridge, MA, 1991. MIT Press.

[8] A. Feder. BIBTEX.org. http://www.bibtex.org/ [accessed 28/04/2009], 2006.

[9] Floyd, C. A Systematic Look at Prototyping. Approaches to Prototyping, pages 1–18, 1984.

[10] Fores, S. Latex Template for Final Year Projects. University of Leeds, 2008.

49

[11] Garey, M. R. and Johnson, D. S. Computers and Intractability; A Guide to the Theory of NP-

Completeness. W. H. Freeman & Co., New York, NY, USA, 1990.

[12] Garey, M. R., Johnson, D. S. and Stockmeyer, L. Some Simplified NP. Complete Graph Problems.

Theoretical Computer Science, 1:237–267, 1976.

[13] Handl, J. Ant-based methods for tasks of clustering and topographic mapping: improvements,

evaluation and comparison with alternative methods. Master’s thesis, Universitat Erlangen-

Nurnberg, Erlangen, Germany, 2003.

[14] Kitware. Cmake. http://www.cmake.org/cmakeindex.html [accessed 10/12/2008], 2008.

[15] Kuntz, P., Layzell, P. and Snyers, D. A Colony of Ant-Like Agents for Partitioning in VLSI

Technology. In Proceedings Fourth European Conference on Artificial Life, Cambridge, MA,

1997. MIT Press.

[16] LATEX. LaTeX - A document preparation system. http://www.latex-project.org/ [accessed

28/04/2009], 2009.

[17] Lumer, E. and Faieta, B. Diversity and Adaptation in Populations of Clustering Ants. In Proceed-

ings Third International Conference on Simulation on Simulation of Adaptive Behaviour: From

Animals to Animats, Cambridge, MA, 1994. MIT Press.

[18] Object Management Group. OMG Unified Modeling Language Specification, 1.5 edition, 2003.

[19] Resnick, M. Turtles, Termites, and Traffic Jams. MIT Press, Cambridge, MA, 1997.

[20] Ruddle, R. GI31 - AGR Advanced Computer Graphics: Object Selection and Manipulation

Exercises. http://www.comp.leeds.ac.uk/royr/gi31/exercises/gi31-ex-obj-manip.html [accessed

28/04/2009], 2004.

[21] SGI. OpenGL The Industry’s Foundation for High Performance Graphics. http://www.opengl.org

[accessed 21/04/2009], 2009.

[22] Shreiner, D. OpenGL(r) Reference Manual: The Official Reference Document To OpenGL, Version

1.4. Pearson Education, 4 edition, 2004.

[23] wxWidgets. Tutorials. http://www.cmake.org/cmakeindex.html [accessed 11/12/2008], 2008.

50

Appendix A

Personal Reflection

A major positive aspect for this project was in the development of simulations and in the extended visu-

alisations within BEAST. This allowed me to tackle a reasonably sized coding problem in an unfamiliar

language (C++) which is, personally, an enjoyable and rewarding task. Yet, little structure was followed

in implementation, whereby the final plan of performing two iterations was not completely adhered to,

especially when creating the GUI which became a problem later in the project and wasn’t available for

demonstration.

The created plan and methodology was quite successful, with the exception of planning project

report writing which was greatly underestimated. The use of prototyping in initial stages helped me

reinforce my perception as to whether the algorithms were implemented correctly. Evolutionary pro-

totyping is certainly a reccommended style of programming for this particular style of project, where

potentially difficult implementations can be drafted in quick succession without having to adhere to a

particular programming style and then developed into more professional solutions at a later stage.

It was certainly felt that the emphasis of the project was a little muddled, focusing on the ant inspired

algorithms but spending up to half of the implementation time creating the 3D world. In hiensite, and

through further background reading during the project, it was found that the algorithms discussed and

51

implemented were certainly at developmental stages and more interesting, complex and more successful

algorithms exist. It would have been more in-keeping to the style of the project if these algorithms were

implemented, they certainly would have resulted in better results in the evaluation. This would suggest

that a more extensive literature search should have been conducted initially.

A major negative of the project is the evaluation. Although many potential standards of evaluating

such solutions were investigated, they were never completed due to time constraints and the complexity

of the evaluation criteria found. It may have also made sense to evaluate the algorithms against other

traditional approaches, such as K-means clustering, to demonstrate how well they perform in compari-

son. Also, no evaluation of the UI or 3D world is provided, partly because the UI was very simple, but

some evaluation of usage would have benefited the report.

Finally, as a piece of advice to future students, I would certainly take into account the technology

that may be used in a project before committing. This project has used C++ throughout, including extra

libraries to create the GUI, and yet I was certainly not wholly comfortable with the language and had

never been introduced to the GUI programming style. Less confident programmers may want to think

twice before tackling such a problem.

52

Appendix B

BEAST Source Mods

This Appendix gives a brief description of the modifications made to the existing BEAST [2] framework

source code in order to make some of the components of this project fully work.

B.1 CMake Changes

Within the beast/projects folder, the CMake [14] build file (CMakeLists.txt) has been modified

to:

SET(wxWidgets_USE_LIBS base core gl net)FIND_PACKAGE(wxWidgets)if(wxWidgets_FOUND)

INCLUDE(${wxWidgets_USE_FILE})include_directories (${BEAST_SOURCE_DIR}/libs ${wxWidgets_INCLUDE_DIRS} )

else(wxWidgets_FOUND)Message("wxWidgets not found!")

endif(wxWidgets_FOUND)

set( beast_SRC# ant1.cc# bacteria.cc# mouse.cc

53

# shrew.cc# ant.cc# braitenberg.cc# pacman.cc# signal.cc# baccyexamples.cc# chase.cc# cluster01.cc

demos.cc# poolbots.cc# sigtest.cc)

add_library (demos SHARED demos.cc)add_library (mouse SHARED mouse.cc)

This modification includes the header files for wxWidgets [23] in order to build the project GUI.

54

Appendix C

The BEAST World Class

A brief summary of the major modifications to the World class are shown in the class diagram on the

next page.

55

56