Report file

designpadΤεχνίτη Νοημοσύνη και Ρομποτική

1 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

154 εμφανίσεις


1

Wator Simulation


4D4 project

2003


By


Mark Hallinan, Evelyn Hickey, David Hutchinson, Annie Yuk


Abstract

Model and animate a simulation of the Shark/Fish problem, using Cellular
Automata; Make reasonable assumptions wherever necessary; collect useful
statistics.



Contents


Section 1:

Problem Statement







2


Section 2:

Aspects of Modelling







3


Section 3:

Aspects of Simulation







4


Section 4:

Implementation: Functions






5


Section 5:

Implementation: Variables






6


Section 6:

V
ariation of Parameters, Statistics





7


Section 7:

Conclusion








10


Section 8:

Bibliography

& Endnotes






11














2

Section 1


Problem Statement



WATOR is a simulation of the interaction of predator and prey over time in a small
rectang
ular area. It is a simple program originally described by A.K. Dewdney in
Scientific American magazine
1
.


The simulation is dependent upon five parameters; population of sharks and fish,
breeding time of fish and sharks, and starvation of sharks. Each of
the ocean’s cells in the
grid can be either empty or occupied by a shark or fish. The cells change their state
according to certain rules.


The aim of this project is to model and simulate such a system so that the shark and fish
populations are stable ove
r a long period of time.
































3

Section 2


Aspects of Modelling



A deterministic Cellular Algorithm is used to model the problem.


The planet is modelled using a 40 * 40 grid


on screen, as red/blue boxes, partitioned by
gridline
s.


The Neighbourhood system for location on the grid is Moore Neighbourhood.


Fish and Shark are initially distributed randomly and uniformly across the grid.


Fish and Shark can occupy discrete positions on the grid.


When a fish or a shark moves beyond
the grid’s boundary, wraparound boundary is used.


Empty ocean is represented by a ‘0’.


Sharks are represented by any integer between 1 and 5


on the screen, as red boxes.


Fish are represented by any integer greater than 5


on the screen, as blue boxe
s.


At each time interval, fish and shark are allowed move, eat, reproduce or die.























4

Section 3


Aspects of Simulation



Rules governing the behaviour of shark and fish:



1)

movement
:
-

the fish and shark can move in one of 8 directions: n
orth, north
-
west,


west, south
-
west, south, south
-
east, east or north
-
east, provided that the cell is not


occupied by another member of the same species.


If all adjacent cells are occupied, that fish or shark cannot move.



2)

feeding
:
-

If a shark occupie
s a cell adjacent to a fish, it moves into the fish’s cell


and eats the fish.



3)

reproduction
:
-

After a certain number of time units, a fish or shark may breed a


new member of its species, which is placed at random on the grid.



4)

overcrowding
:
-

If a fish
or shark is adjacent to too many of its own species, it


may die from overcrowding.



5)

starvation
:
-

Sharks may die if they do not feed within a certain number of time


units.












5

Section 4


Implementation: Functions



The following were the main f
unctions used in the implementation of Wator
2
:



Functions controlling the on
-
screen grid


Void
Render
( )


used to visualise the ocean grid at each time unit.


Void
Fish
(int, int)/Void
Shark
(int, int)


to draw blue/red boxes which represent
fish/shark.


Void
Gridlines
( )


draws vertical and horizontal lines, to partition the grid.



Functions involving fish and shark population sizes


Void
empty
( )/Void
fill
( )


to initially clear/populate the ocean grid.


Void
CountFishSharks
(int)


to count and displa
y the total fish and shark populations.


Void
drawstats
(int)


draws graph charting populations of fish against shark.


Void
overcrowdfish
( )/Void
overcrowdshark
( )


cause fish/shark to die if they are

overcrowded by members of their own species.


Bool
o
cfish
(int, int)/Bool
ocshark
(int, int)


returns true if the fish/shark at location

(x, y) is overcrowded.



Functions controlling individual behaviour of fish and sharks


Void
ComputeNextMove
( )


controls movement of fish, also allows shark to eat fish.


Void
SharksSearch
( )


allows shark to search adjacent squares for fish and eat fish.


Void
SharksDigest
( )


allows shark to breed, and get ‘hungrier’ if no fish are eaten


if
it gets too hungry, there is a probability it will die.


Void
FishBreed
( )


allows fish to breed, and to get ‘older’.





6

Section 5


Implementation: Variables



The following were the main variables used in the program:



BOXSIZE



the size of each box used to visualise fish and sharks.


NOBOXES



the width/height of the grid.


int
fishpopln
, int
sharkpopln



population size of fish/sharks after n time units.


int
iteration



each time unit equals one iteration of the loop in main( ).


int
fishBeginPop
, int
sharksBeginPop



initial population size of fish/sharks.


int
ocean
[ ][ ]



2 Dimensional array to represent grid of fish and sharks.


int
nextOcean
[ ][ ]


used to compute the state of the grid for next time unit.


int
east
,
south
,
emove
,
smove



used for grid location of fish/shark, and in movement.


int
fishbreedtime
, int
sh
arkbreedtime



controls the number of time units before

fish/sharks are allowed to breed. Fish breed every (
fishbreedtime
) time units. Sharks

breed after (
sharkbreedtime
) time units, provided they are not starving.


int
maxfish
, int
maxshark



