Faculteit Toegepaste WetenschappenFaculteit Wetenschappen

Vakgroep Toegepaste Wiskunde en InformaticaVoorzitter: Prof. dr. G. Crombez

Agent-gebaseerd modelleren in Swarm

door Bernard Vanneste

Promotor: prof. W. Bossaert

SCRIPTIE ingediend tot het behalen van de academische graadvan licentiaat in de informatica, optie: toepassingsgerichte

informatica

Academiejaar 2000–2001

i

Toelating tot bruikleen

De auteur geeft de toelating deze SCRIPTIE voor consultatie beschikbaar te stellen

en delen van de SCRIPTIE te copieren voor persoonlijk gebruik. Elk ander gebruik

valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot

de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit

deze SCRIPTIE.

Bernard Vanneste 28 mei 2001

ii

Dankwoord

Graag zou ik iedereen willen bedanken die heeft bijgedragen tot de verwezenlijking van

dit eindwerk, zonder hen zou dit werk niet zijn wat het geweest is. In het bijzonder

vermeld ik:

• Prof. Walter Bossaert voor de steun, het geloof, de inzet, de ideeen en de hulp;

• John Lievens, voor zijn prachtige assortiment aan aangeboden toepasbare proble-

men, en hulp;

• de ganse Swarm Community, voor het opzetten en onderhouden van zo’n prachtige

technologie, en alle andere mensen die van Swarm maakten wat het nu is, zodat

ik dit stuk er over kon schrijven.

• mijn familie en vrienden, voor de steun, en in het bijzonder:

• Gino Landerwyn, voor het delen van ideen, vooral met betrekking tot de mo-

gelijkheden van agent-gebaseerde applicaties;

• Koen Martens en Dirk Vansteelant, voor het openstaan voor mijn soms wereld-

vreemde ideeen en de rest: blijf lachen en denkt nog een keer aan mij als ge in

het rusthuis zit;

• Frederik Adam, Tim Naessens, Sam Lerouge, Tim Stevens, Katrien Van Drogen-

broek, en de anderen, voor de gezellige sfeer in de lessen en over de middag.

• Tim Desplenter, voor het kritisch verdelen van mijn werktijd.

• Stijn Roelens, voor de hints en het lichtend voorbeeld.

• Pieter Claerhout, voor het fantastisch professioneel bekritiseren van de grafische

kant op mijn aanvraag.

• Alex: omdat hij toch zo graag in mijn dankwoordje wou staan.

• alle goeie muzikanten die de saaie kant van het werk deden voorbijvliegen : keep

on rocking in the free world !

• de geduldige lezers, voor hun geduld.

• mijn kamerplantjes, omdat ze er echt altijd waren.

iii

Agent-gebaseerd modelleren in Swarm

door

Bernard Vanneste

Afstudeerwerk ingediend tot het behalen van de graad van licentiaat in de informatica,

optie: toepassingsgerichte informatica

Academiejaar 2000–2001

Universiteit Gent

Faculteit Toegepaste Wetenschappen

Faculteit Wetenschappen

Promotor: prof. W. Bossaert

Samenvatting

Computerprogramma’s zijn er al van voor het begin van de computers. Ze hebben

in de loop der jaren een grote evolutie ondergaan, met als laatste ontwikkelingen de

OO-technieken en de nuts-and-bolts paradigma’s. Omdat bij hardware het einde van

de versnelling van processoren in zicht komt, zal in de toekomst meer efficientie moeten

gehaald worden uit de bestaande hardware. Een techniek die deze uitdaging aangaat is

het agent-gebaseerd programmeren, een techniek die door het imiteren van de natuur

(denk maar aan een mierenkolonie of een bijenzwerm) een hogere realiteitsgraad (voor

simulaties) en een intelligenter resultaat probeert te bieden, door een massa-aanpak

met de “de som is meer dan het geheel der delen” denkwijze.

Er wordt even overlopen wat deze techniek nu juist inhoud, in het bijzonder het

Swarm-platform, dat in ’94 door Chris Langton als een project aan de universiteit van

Santa Fe werd opgestart, en sindsdien een dynamisch project is gebleven, met een grote

aanhang, dat zich stilaan aan het vestigen is als ontwikkelingsplatform voor dergelijke

software.

Het eindwerk wordt geconcretiseerd met het ontwerp en realisatie van een proto-

type. Dit handelt over het simuleren van een huwelijksmarkt, die voor een groot deel

parametriseerbaar zal moeten worden, teneinde onderzoeken naar gelijkaardige proble-

men zonder veel moeite ook te kunnen onderzoeken.

Trefwoorden: agent, Langton, swarm, simulatie .

Inhoudsopgave

1 Inleiding: Over agenten en hun wereld 1

1.1 Wat is een agent eigenlijk? . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Definities van agenten . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Gewenste eigenschappen . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Eigen definitie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 SWARM 9

2.1 Ontstaan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Distributie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Swarm is GNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2 Object C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.4 Object C versus Java . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.5 Doel van Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 SDG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Algemene Structuren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.1 Swarms (zwermen) . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.2 Observer swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.3 Model swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.4 Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Specifieke structuren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.1 CreateBegin en createEnd . . . . . . . . . . . . . . . . . . . . . . 16

2.6.2 Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6.3 EZGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6.4 Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18iv

INHOUDSOPGAVE v

2.6.5 Actiongroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.7 Toepassingsgebieden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.7.1 SFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.7.2 UCLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7.3 Andere universiteiten . . . . . . . . . . . . . . . . . . . . . . . . 21

2.8 Verdere ontwikkelingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.8.1 Annual report 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.9 Verdere informatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.9.1 The Swarm Community . . . . . . . . . . . . . . . . . . . . . . . 22

3 Het proto-type 24

3.1 Wat wordt er verwacht ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.1 Kennismaking met Swarm . . . . . . . . . . . . . . . . . . . . . . 24

3.1.2 Het experiment: algemene noties . . . . . . . . . . . . . . . . . . 25

3.1.3 Het experiment: meer specifiek . . . . . . . . . . . . . . . . . . . 25

3.1.4 Het experiment: bijkomende complexiteit . . . . . . . . . . . . . 26

3.2 Het eerste simulatieprogramma . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Bijsturing van het prototype . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 Opdelingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2 Extra kenmerken . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.3 Verdelingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.4 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 De implementatie 32

4.1 Een eerste versie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1 Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.2 De observer swarm . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.3 De model swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.4 De bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.5 Functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Een intermediaire versie . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.1 Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.2 De observer swarm . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.3 De model swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

INHOUDSOPGAVE vi

4.2.4 De bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 De finale versie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.1 Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.2 De observer swarm . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.3 De model swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.4 De bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.5 Functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4 Volgende versies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.1 Generaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.2 Meerdere niveau’s van swarms. . . . . . . . . . . . . . . . . . . . 51

4.4.3 Run time de parameters kunnen wijzigen . . . . . . . . . . . . . 51

5 Functionaliteit en interpretatie 53

5.1 Functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Wat is mogelijk? . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.2 Wat kan er niet? . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.3 Meerwaarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Interpretatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.1 Aard van de interpretatie . . . . . . . . . . . . . . . . . . . . . . 55

6 Besluit 57

6.1 Verwezenlijkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2 Observaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2.1 Nieuw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2.2 Anders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2.3 Technisch-filosofisch . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2.4 Technisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2.5 Opstarttijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3 Enkele laatste bedenkingen . . . . . . . . . . . . . . . . . . . . . . . . . 60

A Verklarende woordenlijst 1

B SDG 2000 Annual Report 1

C De Thesis 1

INHOUDSOPGAVE vii

D De applicatie installeren 1

D.1 Swarm installeren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

D.1.1 Swarm volledig installeren . . . . . . . . . . . . . . . . . . . . . . 1

D.1.2 Minimale installatie . . . . . . . . . . . . . . . . . . . . . . . . . 1

D.1.3 Swarm onder Linux . . . . . . . . . . . . . . . . . . . . . . . . . 2

D.2 De applicatie uitvoeren. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

D.2.1 Het controlevenster . . . . . . . . . . . . . . . . . . . . . . . . . . 2

D.2.2 De model swarm probe . . . . . . . . . . . . . . . . . . . . . . . 3

D.2.3 De observer swarm probe . . . . . . . . . . . . . . . . . . . . . . 3

D.3 Resultaten uit de applicatie halen . . . . . . . . . . . . . . . . . . . . . . 4

D.3.1 Het bestand “huwbugs.scm” . . . . . . . . . . . . . . . . . . . . . 4

D.3.2 Het gebruik van de parameters . . . . . . . . . . . . . . . . . . . 5

D.3.3 Het gebruik van de model swarm probemap . . . . . . . . . . . . 5

E Uitleg bij de bijgevoegde CD-Rom 1

E.1 Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

E.2 Interessante zaken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

F The Game Of Life 1

G Cellular Automata 1

Lijst van figuren

2.1 Logo van de Swarm Development Group . . . . . . . . . . . . . . . . . . 14

2.2 varProbes en messageProbes . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 voorbeeld van een EZGraph . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Structuur van de applicatie . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Interface eerste versie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Interface intermediaire versie . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 Interface finale versie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

D.1 Wat men te zien zou moeten krijgen net na het starten van het programma. 6

D.2 Twee nieuwe vensters openen. . . . . . . . . . . . . . . . . . . . . . . . . 7

D.3 Het controlevenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

D.4 De modelswarm Probe. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

D.5 De observerswarm Probe. . . . . . . . . . . . . . . . . . . . . . . . . . . 8

viii

Lijst van tabellen

3.1 voorbeeldoutput verhouding geslacht-etniciteit . . . . . . . . . . . . . . 31

3.2 voorbeeldoutput verhouding geslacht-opleidingsniveau . . . . . . . . . . 31

D.1 voorbeeldoutput verhouding geslacht-etniciteit . . . . . . . . . . . . . . 6

D.2 voorbeeldoutput verhouding geslacht-opleidingsniveau . . . . . . . . . . 8

D.3 voorbeeldoutput verhouding geslacht-leeftijdsniveau . . . . . . . . . . . 9

D.4 voorbeeldoutput verhouding geslacht-dummy . . . . . . . . . . . . . . . 9

ix

Hoofdstuk 1

Inleiding: Over agenten en hunwereld

”Too bad all the people that know

how to run the country are busy

driving taxicabs and cutting hair.”

- George Burns

Computerprogramma’s zijn er al sinds het begin van de computer. Ze hebben in de

loop der jaren een grote evolutie ondergaan, met als laatste ontwikkelingen de object

georienteerde technieken en de nuts-and-bolts paradigma’s. Omdat bij hardware het

einde van de versnelling van processoren met de huidige technologie in zicht is, zal in de

toekomst meer efficientie moeten gehaald worden uit de bestaande hardware. Parallelle

technieken slaan al gedeeltelijk deze weg in, maar nog meer alternatieven staan in de

steigers om op grote schaal hun weg te vinden naar de programmeur.

Enkele van deze alternatieven proberen de natuur of een welbepaald deel uit de

natuur, zoals het menselijk brein, na te bootsen om zo betere resultaten te behalen. Een

andere techniek uit deze hoek is die om met behulp van massa-technieken, gebaseerd op

het idee van een zwerm of kolonie, een hogere graad van automatisatie of intelligentie te

bereiken. Een programmeertechniek die het beste uit de bijenzwermen, mierenkolonies

of termietgemeenschappen probeert te halen, en dit door bepaalde structuren en ideeen

ervan te imiteren en implementeren. Deze gedachtengang is een van de startpunten van

dit eindwerk.

Een van de eerste en belangrijkste noties in dit milieu is het begrip agent, agens,

actor, of welke van de vele namen waarmee ook naar deze eenheid wordt verwezen. Het

is de bouwsteen bij uitstek, vergelijkbaar met de werkmier of werkbij in de kolonie.1

Wat is een agent eigenlijk? 2

De ontwikkelaars van het Swarm-platform hebben het idee van zo’n gemeenschap

van agenten in een software-ontwikkelingsomgeving omgezet. Hoe het precies allemaal

in elkaar zit en welke de mogelijkheden zijn probeer ik in dit eindwerk te verduidelijken,

ook aan de hand van een implementatie.

Een beetje situering kan geen kwaad, maar “In der Beschrankung zeigt zich der

Meister”, een goede reden om hier wat verder van wal te steken:

1.1 Wat is een agent eigenlijk?

1.1.1 Definities van agenten

Hier vindt u enkele definities gegeven door andere (groepen van) mensen die in de wereld

van het programmeren zich al op dit onderwerp hebben toegelegd, of de techniek op

de een of andere manier formeel al hebben benaderd. Het is de bedoeling duidelijk

te maken hoe onduidelijk de lijnen op speelveld van het begrip agent zijn getrokken,

en het mogelijk maken van onderscheid tussen wat een agent zal genoemd worden, en

andere computerprogramma’s, code, automaten en dergelijke, in zover dit mogelijk is.

De reikwijdte van het begrip agent schept veel onduidelijkheid, en moet altijd in de

goede context gezien worden. Is de wereld zelf een agent? Zijn parameters agenten?

Uiteindelijk intrageren ze allemaal ergens wel met hun iets of iemand. Met de omvang

van het begrip kan gespeeld worden, en meestal worden definies met een specifieke

toepassing in het achterhoofd aangemaakt.

De biologische agent

De agent in de biologische betekenis, waarvan werd uitgegaan bij deze technologie,

heeft een betrekkelijk eenvoudige structuur, maar kan in groepsverband een heleboel

verwezenlijken, iets waartoe de kleine geleedpotigen op het eerste zicht niet toe in staat

lijken.

Neem bijvoorbeeld de bij. Een echte definitie in de computerwetenschappelijke zin

is niet onmiddelijk voorhanden, maar de kleine bijtjes zijn als groep in staat een grote

korf te bouwen, de winter te overleven en nieuwe kolonies te stichten. Een konigin is

niets anders dan een gewone werkbij die vanaf haar geboorte meer te eten kreeg, en op

volwassen leeftijd een nieuwe korf gaat stichten. Bij de faraomieren is deze eigenschap

nog prominenter: elke verdwaalde werkmier kan zelf een nieuwe konigin worden, eitjes

beginnen leggen en een nieuwe kolonie oprichten.

Wat is een agent eigenlijk? 3

Je zou het deze kleine insekten niet nageven, maar sommige afrikaanse mieren-

soorten zijn in staat gebieden te ontbossen of oorlogen te voeren tegen rivaliserende

kolonies.

Toch weet men dat elke kleine mier of bij op zijn eigen maar over een zeer beperkte

intelligentie beschikt, en niet in staat is te beseffen aan welk groter doel hij meewerkt.

Het succes van deze diertjes blijft geheim. Een deel wordt hoogst waarschijnlijk geleverd

door hun aantallen, een ander deel door de structuur ervan.

De IBM agent

