Upload
tranminh
View
221
Download
0
Embed Size (px)
Citation preview
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