controls t
he overcrowding level fish/shark are allowed to

reach before they start to die, i.e. If a fish is surrounded by more than (
maxfish
) fish, it
will die.

















7

Section 6


Variation of Parameters, Statistics


Different initial conditions were tested
, in order to try and find an optimum natural
balance.


It was found that the initial populations of fish/shark were not of major concern


once
the number of iterations went past 100; no matter what the initial populations were set at,
the populations te
nded to ultimately behave in the same way. For this reason, we set the
standard initial populations for fish and shark to be 50 and 35 respectively.


The sharks were originally designed to lose one unit of energy with every time unit
unless they ate a fish
; they began at 2, gained 1 if they ate a fish but lost 1 if they didn’t.
(When sharks reach zero, they are dead). This initial setup caused the sharks to die out
very rapidly, and the fish population consequently exploded.


Sharks were then fitted with a
digestion process whereby, for each time unit, only a
certain proportion of the sharks could ‘digest a fish’, i.e. lose a unit of energy. This meant
that the sharks were able to survive for longer, and so a balance in populations could be
established. To b
e fair, the proportion of sharks that ‘digest’ at each time unit was set to
be 1/8.


At this stage we decided on the terminating condition for the program


that is, to
terminate the program after a satisfactory number of iterations, and calculate the
popu
lation of each species at that stage.


The program was run through 400 iterations, with initial parameters:

fishBeginPop

= 50,
sharksBeginPop

= 35,
fishBreedTime

= 5,
sharksBreedTime

= 5.


The populations behaved like this:

0
100
200
300
400
500
50
100
150
200
250
300
350
400
Fish
Shark

F
igure 1



8

Section 6



There was initially a steep increase in fish, which thrived for around 300 iterations. After
which the fish all died out. This corresponded with a steep increase in sharks, after which
the shark population began to steadily decrease.


Final populations:
Fishpopln

= 0,
Sharkpopln

= 358.


FishBreedTime

and
SharksBreedTime

were varied to try and cope with this.


An increase in
FishBreedTime

did not change the ultimate behaviour of the populations


they behaved similarly to the graph abo
ve. Similarly, any change in
SharkBreedTime

had no major influence on the trends shown in the graph. Only if
FishBreedTime

was
decreased to 2, was there a change


in this case, the fish population exploded,
overcrowding and thus killing the shark populati
on.


In order to maintain a balance in populations, the functions
OvercrowdFish
and
OvercrowdShark

were introduced. If more than (
maxfish
) fish or (
maxshark
) sharks
surrounded a fish or shark respectively, that fish or shark died from overcrowding.


Variou
s values for
maxfish
/
maxshark

were tested. When the values for
maxfish

and
maxshark

were equal, the populations tended to behave as in Figure 1. For values
maxfish

= 5,
maxshark

= 2, the populations behaved as follows:




0
100
200
300
400
500
50
100
150
200
250
300
350
400
Fish
Shark

Fig
ure 2


The populations remained sufficiently stable for both fish and shark to survive beyond
400 iterations (at iteration 400,
fishpopln

= 317,
sharkpopln

= 100).






9

Section 6




The following was decided to be the optimum set of values for our paramet
ers:


Initial Fish Population = 50, Initial Shark Population = 35


FishBreed Time = 5, SharkBreed Time = 5


MaxFish = 5, MaxShark = 2


These values actually allowed both species to survive beyond 2000 iterations, giving final
populations Fish: 227, Shark:
123.



































10

Section 7


Conclusion



We are very satisfied with our program simulation. It works well to allow both
populations to survive beyond 2000 iterations. It incorporates the computer graphics we
learned from last year. W
e have expanded on the basic fish/shark principal to include
overcrowding. Above all we worked as a team throughout the project, dividing the
workload evenly.


In general:


All members were involved in the planning of the project, and everyone contributed
some
work to every aspect of the project; people were always on hand to help with difficulties
and to offer ideas to whoever was working on a task.


This involved planning, implementation, graphics, debugging, statistical analysis, making
changes to the pr
ogramming and the writing of the report.


Contributions:

Evelyn did the visual aspects of program.

Annie did the implementation and the debugging.

Mark made modifications.

Evelyn did more debugging.

Dave varied and tested the parameters and collected stati
stics.

Dave and Mark jointly wrote the report.

Annie put finishing touches to the report and added extra comments.


This involved at least:

3 hours on planning, including some group meetings.

2 hours on graphics.

3
-
4 hours on implementation and debugging.

2 hours modifying code to include ‘overcrowding’ and ‘drawstats’.

1
-
2 hours on more debugging.

2 hours changing parameters and collecting statistics.

3 hours writing the report.

1 hour on finishing touches


Given more time, we could:

1. Introduce more comp
lex breeding methods for the sharks and fish.

2. Try to make the program more user
-
interactive, i.e. allow parameters to be changed
while the program is being run.

3. Introduce a third species in the food chain such as plankton, which the fish eat



11

S
ection 8


Bibliography & Endnotes



[1]

A.K. Dewdney, Scientific American Vol.25 1984, ‘Computer Recreations’.


[2]

The code for the Basic_Canvas and the skeleton code for New_Canvas were taken
from 3D4


canvas class code by Brendan McKeon 1998.


[3]

Ob
jectMentor Inc.


for inspiration.


www.objectmentor.com/resources/fun/wator/index