(http://activist.gpl.ibm.com:81/WhitePaper/ptc2.htm)

“Intelligent agents are software entities that carry out some set of operations on behalf

of a user or another program with some degree of independence or autonomy, and in

so doing, employ some knowledge or representation of the user’s goals or desires.”

Deze definitie, van IBM’s “Intelligent Agent Strategy white paper”, ziet een (intel-

ligente) agent als een handelaar in dienst van iemand of iets anders, en representeert

dus ook die andere als dusdanig, een soort van plaatsvervangende opdrachtgever, met

een graad van zelfstandigheid. Deze definitie is niet echt een goeie definitie, zonder de

bepaalde graad van zelfstandigheid, kan ongeveer alle code als agent beschouwd wor-

den, want ongeveer alle code voert zichzelf wel uit als handelaar voor een gebruiker of

een ander programma. Bovendien is het begrip “bepaalde mate van zelfstandigheid”

toch behoorlijk vaag.

De MuBot agent

(http://www.crystaliz.com/logicware/mubot.html)

“The term agent is used to represent two orthogonal concepts. The first is the agent’s

ability for autonomous execution. The second is the agent’s ability to perform domain

oriented reasoning.”

Deze maatstaf voor agent-definities komt van een white paper door Sankar Vird-

hagriswaran van Crystaliz, Inc., die het hier over mobiele agenten heeft (die zichzelf

kunnen verplaatsen, ook bvb. van pc naar pc). Autonomie is duidelijk een belangrijk

centraal punt. Het tweede is meer met het oog op het resultaat toegevoegd.

De Maes Agent

[Maes, Pattie (1990) ed., Designing Autonomous Agents, Cambridge, MA: MIT Press]

“Autonomous agents are computational systems that inhabit some complex dynamic

Wat is een agent eigenlijk? 4

environment, sense and act autonomously in this environment, and by doing so realize

a set of goals or tasks for which they are designed”

Pattie Maes wordt beschouwd als een pionier op het gebied van Agent-onderzoek,

en werkt bij MIT’s Media Lab. Het belangrijkste aan haar definitie is dat ze een doel

toevoegt aan de definitie van agent. Een agent heeft een welbepaald doel, en moet die

autonoom in een veranderende (dynamische) omgeving proberen te realiseren.

De AIMA Agent

[Russell, Stuart J. and Peter Norvig (1995), “Artificial Intelligence: A Modern Ap-

proach”, Englewood Cliffs, NJ: Prentice Hall]

“An agent is anything that can be viewed as perceiving its environment through sensors

and acting upon that environment through effectors.”

AIMA staat voor “Artificial Intelligence: a Modern Approach”. De auteurs waren

voornamelijk geınteresseerd in het insluiten van AI-technieken in agenten. Het is

duidelijk dat deze definitie vooral afhangt van wat er gedefinieerd is als omgeving,

en wat er met voelen en reageren op de omgeving bedoeld wordt. Er moet ook een

omgeving worden gedefinieerd en een strengere definitie van interaktie.

Dit waren de belangrijkste definities. Er zijn er nog een aantal andere die ik niemand

wil ontzeggen.

• De KidSim Agent [Smith, D. C., A. Cypher and J. Spohrer (1994), “KidSim:

Programming Agents Without a Programming Language,” Communications of

the ACM] “Let us define an agent as a persistent software entity dedicated to a

specific purpose. ’Persistent’ distinguishes agents from subroutines; agents have

their own ideas about how to accomplish tasks, their own agendas. ’Special

purpose’ distinguishes them from entire multifunction applications; agents are

typically much smaller.”

• De Hayes-Roth Agent [Hayes-Roth, B. (1995). “An Architecture for Adaptive

Intelligent Systems,” Artificial Intelligence: Special Issue on Agents and Inter-

activity] “Intelligent agents continuously perform three functions: perception of

dynamic conditions in the environment; action to affect conditions in the envi-

ronment; and reasoning to interpret perceptions, solve problems, draw inferences,

and determine actions.”

Gewenste eigenschappen 5

• De WooldridgeJennings Agent [Wooldridge, Michael and Nicholas R. Jen-

nings (1995), “Agent Theories, Architectures, and Languages: a Survey,” in

Wooldridge and Jennings Eds., Intelligent Agents, Berlin: Springer-Verlag] “...

a hardware or (more usually) software-based computer system that enjoys the

following properties:

autonomy: agents operate without the direct intervention of humans or others,

and have some kind of control over their actions and internal state;

social ability: agents interact with other agents (and possibly humans) via some

kind of agent-communication language;

reactivity: agents perceive their environment, (which may be the physical world,

a user via a graphical user interface, a collection of other agents, the INTERNET,

or perhaps all of these combined), and respond in a timely fashion to changes that

occur in it;

pro-activeness: agents do not simply act in response to their environment, they

are able to exhibit goal-directed behavour by taking the initiative.”

• De SodaBot Agent [Michael Coen http://www.ai.mit.edu/people/sodabot/

slideshow/total/P001.html] Software agents are programs that engage in dialogs

[and] negotiate and coordinate transfer of information

• De Brustoloni Agent [Brustoloni, Jose C. (1991), “Autonomous Agents: Char-

acterization and Requirements,” Carnegie Mellon Technical Report CMU-CS-91-

204, Pittsburgh: Carnegie Mellon University] Autonomous agents are systems

capable of autonomous, purposeful action in the real world

1.2 Gewenste eigenschappen

Een eenduidige definitie van “agent” is hiermee nog niet in het vooruitzicht, maar alles

hangt bij zo’n definitie af van de toepassing. Een andere aanpak is misschien voor de

hand liggender: hier volgen enkele meer algemene eigenschappen die in een bepaalde

mate aanwezig moeten zijn, om tot een definitie te kunnen komen. De eigenschappen

die ik hier opnoem, zijn mede afkomstig uit [Fon95] en [FG96], maar aangepast op die

manier, dat ze overeenkomen met mijn ervaringen op dit gebied.

Groot in aantal: de agent-gebaseerde aanpak gebaseerd op het biologische model

steunt op het feit dat de basis-eenheid met een beperkte complexiteit toch complexe

Eigen definitie 6

taken kan vervullen door zijn veelheid. Fouttolerantie is een gebied dat ook dikwijls van

deze eigenschap kan meegenieten. Merk op dat deze eigenschap geen nodige eigenschap

is: volgens sommige definities is bvb ook de wereld in zijn geheel een agent.

Autonoom: een van de meest vanzelfsprekende eigenschappen, een bepaalde mate

van zelfstandigheid. Een nodige voorwaarde, zonder deze zouden de agenten niet meer

te onderscheiden zijn van elkaar, of het programma van waaruit ze opgeroepen zijn, en

dus niet bestaan. Kan ook geınterpreteerd worden als de mate waarin code herleidbaar

is tot een eigenaars-entiteit.

Personaliseerbaar: een agent moet ofwel dingen kunnnen aanleren, ofwel, hard of

softwarematig, alles expliciet aangeleerd zijn. De agent moet gewoon weten hoe zich

te gedragen in de situaties waarin hij terechtkomt, maar elke agent moet dergelijke

beslissingen volgens eigen inzicht (geprogrammeerd) en/of ervaring (geleerd) nemen.

Vertrouwen: een agent moet te vertrouwen zijn, in die zin, dat, wanneer men hem

een taak (op)geeft, men erop moet kunnen vertrouwen dat die taak ook zal uitgevoerd

worden, zonder verdere tussenkomst van zichzelf. Men kan dit ook op een andere manier

begrijpen, namelijk, dat wanneer men de agent(en) een taak geeft, men het risico dat

de agent iets verkeerd doet moet afwegen tegenover het vertrouwen dat men erin heeft

dat hij het correct zal uitvoeren. Deze beslissing hangt natuurlijk af van de kost van

een fout.

Samenwerking: een agent en de gebruiker(opdrachtgever) van de agent, moeten

kunnen samenwerken(overleggen) bvb. om de opdracht of het resultaat mee te delen.

Dit kan varieren van het startsein geven aan een agent, tot het wachten van een zet

op een schaakbord. Gerelateerde eigenschappen kunnen zijn: communicatie, overleg,

interactie.

1.3 Eigen definitie

Uit al deze definities en eigenschappen tot een eigen definitie komen vond ik persoonlijk

een zeer moeilijke taak. Eentje die ik lang heb uitgesteld, maar waar ik desalniettemin

toch even de tijd voor heb moeten nemen. Deze definitie heb ik pas na het ontwikkelen

van het prototype samengesteld.

Eigen definitie 7

Wat is een agent? Het is als startpunt van deze thesis, een stuk code of software,

dat moet kunnen reageren op impulsen van buitenaf, en dus ook impulsen moet kunnen

ontvangen. Een robot valt maar moeilijk in deze definitie te plooien, maar voor deze

thesis is dat ook niet echt de bedoeling. Een robot valt meer onder de noemer van

autonoom systeem, zo ook bijvoorbeeld de Von Neumann machine, die zichzelf blijft

reproduceren, tot hij geen onderdelen meer vindt. Om deze in een definitie te kunnen

passen, zou een stuk code, software of een systeem voldoen. Ik zal het echter over de

software-agent hebben.

Welke eigenschappen of kenmerken heeft mijn agent? Eerst en vooral moet mijn

agent voor mijn model zelfstandig zijn, om onderscheidbaar te zijn van bibliotheken

en gewone computerprogramma’s. Er zijn natuurlijk verschillende gradaties van zelf-

standigheid, zo worden bijvoorbeeld de agenten in swarm beheerd door een andere

swarm. Daarom zal ik deze eigenschap beperken tot een minimum aan zelfstandigheid.

Een volgende eigenschap is onafhankelijkheid. Voor deze eigenschap geen compro-

missen. Een agent is onafhankelijk of is het niet. Voor ik hiermee onduidelijkheidschep,

ik bedoel dat de beslissingen die de agent neemt, onafhankelijk moeten zijn van andere

vormen van besturing of controle. Met andere woorden: Wanneer een agent dezelfde

beslissing opnieuw moet nemen, moet hij telkens opnieuw de huidige omstandighe-

den bekijken, intern of extern, en zijn beslissing onafhankelijk van andere parameters

nemen. Randomizers kunnen hierbij een probleem vormen, omdat die dikwijls niet

volledig onafhankelijk zijn. Voorzichtigheid dringt zich dus op, maar met de GNU-

randomizers, zoals deze in het swarm-systeem, is een maximum aan onafhankelijkheid

gegarandeerd.

Een doel, zoals bij de agent van Pattie Maes, heeft mijn agent niet nodig, maar een

software-agent moet wel een voorspelbaar gedrag vertonen op microscopische schaal.

Dit is dan ook een definitie die bruikbaar moet zijn voor simulatiedoeleinden. De “de

som is meer dan het geheel van de delen” gedachte die op langere termijn patroon-

vorming bij simulaties moet mogelijk maken, schrijft een bepaalde mate van gedrag

voor. Dit, om gelijkwaardige resultaten te kunnen bekomen bij gelijkwaardige simu-

laties.

Een laatste element dat niet mag ontbreken is de omgeving. Die moet er kun-

nen zijn, en die moet kunnen dynamisch zijn, alhoewel ze niet dynamisch moet zijn.

Agenten moeten een vorm van interactie kunnen vertonen met de omgeving.

Wat geeft dit alles dan samen?

Eigen definitie 8

1.3.1 Definitie

Een agent in de context van deze thesis, en van het prototype in deze thesis in het bij-

zonder, is een stuk software of code, dat onafhankelijk en zelfstandig, in een dynamische

omgeving handelingen uitvoert, die aan een bepaald voorgeprogrammeerd gedrag op

microscopische schaal voldoen, maar dit niet noodzakelijk op macroscopische schaal

doen, en dat in staat is te communiceren met de omgeving en/of andere agenten.

Hoofdstuk 2

SWARM

Real Programmers’ programs never work right the first time.

But if you throw them on the machine they can be patched

into working in “only a few” 30-hour debugging sessions.

- classic

2.1 Ontstaan

Swarm ontstond in 1994 in het Santa Fe Institute (SFI) in New Mexico, onder leid-

ing van Chris Langton die de bibliotheken ontwikkelde samen met zijn team, waarvan

de belangrijkste mensen toen Nelson Minar, Roger Burkhart & Glen Ropella waren.

De eerste beta-release kwam er in 1995, en versie 1.0 in januari 1997. De laatst ver-

schenen versie vandaag is 2.1.1. Sinds versie 2.0 is het ook mogelijk om in Java Swarm-

applicaties te schrijven. De Swarm-bibliotheken zijn echter nog steeds in Object-C.

Er wordt ook een jaarlijkse bijeenkomst voor de community georganiseerd, Swarm-

fest genaamd, waar nieuwe ontwikkelingen worden voorgesteld en ervaringen uitgewis-

seld. Dit is ook merkbaar bvb in de mailinglist, die in de periode na het swarmfest

meer aktiviteit vertoont.

User support gebeurt sinds het ontstaan via hun website (www.santafe.edu/projects/swarm)

die nu ook een eigen domeinnaam heeft gekregen (www.swarm.org). Er is ook een

mailinglist die voor support gebruikt wordt, waar alle vragen door leden van het huidige

ontwikkelingsteam of andere swarm-guru’s worden beantwoord. Onderhoud van beide

gebeurt sinds 1999 door de Swarm Development Group (zie verder).

In 1997 richtte Chris(topher) Langton samen met Glen Ropella en Douglas Orr The

Swarm Corportation op, een commercieel bedrijf dat sindsdien met Swarm-technologieen

expert consulting and modelling probeert aan te bieden aan bedrijven en de overheid.9

Distributie 10

Zij bleven sindsdien nog steeds lid van de Swarm Development Group, zij het dan op

een andere manier.

The Swarm Development Group (SDG) werd gesticht in september 1999 als een

private, non-profit organisatie om de ontwikkeling van Swarm en de interesses van de

leden ervan te steunen. Meer hierover verder.

2.2 Distributie

Alle software is vrij te verkrijgen onder de GNU-licentie op de swarm ftp-site (ftp.swarm.org).

Deze site wordt ook gemirrord in Australie, Utah en Europa door bevriende univer-

siteiten. Er is ondersteuning voor een hele reeks besturingssystemen, waaronder win-

dows2000, windowsNT 4, windows 95/98, Debian GNU/Linux2.2, Red Hat GNU/Linux,

SuSE 6.3 GNU/Linux en Solaris 2.7. Dikwijls worden pakketten op aanvraag (via de

mailinglist) ook nog eens gecompileerd voor andere configuraties of systemen.

Omdat het geheel van software een grote brok is om af te halen, kan men ook het

gehele pakket op CD-Rom bestellen voor 20 USD.

2.3 Platform

2.3.1 Swarm is GNU

Swarm is vrij verkrijgbaar (zie ook het vorige puntje), maar onder de GNU-licentie. Dit

heeft een aantal bekende gevolgen. Het belangrijkste waarschijnlijk is dat de broncode

van het programma volledig verkrijgbaar is en beschermd is. Iedereen die dat wil kan

zien hoe het programma werkt, bugs opsporen en verbeteringen voorstellen.

Het fijne van de deal kan iedereen terugvinden in de GNU General Public License

(GPL), gemakkelijk te vinden op het internet.

2.3.2 Object C

Wat is die Object C?

Eerst en vooral : Object C is een superset van C, op het einde van jaren ’80 als OO

(Object Oriented, object georienteerd) uitbreiding van C ontwikkeld door Brad Cox.

Object C voegt geen nieuwe sleutelwoorden aan C toe, alleen een manier om klasses

te definieren en instanties van objecten te behandelen.

Platform 11

Verschillen tussen C++ en Object C

• Object C is alleen maar een superset van C, maar C++ voegt een nieuwe laag

van complexiteit toe aan C.

• Objecten in C++ zijn alle statische getypeerd (de compiler moet de types ken-

nen), terwijl dit in Object C optioneel is.

• Object C laat “dynamic” en “late binding” toe, een voordeel dat zich vooral uit

bij het laten geboren worden en sterven van agenten. Dit is een stuk moeilijker

in C++.

• C++ heeft een ingebouwde constructor en destructor functie (geboren worden en

sterven van agenten), maar in Object C is geheugenallocatie en de-allocatie de

taak van verschillende gescheiden klasses, Swarm biedt een eigen implementatie

hiervan.

Hoe komen ze toch bij die Object C?

Nelson Minar antwoordde ooit op een dergelijk vraag in de mailinglist met het volgende

antwoord :“For a bit of historical perspective, the choice of Objective C was always a compro-

mise. When we sat down to start writing Swarm (in 1994) we couldn’t find a languagethat suited our purposes. C++ was simply not appropriate. We thought about CLOS,or Smalltalk, or a bunch of other researchy languages, but those all seemed to obscure.

So our plan was to write our own language, based on C. Roger and I got abouthalfway through designing it. Then we took a look and realized that the language wedesigned was close enough to Objective C that we should just use that.

And as funky as Objective C is at times, I think we made the right choice. Yes, it’s a

bit obscure, but the language is simple and the support that is there is pretty good. Yes,

it’s kind of GNU/Unix centric - but until recently, we never even considered running

Swarm on Windows. The good side is that it works quite well, and Swarm does some

awfully nifty things that normal C systems couldn’t touch. ”

Maar volgens de Swarm User Guide [JL00] is swarm in Object C geschreven omdat

• Object C eenvoudiger te leren is, omdat het veel gelijkenis toont met C, en omdat

• Object C run-time binding toelaat. Het voordeel hiervan is dat er boodschappen

kunnen gestuurd worden zonder de precieze identiteit (type) van de ontvanger te

kennen, zodat code geschreven kan worden om de omgeving en set van objecten

Platform 12

te laten veranderen en evolueren. Nadeel is echter dat een programma zal crashen

wanneer een object een bericht krijgt waarvoor het geen gepaste uitvoermethode

heeft.

2.3.3 Java

Sinds versie 2.0 van Swarm is er ook de mogelijkheid de Object C bibliotheken van

Swarm te gebruiken met Java, via de Java Native Interface. De bedoeling van de Java-

laag van Swarm is om de protocollen van de swarm bibliotheken te spiegelen als Java

interfaces. Een Java-masker voor object-C als het ware.

Java is de toekomst in de ogen van de swarm-ontwikkelaars, die (zie ook verder)

in een volgende versie (versie 2.2) swarm volledig integreerbaar willen maken in web-

browsers, zodat iedereen de applicaties via het internet kan draaien.

2.3.4 Object C versus Java

Java heeft natuurlijk het voordeel van de taal van de toekomst te zijn, en het is een taal

waarvan kennis buiten de swarm-omgeving ook nuttig kan zijn, wat je niet echt van

Object C kan zeggen. Java is bovendien ook de taal waarin de nieuwe ontwikkelingen

en uitbreidingen van Swarm zullen gebeuren, maar er is hier nog weinig van verspreid.

De bibliotheken van Swarm zullen echter in de volgende paar versies in Object C

geprogrammeerd blijven, en de swarm-tutorial was, uitgezonderd dan in de eerste paar

hoofdstukken, alleen maar gericht op Object C. Bovendien zijn de meeste bestaande

voorbeelden ook in Object C geprogrammeerd.

Deze argumenten beschouwend in september, heb ik voor mezelf voor een Ob-

ject C implementatie gekozen. Een tweetal andere argumenten waren echter even

doorslaggevend:

• Ik ken met moeite de beginselen van Java (ik kan er wel iets van, maar toch niet

veel), terwijl ik wel al enkele cursussen programmeren in C achter de kiezen had.

• Op de mailinglist werden geregeld problemen met Java gemeld, terwijl er niet

minder mensen met Object C applicaties aan het ontwikkelen waren.

2.3.5 Doel van Swarm

Vandaag definieren de mensen van de SDG hun pakket als volgt:

“Swarm is a general purpose simulation package for the investigation of concurrent,

distributed systems: systems in which hundreds or thousands of autonomous agents

SDG 13

interact with one another and with a dynamically changing environment. Swarm pro-

vides general purpose utilities for designing, implementing, running, and analyzing such

multi-agent systems.”

Het hoofddoeleinde van de creatievelingen achter het swarm-platform, was om

een gemeenschappelijk simulatieplatform voor Agent Gebaseerd Modelleren (ABM) te

bieden. Ze hebben dat gedaan in de vorm van het aanbieden van voorzieningen voor het

ontwerpen, implementeren, uitvoeren en analyseren van multi-agent systemen, zoals de

definitie verduidelijkt. Bij de oprichting van SDG bleven de doelstellingen van Swarm

als programma ongewijzigd, maar de doelstellingen als groep werden wat meer gefor-

maliseerd.

2.4 SDG

In November 1999 verliet het Swarm team officieel het Santa Fe Instituut en verplaatste

al zijn aktiviteiten naar de SDG, om de ontwikkeling van het swarm simulatie systeem

te ondersteunen, en de belangen van de teamleden te beschermen.

De Swarm Development Group is een VZW (non-profit organisation) waarvan de

doelstellingen in de vorige paragraaf werden opgesomd. Hun meest aktieven taken

zijn het dagelijks beantwoorden van de vele vragen die uit de gebruikersgemeenschap

voortkomen, en het continu onderhouden, aanpassen en vernieuwen van het pakket zelf.

De doelstellingen van de SDG klonken als volgt:

• De stand van zaken bij multi agent gebaseerd simuleren verbeteren door het

verbeteren van het Swarm simulatie systeem en door ondersteuning van de Swarm

gebruikersgemeeschap.

• de vrije uitwisseling van multi agent gebaseerd simuleren tussen computerspecialisten

en het publiek bevorderen.

• het uitbreiden en in stand houden van de rechtschapenheid en bekwaamheid van

de individuen die zich bezig houden met toepassingen van agent gebaseerde si-

mulatie.

De meest aktieve leden die dat vooral laten blijken via de mailinglist en het online

zetten van tutorials en applicaties zijn : Paul Johnson, Benedikt Stefansson, Alex

Lancaster, Glen Ropella, Marcus Daniels en Randy Burge.

Algemene Structuren 14

Figuur 2.1: Logo van de Swarm Development Group

2.5 Algemene Structuren

Hier probeer ik de gebruikte structuren in swarm (en dus ook mijn applicatie) een

beetje te verduidelijken, voor een volledigere tutorial verwijs ik naar [JL00].

2.5.1 Swarms (zwermen)

Het simulatiesysteem is georganiseerd als een een hierarchische structuur van comput-

erobjecten. Dit is de algemene structuur: Eerst en vooral wordt de observer swarm

gecreeerd, die maakt de user interface aan en creeert de model swarm, en de model

swarm maakt dan de lagere niveaus aan, en plant hun activiteiten.

Een swarm is eigenlijk een subklasse van de activity bibliotheek, dit houdt in dat

een swarm vooral het plannen van eigen activiteiten en het plannen van activiteiten op

lagere niveaus gebeurt.

Typisch plannen we de belangrijkste model akties ook gebruik makend van de ac-

tivity blibliotheek.

Wanneer gebeurtenissen gepland zijn moeten we alleen nog het (werk-) schema

activeren.

De typische stappen die gebeuren bij het creeren van een swarm zijn:

• createBegin, createEnd, createSelf : geheugenplaatsen en parameters aanvragen

en initializeren.

• createObjects, buildObjects : alle agenten en objecten in het model bouwen

• scheduleEvents, buildActions : de gebeurtenissen plannen, volgorde en duur

definieren.

• activateSchedule : het schema in werking laten treden en het schema laten opgaan

in het schema van de swarm op een niveau hoger.

Algemene Structuren 15

2.5.2 Observer swarm

Wanneer een swarmprogramma in een grafische mode werkt, is wat de gebruiker te zien

krijgt beheerst door de hoogste niveau swarm, die meestal “observer swarm” genoemd

wordt. De observer swarm neemt het GUISwarm protocol over, wat inhoudt dat het alle

kenmerken van een swarm erft, samen met enkele extra kenmerken.

Het meest opvallende van die extra kenmerken is het controlepaneel. Het controlepa-

neel is een set knoppen die het model kunnen starten, stoppen, pauzeren of stapsgewijs

verdergaan.

De grafische diagrammen en het “ZoomRaster” (voor werelden met ruimtelijke po-

sitionering) zijn de belangrijkste andere grafische objecten die kunnen gecreeerd worden

in observer swarm in de GUI mode. De twee belangrijkste diagramsoorten die door het

GUISwarm protocol worden aangeboden zijn het histogram en de lijngrafiek.

2.5.3 Model swarm

De kern van een swarm applicatie is een model swarm, de swarm die het gesimuleerde

model samenvat. Alles in de model swarm stemt overeen met objecten in de gemodel-

leerde wereld, agenten, hun wereld, en hun interaktie.

Naast de verzameling objecten, bevat de model swarm ook een activiteitenschema

van het model. Het schema definieert het effect van de voorbijgaande tijd op het model

op een discrete manier. Bij mijn model is dit bijvoorbeeld het ouder worden.

Model swarms bestaan uit een verzameling in- en outputs. De inputs zijn de model-

parameters: het aantal agenten, hun verdelingen en hun parameters. De outputs van

de modelswarm zijn de waargenomen waarden van het model: de individuele bugs, het

aantal huwelijken dat ze gesloten hebben, en de verdeling van die huwelijken.

2.5.4 Bugs

Helemaal onderaan het swarm model bevinden zich de swarm-agenten. Deze worden

gewoonlijk met “bugs” aangeduid, naar analogie met de beestjes in een mierenkolonie

of een bijenzwerm. Er treedt af en toe verwarring op in de terminologie, voornamelijk

tussen de wetenschapper en de programmeur. De wetenschapper beschouwt een theo-

retisch belangrijke eenheid uit zijn simulatie als een agent. Voor de programmeur is de

term agent iets breder, meer als “object”.

Daarom hebben ze in de Swarm User Guide ([JL00]) een onderscheid gemaakt tussen

primaire agenten en hulp agenten. Het idee er achter is dat de primaire agenten die

Specifieke structuren 16

zijn, die ook in het gesimuleerde model voorkomen. Er is praktisch echter geen verschil,

en aangezien er in mijn model maar een soort agenten voorkomt, valt het onderscheid

volledig weg.

Alle gedrag van agenten wordt op dit niveau gedefinieerd, maar verder wordt er met

niks rekening gehouden.

Bugs hebben parameters en methodes : met de parameters onderscheiden ze zich

van de andere bugs, en de methodes worden aangeroepen door de hoger liggende swarms

voor in- en output, en om activiteiten uit te voeren. De parameters worden gewijzigd

door hun eigen methodes.

2.6 Specifieke structuren

Voor sommige structuren en gebeurtenissen zijn er specifieke swarm-structuren. Ik

wil hier de kans aangrijpen wat meer uitleg te geven bij die structuren, zodat de pro-

grammacode wat makkelijker leesbaar wordt.

2.6.1 CreateBegin en createEnd

De methodes createBegin en createEnd zijn een koppel functies, die in elke swarm

aangeroepen worden om zich te bekommeren om de geheugenplaatsen, en om de vari-

abelen en parameters te initialiseren.

De code voor de createBegin methode in de observer swarm ziet er bvb als volgt uit

:

+ createBegin: aZone

{ObserverSwarm * obj;

id <ProbeMap> probeMap;

obj = [super createBegin: aZone];

obj->displayFrequency = 1;

return obj;

}

Alle variabelen van de bovenliggende klasses wordt geınitialiseerd in 1 stap door bij

de superclass de createBegin methode aan te roepen. Alle gecreeerde objecten worden

in aZone bewaard, die vanuit de main wordt meegegeven.

Specifieke structuren 17

Door een hierarchische structuur in de swarm code erven de verschillende swarms

de mogelijkheden om geheugenplaatsen en objecten te reserveren.

De code voor de createEnd methode is al een stuk eenvoudiger:

- createEnd

{return [super createEnd];

}

Deze code is zelfs strict niet nodig, maar het kan zeker geen kwaad. Zou deze

methode niet geımplementeerd zijn, dan zou de observerswarm de functie createEnd

van de GUISwarm erven. Door het op deze manier te gebruiken, ben ik gewoon zeker

dat de createEnd methode bij de superclass aangeroepen wordt, wat kan belangrijk zijn

voor de initialisatie van sommige variabelen bij een superclass.

De createEnd methode kan ook een plaats zijn waar de vervollediging van initiali-

saties van objecten eigen aan de swarm kan plaatsvinden.

In sommige gevallen kan het gemakkelijker zijn de createBegin en createEnd me-

thodes van de superclass te laten uitvoeren door een enkele boodschap, create, maar

meestal worden tussen deze twee stappen eigen variabelen gedefinieerd.

2.6.2 Probes

Probes laten de gebruiker toe dynamisch in te werken op objecten in zijn simulatie.

Terwijl de simulatie vordert, kan de gebruiker de waarden observeren en zelfs veranderen

(bvb met de variabele stopoptijdstip). Meer zelfs, de gebruiker kan zelfs specifieke

methodes oproepen, om parameters te bekomen of input die door de gebruiker werd

gespecifieerd in te voeren.

Een probe is eigenlijk een object, dat toelaat informatie te verzamelen over een

object, en die door te geven aan andere objecten, zoals grafische vensters.

Swarm biedt 2 soorten probes: messageProbes en varProbes. De eerste peilen

methodes. Ze verschijnen als een knop in een venster, met de naam van de methode op

de knop, en die methode wordt uitgevoerd wanneer wanneer de knop ingedrukt wordt.

Varprobes peilen variabelen. Een varprobe verschijnt voor een gebruiker in een

venster als de naam van een variabele of parameter met daarnaast een ruimte voor die

de waarde van de variabele of parameter kan bevatten. Varprobes kunnen de inhoud

van arrays of structs niet weergeven.

Specifieke structuren 18

Figuur 2.2: varProbes en messageProbes

Probes worden gegroepeerd in probe displays, dit zijn vensters die een verzameling

informatie bevatten over eenzelfde structuur. De default probe display bevat alle mo-

gelijke probes die een structuur kan bevatten, maar meestal worden probe displays op

maat gemaakt door de programmeur. In dat geval moeten de afzonderlijke probes die

in de probe display getoont moeten worden allemaal afzonderlijk worden aangebracht.

2.6.3 EZGraph

De EZGraph is een verschrikkelijk handige tool om grafische output te verkrijgen bij

een bepaalde simulatie. Het is eigenlijk alleen maar een omhulling voor verschillende

andere objecten, maar zeer gemakkelijk in gebruik.

De EZGraph laat toe de creatie en bouw in een stap te doen, na het toevoegen van

de titels en de labels moeten er alleen nog opeenvolgingen van input-data aangebracht

worden.

2.6.4 Schedules

Het tijds-planningsmechanisme in het swarm systeem is een van de belangrijkere ele-

menten in swarm, omdat het de manier is om de acties en reacties van verschillende

agenten op verschillende niveaus van de simulatie te integreren. Met andere woorden:

zonder schedules geen simulatie.

De akties die in een simulatie gebeuren zijn georchestreerd door objecten die lui-

steren naar het Schedule protocol. Een schedule wordt in een object gemaakt, en dan

Toepassingsgebieden 19

Figuur 2.3: voorbeeld van een EZGraph

meegedeeld aan de bovenligger in de hierarchie van de swarm. Het is als het ware een

kalender, waar het object met een rode stift omcirkelt wanneer het iets moet uitvoeren.

Schedules die gebeurtenissen definieren worden omschreven aan de hand van hun

repeat interval (hoe dikwijls ze moeten opgeroepen worden), het tijdstip waarop ze voor

het eerst moeten aangeroepen worden, de naam van de eigenaar (wie ze iets moeten

laten uitvoeren), en de methode die ze moeten oproepen (wat ze moeten doen).

In het algemeen wordt een aktie in een schedule gevraagd voor 1 enkel object, of

voor een lijst objecten (zoals agenten), die bvb in een List zijn opgeslagen, zoals bij

mijn applicatie.

2.6.5 Actiongroups

Een ActionGroup is een verzameling akties die verondersteld zijn in een bepaalde volg-

orde te verlopen. In een algemene swarm-toepassing wordt meestal eerst een Action-

Group aangemaakt met een verzameling samenhorende akties, en dan wordt die in een

schedule gepland om om de zoveel tijd uitgevoerd te worden.

2.7 Toepassingsgebieden

Tegenwoordig zijn de toepassingen van Swarm beperkt gebleven tot simulaties, maar

voor een pakket dat nog maar 4 jaar volledig beschikbaar is, is er al heel wat aan de

Toepassingsgebieden 20

weg getimmerd, in een kleurrijk spectrum van toepassingsgebieden. Iedereen die met

een toepassing bezig is en dat wil vermelden, kan dat doen op swarm.org, waar ook een

volledigere lijst beschikbaar is.

De meeste toepassingen bevinden zich echter in het veld van de biologie en de

ecologie. Andere gebieden waar er met behulp van swarm-simulaties onderzoek ver-

richt wordt zijn antropologie (sociologie), computerwetenschappen, economie, politieke

wetenschappen, geografie en defensie-gerelateerd.

Het nut van de simulaties die mogelijk zijn met swarm is (volgens Benedikt Stefans-

son [Ste99]) onder andere te vinden in:

• De studie van complexe niet-lineaire systemen, bvb een ecosysteem, een interna-

tionaal conflict, of een financiele crisis.

• het bestuderen van

– Ruimtelijke interactie

– Adaptieve, heterogene agenten

– Agenten die geconfronteerd worden met de kosten van informatiegaring en

verwerking

– Geneste subsystemen zoals de economie, beurzen, bedrijfsstrategieen, werkne-

mers, ...

2.7.1 SFI

Het Santa Fe Institute in New Mexico is niet alleen de plaats waar het simulatie systeem

ontwikkeld is, maar er lopen weliswaar ook enkele projecten waarin de mogelijkheden

benut worden.

• Bugverse is een project om de evolutie van compexiteit in neurale netwerken met

recursief modulaire architecturen te bestuderen. (de verschillende niveaus van

origanisatie) Er wordt aan gewerkt door Alex Lancaster (SFI) in samenwerking

met David Alexander van het “Mental Health Research Institute” in Melbourne,

Australie.

• Brandon Weber heeft uitgebreide documentatie geschreven voor de twee “Artifi-

cial Stock Market” implementaties, die beschikbaar zijn op de ftp-site.

Verdere ontwikkelingen 21

2.7.2 UCLA

Aan de Universiteit van California, Los Angeles (UCLA) zijn een heleboel experimenten

lopend, en wordt er in de richting Political Science, in het vak Computational Social

Science, het volledige swarm-programma aangeleerd.

Dit zijn een aanal projecten die er lopend waren of zijn:

• Charles Taylor and John Carnahan (biologie): Mosquito Breeding and Diffusion

in Africa

• Melissa Savage and Robert Bell (ecologie): Effects of catastrophes on forest de-

velopment

• Benedikt Stefansson (economie): Competition in markets with product differen-

tiation

2.7.3 Andere universiteiten

Ook een aantal andere universiteiten zijn een aantal onderzoeken met behulp van swarm

aan de gang:

• Aan de Washington State University: Tim Kohler, Eric Carr, and Jim Kresl

(anthropologie): “Village formation among the Anasazi”.

• Aan Dublin City University, Ireland: Barry McMullin (chemie): “Cellular devel-

opment in an artifical chemistry”.

• In Yale zijn er een aantal biologische toepassingen in ontwikkeling, onder andere

Gecko, een simulator om dynamiek in ecosystemen te modelleren.

• Bij het “US Army”: “Fuzzy-Genetic Decision Optimization for Positioning of

Military Combat Units” door kapitein Rob Kewley, over hoe het best miliaire

eenheden positioneren op een slagveld.

2.8 Verdere ontwikkelingen

Waar er in de volgende versies van swarm heen wordt gesprongen, is een heel stuk

duidelijker geworden met het verschijnen van het Jaarrapport 2000.

Bijna alle doelstellingen die na de vorige versie waren gesteld zijn gehaald: de “Java

graphical user interface” en een versie voor Windows NT. Alleen swarm.COM is voor

Verdere informatie 22

de volgende versie van swarm gepland. COM is een technologie die de communicatie

tussen verschillende componenten moet vergemakkelijken, onafhankelijk van hun on-

twikkelingstaal. Er is al een demo-code beschikbaar op de ftp-site.

2.8.1 Annual report 2000

Het jaarrapport 2000 was het eerste jaarrapport sinds de oprichting van de SDG, waarin

veel informatie te vinden is over hoe en wat er allemaal gebeurd is in dat eerste jaar,

tot wat de nieuwe horizonten zijn van swarm. Wat meer specifiek is er o.a. te vinden :

• Swarm.COM, over ondersteunen van deze nieuwe standaard

• het ondersteunen van javascript naast Java en Object C

• een IMT module voor het ondersteunen van de IMA architectuur

• de nieuwe mogelijkheden voor de volgende release(s)

2.9 Verdere informatie

Voor up-to-date informatie kan ik u alleen maar verder verwijzen naar de website, er

is daar reeds een heleboel informatie over het eigen systeem verzameld, en ook de site

van Benedikt Stefansson, die de slides van zijn eigen lessen in swarm ook ergens op het

net heeft staan.

Vragen kunnen altijd terecht op de mailinglist, en wie deze al een tijdje volgt zal

waarschijnlijk al zijn vragen vanzelf aan bod zien komen.

2.9.1 The Swarm Community

“The Swarm Community” zijn al de mensen die meehelpen aan het succes van swarm,

iemand die iets met dit simulatiesysteem wil proberen, zal zeker in aanraking komen

met deze mensen. Op de Website is een volledig stuk aan hun bijdragen gewijd. Er

zijn onder andere een heleboel bibliotheken met betrekking tot bepaalde simulaties

beschikbaar.

De verschillende mailinglists zijn de manier bij uitstek waarmee de leden met elkaar

in contact blijven. Iemand die op de hoogte wil blijven van alle nieuwe mogelijkheden

en ontwikkelingen in swarm, hoeft zich alleen maar in te schrijven. Het is volledig gratis

en er worden elke dag zo’n 5 a 20 mails verstuurd. Ik wil de lezer echter gewaarschuwd

hebben: het gaat er dikwijls ook zeer technisch aan toe.

Verdere informatie 23

Via de site is het ook mogelijk verschillende papers van leden te raadplegen en te

bestuderen.

Hoofdstuk 3

Het proto-type

The first step in making a dream come true is to wake up.

- unknown

3.1 Wat wordt er verwacht ?

3.1.1 Kennismaking met Swarm

Eind april vorig jaar haalde ik, na het bekijken van de beschikbare thesisonderwerpen,

en het ingewonnen advies van Stijn Roelens, het pakket af om in Swarm te kunnen

ontwikkelen. Enkele dagen later had ik reeds beslist welk thesisonderwerp het mijne

zou moeten zijn, en mijn aanvraagformulier was snel op weg. Eerder dit schooljaar

kreeg ik dan ook de bevestiging dat mijn thesis-onderwerp vastlag. Mijn keuze was

goedgekeurd.

Ergens halfweg augustus ben ik dan begonnen met een kijkje te nemen naar de

beschikbare voorbeelden, die op de Swarm-website stonden. De aanwezige voorbeeldjes

compileren lukte al gauw. In september lukte het me al enkele heel eenvoudige ideetjes

zelf te ontwikkelen, voornamelijk andere voorbeeldjes die ik aanpaste naar eigen inzicht.

In oktober begonnen dan de gesprekken met prof. Bossaert over een meer praktische

toepassing die ik zou kunnen ontwikkelen.

Na een tijdje ontmoette ik zo John Lievens, assistent van professer Paige bij de

bevolkingswetenschappen, die op een mail van professor Bossaert antwoordde en die

heel genteresseerd was in nieuwe technologien als deze, en hun toepassingen. Hij stelde

voor iets te ontwikkelen waar hij eventueel de resultaten van zou kunnen gebruiken en

interpreteren, verband houdend met het onderzoek waar hij mee bezig was en is.

Dat was het dan ongeveer in een notedop. Wat er allemaal van geworden is vindt

24

Wat wordt er verwacht ? 25

u terug in deze scriptie, evenals verdere uitleg over de technologie, de ontwikkelingen

en mijn resultaten en bevindingen.

3.1.2 Het experiment: algemene noties

Het voorstel tot ontwikkeling van John Lievens betrof een huwelijksmarkt: een soort

van geısoleerde wereld waar alleen mensen(agents) voorkomen die op zoek zijn naar een

huwelijkspartner. Deze individuen beschikken allemaal over persoonlijke kenmerken,

die hen onderscheiden van elkaar, zoals geslacht, leeftijd, opleidingsniveau, etniciteit,

en dergelijke meer.

Deze personen ontmoeten elkaar op regelmatige basis, en beginnen met een vorm van

onderhandelen, die, als ze beiden instemmen, eindigt in een huwelijk en het verdwijnen

van hen beide van de huwelijksmarkt. Als de onderhandelingen niet aflopen zoals

gepland, vertrekken beide individuen terug met dezelfde kenmerken de huwelijksmarkt

in, op zoek naar een nieuwe mogelijke partner. Partners van hetzelfde geslacht zijn niet

toegestaan.

3.1.3 Het experiment: meer specifiek

De huwelijkskandidaten beschikken allereerst over een aantal kenmerken waarmee ze in

de wereld geworpen worden. Deze kenmerken zijn geslacht, leeftijd, opleidingsniveau en

etniciteit. Alleen de reactie op het geslacht ligt op voorhand vast: iemand van hetzelfde

geslacht wordt niet als partnerkandidaat beschouwd. Alle kandidaten van het andere

geslacht, ongeacht hun andere kenmerken, worden in aanmerking genomen.

De andere persoonlijkheidskenmerken worden op de volgende manieren in acht

genomen:

• leeftijd : kandidaten zoeken een kandidaat waarvan de leeftijd niet te veel ver-

schilt. Ook is het zo dat kandidaten naar mate ze ouder worden, minder kieskeurig

worden naar de keuze van een partner toe.

• opleidingsniveau : kandidaten zoeken een partner waarvan het opleidingsniveau

zo dicht mogelijk bij hun eigen opleidingsniveau ligt. Het opleidingsniveau kan

afhankelijk gemaakt worden van de etniciteit.

• etniciteit : kandidaten uit andere etnische groepen worden niet gemakkelijk aan-

vaard door de huwelijkskandidaten. Er wordt voorkeur gegeven aan kandidaten

Wat wordt er verwacht ? 26

uit hun eigen etnische groep. Etniciteit kan niet in gradaties voorkomen: iedereen

behoort tot juist 1 etnische groep.

Niet alle kenmerken zijn even belangrijk voor de huwelijkskandidaten. Kandidaten

geven voorkeur aan iemand met dezelfde leeftijd, daarna aan een partnerkandidaat

met dezelfde etniciteit en het minst belangrijk vinden ze het feit of hun eventuele

toekomstige wederhelft hetzelfde opleidingsniveau heeft.

Bij de onderhandelingen worden de kenmerken dan in geevalueerd, naar mate hun

belangrijkheid (zie vorige paragraaf), samen met een extra parameter, het “random

effect”, de parameter die in een bepaalde mate cupido, de omstandigheden of iets

dergelijks kan genoemd worden. Deze “onderhandelingsparameters” vormen dan samen

een resultaat en naargelang de waarde ervan wordt een huwelijk aangegaan of een nieuwe

kandidaat gezocht.

3.1.4 Het experiment: bijkomende complexiteit

Dat is natuurlijk nog niet alles, maar wel al iets mooi om mee te beginnen. Om van

dienst te kunnen zijn op echte toepassingen, zou het wenselijk zijn om enkele bijkomende

vormen van complexiteit te kunnen onderzoeken. Al deze bijkomende vervormingen

van het originele probleem zijn afkomstig uit de realiteit, de herkenbaarheid ervan is

betrekkelijk groot, en de toepasbaarheid dus ook hoger.

beschikbaarheid van partners

Deze extra parameter handelt over de omvang van een groep in de huwelijksmarkt

waarvan enkele kenmerken hen (duidelijk) isoleren van de anderen, bijvoorbeeld et-

niciteit. Als er een kleine etnische groep kandidaten bestaat, tussen een veel grotere

groep anderen, dan lijkt het te verwachten dat de etnische kandidaten meer “moeite”

zullen moeten doen om een partner te vinden dan de anderen, ook omdat de ze minder

snel een ideale keuze zullen vinden in hun eigen etnische groep. Het resultaat kun-

nen herkennen en daarna de mogelijke oorzaken vinden en eventueel zelfs praktische

oplossingen kunnen behoort allemaal tot de mogelijkheden.

heterogeniteit

Dit handelt over de heterogeniteit van eigenschappen over de gehele populatie. Als de

populatie bijvoorbeeld bestaat uit een veel kleine etnisch geısoleerde groepen, dan is

Het eerste simulatieprogramma 27

het te verwachten dat huwelijken tussen etnisch verschillende kandidaten makkelijker

voorkomen dan in een veel/weinig situatie zoals in de vorige paragraaf. Wat gebeurt er

als het opleidingsniveau ook sterk heterogeen is, en wat als het dat niet is zijn mogelijke

vragen. Er wordt vooral gekeken naar heterogeniteit van populaties op het vlak van

opleidingsniveau en etniciteit.

correlatie van de persoonlijke kenmerken

En tenslotte is het de bedoeling eventueel te kunnen bestuderen wat het effect is als de

correlatie van de persoonlijke kenmerken, ttz, de mate waarin ze van elkaar afhangen,

bvb wanneer een etnisch geısoleerde groep ook een consistent lager of hoger opleidings-

niveau heeft. Mogelijke bijwerkingen zullen misschien kunnen waargenomen worden.

Er wordt vooral gekeken naar de correlatie tussen de etniciteit en het opleidingsniveau.

3.2 Het eerste simulatieprogramma

Een van de eerste versies die ik John Lievens liet zien had nog een beperkte function-

aliteit, maar werkte al volledig en de code ervan zag er ongeveer uit als bij de code van

“een intermediaire versie”, in het volgende hoofdstuk besproken, waarvan de code ook

beschikbaar is op de cdrom (programmacode/versie 1).

3.2.1 Functionaliteit

De functionaliteit die deze versie bood was dus nog redelijk beperkt, maar de basis-

functionaliteiten waren wel al aanwezig.

De huwelijkskandidaten zijn vervangen door bugs, de elementaire vorm van agen-

ten in swarm, en beschikken elk over een aantal kenmerken waarmee ze in de wereld

geworpen worden. Deze kenmerken zijn geslacht, leeftijd, opleidingsniveau en etniciteit.

Deze bugs worden dan allemaal samen in de huwelijkspool gezet en gaan tijdens

elke tijdsstap op zoek naar geschikte partners. De werking van het programma is zo,

dat elke bug tijdens elke tijdsstap een vast aantal pogingen onderneemt tot het vinden

van een partner. De partner wordt dan beoordeeld aan de hand van een aantal andere

kenmerken, die een bepaalde belangrijkheidsfactor meekrijgen, en wanneer de partners

in het huwelijksbootje stappen, worden ze onbereikbaar voor andere kapers op de kust,

en tussen het einde van de tijdstap en de volgende verdwijnen de kandidaten uit de

huwelijkspool, en worden vervangen door nieuwe bugs met dezelfde kenmerken.

Bijsturing van het prototype 28

Dit alles gebeurt nu echter wel niet volgens een klassieke programmeertaal, maar

volgens de regels van swarm, die inhouden dat bijvoorbeeld akties in discrete stappen

zijn ingedeeld en de akties van de bugs verzameld in lijsten, actionlists genaamd.

3.2.2 Technologie

Ik moet toegeven dat ik in het begin hard heb geworsteld met het begrijpen wat er

nu juist allemaal aan de hand was in swarm, en op welke manier alles verliep, maar

eenmaal onder controle bleek het een programmeeromgeving als een ander te zijn, met

veel voordelen, en evenveel nadelen.

Een van de eigenschappen van swarm is dat de acties vooral bij de agenten gebeuren,

op het laagste niveau van de toepassing, en erboven staat alleen de besturing. Het is

echter de bedoeling om bepaalde waarnemingen te kunnen doen op een hoger niveau,

bijvoorbeeld hoe het aantal kandidaten die huwen evolueert ten opzichte van de tijd,

zonder tussenkomst op dit niveau. Dit gebeurt hier dan ook in een zekere mate. De

bugs kunnen niet alle kandidaten van de hele populatie tegen elkaar afwegen, en dan

de beste voor zichzelf eruit kiezen. Ze hebben alleen het hier en nu, en moeten bij

elke partner beslissen of ze verder op zoek gaan, maar dit wel ten koste van tijd, of een

huwelijk aangaan, wetend dat er geen weg terug is en dat ze bij een volgende ontmoeting

een “interessantere” partner zouden kunnen ontmoeten, en er rekening mee houdend

dat ze na een bepaalde tijd, gehuwd of niet, zowieso uit de pool moeten.

Deze akties vertalen zich met de swarm compiler mooi in 1 samenhangend pro-

gramma, alhoewel het dit niet echt is, maar toch deze schijn geeft. Achter deze gevel

van een uitvoerbaar programma, zitten de verscheidene agenten elk met hun eigen deel

aan resources en tijd, elk op zoek naar zijn ideale partner.

3.3 Bijsturing van het prototype

Het vervolg op deze eerste prototypes liet niet lang op zich wachten, en de stand van

zaken besprekend werd het model uitgebreid, niet zonder enig overleg. Hier volgen de

zaken die in de loop van tijd aan het eerste model werden toegevoegd.

3.3.1 Opdelingen

Het aantal mogelijke etnische groepen werd beperkt tot vijf om het mogelijk te maken

kenmerken te laten verschillen per etnische groep, en eventueel nog per sexe. Op

deze manier kunnen nu bijvoorbeeld bij elke etnische groep een eigen gemiddelde voor

Bijsturing van het prototype 29

opleidingsniveau opgegeven worden per geslacht. Het voorstellen van een bepaalde

etnische groep met bijvoorbeeld beter opgeleide mannen dan vrouwen of net omgekeerd

wordt nu mogelijk, evenals bijvoorbeeld twee etnische groepen waarbij de mannen en

vrouwen complementaire eigenschappen hebben, om bvb te bestuderen als deze groepen

dan sneller inter-raciale huwelijken aangaan.

Een van de beperkingen is dan wel dat de parameters ingegeven moeten worden.

Dit is een serieus nadeel, bedenkend dat wat er uit het programma komt nu veel meer

afhangt van wat er in wordt gestoken. Ook effecten op grotere en langere schaal zullen

nu veel moeilijker zichtbaar worden, maar meer over deze effecten in een volgend hoofd-

stuk.

3.3.2 Extra kenmerken

Na verloop van tijd werd er ook de optie geopperd om nog een extra kenmerk per

huwelijkskandidaat in te voeren, maar zonder invulling, een soort “blanco” kenmerk.

Dit kenmerk is er ook gekomen, en kreeg de naam “dummy-kenmerk” mee. Zou het nu

interessant geacht kunnen worden om bepaalde bijkomende kenmerken, die voorheen

nog niet in het model waren opgenomen, toch te willen bestuderen, dan kan dit nu door

het invullen en interpreteren van dit dummy kenmerk met deze eigenschappen.

Een heleboel extra attributen werden ook toegevoegd aan de bugs, zoals een belang

voor elke bestaande parameter, en parameters voor de verdelingen. Kenmerken in een

bepaalde simulatie niet laten meetellen is met dit programma bijna kinderlijk eenvoudig.

Het kan dat bijvoorbeeld in een bepaalde testopstelling het dummy kenmerk niet meer

mag meespelen. Het enige dat bij de parameters gewijzigd moet worden is dan het

belang van het respectievelijke kenmerk dat moet verdwijnen, dat op nul moet gezet

worden.

Het is ook mogelijk, door de doorgedreven parametrisatie van de applicatie, om

bijvoorbeeld een bepaald kenmerk door een etnische groep hoog in waarde te laten

schatten, terwijl dit bij een andere etnische groep niet eens van tel is. Dit namelijk

omdat bij een huwelijk in de finale versie, elke partner met zijn eigen parameters gaat

“checken” als de kandidaat volgens zijn eigen waarden voldoet als partner. Op deze

manier zal bijvoorbeeld een bug die andere bug heeft goed bevonden als partner, niet

altijd hetzelfde antwoord terugkrijgen van deze partner, en in dat geval dan ook geen

huwelijk kunnen aangaan.

Bijsturing van het prototype 30

3.3.3 Verdelingen

Wat er ook bij kwam kijken zijn verdelingen. Deze instellingen en parameters zijn

meer dan eens in opeenvolgende versie gewijzigd geweest, en uiteindelijk zijn de meeste

ervan normaal verdeeld geweest, volgens de standaard normale verdeling uit de swarm-

bibliotheek.

Gemiddelde en variantie zijn per etnische groep en geslacht instelbaar, maar weer

met dezelfde bedenking als voorheen: hoe meer parameters er ingesteld kunnen worden,

hoe meer de output niet meer dan een factor zal zijn van hetgeen erin wordt gestoken.

Alleen de verdeling van de leeftijd is niet instelbaar. Hier wordt ervan uitgegaan

dat elke agent de huwelijkspool binnenstapt op hetzelfde tijdstip in zijn leven, en de

pool pas verlaat na ofwel een huwelijk ofwel een bepaalde bovengrens voor de leeftijd.

Het percentage van een bepaalde groep dat man of vrouw is, is ook niet instelbaar

volgens een bepaalde verdeling, maar dit omdat dit expliciet opgegeven moet worden.

Als men bijvoorbeeld wil dat in een bepaalde etnische groep het aantal mannen normaal

verdeeld is met bepaalde parameters, dan moet men dit op voorhand berekenen, en in de

parameters opgeven. Het aantal mannen en vrouwen tijdens een simulatie wijzigt niet

omdat de nieuwe bugs die aan de huwelijkspool toegevoegd worden, dezelfde kenmerken

hebben als deze bugs, die ze vervangen. Dit is echter een eigenschap die gemakkelijk

kan gewijzigd worden, moesten er bijvoorbeeld generaties in simulaties moeten kunnen

voorkomen. Alleen de implementatie van de reincarnate methode moet dan aangepast

worden.

3.3.4 Output

Op dit gebied is er nog veel gebeurd in de tijdsspanne tussen de eerst werkende ver-

sies en de finale versie. De mogelijkheid is erbij gekomen om ongeveer alles wat de

bugs van aktiviteit vertonen uit te schrijven. Huwelijken, verdwijnen uit de huwelijks-

pool, welke toegevingen de bugs deden om tot een huwelijk te komen, worden op een

uniforme manier en met tab-stops uitgeschreven, zodat deze data onmiddellijk in een

spreadssheet-toepassing zoals MS Excel kan ingevoegd worden.

Naast het uitschrijven van de kenmerken van de bugs op het tijdstip wanneer ze

huwen, wordt via de grafische interface ook de mogelijkheid geboden om informatie

over de huwelijken in de laatste tijdstap in tabelvorm weer te geven en in een bestand

te steken.

Wat echter nog interessanter is, is de mogelijkheid deze informatie op te vragen over

Bijsturing van het prototype 31

het ganse verloop van de simulatie. Alle informatie over wie juist met wie trouwde is

raadpleegbaar en achteraf invoegbaar in bvb Excel.

Tabel 3.1 geeft de situatie weer gedurende slechts 1 tijdstip, 3.2 geeft de resultaten

gedurende een langere periode weer. Dezelfde vorm van output voor de verhouding

dummy-geslacht en de verhouding leeftijd-geslacht wordt ook weergegeven.

Tabel 3.1: voorbeeldoutput verhouding geslacht-etniciteitf \m 1 2 3 4 51 23 2 1 0 42 2 15 0 5 03 6 6 5 0 04 1 4 1 2 05 6 0 0 0 6

Tabel 3.2: voorbeeldoutput verhouding geslacht-opleidingsniveauf \m 1 2 3 4 5 6 7 8 9 101 0 0 0 0 0 0 0 0 0 02 0 6 46 53 7 1 6 10 2 03 0 3 55 76 11 2 11 23 2 04 0 1 35 117 62 112 70 29 3 05 0 6 38 159 109 164 261 171 21 36 0 2 29 110 76 92 320 303 50 27 0 0 0 6 6 0 19 39 6 08 0 0 4 8 3 7 59 146 66 09 0 0 2 8 2 2 23 74 53 310 0 0 0 0 0 0 0 2 4 0

Hoofdstuk 4

De implementatie

Computers are like Old Testaments gods.

Lots of rules and no mercy.

- classic

4.1 Een eerste versie

Dit is een van de eerste versie van het programma die werkten, en waar de structuur

al duidelijk begon te worden. Op dit stadium had ik al een heleboel problemen die te

maken hadden met de taal en versie 2.1 van het programma (sommige objecten kunnen

op een andere manier aangeroepen worden) overwonnen, en ik zal hier proberen wat

meer duidelijkheid te scheppen in wat er in de code staat. De code van dit programma

is meegeleverd als appendix.

4.1.1 Structuur

De structuur van het applicatie is al duidelijk zichtbaar, in die zin dat er al een observer

swarm, een model swarm en afzonderlijke agenten aanwezig zijn.

Vanuit het korte main-programma, dat verder niet meer zal veranderen, wordt de

observer swarm opgeroepen, die op zijn beurt de model swarm beheert, die op zijn

beurt een lijst bijhoudt van de bugs.

Het compileren van een swarm programma gebeurt met behulp van een “makefile”,

een bestand waarin de afhankelijkheden tussen de verschillende klasses in de simulatie

vermeld worden.

32

Een eerste versie 33

Figuur 4.1: Structuur van de applicatie.

4.1.2 De observer swarm

De objecten die deze swarm bijhoudt zijn nog minimaal: een Schedule, een Action-

Group, een Graph-object, en de model swarm.

Ook de methodes zijn nog tot een minimum beperkt: createBegin en createEnd,

buildObjects, buildActions en de activateIn methode.

Misschien interessant om te wijzen op de graphDeath methode, die nog noodza-

kelijk is, omdat de grafische vensters objecten zijn, en gedropped moeten worden. -

whateverGraphDeath : caller

{[whateverGraph drop] ;

whateverGraph = nil;

return self;

}

In de buildObjects methode kan u zien dat na het creeren van de objecten van

de superklasse, de GUISwarm, het controlepaneel in een bevroren staat laten starten,

anders kan een subklasse al bewerkingen doen zonder dat zijn schedule al gepland is in

het eigen schedule.

Bij de creatie van de EZGraph kan u de manier van oproepen van de destructor,

die opgeroepen wordt met @selector(...) , en de selector van de eerste (en enige)

Een eerste versie 34

sequence die in de grafiek wordt getekend, de macro M(...). Deze macro roept eigenlijk

alleen de eerste methode op, zij het dat hij maximum 3 argumenten kan meekrijgen.

De sequentie die in de grafiek voorkomt krijgt zijn informatie van de lijst van bugs

die de model swarm bijhoudt (withFeedFrom [modelSwarm getHuwBugsList] ), die

dan natuurlijk al bestaat, aangezien enkele regels eraan voorafgaand de [ModelSwarm

create: self] methode wordt opgeroepen, waarbij de BugList wordt gemaakt.

Als de input niet louter de waarde van een parameter is, dan moet de input niet

gewoon een createSequence zijn, maar een bewerking daarvan. Hier is dit bvb een

createAverageSequence, die een gemiddelde van de aangeboden waarden kiest. Het

doet er niet toe welke soort objecten er in de list zitten, zolang ze maar met een waarde

kunnen antwoorden op getSkill. Er zijn ook alternatieven voor het gemiddelde, zoals

de max, min en som functies.

Bij de buildActions (let op het verschil met buildObjects), wordt eerst een ac-

tiegroep aangemaakt, waarin de update methode voor zichzelf, en de doTkEvents

methode voor de “actionCache” worden aangeroepen. De update methode bevat de

stappen die moeten uitgevoerd worden gedurende elke tijdseenheid (eigenlijk elke dis-

playFrequency aantal eenheden), wat alleen het vernieuwen van de grafiek inhoudt. De

doTkEvents is een methode, die, telkens wanneer opgeroepen, de verversingsfuncties

van de schermoutput oproept, het is te zeggen, telkens wanneer deze functie wordt

aangeroepen, wordt het controlepaneel gecontroleerd als er op een knop werd gedrukt,

en de andere grafische output vernieuwd, als er nieuwe data naar gevoerd werd.

En dan wordt de ActionGroup “displayActions” in het schedule gevoerd: Het sched-

ule duurt maar 1 stap lang, en wordt elke tijdseenheid opnieuw aangeroepen. De plan-

ning in dit schedule zelf is “Op tijdstip 0: voer de ActionGroep displayActions uit”.

Als er geen repeatInterval wordt gespecifieerd, dan wordt het schedule maar een keer

uitgevoerd, dit wordt gebruikt in dynamische schedules, zoals bvb bij het mousetrap

voorbeeld dat in het swarmApps pakket te vinden is.

4.1.3 De model swarm

Net zoals de observer swarm heeft de model swarm een ActionGroup en een Schedule,

alsook een List object, waarin de verzameling bugs bijgehouden wordt.

Qua functies zijn naast de standaard functies ook een functie addHuwBug en getH-

uwBugList terug te vinden. Deze eerste wordt alleen gebruikt bij het creeren van de

agenten, en de laatste (voorlopig) alleen om input te kunnen krijgen voor de graph

Een eerste versie 35

in de observer swarm. (de input-sequentie in de grafiek heeft als optie withFeedFrom:

List).

De createBegin, createEnd, buildObjects, buildActions en activateIn methodes hebben

dezelfde functies als in bijna elke beschikbare swarm, namelijk initializatie, allocatie en

planning opstellen.

De functie neemt een HuwBug, en voegt deze toe op het einde van de list. Merk

op: andere objecten kunnen niet door deze functie in de list gestoken worden, alhoewel

de lijst zelf er geen bezwaar zou tegen hebben.

Bij de methode getHuwBugList wil ik toch even wijzen op het feit dat in het swarm

simulatie systeem het default return type object is, dus wat deze functie eigenlijk doet

is gewoon een pointer teruggeven naar de originele list. Het maakt geen nieuw object

in het geheugen aan.

In de createBegin methode zorgt de lijn Modelswarm *obj ervoor dat er een plekje

in het geheugen wordt vrijgehouden, gewoon via de Object C standaardbibliotheken.

Het feit dat je dingen zoals obj->numbugs = 100; hier kan schrijven, is omdat de

classes in Object C niet op dezelfde manier afgeschermd zijn als in C++, maar perfect

bruikbaar als er objecten vroeg moeten geınitialiseerd worden.

De bugs worden gemaakt en geınitialiseerd in de buildObjects methode. Dit is

logisch, aangezien de bugs in feite attributen zijn van de model swarm, objecten die

moeten gebouwd worden. De model swarm is als het ware niks anders dan een soort

van kader rond de bugs. De uniformIntRand methode is een methode uit de ran-

dom.h bibliotheek die een rondom integer tussen een bepaald interval bepaalt. Hier

zijn alle variabelen nog uniform verdeeld tussen bepaalde punten. Wanneer de huwbugs

gecreeerd zijn, worden ze in de lijst structuur toegevoegd. Het feit dat de status van

de bugs pas wordt geınitializeerd nadat ze aan de list toegevoegd worden doet er niet

toe, aangezien het object hbug en het object in de lijst allebei maar een link naar een

geheugenplaats zijn. De link kopieren naar een list verandert niets aan de situatie.

De akties die voor de bugs gepland worden in het schedule, zijn beperkt tot 1

aktie, maar die wordt wel door alle bugs in de list uitgevoerd. Dit gebeurt door de

createActionForEach methode uit te voeren bij de modelaction. De “action” die ze

moeten uitvoeren is “step”. Op deze manier worden alle akties in het schedule van de

model swarm gepland.

De activateIn methode wordt hierarchisch aanroepen, en zorgt ervoor dat de sched-

ules van alle niveaus van de swarms op elkaar afgestemd worden.

Een eerste versie 36

4.1.4 De bugs

In deze fase houden deze nog niet veel in, maar hebben ze toch al de meeste kenmerken

van een object c klasse.

Elke instantie van dez klasse houdt zijn eigen 4 parameters bij, geslacht, opleidings-

niveau, leeftijd en etniciteit. Voor elk van deze attributen is er een get en set me-

thode, om het attribuut te kunnen wijzigen en lezen, en er ook nog de “step”-methode,

die elke swarm-tijdseenheid (die door de bovenliggende niveaus wordt bepaald) wordt

aangeroepen, maar waar hier alleen de leeftijd met 1 toeneemt. Dit is natuurlijk nog

niet in orde, want onze agenten sterven niet en blijven ouder worden.

Er is ook nog een print-methode, die de attributen uitschrijft, maar eigenlijk alleen

bedoeld was om te zien wat er nu eigenlijk allemaal aan de hand was in de swarm,

wanneer er iets niet werkte naar behoren.

Figuur 4.2: Interface eerste versie

4.1.5 Functionaliteit

Op gebied van functionaliteit heeft deze versie natuurlijk nog niet zoveel te bieden. Er

zijn al agentjes in de denkbeeldige wereld losgelaten met de basiskenmerken, en ze doen

al iets elke tijdsstap, maar er is nog geen onderlinge communicatie en nog geen manier

om te weten wat er aan het gebeuren is.

Een intermediaire versie 37

4.2 Een intermediaire versie

Dit moet ongeveer de eerste versie geweest zijn die ik John Lievens liet zien, er is al

een heleboel verbeterd en scherper gesteld vergeleken met de vorige versie, maar toch

werken er nog een heleboel dingen ook niet. Toen ik aan deze versie aan het werken

was begreep ik ook al meer van het waarom en hoe van de taal, en hier zat er dan ook

al wat meer creativiteit in.

4.2.1 Structuur

Aan de observer-model-agent structuur is er niet veel veranderd vergeleken met de

eerste versie, wat er wel gebeurt is, is dat de communicatie tussen de verschillende

klasses sterk is toegenomen, er zijn probes toegevoegd, en er kunnen parameters inge-

laden worden vanuit een aparte invoerfile, zodat voor verschillende experimenten niet

het volledige programma moet worden gehercompileerd.

4.2.2 De observer swarm

Qua attributen is er in deze klasse niet zo veel verschil met versie 1, er is een grafiekje

bijgekomen, en op het gebied van methodes zijn er geen nieuwe te bekennen.

Inhoudelijk is er wel iets veranderd, er is namelijk een probe aan deze klasse toegevoegd.

Een probe laat toe data uit te klasse interaktief weer te geven. De waarde van de vari-

abele kan gewijzigd worden door een nieuwe waarde in te geven en dan op de enter-toets

te drukken.

De probemap (object waar de verschillende probes per klasse in worden bijge-

houden) wordt aangemaakt in de createBegin methode, op dezelfde manier als een

gewoon object, en wordt, eens gevuld, in de probeLibrary gevoegd.

// probemap makenid <ProbeMap> probeMap;(...)probeMap = [EmptyProbeMap createBegin: aZone];[probeMap setProbedClass: [self class]];probeMap = [probeMap createEnd];

// een probe (~sensor) invoegen in de probeMap[probeMap addProbe: [probeLibrary getProbeForVariable: "displayFrequency"

inClass: [self class]]];

// probeMap in de probeLibrary voegen[probeLibrary setProbeMap: probeMap For: [self class]];

Een intermediaire versie 38

De probelibrary is een singleton-klasse, die maar een keer voorkomt voor de hele ap-

plicatie, maar wel van overal toegankelijk, waar alle probemaps van de verschillende

klasses worden bijgehouden.

In de buildObjects methode wordt de probemap dan aan een probeDisplay gekop-

peld, een venster in het programma, met een macro. Tegelijkertijd worden ook de

probeDisplays van de modelswarm geactiveerd.

CREATE_PROBE_DISPLAY (modelSwarm);CREATE_PROBE_DISPLAY (self);

Ik wil ook nog de aandacht vestigen op dit kort stukje code uit de buildObjects

methode:

if ((modelSwarm =[lispAppArchiver getWithZone: globalZone key: "modelSwarm"]) == nil)

raiseEvent(InvalidOperation,"Kan de modelSwarm parameters niet vinden !\n

Vul de file huwBugs.scm deftig in!");

Hier wordt de modelswarm gecreeerd aan de hand van de lispAppArchiver. Dit is in

feite een singleton-klasse, een klasse die maar 1 keer voorkomt voor de hele applicatie,

die code verstaat die volgens de lisp-conventies is gemaakt. Als de modelswarm niet

wordt gemaakt in het huwbugs.scm bestand, dan geeft het programma een error. Het

is mogelijk om meerdere klasses in eenzelfde bestand te maken, maar er kan slechts een

bestand per applicatie zijn.

Hier is het stukje Lisp-code in de file huwbugs.scm, dat de modelswarm aanmaakt,

het enige dit stukje doet is een modelswarm maken met de gegeven parameters.

(list(cons ’modelSwarm

(make-instance ’ModelSwarm#:numbugs 500#:numhuws 0#:pogingen 1)))

In de rest van de observer swarm is niet zoveel nieuws te bekennen. Er zijn wel

een aantal nieuwe sequenties toegevoegd aan de grafieken, die gebruik maken van een

aantal nieuwe methodes die de bugs aanbieden, en er is een nieuwe grafiek bijgekomen.

Een intermediaire versie 39

4.2.3 De model swarm

De model swarm heeft wel een aantal attributen bijgekregen. Er wordt nu ook bijge-

houden hoeveel huwelijken er in de laatste stap gebeurd zijn, en hoeveel in het totaal

al gebeurd zijn. Er is ook randomizer object toegevoegd, van het type NormalDist

dat eens geınitialiseerd normaal verdeelde waarden kan weergeven met een bepaalde

variantie en een bepaald gemiddelde.

Op het gebied van functies zijn er ook enkele nieuwigheden. Er zijn enkele tel-

methodes toegevoegd, en getNumBugs, dat het aantal bugs teruggeeft. Als de parame-

ter numbugs gewijzigd is na het initialiseren van de bugs, zal deze methode dus niet het

oude maar het nieuwe aantal teruggeven. Het oude aantal is nog steeds te verkrijgen

door [getHuwBugsList getCount].

Ook hier wordt er een probemap in de methode createBegin gemaakt, maar hier

wordt die niet alleen met probes voor variabelen, maar ook met probes voor methodes

gevuld. Die methodes verschijnen als een knop in het probedisplay, en als die knop

ingedrukt wordt verschijnt de output van de functie in het vakje ernaast.

[probeMap addProbe: [probeLibrary getProbeForMessage: "telHuwelijken"inClass: [self class]

]];

De probemap wordt ook weer in de probelibrary gevoegd, en zoals gezien bij de observer

swarm, daar geactiveerd.

De manier waarop random getallen met een bepaalde generator worden verkregen

is niet zomaar een of andere functieaanroep. Eerst wordt een bepaalde randomizer

gekoppeld aan een randomizer object (hier bvb een NormalDist type), waarna het

geınitialiseerd wordt met een seed dat bepaald wordt wanneer de simulatie gecompileerd

wordt. Voor een seed gebaseerd op de kloktijd, moet de applicatie met de “-b” vlag

uitgevoerd worden. Het voordeel van een vast seed is dat een experiment dat vreemde

of interessante resultaten voortbrengt, een tweede keer kan gereproduceerd worden.

Er kunnen voor een object van het NormalDist-type altijd een default gemiddelde en

variantie vastgelegd worden, iets wat hier niet gebeurt.

myNormalDist = [NormalDist create: self setGenerator: randomGenerator];skill = [myNormalDist getSampleWithMean: 25 withVariance: 50];

Het enige dat nog de aandacht trekt is het feit dat er in het modelActions-object

drie akties na elkaar gepland zijn, waarvan er twee voor al de bugs in de list bedoeld

Een intermediaire versie 40

zijn, en eentje voor zichzelf. Deze akties zullen in de gedefinieerde volgorde worden

uitgevoerd, en de volgorde is hier van belang: na het uitvoeren van “checkToDie” zullen

alle gehuwde bugs weer uit de huwelijkspool verdwenen zijn. Dat de step-aktie voor de

tel-aktie gebeurt is ook weer logisch, aangezien de telaktie pas een geldig resultaat zal

leveren als de gehuwde bugs nog in de huwelijkspool aanwezig zijn. Het schedule moet

niet verlengd worden omdat er nu een actiegroep van meer dan een aktie in voorkomt.

De aktiegroep wordt beschouwd als iets dat in een tijdsstap kan uitgevoerd worden.

[modelActions createActionForEach: huwBugsList message: M(checkToDie)];[modelActions createActionForEach: huwBugsList message: M(step)];[modelActions createActionTo: self message: M(telHuwBijTotaal)];

Een andere mogelijkheid om deze handelingen uit te voeren zou zijn om drie verschil-

lende actionGroups te definieren, het schedule initieren met een interval van 3 en de

verschillende actionGroups op het juiste, verschillende tijdstip te plaatsen. Dit zou wel

als gevolg hebben dat de tijd in de bovenliggende lagen drie keer zo snel zou lopen, met

enkele vreemde bijwerkingen als gevolg.

4.2.4 De bugs

Een aantal nieuwe attributen en methodes hebben de huwbugs bijgekregen: eerst en

vooral wordt er bijgehouden of ze al dan niet gehuwd zijn, en ze houden een extra

parameter “tries” bij, die het aantal keren dat ze naar een geschikte partner zoeken per

tijdseenheid voorstelt. En, niet te vergeten: ze houden een link bij naar de huwelijks-

pool waarin ze zich bevinden, of, beter gezegd, waarin ze op zoek gaan naar een partner.

Deze link wordt aangemaakt wanneer de bugs in de modelswarm gecreerd worden.

Qua extra methodes zijn er naast de nieuwe get- en set-methoden, ook enkele getEq-

methoden. Deze herschalen de waarden van een bepaald attribuut naar procenten. Dit

met als enige doel de verschillende parameters op eenzelfde waardeschaal te kunnen

vergelijken. Het is misschien ook logisch even op de afwezigheid van de get-methode

voor de huwelijkspool te letten, omdat dit een van de attributen is die tot de interne

keuken van het programma behoort. Ze moet geınitialiseerd worden, maar blijft verder

verborgen.

In de implementatie (bugs.m) is er in de step-methode een regel bijgekomen, namelijk

if (gehuwd == 0) [self findPartner];

De Bugs gaan op zoek naar een partner tijdens elke tijdsstap, tenzij ze al gehuwd

zijn. Dit kan natuurlijk voorkomen, want als de eerste bug in de lijst op zoek gaat

Een intermediaire versie 41

naar een partner en er eentje vindt, is er natuurlijk al een andere huwbug in de lijst

die ook zal gehuwd zijn. In de methode findpartner gaan de bugs op zoek naar een

huwelijkspartner in de pool. Eerst wordt met een iterator een item uit de lijst gezocht,

de kandidaat-huwelijkspartner, en dan worden de grenzen tussen de partners afgetast,

en eventueel een huwelijk gevestigd. Misschien is het ook even kort interessant af te

vragen als een bug toch niet al dan niet toevallig met zichzelf kan trouwen, maar dat is

niet het geval, aangezien er gecheckt wordt of de partners van een verschillend geslacht

zijn, en een bug kan maar 1 geslacht tegelijk hebben. De formule waarbij 2 partners

ontdekken als ze interesse hebben voor elkaar, is

liefde_Skill = [partner getEqSkill] - [self getEqSkill];if (liefde_Skill < 0) liefde_Skill = -liefde_Skill;

liefde_Age = [partner getEqAge] - [self getEqAge];if (liefde_Age < 0) liefde_Age = -liefde_Age;

if ([partner getEtnic] == [self getEtnic]) liefde_Etnic = 0;else liefde_Etnic = 50;

cupido = [uniformIntRand getIntegerWithMin: 0 withMax: 100];

liefde_Totaal = // zo klein mogelijk !!liefde_Age + liefde_Etnic + liefde_Skill + cupido;

if (liefde_Totaal <= 200) // getmarried ...

Dit komt overeen met(

(randomgetal)+∑

allekenmerken

|kenmerk(self)− kenmerk(partner)|)

≤ getal(200)

In de volgende versie is dit gewijzigd, daar passen de huwelijkskandidaten deze

formule op elkaar toe, wat beter is omdat de bugs dan zelfstandiger zijn. Wanneer

een bug hier de leeftijd 36 bereikt, of gehuwd is, moet hij verdwijnen. Dit gebeurt

in de methode checkToDie. Als aan een van deze laatste condities voldaan is, wordt

de methode reincarnate aangeroepen, waarin een nieuwe, jongere bug met dezelfde

kenmerken in de pool wordt gesmeten. Dit is eigenlijk een vuile truuk, om geen bugs

te moeten laten sterven en geboren worden, wat een hels karwei qua implementatie is,

en niet te vergeten qua resources.

De implementatie van de getEqxxxx methodes is vrij vanzelfsprekend. Er wordt

geprobeerd de attributen uit te tekenen op een procentuele schaal, en voor de meeste

attributen is dit triviaal.

Een intermediaire versie 42

functionaliteit

Er is al heel wat gebeurd sinds die eerste versie, ook grafisch. Maar was het al bruik-

baar?

Op dit moment is het in elk geval een simulatie die naam waardig. Er zijn agenten

die een bepaald gedrag vertonen, en de mogelijkheid is er om centraal de simulatie te

besturen. Om echt nuttig te zijn, bvb voor studies, is er nog maar een korte weg af

te leggen. Output, output, output. Meer en gedetailleerdere resultaten zijn nodig om

zin te geven aan enige vorm van interpretatie. Verder is er qua gedrag voor elk idee

een nieuwe mogelijkheid, het is hier een beetje het kaf van het koren scheiden en de

interessantste en meest realistische te implementeren, met zo weinig mogelijk verlies op

gebied van efficientie en andere functionaliteit.

Zo kwamen er op dit moment ook veel ideeen naar boven, aangebracht door John

en soms door mijzelf, die daarna al dan niet geimplementeerd werden. Deze ideeen zijn

de basis van de wijzigingen die nog gemaakt zijn na deze versie.

Figuur 4.3: Interface intermediaire versie.

De finale versie 43

Hier was de applicatie duidelijk al op de goede weg, dit mag ook blijken uit de code

en de grafische output. Verder wordt vooral nog meer realisme in de handelingen van

de agenten, en meer en gedetailleerdere resultaten. Op naar een volgende versie.

Misschien nog even opmerken dat het centrale object hier de huwbugslist is gewor-

den, en dat de meeste communicatie tussen de bugs onderling, partners zoeken, en

tussen de bugs en het systeem, zoals de data die naar de graphs gaat, via deze huw-

bugslist verloopt. Dit zou een probleem kunnen zijn, omdat dit ene object de “bot-

tleneck” of strophals van de applecatie kan worden. Dit probleem zal zich niet zozeer

voordoen bij seriele processoren, maar wel wanneer dit programma bvb op een com-

puter met meerdere processoren zal worden uitgevoerd (deze functionaliteit zal echter

pas vanaf de volgende versie van swarm aangeboden worden).

4.3 De finale versie

Dit is de laatste versie die ik aan John Lievens bezorgde. Dit is natuurlijk geen eindpunt,

software is pas af als ze niet meer gebruikt wordt. Wat het wel is, is een eindpunt van

deze thesis, in de software-ontwikkelingszin van het woord. Ik hoop dat ik met trots

kan zeggen dat dit een tool is dat op een nuttige uitbreiding is van de gereedschapskist

van de bevolkingswetenschappen, en een even nuttige exploratie van agentgebaseerde

technieken op zich, door de ogen van swarm.

De dingen waarop me ik na de vorige versie vooral heb toegespitst zijn de ver-

beteringen door John Lievens voorgesteld, in die mate dat het toegelaten werd door

de technologie en mijn programmakennis. Wat de aandacht zal trekken is vooral een

doorgedreven parametrisatie, en meer gespecialiseerde en meer outputfuncties.

4.3.1 Structuur

De observer swarm, model swarm en de agenten zitten nog steeds in het model, maar

de implementatie van deze delen is vooral in volume toegenomen. Het korte main

programma blijft ongewijzigd, maar het Huwbugs.scm bestand dat alle instelbare pa-

rameters bevat is sterk uitgebreid.

Over het algemeen blijft de structuur echter hetzelfde: vanuit het korte main-

programma wordt de observer swarm opgeroepen, die op zijn beurt de model swarm

beheert, die op zijn beurt een lijst bijhoudt van de bugs, elk met hun eigen schedule en

activity-list.

De finale versie 44

4.3.2 De observer swarm

Deze swarm bevat in de finale versie twee EZgraphs, die hun informatie uit de list met

bugs (de huwelijkspool) halen, maar die meer als controlepunten dienen dan dat er echt

interessante informatie van valt te lezen. Wat wel duidelijk wordt is het percentage van

de bugs die huwen, en welk percentage daarvan dan weer niet binnen zijn eigen etnische

groep is gehuwd. Deze grafiekjes zijn echter leuk om te zien, en geven de evolutie van

de bugs ten opzichte van de tijd accuraat weer.

Het meeste van de code in deze swarm heeft dan ook te maken met het beheer van

deze twee graphs en het beheer van de model swarm. Aan de implementatie van de

probemap voor deze swarm is niks gewijzigd.

Wat niet zichtbaar is, maar waar wel veel informatie in de modelswarm geloodst

wordt, is het aanroepen van de lispAppArchiver, die de modelswarm aanmaakt, en alle

parameters uit het bestand “Huwbugs.scm” leest.

Er wordt niet gecontroleerd of alle parameters wel ingevuld zijn, alleen dat deze file

inderdaad een object modelswarm aanmaakt.

Omdat de creatie van de model swarm eigenlijk door een stukje Lisp-code gebeurt,

en niet door de observer swarm zelf, alhoewel deze wel het object beheert en zelf het

commando aan de lisp-archiver voor de creatie geeft, is het misschien interessant kort

even erbij stil te staan.

(list(cons ’modelSwarm

(make-instance ’ModelSwarm#:stopoptijdstip 100#:numbugs 700#:printout 1#:pogingen 5....)))

Wat er hier staat is eigenlijk een commando, dat een instantie van het type “Model-

swarm” (klasses hebben een hoofdletter vooraan in swarm, instanties een kleine letter)

dat “modelswarm” genoemd wordt, gemaakt wordt met de gegeven parameters. Het is

niet zo dat de stukken tekst voor de parameters maar louter herkenningswoorden zijn

voor swarm, neen, het is effectief code die run-time uitgevoerd wordt, aan de hand van

de LispAppArchiver, een stuk code dat in staat is Lisp-commando’s te begrijpen en uit

te laten voeren in de rest van het programma.

De finale versie 45

4.3.3 De model swarm

Alhoewel de structuur zelf van de model swarm weinig veranderde met de vorige bespro-

ken code, ziet ze er toch heel wat chaotischer en uitgebreider uit. Dit is voornamelijk

door alle parameters die ingesteld kunnen worden, en de meer uitgebreide resultaten

die geleverd kunnen worden.

De functies extraInfo en eindInfo leveren de getabuleerde resultaten voor de huweli-

jken in respectievelijk de laatste tijdsstap en de gehele duur van het programma. Om

deze resultaten uit de bugs te halen, is het vitaal te wachten tot elke bug zijn partner

gevonden heeft of net niet, en sneller te zijn dan het vernieuwen van de bugs, bij het

begin van de volgende tijdsstap. Dit is zichtbaar in actiongroup “modelactions” :

[modelActions createActionForEach: huwBugsList message: M(checkToDie)];[modelActions createActionForEach: huwBugsList message: M(getOlder)];[modelActions createActionForEach: huwBugsList message: M(step)];[modelActions createActionTo: self message: M(telHuwBijTotaal)];[modelActions createActionTo: self message: M(checkToStop)];

Het eerste dat elke tijdsstap moet gebeuren is de overbodige bugs verwijderen en

vervangen door nieuwe, daarna alle huwbugs wat ouder laten worden (telt gewoon bij

elke bug eentje op bij de leeftijd), en daarna op zoek gaan naar een partner en alle

andere dingen die een bug nog zou willen doen gedurende een tijdsstap.

De twee volgende akties zijn, zoals moet blijken uit het “createActionTo: self”

statement, niet voor alle bugs, maar voor de modelswarm zelf bestemd. De eerste telt

alle huwelijken en houdt deze bij om achteraf de output over het ganse verloop van het

programma te kunnen weergeven. De tweede controleert of het stoptijdstip nog niet

bereikt is, en, indien zo, stopt het.

De aandachtige lezer vroeg zich natuurlijk al af waarom de checkToDie methode

eerst komt, en niet op het einde of na de step methode, zoals verwacht. Eerst en

vooral wordt deze actionlist herhaaldelijk na elkaar uitgevoerd, dus in een zekere zin

komt de checkToDie methode ook altijd op het einde. De eigenlijke reden is omdat

wanneer deze op het einde wordt uitgevoerd, er andere output niet meer bruikbaar

wordt. Deze aktielijsten worden door swarm als een eenheid van aktie behandeld, en

wanneer er in de observerswarm naar de huwbugs zou gekeken worden, dan zou alle

interessante informatie er reeds verdwenen zijn, terwijl alle bugs in deze toestand na

het beeindigen van deze lijst met akties, nog steeds alle informatie over de voorbije

tijdseenheid bevatten. Een andere oplossing, het werken met meerdere aktielijsten,

De finale versie 46

heeft dan weer als gevolg dat elke elementaire stap in de modelswarm dubbel zo lang

zou duren als in de observer swarm, wat ook weer niet de bedoeling is.

Voor het ophalen van de informatie uit de bugs wordt gebruik gemaakt van een

iterator, een index die door alle elementen van de huwelijkspool loopt. De algemene

manier van werken is als volgt:

id <Index> huwIndex = nil;

huwIndex = [huwBugsList begin: [self getZone]];

while ([huwIndex next]){

if ([[huwIndex get] getGehuwd] == 1){i = [[huwIndex get] getEtnic];j = [[huwIndex get] getPartnerEtnic];

//....}

}[huwIndex drop];//...

De iterator wordt gecreeerd, en doorloopt de lijst op manier die bijna identiek is als

de iterators uit de STL-bibliotheken. Wat opvalt is dat, alhoewel er geen malloc en free

meer nodig zijn in object C, er toch nog voor objecten nood is aan een drop-methode

om ze uit het geheugen te krijgen. Bij de swarm-objecten is dit echter verborgen door te

werken met een de createBegin en createEnd methodes, die door hun super-methodes

aan te roepen, een drop-methode erven van de bovenliggende klasses.

Waar ik ook even de aandacht op wil trekken, is het feit dat in de probemap de

parameter “stopoptijdstip” run-time aanpasbaar is. De parameter een nieuwe waarde

geven en dan op enter drukken zorgt ervoor dat er op dit nieuwe tijdstip gestopt zal

worden.

[probeMap addProbe: [probeLibrary getProbeForVariable: "stopoptijdstip"inClass: [self class]]];

[probeMap addProbe: [probeLibrary getProbeForVariable: "counter"inClass: [self class]]];

[probeMap addProbe: [probeLibrary getProbeForVariable: "huws"inClass: [self class]]];

[probeMap addProbe: [probeLibrary getProbeForVariable: "etnischehuws"inClass: [self class]]];

[probeMap addProbe: [probeLibrary getProbeForVariable: "nietetnischehuws"

De finale versie 47

inClass: [self class]]];[probeMap addProbe: [probeLibrary getProbeForVariable: "totalhuws"

inClass: [self class]]];[probeMap addProbe: [probeLibrary getProbeForVariable: "totetnischehuws"

inClass: [self class]]];

Dit is ook zo met de andere parameters, en dit zou ook zo zijn zouden er nog parameters

bijgevoegd worden, maar bij deze andere attributen heeft het weinig nut, of, in het geval

van bijvoorbeeld de skill of belang parameters (hier niet aanwezig), weinig effect, omdat

na de initialisatie van de bugs, deze parameters niet meer gebruikt worden.

De meeste andere gebruikte technieken en methodes in de broncode zijn reeds uit-

gelegd in de vorige stukken of betrekkelijk voor de hand liggend.

4.3.4 De bugs

Bij deze structuur is er sinds de vorige versie wel het een en het ander veranderd.

Om te beginnen heeft elke bug een extra aantal attributen: een dummy kenmerk, dat

qua interpretatie nog ingevuld kan worden, tijdstippen sinds de “geboorte”, een reeks

waardeparameters om per kenmerk een voorkeur weer te geven, en, last but not least,

elke bug onthoudt bij een huwelijk welke zijn partner is (was).

Op gebied van methodes zijn er ook enkele nieuwe: zo zijn er de getPartnerXxx,

die als de bug gehuwd is, een kenmerk van de huwelijkspartner weergeven, en enkele

nieuwe getters en setters.

Een van de belangrijke veranderingen die al deze nieuwe kenmerken mogelijk maken,

is het feit dat bij een huwelijk elke partner nu voor zich kan kijken als de partner de

ware Jacob of Jacobina is, elk met een eigen waardenschaal, die in BelangKenmerk

attributen zit opgeslagen. Het controleren als een partner aan alle eisen voldoen is dan

ook in een aparte methode terechtgekomen (checkPartnerForWedding), een methode

die alleen ja of nee kan teruggeven.

Het bijhouden van de huwelijkspartner in elke bug was vooral noodzakelijk voor

het extraheren van informatie na elke tijdsstap, maar biedt ook nog andere mogelijk-

heden: zo zou het implenteren van generaties, elke nieuwe bug die in de huwelijks-

pool terechtkomt erft eigenschappen van zijn virtuele ouders, geen problemen mogen

veroorzaken, meer hierover in het volgende deel.

Het dummykenmerk wordt nu natuurlijk ook in rekening gebracht in de checkPart-

nerForWedding methode, de methode die moet controleren als een partner geschikt is.

Als een bepaald kenmerk niet zou mogen meetellen voor een bepaalde bug, volstaat

De finale versie 48

het het belang van dat kenmerk op nul te zetten, aangezien deze methode een licht

gewijzigde formule gebruikt, namelijk waar voor elk kenmerk een waardeschaal aan elk

kenmerk wordt gehecht:

(randomgetal ∗ belang random getal)+

∑

allekenmerken

belang kenmerk∗ |kenmerk(self)− kenmerk(partner)|

≤ belang totaal

Wat ook gewijzigd is, is dat deze formule nu tweemaal met andere parameters

gebruikt wordt, eenmaal bij elke partner met zijn eigen belang-attributen.

Elke bug houdt ook een extra parameter bij die, wanneer hij aangezet wordt, ervoor

moet zorgen dat elke bug bij elke belangrijke gebeurtenis dit meedeelt aan de gebruiker.

Deze parameter is het attribuut printout. Als deze parameter op 1 staat, zal elke bug

bij een huwelijk of bij het verdwijnen uit de huwelijkspool zijn kenmerken meegeven,

evenals de tijd die hij in de pool verbleef. Deze zou afleidbaar moeten zijn uit de leeftijd,

maar dit is niet altijd zo: wanneer de bugs voor het eerst in de huwelijkspool verschijnen,

bij de initialisatie van de applicatie, hebben ze allen al een bepaalde startleeftijd. Wat

bij deze bug-structuur nu wel in een bepaalde mate naar boven komt, is dat de structuur

heel wat onduidelijker wordt door de omvang ervan, en door de parametrisatie van de

applicatie.

De totalage parameter die uitgeschreven wordt is niks anders dan de tijd die er

al is verlopen sinds het starten van de applicatie, deze wordt niet aangepast bij het

reıncarneren van de bugs.

De meeste structuren en technieken zijn nu al ergens aan bod gekomen in dit of het

vorige hoofdstuk, maar ik wil toch nog even het oog richten op de createEnd-methode:

- createEnd{if (huwpool == nil)

[InvalidCombinationraiseEvent: "Geen geldige pool bij bug aangetroffen\n"];

if ( gender<0 || skill<0 || age<0 || etnic<0 || dummy<0)[InvalidCombination raiseEvent: "Ongeldige waarde in Bug (1)\n"];

tempage = 0;totalage = 0;

Volgende versies 49

return self;}

Zoals uit dit stukje al doet vermoeden, is deze methode een ideale plaats om controles

uit te voeren als de initialisatie goed is verlopen, maar ook om parameters zoals tempage

en totalage, die niet instelbaar zijn vanuit de model swarm, te initialiseren.

4.3.5 Functionaliteit

Omdat deze versie de finale is, komt de functionaliteit van deze versie overeen met de

functionaliteit besproken in het vorige hoofdstuk, en gedeeltelijk in het volgende. Ik

wil echter niemand een screenshot van het volledige programma in werking ontzeggen.

Wat niet zichtbaar is de textuele output, zoals in tabel 3.1 en 3.2.

4.4 Volgende versies

In dit deel wil ik even de zin en onzin van enkele extra mogelijkheden overlopen. Deze

zouden bijvoorbeeld kunnen zijn :

? generaties

? meer vormen en niveaus van swarms (subsubswarms)

? de mogelijkheid om at run time parameters te veranderen

Maar eigenlijk heb ik dit probleem achterwaarts benaderd: als ik alle mogelijkheden

en tijd van de wereld had, wat zou ik nog willen bijvoegen om een “ideale” simulatie

te bekomen, en wat niet, en waarom niet?

4.4.1 Generaties

Dit is waarschijnlijk het meest interessante onderdeel dat nog niet geımplementeerd

is in deze applicatie. Hiermee wordt bedoeld dat nieuwe bugs de kenmerken zouden

vertonen van bugs die tijdens een vorige tijdsstap gehuwd zijn. Generaties in de appli-

catie toevoegen zou effecten kunnen hebben op macroscopische schaal, bijvoorbeeld het

“uitsterven” van bepaalde etnische groepen, of het integreren van bepaalde groepen dat

sneller of trager kan gaan. Vreemd genoeg zou dit implementeren niet zo bijster veel

moeite meer kosten, alle benodigdheden zijn reeds aanwezig. Alleen de reincarnate-

methode zou moeten aangepast worden naar iets in de aard van

Volgende versies 50

Figuur 4.4: Interface finale versie.

- reincarnate{gehuwd = 0;tempage = 0;age = 18;if ([getuniformInt withMin:0 withMax:1] == 0) skill = [partner getSkill];if ([getuniformInt withMin:0 withMax:1] == 0) etnic = [partner getEtnic];...

return self;}

Op deze manier zouden kenmerken telkens ofwel van de moeder ofwel van de vader

overgeerfd worden. Dit zou kunnen leiden tot het verminderen van het aantal mogelijke

combinaties, maar dit zou gedeeltelijk kunnen opgevangen worden door bijvoorbeeld

een (willekeurige) verdeling vader/moeder aan de kinderen mee te geven. Dit zou dan

Volgende versies 51

weer kunnen leiden tot een uitmiddeling van kenmerken per etnische groep of voor de

hele groep, iets wat het onderwerp van enkele testen zou kunnen zijn.

4.4.2 Meerdere niveau’s van swarms.

Hier wil ik toch even nuanceren bij het mogelijke nut van het invoeren van deze bij-

komende structuren in de applicatie. Door een mogelijk extra niveau in te voeren,

bijvoorbeeld een aparte swarm maken voor elke etnische groep, met elk eigen ken-

merken en formules, worden de mogelijkheden serieus uitgebreid, maar de complexiteit

in de vorm van communicatie wordt hierdoor sterk bemoeilijkt, ook al omdat het bij-

houden van een afzonderlijke, centrale buglist in dit geval voor overhead zou zorgen.

Dit wil niet zeggen dat dit idee niet waardevol zou zijn, integendeel, het stelt gewoon

een nieuwe richting voor in het agent-gebaseerd modelleren, en om dit toe te passen zal

er meer dan een nachtje over geslapen moeten worden.

Swarm laat ook toe om een extra swarm bovenop de observer swarm te bouwen, die

dan de applicatie telkens met een nieuw stel parameters zou kunnen laten lopen. Voor

onderzoeksdoeleinden zou dit een zeer handig hulpmiddel kunnen zijn.

4.4.3 Run time de parameters kunnen wijzigen

Dit is iets wat een verandering van de omgeving zou kunnen weergeven. Het idee zou

zelfs verder kunnen worden getrokken naar een omgeving die afhankelijk is van enkele

parameters, die eventueel zelfs weer afkomstig zouden kunnen zijn uit de veranderde

situatie van de bugs zelf. Dit klinkt natuurlijk allemaal wel mooi, maar is het ook

nuttig, en haalbaar?

De nuttigheid ervan ligt natuurlijk in het voorstellen van veranderende situaties,

waar bijvoorbeeld een nieuw evenwicht wordt gezocht wanneer een nieuwe etnische

groep wordt geıntroduceerd.

De haalbaarheid ervan is moeilijker te overzien. Er zijn een paar mogelijkheden,

waarvan de meeste wel voor een aanzienlijke overhead zullen zorgen. Ik denk bvb aan

bij de reincarnate methode, op het niveau van de bugs, telkens de nieuwe parameters

aan de modelswarm te vragen, wat niet eenvoudig te programmeren zal zijn, of, en dit

is waarschijnlijk de eenvoudigste methode, telkens er een parameter gewijzigd wordt, zo

snel mogelijk tussen twee tijdsstappen door de nieuwe parameters aan de bugs proberen

door te geven. Deze laatste oplossing zou dan natuurlijk op het niveau van de model

swarm komen en er zou dan een nieuwe methode moeten komen in de actionlist, bij-

Volgende versies 52

voorbeeld een “update” methode, die wel een deel resources zou vreten, maar dat is iets

wat tot een minimum zou kunnen beperkt worden door met een “dirty bit” te werken.

Om het aantal bugs runtime te kunnen wijzigen, zouden er bovendien een nieuwe

addBug en removeBug methode noodzakelijk zijn, iets wat niet in de mate van het

onmogelijke ligt.

Hoofdstuk 5

Functionaliteit en interpretatie

The Three Laws of Robotics

1. A robot may not injure a human being, or, through

inaction, allow a human being to come to harm.

2. A robot must obey the orders given it by human beings except

where such orders would conflict with the First Law.

3. A robot must protect its own existence as long as such

protection does not conflict with the First or Second Law.

Isaac Asimov

5.1 Functionaliteit

In dit hoofdstuk mag ik het zeker niet laten de mogelijkheden en gebreken van mijn

applicatie aan het licht te brengen, met andere woorden: Wat is er mogelijk, en wat

niet?

5.1.1 Wat is mogelijk?

Het leukst is natuurlijk het hebben over de mogelijkheden van iets dat men zelf heeft

gemaakt. De details, zijn er vijfendertig of maar achtentwintig cijfers na de comma

mogelijk, zijn hier minder belangrijk: dit is het stukje waarin ik een beetje mijn werk

probeer op te hemelen, ik zal het daarom ook niet te lang proberen te houden.

Wat kan er dan? Om te beginnen wordt de probleemstelling van de huwelijksmarkt

die we willen onderzoeken, op een agent-gebaseerde manier in een model gegoten, en

zo uitgevoerd. Het gedrag van de afzonderlijke agenten, “bugs” genaamd in het swarm

simulatie model, is doorzichtig geprogrammeerd, in die zin dat ze, elk voor zich, een

53

Functionaliteit 54

voorspelbare sequentie akties zullen uitvoeren, die in een beperkt aantal functies en

methodes gemodelleerd worden.

De applicatie kan gemodelleerd worden aan de hand van een talloze parameters. Met

behulp van deze parameters is het mogelijk de startsituatie van een bepaalde simulatie

correct en eenvoudig in te voeren aan de hand van een bestand.

Sommige output kan in tabelvorm, andere dan weer in een meer grafische vorm, in

een grafiek op het scherm getoverd worden. De mogelijkheid bestaat ook om elke bug

bij elke belangrijke gebeurtenis te laten rapporteren.

5.1.2 Wat kan er niet?

Structureel heeft deze applicatie niks te kort, maar er zijn toch een aantal dingen waar

ik niet in slaagde, ongeacht de moeite. Het zijn vooral kleine maar vervelende dingen.

Zo is er het feit dat de probemaps, de vensters die de observer swarm en de model

swarm controleren, zichzelf niet elke tijdsstap automatisch aanpassen. Er is de on-

gelegenheid dat de grafiekjes altijd een tijdsstap achterlopen op de “feiten”, wat ook

maar een klein ongemak is, maar waar ook rekening mee moet worden gehouden. Zo

is er de ook de onmogelijkheid de parameters run-time te wijzigen, of alle parameters

in windows-venstertjes weer te geven. Waar ik ook nog niet vermeldde is dat er geen

apart uitvoerbestand voor afzonderlijke data kan gespecifieerd worden, bijvoorbeeld een

apart bestand voor individuele data, en een afzonderlijk bestand voor data betreffende

de groep.

Wat in agent-gebaseerd opzicht een groter probleem is, is dat de output beperkt

blijft door de aanwezigheid van te veel parameters, in dit stadium kan je alleen uit

de applicatie halen wat men erin steekt, waarmee ik bedoel dat het resultaat bepaald

is door de parameters die op voorhand worden ingegeven. Door bijvoorbeeld met

generaties te werken, of de agenten zichzelf na verloop van tijd soepeler op te laten

stellen zou het eindresultaat al een stuk onconventioneler kunnen worden.

5.1.3 Meerwaarde

De vraag kwam van John Lievens, of er wel een verschil is tussen dit programma en

een “gewoon” programma, waar bijvoorbeeld een lusje loopt die iets dergelijks doet.

Mijn eerste gedacht was dat er inderdaad geen verschil was, behalve dan dat in dit

programma alles effectief wat meer vanuit het ik-standpunt van de agent verloopt.

Daar lag ik natuurlijk wakker van, en ik dacht er nog een paar keer goed over na.

Interpretatie 55

De vraag kan eigenlijk hersteld worden wat nu eigenlijk de geboden meerwaarde is,

vergeleken met een andere, conventionele programma’s (in zover die bestaan, natu-

urlijk).

Eerst en vooral moet ik wel toegeven dat puur functioneel gezien, het verschil met

de conventionele programma’s inderdaad nog minimaal is, maar . . .

Programmatorisch gezien is er echter een veel groter verschil: er is de andere struc-

tuur van het programma, waarbij het gedrag gecentraliseerd wordt rond de agenten, de

bugs. Hieruit volgt, na constructie van de basis-structuur, dat het gemakkelijker wordt

om structuren uit te breiden, of functionaliteit bij te voegen, daar waar er bij een meer

conventioneel programma veel kans is dat alles herschreven moet worden. Ik wil als

voorbeeld nog maar eens generaties aanhalen, waarvoor, zoals beschreven in hoofdstuk

4, maar een paar lijnen extra code zouden nodig zijn.

5.2 Interpretatie

Op het gebied van interpretatie speel ik natuurlijk geen thuismatch, maar al con-

verserend met John Lievens heb ik toch enkele glimpsen van het doeldomein opgevan-

gen.

5.2.1 Aard van de interpretatie

De mogelijke interpretatie op het gebied van de bevolkingswetenschap ligt vooral in

het ontdekken en analyseren van de oorzaken van realistische situaties, minder in het

gebied van voorspellen van de toekomst aan de hand van de huidige situatie.

Wat dus niet de bedoeling is van het programma is een “glazen bol” spelen voor

wetenschappers, daarvoor zouden ook (bijna) alle mogelijke parameters in acht genomen

moeten worden, iets wat niet mogelijk is met het huidige niveau van technologie. Wat

wel de bedoeling is, is een hint geven naar de mogelijke oorzaken van trends of situaties:

als bepaalde parameters met de juiste waarde worden ingevuld, dan wordt het gewenste

effect ook zichtbaar in de simulatie, dus die omstandigheden zouden dan aan de bron

van deze trend of situatie kunnen liggen.

Wat dus in de mogelijkheden van dit model van simuleren ligt, is kenmerken op

macroscopische schaal aan de hand van ingegeven microscopische kenmerken analyseren

of aan het licht brengen.

Als iemand dan toch dit simulatie systeem zou (willen) gebruiken om voorspellingen

te maken, dan zal die moeten aanvaarden dat er hoogstens mogelijke situaties zullen

Interpretatie 56

mee kunnen worden berekend, en niet een “juiste oplossing”. Misschien kunnen er wel

bepaalde mogelijkheden geelimineerd worden. Een juist gebruik zou dan suggereren dat

men bijvoorbeeld als invulling voor de dummy-parameter een heleboel waarden met een

hoge belangrijkheidsfactor ingeeft bij alle mogelijke bugs, en evenveel keer de simulatie

laat lopen, waarna men kan veronderstellen dat met een hoge waarschijnlijkheid in een

naburige toekomst de situatie binnen bepaalde grenzen zal liggen.

Hoofdstuk 6

Besluit

Michael: “I was wondering if you were free today?”

Stephanie: “Yeah. I’m free everyday, it’s in the Constitution.”

From: “Grease 2”

6.1 Verwezenlijkingen

Eerst en vooral hoop ik met deze scriptie een rondleiding gemaakt te hebben door

de wondere wereld die het swarm simulatie systeem is, aan de hand van een nieuwe

applicatie, waarvan ik ook hoop dat ze haar nut zal bewijzen in de praktijk.

Ik hoop onderweg zeker enkele structuren en denkwijzen van agent-gebaseerde pro-

gramma’s in het algemeen en van swarm in het bijzonder te hebben verduidelijkt, en een

bijdrage te hebben geleverd aan deze spannende technologie, en zelfs wat duidelijkheid

geschapen te hebben bij het maken van een applicatie in swarm.

Maar wat ik vooral hoop duidelijk gemaakt te hebben, is dat het swarm simulatie

systeem een handige tool kan zijn voor allerlei gebieden, dat het een bruikbare tool kan

leveren voor exploratie van bevolkingswetenschappen, en dat de resultaten die ermee

behaald kunnen worden, binnen de lijnen van het verhoopte liggen, in dit geval : de

exploratie van de huwelijksmarkt, met mogelijke interpretatie van de belangen van

bepaalde parameters en waarden in een realistische context.

6.2 Observaties

6.2.1 Nieuw

Eerst en vooral wil ik toch gezegd hebben dat ik overtuigd ben van de mogelijkheden van

deze agent-gebaseerde technologie, anders zou ik nooit aan deze scriptie zijn begonnen.57

Observaties 58

Dat ze een nieuwe kijk op veel problemen brengt of kan brengen, dat weet ik zeker.

Aan de andere kant, staat deze technologie nog in de kinderschoenen, en hoewel er al

verschillende toepassingsplatforms op de scene aanwezig zijn, zijn er weinig praktisch

bruikbaar, en is het gedachtengoed alleen nog maar in de hoogste regionen van de

computerwetenschappen doorgedrongen.

Van al deze toepassingspaddestoelen die nu uit de grond aan het schieten zijn, is het

swarm platform waarschijnlijk wel de meest gebruiksvriendelijke, meest verspreidde en

meest bruikbare. Het feit dat het amerikaanse leger swarm al gebruikt om simulaties

uit te laten voeren, en dat ze de belangrijkste sponsor van SDG geworden zijn, is meer

dan een teken aan de wand.

Toen ik met deze scriptie begon, dacht ik, in wat waarschijnlijk naıviteit was, hier

een enorm project mee te kunnen verwezenlijken, of toch iets spectaculair mee te doen.

De realiteit drukte me al gauw met de neus op de feiten, maar toch. Ik ben misschien

gedeeltelijk wel ontgoocheld omdat ik de wereld niet volledig op zijn kop heb gezet met

mijn vernieuwende ideeen, maar besef ik wel dat ik toch een kleine stap in de goeie

richting heb gezet, en in die zin heb ik wel voldoening gekregen van mijn werk.

6.2.2 Anders

Deze scriptie gaat ook op een manier over het op een andere manier naar dingen kijken.

Een andere manier van programmeren, een andere manier van simuleren, een andere

manier van onderzoek en een andere manier om computerprogramma’s te gebruiken.

De programmeertaal swarm, hoewel ze doorzichtig lijkt, verschilt toch op veel vlakken

van klassieke talen. Misschien heb ik relatief weinig verwezenlijkt, vergeleken met wat

ik verhoopt had bij de aanvang van deze scriptie, maar ik heb de kans gekregen om op

een andere manier iets nieuw bij te leren, en op een andere manier naar veel dingen te

kijken, en onderweg heb ik nog iets opgestoken van het swarm simulatie systeem, hoe

het werkt, waar het kan werken en voor wie het kan werken.

6.2.3 Technisch-filosofisch

De agenten in swarm zijn bij lange na nog geen echte software-agenten. Dat is waar-

schijnlijk waarom het systeem ook beperkt is tot het uitvoeren van simulaties, en niet

bijvoorbeeld een modulaire programmeertaal waar, eens een stuk code in de vorm van

een agent bestaat, het nooit meer opnieuw moet geprogrammeerd worden, of waar bij-

voorbeeld een menubalk een verzameling agenten is die elk voor zichzelf controleren of

Observaties 59

de gebruiker ze wel nodig heeft.

Nee, wat swarm wel is, is een programma dat zich gedraagt als een hoop voorge-

programmeerde agenten. Het verschil is zeer sumier, en ik heb ermee rondgelopen

sinds ik mijn eerste stappen in swarm probeerde te zetten. Het subtiele ligt erin dat

de gebruiker in swarm opdrachten kan geven aan het ganse systeem, aan alle agenten

tegelijk dus, opdrachten als stop, start en deze meer. Bij een totalitair agent gebaseerd

systeem zouden al deze functionaliteiten niet aanwezig zijn, maar verder zou er nog

weinig verschil zijn.

Het subtiele verschil tussen swarm en deze hogere orde van programmeren ligt

volgens mij alleen in het feit dat, zou swarm zo’n summum van kunst willen zijn, het

zich moet verheffen tot besturingssysteem van de machine en alle controle opeisen, en

zich gedragen als een soort van laag tussen de hardware en de agenten. De agenten

zouden dan met alle hardware, bestandstoegangen, schermoutput en zo meer, via deze

laag kunnen communiceren.

6.2.4 Technisch

Bij swarm, zoals bij de meeste van de agentgebaseerde software paddestoelen, staat de

communicatie centraal. De manier van communiceren tussen de verschillende agenten

en tussen de agenten en hun omgeving is het belangrijkst, en werkend in swarm denk

ik dat dit vooral de reden is waarom ooit de keuze gemaakt is om voor object C te

kiezen, en niet Java, C++, Pascal, Fortran, ADA of welke programmeertaal dan ook.

Niet te vergeten echter is er in swarm ook nog een keer de communicatie tussen

het systeem en de agenten. Deze verloopt via het systeem van het opwerken van

verschillende niveau’s van swarms, die dan elk een deel van de organisatie voor zich

nemen en de verschillende tijdsschema’s organiseren.

Een andere observatie is dat er in het programmeren zelf niet veel verschil is tussen

swarm en de andere talen niet veel verschil is: De code zelf moet nog steeds geschreven

worden, en wanneer ik niet goed wakker ben en wat code produceer dan zal het zeker

niet onmiddellijk gecompileerd worden. Een komma op de verkeerde plaats, een index

eentje ernaast, . . . de kleine dingen nemen veel tijd in beslag, en er is wat discipline

nodig om goede code te produceren.

Bovendien is er niet zo veel documentatie beschikbaar dan over pakweg een HTML

pagina maken, en deze die er wel is, is dikwijls voor een nogal technisch publiek

geschreven. Voor mensen die van nul beginnen in swarm kan ik warm alle hulpmiddellen

Enkele laatste bedenkingen 60

van Benedict Stefansson aanraden. Wat een onbehaaglijk gevolg is van deze schaarsste

aan documentatie is dat iets opzoeken veel tijd in beslag neemt. De mailinglist is een

prachtig middel maar alleen beschikbaar voor mensen met internetverbinding.

En een laatste opmerking die in dit onderdeel thuishoort is dat swarm in zijn huidige

vorm alleen een programmeertaal is om simulaties uit te voeren (zie ook H2), het is ook

met deze bedoeling opgericht, en alhoewel er wel al heel complexe simulaties mogelijk

zijn, heb ik bijvoorbeeld nog geen enkele implementatie ontmoet waar dynamische

agenten in bestonden die zichzelf (gedeeltelijk) konden herprogrammeren naargelang

de omgeving. Ik denk dat wat ik hier eigenlijk mee probeer te zeggen is, dat men

swarm in de juiste context moet gebruiken, namelijk als een simulatie systeem.

6.2.5 Opstarttijd

Misschien lag het aan mij, maar ik heb er toch een betrekkelijk lange tijd over gedaan

om vertrouwd te raken met swarm. Ik had het gevoel dat het niet zozeer de Object C

code was die het hem deed, het was meer de andere orientatie van structuren en klasses

was die me in het begin wat verwarde.

Mijn eigen gebrek aan kant-en-klare programmeerkennis weerhield me natuurlijk

ook voor een deel, in onze richtingen wordt meer de nadruk op een wiskundige achter-

grond dan op praktische kennis gelegd, waarmee ik niet wil zeggen dat ik niet kan

programmeren, ik begrijp goed hoe het in elkaar zit, ik heb gewoon nog geen jaren

ervaring ermee.

6.3 Enkele laatste bedenkingen

• Het blijft een computerprogramma: als het op een dubbel zo snelle computer

loopt, zal de simulatie ook dubbel zo snel vooruit gaan. Dit alleen om iedereen

er nog even op te wijzen dat een computerprogramma niet de werkelijkheid is,

en dus ook niet zo mag begrepen worden. Of ook, hoeveel parameters en mooie

modellen je nog in een computer steekt, de glazen bol van madame blanche zal

in de eerste twintig jaar nog steeds niet te kloppen zijn.

• Het swarm simulatie systeem is niet vanzelfsprekend om in te beginnen program-

meren, maar eenmaal vertrokken is het een verbazende taal met voldoende flexi-

biliteit om realistische en complexe modellen mee uit te werken volgens het agent

gebaseerde idee.

Enkele laatste bedenkingen 61

• Wanneer nieuwe simulaties steeds omvangrijker worden, nemen de mogelijkheden

exponentieel toe, het is een denkgebied waar het plafond nog lang niet is bereikt,

maar de problemen zullen er evenredig mee toenemen. Wat ik bijvoorbeeld merkte

is dat de communicatie tussen de verschillende delen van het programma een

nieuw knelpunt zal worden, een probleem dat zich bij klassieke sequentiele pro-

gramma’s zelfs niet voordoet.

• De agent-technologie staat nog in de kinderschoenen en dit is ook nog te merken

aan een heleboel kinderziektes, veel ideeen zijn nog niet ontwikkeld en veel gedacht-

engangen zijn nog niet bewandeld. Hoewel er dus nog hard aan de weg getimmerd

moet en zal worden, is het een aangename, verfrissende manier om probemen te

benaderen, en ik ben ervan overtuigd dat het voor deze techniek maar een kwestie

van tijd is eer ze verspreid wordt en toepassing zal vinden in tal van gebieden.

Bijlage A

Verklarende woordenlijst

“The atmospheric conditions have been

very unfavourable lately,” said Owl.

“The what?”

“It has been raining,” explained Owl.

“Yes,” said Christopher Robin. “It has.”

uit: Winnie the Pooh

• ABM: Agent Based Models, modellen gebaseerd op agent-technologie, zoals

Swarm.

• ABM: Agent Based Modeling, agent-gebaseerd modelleren.

• Activities (in swarm): essentieel ’lijsten’ (lists) van boodschappen die naar

objecten gezonden moeten worden.

• Actors: alle delen die een rol spelen in een simulatie, met inbegrip van alle

agents, (en soms) de wereld(en), en objecten die zich in die wereld(en) bevinden.

Zie ook H1 voor een duidelijkere uitleg.

• Agent: een vaag begrip dat ofwel een fysische eenheid (zoals een computer of

een robot of zelfs een mens) ofwel een logische eenheid met betrekking tot het

domein. Een agent kan ook samengesteld zijn uit een verzameling andere agents.

Zie ook H1 voor een duidelijkere uitleg.

• Autonomiteit: de (bijna altijd) belangrijkste eigenschap die men in een agent

probeert in te bouwen. Zie ook H1.2.

1

2

• Boids: een populaire agent-gebaseerde toepassing, waarbij een zwerm vogels ges-

imuleerd wordt, die, afhankelijk van een klein aantal parameters, andere patronen

aannemen.

• Bug: een populaire benaming voor een agent, afkomstig uit het ecologische

gedachtengoed, waar veel eenvoudige toepassingen hun oorsprong vinden.

• CAS: Complex Adaptieve Systemen, systemen die in staat zijn zich aan te passen

aan een veranderende omgeving, door bvb agent gebaseerde technologieen.

• Cellular Automata: een eenvoudigere vorm van agent-gebaseerde systemen,

waarbij een cel uit de toepassing telkens identiek is aan de andere, en waarbij

naar patronen gezocht wordt. (Bijlage G)

• Conways game of life: een van de eerste computertoepassingen die in het veld

van cellulaire automaten, waarbij een rooster van zich in een binaire toestand

bevindende cellen wisselt van toestand met discrete tijdsstappen. (Bijlage F)

• Echo, SimLife, Sugarscape, Logo, Polyworld, Mirror World, ... : Andere

agent-gebaseerde software/softwarepakketten, de meeste hiervan zijn te vinden

op het internet, van sommige is de broncode ook beschikbaar, sommige spitsen

zich toe op slechts een toepassing, voor meer informatie over deze afzonderlijke

systemen verwijs ik graag door naar het net.

• Emergence: het idee dat “het geheel meer is dan de som van delen” , en dat uit

wat als chaos ontstond, en in tegenstelling tot wat er op het eerste zicht lijkt, er

toch patronen herkenbaar worden, onder alle omstandigheden.

• Factory-Object: een “Swarm” die een collectie van een of andere klasse objecten

beheert, beschouwt die ’beheerde objecten’ als factory-objecten.

• Huwelijkspool: de verzameling mensen die op zoek zijn naar een partner.

• Integrerende Eenvoudige Componenten: een moeilijkere term voor agent,

gebruikelijk in complexere software-systemen, waar de verschillende componenten

als concurrerende eenheden om processortijd en resources worden gezien.

• LispAppArchiever: een ingebouwde precompiler in Swarm die het mogelijk

maakt een reeks van experimenten uit te voeren met verschillende parameters.

3

• MAS: Multi-Agent System : een structuur gegeven door een omgeving, om

samenwerking tussen zichzelf en externe agenten te voorzien. Het betreft een

structuur die meerdere soorten agenten bevat, bvb een simulatiesysteem van een

ecosysteem waar gecommuniceerd wordt tussen het ecosysteem en de omgeving

(verrijkking van de bodem e.d.).

• model: in deze thesis wordt hieronder het schematisch voorbeeld van een werk-

wijze of een systeem begrepen.

• parallellisme: in deze thesis wordt hieronder de mogelijkheid van een comput-

ersysteem om verschillende zaken op hetzelfde tijdstip uit te voeren begrepen.

• probe: een object dat informatie kan verzamelen over een object, en doorgeven

aan een ander object, ook bvb. grafische vensters. Er bestaan in Swarm VarProbes

en MessageProbes. Meer informatie in H3 en [JL00].

• SFI: Santa Fe Institute (New Mexico) (http://www.santafe.edu): de plaats waar

Chris Langton in 1994 het swarm-project gestart is.

• simulaties: de sterkte van swarm ligt in het standaardiseren van simulaties,

nabootsingen van systemen of modellen.

• Swarmapps: een verzameling van duidelijke en veelgebruikte voorbeelden in

swarm in object-c, bevat onder meer een tutorial m.b.v. bugs en de applicaties

heatbugs en mousetraps.

• Swarmpackage: het volledige windows-pakket dat men op de website van

swarm kan afhalen, het is gebaseerd op de cygwin engine aangevuld met de swarm

development tools, zoals object C compilers en hun zelfontwikkelde bibliotheken

ervoor.

• Toplevel Swarm: bij een typische swarm simulatie, wordt er eerst een “toplevel

swarm” gecreerd, die de creatie, het draaien van en de interactie met de rest van

de simulatie dirigeert.

• wereld: de omgeving waarin een simulatie zich afspeelt. Deze kan zowel logisch

of fysisch zijn.

Bijlage B

SDG 2000 Annual Report

When someone says“I want a programming language in which I need

only say what I wish done”, give him a lollipop.

2000 Annual ReportFrom: mgd@swarm.org (Marcus G. Daniels)Subject: First annual report, Swarm Development GroupTo: swarm-announce@santafe.eduDate: 21 Oct 2000 15:57:30 -0700

It has been a year since the Swarm Development Group was spun-out ofthe Santa Fe Institute. It has been anything but boring, and I thinkit is safe to say we have all learned a lot.

Since before the middle of last year, Irene Lee led the charge toestablish the Swarm Development Group as a non-profit corporation.By the time of our formal departure from SFI, this status was secured,the SDG directors board was formed, and we had an agreement with SFIto transfer copyright of the software. By the end of the year, we hadoffice space allocated, and new computer equipment was up and running.

Without taking a breath, Irene went on to organize the firstnon-SFI-supported SwarmFest. Although things looked pretty grim forSwarmFest 2000 for a few days, Irene persevered and in the end themeeting turned out great. Our friends from Utah State were terrifichosts and the content and attendance was more than we had hoped.

To do all this work, Irene burned the candle at both ends. The SDGhad no money to pay her, and eventually she just had to stop for thesake of her sanity. Irene’s departure was a major loss for the

1

2

Swarm Development Group.

As a stop-gap measure, Chris Langton stepped-in as president until wecould find a replacement. In a few weeks, we (the SDG directors)selected Randy Burge to replace Irene. Randy is an expert intech-transfer, working for Lockheed Martin’s Technology VenturesCorporation and Los Alamos National Labs, among others.

Just about the time Randy came on-board, a major anthropology grantChris was awaiting came-through, and with more money than expected.Chris needed to direct all his attention to scientific work. (Chris,in his irrepressible style, is taking his usual first principlesapproach to the task. Construction, deconstruction, tools &techniques, and even science itself all merge into a intermingled, yetseemingly-effortless vibe. It is *really* annoying..eh, I mean, neat!)

Meanwhile, Alex Lancaster and Glen Ropella have continued (andcontinue) to donate their time and money to the Swarm cause.

Alex left SFI this summer to begin study in the Integrative Biologydepartment at Berkeley. Alex remains an active SDG director and helpsto keep our web pages up-to-date.

Since April, Glen, the Vice President of the Swarm Development Group,and my predecessor at SFI, has been working remote for a SiliconValley dot com. Glen shares office space with the SDG, and heperiodically sells his blood to raise money for rent, disk drives, DSLconnections, and the like.

Roger Burkhart, the primary designer of Swarm, continues to provide anunending array of deep design plans. It was a travesty hispresentation at SwarmFest 2000 was not captured on digital media,seeing how many SwarmFest attendees remarked how they would watch itagain and again in a trance of hypnotic fascination. In particular,this observer remains shaken by the reality of watching over hisshoulder as he wrote the slides during presentations earlier that day.

Paul Johnson tirelessly interprets and recodes our (eh, especiallymy), various mutterings for the benefit of the Swarm community atlarge. Paul’s contribution to Swarm and agent-based modeling can’t beoverestimated.

As for me, the only SDG employee, through sheer necessity I’ve takenon the role of executive director of the SDG (even though I’m reallyjust the head geek). Mail your complaints, administrativa and CD-ROM

3

requests to me! More e-mail! More e-mail!

Technical status================

At SwarmFest 2000 in March, Swarm 2.1 was released. Swarm 2.1 was thefirst release developed at the new SDG office in Santa Fe. Thisrelease addressed a number of limitations in the initial Java supportfor Swarm (2.0) that the Swarm user community had identified.

We have since made one maintenance release (2.1.1), which is what wedistribute on CD-ROM. Additional incremental improvements and fixesare available as drop-in DLL upgrades for Windows users atftp://ftp.swarm.org/pub/swarm/binaries/w32/2.1.1-fixes.

Since then, I’ve been keeping my head down and working on new cool stuff.

The road ahead==============

I’ll cut to the chase. Here’s the new cool stuff pending for the next release.

1) Swarm models will be sharable as self-contained documents.

2) Describing the ‘big picture’ for a model will not involve programming.In simple cases, the ‘little picture’ (e.g. ‘step’ methods) will notinvolve programming, either. Read on for details on this.

3) Swarm models can run inside a web browser, specifically Netscape 6.Swarm is already equipped to run JavaScript Swarm models off the web.

4) Swarm models can reference subcomponents via the web.For example, an ObserverSwarm can sit on website A and the ModelSwarmit manages could be on website B. When run, it would all be builtand run inside the users browser.

There are all sorts of potential elaborations on this: one mightbe using popular search engines to pick up compatiblesubcomponents to use. Real-time collaborative work environments areanother possibility.

5) Swarm models can reference subcomponents developed outside of theSwarm community. For example, there is already an geneticalgorithm optimizer module.

4

6) Swarm modelers can move in a low-investment wayfrom Swarm to different scheduling paradigms (and back!)

The killer app--------------These six features put in place what is needed for an interactive,browser-based development environment for agent-based models.

The details of how such an application will look are subject tochange, of course, but imagine a vertically split-screen arrangement of toolpalette adjacent to an iconic canvas workspace.

The palette will have items like Agent, Swarm, Schedule, Action,Grid2d, Canvas. Dragging a Schedule over a Swarm would install theSchedule in the Swarm. Dragging an Action over a Schedule wouldinstall the Action in the Schedule. Dragging an Agent over an Actionwould make the Agent the target of the Action. Clicking on the‘message’ slot in an Action would bring up a script editor.Inappropriate combinations, would be rejected, and so on...

Note that the first release will be usable before the graphicaldevelopment environment is available. This milestone will be usableby itself and it will be easier to learn and use than the currentJava/Objective C development kit.

Background==========

At a conceptual level, the vocabulary for building Swarm models isstraightforward: agent behaviors are Actions and these Actions aredriven by Schedules. An Action is a recipient target (e.g. an agent),combined with some transformation on that target. Agents can combineSchedules to get multifaceted behavior patterns, and they have theoption of modifying Schedules as a simulation runs. Multiple agentscan be run together in a coordinated time and space, a Swarm. Thesethree features (Action, Schedule, and Swarm), make it possible todescribe agents in a modular and precise way. Further, the Swarmsimulator processes these descriptions in such a way that emergentconcurrent Actions are tracked, and thus the system is, in principle,highly scalable.

Agent Actions-------------A way to talk in precise terms about primitive agent actions isneeded. Sometimes agent actions will be non-linear transformations of

5

agent state, and often actions will need to be mechanistic.

As of the last release of Swarm, models must represent Action targets andmessages as Java or Objective C objects and methods on those objects.Although Java is popular, it still takes a fair amount of time tolearn, and is oriented towards implementation, not experimentation,i.e. a single intent mapping to straightforward chunks of code.

Although an implementation language like C++, Java, or Objective C cancertainly satisfy this need for describing the meaning of an Action,in a very real sense these languages are overkill and unwieldy forthe initial stages of the modeling enterprise.

In contrast, scripting languages are designed to be dynamic,incremental, and forgiving.

The next release of Swarm, will support JavaScript and Scheme inaddition to Objective C and Java. This support is actually in thesource tree already, and available to inquisitive users that want tobuild Swarm snapshots from source code.

As with anything, there are tradeoffs. Interactive scriptinglanguages are slow, in general. Being dynamic and forgiving meansthat more stuff has to be checked more of the time. Once a clearhypothesis is formed (e.g. in the scripting environment), there willtypically be a need to scale the system up to see what dynamics occur for alarger population of agents.

In this situation performance becomes a serious consideration -- evento the point that the overhead of the Java virtual machine or theoverhead of dynamic method dispatch is prohibitive in parts of amodel. It is beneficial if Swarm models can be described in a tightlycontrolled environment such as C++.

The fix is in-------------With the next release of Swarm, we’ve targeted a system specificallyintended to solve this problem: COM (http://www.microsoft.com/COM).COM is a technology that facilitates interoperable components, regardless oftheir implementation language. COM has the attribute of being verylightweight and fast for the common case of messages within componentson the same computer.

But don’t get the idea we’re dependent on Microsoft. We’re usingthe Mozilla COM implementation, XPCOM, which is portable across Windows,

6

MacOS, and Unix, and has completely freely redistributable source code.

"Show me the money", you scream! Snapshots and demo code are at:

ftp://ftp.swarm.org/pub/swarm/src/testing/COM

Model Architecture==================

Actions, Schedules, and Swarms look and act like other Javaor Objective C types. To create agents and groups of agents (and thusmodels) means creating and connecting instances of these types usingcode.

With a deliberate effort of abstraction, a modeler can takeminimalistic approach to the implementation of Swarm models in Javaand Objective C, and cut away a lot of the fat. Empirically, a reviewof Swarm models shows a lot of variance in programming idioms fortasks that are in fact identical.

To avoid describing a model’s architecture using raw code, the firsttask is to figure out what all Swarm models have in common, and thento specify a semantics that encompasses the important features of thatcommonality.

There are two parts to this: the first was stated above: a Swarm modelis one that uses Swarm scheduling semantics, i.e. Swarm, Schedule, Action.

The other part is the fact that modelers use Swarm to do things besidesdescribing complex, aggregate behavior patterns. For example, Swarmprovides objects, the means to load and save objects, data structuressuch as lists and maps, probes to inspect these data structures, gridsand rasters to display them, etc. All of this and more is needed bymodelers to create and evaluate their models.

How can we factor out all the constant architectural aspects of aSwarm model but preserve the goal of a having a quick, expressiveexperimental environment?

IMA, the Integrating Modeling Architecture------------------------------------------At SwarmFest 1999, Ferdinando Villa (http://ieee.umces.edu/~villa), ascientist at the Institute for Ecological Economics at the Universityof Maryland presented a paper which proposed a modular descriptionarchitecture for modeling called IMA, the Integrating Modeling

7

Architecture.

Paraphrased, Ferdinando made the observation that modeling requires:

1) one or more paradigms for generating hypotheses

2) specific semantics for describing scenarios subject topredictions of these hypotheses

3) techniques to ground the semantics with validation on real data

4) modular tools to make all this feasible, with the realization thatsome of these tools really need to be designed by domain experts

With regard to the first requirement, Swarm scheduling (as a specialcase of agent-based modeling as a special case of discrete-eventsimulation) is one possible paradigm for hypothesis generation and testing.

With regard to the second requirement, in a sense we have these‘specific semantics’ (Swarm, Schedule, Action). In practice, asmentioned earlier, there is a need for stronger conventions for gluingthe components together.

Where things really get untenable for Swarm is with #3 and #4. Sofar, we’ve addressed this with relatively low-level integrationfeatures like multi-language support, HDF5 object persistence,community programming support, and our minimalistic class librariesfor space representation and some basic built-in analysis tools.

SDG members tell me time and time again how much they want betterspatial representation capabilities, better analysis & visualizationtools, and better data representation techniques for agents.

IMA addresses all these problems. In IMA, model component semantics(in our case, one example is agents) are described in Modules.Primitive Modules are things such as datasets, probes, or scripts eachhaving a specific typing and parameterization. The physicalrepresentation scheme for all IMA components is a tree of linkednodes. In fact, it is the Document Object Model(http://www.w3.org/DOM), a well-known standard for active managementof hierarchical web content.

IMA is described in detail at: http://ima.umces.edu/imt.A SourceForge page is at: http://sourceforge.net/projects/imt

8

So, compared to Swarm model implementation as it is done today, thefirst change with IMA is that ‘the big picture’, is painted using atree of Module nodes. Most of these Modules will have a specificfixed grammar. For example, a user would not be allowed to create aSchedule outside of a Swarm, as they can in, say, Java.

When a Swarm modeler says "I have an ObserverSwarm, which contains aModelSwarm which contains three Agents using ScheduleA thatruns ActionA and ActionB", in IMA it means exactly one set of forms,and only the details of the ActionA and ActionB Modules would (orcould) include any code at all.

This notion of a grammar of module types has the handy attribute thatit is a well-behaved structure which can be manipulated using agraphical model development application, as described earlier.

A corollary is that there will not be obscure toolchain complexity ora compiler involved in model development, except in cases where such‘native’ components are desired for performance.

IMA addresses issues #3 and #4 by being designed for uncoordinatedextensibility. It is easy for third parties to add new Module typesto their modeling environment. In contrast, it is not easy forsomeone to add a feature to the Swarm libraries, since there are somany internal conventions to the Swarm code.

A Swarm IMT module------------------IMT is the engine of the IMA architecture.

A Swarm IMT module is well underway. Swarm now supports COM whichmakes it possible to load the Swarm simulator dynamically from the IMTC++ engine, and for Swarm to call the IMT engine via COM.

The SDG is enhancing the clean IMT prototype to use Mozilla’s DOMinterfaces. This will allow IMT to load model descriptions off theweb, and run them inside Netscape 6. Concurrently, Dr. Villacontinues with foundational work on IMA semantics.

With a Netscape 6 plug-in for IMT working, the SDG will then implementa basic ‘Swarm’ Module grammar for IMT. This will have a simpledesign similiar to the XML prototypes described in previous papers(http://www.santafe.edu/~mgd/anl/hydralink.html#AEN127), except that Actionswill reference IMT Script Modules, not raw precompiled Java code.

9

The Netscape 6 plug-ins for IMT (the basic IMA grammar processor andobject manager), the Swarm IMT plug-in (the Swarm add-in grammarmodule for IMT), and the Swarm plug-in (the existing Swarm engine)will constitute the first milestone, described above.It’s no oversight: flat-out native code, all the way down.

The second milestone will layer on top of the IMT system a graphicaleditor and development environment for IMT/Swarm models. Again, thiscan be tackled in a modular way where the SDG contributes inspectors,editors, etc. specific to Swarm as a plug-in, and gets the rest for free.(And other collaborators on the the IMA effort can do the same, of course!)

Mozilla has good infrastructure in place for this work, and by thetime we get to this point we (the IEE and SDG) should have a clearpicture of Mozilla’s future.

The first milestone should be ready around the first of the year, andthen they’ll need be a period of incremental improvement and astability release. (The first release of Netscape 6 is expected soon,Mozilla 1.0 is expected second quarter of next year.)

This dream’s in sight=====================

Better ways are needed to manage and measure the complexity of agentmodels. The SDG has started on a course that emphasizes collaborationand integration, both with regard to semantics and infrastructure.Concretely, we are directing resources to assist projects that takethe lead to solve the basic representational problems facing everyonein this domain, and especially those projects that havefreely-redistributable infrastructure to show for it.

In the near term, in collaboration with the IMA project, the SDGaims to create a web-based model description and execution facility.This task is in fact nearing completion.

The technique of agent-based modeling has substantial traction, andSwarm has proven itself in this domain. We expect the distributed,multi-level Swarm scheduling interfaces will be a useful contribution tothe IMA framework. The design of IMA is such that we can extend the systemas necessary as SDG member needs dictate.

Pragmatically, there is a clear need for a migration path from theSwarm development kit that is in use today to the next-generationIMA system, and there are clearly a number of SDG members with deep

10

investments in Objective C and Java models. For this reason we’vetaken steps to make the Swarm engine usable in larger modelingframeworks by introducing bridge technologies to COM and Java.In this way, we can afford to investigate new approaches whilemaintaining the existing engine for SDG members with existing investments.

Building on IMA’s flexible infrastructure and semantics, we will thenbegin work on an accessible but flexible model development applicationfor modelers. This work will start immediately after the nextstabilized Swarm release. And of course the more groups that join theSwarm Development Group, the faster this work will move forward!

Marcus DanielsExecutive DirectorSwarm Development Group

---

Why not continue development with the current Swarm analysis, gui,simtoolsgui, and space libraries? The underlying GUI interfaces thatSwarm has are undesirable for general usage. This is because theywere put in place primarily to support the probe panels, analysis andspace capabilities that do exist in Swarm. Basing further work in thespace and analysis libraries on this code is a poor investment sincethis GUI library lacks any real design, and because it is based onObjective C. Such work would be polluted by a problematic foundationand, worse, there is no substantial developer community aroundObjective C. This latter problem also makes further development onthe collections library a questionable enterprise. All in all Swarmneeds to rebuild itself around a modern foundation. This meansleveraging best-of-the-breed components and avoiding from-scratchimplementation whenever possible.

A note on Mozilla: some people believe Mozilla will fail. Somepeople believe that Mozilla is hopelessly bloated, bug-ridden and thatNetscape will die. Putting aside for the moment that these people aremistaken, defeatist, and and deeply misguided, ;-), I should point outthat all the technologies mentioned above are all well-documentedstandards. Microsoft COM is deployed on millions of Windows machines,and DOM (level 1) is a standard Internet Explorer will support sooneror later. So there are alternatives: one is to use scriptable COMcomponents with Internet Explorer. Indeed, these are not zero-energyalternatives, but they are low-energy alternatives.

Bijlage C

De Thesis

There is a little fluffy bunny. ”Cute”, you may say, and you’d be right.

She is sitting outside her burrow on a warm summer evening, scribbling away on a large

folder of paper. Along comes a fox:

Fox: Hello Miss Rabbit.

Bunny: Hmm.

Fox: Excuse me.

Bunny: Hmm.

Fox: What are you doing?

Bunny; (Putting down pen) I’m writing my PhD. thesis.

Fox: How interesting. What is it about?

Bunny: It’s called ”How to eat foxes and wolves”.

Fox: (Laughing aloud (-: ) Ho, ho, ho! What can you know about eating foxes and

wolves, you’re only a little bunny.

Bunny: Come down into my burrow and I’ll show you what I’ve been up to.

The fox agrees, and follows her down through the maze of tunnels into the central

cavern. There are terrible sounds (tearing flesh, cracking bones etc. cf.Python and

the Holy Grail), and the rabbit comes out licking her lips. She picks up her pen and

continues writing...

Along comes a wolf:

Wolf: Excuse me, little bunny.

Bunny: Hmm.1

2

Wolf: Why are you busy writing on such a hot summer night? (cf.Meatloaf, Cadbury’s

Caramel advert U.K)

Bunny: (Putting down pen) I’m writing my PhD. thesis.

Wolf: Really. What is it called?

Bunny: It’s called ”How to eat foxes and wolves”.

Wolf: You can’t be serious! I’ve eaten more rabbits than you’ve had hot dinners :-).

What can you know about eating wolves.

Bunny: Come down into my burrow and I’ll show you.

The wolf agrees, and follows her down through the maze of tunnels into the central

cavern. There are terrible sounds etc. and the rabbit comes out drinking a glass of

Cockburns (”We don’t pronounce the ’C-K’”) port. If you had followed her into the

burrow you would have found a lion.

MORAL: Don’t ask, “What is the thesis about?”.

Ask “Who is your advisor?”.

Bijlage D

De applicatie installeren

Got Mole problems?

Call Avogardo 6.02× 1023

D.1 Swarm installeren

Om swarmapplicaties op een windows-platform te kunnen draaien, moeten de swarm-

bibliotheken op deze geınstalleerd zijn. Dit kan door ofwel het swarm pakket volledig te

installeren, waarbij alle functionaliteiten dan geinstalleerd worden en de programma’s

ook gecompileerd kunnen worden, ofwel door een minimale installatie uit te voeren,

waarbij enkel de nodige bibliotheken voor uitvoering worden gekopieerd, en de appli-

caties dan uitvoerbaar zijn, maar geen verdere functionaliteit aangeboden wordt.

D.1.1 Swarm volledig installeren

Hiervoor is er een uitvoerbaar bestand dat de rest van de installatie voor zich neemt

voorhanden. De laatste versie van dit bestand is beschikbaar via de swarm-site, en

versie 2.2.1, de versie waarin de applicatie die bij deze scriptie hoort is ontwikkeld,

staat ook op de cd-rom.

D.1.2 Minimale installatie

Om niet het volledige pakket, dat nogal groot is, te moeten installeren, volstaat het

enkele dll-bestanden, dit zijn windows-bibliotheken, naar de windows systeemdirectory

te kopieren en enkele directory’s op de juiste plaats te zetten.

1. Kopieer de bestanden BLT24.dll, cytclt80.dll, cygtk80.dll, cygwin1.dll, objc.dll en

swarm.dll naar de c:\windows\system directory.

2. Maak een nieuwe map c:\Swarm-2.1.1\ aan.1

2

3. Kopieer de directory’s blt2.4, tcl8.0 en tk8.0 daarheen.

De nodige bestanden staan ook op de cd-rom.

D.1.3 Swarm onder Linux

Omdat swarm eigenlijk een simulatiesysteem is dat ontwikkeld werd onder unix en

linux, zou het hierop beter moeten lopen dan op een windows-pc. Eenvoudiger echter

in het minst. Om swarm onder linux geınstalleerd te krijgen moeten alle pakketten

afzonderlijk afgehaald en geınstalleerd worden. Door het grote aantal zal ik hier naar

de swarm-website verwijzen, waar een stap-voor-stap gids aanwezig is.

D.2 De applicatie uitvoeren.

Als u de volledige installatie van Swarm heeft uitgevoerd, kan u het programma uitvo-

eren door eerst een swarm-terminal te openen en dan met behulp van Unix-commando’s

naar de gewenste directory gaan en het bestand uit te voeren.

Als u voor een minimale installatie koos, kan u het programma uitvoeren door op

een uitvoerbaar bestand dubbel te klikken.

Als u de volledige installatie heeft uitgevoerd en u de swarm simulaties ook wil

kunnen uitvoeren door dubbelklikken, hoeft u alleen nog de nodige DLL bestanden

naar de windows systeem directory te verplaatsen zoals in het vorige puntje.

Als u dan het programma “swarm.bat” uitvoert, zou u ongeveer hetzelfde moeten

te zien krijgen als in figuur D.1

Van zodra u op “start” of “next” klikt in het juiste venstertje, zullen er nog twee

andere vensters geopend worden, met grafische output, zoals in figuur D.2.

Wat al deze net geopende vensters betekenen of welke functionaliteit ze hebben, en

hoe u deze functies kan veranderen zal ik hierna proberen uit te leggen.

D.2.1 Het controlevenster

Dit venster ziet er uit als in figuur D.3. Er zijn vijf functies aan dit controlevenster

verbonden, en, zoals men kan zien, zijn deze “start”, “stop”, “next”, “save” en “quit”.

De “start”-knop dient om vanop een willekeurig tijdstip waarop de applicatie stil-

staat te laten beginnen of verder gaan met de simulatie. De “stop”-knop doet net het

tegengestelde, namelijk de simulatie op het huidige tijdstip laten stoppen. De simu-

latie wordt hier echter niet mee beeindigd, alleen gestopt. Met de “next”-knop kan

3

de simulatie stapsgewijs vorderen. Telkens er op deze knop geklikt wordt, wordt er

een tijdsstap in de simulatie uitgevoerd. De “save”-knop dient om de positie van de

vensters die deze mogelijkheid aanbieden op te slaan. Deze functie vertoonde bij het

testen echter nog enkele gebreken onder windows NT (crashen), niet onder windows 98

of Me.

De “Quit”-knop tot slot, beeindigt de volledige simulatie en sluit alle swarm-vensters.

D.2.2 De model swarm probe

Dit venster heeft het uiterlijk van figuur D.4. De knopjes en hokjes die u kan on-

derscheiden, zijn respectievelijk zeven “varProbes” en drie “messageProbes”. Dit wil

zeggen dat deze knoppen respectievelijk hokjes een methode respectievelijk variabele

voorstellen uit de interne keuken van de model swarm. Als u op zo’n knopje drukt,

dan wordt de bijhorende methode in de model swam uitgevoerd. De variabelen stellen

bepaalde variabelen voor, maar ze worden enkel geupdated wanneer een van de onder-

staande methodes wordt aanroepen.

Het is ook mogelijk het tijdstip waarop gestopt moet worden te specifieren, met de

“stopoptijdstip” variabele. Let op! Wanneer er een nieuwe waarde bij deze variabele

wordt ingevuld moet er nog eens op enter gedrukt worden, pas dan wordt deze nieuwe

waarde ook effectief geldig.

En dan de methodes. De eerste, ook “dummybutton” genoemd met dat opzicht,

heeft geen functionaliteit in het geheel. Zijn enige nut is dat wanneer hij aanroepen

wordt, de andere variabelen ge-updated worden. De volgende twee “knopjes” dienen om

de stand van zaken uit te brengen. Met swarm.bat komen ze terecht in een tekstbestand

“out.txt”, anders gewoon in de stdout-stream (d.i. meestal gewoon op het scherm).

Wat er juist als resultaat bekomen wordt, is, in tabelvorm, welke huwelijken gevormd

werden, en waar er toegevingen gedaan werden. De knop met “extraInfo” geeft dit

alleen voor de laatste tijdsstap, de “eindInfo”-knop geeft de stand van zaken sinds het

begin van de simulatie. Een voorbeeld van wat er te verwachten valt is weergegeven in

tabel D.1, D.2, D.3 en D.4. De betekenis en het gebruik van de andere varprobes

volgt in een volgende paragraaf.

D.2.3 De observer swarm probe

Zie ook figuur D.5 Deze is eigenlijk van weinig nut, de enige aanwezige variabele die

geprobed wordt, is de displayfrequency, en hoewel het leuke effecten kan geven als deze

4

gewijzigd wordt, van weinig nut. Deze variabele van waarde laten wijzigen heeft als

gevolg dat niet elke stap de data weer naar de grafische probes wordt gestuurd, en

ook het controlevenster wordt dan op mindere tijdstippen geraadpleegd. Mede omdat

deze mogelijkheid er is, is ter controle bij de modelswarm probe een tijdstip ingevoegd,

vertrouw alleen op deze variabele om het aantal afgelegde tijdsstappen af te lezen.

Hier geldt ook dezelfde opmerking als bij de vorige paragraaf: als men de variabele

van waarde wil laten veranderen, mag men niet vergeten na het invullen van een nieuwe

waarde op enter te drukken, zoniet nemen de veranderingen geen effect.

Druk op het kleine rode knopje in de rechterbovenhoek om deze probe te laten

verdwijnen.

D.3 Resultaten uit de applicatie halen

D.3.1 Het bestand “huwbugs.scm”

Dit is een belangrijk onderdeel om resultaten te kunnen verkrijgen, omdat hier bijna

alle parameters ingesteld kunnen worden. Dit kan gewoon geopend worden met een

tekst-editor, zoals notepad (kladblok) of emacs.

Om te beginnen is het belangrijk om de parameter “printout” gelijk te stellen aan

0 als men rechtstreeks met de executable werkt, omdat dit anders de werking van het

programma danig vertraagt, dat een gewone werking niet meer mogelijk is.

De enige variabelen die voor alle groepen bugs tellen zijn de eerste zes, hier volgen

ze met een korte beschrijving:

• stopoptijdstip : het tijdstip waarop de applicatie gestopt moet worden.

• numbugs : het totaal aantal bugs in de simulatie

• printout : 1 als elke bug bij elke belangrijke aktie moet rapporteren

• pogingen : het aantal keer een bug per tijdsstap op zoek gaat naar een partner

• variantie_skill: de variantie die voor het initialiseren de skill wordt gebruikt

• variantie_dummy: de variantie die voor het initialiseren de dummy variabele

wordt gebruikt

De andere variabelen zijn om per etnische groep en geslacht het gemiddelde en het

belang van de verschillende kenmerken weer te geven.

5

D.3.2 Het gebruik van de parameters

Wat belangrijk is om weten, is dat alle bugs dezelfde formules gebruiken om te bepalen

als een andere bug een geschikte huwelijkspartner is. Door de parameters te wijzigen,

interpreteren de bugs andere kandidaten als meer of minder geschikt.

Deze formule staat ook beschreven in hoofdstuk 4:

(randomgetal ∗ belang random getal)+

∑

allekenmerken

belang kenmerk∗ |kenmerk(self)− kenmerk(partner)|

≤ belang totaal

De waarden die in deze formule gebruikt worden voor de kenmerken liggen allemaal

tussen 0 en 100, de “belang-totaal”-parameter moet dus met dit in het achterhoofd

gekozen worden. Als er bij een bepaalde simulatie dus teveel huwelijken voorkomen

tussen bugs van een verschillende etnische groep, kan dat dus gewijzigd worden door

de parameter belang_etnic te verlagen. Als er bijna geen huwelijken zijn, zal waar-

schijnlijk de parameter belang_totaal moeten verhoogd worden.

Merk op dat er volledig volgens de regels wordt gespeeld als de parameter belang_Liefde

(d.i. het belang van de random parameter) gelijk gesteld wordt aan nul.

D.3.3 Het gebruik van de model swarm probemap

Het gebruik van de “varprobes” is redelijk vanzelfsprekend. Telkens wanneer een van

de “messageprobes” aanroepen wordt, wordt de inhoud van de varprobes ververst. De

dummybutton is daar ideaal voor, vooral omdat hij ook geen andere functionaliteit

heeft.

De namen van de variabelen spreken voor zich, maar toch: de eerste twee hebben

te maken met het tijdsverloop, de volgende vier met het hetgeen er in de laatste stap

gebeurd is, en de laatste twee met het totale verloop van de applicatie.

De extraInfo- en eindInfo-knop hebben, wanneer ingedrukt, het gevolg dat infor-

matie over de aangegane huwelijken in tabelvorm, zoals bij tabel D.1, D.2, D.3 en D.4,

in het output-bestand wordt gevoegd. De extraInfo-knop heeft alleen betrekking op de

laatste tijdsstap, terwijl de eindInfo-knop betrekking heeft tot de informatie gedurende

het gehele tijdsverloop.

6

Figuur D.1: Wat men te zien zou moeten krijgen net na het starten van het programma.

Tabel D.1: voorbeeldoutput verhouding geslacht-etniciteitf \m 1 2 3 4 51 914 28 91 44 932 65 403 175 174 193 32 2 220 26 194 25 119 59 204 235 167 20 21 6 252

7

Figuur D.2: Twee nieuwe vensters openen.

Figuur D.3: Het controlevenster.

8

Figuur D.4: De modelswarm Probe.

Figuur D.5: De observerswarm Probe.

Tabel D.2: voorbeeldoutput verhouding geslacht-opleidingsniveauf \m 1 2 3 4 5 6 7 8 9 101 0 0 0 0 0 0 0 0 0 02 0 6 46 53 7 1 6 10 2 03 0 3 55 76 11 2 11 23 2 04 0 1 35 117 62 112 70 29 3 05 0 6 38 159 109 164 261 171 21 36 0 2 29 110 76 92 320 303 50 27 0 0 0 6 6 0 19 39 6 08 0 0 4 8 3 7 59 146 66 09 0 0 2 8 2 2 23 74 53 310 0 0 0 0 0 0 0 2 4 0

9

Tabel D.3: voorbeeldoutput verhouding geslacht-leeftijdsniveauf \m 1 2 3 4 5 6 7 8 9 101 504 406 100 14 18 2 0 0 0 02 399 558 154 28 20 6 0 0 0 03 99 167 156 38 17 8 4 1 0 04 15 28 27 13 23 8 1 6 0 15 12 28 24 16 32 14 1 5 3 06 3 6 12 7 20 18 3 1 3 27 1 3 2 1 9 8 7 3 2 08 0 0 2 0 2 10 6 11 3 59 0 1 0 1 0 2 3 15 6 1310 0 0 0 0 1 4 2 5 13 29

Tabel D.4: voorbeeldoutput verhouding geslacht-dummyf \m 1 2 3 4 5 6 7 8 9 101 0 0 0 0 0 0 0 0 0 02 3 1 3 2 0 0 0 0 0 03 34 5 40 7 0 0 7 2 0 04 96 23 97 26 0 0 28 22 16 245 226 31 94 27 0 0 72 47 6 266 118 14 30 11 0 0 36 22 13 197 13 1 4 0 0 0 10 11 25 248 14 2 18 4 0 0 59 90 159 1139 2 1 10 1 0 0 52 71 51 9210 24 5 25 10 0 0 36 46 115 571

Bijlage E

Uitleg bij de bijgevoegdeCD-Rom

God is a comic playing to an audience that’s afraid to laugh.

Classic

E.1 Listing

\documentatieAllerlei documentatie ivm Swarm & Agentgebaseerd programmeren

\swarm pakettenMateriaal om in swarm te beginnen programmeren

\programmacodeProgrammacode (3 versies)

\swarm minimale installatieNodige bestanden om swarm-applicaties te kunnen uitvoeren

\documentatie\lecturesDocumentatie ivm Swarm in

\documentatie\swarm standaardDe standaard documentatie beschikbaar via de swarm website

\documentatie\webpagina’sInteressante webpagina’s

\documentatie\object cReferentiewerk Objective C

\documentatie\andere systemenHandleidingen van andere agent-gebaseerde systemen

\documentatie\onderzochtte onderwerpenAndere papers betreffende swarm

\swarm paketten\andere voorbeeldenAndere Swarm-applicaties

1

2

E.2 Interessante zaken

Het interessantste op de bijgeleverde CD is waarschijnlijk de documentatie. Vooral

de lectures van Benedict Stefansson de papers over andere onderzochtte onderwerpen

bevatten nuttige informatie. Ook de verschillende webpagina’s bieden een schat aan

informatie. Ik kan maar aanmoedigen om ook vanalles op het net te gaan zoeken,

hoewel het selecteren van informatie via deze weg veel tijd in beslag neemt.

De verschillende webpagina’s staan ook nog eens in een apart zip-bestand op de

cdrom, dit omdat er bij het schrijven van cd’s maar een beperkt aantal tekens in

bestandsnamen kan staan, wat bij sommige pagina’s vreemde bijwerkingen heeft.

Bijlage F

The Game Of Life

Confucius says too much.

Recent Chinese Proverb

In de jaren ’70 ontdekte John Conway zijn “Game of Life”. Het was een van de

eerste structuren waar men complex gedrag kon vaststellen aan de hand van enkele zeer

eenvoudige regeltjes. Tegenwoordig kan men met behulp van bepaalde structuren zelfs

al programmeren aan de hand van model. Het is duidelijk dat dit model een van de

voorlopers was van het agent-gebaseerde idee.

Bijlage G

Cellular Automata

Computers are like Old Testaments gods.

Lots of rules and no mercy.

Anonymous

Bibliography

[App] Brad Appleton. Patterns and software: Essential concepts and terminology.

http://www.enteract.com/ bradapp/. Sober maar compleet overzicht

van patronen en alles wat erbij komt kijken.

[Buc94] Roger Buckhart. Position paper for oopsla 1994 workshop on “the object

engine”. In The Swarm Multi-Agent Simulation System, 9 1994. Redelijk

interessant paper over Swarm als manier van dingen berekenen en

als object motor.

[Dan00] Marcus G. Daniels. Swarm template. Beschikbaar via het SwarmApps pack-

age, 2000. Lege swarm zonder functionaliteit. Handig als men van

nul wil of moet beginnen.

[Daw90] Richard Dawkins. The Selfish Gene. Oxford University Press, 1990.

Fantastische nieuwe kijk op overlevingsmechanismen en de

achterliggende redenen van het zijn.

[DL00a] Marcus G Daniels and Alex Lancaster. Installbook. In Getting Started With

Swarm. Swarm Development Group, 03 2000. Overzicht van de nodige

libraries en configuratie van Swarm. Noodzakelijke maar voor de

hand liggende dingen.

[DL00b] Marcus G Daniels and Alex Lancaster. overbook. In Brief Overview Of

Swarm. Swarm Development Group, 3 2000. Zeer degelijke handleiding

tot swarm, maar alleen bruikbaar als je er al veel van begrijpt.

(niet om mee te beginnen) .

[DL00c] Marcus G Daniels and Alex Lancaster. refbook-2.1.1. In Reference Guide For

Swarm 2.1.1. Swarm Development Group, 3 2000. Moeilijk overzicht van

1

alle mogelijke soorten objecten en bijhorende methodes in Swarm.

Bedoeld als naslagwerk.

[DL00d] Marcus G Daniels and Alex Lancaster. set-2.1.1. In Documentation Set For

Swarm 2.1.1. Swarm Development Group, 3 2000. Voor zover ik kan zien

niet meer dan een samenvoeging van de reference guide en het brief

overview.

[FG96] Stan Franklin and Art Graesser. Is it an agent, or just a program?: A tax-

onomy for autonomous agents. Institute for Intelligent Systems - University

of Memphis, 1996. http://www.msci.memphis.edu/ franklin/AgentProg.html

Interessant theoretisch overzicht van agenten.

[Fon93] Leonard N. Foner. A sociologicak case study. In What’s An Agent, Anyway?

MIT Media Lab, 1 1993. Redelijk interessant paper over Agenten

en hun (mogelijke) interactie met mensen aan de hand van voor-

beelden met “Julia”.

[Fon95] Lenny Foner. What’s an agent? crucial notions. MIT, 1995.

ftp://media.mit.edu/pub/Foner/Papers/Julia/Agents–Julia.ps of online

op http://foner.www.media.mit.edu/people/foner/Julia/ Overzicht van

eigenschappen die agenten kunnen hebben.

[Hol98] John H. Holland. Emergence: From Chaos to Order. Oxford University

Press, 1998. Traag vorderend werk over het ontstaan van patronen

en orde vanuit schijnbare chaos.

[Hoo99] Lindsay Hood. Greenhouse beyond kyoto conference day 2: Tools

for an uncertain world: Agent based modeling. Bureau of Re-

source Sciences, 1999. http://www.affa.gov.au/docs/rural-science/social-

science/kyoto/hood.html Duidelijke pagina over het (mogelijke) nut

van praktische toepassingen van agentgebaseerde technieken.

[JL00] Paul Johnson and Alex Lancaster. Userbook. In Swarm User Guide: A User’s

Guide For The Swarm Simulation System. Swarm Development Group, April

2000. Het werk om met swarm te beginnen. Helaas in het engels en

niet altijd even duidelijk, wel degelijk.

[Joh] Paul Johnson. Swarm on-line faq.

http://lark.cc.ukans.edu/ pauljohn/SwarmFaq/SwarmOnlineFaq.html. The

place To be voor alle mogelijke (beginners-) problemen met Swarm.

Vooral m.b.t. installatie vond ik dit zeer hulpvol.

[Lan00] Alex Lancaster. Simplebug tutorial. Beschikbaar via het SwarmApps pack-

age, 2000. Ongeveer de meest interessante en praktische handleiding

tot het produceren van een eenvoudige swarm, zonder veel bijko-

mende uitleg.

[LW95] Don Larkin and Greg Wilson. Object Oriented Programming And The Objec-

tive C Language. Next Developer’s Library, 1995. Het bijna enige naslag-

werk over Object C. Goed, maar met een te lange inleiding.

[Ren95] Craig Renolds. Boids, background and update.

http://www.red3d.com/cwr/boids/, 4 1995. Interessant overzicht

met veel te veel links waarvan er veel alweer niet werken met

theoretische achtergrond over Boids, een ander idee in de trend

van “emergent” gedrag.

[Ste98] Benedikt Stefansson. Agent based modeling in swarm. In Lectures 1-8, 11

1998. Cursusnota’s behorende bij een cursus swarm aan het UCLA.

Veel voorbeelden zijn moeilijk te vinden en deze slides zijn niet

volledig, maar alles is zeer duidelijk gestructureerd en uitgelegd.

[Ste99] Benedikt Stefansson. Introduction. In Swarmfest ’99 Tutorial, Maart 1999.

Driedelige stand van zaken (1999) van swarm met enkele een-

voudige voorbeeldjes.

[Swa00a] The swarm corporation website. http://www.swarm.com, 10 2000. The

Swarm Corporation. Website van het commercieel bedrijf waar Chris

Langton vandaag werkt.

[Swa00b] The swarm homepage. http://www.swarm.org, 12 2000. The Swarm Devel-

opment Group. Waar elke zoektocht naar interessante voorbeelden

en documenten m.b.t. swarm aanvangt.