Added docs
This commit is contained in:
parent
7518e8a293
commit
ec5ddd2edf
|
|
@ -0,0 +1,67 @@
|
|||
Flask
|
||||
SQLAlchemy - MySQL backend
|
||||
|
||||
http://github.com/ruppmatt/AEDeveloper
|
||||
|
||||
Two modes -
|
||||
Local for debug (flask)
|
||||
WSGI Apache Module for deployment
|
||||
|
||||
MySQL for AEDeveloper
|
||||
u/n: aedeveloper
|
||||
p/w:
|
||||
|
||||
|
||||
leviathan.cme.msu.edu
|
||||
|
||||
database is in
|
||||
cd ..
|
||||
cd ..
|
||||
cd /var/www/
|
||||
cd wsgi-scripts
|
||||
cd AEDeveloper
|
||||
ls -l #to see files
|
||||
ls -lah #to see . files
|
||||
|
||||
files need to be owned by Apache
|
||||
so use script
|
||||
cat update.sh #to see script to update from github and have apache own
|
||||
|
||||
cat aedeveloper.wsgi #to see this protocol that apache uses.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
To add a user
|
||||
---------------------------------------------------------------------------
|
||||
To create a user from the command line use
|
||||
sudo ./create_user.sh
|
||||
|
||||
create_user.py [-h] username password fullname email
|
||||
where username and password cannot spaces
|
||||
fullname can be wrapped in quotes and have spaces
|
||||
|
||||
need root access to add a user.
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
Matt uses flask on his machine using start_local.py
|
||||
need to have mysSQL running.
|
||||
|
||||
Cannot have any print statements when deploy
|
||||
|
||||
|
||||
|
||||
To restart Apache
|
||||
sudo apachectl restart #apache control
|
||||
|
||||
|
||||
cat update.sh does a restart tat is slightly different
|
||||
|
||||
sudo service apache2 restart
|
||||
|
||||
|
||||
I found an abstract for some of the work discussed in the article.
|
||||
|
||||
Immunizing Against Prejudice: Effects of Disease Protection on Attitudes Toward Out-Groups
|
||||
By:Huang, JY (Huang, Julie Y.); Sedlovskaya, A (Sedlovskaya, Alexandra); Ackerman, JM (Ackerman, Joshua M.; Bargh, JA (Bargh, John A.)
|
||||
PSYCHOLOGICAL SCIENCE Volume: 22 Issue: 12 Pages: 1550-1556 Dec 2011
|
||||
Contemporary interpersonal biases are partially derived from psychological mechanisms that evolved to protect people against the threat of contagious disease. This behavioral immune system effectively promotes disease avoidance but also results in an overgeneralized prejudice toward people who are not legitimate carriers of disease. In three studies, we tested whether experiences with two modern forms of disease protection (vaccination and hand washing) attenuate the relationship between concerns about disease and prejudice against out-groups. Study 1 demonstrated that when threatened with disease, vaccinated participants exhibited less prejudice toward immigrants than unvaccinated participants did. In Study 2, we found that framing vaccination messages in terms of immunity eliminated the relationship between chronic germ aversion and prejudice. In Study 3, we directly manipulated participants' protection from disease by having some participants wash their hands and found that this intervention significantly influenced participants' perceptions of out-group members. Our research suggests that public-health interventions can benefit society in areas beyond immediate health-related domains by informing novel, modern remedies for prejudice.
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
Goals for 2017 0829
Avida
- Changes
- ./run_tests
- commit & push
then
(automated tests)
Don‰_ªt have
- No method aside from commit msgs describing changes
- no unit tests
Add in code commit lists
or in the readme file?
tagging commits with Av_ED 3.0.2 or what ever
- on both Avida and AV_UI so we know what version of Av_ui goes with which version of Avida Core
AV_UI
- changes
- haphazard tests by Diane by hand
- commit push
- get Jake to test
- fixes
- commit push with tag.
_____________________________________________________________
following JakeÕs readme file on https://github.com/cousi2344/avida-ed-testing/blob/master/README.rst
toward the end ran
<dBlackwood:~/_dev/avida-ed-testing > python tests/test_suite_basic.py --setuipath .
ExperimentControlsTest(BaseTest);
Run the test longer and check to see that nothing bad happened
pytest -v pathtotestfile/testfile.py
all tests are in the test folder. Individual tests are in each of the following folders.
population
organism
analysis
Looking at one test
pytest tests/common/common_basic/navigation/basic_nav_test.py
mac has forward slashes;
mac has back slashes;
another example
pytest tests/population/population_basic/env_settings/pause_update_test.py
changed it to run for 19 instead of 9 updates.
Pull stuff to the av_ui folder within avida-ed-testing
<dBlackwood:~/_dev/avida-ed-testing > . venv/bin/activate
cd tests
_____________________________________________________________
AV_UI change
git clone on server
add in stand alone packages
Test on Server
- automated tests
- tests done by hand
Move Production to Archive (name with version number and date released)
Move test to ‰_Ïapp‰__ folder
- Tag github at this time
_____________________________________________________________
Avida-ED change
pull av_ui changes
push changes
notify diane
tag when in production
‰_Ó‰
wireframe fry
cartoon icons
some parts 2d and some parts 3d
geneartive and proceedural things in games (Robin)
art assests, story, play through a book.
Generative games
Mindcraft
No mans sky
small group of people generate a rich environment.
Spore - not a good game
box car d2 very simple looks crappy.
Fry
- how to swim at all
- evade predators
Swim down stream.
point sources of pollution
Ocean
predators
gather food - grow
Upstream
- fish ladders
- bears
Mating
- finding a mate
- sexual selection
-
Robin
- much easier
- one kind of salmon
- swimming blobs
- keep the same blobs in all the environments
add chemicals
speed of flow
increase the complexity of
Box car 2d - has physics engine
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
Avida-Ed-Testing Notes
|
||||
|
||||
Use once all is installed
|
||||
start virtual environment.
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Python virtual environment.
|
||||
————————————————————————————————————————————————————
|
||||
python --version to get default version which is Python 2.7.10
|
||||
|
||||
which python3 to get the path over version 3 of python
|
||||
|
||||
only do once to set up an virtual environment folder (we called it venv) had to use path
|
||||
in the folder that holds venv type
|
||||
|
||||
virtualenv -p /Library/Frameworks/Python.framework/Versions/3.6/bin/python3 venv
|
||||
Running virtualenv with interpreter /Library/Frameworks/Python.framework/Versions/3.6/bin/python3
|
||||
|
||||
to activate
|
||||
<dBlackwood:~/_dev/avida-ed-testing > source venv/bin/activate
|
||||
|
||||
to get out
|
||||
<dBlackwood:~/_dev/avida-ed-testing > deactivate
|
||||
|
||||
while virtual environment activated use the following command to install local packages.
|
||||
Only need to do once when virtual environment is first set up.
|
||||
<dBlackwood:~/_dev/avida-ed-testing > pip install -r requirements.txt
|
||||
|
||||
pip = python package installer
|
||||
pip freeze lists the packages that are installed.
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Python Virtual Environment 2017 August 25
|
||||
————————————————————————————————————————————————————
|
||||
virtualenv --version to check version of virtual environment.
|
||||
|
||||
docs.python-guide.org/en/latest/dev/virtualenvs
|
||||
a place to get info
|
||||
|
||||
we need to specify which version of python.
|
||||
virtualenv -p /Library/Frameworks/Python.framework/Versions/3.6/bin/python3 venv
|
||||
where venv is the folder for info on the virtual environment.
|
||||
|
||||
pip is the package manager
|
||||
|
||||
pip --help to get help on pip
|
||||
|
||||
pip install -r requirements.txt to load requirements.
|
||||
There may be stuff in the requirements file that we really don’t need.
|
||||
|
||||
————————————————————————————————
|
||||
Actual Testing Notes
|
||||
————————————————————————————————
|
||||
to activate virtual environment
|
||||
<dBlackwood:~/_dev/avida-ed-testing > source venv/bin/activate
|
||||
|
||||
then try
|
||||
python tests/suite.py --setuipath ../av_ui
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
———————————
|
||||
semantic ui as a package to help with Avida-ED 3
|
||||
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
Avida from the command line.
|
||||
|
||||
There are several "main"s in avida.
|
||||
|
||||
source/targets/viewer-text/viewer-text.cc
|
||||
not used that often - put terminal graphics - world as hash marks.
|
||||
|
||||
source/targets/avida/primative.cc
|
||||
typical one that folks use that is where "main" is
|
||||
|
||||
Abstraction level for Avida-ED on the mac between that and the rest of Avida.
|
||||
|
||||
There are half implemented versions of avida that Dave left and did not complete.
|
||||
world object,
|
||||
cworld - old naming convention (c said it was a class)
|
||||
still the main work horse
|
||||
World - (from Dave) new faccet system and the way Avida-ED Mac worked
|
||||
both worlds are needed. circularly dependent. never separated.
|
||||
managers are "facets"
|
||||
|
||||
|
||||
cAvidaConfig* cfg = new cAvidaConfig();
|
||||
- the hard coded version (built in defaults) global config
|
||||
- all of avida.cfg file set up here with default values.
|
||||
|
||||
|
||||
Avida::Util::ProcessCmdLineArgs(argc, argv, cfg, defs);
|
||||
loads command line arguments
|
||||
names of files except avida.cfg are in avida.cfg
|
||||
|
||||
|
||||
Everything was supposed to be facetted.
|
||||
generic programming concept that Dave wanted in Avida, but not fully implemented
|
||||
not sure if it is the same as views.
|
||||
|
||||
Avida::World* new_world = new Avida::World();
|
||||
sets up facetted world
|
||||
|
||||
cWorld* world = cWorld::Initialize(cfg, cString(Apto::FileSystem::GetCWD()), new_world, &feedback, &defs);
|
||||
everything is controlled through cWorld
|
||||
go in and read the config files. (passing in current directory)
|
||||
|
||||
/******** inside cWorld initialize *******/
|
||||
cUserFeedback feedback;
|
||||
used to have a communication cue.
|
||||
effected structure of Json project.
|
||||
looks for messages
|
||||
|
||||
(new Avida2Driver(world, new_world))->Run();
|
||||
runs one update at a time.
|
||||
Avida-ED 3 uses "web" driver.
|
||||
|
||||
in cWorld.cc on line 121 create the world
|
||||
|
||||
if starts with "m" it is a member of the current class (not a local variable) by convention in Avida-ED.
|
||||
|
||||
load on line 128
|
||||
|
||||
In order speed out time ( there is an delta offset)
|
||||
|
||||
|
||||
------------
|
||||
Spatial system and the Global resource system.
|
||||
in the course of an update
|
||||
the deltas will not be applied then "end of an update" when ever someone wants too.
|
||||
|
||||
----------
|
||||
effect of reaction with food does not take place until cell divides.
|
||||
|
||||
|
|
@ -0,0 +1,342 @@
|
|||
Starting at _dev/avida-notebook/AvidaResourceNotebook
|
||||
|
||||
git clone https://github.com/devosoft/avida.git
|
||||
cd avida
|
||||
git checkout AvidaED-Web
|
||||
git submodule init
|
||||
git submodule update
|
||||
|
||||
|
||||
cat .gitmodules
|
||||
to see what was put in .getmodules
|
||||
|
||||
The modules are in the /lib folder
|
||||
|
||||
./build_avida avida-ed #puts in the cbuild/work folder
|
||||
|
||||
more options now.
|
||||
|
||||
Do all the git stuff from the terminal. X-code does not always play nicely with git
|
||||
|
||||
DRIVER
|
||||
|
||||
use a feedback object
|
||||
- user feedback
|
||||
- - error
|
||||
- - info
|
||||
- - warning
|
||||
- - data new for Avida-ED
|
||||
|
||||
are there any messages that need to be sent
|
||||
|
||||
Logic of the asychreous state -
|
||||
-previous grid update (stats that av_ui requests
|
||||
|
||||
- handles messages from av_ui
|
||||
- step update
|
||||
- stuff goes into evens.
|
||||
- still event driven application
|
||||
|
||||
|
||||
webDriverActions.h
|
||||
- writes to feedback rather than to a file.
|
||||
|
||||
Only that can be sent to av_ui
|
||||
come from WebDriverActions.h
|
||||
place to get info from avida to av_ui
|
||||
can read in json and write json
|
||||
|
||||
messaging.h
|
||||
- interface between javascript and avida
|
||||
- untility to grab stuff.
|
||||
|
||||
|
||||
Might also look in applications
|
||||
|
||||
cd apps
|
||||
516 cd viewer-webed
|
||||
518 cd resources
|
||||
|
||||
prepend.js calls avida-messages.js
|
||||
avida-messages.js would contain the que, but I dont’ send messages fast enough for there to be a que
|
||||
|
||||
Debug stuff is in avida-messages.js.
|
||||
the counterpart is WebDebug.h
|
||||
|
||||
macro called debug mode.
|
||||
|
||||
|
||||
|
||||
|
||||
Build Script
|
||||
./build_avida avida-ed (from main avida folder)
|
||||
|
||||
Need C++ 11 or 14 installed.
|
||||
gcc 45 and all of clang handles it
|
||||
|
||||
setting up Empscripten again.
|
||||
|
||||
emsdk_portable.
|
||||
|
||||
emsdk script handles everything
|
||||
|
||||
emsdk update reaches out and grabs the info
|
||||
|
||||
./emsdk list tells what is available and what is installed.
|
||||
|
||||
node js
|
||||
clang
|
||||
need emscripten
|
||||
|
||||
out of tagged releases right now.
|
||||
|
||||
|
||||
./emsdk install (what ever need to pull in) which packages
|
||||
|
||||
emsdk environment.
|
||||
|
||||
put in bash r c file.
|
||||
|
||||
puts in the right environmental files set
|
||||
|
||||
./emsdk_set_env.sh
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Emscripten install notes
|
||||
————————————————————————————————————————————————————
|
||||
./emsdk update
|
||||
|
||||
./emsdk list #to see what is available
|
||||
|
||||
./emsdk install latest to install the latest version
|
||||
|
||||
./emsdk activate latest needed to actually use the stuff
|
||||
|
||||
source ./emsdk_env.sh to set up shell variables
|
||||
|
||||
Then need to edit .profile in the home folder to make sure emscripten is in the path
|
||||
that is put the following line in the .profile file with the correct path
|
||||
source /Users/dianeblackwood/_dev/emscripten/emsdk-portable/emsdk_env.sh
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
To check on the status of cmake do
|
||||
which cmake on the command prompt.
|
||||
————————————————————————————————————————————————————
|
||||
|
||||
Back to compiling Avida. . . .
|
||||
|
||||
At the command prompt in the following folder /Users/dianeblackwood/_dev/avida/
|
||||
First remove the cbuild folder
|
||||
rm -rf cbuild
|
||||
—— note rm -rf * will delete all files/folders on the disk
|
||||
rm - remove
|
||||
-rf recursive forcefully
|
||||
|
||||
./build_avida avida-ed-web is the correct build for the web based branch
|
||||
|
||||
|
||||
To update avida to use the latest version of av_ui
|
||||
./update_avui.sh
|
||||
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
X-Code
|
||||
————————————————————————————————————————————————————
|
||||
use [command][shift]o to search for a file or object anywhere in the project
|
||||
use spy glass on tool bar upper left to find a string
|
||||
|
||||
— to build using xcode
|
||||
Under Applications in the project navigator
|
||||
- click on viewer-webed
|
||||
then in center area look under TARGETS
|
||||
- click on viewer-webed
|
||||
The arguments must be $(ACTION) avida-ed-web
|
||||
|
||||
icons on uppper left (cartoon dialog = report navigator)
|
||||
|
||||
Product menu -> Clean delete the cbuild folder.
|
||||
|
||||
then hit play button (right pointing triangle)
|
||||
————————————————————————————————————————————————————
|
||||
Cmake
|
||||
————————————————————————————————————————————————————
|
||||
cmake --version
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Path
|
||||
————————————————————————————————————————————————————
|
||||
changing files to update the path.
|
||||
env|grep -i path to list the path var
|
||||
export PATH=“${PATH}:/new/path” per session
|
||||
or
|
||||
modify ~/.profile w/ above
|
||||
|
||||
source the file or open new shell
|
||||
|
||||
Change the .profile file in the home directory
|
||||
cd to get to home directory
|
||||
ls -a to display .files
|
||||
|
||||
open a new terminal session
|
||||
or type
|
||||
source .profile to get the new path or any other new stuff in .profile
|
||||
|
||||
echo ${PATH} to see the current path
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Node.js was installed at
|
||||
|
||||
/usr/local/bin/node
|
||||
|
||||
npm was installed at
|
||||
|
||||
/usr/local/bin/npm
|
||||
|
||||
Make sure that /usr/local/bin is in your $PATH.
|
||||
————————————————————————————————————————————————————
|
||||
VIM
|
||||
————————————————————————————————————————————————————
|
||||
vim filename to open vim with a certain file.
|
||||
[esc]i to insert
|
||||
[escape] to leaven insert mode
|
||||
[shift]:wq to have command prompt; write; quit
|
||||
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
command prompt
|
||||
————————————————————————————————————————————————————
|
||||
md5 build_avida to get hash number
|
||||
pwr to get what folder one is in
|
||||
cd to change folder to home or root
|
||||
cat to concatenate files, but just list one then it gives a listing
|
||||
ls to get a folder listing
|
||||
ls -alh listing with all files; long version; human readable file size
|
||||
ls -lh long version;
|
||||
nameOfExecutableFile --version to get a version number
|
||||
which nameOfFile
|
||||
mv move to change the file or folder name.
|
||||
&& to put more than one command on the same line. if one command fails it does not do the next command
|
||||
& to something in background as a batch
|
||||
can use | to redirect stuff to another program
|
||||
3 streams = input stream, output stream and error stream
|
||||
|
||||
ln creates a soft link -s means soft
|
||||
<dBlackwood:~/_dev/avida-ed-testing > ln -s ~/_dev/avida/cbuild/work/ av_ui
|
||||
|
||||
file/dir soft link
|
||||
points to nothing if file deleted.
|
||||
hard link still retains the block. if there are any hard links to a file it still exists, bust with one fewer names
|
||||
soft link does not retain the file if the file is deleted (file exists as long as there is the original name or a hard link
|
||||
The original name is a hard link sort of
|
||||
man ls gives you the manual for ls = man works for many other commands.
|
||||
q to quit out of man
|
||||
less and more work the same way and show you part of a file.
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Error logging 2017 August 25
|
||||
————————————————————————————————————————————————————
|
||||
av_ui (web page)
|
||||
^
|
||||
|
|
||||
v
|
||||
Avida Core (Web worker)
|
||||
^
|
||||
|
|
||||
|
|
||||
v
|
||||
WS_server (python)
|
||||
- /Logger (web page)
|
||||
localhost:5000/logger
|
||||
- /Command
|
||||
localhost:5000/command
|
||||
- /executor (web page) a way to send commands without using av_ui
|
||||
localhost:5000/avida
|
||||
|
||||
/avida on lines between Avida CORE and WS_Server
|
||||
|
||||
and WS_Server and /executor
|
||||
|
||||
AEDBridge (name of the project)
|
||||
- WebSocktes for duplex coms
|
||||
- Needs server provided by flask
|
||||
- python 3
|
||||
|
||||
|
||||
logger displays stuff that is normally disabled in avida.
|
||||
C_ (MODE, STMT, VERBOSITY)
|
||||
displays on a webpage.
|
||||
|
||||
————
|
||||
To enable
|
||||
- modify WebDebug.h
|
||||
to turn on debug statements
|
||||
- modify messages.js
|
||||
to enable websocket
|
||||
|
||||
————
|
||||
Redis is the name of the database all stored in memory that the WS_SERVER uses.
|
||||
|
||||
|
||||
|
||||
This is all in a python virtual environment.
|
||||
|
||||
|
||||
———————
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Redis 2017 August 25
|
||||
————————————————————————————————————————————————————
|
||||
|
||||
./redis-server --port 5060
|
||||
|
||||
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————————————————
|
||||
Git help for Github
|
||||
————————————————————————————————————————————————————————————————————————————————————————————————————————
|
||||
git checkout build_avida to revert back version on website.
|
||||
https://chris.beams.io/posts/git-commit/
|
||||
|
||||
git reset --hard to get rid of changes made to local folder
|
||||
|
||||
|
||||
|
||||
git submodule init && git submodule update
|
||||
|
||||
git checkout AvidaED-Web puts me in the AvidaED-web branch
|
||||
|
||||
https://chris.beams.io/posts/git-commit/
|
||||
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————————————————
|
||||
Changing how we calculate averages for population stats 2017 August 25
|
||||
————————————————————————————————————————————————————————————————————————————————————————————————————————
|
||||
#In the root directory
|
||||
./update_avui.sh gets latest av_ui from git hub an stages them to go in the next update
|
||||
|
||||
#Then build
|
||||
|
||||
#When tested add the changes and commit
|
||||
git add apps/viewer-webed/src/WebDriverActions.h
|
||||
git add cbuild/bin/*
|
||||
git commit #Add comments in editor when it pops up and exit
|
||||
git commit -m “ the comments “
|
||||
git push
|
||||
#Email Diane
|
||||
|
||||
|
||||
Matt uses Dr. Gein for a dentist - in his 70s and is semi-retired
|
||||
Yancy Tygesen on Jolly Road Okemos oral surgeon
|
||||
|
||||
|
||||
————
|
||||
|
||||
Avida building avida cleanly
Commit change in Avida
- Clean builds
- - Remove cbuild folder
- - - rm –rf cbuild
or
|
||||
./build_avida clean
|
||||
- - now actually build avida for regular C
./build_avida
|
||||
|
||||
- - now build avida for avida-ed-web (emscripten)
|
||||
./build_avida clean && ./build_avida avida-ed-web
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
Starting at _dev/avida-notebook/AvidaResourceNotebook
|
||||
|
||||
git clone https://github.com/ruppmatt/AvidaResourceNotebook.git
|
||||
|
||||
cd AvidaResourceNotebook && git clone https://github.com/devosoft/avida && cd avida && ./build_avida && cd .. && virtualenv -p `which python3` venv && . venv/bin/activate && pip install -r requirements.txt && ln -s ../avida/cbuild/work/avida default_config/avida && cd default_config && ./avida && cd ..
|
||||
|
||||
in ~/_dev/avida-notebook/avidaResourceNotebook
|
||||
git submodule init && git submodule update
|
||||
-------
|
||||
|
||||
or all at once
|
||||
git clone https://github.com/ruppmatt/AvidaResourceNotebook && cd AvidaResourceNotebook && git clone https://github.com/devosoft/avida && cd avida && ./build_avida && cd .. && virtualenv -p `which python3` venv && . venv/bin/activate && pip install -r requirements.txt && ln -s ../avida/cbuild/work/avida default_config/avida && cd default_config && ./avida && cd ..
|
||||
then in ~/_dev/avida-notebook/avidaResourceNotebook
|
||||
~/_dev/avida-notebook/avidaResourceNotebook
|
||||
|
||||
|
||||
At that point you can launch the notebook by:
|
||||
jupyter notebook
|
||||
|
||||
--------------------------------
|
||||
git clone https://github.com/devosoft/avida.git
|
||||
cd avida
|
||||
git checkout AvidaED-Web
|
||||
git submodule init
|
||||
git submodule update
|
||||
|
||||
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
VIM
|
||||
————————————————————————————————————————————————————
|
||||
vim filename to open vim with a certain file.
|
||||
[esc]i to insert
|
||||
[escape] to leaven insert mode
|
||||
[shift]:wq to have command prompt; write; quit
|
||||
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
command prompt
|
||||
————————————————————————————————————————————————————
|
||||
md5 build_avida to get hash number
|
||||
pwr to get what folder one is in
|
||||
cd to change folder to home or root
|
||||
cat to concatenate files, but just list one then it gives a listing
|
||||
ls to get a folder listing
|
||||
ls -alh listing with all files; long version; human readable file size
|
||||
ls -lh long version; including where a soft link goes
|
||||
nameOfExecutableFile --version to get a version number
|
||||
which nameOfFile
|
||||
mv move to change the file or folder name.
|
||||
&& to put more than one command on the same line. if one command fails it does not do the next command
|
||||
& to something in background as a batch
|
||||
can use | to redirect stuff to another program
|
||||
3 streams = input stream, output stream and error stream
|
||||
|
||||
ln creates a soft link -s means soft
|
||||
<dBlackwood:~/_dev/avida-ed-testing > ln -s ~/_dev/avida/cbuild/work/ av_ui
|
||||
|
||||
file/dir soft link
|
||||
points to nothing if file deleted.
|
||||
hard link still retains the block. if there are any hard links to a file it still exists, bust with one fewer names
|
||||
soft link does not retain the file if the file is deleted (file exists as long as there is the original name or a hard link
|
||||
The original name is a hard link sort of
|
||||
man ls gives you the manual for ls = man works for many other commands.
|
||||
q to quit out of man
|
||||
less and more work the same way and show you part of a file.
|
||||
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Off Topic
|
||||
————————————————————————————————————————————————————
|
||||
|
||||
————————————————————————————————————————————————————
|
||||
Genetics
|
||||
————————————————————————————————————————————————————
|
||||
|
||||
Greta Kaplan I've never seen this dog: If I've read the thread right the dog is reported to be Bb KyKy ataw EmE DD.
|
||||
|
||||
Bb - the base color is black rather than liver and should have black nose, toe pads and nails unless there is white spotting of some form which is not included above. Greta's description as black tricolor - indicates she is a black and tan with white which is consistent with B-kykyat-E-D-.
|
||||
|
||||
KyKy - allows expression at the A loci and is NOT brindle.
|
||||
|
||||
At indicates tan points. The Aw indicates wild type. Generally in the Agouti series Ay > Aw > at > a
|
||||
If the dog looks like a blacktri, then I'd question the aw, typically a black-tri would be atat or ata
|
||||
|
||||
Em - indicates a mask, E is just normal extension = dog can produce both types of pigment
|
||||
there is a lot of variation in masks
|
||||
|
||||
DD - no dilution
|
||||
|
||||
|
|
@ -0,0 +1,215 @@
|
|||
This worked for me to set up Matt's ResouceNotebook. I did have python already installed.
|
||||
|
||||
Quickest start:
|
||||
|
||||
Go to the directory where you'd like to install the repository. Make sure that there is not already a directory called AvidaResourceNotebook present. Then paste and run this in the terminal:
|
||||
|
||||
git clone https://github.com/ruppmatt/AvidaResourceNotebook && cd AvidaResourceNotebook && git clone https://github.com/devosoft/avida && cd avida && ./build_avida && cd .. && virtualenv -p `which python3` venv && . venv/bin/activate && pip install -r requirements.txt && ln -s ../avida/cbuild/work/avida default_config/avida && cd default_config && ./avida && cd ..
|
||||
|
||||
At that point you can launch the notebook by:
|
||||
|
||||
jupyter notebook
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
Avida resources animations
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
To build avida go to avida-projects/avida and run
|
||||
./build_avida
|
||||
|
||||
|
||||
|
||||
folder structure for this project
|
||||
avida-projects/
|
||||
resources/
|
||||
avida/ soft link to avida under work in avida folder below
|
||||
venv/
|
||||
avida/
|
||||
cbuiid/
|
||||
work/
|
||||
avida
|
||||
*.cfg
|
||||
*.org
|
||||
|
||||
to set up softlink go to the resources/avida folder
|
||||
|
||||
ln -s ../../avida/cbuild/work/avida .
|
||||
cp ../../avida/cbuild/work/*.cfg .
|
||||
cp ../../avida/cbuild/work/default-heads.org .
|
||||
|
||||
|
||||
——————————————————————————
|
||||
Files: in general
|
||||
——————————————————————————
|
||||
analyze.cfg - for analyze mode (avdia -a) can be blank, but needs to exist
|
||||
utility to analyze after the fact. can be blank, but must exist.
|
||||
avida.cfg - global configuration
|
||||
environment.cfg
|
||||
eventts.cfg
|
||||
instset-heads.cfg - instruction set list
|
||||
default-head.org default ancestor
|
||||
|
||||
not using the following so we removed them
|
||||
>rm instset-heads-sex.cfg instset-transsmt.cfg
|
||||
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
Getting Jupyter on Computer
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
I’m putting this in a folder called avida-projects
|
||||
Create virtual environment by going to the folder where the virtual environment will be crated and running:
|
||||
>virtualenv -p /Library/Frameworks/Python.framework/Versions/3.6/bin/python3 venv
|
||||
|
||||
Then activate the virtual environment
|
||||
>source venv/bin/activate
|
||||
|
||||
path for python3 might be different on a different computer.
|
||||
|
||||
Matt then supplied requirements.txt file that goes in the avida-stuff folder
|
||||
|
||||
So then in the same folder run
|
||||
>pip install -r requirements.txt
|
||||
|
||||
Matt also provided Animate Spatial Resources.ipynb
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
to run jupyter python notebook
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
|
||||
activate the virtual environment if that has not been done already
|
||||
>source venv/bin/activate
|
||||
|
||||
python -m jupyter notebook
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
In the Notebook
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
TO run: In the Cells dropdown menu, Click “Run Cells”
|
||||
or <control><enter> to run the cell that one is currently in
|
||||
|
||||
In [ ] beside the cell gives some status information
|
||||
empty = never executed
|
||||
[#] what order it was executed (such as [1]
|
||||
[*} executing or about to be executed
|
||||
|
||||
|
||||
To start clean use the Kernel menu
|
||||
python is single threaded
|
||||
- interupt will stop the kernel (stop running)
|
||||
-
|
||||
|
||||
——————————————————————————
|
||||
Command Mode:
|
||||
——————————————————————————
|
||||
When the vertical line on the left is blue, it is in command mode
|
||||
h: gives some command listings
|
||||
<esc> got me into command mode
|
||||
|
||||
|
||||
——————————————————————————
|
||||
Typing Mode
|
||||
——————————————————————————
|
||||
The vertical line on the left is green
|
||||
clicking in the cell put it in this mode.
|
||||
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
Test to see that avida runs
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
go to avida-projects/resources/avida
|
||||
>./avida
|
||||
|
||||
to clear the data folder (output created when running avida)
|
||||
>rm -rf data
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
First Experiment with one non-reproducing organism and let resources flow
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
|
||||
Files
|
||||
analyze.cfg - for analyze mode (avdia -a) can be blank, but needs to exist
|
||||
avida.cfg -
|
||||
disable mutations
|
||||
disable death
|
||||
|
||||
environment.cfg
|
||||
|
||||
eventts.cfg
|
||||
only inject
|
||||
printSpatial Resources
|
||||
Exit
|
||||
|
||||
instset-heads.cfg - (add nop-x to end)
|
||||
|
||||
default-head.org default ancestor
|
||||
replace
|
||||
h-divide w/ nop-x
|
||||
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
vim notes
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
vim cheatsheet on line to find more help on vim
|
||||
|
||||
vim filename
|
||||
|
||||
<esc> put in command mode
|
||||
|
||||
in commmand mode
|
||||
G - puts at end of file
|
||||
gg - goes to the top
|
||||
o - opens an new line below and goes into insert mode
|
||||
O - opens a new line above the current line and goes into insert mode
|
||||
i - goes into insert mode
|
||||
:wq - write quit the colon is important
|
||||
R - replace mode
|
||||
0 - go to the start of the line
|
||||
$ - go to the end of the line
|
||||
/ - begin search process
|
||||
:nohls to get rid of highlighting from search
|
||||
:19 jumps to line 19 for example
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
|
||||
https://docs.google.com/spreadsheets/d/1ZS9OT1Om0PYd_ePamXXgr1MhGPrC7ZcvP-7rUCqq7Gs/edit#gid=0
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
|
||||
Asking Students about Nature of Science
|
||||
“Science and the Citezin”
|
||||
Nature and Process of Science”
|
||||
General Education at the college level - Utah State regional campus (20 students)
|
||||
Mike will interview over Zoom in December
|
||||
|
||||
how does this fit into experimental design.
|
||||
Nature and Practice of Science.
|
||||
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
git reset --hard to revert back to last clone commit or pull or clone
|
||||
git reset --hard origin/master to pull to latest and erase local changes.
|
||||
origin is the name of the remote (git hub) branch
|
||||
|
||||
start virtual environment
|
||||
. venv/bin/activate
|
||||
|
||||
————————————————————————————————————————————————————————————————————————————————————————————
|
||||
Info about how the python notebook works.
|
||||
|
||||
Currently developing on avidares
|
||||
this is a package because it has a file called __init__.py
|
||||
not full, because there is no setup.py file that would let .pip install it (part of the Easy_setup)
|
||||
|
||||
avidares.SingleExperiment is getting SingleExperiment is module (file) withing the package avidares
|
||||
|
||||
classes in SingleExperiment that mostly use
|
||||
ResourceExperiment.
|
||||
ResourceExperimentAnimation
|
||||
|
||||
|
||||
classes in FactoredExperiment that mostly use
|
||||
ResourceFactoredExperiment
|
||||
ResourceFactoredExperimentIterator
|
||||
ResourceFactoredExperimentAnimation
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
2017 Aug 16
|
||||
onstructor
|
||||
Copy constructor
|
||||
assignment onstructor (=)
|
||||
destructor
|
||||
———————
|
||||
|
||||
Implementing an Action
|
||||
- - write constructor
|
||||
- - implement GetDescription (. . .)
|
||||
- - implement Process (. . .)
|
||||
- - if needed destructor
|
||||
|
||||
|
||||
in avida cfg file
|
||||
|
||||
u 0 [_____________}
|
||||
0 is an update number
|
||||
[__________] is the name of a cAction
|
||||
|
||||
u start:interval:end [_______] [args]
|
||||
|
||||
args = usually copied to a new string typically called Largs in constructor)
|
||||
called m_args internally (class member internal to that class)
|
||||
|
||||
class member by convention indicated by m_
|
||||
|
||||
|
||||
———
|
||||
|
||||
for web interface we have cWebAction
|
||||
|
||||
cAction (virtual)
|
||||
|
|
||||
v
|
||||
cWebAction (virtual)
|
||||
|
|
||||
v
|
||||
cWebActionSomething (implemented) where something is the name.
|
||||
|
||||
|
||||
allows us to use
|
||||
- json args
|
||||
- feedback option for data
|
||||
- packaging data utility
|
||||
|
||||
———————————
|
||||
Organism
|
||||
<— phnotype
|
||||
<- genotype
|
||||
<- hardware
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,248 @@
|
|||
Experiments script
|
||||
environment
|
||||
populations
|
||||
one or more
|
||||
individual organisms (rovers)
|
||||
build method on rovers
|
||||
using factories (reflection with factory rather than actual thing)
|
||||
|
||||
|
||||
Robin
|
||||
|
||||
When start play
|
||||
|
||||
2 phases (set up and Loop)
|
||||
|
||||
Setup
|
||||
|
||||
Loop of following to blocks
|
||||
Start Generation
|
||||
running phase
|
||||
replicate phase
|
||||
|
||||
When press play
|
||||
deserializing
|
||||
calling a bunch of factories
|
||||
makes some game objects
|
||||
|
||||
Life Cycle of an organism
|
||||
- Spawn
|
||||
- build
|
||||
- running (not the update functions)
|
||||
running is called in the experiment's update function
|
||||
control to not skip frames
|
||||
|
||||
Structure of mono 0 behaviors
|
||||
|
||||
Game Object (location in the world)
|
||||
can have stuff attached.
|
||||
mono-behaviors attached.
|
||||
(code to excute)
|
||||
|
||||
|
||||
Mono-behavior is a class
|
||||
with virtual methods
|
||||
called by unity engine in an opaque way.
|
||||
don't worry about how.
|
||||
wake ( called unconditionally) called as soon as estangiaged.
|
||||
start (only after exists in the world)
|
||||
enabled and disabled
|
||||
update function (called kind of like every frame but not locked to physics engine)
|
||||
|
||||
Fixed updated to the physics engine, but not fixed to the update rates
|
||||
rendering is expensive -
|
||||
physics is often faster than the rendering
|
||||
rendering pushing to gpu one bit at a time (not in parallel)
|
||||
Unity obscures stuff.
|
||||
appear to running in a single thread (but not really)
|
||||
|
||||
Multiple event listeners
|
||||
|
||||
void Awake() {
|
||||
this.enable=clase;
|
||||
}
|
||||
|
||||
spawning is expensive.
|
||||
- avoid spawning when possible.
|
||||
try not to spawn new things
|
||||
|
||||
Expensive to create new object; cheap to change object.
|
||||
so reuse object rather than kill and spawn again
|
||||
|
||||
|
||||
Running will not happen before building is done
|
||||
|
||||
bodies will be spawned, but the controller will not be spawned.
|
||||
|
||||
|
||||
for x in org.Build() {
|
||||
yield return x;
|
||||
}
|
||||
add org to running list
|
||||
(keeps running till it dies)
|
||||
|
||||
synchronous - all born and die as a group.
|
||||
selective pressure to be constructed faster if the don't specifically wait for slow builders before running the group.
|
||||
|
||||
Need to know when an organism wants to replicate.
|
||||
|
||||
Jake left so beginner
|
||||
|
||||
Game Objects
|
||||
- core thing
|
||||
does not do anything. does not even have a position
|
||||
- can have multiple components attched to it.
|
||||
each one is a C# class
|
||||
access the components with a api
|
||||
All of the objects get a transform objects
|
||||
model view mattricies (positional spatial information)
|
||||
|
||||
|
||||
|
||||
Quaternions - a generization of complex numbers
|
||||
complex number = real + complex * i
|
||||
a1 + a2*i + a3*j + a4*k where (1, 2, 3 are subscripts and i, j, k are vectors)
|
||||
can be restricted to a subset with magnitudes of 1
|
||||
Eular coorinates can have gimble lock.
|
||||
|
||||
meshes and physics objects.
|
||||
change looks or physics behavior or mono-behaviors.
|
||||
|
||||
Exercise to make a simple game in unity
|
||||
drive ball around in push things and events trigger when it hits things.
|
||||
|
||||
re-implement the rovers. Make changes to rovers.
|
||||
re-do the make command and have it pop up in the user interface.
|
||||
|
||||
do some live coding of implementing something.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2017_1208 Charles Meeting
|
||||
|
||||
Three parts of contribution to paper
|
||||
1. Intellecturally
|
||||
|
||||
2. data generation (including statistics)
|
||||
|
||||
3. writing/editing
|
||||
|
||||
|
||||
Author - made the paper happen as opposed to not happen.
|
||||
making it rise to higher level quality.
|
||||
|
||||
|
||||
Literature Review - conceptual
|
||||
|
||||
|
||||
Seeds should be different.
|
||||
|
||||
every treatment should have unique seed.
|
||||
|
||||
Avida (0= random number based on time)
|
||||
another number - random number base on that seed.
|
||||
|
||||
Josh example
|
||||
Compare high mutation rate to low mutation rate
|
||||
should be completely different.
|
||||
|
||||
If doing paired runs, perhaps.
|
||||
|
||||
if you want same initial conditions go out of way to make sure that is true. Don't assume that using the same random seed will do that for you.
|
||||
|
||||
Reusing seeds from one treatment to another should not mater.
|
||||
|
||||
Leslie Moore never re-used the same seed from experiment to the next.
|
||||
|
||||
Paired runs with paired statistics.
|
||||
If use the same seed - do intentionally and know what you are doing.
|
||||
|
||||
|
||||
# 9 Proffesor asked to review a paper that they know from seeing at conference, but not otherwise. Concerned about ideas effecting their own research. implied belief that ideas will not be stolen by the reviewer. Is it wrong to have a head start.
|
||||
People worried about being scooped.
|
||||
|
||||
|
||||
Data Matching
|
||||
Rodan -
|
||||
|
||||
|
||||
python library to access git history.
|
||||
|
||||
troll git histories when doing search .
|
||||
|
||||
Rose (used evernote for a while)
|
||||
Noodle - lab notebook.
|
||||
Rose wrote Noodle (CK editor) saves to html files
|
||||
python script with flask (attaches to port 5000
|
||||
search is grep based.
|
||||
|
||||
Scientific keeping in journals.
|
||||
- personal notes and commenatary separate.
|
||||
- win a nobel prize - notebook published
|
||||
- if random personal shit in notebook needs to be stated as such.
|
||||
|
||||
- helps keep things in context to note some stuff read
|
||||
- don't put patentable on web unless you want to prevent someone else from patententable. Who ever files first unless it has been made public. Special paper notebooks
|
||||
|
||||
Evernote had good handwriting recognition - can
|
||||
silver note (only for PCs)
|
||||
|
||||
Experimental treatment description
|
||||
discussion of what
|
||||
|
||||
|
||||
Struture in Log form and search for projects.
|
||||
|
||||
|
||||
Links in log to notebooks.
|
||||
|
||||
iPython notebook.
|
||||
Discussion in Noodle.
|
||||
|
||||
Tagging is a big thing.
|
||||
|
||||
When does one save full data and when can you just save the configuration to generate the data.
|
||||
|
||||
Published paper. Lots of fitness data throughout the data. all average in the paper.
|
||||
|
||||
|
||||
Python Library called bump version major or minor push tags to git hub.
|
||||
|
||||
|
||||
Not sure what version that you have done a run on .
|
||||
|
||||
|
||||
Do a final data run after all stat exploration, ideas, etc done.
|
||||
|
||||
|
||||
Time for lab meeting for next semester. Push to slack.
|
||||
----------
|
||||
|
||||
University Lawyer.
|
||||
solisitation of copywrited material
|
||||
doing wrong stuff, vs. knowingly knowling doing wrong stuff.
|
||||
|
||||
People to inform students of what is allowed and what is not allowed. Will talk to legal stuff at other big 10 conference.
|
||||
Send a notice that the majority of their stuff is copywrited.
|
||||
|
||||
other proposed solutions
|
||||
- Chad is used for cheating
|
||||
- Provost looking into what can be done to students for posting course content to Chag??? 2000 level students caught cheating
|
||||
- plagerism is not technically against the law?
|
||||
|
||||
- normal accounts cannot post solutions.
|
||||
- posting questions and using the answers
|
||||
- solutions posted for low level courses are reasonable.
|
||||
|
||||
Looking new omnibussman at MSU
|
||||
|
||||
following Monday a week Party for Rose.
|
||||
No lab meeting next year.
|
||||
|
||||
Bliss Salon and Jamie Fenriss
|
||||
near Myer on Saginaw west side near 69/96
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
|
|
@ -0,0 +1,10 @@
|
|||
On Texas Server
|
||||
|
||||
degas2.fdisk.net
|
||||
/var/www/vhosts/avidaed/public_html/app
|
||||
get password from Wesley or Marc
|
||||
|
||||
On MSU server
|
||||
Pulse Secure must be running if off campus
|
||||
leviathan.cme.msu.edu
|
||||
/var/www/avida-ed.beacon-center.org/app
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
When studying biological evolution, we have to overcome a large obstacle: Evolution is extremely slow. Traditionally, evolutionary biology has therefore been a field dominated by observation and theory, even though some regard the domestication of plants and animals as early, unwitting evolution experiments. Realistically, we can carry out controlled evolution experiments only with organisms that have very short generation times, so that populations can undergo hundreds of generations within a time frame of months or years. With the advances in microbiology, such experiments in evolution have become feasible with bacteria and viruses [ElenaLenski2003, TravisanoRainey2000]. However, even with microorganisms, evolution experiments still take a lot of time to complete and are often cumbersome. In particular, some data can be difficult or impossible to obtain, and it is often impractical to carry out enough replicas for high statistical accuracy.
|
||||
|
||||
According to Daniel Dennett, "...evolution will occur whenever and wherever three conditions are met: replication, variation (mutation), and differential fitness (competition)"[Dennett2002]. It seems to be an obvious idea to set up these conditions in a computer, and to study evolution ''in silico'' rather than ''in vitro''. In a computer, it is easy to measure any quantity of interest with arbitrary precision, and the time it takes to propagate organisms for several hundred generations is only limited by the processing power available. In fact, population geneticists have long been carrying out computer simulations of evolving loci, in order to test or augment their mathematical theories (see [HartlClark2006, KimStephan2003, McVeanCharlesworth2000, Nowak2006, Orr2000] for some examples). However, the assumptions put into these simulations typically mirror exactly the assumptions of the analytical calculations. Therefore, the simulations can be used only to test whether the analytic calculations are error-free, or whether stochastic effects cause a system to deviate from its deterministic description, but they cannot test the model assumptions on a more basic level.
|
||||
|
||||
An approach to studying evolution that lies somewhere in between evolution experiments with biochemical organisms and standard Monte-Carlo simulations is the study of self-replicating and evolving computer programs (digital organisms). These digital organisms can be quite complex and interact in a multitude of different ways with their environment or each other, so that their study is not a simulation of a particular evolutionary theory but becomes an experimental study in its own right. In recent years, research with digital organisms has grown substantially ([AdamiOfriaCollier2000, ComasMoyaGonzalez-Candelas2005, Egri-NagyNehaniv2003, GerleeLundh2005, LenskiOfriaPennock2003, MisevicOfriaLenski2006, WilkeWangOfria2001, YedidBell2001, YedidBell2002, ZhangTravisano2007], see [Adami2006, WilkeAdami2002] for reviews), and is being increasingly accepted by evolutionary biologists [ONeill2003]. (However, as Barton and Zuidema [BartonZuidema2003] note, general acceptance will ultimately hinge on whether artificial life researchers embrace or ignore the large body of population-genetics literature.) Avida is arguably the most advanced software platform to study digital organisms to date, and is certainly the one that has had the biggest impact in the biological literature so far. Having reached version 2.14, it now supports detailed control over experimental settings, a sophisticated system to design and execute experimental protocols, a multitude of possibilities for organisms to interact with their environment (including depletable resources and conversion from one resource into another) and a module to post-process data from evolution experiments (including tools to find the line of descent from the original ancestor to any final organism, to carry out knock-out studies with organisms, to calculate the fitness landscape around a genotype, and to align and compare organisms' genomes).
|
||||
|
||||
## History of Digital Life
|
||||
|
||||
The most well-known intersection of evolutionary biology with computer science is the genetic algorithm or its many variants (genetic programming, evolutionary strategies, and so on). All these variants boil down to the same basic recipe: (1) create random potential solutions, (2) evaluate each solution assigning it a fitness value to represent its quality, (3) select a subset of solutions using fitness as a key criterion, (4) vary these solutions by making random changes or recombining portions of them, (5) repeat from step 2 until you find a solution
|
||||
that is sufficiently good.
|
||||
|
||||
This technique turns out to be an excellent method for solving problems, but it ignores many aspects of natural living systems. Most notably, natural organisms must replicate themselves, as there is no external force to do so; therefore, their ability to pass their genetic information on to the next generation is the final arbiter of their fitness. Furthermore, organisms in a natural system have the ability to interact with their environment and with each other in ways that are excluded from most algorithmic applications of evolution.
|
||||
|
||||
Work on more naturally evolving computational systems began in 1990, when Steen Rasmussen was inspired by the computer game "Core War" [Dewdney1984]. In this game, programs are written in a simplified assembly language and made to compete in the simulated core memory of a computer. The winning program is the one that manages to shut down all processes associated with its competitors. Rasmussen observed that the most successful of these programs were the ones that replicated themselves, so that if one copy were destroyed, others would still persist. In the original Core War game, the diversity of organisms could not increase, and hence no evolution was possible. Rasmussen designed a system similar to Core War in which the command that copied instructions was flawed and would sometimes write a random instruction instead on the one intended [RasmussenKnudsenFeldberg1990]. This flawed copy command introduced ''mutations'' into the system, and thus the potential for evolution. Rasmussen dubbed his new program "Core World", created a simple self-replicating ancestor, and let it run.
|
||||
|
||||
Unfortunately, this first experiment was only of limited success. While the programs seemed to evolve initially, they soon started to copy code into each other, to the point where no proper self-replicators survived---the system collapsed into a non-living state. Nevertheless, the dynamics of this system turned out to be intriguing, displaying the partial replication of fragments of code, and repeated occurrences of simple patterns.
|
||||
|
||||
The first successful experiment with evolving populations of self-replicating computer programs was performed the following year. Thomas Ray designed a program of his own with significant, biologically-inspired modifications. The result was the Tierra system [Ray1992]. In Tierra, digital organisms must allocate memory before they have permission to write to it, which prevents stray copy commands from killing other organisms. Death only occurs when memory fills up, at which point the oldest programs are removed to make room for new ones to be born.
|
||||
|
||||
The first Tierra experiment was initialized with an ancestral program that was 80 lines long. It filled up the available memory with copies of itself, many of which had mutations that caused a loss of functionality. Yet other mutations were neutral and did not affect the organism's ability to replicate --- and a few were even beneficial. In this initial experiment, the only selective pressure on the population was for the organisms to increase their rate of replication. Indeed, Ray witnessed that the organisms were slowly shrinking the length of their genomes, since a shorter genome meant that there was less genetic material to copy, and thus it could be copied more rapidly.
|
||||
|
||||
This result was interesting enough on its own. However, other forms of adaptation, some quite surprising, occurred as well. For example, some organisms were able to shrink further by removing critical portions of their genome, and then use those same portions from more complete competitors, in a technique that Ray noted was a form of parasitism. Arms races transpired where hosts evolved methods of eluding the parasites, and they, in turn, evolved to get around these new defenses. Some would-be hosts, known as hyper-parasites, even evolved mechanisms for tricking the parasites into aiding them in the copying of their own genomes. Evolution continued in all sorts of interesting manner, making Tierra seem like a choice system for experimental evolution work.
|
||||
|
||||
In 1992, <a href="http://faculty.kgi.edu/adami">Chris Adami</a> began research on evolutionary adaptation with Ray's Tierra system. His intent was to have these digital organisms to evolve solutions to specific mathematical problems, without forcing them use a pre-defined approach. His core idea was the following: If he wanted a population of organisms to evolve, for example, the ability to add two numbers together, he would monitor organisms' input and output numbers. If an output ever was the sum of two inputs, the successful organisms would receive extra CPU cycles as a bonus. As long as the number of extra cycles was greater than the time it took the organism to perform the computation, the leftover cycles could be applied toward the replication process, providing a competitive advantage to the organism. Sure enough, Adami was able to get the organisms to evolve some simple tasks, but faced many limitations in trying to use Tierra to study the evolutionary process.
|
||||
|
||||
In the summer of 1993, <a href="http://www.cse.msu.edu/~ofria/">Charles Ofria</a> and <a href="http://ivory.idyll.org/">C. Titus Brown</a> joined Adami to develop a new digital life software platform, the Avida system. Avida was designed to have detailed and versatile configuration capabilities, along with high precision measurements to record all aspects of a population. Furthermore, whereas organisms are executed sequentially in Tierra, the Avida system simulates a parallel computer, allowing all organisms to be executed effectively simultaneously. Since its inception, Avida has had many new features added to it, including a sophisticated environment with localized resources, an events system to schedule actions to occur over the course of an experiment, multiple types of CPUs to form the bodies of the digital organisms, and a sophisticated analysis mode to post-process data from an Avida experiment. Avida is under active development at Michigan State University, led by Charles Ofria and <a href="http://programerror.com">David Bryson</a>.
|
||||
|
||||
|
||||
## The Scientific Motivation for Avida
|
||||
|
||||
Intuitively, it seems that natural systems should be used to best understand how evolution produces the variation in observed in nature, but this can be prohibitively difficult for many questions and does not provide enough detail. Using digital organisms in a system such as Avida can be justified on five grounds:
|
||||
|
||||
<ol>
|
||||
<li>''Artificial life forms provide an opportunity to seek generalizations about self-replicating systems'' beyond the organic forms that biologists have studied to date, all of which share a common ancestor and essentially the same chemistry of DNA, RNA and proteins. As John Maynard Smith[Maynard-Smith1992] made the case: "So far, we have been able to study only one evolving system and we cannot wait for interstellar flight to provide us with a second. If we want to discover generalizations about evolving systems, we will have to
|
||||
look at artificial ones." Of course, digital systems should always be studied in parallel with natural ones, but any differences we find between
|
||||
their evolutionary dynamics open up what is perhaps an even more interesting set of questions.</li>
|
||||
<li>''Digital organisms enable us to address questions that are impossible to study with organic life forms''. For example, in one of our current experiments we are investigating the importance of deleterious mutations in adaptive evolution by explicitly reverting all detrimental mutations. Such invasive micromanaging of a population is not possible in a natural system, especially without disturbing other aspects of the evolution. In a digital evolving system, every bit of memory can be viewed without disrupting the system, and changes can be made at the
|
||||
precise points desired.</li>
|
||||
<li>''Other questions can be addressed on a scale that is unattainable with natural organisms''. In an earlier experiment with digital organisms [LenskiOfriaCollier1999] we examined billions of genotypes to quantify the effects of mutations as well as the form and extent of their interactions. By contrast, an experiment with ''E. coli'' was necessarily confined to one level of genomic complexity. Digital organisms also have a speed advantage: population with 10,000 organisms can have 20,000 generations processed per day on a modern desktop computer. A similar experiment with bacteria took over a decade [Lenski2004].</li>
|
||||
<li>''Digital organisms possess the ability to truly evolve, unlike mere numerical simulations''. Evolution is open-ended and the design of the evolved solutions is unpredictable. These properties arise because selection in digital organisms (as in real ones) occurs at the level of the whole-organism's phenotype; it depends on the rates at which organisms perform tasks that enable them to metabolize resources to convert them to energy, and the efficiency with which they use that energy for reproduction. Genome sizes are sufficiently large that evolving populations cannot test every possible genotype, so replicate populations always find different local optima. A genome typical consists of 50 to 1000 sequential instructions. With commonly 26 possible instructions at each position, there are many more potential genome states than there are atoms in the universe.</li>
|
||||
<li>''Digital organisms can be used to design solutions to computational problems'' where it is difficult to write explicit programs that produce the desired behavior [Goldberg2002,Koza2003]. Current evolutionary algorithm approaches are based on a simplistic view of evolution, leaving out many of the factors that are believed to make it such a powerful force. Thus there are new opportunities for biological concepts to have a large impact outside of biology, just as principles of physics and mathematics are often used throughout other fields, including biology.</li>
|
||||
</ol>
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
These settings allow you to control the number of analyze threads and to define values that analyze mode can access.
|
||||
|
||||
See avida.cfg for <code>MAX_CONCURRENCY, ANALYZE_OPTION_1</code>, and <code>ANALYZE_OPTION_2</code>.
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,29 @@
|
|||
One really useful feature in analyze mode is the ability for the user to construct a variety of their own commands without modifying the source code. This is done with the FUNCTION command. For example, if you know you will always need a file called lineage.html with very specific information in it, you might write a helper command for yourself as follows:
|
||||
|
||||
<pre>
|
||||
FUNCTION MY_HTML_LINEAGE # arg1=run_directory
|
||||
PURGE_BATCH
|
||||
LOAD $1/detail-100000.spop
|
||||
FIND_LINEAGE num_cpus
|
||||
RECALCULATE
|
||||
DETAIL $1/lineage.html depth parent_dist length fitness html.sequence
|
||||
END
|
||||
</pre>
|
||||
|
||||
This works identically to how we found lineages and printed their data in the section above. Only this time, it has created the new command called MY_HTML_LINEAGE that you can use anytime thereafter. Arguments to functions work similar to variables, but they are numbers instead of letters. Thus $1 translates to the first arguments, $2 becomes the second, and so on. You are limited to 9 arguments at this point, but that should be enough for most tasks. $0 is the name of the function you are running, in case you ever need to use that.
|
||||
|
||||
You may be interested in also using functions in conjunction with the SYSTEM command. Anything you type as arguments to this command gets run on the command line, so you can make functions to do anything that could otherwise be done were you at the shell prompt. For example, imagine that you were going to use a lot of compressed files in your analysis that you would first need to uncompress. You might right a function like:
|
||||
|
||||
<pre>
|
||||
FUNCTION UNZIP # Arg1=filename
|
||||
SYSTEM gunzip $1
|
||||
END
|
||||
</pre>
|
||||
|
||||
This is a shorter example than you might typically want to write a function for, but it does get the point across. This would allow you to just type UNZIP whenever you needed to uncompress something.
|
||||
|
||||
Functions are particularly useful in conjunction with the INCLUDE command. You can create a file called something like my_functions.cfg in your Avida work directory, define a bunch of functions there, and then start all of your analyze.cfg files with the line:
|
||||
|
||||
<code> INCLUDE my_functions.cfg </code>
|
||||
|
||||
and you will have access to all of your functions thereafter. Ideally, as this language becomes more flexible, so will your ability to create functions within the language, so you will be able to develop flexible and useful libraries for yourself.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
Quite often, the portion of an Avida run that we will be most interested in is the lineage from the final dominant genotype back to the original ancestor. As such, there are tools in Avida to get at this information.
|
||||
|
||||
<pre>
|
||||
FORRANGE i 100 199
|
||||
SET d /home/charles/dev/avida/runs/evo-neut/evo_neut_$i
|
||||
PURGE_BATCH
|
||||
LOAD $d/detail-100000.spop
|
||||
FIND_LINEAGE num_cpus
|
||||
RECALCULATE
|
||||
DETAIL lineage.$i.html depth parent_dist length fitness html.sequence
|
||||
END
|
||||
</pre>
|
||||
|
||||
This program looks very similar to one in the <a href="http://avida.devosoft.org/wiki/documentation/configuration-and-command-reference/sample-programs-from-analyze-mode/using-variables/" title="Using Variables">Using Variables</a> example. The first four lines are actually identical. A .spop detail file contains all of the genotypes that were currently alive in the population at the time it was printed, and by default all of the genotypes that are direct ancestors of those that were still alive. (If you used the save_historic=1 option when you saved this population, the .spop contains only the currently-alive genomes, and you will not find much of a lineage!)
|
||||
|
||||
The .spop file therefore gives us the lineages of the entire population back to the original ancestor. Since we are only interested in a single lineage, the next thing we do is run the FIND_LINEAGE command to pick out a single genotype, and discard everything else except for its lineage. In this case, we pick the genotype with the highest abundance (the most virtual CPUs associated with it) at the time of printing.
|
||||
|
||||
As before, the RECALCULATE command gets us any additional information we may need about the genotypes, and then we print that information to a file using the DETAIL command. The filenames that we are using this time have the format lineage.$i.html, so they are all being written to the current directory with filenames that incorporate the run number right in them. Also, because the filename ends in the suffix '.html', Avida knows to print the file in a proper html format. Note that the specific values that we choose to print take advantage of the fact that we have a lineage (and hence measured things like the genetic distance to the parent) and are in html mode (and thus can print the sequence using colors to specify where exactly mutations occurred).
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
The following program will load in a genome sequence, run it through a test CPU, and output the information about it in a couple of formats.
|
||||
|
||||
<pre>
|
||||
VERBOSE
|
||||
LOAD_SEQUENCE rmzavcgmciqqptqpqcpctletncogcbeamqdtqcptipqfpgqxutycuastttva
|
||||
RECALCULATE
|
||||
DETAIL detail_test.dat fitness merit gest_time length viable sequence
|
||||
TRACE
|
||||
PRINT
|
||||
</pre>
|
||||
|
||||
This program starts off with the VERBOSE command so that Avida will print to the screen all of the details about what is going on as it runs the analyze script; I recommend you begin all of your programs this way for debugging purposes. The program then uses the LOAD_SEQUENCE command to allow the user to enter a specific genome sequence in its compressed format. This will translate the genome into the proper genotype as long as you are using the correct instruction set file, since that file determines the mappings of letters to instructions).
|
||||
|
||||
The RECALCULATE command places the genome sequence into a test CPU, and determines its fitness, merit, gestation time, etc. so that the DETAIL command that follows it can have access to all of this information as it prints it to the file "detail_test.dat" (its first argument). The TRACE and PRINT commands will then print individual files about this genome, the first tracing its execution line-by-line, and the second summarizing all sorts of statistics about it and displaying the genome. Since no directory was specified for these commands, archive/ is assumed, and the filenames are org-S1.trace and org-S1.gen. If a genotype has a name when it is loaded, that name will be kept, but if it doesn't, it will be assigned a name starting at org-S1, then org-S2, and so on counting higher. The TRACE and PRINT commands add their own suffixes to the genome's name to determine the filename they will be printed as.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
Here are a couple of example problems you can try to see how well you can use analyze mode. These should get you used to working with it for future projects.
|
||||
|
||||
Problem 1. A detail file in Avida contains one line associated with each genotype, in order from the most abundant to the least. Currently, the LOAD command will load the entire file's worth of genotypes into the current batch, but what if you only wanted the top few? You should write a function called LOAD_DETAIL_TOP that takes two arguments. The first ($1) is the name file that needs to be loaded in (just as in the original command), and the second is the number of lines you want to load.
|
||||
|
||||
The easiest way to go about doing this is by using the SYSTEM command along with the Unix command head which will output the very top of a file. If you typed the line:
|
||||
|
||||
<code> head -42 detail-1000.spop > my_temp_file
|
||||
</code>
|
||||
|
||||
The file my_temp_file would be created, and its contents would be the first 42 lines of detail-1000.spop. So, what you need this function to do is create a temporary file with proper number of lines from the detail file in it, load that temp file into the current batch, and then delete the file (using the rm command). Warning: be very careful with the automated deletions -- you don't want to accidentally remove something that you really need! I recommend that you use the command rm -i until you finish debugging. This problem may end up being a little tricky for you, but you should be able to work your way through it.
|
||||
|
||||
Problem 2. Now that you have a working LOAD_DETAIL_TOP command, you can run LOAD_DETAIL_TOP 1 in order to only load the most dominant genotype from the detail file. Rewrite the example program from the section "Working with Batches" above such that you now only need to work within a single batch.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
Often, you will want to run the same section of analyze code with multiple different inputs each time through, or else you might simply want a single value to be easy to change throughout the code. To facilitate such programming practices, variables are available in analyze mode that can be altered for each repitition through the code.
|
||||
|
||||
There are actually several types of variables, all of which are a single letter of number. For a command that requires a variable name as an input, you simply put that variable where it is requested. For example, if you were going to set the variable i to be equal to the number 12, you would type:
|
||||
|
||||
<code> SET i 12 </code>
|
||||
|
||||
But later on in the code, how does Avida know when you type an i if you really want the letter 'i' there, or if you prefer the number 12 to be there? To distinguish these cases, you must put a dollar sign '$' before a variable wherever you want it to be translated to its value instead of just using the variable name itself.
|
||||
|
||||
There are a few different commands that allow you to manipulate a variable's value, and sometimes execute a section of code multiple times based off of each of the possible values. Here is one example:
|
||||
|
||||
<pre>
|
||||
FORRANGE i 100 199
|
||||
SET d /home/charles/dev/avida/runs/evo-neut/evo_neut_$i
|
||||
PURGE_BATCH
|
||||
LOAD $d/detail-100000.spop
|
||||
RECALCULATE
|
||||
DETAIL $d/detail.dat update length fitness sequence
|
||||
END
|
||||
</pre>
|
||||
|
||||
The FORRANGE command runs the contents of the loop once for each possible value in the range, setting the variable i to each of these values in turn. Thus the first time through the loop, 'i' will be equal to the value '100', then '101', '102', all the way up to '199'. In this particular case, we have 100 runs (numbered 100 through 199) that we want to work with.
|
||||
|
||||
The first thing we do once we're inside the loop is set the value of the variable 'd' to be the name of the directory we're going to be working with. Since this is a long directory name, we don't want to have to type it over every time we need it. If we set it to the variable d, then all we need to do is type '$d' in the future, and it will be translated to the full name. Note that in this case we are setting a variable to a string instead of a number; that's just fine and Avida will figure out how to handle it properly. This directory we are working with will change each time through the loop, and that it is no problem to use one variable as part of setting another.
|
||||
|
||||
After we know what directory we are using, we run a PURGE_BATCH to get rid of all of the genotypes from the last time through the loop (lest we just keep building up more and more genotypes in the current batch) and then we refill the batch by using LOAD to load in all of the genotypes saved in the file detail-100000.spop within our chosen directory. The RECALCULATE command runs all of the genotypes through a test CPU so we have all the statistics we need, and finally DETAIL will print out the stats we want to the file detail.dat, again placing it in the proper directory. The END command signifies the end of the FORRANGE loop.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
In analyze mode, we can load genotypes into multiple batches and we then operate on a single batch at a time. So, for example, if we wanted to only consider the dominant genotypes at time points 100 updates apart, but all we had to work with were the detail files (containing all genotypes at each time point) we might write a program like:
|
||||
|
||||
<pre>
|
||||
SET d /home/charles/avida/runs/mydir/here-it-is
|
||||
SET_BATCH 0
|
||||
FORRANGE u 100 100000 100 # Cycle through updates
|
||||
PURGE_BATCH # Purge current batch (0)
|
||||
LOAD $d/detail-$u.spop # Load in the population at this update
|
||||
FIND_GENOTYPE num_cpus # Remove all but most abundant genotype
|
||||
DUPLICATE 0 1 # Duplicate batch 0 into batch 1
|
||||
END
|
||||
SET_BATCH 1 # Switch to batch 1
|
||||
RECALCULATE # Recalculate statistics...
|
||||
DETAIL dom.dat fitness sequence # Print info for all dominants!
|
||||
</pre>
|
||||
|
||||
This program is slightly more complicated than the other examples, so I added in comments directly inside it. Basically, what we do here is use batch 0 as our staging area where we load the full detail dumps, strip them down to only the single most abundant genotype, and then copy that genotype over into batch 1. By the time we're done, we have all of the dominant genotypes inside of batch 1, so we can print anything we need right from there.
|
||||
|
|
@ -0,0 +1,273 @@
|
|||
Avida 3 will include and be built around a flexible, extensible application programming interface (API). The intention of the API is to provide a powerful, stable interface to core Avida functionality.
|
||||
|
||||
The API will be broken up into multiple modules that will be connected together to create rich experiments and powerful analyses. The development of this API is very active right now. The following provides an overview of existing components and an estimation of their completeness and stability.
|
||||
|
||||
### API Modules
|
||||
* core
|
||||
* data
|
||||
* environment
|
||||
* systematics
|
||||
* util
|
||||
* viewer
|
||||
|
||||
### Notes
|
||||
The following are miscellaneous notes, which may or may not be relevant to the current Avida 3.0 plans. Preserved for consideration.
|
||||
|
||||
* Get rid of merit. Organisms have energy (which they absorb by performing reactions) and metabolic rate, which determines how quickly they use that energy to execute instructions.
|
||||
* Each thread in an organism is placed into the scheduler. When a thread is created, the scheduler assigns it a process ID, and that ID is then freed up with the thread is removed. A thread must keep track of its own ID. When a thread is removed, its ID is placed in a container of free IDs. Only when that container is empty are new IDs created. This will happen rarely enough that its okay if its a slow process.
|
||||
* New analyze mode! This should be interesting... Require lex & yacc?
|
||||
* Implement new method of performing mutations. The old stuff should be entirely removed.
|
||||
* This version will be optimized for stack-based CPUs, but the old register based CPUs should still function fine.
|
||||
* Make sure all output files have headers. There should be a central object that all files are output through that will make sure this is the case.
|
||||
* Make events just call analyze scripts. Re-design entire event structure.
|
||||
|
||||
### Mutations.cfg ideas
|
||||
<pre>
|
||||
# @CAO : THIS IS A PROTOTYPE FILE FOR HOW I'D LIKE TO SEE MUTATIONS WORK
|
||||
|
||||
# This file is used to configure the mutations that occur during an avida
|
||||
# run. The format is simple:
|
||||
#
|
||||
# MUTATION <name> <trigger> <scope> <type> <rate>
|
||||
#
|
||||
# The "trigger" determines when the mutation should be tested for.
|
||||
# Possibilities are -
|
||||
#
|
||||
# update : Test for these mutations each update
|
||||
# divide : Test during the successful birth of an offspring
|
||||
# parent : Test on a parent during a divide operation
|
||||
# write : Test each time an instruction is written to memory
|
||||
# read : Test whenever an instruction is read from memory.
|
||||
# exec : Test while an instruction is being processed by the hardware
|
||||
#
|
||||
# A copy command will perform both a read and a write. A read mutation will
|
||||
# affect the site being read, and are therefore particulaly dangerous.
|
||||
#
|
||||
# The scope of a mutation type determines how much will be mutated. There
|
||||
# are currently a few options -
|
||||
#
|
||||
# genome : A single mutation occurs in the whole genome.
|
||||
# local : Mutations occur at a local position. If no local position can
|
||||
# be specified in the trigger (i.e. 'parent') nothing happens.
|
||||
# prop : Proportional: same as local, but the rate used is normalized to
|
||||
# 1/genome_length
|
||||
# global : Same as local, but *all* positions in the genome are tested.
|
||||
# spread : Same as prop, but all positions are tested.
|
||||
#
|
||||
# The type of mutation determines what happens when a mutation does occur
|
||||
# at a site -
|
||||
#
|
||||
# point : Change the affected locus to a random instruction.
|
||||
# insert : Insert a random instruction at this poistion.
|
||||
# delete : Remove the instruction currently at this position.
|
||||
# head_inc : Advance heads at this position.
|
||||
# head_dec : Retreat heads at this position.
|
||||
# temp : Don't change the genome, but temporarily act as if a change has
|
||||
# occured. This is only relevent for types "read" and "exec".
|
||||
# kill : Sterilize the organism affected so that it is effectively dead.
|
||||
#
|
||||
# Finally, the rate indicates the frequency at which mutations occur.
|
||||
#
|
||||
# EXAMPLES:
|
||||
#
|
||||
# Old stype copy mutation rate of 0.0075:
|
||||
#
|
||||
# MUTATION copy_mutation write local point 0.0075
|
||||
#
|
||||
# Old style divide insertion of 0.05:
|
||||
#
|
||||
# MUTATION divide_ins divide genome insert 0.05
|
||||
#
|
||||
# Keeping an average genome mutation rate at 2.0 with copy mutations...
|
||||
#
|
||||
# MUTATION copy_spread write prop point 2.0
|
||||
#
|
||||
# Most types of mutations that people want should be possible.
|
||||
#
|
||||
# CONFLICTS:
|
||||
# Only local & spread scopes can interact with head/temp types.
|
||||
# Divide trigger cannot work with local & spread scopes.
|
||||
</pre>
|
||||
|
||||
|
||||
### Stack-based Instruction Set
|
||||
<pre>
|
||||
# This new CPU has 8 heads, 2 of each main type, and otherwise has four
|
||||
# stacks (A, B, C, and D) and no registers.
|
||||
|
||||
# Base Instruction Set
|
||||
# Nops (1-4)
|
||||
Nop-A 1 # Associated with the Instruction Pointers
|
||||
Nop-B 1 # Associated with the Read Heads
|
||||
Nop-C 1 # Associated with the Write Heads
|
||||
Nop-D 1 # Associated with the Flow Heads
|
||||
|
||||
# Other control functions (5)
|
||||
Toggle 1 # Causes all instructions to swap to a complementary behavior
|
||||
# affects only the instruction that immediately follows it.
|
||||
# A nop indicates that the associate head should be toggled
|
||||
# to its alternate. Two toggles will reset all toggled states
|
||||
|
||||
# Single input Math -- *modifies* top of ?Stack-B? (6-7)
|
||||
Val-Shift 1 # shirt-r before toggle, shift-l after.
|
||||
Val-Inc 1 # inc before toggle, dec after
|
||||
|
||||
# Double input math -- uses top of Stack-A and Stack-B; pushes result onto
|
||||
# the top of Stack-B (8-9)
|
||||
Val-Nand 1 # unaffected by toggle
|
||||
Val-Add 1 # add before toggle, sub after
|
||||
|
||||
# Biological (10-13)
|
||||
SetMemory 1 # Set the write head at the beginning of a memory space. Up
|
||||
# to four memory spaces can be used at once. Nop-A is the
|
||||
# main genome, and the other nops are possible offspring.
|
||||
# A nop argument will indicate a space; no nops will find
|
||||
# an "unclaimed" memory space (if possible)
|
||||
# Perhaps Toggle can be used for recombination somehow??
|
||||
Divide 1 # Divide off offspring memory. After toggle becomes Inject.
|
||||
# If threads are active a successful inject will also cause
|
||||
# a fork. In either case, it uses the memory that contains
|
||||
# the active write head.
|
||||
Inst-Read 1 # Push the instruction at ?read-head? into Stack-A (advance
|
||||
# head) Toggle to move head back by one rather than advance.
|
||||
Inst-Write 1 # Pop Stack-A into position at ?write-head? (advance head)
|
||||
# Toggle to move head back by one rather than advance.
|
||||
|
||||
# Flow Control (14-15)
|
||||
If-Equal 1 # Compares top of ?Stack-A? with successor (Default: Stack-B)
|
||||
# Becomes If-NEqual after toggle
|
||||
If-Less 1 # Compares top of ?Stack-A? with successor (Default: Stack-B)
|
||||
# Becomes If-Greater after toggle
|
||||
|
||||
# Head Control (16-19)
|
||||
Head-Push 1 # Push position of ?IP? head onto Stack-B.
|
||||
# Toggle to use Stack-D
|
||||
Head-Pop 1 # Move ?flow-head? to address in Stack-B (pop Stack-B)
|
||||
# Toggle to use Stack-D
|
||||
|
||||
Head-Move 1 # Move ?IP? head to flow-head
|
||||
# - if flow-head is given as nop, advance flow-head
|
||||
# Toggle to decrement flow-head when given as nop.
|
||||
Search 1 # Search for matching template, set flow head to last line,
|
||||
# template size to Stack-A and template distance to Stack-B
|
||||
# If no template, move flow-head to next line, set A&B=0.
|
||||
# Toggle to NOT leave size&distance
|
||||
|
||||
# Stack Control (20-24)
|
||||
Push-Next 1 # Pop off ?Stack-A? and push on successor (Default: Stack-B)
|
||||
Push-Prev 1 # Pop off ?Stack-B? and push on predecessor (Default: Stack-A)
|
||||
Push-Comp 1 # Pop off ?Stack-B? and push on complement (Default: Stack-D)
|
||||
Val-Delete 1 # Pop off (and lose) top value of ?Stack-B?
|
||||
Val-Copy 1 # Duplicate the contents at the top of ?Stack-B?
|
||||
|
||||
# CPU:
|
||||
# Stack-A (Used in copying & math)
|
||||
# Stack-B (Used for positioning and math)
|
||||
# Stack-C (Input) -- Filled on birth
|
||||
# Stack-D (Output) -- Scanned (and emptied) on divide
|
||||
#
|
||||
# Four nops. Each nop has a predecessor, successor and complement (opposite)
|
||||
#
|
||||
# nop-A -> IP
|
||||
# nop-B -> Read Head
|
||||
# nop-C -> Write Head
|
||||
# nop-D -> Flow Head
|
||||
#
|
||||
# Note lack of allocate instruction!
|
||||
# The organism has additional memory space that the write heads starts out
|
||||
# at the beginning of. It is treated as an extension of the main memory,
|
||||
# BUT is local to each thread if there is more than one.
|
||||
|
||||
# SAMPLE ORGANISM:
|
||||
#
|
||||
# Search # 1: Find organism end.
|
||||
# Nop-C # 2: - Match A:A
|
||||
# Nop-C # 3:
|
||||
# Head-Push # 4: Save end position to Stack-B
|
||||
# Nop-D # 5: - Flow head is at end...
|
||||
# Push-Prev # 6: Move end position to Stack-A
|
||||
# SetMemory # 7: Place write-head in memory space for offspring
|
||||
# Search # 8: Drop flow head at start of copy loop
|
||||
# Inst-Read # 9:
|
||||
# Inst-Write # 10:
|
||||
# Head-Push # 11: Get current position of...
|
||||
# Nop-C # 12: - Read-Head
|
||||
# If-Equal # 13: Test if we are done copying...
|
||||
# Divide # 14: ...If so, divide.
|
||||
# Head-Move # 15: ...If not, continue with loop.
|
||||
# Nop-A # 16:
|
||||
# Nop-A # 17:
|
||||
|
||||
# Other possible, special instructions...
|
||||
# ScanWorld 1 # Environment-specific scanning instruction...
|
||||
# Val-Swap 1 # Swap top contents of ?Stack-A? with successor (Default: B)
|
||||
# Toggle will swap with complement.
|
||||
# Inst-Copy 1 # Combine read and write
|
||||
# Inst-Move 1 # Like Inst-Copy, but actually deletes original and can
|
||||
# move multiple lines at once (as indicated by ?Stack-B?)
|
||||
# SearchOut 1 # Like search, but in faced creature. Needs exact match!
|
||||
# Rotate 1 # Rotate to neighbor with template (toggle reverses dir)
|
||||
# in mass action, find randomly in population.
|
||||
# If-Bit-1 1 # Is last bit of ?Stack-B? a one? (toggle to If-Bit-0)
|
||||
# If-Zero 1 # Toggle to If-N-Zero
|
||||
# If-InstEqu 1 # Does contents of ?read-head? match successor (write-head)
|
||||
# (toggle to If-InstNEqu)
|
||||
# Order 1 # Put top two numbers in ?Stack-B? into numerical order
|
||||
# Push-Zero 1 # Push a zero onto the top of ?Stack-B?
|
||||
# Replicate 1 # Make a full offspring
|
||||
|
||||
|
||||
# ------- THREADING --------
|
||||
# There can only be up to four threads in an organism, specified as
|
||||
# Thead-A through Thread-D
|
||||
|
||||
# Hardware:
|
||||
# For threads, Stacks A and B are local, while C and D are global.
|
||||
# All heads are local to each thread.
|
||||
# - Read and Flow heads will initialize to fork.
|
||||
# - Write head will initialize on new offspring memory.
|
||||
# Each thread has its own offspring memory.
|
||||
# Each thread keeps its own list of toggled instructions.
|
||||
|
||||
# Instructions:
|
||||
# ThreadFork 1 # Create a new thread. By default this will be the next
|
||||
# available thread ID, but if a nop follows it will
|
||||
# indicate the thread instead. If a thread is specified
|
||||
# that already exists, its priority will increase to a
|
||||
# maximum. On the original thread executes the next
|
||||
# instruction. Toggle to ThreadKill ?cur-Thread?, which
|
||||
# will decrement a thread one step, to a min of 0.
|
||||
# If-Thread 1 # Only execute next instruction if this is ?Thread-A?
|
||||
# Toggle to IfNThread
|
||||
# ThreadCopy 1 # Make this thread an exact copy of ?Thread A? including
|
||||
# working on the same memory space. Toggle to ThreadClr
|
||||
# which will reset the specifed thread (default current)
|
||||
|
||||
# SAMPLE PARASITE
|
||||
#
|
||||
# Nop-A # 1: Some nop to extend the template above
|
||||
# Toggle # 2: Toggle the Divide command...
|
||||
# Divide # 3: ... to become "Inject"
|
||||
# Toggle # 4: Toggle the If-Equal command...
|
||||
# If-Equal # 5: ... to become "If-NEqual"
|
||||
# Search # 6: Locate the end, so we know when to stop.
|
||||
# Nop-C # 7:
|
||||
# Nop-D # 8:
|
||||
# Head-Push # 9: Save the location of the flow head to mark the end.
|
||||
# Nop-D # 10:
|
||||
# Push-Prev # 11: Move end position to Stack-A
|
||||
# SetMemory # 12: Claim and empty memory space
|
||||
# Search # 13: Drop flow head at start of copy loop
|
||||
# Inst-Read # 14:
|
||||
# Inst-Write # 15:
|
||||
# Head-Push # 16: Get current position of...
|
||||
# Nop-C # 17: - Read-Head
|
||||
# If-Equal # 18: Test if we are done copying... (If-NEqual)
|
||||
# Head-Move # 19: ...If not, continue with loop.
|
||||
# Divide # 20: ...If so, Inject!
|
||||
# Nop-C # 21: ... Into the very end of the host.
|
||||
# Nop-C # 22
|
||||
# Head-Move # 23: Go to the beginning of the copy loop and start over!
|
||||
# Nop-A # 24: End Template
|
||||
# Nop-B # 25:
|
||||
</pre>
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
The Avida configuration file (<kbd>avida.cfg</kbd>) is the main configuration file for Avida. With this file, the user can setup all of the basic conditions for a run.
|
||||
|
||||
<strong>avida.cfg is actually an excellent guide to itself</strong>; every option has a description of what it does and what its options are, and many of these pages will simply refer you to the file itself instead of replicating that description. We endeavor here to give extended explanations of particularly common or confusing options, and of settings that interact with other settings.
|
||||
|
||||
|
||||
== Configuration Sections ==
|
||||
* [[General Settings]]
|
||||
* [[Mutation Settings]]
|
||||
* [[Topology Settings]] : the shape and connectedness of the world
|
||||
* [[File Settings]] : other configuration files and where to save your data
|
||||
* [[Instruction Set]]
|
||||
* [[Reproduction Settings]] : birth and death
|
||||
* [[Time Slicing Settings]] : how CPU time is distributed among organisms
|
||||
* [[HTML Output Color Settings]]
|
||||
* [[Resource Hoarding Settings]] : internal resource storage for organisms
|
||||
* [[Divide Settings]] : limitations on organism division
|
||||
* [[Settings for Genealogy Info in the Test CPU]]
|
||||
* [[Mutations Reversion Settings]]
|
||||
* [[Analysis Settings]]: threads and variables in analyze mode
|
||||
|
|
@ -0,0 +1,211 @@
|
|||
# Avida: Beginner User Documentation
|
||||
|
||||
As you’re beginning to use Avida to answer research questions, it can be easy to get lost in the extensive amount of variables and settings you can use in Avida. The purpose of this documentation is to identify the features that are most important for you to consider before running an experiment in Avida. For each feature, this documentation will explain what it controls, what options you have, and how and where you set those options.
|
||||
|
||||
## **1. Set up the environment.**
|
||||
_Why you need to do this_
|
||||
|
||||
Setting up the environment tells Avida how big your universe is and what shape you want your universe to take. This will be important in determining a) the population cap for your experiment, b) how much (if any) empty space exists in your world, and c) how proportionally (or not) the organisms in your experiment have access to other organisms and resources. What you choose in this portion of the experiment will affect how organisms in your Avida universe interact with each other and, indirectly, the carrying capacity of your Avida universe.
|
||||
|
||||
_What you can do_
|
||||
|
||||
Avida allows you to customize both the world size and the world geometry. The world size determines the carrying capacity of your Avida world. In Avida (which is based on a grid system), each grid block can be occupied by only one Avida organism. So if you set the Avida grid height to 120 and the Avida grid width to 120, your Avida universe would have a carrying capacity of 14,400.
|
||||
|
||||
World geometry determines what shape your Avida grid will take. By default, the Avida universe is set to taking a toroidal (doughnut) shape. The creators of Avida chose this so that there are no edges in the universe and so that each organism has equal access to resources and neighbors. If, however, having boundaries and edges in your universe is important, you can change the shape of the Avida world to a bounded grid, hexagonal, random connected, and more. Details for what options exist for this setting and what they mean can be found in the avida.cfg file.
|
||||
|
||||
_Where to do it_
|
||||
|
||||
Both world size and world geometry are set in the avida.cfg file. World size is controlled by the WORLD_X and WORLD_Y controls; world geometry is controlled by the WORLD_GEOMETRY control. Similar to most grid systems, the width is controlled by the WORLD_X control and the height is controlled by the WORLD_Y control.
|
||||
|
||||
_How to do it_
|
||||
|
||||
To make changes to the default settings for world size and world geometry, 1) find the variables mentioned above in the avida.cfg file, 2) highlight and replace the current values with the ones you selected, and 3) save the file with your new changes.
|
||||
|
||||
## 2. Stock the environment with organisms.
|
||||
|
||||
_Why you need to do this_
|
||||
|
||||
An experiment can’t run without any organisms to evolve. If you don’t load an organism into the Avida config file, it would be like conducting a culture experiment— without any organisms in the petri dish.
|
||||
|
||||
_What you can do_
|
||||
|
||||
Avida comes with a number of different organisms you can use to populate your Avida world. Most experiments will use the basic Avida organism (defaultheads.org). This organism is haploid and asexual. For your first Avida experiments, it is highly recommended that you use the basic Avida organism. Only if your experiment explicitly calls for a different organism should you consider using a different Avida organism.
|
||||
|
||||
_Where to do it_
|
||||
|
||||
Organisms are stocked (or “injected”) into Avida in the events.cfg file. The command that controls what organisms are injected is the “Inject” function located here.
|
||||
|
||||
|
||||
|
||||
_How to Do it_
|
||||
|
||||
By default, Avida will inject the basic Avida organism (defaultheads.org). Unless you are changing this to a different organism, feel free to leave the file asis.
|
||||
|
||||
## 3. Decide how organisms will be born and how organisms will die.
|
||||
|
||||
_Why you need to do it_
|
||||
|
||||
The functions described in this setting give you control over how organisms enter and leave your Avida universe. Birth method determines where on the Avida grid new organisms are placed. Having control over this function allows you to mimic biological communities (if that’s important to your experiment) or to decide how organisms are dispersed across the Avida universe.
|
||||
|
||||
Death method allows you to determine whether organisms in your world can die from old age or not. This distinction may be crucial for experiments that investigate longevity issues. Population cap controls determine how many organisms are allowed to exist in your Avida universe and, if the population cap is reached, the population cap eldest control will determine if a) the oldest organism in the universe dies or b) a random organism from the universe dies.
|
||||
|
||||
_What you can do_
|
||||
|
||||
When it comes to placing new organisms in your Avida world, the birth method feature in Avida gives you a few options for where those organisms are placed. By default, new organisms are placed randomly onto the Avida grid. You can change this option, however, via the eleven birth method options found in the avida.cfg file next to the BIRTH_METHOD control. Some options include having new organisms facing the parent organism, replacing the oldest age in the neighborhood, or replacing the oldest within the entire population.
|
||||
|
||||
The death method setting allows you to decide if an organism in your Avida world can die of old age or not. Avida has one setting for turning off this function— meaning that an organism will never die of old age. Avida has another setting for turning this function on, meaning that organisms who complete a certain number of instructions (i.e., AGE_LIMIT) will die.
|
||||
|
||||
The population cap controls allow you to set a limit on how many organisms can exist in your Avida universe. While this is also partially controlled by the world size (see explanation in Step 1), the population cap can allow you to set an even smaller population maximum in your Avida world if having space and empty squares on the Avida grid is important to you. For example, let’s say I set my Avida world size to be 60 units high and 60 units wide. This would mean that I have set a de facto population cap of 3,600 (60 X 60) because Avida will only allow one organism to occupy a grid cell.
|
||||
|
||||
But this also means that, unless other factors (such as competition or a population cap) come into play, the population will continue growing until it fills each of the 3,600 cells. IF, however, I wanted there to be some extra space protected in the Avida world— if my experiment called for there to be extra room between organisms — I could set a population cap of 3,000 organisms. This means that, no matter how large my world is, there will only ever be a maximum 3,000 organisms in the Avida universe. Setting a population cap allows you to protect empty space and/or to keep a more precise control over your maximum potential population size.
|
||||
|
||||
Similarly, Avida allows you some flexibility over what happens to your Avida organisms when the population cap is reached. You can choose to a) kill off the oldest organism in the population or b) kill off a random member of the population. This choice is more or less critical depending on your research question(s), but should be thought over carefully when setting up your Avida experiment.
|
||||
|
||||
_Where you do it_
|
||||
|
||||
The birth method and death method settings are found in the reproduction section of the avida.cfg file. Birth method is controlled by the BIRTH_METHOD variable and the death method is controlled by the DEATH_METHOD variable. Controls for the population cap settings, including POPULATION_CAP and POP_CAP_ELDEST, are located in the “general group” section of the avida.cfg file.
|
||||
|
||||
_How you do it_
|
||||
|
||||
To change Avida’s birth method (i.e., where new organisms are placed in the Avida grid), choose the option you would prefer from the avida.cfg documentation (located next to the BIRTH_METHOD control). Highlight and replace the preselected option (in this case, number 7) with the option you would prefer for your experiment. Be sure to save the file with your changes.
|
||||
|
||||
To change the death method, locate the DEATH_METHOD variable in the avida.cfg file. By default, Avida is set to death method setting 2, which has a deathbyoldage feature. If you wish to turn this off, highlight and replace the 2 with a 0 (0 is the setting for no death by old age). If you wish to have organisms die from old age, keep the file the same.
|
||||
|
||||
To set a population cap, find the POPULATION_CAP control in the avida.cfg file, highlight the 0 (Avida defaults to 0/no population cap), and replace it with your population cap number (from our example above, this would be 3000). Do not use commas when writing in your population cap number in Avida. Once you’ve made your changes, save the avida.cfg file.
|
||||
|
||||
The POP_CAP_ELDEST control works by entering in either a 0 (default) or 1 after the control name in the avida.cfg file. Select 0 for a random organism or 1 for the oldest organism to die if the population reaches the carrying capacity (i.e., population cap) you set for the population in the previous step.
|
||||
|
||||
## 4. Stock the environment with resources.
|
||||
|
||||
_Why you need to do this_
|
||||
|
||||
Just like in biological systems, Avida works by using competition for resources as a motivation for organisms to evolve characteristics that help them secure more resources and, thus, make them more likely to reproduce. In Avida, you have some control over how many resources are available to organisms in your experiment as well as how evenly (or not) those resources are distributed across the Avida grid.
|
||||
|
||||
_What you can do_
|
||||
|
||||
By default, resources in Avida are infinite and undepletable. This means that there is never a shortage of a resource and that organisms are competing to acquire the most resources out of the infinite resource pool. They are not competing against each other for a limited number of resources. Furthermore, resources are, by default, dispersed evenly within the Avida environment. This means that there is no clustering of resources in a particular area. Organisms placed anywhere on the Avida grid will have equal access to resources.
|
||||
|
||||
While most experiments work well with the default settings, you can change both the amount of resources available (i.e., create a depletable resource) or the dispersal pattern of the resources (i.e., create high and low resource concentration areas) to better answer your research questions.
|
||||
|
||||
_Where you do this_
|
||||
|
||||
Any changes to the default settings of infinite and evenly dispersed resources are made in the environment.cfg file.
|
||||
How you do this
|
||||
Since most experiments don’t require changes to the default settings, changing the dispersal pattern and/or limiting the availability of resources requires more complex instructions. Those instructions, along with more description about what options are available to you, are located on the Avida documentation wiki [here](https://github.com/devosoft/avida/wiki/Environment-file).
|
||||
|
||||
## 5. Decide what task(s) organisms will use to compete for resources and how they will/will not be rewarded for those tasks.
|
||||
|
||||
_Why you need to do this_
|
||||
|
||||
In Avida, organisms complete logic functions to increase their merit. The more merit an organism in Avida has, the more CPU cycles it will receive. This means that the organism can reproduce faster and, eventually, become a more fit organism. As a researcher, you get to make choices about what logic tasks organisms in your Avida world will be asked to complete and how they will/will not be rewarded for completing these tasks. This will impact what types of behavior(s) you see evolving during your experiment.
|
||||
|
||||
_What you can do_
|
||||
|
||||
It is important that you decide 1) what kinds of logic tasks organisms in your experiment(s) will be asked to complete, 2) how organisms in your experiment will be rewarded for completing those various tasks, and 3) how an organism’s merit gets added to its pre-existing merit when it successfully completes a logic task.
|
||||
|
||||
### Kinds of logic tasks
|
||||
|
||||
By default, Avida will ask the organisms in your experiment to complete a series of nine logic tasks. This is often referred to in the Avida literature as the “default logic9 environment.” These nine logic tasks are listed in the environment.cfg file and move from relatively simple functions to more complex functions. For most experiments, the default logic9 environment provides a sufficiently complex environment. You can make the environment more complex, however, by adding additional logic tasks. There is a logic77 environment that adds such complexity but, again, most experiments work successfully with the default logic9 environment.
|
||||
|
||||
Conversely, if you’re not really interested in looking at tasks or looking at evolved behavior, you can remove some logic tasks or remove the logic tasks all together. This can make your data easier to analyze and will prevent you from having to factor in evolvability later on in your experiment.
|
||||
|
||||
### How organisms are rewarded
|
||||
Avida allows you to control how organisms are rewarded for completing logic tasks. For every different logic task you ask your organisms to complete, you get to decide a point value reward for completing that task. By default, simple logic tasks receive less reward points than the more complex logic tasks. This is to ensure that organisms have sufficient motivation to attempt to complete the more complicated logic tasks. You can choose, however, to undo this default setting and reward all tasks the same. If you were interested in how a particular behavior evolves you could arbitrarily set the reward value for a certain function significantly higher and see how that impacts evolution. Because the options here are endless, it’s important to keep your research question(s) in mind when deciding how rewards are distributed in Avida.
|
||||
|
||||
### How an organism’s merit is accumulated
|
||||
|
||||
Every time an organism in Avida completes a logic task, it receives increased merit. You have to decide how that newly earned merit will be combined with the organism’s previously accumulated merit. By default, an organism’s merit increases exponentially. This encourages organisms to spend time solving more complicated logic tasks (even though they take more time) because the reward for completing those tasks is exponentially higher than the reward they would receive from completing simpler logic tasks. This also prevents an organism that completes many simple logic tasks from acquiring more merit than an organism who completes a few difficult logic tasks.
|
||||
|
||||
While most experiments find the default settings to be a conducive way of encouraging the evolution of more complicated behavior, there are other settings that may be more appropriate for your particular research goals. More information about what other options are available and how they can be used in your experiment is located on the Avida documentation wiki [here](https://github.com/devosoft/avida/wiki/Environment-file).
|
||||
|
||||
_Where you can do it_
|
||||
|
||||
All of the settings for logic tasks and task reward are located in the environment.cfg file. When you open the file, you will see the nine default logic tests laid out as in the following example:
|
||||
|
||||
`REACTION NOT not process:value=1.0:type=pow requisite:max_count=1`
|
||||
|
||||
Each line that starts with REACTION marks a different logic task. The variables listed after REACTION in each line determine the reward value, type, and restrictions for that logic task. Here’s an example of how to read these variables.
|
||||
|
||||
In the examples above “NOT” would be the name of the logic task and “not” would be the type of logic task (often, these are the same). So this tells you that this logic function is named “NOT” and will ask the organisms in your experiment to solve a logic problem that requires them to complete a “not” logic task. (In Avida, this would be an organism correctly knowing to convert the sequence 001101 to 110010).
|
||||
|
||||
The “process:value=1.0:type=pow” is the part of the REACTION line that determines how much merit an organism receives for completing that task and how that merit gets added to the organism’s preexisting merit. The “value=1.0” part of the code assigns how much reward value (i.e., increased merit) an organism would receive from successfully completing that task. In this case, an organism gets 1.0 merit points for completing the task. The “type=pow” part of the code determines how newly earned merit from completing this task will be combined with the organism’s preexisting merit. In this example, an organisms merit is increased exponentially (the “pow” stands for power). This would mean that an organism would receive a 2^bonus or 2^1 for completing this task.
|
||||
|
||||
The final part of this REACTION line— “requisite:max_count=1” — sets a limit for how many times an organism can receive increased merit from completing this task. By default, this is set to 1, meaning that an organism would only receive increased merit the first time it completed that logic task. After that, the organism would not receive increased merit from repeating the same function. While this default setting encourages organisms to attempt increasingly complex behaviors, it may not work for all experiments and can be replaced with any value you choose. If your experiment requires that there is no merit cap on a particular logic function, you can delete the max_count=1 function completely so that the new code would read:
|
||||
|
||||
`REACTION NOT not process:value=1.0:type=pow`
|
||||
|
||||
_How you do it_
|
||||
|
||||
As we’ve seen in other portions of the Avida program, you make changes to these settings by highlighting the default value you wish to change and replacing it with your new value. For example, if I wanted to change how much merit an organism received from completing the NOT function in my experiment, I would highlight the source code where it says “1.0” and replace it with a higher value, such as “2.0” so that the final code would read like this (*'s to show changes):
|
||||
|
||||
`REACTION NOT not process:value=**2.0**:type=pow requisite:max_count=1`
|
||||
|
||||
If I also wanted to have the merit an organism receives from completing the NOT function to be
|
||||
added to their previous merit (as opposed to being increased exponentially), I would highlight 7
|
||||
where it says “pow” in the documentation and replace it with “add.” Again, the new REACTION line would read like this:
|
||||
|
||||
`REACTION NOT not process:value=2.0:type=**add** requisite:max_count=1`
|
||||
|
||||
If your experiment calls for less logic functions, you can delete a logic task by highlighting and
|
||||
deleting the undesired logic task. Be sure to delete the _entire_ line, not just part of the command.
|
||||
|
||||
It is also important that you not change either the task name (i.e., NOT) or task type (i.e., not) in the environment.cfg file. This will cause an error with your experiment. When you are done editing this file remember to save your changes.
|
||||
|
||||
## 6. Decide how long your experiment will last.
|
||||
|
||||
_Why you need to do this_
|
||||
|
||||
By default, Avida will run an experiment for 100,000 updates, where 10 updates are roughly equal to 1 generation. Depending on what type of experiment you’re doing, you may want to lengthen or shorten the default experiment runtime. Setting the experiment update time is like deciding how long you want a certain bacteria to culture and/or how many generations of fruit flies you’re going to analyze. Shorter experiment times in Avida will take less time and will be much less data to analyze and store; however, longer experiments will allow you to see more longterm
|
||||
evolutionary patterns and population dynamics.
|
||||
|
||||
_Where to do this_
|
||||
|
||||
The variable that controls the experiment length is located in the event.cfg file and is labeled “EXIT” (will be located near the bottom of the file).
|
||||
|
||||
|
||||
|
||||
_How to do this_
|
||||
|
||||
You can change the experiment update length by selecting the number 100000 and replacing it by typing in any positive whole number you select. Be sure to save the file before closing to update your changes.
|
||||
|
||||
## 7. Decide what types of data you will collect from your experiment.
|
||||
|
||||
_Why you need to do this_
|
||||
|
||||
Avida can collect and print a number of different types of data reports on any experiment. Depending on what your experiment is investigating, different types of data reports may or may not be as useful to you in answering your research question(s). Some of these data files are complex, take a long time to print, and use up a lot of computing/memory power on your device. Therefore, you can save yourself a lot of time and technological resources by intentionally selecting only the files you need Avida to print from your experiment.
|
||||
|
||||
In addition to selecting what files to print, it is also important to select the frequency at which Avida prints your data files. By default, Avida prints a complete set of data files after every 100 updates for the entire duration of your experiment. Depending on how long your experiment lasts and/or if you’re looking at shortterm or longterm evolutionary patterns, this default print frequency might not make sense for your research.
|
||||
|
||||
_What you can do_
|
||||
|
||||
The types of data files Avida can print are split into two groups: standard data files and nonstandard data files. The standard data files are printed by default in Avida and will save basic data about what is happening in your experiment (more information about what is collected in each of the standard data files is located in the events.cfg file).
|
||||
|
||||
The nonstandard data files keep track of more nuanced and specific data. These files are not printed by default in Avida. Because these files often require that Avida make more calculations, these files take up more computational/memory space on your device. Therefore, it is recommended that you only print the nonstandard data files that are essential to your experiment. Most experiments, especially at the beginner level, do not require any additional data files from the nonstandard data files group.
|
||||
|
||||
Avida also gives you a lot of control over when and how often the program prints data files. In particular, you can control three factors: 1) when Avida starts printing data files, 2) how many update cycles between data file printing, and 3) when Avida stops printing data files.
|
||||
|
||||
You can choose any update cycle to begin and end data collection, and can print data files as frequently (i.e., every 10 updates) or infrequently (i.e., every 10,000 updates) as needed.
|
||||
|
||||
_Where you can do this_
|
||||
|
||||
All settings to control data file printing are found in the events.cfg file. The standard data files are grouped together towards the beginning of the document and the nonstandard data files are group together towards the end of the document. The print timing and frequency controls are located next to each data file in this document.
|
||||
|
||||
_How you can do this_
|
||||
|
||||
Each data file is listed in the events.cfg file like this:
|
||||
|
||||
`u 0:100:end PrintAverageData`
|
||||
|
||||
To turn a data file on (i.e., print the file) remove the # from before the file name. Notice that the files in the standard file group don’t have a # at the beginning of the file name; that’s because they are printed (turned on) by default. If you choose to not print a certain data file, add a # to the beginning of the file name that you wish to turn off. For example, if you didn’t want to print the PrintAverageData file, you would insert an # before the u (i.e., `# u 0:100:end PrintAverageData`). The nonstandard data files do have a # before their file name (i.e., `# u 100:100:end PrintTotalsData`). This means that, unless you remove the #, that file will not print.
|
||||
|
||||
When Avida starts printing data, how often Avida prints a data file, and when Avida ends printing data are controlled by the three variables within colons. Taking our example from above,
|
||||
|
||||
`u 0:100:end PrintAverageData`
|
||||
|
||||
the “0” would be when Avida starts printing this data file (i.e., at the 0th update), the “100” would be the frequency at which Avida prints this data file (i.e., every 100 updates), and the “end” would be when Avida stops printing this data file (i.e., when the experiment ends). Rewriting this example to the following,
|
||||
|
||||
`u: 100:1000:10000 PrintAverageData`
|
||||
|
||||
would tell Avida to a) start printing this file at the 100th update, b) print this data file every 1,000 updates, and c) stop printing this file at 10,000 updates (even if the experiment is still running).
|
||||
|
||||
This documentation was produced by Rebecca Zantjer with consultation from members of the Devolab.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
## Main Configuration Files
|
||||
* [[Avida.cfg|Avida.cfg]]
|
||||
* [Events File](https://github.com/devosoft/avida/wiki/Events-file)
|
||||
* [Environment File](https://github.com/devosoft/avida/wiki/Environment-file)
|
||||
* [Instruction Set](https://github.com/devosoft/avida/wiki/Instruction-Set)
|
||||
* [[instset-heads.cfg]]
|
||||
* [[default-heads.org]]
|
||||
* [Analyze File](https://github.com/devosoft/avida/wiki/Analyze-File)
|
||||
|
||||
## Analyze Mode
|
||||
* [[Analyze File]]
|
||||
* [[Sample Analyze Programs]]
|
||||
|
||||
## Subpopulations (Demes)
|
||||
* [[Deme introduction]]
|
||||
* [[Deme migration]]
|
||||
|
||||
## Misc. Configuration
|
||||
* [[Quirks]]
|
||||
* [[Setting up Fixed-Length Organisms]]
|
||||
* [[Introduction to Parasites]]
|
||||
* [[Gradient Resources]]
|
||||
* [[Internal resources]]
|
||||
* [[Using mating types (separate sexes)]]
|
||||
* [[Energy model configuration]]
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
A flame graph is a visual representation of genetic diversity and "speciation" through an Avida run, graphing genetic distance over time. It is related to a phylogeny, but it is <em>not</em> a phylogeny and should not be mistaken for (or used as!) one.
|
||||
|
||||
1. Generating the Data
|
||||
|
||||
First you must obtain the necessary data -- you need population detail files (historic files are not necessary) files. The default events.cfg generates these only every 50,000 updates, so you must change this to get finer timeslices. More timeslices yield a smoother graph, but also increase the storage space necessary for your run. I generally use time slices of 100 or 50 updates, because storage is cheap and I like smooth graphs.
|
||||
|
||||
Once you have your population files, there are two ways to create a flamegraph. Choose according to your preferred tools:
|
||||
|
||||
== Producing a Flame Graph with flamegraph.py ==
|
||||
|
||||
flamegraph.py is a Python script found in avida-core/source/utils/hist_map/ which uses matplotlib to produce the flamegraph. (It requires both Python and [http://matplotlib.sourceforge.net/ matplotlib] to work). It will handle both unzipped (.spop) and gzipped(.spop.gz) files.
|
||||
|
||||
To run it:
|
||||
|
||||
<code>python flamegraph.py <output file> <column # of phylogenetic depth> <column # of number of organisms> <files> </code>
|
||||
|
||||
matplotlib can produce graphs in png, pdf, ps, eps, or svg format; choose the extension of your output file appropriately.
|
||||
|
||||
In the current default Avida, the population detail files (.spop) use column 14 for phylogenetic depth and column 5 for number of organisms. (Older Avida population detail files with the .pop extension use columns 12 and 4, respectively.) Additionally, you will want to ensure that flamegraph.py reads the detail files the correct order, and that you include any files still gzipped. Altogether, your command should look something like this:
|
||||
|
||||
<code>python flamegraph.py flame.pdf 14 5 detail-?00.spop* detail-??00.spop* detail-???00.spop* detail-????00.spop*
|
||||
</code>
|
||||
|
||||
When it has run, you may wish to check the reported number of rows -- it should be the number of detail files provided.
|
||||
|
||||
(If you wish to immediately see the graph produced, you can add the -g flag. The -q flag will stop all those "Processing..." messages from appearing.)
|
||||
|
||||
== Producing a Flame Graph with hist_map and Matlab ==
|
||||
|
||||
This is the "classic" method.
|
||||
|
||||
<strong>1. hist_map</strong>
|
||||
|
||||
If you have not already compiled hist_map, do so. It is located in source/utils/hist_map/, and you can simply use the Makefile. (Type "make" on the command line while in this directory.)
|
||||
|
||||
Now run it:
|
||||
|
||||
<code>hist_map <column # of phylogenetic depth> <column # of number of organisms> <files> <output file> </code>
|
||||
|
||||
In the current default Avida, the population detail files (.spop) use column 14 for phylogenetic depth and column 5 for number of organisms. (Older Avida population detail files with the .pop extension use columns 12 and 4, respectively.) Additionally, you will want to ensure that hist_map reads the detail files the correct order. Altogether, your command should look something like this:
|
||||
|
||||
<code>hist_map 12 4 detail-?00.spop detail-??00.spop detail-???00.spop detail-????00.spop <output file></code>
|
||||
When it has run, you may wish to check the reported number of rows -- it should be the number of detail files provided.
|
||||
|
||||
<strong>2. Matlab</strong>
|
||||
|
||||
Load the file created by hist_map into matlab, using zl or your favorite matrix-loading tool. E.g.:
|
||||
|
||||
<code>flame_matrix = zl('<file generated by hist_map>');</code>
|
||||
What you will actually graph is the transpose of the log of this matrix + 1:
|
||||
|
||||
<code>flame_graphable = (log(flame_matrix + 1))';</code>
|
||||
Finally, pcolor it -- for flame-colored flame graphs, use the hot colormap:
|
||||
|
||||
<code>colormap('hot')</code>
|
||||
<code>flame_graph = pcolor(flame_graphable)</code>
|
||||
If at this point your flame graph is pure black, try the command
|
||||
|
||||
<code>shading flat</code>
|
||||
|
|
@ -0,0 +1,228 @@
|
|||
This document describes the structure of the classic virtual CPU and an example organism running on it.
|
||||
|
||||
## The Virtual CPU Structure
|
||||
|
||||
The virtual CPU, which is the default "body" or "hardware" of the organisms, contains the following set of components, (as further illustrated in the figure below).
|
||||
|
||||
* A <strong style="color: #006666">memory</strong> that consists of a sequence of instructions, each associated with a set of flags to denote if the instruction has been executed, copied, mutated, etc. Memory is treated as circular, such that execution will loop back to the first instruction after the last instruction has been executed
|
||||
* An <strong style="color: #880088">instruction pointer</strong> (IP) that indicates the next site in the memory to be executed.
|
||||
* Three <strong style="color: #FF8888">registers</strong> that can be used by the organism to hold data currently being manipulated. These are often operated upon by the various instructions, and can contain arbitrary 32-bit integers.
|
||||
* Two <strong style="color: #008800">stacks</strong> that are used for storage. The organism can theoretically store an arbitrary amount of data in the stacks, but for practical purposes we currently limit the maximum stack depth to ten.</li>
|
||||
* An <strong style="color: #CCCC00">input buffer</strong> and an <strong style="color: #CCCC00">output buffer</strong> that the organism uses to receive information, and return the processed results.</li>
|
||||
* A <strong style="color: #8888FF">Read-Head</strong>, a <strong style="color: #8888FF">Write-Head</strong>, and a <strong style="color: #8888FF">Flow-Head</strong> which are used to specify positions in the CPU's memory. A copy command reads from the Read-Head and writes to the Write-Head. Jump-type statements move the IP to the Flow-Head.
|
||||
|
||||
<img src="images/cpu2.gif" alt="" title="cpu2" width="593" height="476" class="alignnone size-full wp-image-185" />
|
||||
|
||||
|
||||
## Instruction Set Configuration
|
||||
|
||||
The instruction set in Avida is loaded on startup from a configuration file specified in the <kbd>avida.cfg</kbd> file. This allows selection of different instruction sets without recompiling the source code, as well as allowing different sized instruction sets to be specified. It is not possible to alter the behavior of individual instructions or add new instructions without recompiling Avida; such activities have to be done directly in the source code.
|
||||
|
||||
The available instructions are listed in the <kbd>inst_set.*</kbd> files with a <code>1</code> or a <code>0</code> next to an instruction to indicate if it should or should not be included. Changing the instruction set to be used simply involves adjusting these flags.
|
||||
|
||||
The instructions were created with three things in mind:
|
||||
|
||||
* To be as complete as possible (both in a "Turing complete" sense -- that is, it can compute any computable function -- and, more practically, to ensure that simple operations only require a few instructions).
|
||||
* For each instruction to be as robust and versatile as possible; all instructions should take an "appropriate" action in any situation where they can be executed.
|
||||
* To have as little redundancy as possible between instructions. (Several instructions have been implemented that are redundant, but such combinations will typically not be turned on simultaneously for a run.)
|
||||
|
||||
One major concept that differentiates this virtual assembly language from its real-world counterparts is in the additional uses of <code>nop</code> instructions (no-operation commands). These have no direct effect on the virtual CPU when executed, but often modify the effect of any instruction that precedes them. In a sense, you can think of them as purely regulatory genes. The default instruction set has three such <code>nop</code> instructions: <code>nop-A</code>, <code>nop-B</code>, and <code>nop-C</code>.
|
||||
|
||||
The remaining instructions can be seperated into three classes. The first class is those few instructions that are unaffected by nops. Most of these are the "biological" instructions involved directly in the replication process. The second class of instructions is those for which a <code>nop</code> changes the head or register affected by the previous command. For example, an <code>inc</code> command followed by the instruction <code>nop-A</code> would cause the contents of the <code>AX</code> register to be incremented, while an <tt>inc</tt> command followed by a <tt>nop-B</tt> would increment <code>BX</code>.
|
||||
|
||||
The notation we use in instruction definitions to describe that a default component (that is, a register or head) can be replaced due to a nop command is by surrounding the component name with <code>?</code>'s. The component listed is the default one to be used, but if a <code>nop</code> follows the command, the component it represents in this context will replace this default. If the component between the question marks is a register than a subsequent <code>nop-A</code> represents the <code>AX</code> register, <code>nop-B</code> is <code>BX</code>, and <code>nop-C</code> is <code>CX</code>. If the component listed is a head (including the instruction pointer) then a
|
||||
<code>nop-A</code> represents the Instruction Pointer, <code>nop-B</code> represents the Read-Head, and <code>nop-C</code> is the Write-Head. Currently the Flow-Head has no <code>nop</code> associated with it.
|
||||
|
||||
The third class of instructions are those that use a series of <tt>nop</tt> instructions as a template (label) for a command that needs to reference another position in the code, such as <code>h-search</code>. If <code>nop-A</code> follows a search command, it scans for the first complementary template (<code>nop-B</code>) and moves the Flow-Head
|
||||
there. Templates may be composed of more than a single <code>nop</code> instruction. A series of nops is typically abbreviated to the associated letter and separated by colons. This the sequence "<code>nop-A nop-A nop-C</code>" would be displayed as "<code>A:A:C</code>".
|
||||
|
||||
The label system used in Avida allows for an arbitrary number of nops. By default, we have three: <code>nop-A</code>'s complement is <code>nop-B</code>, <code>nop-B</code>'s is <code>nop-C</code>, and <code>nop-C</code>'s is <code>nop-A</code>. Likewise, some instructions talk about the complement of a register or head -- the same pattern is used in those cases. So if an instruction tests if <code>?BX?</code> is equal to its complement, it will test if
|
||||
<code>BX == CX</code> by default, but if it is followed by a <code>nop-C</code> it will test if <code>CX == AX</code>.
|
||||
|
||||
|
||||
## Instruction Set Reference
|
||||
|
||||
An abbreviated description of the 26 default instructions is below.
|
||||
|
||||
<table>
|
||||
<tr><th valign=top>(a-c) <td><code>nop-A</code>, <code>nop-B</code>, <br> and <code>nop-C</code>
|
||||
<td valign=top>No-operation instructions; these modify other instructions.</tr>
|
||||
|
||||
<tr><th>(d) <td><code>if-n-equ</code>
|
||||
<td>Execute next instruction only-if ?BX? does not equal its complement</tr>
|
||||
|
||||
<tr><th>(e) <td><code>if-less</code>
|
||||
<td>Execute next instruction only if ?BX? is less than its complement</tr>
|
||||
|
||||
<tr><th>(f) <td><code>if-label</code>
|
||||
<td>Execute the next instruction only if the given template complement was just copied</tr>
|
||||
|
||||
<tr><th>(g) <td><code>mov-head</code>
|
||||
<td>Move the ?IP? to the same position as the Flow-Head</tr>
|
||||
|
||||
<tr><th>(h) <td><code>jmp-head</code>
|
||||
<td>Move the ?IP? by a fixed amount found in CX</tr>
|
||||
|
||||
<tr><th>(i) <td><code>get-head</code>
|
||||
<td>Write the position of the ?IP? into CX</tr>
|
||||
|
||||
<tr><th>(j) <td><code>set-flow</code>
|
||||
<td>Move the Flow-Head to the memory position specified by ?CX?</tr>
|
||||
|
||||
<tr><th>(k) <td><code>shift-r</code>
|
||||
<td>Shift all the bits in ?BX? one to the right</tr>
|
||||
|
||||
<tr><th>(l) <td><code>shift-l</code>
|
||||
<td>Shift all the bits in ?BX? one to the left</tr>
|
||||
|
||||
<tr><th>(m) <td><code>inc</code>
|
||||
<td>Increment ?BX?</tr>
|
||||
|
||||
<tr><th>(n) <td><code>dec</code>
|
||||
<td>Decrement ?BX?</tr>
|
||||
|
||||
<tr><th>(o) <td><code>push</code>
|
||||
<td>Copy the value of ?BX? onto the top of the current stack</tr>
|
||||
|
||||
<tr><th>(p) <td><code>pop</code>
|
||||
<td>Remove a number from the current stack and place it in ?BX?</tr>
|
||||
|
||||
<tr><th>(q) <td><code>swap-stk</code>
|
||||
<td>Toggle the active stack</tr>
|
||||
|
||||
<tr><th>(r) <td><code>swap</code>
|
||||
<td>Swap the contents of ?BX? with its complement.</tr>
|
||||
|
||||
<tr><th>(s) <td><code>add</code>
|
||||
<td>Calculate the sum of BX and CX; put the result in ?BX?</tr>
|
||||
|
||||
<tr><th>(t) <td><code>sub</code>
|
||||
<td>Calculate the BX minus CX; put the result in ?BX?</tr>
|
||||
|
||||
<tr><th>(u) <td><code>nand</code>
|
||||
<td>Perform a bitwise NAND on BX and CX; put the result in ?BX?</tr>
|
||||
|
||||
<tr><th>(v) <td><code>h-copy</code>
|
||||
<td>Copy an instruction from the Read-Head to the Write-Head and advance both.</tr>
|
||||
|
||||
<tr><th>(w) <td><code>h-alloc</code>
|
||||
<td>Allocate memory for an offspring</tr>
|
||||
|
||||
<tr><th>(x) <td><code>h-divide</code>
|
||||
<td>Divide off an offspring located between the Read-Head and Write-Head.</tr>
|
||||
|
||||
<tr><th>(y) <td><code>IO</code>
|
||||
<td>Output the value ?BX? and replace it with a new input</tr>
|
||||
|
||||
<tr><th>(z) <td><code>h-search</code>
|
||||
<td>Find a complement template and place the Flow-Head after it.</tr>
|
||||
|
||||
|
||||
</table>
|
||||
|
||||
|
||||
### An Example Ancestor
|
||||
|
||||
The following organism is stored in the file <kbd>organism.heads.15</kbd>, which you should find in the <kbd>support/config/misc/</kbd> directory. This is a simplified version of <kbd>organism.default</kbd> and
|
||||
<kbd>organism.heads.100</kbd>, of lengths 50 and 100 respectively (each has additional instructions placed before the copy loop)
|
||||
|
||||
<table>
|
||||
<tr><td colspan=2><font color="#886600"># --- Setup ---</font><br>
|
||||
<tr><td><b><code>h-alloc</code></b> <td><font color="#886600"># Allocate extra space at the end of the genome to copy the offspring into.</font><br>
|
||||
<tr><td><b><tt>h-search </tt></b> <td><font color="#886600"># Locate an
|
||||
<tt>A:B</tt> template (at the end of the organism) and
|
||||
place the Flow-Head after it</font><br>
|
||||
<tr><td><b><tt>nop-C</tt></b> <td><font color="#886600">#</font><br>
|
||||
<tr><td><b><tt>nop-A</tt></b> <td><font color="#886600">#</font><br>
|
||||
<tr><td><b><tt>mov-head</tt></b> <td><font color="#886600"># Place the
|
||||
Write-Head at the Flow-Head (which is at beginning of
|
||||
offspring-to-be).</font><br>
|
||||
<tr><td><b><tt>nop-C</tt></b> <td><font color="#886600"># [ Extra
|
||||
<tt>nop-C</tt> commands can be placed here w/o harming the
|
||||
organism! ]</font><br>
|
||||
<tr><td>
|
||||
<tr><td colspan=2><font color="#886600"># --- Copy Loop ---</font><br>
|
||||
<tr><td><b><tt>h-search</tt></b> <td><font color="#886600"># No template,
|
||||
so place the Flow-Head on the next line code</font><br>
|
||||
<tr><td><b><code>h-copy</code></b> <td><font color="#886600"># Copy a single
|
||||
instruction from the read head to the write head (and advance both
|
||||
heads!)</font><br>
|
||||
<tr><td><b><code>if-label</code></b> <td><font color="#886600"># Execute the
|
||||
line following this template <i>only if</i> we have just copied an
|
||||
<code>A:B</code> template.</font><br>
|
||||
<tr><td><b><code>nop-C</code></b> <td><font color="#886600">#</font><br>
|
||||
<tr><td><b><code>nop-A</code></b> <td><font color="#886600">#</font><br>
|
||||
<tr><td><b><code>h-divide</code></b> <td><font color="#886600"># ...Divide off offspring! (note if-statement above!)</font><br>
|
||||
<tr><td><b><code>mov-head</code></b> <td><font color="#886600"># Otherwise,
|
||||
move the IP back to the Flow-Head at the beginning of the copy
|
||||
loop.</font><br>
|
||||
<tr><td><b><code>nop-A</code></b> <td><font color="#886600"># End label.</font><br>
|
||||
<tr><td><b><code>nop-B</code></b> <td><font color="#886600"># End label.</font><br>
|
||||
</table>
|
||||
|
||||
This program begins by allocating extra space for its offspring. The exact amount of space does not need to be specified -- it will allocate as much as it is allowed to. The organism will then do a search for the end
|
||||
of its genome (where this new space was just placed) so that it will know where to start copying. First the Flow-Head is placed there, and then the Write-Head is moved to the same point.
|
||||
|
||||
It is after this initial setup and before the actual copying process commences that extra <code>nop</code> instructions can be included. The only caveat is that you need to make sure that you don't duplicate any templates
|
||||
that the program will be searching for, or else it will no longer function properly. The easiest thing to do is insert a long sequence of <code>nop-C</code> instructions.
|
||||
|
||||
Next we have the beginning of the "copy loop". This segment of code starts off with an <code>h-search</code> command with no template following it. In such as case, the Flow-Head is placed on the line immediately following the search. This head will be used to designate the place that the IP keeps returning to with each cycle of the loop.
|
||||
|
||||
The <code>h-copy</code> command will copy a single instruction from the Read-Head (still at the very start of the genome, where it begins) to the Write-Head (which we placed at the beginning of the offspring). With any copy command there is a user-specified chance of a copy mutation. If one occurs, the Write-Head will place a random instruction rather than the one that it gathered from the Read-Head. After the copy occurs (for better or worse),
|
||||
both the Read-Head and the Write-Head are advanced to the next instruction in the genome. It is for this reason that a common mutation we see happening will place a long string of h-copy instruction one after another.
|
||||
|
||||
The next command, <code>if-label</code> (followed by a <code>nop-C</code> and a <code>nop-A</code>) tests to see if the complement of <code>C:A</code> is the most thing copied. That is, if the two most recent instructions copied were a <code>nop-A</code> followed by a <code>nop-B</code> as is found at the end of the organism. If so, we are done! Execute the next instruction which is <code>h-divide</code> (when this occurs, the read and write heads will surround the portion of memory to be split off as the offspring's genome). If not, then we need to keep going. Skip the next instruction and move on to the <code>mov-head</code> which will move the head specified by the <code>nop</code> that follows (in this case <code>nop-A</code> which is the Instruction Pointer) to the Flow-Head at the beginning of the copy loop.
|
||||
|
||||
This process will continue until all of the lines of code have been copied, and an offspring is born.
|
||||
|
||||
|
||||
### An Example Logic Gene
|
||||
|
||||
Here is a short example program to demonstrate one way for an organism to perform the "OR" logic operation. This time I'm only going to show the contents of the registers after each command because the functionality of the individual instructions should be clear, and the logic itself won't be helped much by a line-by-line explanation in English.
|
||||
|
||||
<table>
|
||||
<tr><th bgcolor="#CCCCFF" width=11%>Line #
|
||||
<th bgcolor="#CCCCFF" width=34%>Instruction
|
||||
<td bgcolor="#CCCCFF" width=11%><b>AX</b>
|
||||
<td bgcolor="#CCCCFF" width=11%><b>BX</b>
|
||||
<td bgcolor="#CCCCFF" width=11%><b>CX</b>
|
||||
<td bgcolor="#CCCCFF" width=11%><b>Stack</b>
|
||||
<td bgcolor="#CCCCFF" width=11%><b>Output</b>
|
||||
<tr><th bgcolor="#FF88FF"> 1 <th bgcolor="#88FFFF">IO
|
||||
<td bgcolor="#FFBBBB">? <td bgcolor="#FFBBBB">X <td bgcolor="#FFBBBB">?
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88"> ?
|
||||
<tr><th bgcolor="#FF88FF"> 2 <th bgcolor="#88FFFF">push
|
||||
<td bgcolor="#FFBBBB">? <td bgcolor="#FFBBBB">X <td bgcolor="#FFBBBB">?
|
||||
<td bgcolor="#AAFFAA">X, ? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF"> 3 <th bgcolor="#88FFFF">pop
|
||||
<td bgcolor="#FFBBBB">? <td bgcolor="#FFBBBB">X <td bgcolor="#FFBBBB">X
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF"> 4<th bgcolor="#88FFFF">nop-C <td colspan=5>
|
||||
<tr><th bgcolor="#FF88FF"> 5 <th bgcolor="#88FFFF">nand
|
||||
<td bgcolor="#FFBBBB">~X <td bgcolor="#FFBBBB">X <td bgcolor="#FFBBBB">X
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF"> 6<th bgcolor="#88FFFF">nop-A <td colspan=5>
|
||||
<tr><th bgcolor="#FF88FF"> 7 <th bgcolor="#88FFFF">IO
|
||||
<td bgcolor="#FFBBBB">~X <td bgcolor="#FFBBBB">Y <td bgcolor="#FFBBBB">X
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88"> X
|
||||
<tr><th bgcolor="#FF88FF"> 8 <th bgcolor="#88FFFF">push
|
||||
<td bgcolor="#FFBBBB">~X <td bgcolor="#FFBBBB">Y <td bgcolor="#FFBBBB">X
|
||||
<td bgcolor="#AAFFAA">Y, ? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF"> 9 <th bgcolor="#88FFFF">pop
|
||||
<td bgcolor="#FFBBBB">~X <td bgcolor="#FFBBBB">Y <td bgcolor="#FFBBBB">Y
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF">10<th bgcolor="#88FFFF">nop-C <td colspan=5>
|
||||
<tr><th bgcolor="#FF88FF">11 <th bgcolor="#88FFFF">nand
|
||||
<td bgcolor="#FFBBBB">~X <td bgcolor="#FFBBBB">~Y <td bgcolor="#FFBBBB">Y
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF">12 <th bgcolor="#88FFFF">swap
|
||||
<td bgcolor="#FFBBBB">Y <td bgcolor="#FFBBBB">~Y <td bgcolor="#FFBBBB">~X
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF">13<th bgcolor="#88FFFF">nop-C <td colspan=5>
|
||||
<tr><th bgcolor="#FF88FF">14 <th bgcolor="#88FFFF">nand
|
||||
<td bgcolor="#FFBBBB">Y <td bgcolor="#FFBBBB">X or Y <td bgcolor="#FFBBBB">~X
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88">
|
||||
<tr><th bgcolor="#FF88FF">15 <th bgcolor="#88FFFF">IO
|
||||
<td bgcolor="#FFBBBB">Y <td bgcolor="#FFBBBB">Z <td bgcolor="#FFBBBB">~X
|
||||
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88"> X or Y
|
||||
</table>
|
||||
|
|
@ -0,0 +1 @@
|
|||
The default ancestor organism when using the Heads virtual CPU.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
<div>
|
||||
<p>(Material adapted from Heather Goldsby's dissertation... so, it's a bit formal.)</p>
|
||||
<p>To study group behavior with Avida, we divide the population of digital organisms into distinct subpopulations and link their long-term fates. Groups (also referred to as demes or colonies) can comprise a set of genetically-clonal or genetically-heterogeneous organisms. As with individual organisms, entire groups replicate and compete for space, but at a much greater time-scale.</p>
|
||||
<p><strong>Group Competition</strong></p>
|
||||
<p>There are two different forms of group competition. Both types of group competition result in group replication. First, for some experiments, we use tournament selection in which groups compete every 100 updates based on a fitness function, where a group's success is determined by the behavior of its constituent organisms. Each tournament contains a set of groups selected at random, and the group with greatest fitness is replicated (ties are broken randomly). Second, some of our experiments use task-based group competition (or deme replication event), where a group replication event is triggered by the collective behavior of individuals within a group. For example, a group could be set to replicate once its constituent organisms have consumed a certain amount of resources. (See create a deme replication event for a tutorial on how to make this work.)</p>
|
||||
<p> </p>
|
||||
<p><strong>FAQ:</strong></p>
|
||||
</div>
|
||||
<ul>
|
||||
<li><strong>How do I set the size of a deme?</strong> The deme x-dimension is that of the world (WORLD_X) and the deme y-dimension is the y-dimension of the world divided by the number of demes (WORLD_Y/NUM_DEMES). So, for example, if you want 400, 5x5 demes, WORLD_X = 5, WORLD_Y=2000, NUM_DEMES=400. Demes are essentially placed in a long vertical line in the world. </li>
|
||||
<li><strong>How many demes should I use?</strong> Ug. This part gets a little tricky. By default, most of us have used 400, 5x5 demes. This provides a reasonable runtime on the HPC and only hogs 2 gigs of memory per node. More demes or larger demes consume proportionally more resources. </li>
|
||||
<li><strong>How do you populate demes at the start of a run?</strong> There are quite a few different inject options that work with demes. Two common ones are to use InjectAll, which injects the ancestor organism (controlled by the START_ORGANISM configuration option) into all cells in all demes, and InjectDemes, which injects the ancestor organism into one cell per deme. Check out the complete list of actions for more options. </li>
|
||||
</ul>
|
||||
|
||||
[[How to create a deme replication event]]
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
<p>Subpopulation migration in Avida is supported by the assignment of "migration weights" for connections between subpopulations. The migration "topology" between subpopulations is defined through reading in a connection-weight matrix in the following format: <br /> </p>
|
||||
<p># BEGIN<br /># All text beyond the '#' character in a file is a comment and will not be read in by Avida<br /># Subpop: [0] [1] [2] [3]<br /> <strong>5.0, 0.10, 0.0, 4.0</strong> # [0] Row[0].Sum = 9.10<br /> <strong>3.0, 0.20, 0.8, 2.0</strong> # [1] Row[1].Sum = 6.00<br /> <strong>7.0, 0.30, 0.0, 1.0</strong> # [2] Row[2].Sum = 8.30<br /> <strong>2.0, 1.30, 9.0, 0.0</strong> # [3] Rom[3].Sum = 12.30<br /># END</p>
|
||||
<p><span style="text-decoration: underline"><br />What this file means</span>: The above un-commented text shows a simple 4-line file with each line containing 4 comma-separated values. Each row in the connection matrix contains all the connection weights *from* subpopulation[row] to other subpopulations that are indexed by column. For example, the connection weight between Subpopulation[1] and Subpopulation[2] is 0.8 where the from-subpopulation is row index 1 and to-subpopulation is column index 2. By setting each of these weights, you can specify what the appropriate migration probability will be from a given subpopulation to another subpopulation. Internally, when a migration event is going to occur from a given subpopulation (let's assume Subpopulation[1]), Avida will sum up the values in row 1 of the connectivity matrix (3.0 + 0.20 + 0.8 + 2.0 = 6.00) and generate a random number between: 0 and Row[1].Sum. This random number will be used to determine which subpopulation the organism will migrate into using a "roulette selection" protocol where each connection is represented by its weight's proportion of the sum. As you may have noticed, the sum of a row does not have to equal 1.0 as a typical probability matrix does. The probability matrix would be an exclusive subset of the type of connectivity matrices you can use under this setup. <br /><span style="text-decoration: underline">Restrictions for this file (and why)</span>:</p>
|
||||
<ol>
|
||||
<li><strong><em>The number of rows must equal the number of demes which must equal the number of columns in each row </em></strong>- This assumes that you will provide a connection weight value for every subpopulation pair possible. This is easier to read for both us as researchers and the computer/programmer :)</li>
|
||||
<li><strong><em>A row's sum cannot equal 0.0</em></strong> - Minimally, there must be a path for migration to occur and the control/null case is that the organism remains in its own subpopulation. Therefore, to use the migration matrix but turn migration among subpopulations OFF, one can simply supply the identity matrix where the diagonal is the only non-zero value (or just not use the migration matrix method ). </li>
|
||||
<li><em><strong>A matrix entry cannot be negative</strong></em> - Intuitively, a negative migration value does not carry much meaning when trying to determine where an organism will migrate to and therefore, this will not be allowed.</li>
|
||||
</ol>
|
||||
<p> </p>
|
||||
<p>To turn on and use subpopulation migration, the following configuration parameters in <strong>*avida.cfg*</strong> will need to be set appropriately: </p>
|
||||
<p>(1) <strong>MIGRATION_FILE</strong> -- This config setting should be set to the migration file name that you want Avida to initialize with. Note: This file must be contained in the same working directory as your avida.cfg, events.cfg, and other Avida-related files. This setting is only used by Avida when the DEMES_MIGRATION_METHOD is set to use the migration matrix, otherwise a dummy value can be left here. </p>
|
||||
<p>(2) <strong>NUM_DEMES</strong> - This value specifies the total number of subpopulations in the run and it is *critical* that your MIGRATION_FILE's connectivity matrix have NUM_DEMES rows and that each row has NUM_DEMES columns. </p>
|
||||
<p>(3) <strong>DEMES_MIGRATION_RATE</strong> - This value can be between 0.0 and 1.0 and essentially specifies the "success rate" that a triggered migration event will actually take place. When set to 0.0, migration will *never* occur and when set to 1.0, a triggered migration rate will *always* succeed and use the DEMES_MIGRATION_METHOD. If this value was set to 0.50, for example, it would mean that a migration event would trigger but that 50% of the time the actual migration action would not occur. </p>
|
||||
<p>(4) <strong>DEMES_MIGRATION_METHOD</strong> - This config setting should be set to <strong>4</strong> to use the new connection matrix setup. Rather than the pre-built migration methods (Any other deme, Eight neighboring demes, Two adjacent demes in list, etc.), the "4" setting specifies to use the weights within the migration matrix to determine where an organism should migrate to. </p>
|
||||
<p> </p>
|
||||
<p><span style="text-decoration: underline"><strong>Deme Migration Events (can be added in your events.cfg)<br /></strong></span></p>
|
||||
<ul>
|
||||
<li><strong>SetMigrationMatrix</strong> - The SetMigrationMatrix event takes one argument/parameter which is the filename of a *new* migration matrix to be used to replace the current one. For example, if a user wanted to "turn off migration at update 10,000", he/she could add a line into events.cfg that reads as follows: "<em>u 10000 SetMigrationMatrix migration2.cfg</em>". At update 10,000, this event would be triggered causing the migration2.cfg file (containing connection values only on the diagonal) to be used. Note: This migration file must adhere to the restrictions stated above, otherwise Avida will report an error and exit mid-run.</li>
|
||||
<li><strong>AlterMigrationConnection</strong> - To provide more fine-grained control over how connection weights change, the AlterMigrationConnection event can be used in place of SetMigrationMatrix. This event takes *3* arguments: (1) from-index, (2) to-index, (3) alter_amount. When triggered, this event will go to the weight indexed by [from-index][to-index] and add the alter_amount value to the current weight. Naturally, if you wanted to decrease the current weight, you would simply make the alter_amount argument a negative value. By using the standard event protocol in Avida that has [start:interval:end], it is possible to cause a connection weight to change over a period of time by a certain amount. For example, if a user wanted to "<span style="text-decoration: underline">decrease</span> the connection between Subpopulation <span style="text-decoration: underline">0</span> and Subpopulation <span style="text-decoration: underline">1</span> by <span style="text-decoration: underline">3</span> units every <span style="text-decoration: underline">100</span> updates from update <span style="text-decoration: underline">10,000</span> to update <span style="text-decoration: underline">20,000</span><em>" </em>the corresponding event would be<em>: "u [10000:100:20000] AlterMigrationConnection 0 1 -3.0". </em>Note: Every time this event is triggered it will alter the last updated amount for that connection, if the matrix entry value goes negative or if the row's sum becomes 0.0, an error will be flagged and the run will exit. (This will likely need fixing in the future .. but for now keep it in mind)</li>
|
||||
<li><strong>DumpOffspringMigrationCounts</strong> - The DumpOffspringMigrationCounts action can be used to output how many organisms have migrated between the subpopulations (demes) in Avida. Each file that is outputted will appear in the data/ folder as follows: <em>counts_offspring_migration.[update].dat</em>. The [update] will contain the update # at which the file was dumped to the folder. The file is internally structured as a comma-separated (CSV) file containing a total of NUM_DEMES individual lines and each line containing NUM_DEMES comma-separated values (exactly like the MIGRATION_FILE). A 2D index into this CSV matrix (say the Yth CSV-value on line X) returns the number of offspring that migrated <span style="text-decoration: underline">from</span> subpopulation X <span style="text-decoration: underline">to</span> subpopulation Y. *Note*: After each dump, all migration counts are reset to zero, therefore, if you want the total number of migrations that occurred in the entire run, you would need to sum up the respective values across all files dumped. An example of this command is: <em>"u 100:200:end DumpOffspringMigrationCounts"</em> where the user wanted to "dump the offspring migration counts starting at update <span style="text-decoration: underline">100</span> for every <span style="text-decoration: underline">200</span> updates until the <span style="text-decoration: underline">end</span> of the run." </li>
|
||||
<li><strong>DumpParasiteMigrationCounts</strong> - The DumpParasiteMigrationCounts action can be used to output how many parasites have migrated between the subpopulations (demes) in Avida. Each file that is outputted will appear in the data/ folder as follows: <em>counts_parasite_migration.[update].dat</em>. The [update] will contain the update # at which the file was dumped to the folder. The file is internally structured as a comma-separated (CSV) file containing a total of NUM_DEMES individual lines and each line containing NUM_DEMES comma-separated values (exactly like the MIGRATION_FILE). A 2D index into this CSV matrix (say the Yth CSV-value on line X) returns the number of parasites that migrated from subpopulation X to subpopulation Y. *Note*: After each dump, all migration counts are reset to zero, therefore, if you want the total number of parasite migrations that occurred in the entire run, you would need to sum up the respective values across all files dumped. An example of this command is: <em>"u 100:200:end DumpParasiteMigrationCounts"</em> where the user wanted to "dump the parasite migration counts starting at update 100 for every 200 updates until the end of the run."</li>
|
||||
</ul>
|
||||
<div>Hopefully this wiki article is of benefit for others who want to explore migration using Avida. If you have any questions/comments about the implementation, please feel free to contact me (Chad Byers) at byerscha@msu.edu </div>
|
||||
<div> </div>
|
||||
<div><strong>For Developers: </strong>To see <span style="text-decoration: underline">where</span>, in the source files, that updates/revisions have been made to support subpopulation migration, use the *Find All* feature in your IDE and search for "MIGRATION_MATRIX"</div>
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
We welcome all those interested to contribute to the development and improvement of the Avida project. This developer’s guide will describe how to get started, the guidelines for contributions, and where to find ideas for what is needed.
|
||||
|
||||
## Project Structure
|
||||
Avida consists of several modules/sub-projects.
|
||||
|
||||
* [Avida-Core Library](Development-|-avida-core)
|
||||
* [Avida-Viewer Library](Development-|-avida-viewer)
|
||||
* [Avida2 Frontend](Development-|-avida2)
|
||||
* [The OS X/iOS Viewers](Development-|-viewer-macos)
|
||||
* [The Windows Viewer](Development-|-viewer-windows)
|
||||
|
||||
### [Getting Started](Development-|-Getting-Started)
|
||||
### [Coding Style Guide](Development-|-Coding-Style-Guide)
|
||||
|
||||
|
||||
## Mini Tutorials
|
||||
* [A Conceptual Introduction to C++](Development-|-Tutorial-|-C-Plus-Plus-Intro)
|
||||
* [Guide to the Death/Birth Cycle](Development-|-Tutorial-|-Birth-Death-Cycle)
|
||||
* [Guide to an Avida Organism Life Cycle](Development-|-Tutorial-|-Life-Cycle)
|
||||
* [The Building Blocks of the Virtual CPU](Development-|-Tutorial-|-Genome)
|
||||
* [The Environment Source Code](Development-|-Tutorial-|-Environment)
|
||||
* [Instruction Implemention Checklist](Development-|-Tutorial-|-Instruction-Checklist)
|
||||
* [Environment Task Implementation Checklist](Development-|-Tutorial-|-Task-Checklist)
|
||||
|
|
@ -0,0 +1,303 @@
|
|||
<p>
|
||||
This document discusses how to implement your own instructions.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>1. Build the method to be attached to the new instruction</h2>
|
||||
|
||||
<p>
|
||||
For this first step, you will be editing the virtual CPU definition in
|
||||
<kbd>cHardwareCPU.h</kbd> and <kbd>cHardwareCPU.cc</kbd>, both of which are
|
||||
found in the directory <kbd>source/cpu/</kbd>. Start by going to the
|
||||
final section of the class definition in the header file and writing
|
||||
the declaration for the new method that will be called whenever the
|
||||
instruction is executed. For example, if you were going to add the
|
||||
instruction <code>minus-17</code> (which performs the oh-so-useful behavior
|
||||
of subtracting 17 from the ?BX? register), you would add the line:
|
||||
</p>
|
||||
<pre>
|
||||
bool <span class="method">Inst_Minus17</span>(<span class="class">cAvidaContext</span>& <span class="object">ctx</span>);
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If possible, place it near other instructions of the same type. There are
|
||||
about a hundred methods cHardwareCPU. This instruction would likely fit best
|
||||
with the group of instruction described as "Single-Argument Math".
|
||||
That is, all those instructions that perform mathematical operation that only
|
||||
affect a single register.
|
||||
</p>
|
||||
<p>
|
||||
All methods associated with instructions return a
|
||||
<span class="class">bool</span> value that determines if it was
|
||||
successfully executed. Most instructions will always return true since they
|
||||
have no way to fail. The convention that we use to designate a method
|
||||
explicitly associated with an instruction is placing a prefix of
|
||||
<code>Inst_</code> in front of it.
|
||||
</p>
|
||||
<p>
|
||||
Next, you have to write the function body in the code file
|
||||
(<kbd>cHardwareCPU.cc</kbd>). The method bodies will be listed at the end of
|
||||
this file in the same order that they were declared in the header. You would
|
||||
find the proper position, and write something to the effect of:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
bool <span class="class">cHardwareCPU</span>::<span class="method">Inst_Minus17</span>(<span class="class">cAvidaContext</span>& <span class="object">ctx</span>)
|
||||
{
|
||||
const <span class="class">int</span> <span class="object">reg_used</span> = <span class="method">FindModifiedRegister</span>(REG_BX);
|
||||
<span class="method">GetRegister</span>(<span class="object">reg_used</span>) -= 17;
|
||||
return true;
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The first line of this method uses a helper function called
|
||||
<span class="method">FindModifiedRegister</span>() to identify the register
|
||||
that should be affected (it scans the next instruction to test if it is a
|
||||
<code>nop</code>), with a default value of <code>REG_BX</code> passed in.
|
||||
The second line then subtracts 17 from the value in that register. The
|
||||
constant values and available helper functions will be described in more
|
||||
detail below, as will a guide to accessing the components in the virtual
|
||||
CPU. For the moment, you have finished implementing the method!
|
||||
</p>
|
||||
<p>
|
||||
Note that this would be a good time to recompile if you want to test how
|
||||
well your implementation is going so far.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>2. Link the instruction name to its method</h2>
|
||||
|
||||
For this step, you will need to edit the code file. You would go into the method
|
||||
<span class="class">cHardwareCPU</span>::<span class="method">initInstLib</span>(void)
|
||||
and add in the line
|
||||
|
||||
<pre>
|
||||
<span class="class">cInstEntryCPU</span>("minus-17", &<span class="class">cHardwareCPU</span>::<span class="method">Inst_Minus17</span>);
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
in the same order that it was defined in the class definition.
|
||||
</p>
|
||||
<p>
|
||||
Since we want to use a pointer to the appropriate method, that is what we
|
||||
must pass into the dictionary. To obtain said pointer, we must list the class
|
||||
the function is part of (<span class="class">cHardwareCPU</span>) follow it
|
||||
by a double colon (::) and then give the method name
|
||||
(<span class="method">Inst_Minus17</span>) <em>without</em> the normal
|
||||
parentheses following it. The parentheses indicate that we should execute
|
||||
the method. Without them, it is just the data that represents the method,
|
||||
and by preceding this whole mess with an ampersand ('&') we get the pointer
|
||||
to the location in memory that the method resides.
|
||||
</p>
|
||||
<p>
|
||||
<b>IMPORTANT:</b> If your instruction interacts with the population, resources,
|
||||
or IO, make sure to flag the instruction for speculative stall by adding a third
|
||||
argument, <i>nInstFlags::STALL</i>. For an example, look at the 'h-divide'
|
||||
instruction.
|
||||
</p>
|
||||
<p>
|
||||
Compile again, and you should have your instruction ready for use.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>3. Add the entry to your instruction set and test it!</h2>
|
||||
|
||||
<p>
|
||||
This last part should be the easiest. If you want the new instruction you
|
||||
just created to be loaded on startup, you must add a line in the instruction
|
||||
set you are using (specified in the configuration file) to indicate its
|
||||
inclusion:
|
||||
</p>
|
||||
<pre>
|
||||
minus-17 1
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
And there you have it! Now the real trick is to test if its working
|
||||
properly. I'd recommend using as a framework the creature
|
||||
<kbd>default-classic.org</kbd> and modifying some of the long series of
|
||||
<code>nop-C</code> instructions inside of it to perform some math using the
|
||||
new instruction (only the very first <code>nop-C</code> cannot be changed). You
|
||||
can then either go into zoom mode in the viewer and step through the creature,
|
||||
or else use analyze mode trace its execution. If you are going to use zoom
|
||||
mode, setup your modified creature as the START_CREATURE in configuration file.
|
||||
If you want to use analyze mode, put the following lines into the
|
||||
<code>analyze.cfg</code> file in your work/ directory:
|
||||
|
||||
<pre>
|
||||
LOAD_ORGANISM inst_test.org
|
||||
TRACE
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Where you have to replace <kbd>inst_test.org</kbd> with the name of the
|
||||
organism you want to trace. The new file will appear in the
|
||||
<kbd>data/archive/</kbd> directory, with the same name as the one you loaded
|
||||
in, but a <kbd>.trace</kbd> appended to the end.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h3>CPU Components</h3>
|
||||
|
||||
<p>
|
||||
Various CPU components are often manipulated by instructions, and we
|
||||
need a standard way of doing this. We have settled on each component being
|
||||
associated with a method to access it, to provide a single location that can
|
||||
control that access. This has already been useful -- in a multi-threaded
|
||||
CPU (i.e., a CPU that has multiple positions in its genome being executed at
|
||||
the same time) each thread has its own registers and heads, so we need to
|
||||
always be sure we are manipulating the component of the active thread. If
|
||||
you simply use the following methods, they will always find the correct
|
||||
component for you.
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt>
|
||||
<pre>
|
||||
void <span class="method">StackPush</span>(<span class="class">int</span> <span class="object">value</span>);
|
||||
<span class="class">int</span> <span class="method">StackPop</span>();
|
||||
void <span class="method">SwitchStack</span>();
|
||||
</pre>
|
||||
</dt>
|
||||
<dd>
|
||||
There are two stacks in a normal CPU, and more in a multi-threaded version
|
||||
(one global stack, and one local to each thread). The first stack method will
|
||||
place a new value on the top of the currently active stack, the second will
|
||||
remove the top value, and the last will toggle the currently active stack.
|
||||
</dd>
|
||||
<dt>
|
||||
<pre>
|
||||
<span class="class">cCPUHead</span>& <span class="method">GetHead</span>(int <span class="object">head_id</span>);
|
||||
<span class="class">cCPUHead</span>& <span class="method">IP</span>();</pre>
|
||||
</dt>
|
||||
<dd>
|
||||
Each thread in a CPU has four heads associated with it, designated by the
|
||||
constants <code>HEAD_IP</code>, <code>HEAD_READ</code>,
|
||||
<code>HEAD_WRITE</code>, and <code>HEAD_FLOW</code>. These heads each point
|
||||
to a position in memory, and all have their own purpose. A head can be
|
||||
accessed by passing the appropriate constant into the GetHead() method. The
|
||||
extra method IP() was added to more easily obtain just the instruction pointer.
|
||||
The IP is a very special head since it designates what instruction is going to
|
||||
be executed next, and often it will make code clearer if you obtain it by
|
||||
calling IP(). (It will show that you need to make sure of the special
|
||||
qualities of the instruction pointer.)
|
||||
</dd>
|
||||
<dt>
|
||||
<pre>
|
||||
int& <span class="method">Register</span>(int <span class="object">reg_id</span>);
|
||||
</pre>
|
||||
</dt>
|
||||
<dd>
|
||||
There are three registers available, associated with the constants
|
||||
<code>REG_AX</code>, <code>REG_BX</code>, and <code>REG_CX</code>. If the
|
||||
Register() method is called, an integer reference will be returned associated
|
||||
with that register. Any change to this integer will make a corresponding
|
||||
change to the register in question.
|
||||
</dd>
|
||||
<dt>
|
||||
<pre>
|
||||
<span class="class">cCPUMemory</span>& <span class="method">GetMemory</span>();
|
||||
</pre>
|
||||
</dt>
|
||||
<dd>
|
||||
This method allows the programmer to access the full memory of the CPU. As
|
||||
you know, the class cCPUMemory is built on top of Genome, so you can
|
||||
manipulate it in all of the same ways.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
These are only a sampling of the available methods of interacting with the
|
||||
components of the CPU, but they give you a good cross-section without
|
||||
overwhelming you with all of the possibilities. You should look through the
|
||||
source files if you want to see the other options that are available to you.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Helper Methods</h2>
|
||||
|
||||
<p>
|
||||
There are several very common tasks that are performed during the execution
|
||||
of many of the instructions. For each of these tasks we have created a
|
||||
helper function to ease the creation of new instructions.
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt>
|
||||
<pre>
|
||||
void <span class="method">ReadLabel</span>();
|
||||
<span class="class">cCodeLabel</span>& <span class="method">GetLabel</span>();
|
||||
<span class="class">cCPUHead</span> <span class="method">FindLabel</span>(int <span class="object">direction</span>);
|
||||
</pre>
|
||||
</dt>
|
||||
<dd>
|
||||
ReadLabel() will read in the label (series of nop instructions) that
|
||||
immediately follows the instruction being executed. The label that was read
|
||||
can then be accessed (and even modified) using GetLabel(). Finally, the
|
||||
Findlabel() method takes single int argument that determines the direction
|
||||
(from the instruction pointer) in which the label should be search for. If
|
||||
this argument is a 1 it will search forward, and if its a -1, it will search
|
||||
backwards. A zero indicates that the search should start from the beginning
|
||||
of the genome, and proceed to the end. Once it finds the matching label, it
|
||||
will return a head at the position in which the label was found. These
|
||||
helper methods are particularly useful in any instruction that has to affect
|
||||
other portions of the source code. See the method Inst_HeadSearch for an
|
||||
example of how these are used.
|
||||
</dd>
|
||||
<dt>
|
||||
<pre>
|
||||
int <span class="method">FindModifiedRegister</span>(int <span class="object">default_register</span>);
|
||||
int <span class="method">FindModifiedHead</span>(int <span class="object">default_head</span>);
|
||||
</pre>
|
||||
</dt>
|
||||
<dd>
|
||||
These two methods will look ahead and determine if a nop instruction is
|
||||
immediately following the instruction being executed. If so, it will return
|
||||
the register or head ID associated with that nop (for use in the rest of the
|
||||
method), and if no nop is found, it will automatically return the
|
||||
default value passed in. We used FindModifiedRegister in the example new
|
||||
instruction above.
|
||||
</dd>
|
||||
<dt>
|
||||
<pre>
|
||||
int <span class="method">FindComplementRegister</span>(int <span class="object">base_reg</span>);
|
||||
</pre>
|
||||
</dt>
|
||||
<dd>
|
||||
Several instructions are defined as affecting a certain, modifiable register
|
||||
and its complement. In order to have a standard way of determining the
|
||||
complement of a register (which, by default, cycle in the same order as
|
||||
complement labels), we use this function whenever we need to determine one.
|
||||
See, for example, see the definition of Inst_IfNEqu().
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Problem</h2>
|
||||
|
||||
<p>
|
||||
To test your understanding of adding instruction into Avida, try writing two
|
||||
new instructions. The first one is the mathematical instruction
|
||||
<strong><code>cube</code></strong> that will take the ?BX? register, and put
|
||||
its value to the third power. If you look in the actual source files, you
|
||||
will see that there is already a <code>square</code> instruction that you can
|
||||
model this on.
|
||||
</p>
|
||||
<p>
|
||||
Next, you will implement the instruction <strong><code>if-twice</code></strong>
|
||||
that will execute the next instruction if-and-only-if the value in the ?BX?
|
||||
register is twice that of the value in its complement. In other words by
|
||||
default, if would test of BX was twice CX, but if it is followed by a
|
||||
<code>nop-C</code> it will test if CX is twice AX.
|
||||
</p>
|
||||
<p>
|
||||
For both of these instruction make sure to craft an organism to test that
|
||||
they are working properly!
|
||||
</p>
|
||||
|
|
@ -0,0 +1,298 @@
|
|||
<p>
|
||||
This document describes the coding standards that should be followed
|
||||
when developing within Avida.
|
||||
</p>
|
||||
|
||||
|
||||
## C/C++ Dialect
|
||||
<ul>
|
||||
<li>ISO Standard C++ (1998/2003)</li>
|
||||
<li>Do not use GCC extensions (such as multi-line strings and comments).</li>
|
||||
<li>No compiler warnings with explicitly supported compilers, including GCC and Clang-LLVM.</li>
|
||||
</ul>
|
||||
|
||||
|
||||
## Code Formatting
|
||||
|
||||
<h3>Indentation</h3>
|
||||
<ul>
|
||||
<li>
|
||||
All source code indentation should be spaces. This includes C++, Python,
|
||||
and HTML.
|
||||
</li>
|
||||
<li>
|
||||
The size of a single indentation is 2 spaces.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h3>Braces</h3>
|
||||
|
||||
<div style="margin-left: 10px">
|
||||
<h4>Function Definitions</h4>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
Open and close braces should each be on their own line. Do not
|
||||
place the open brace on the same line as the function signature. The only
|
||||
exception to this rule is single line class methods, in which both braces
|
||||
are allowed to be on the same line as the code (but only in pairs). Examples:
|
||||
</p>
|
||||
<h5 class="method">Right:</h5>
|
||||
<pre>
|
||||
void cFoo::Method()
|
||||
{
|
||||
// code goes here
|
||||
}
|
||||
|
||||
// ... in a class
|
||||
inline void Method() { ; }
|
||||
|
||||
inline void Method()
|
||||
{ // longer code in here }
|
||||
</pre>
|
||||
<h5 class="class">Wrong:</h5>
|
||||
<pre>
|
||||
void cFoo::Method() {
|
||||
// code goes here
|
||||
}
|
||||
|
||||
// ... in a class
|
||||
inline void Method() {
|
||||
; }
|
||||
</pre>
|
||||
|
||||
</div>
|
||||
|
||||
<h4>For, While, Do Loops and Switch Statements</h4>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
The open brace should go on the same line as the control structure,
|
||||
the close brace on its own line. Examples:
|
||||
</p>
|
||||
<h5 class="method">Right:</h5>
|
||||
<pre>
|
||||
while (foo) {
|
||||
// code goes here
|
||||
}
|
||||
</pre>
|
||||
<h5 class="class">Wrong:</h5>
|
||||
<pre>
|
||||
while (foo)
|
||||
{
|
||||
}
|
||||
</pre>
|
||||
|
||||
</div>
|
||||
|
||||
<h4>If/Else Statements</h4>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
The same formatting rules as for/while/etc., but if there is an else clause
|
||||
the close brace should go on the same line as the else statement. Single
|
||||
line if else statements should not get braces, unless they accompany a
|
||||
multi-line statement. Examples:
|
||||
</p>
|
||||
<h5 class="method">Right:</h5>
|
||||
<pre>
|
||||
if (foo) {
|
||||
DoSomething();
|
||||
DoAnotherSomething();
|
||||
} else {
|
||||
DoADifferentSomthing();
|
||||
}
|
||||
|
||||
if (!foo) CallAFunction();
|
||||
else CallBFunction();
|
||||
</pre>
|
||||
<h5 class="class">Wrong:</h5>
|
||||
<pre>
|
||||
if (foo)
|
||||
{
|
||||
DoSomething();
|
||||
DoAnotherSomething();
|
||||
} else
|
||||
DoADifferentSomthing();
|
||||
|
||||
if (!foo) {
|
||||
CallAFunction();
|
||||
}
|
||||
else CallBFunction();
|
||||
</pre>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h3>Parentheses</h3>
|
||||
<div style="margin-left: 10px">
|
||||
<h4>Function Declarations and Calls</h4>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
Do not use any space between the name and the open parenthesis, inside the
|
||||
parentheses, or before commas that separate arguments. A single space
|
||||
should follow commas that separate arguments. Examples:
|
||||
</p>
|
||||
<h5 class="method">Right:</h5>
|
||||
<pre>
|
||||
void cFoo::Method(int arg1, double arg2);
|
||||
int aFunction();
|
||||
</pre>
|
||||
<h5 class="class">Wrong:</h5>
|
||||
<pre>
|
||||
void cFoo::Method( int arg1 , double arg2 );
|
||||
void cFoo::Method (int arg1, double arg2);
|
||||
int Function ( );
|
||||
</pre>
|
||||
|
||||
</div>
|
||||
|
||||
<h4>Control Structures</h4>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
Control structures such as if, for, while, do, and switch statements use a
|
||||
single space before the open parenthesis, but spaces inside them.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h3>Other Punctation</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Pointer and reference types should be written with <strong>NO</strong> space
|
||||
between the type name and the * or &.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h3>Include Guards and Statements</h3>
|
||||
<ul>
|
||||
<li>
|
||||
All header files must use include guards, where the name of the guard is
|
||||
exactly the filename with the period replaced with an underscore. For
|
||||
example, <kbd>cPopulation.h</kbd> is guarded by:
|
||||
<pre>
|
||||
#ifndef cPopulation_h
|
||||
#define cPopulation_h
|
||||
|
||||
// Code goes here
|
||||
|
||||
#endif
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
Include statements in header (<kbd>.h</kbd>) and implementation (<kbd>.cc</kbd>) files must
|
||||
<strong>not</strong> check include guards (no <kbd>#ifndef</kbd> blocks). This compile time
|
||||
optimization is to be left for the compiler to perform.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Variable names should be all lowercase. Multi-word variables should have the
|
||||
words separated by underscores ('_'). Examples:
|
||||
<pre>
|
||||
i
|
||||
position
|
||||
this_is_my_var
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
Class instance member variables should have the same format as regular
|
||||
variables, but must be prefixed with 'm_'. Examples:
|
||||
<pre>
|
||||
m_type
|
||||
m_lexeme
|
||||
m_my_component
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
All functions and public struct/class methods should begin with a capital
|
||||
letter followed by lowercase. Additional words should be signified by
|
||||
capital letters. Underscores should only be used to indicate a category
|
||||
of functions. Examples:
|
||||
<pre>
|
||||
Sort()
|
||||
ThisIsMyFunction()
|
||||
cHardwareCPU::SingleProcess()
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
Private and protected struct/class support methods should begin with a
|
||||
lowercase letter. Additional words should be signified by capital letters.
|
||||
Underscores should only be used to indicate a category of functions. Examples:
|
||||
<pre>
|
||||
cHardwareBase::doSlipMutation()
|
||||
cParser::parseCodeBlock()
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
All class names should begin capital letters leading each word (similar to functions). Examples:
|
||||
<pre>
|
||||
Genome
|
||||
Array
|
||||
HeadTypes
|
||||
SomeData
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
All constant values (even as listed in enumerations) should be in all
|
||||
capital letters, with words separated by underscores. Examples:
|
||||
<pre>
|
||||
NUM_REGISTERS
|
||||
MAX_STRING_LENGTH
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
All filenames should be the same as the class defined within that file.
|
||||
Header files should use <kbd>.h</kbd>; implementation files should use
|
||||
<kbd>.cc</kbd>.
|
||||
Examples:
|
||||
<pre>
|
||||
Genome.h
|
||||
Array.h
|
||||
Population.cc
|
||||
</pre>
|
||||
</li>
|
||||
<li>
|
||||
Generally, there should only be one class defined in each header/source
|
||||
file pair. Implementation helper classes should be defined as internal
|
||||
class members.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Class Dependency Guidelines</h2>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
Some groupings of classes should maintain important limitations with respect
|
||||
to class dependency.
|
||||
</p>
|
||||
|
||||
<h3>Tools Classes</h3>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
All classes developed as general utility classes should be placed within the
|
||||
<kbd style="color: #008844">source/tools</kbd> directory. These classes
|
||||
should have no dependencies that extend outside of this directory.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<h3>STL Usage</h3>
|
||||
<div style="margin-left: 10px">
|
||||
<p>
|
||||
Usage of the Standard Template Library should be very limited. A number of
|
||||
these templates have unspecified orderings that can vary across platforms,
|
||||
affecting consistency. Where possible, it is greatly preferred to use the
|
||||
local tools classes.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
These instructions will guide you through the process of setting up tools, obtaining the source code, building the suite, and provide an overview of the source code structure.
|
||||
|
||||
## Development Tools
|
||||
Avida is a cross platform project designed to work on most POSIX-compliant systems, such as Linux, Mac OS X, Unix-variants, and Windows. You will need a development environment for your platform, such as GCC on Linux, Microsoft Visual Studio on Windows, and Apple Xcode on Mac OS X. The cross platform build system uses <a href="http://cmake.org">CMake</a>, version 2.6 or greater, to generate platform specific build files. In order to obtain the source code, you will need a recent copy of <a href="http://git-scm.com">Git</a>.
|
||||
|
||||
## Getting the Source Code
|
||||
The Avida project uses multiple Git repositories to manage the source code. If you are new to Git, see <a href="http://avida.devosoft.org/devguide/using-git/">Using Git</a> for an overview of basic usage. When developing in Avida, you should always work from a working copy of the Git repository to ensure that you may stay up to date with recent changes. To clone the master Avida repository, move to the directory where you want to store the clone and run the following:
|
||||
<pre>$ git clone https://github.com/devosoft/avida.git</pre>
|
||||
Note, however, that the Avida project uses the Apto library linked as a submodule. You must initialize the submodule following the clone command above before you will be able to build the project:
|
||||
<pre>$ cd avida
|
||||
$ git submodule init
|
||||
$ git submodule update</pre>
|
||||
At this point you should be able to proceed to compiling.
|
||||
|
||||
## Compiling
|
||||
### Unix Command Line - CMake
|
||||
You will need a copy of <a href="http://cmake.org/">CMake</a>.
|
||||
<ol>
|
||||
<li>At the top level of the source code run the <code>./build_avida </code>script.</li>
|
||||
<ul><li>To compile the avida-viewer, use the flag <code>-DAVD_GUI_NCURSES</code> with <code>./build_avida</code></li></ul>
|
||||
<li>Change into the directory <code>cbuild/work</code></li>
|
||||
<li>The compiled executables (avida, avida-viewer), as well as the sample configuration files will be present in the work directory.</li>
|
||||
</ol>
|
||||
### Mac OS X - Xcode
|
||||
<ol>
|
||||
<li>Open the Avida.xcodeworkspace file in the top level of the source code.</li>
|
||||
<li>Select the <em>avida</em> build scheme in the top left of the workspace window.</li>
|
||||
<li>Select menu option Product > Archive</li>
|
||||
<li>"Distribute..." the archive, "Save Built Products"</li>
|
||||
<li>The archive contents will contain the executable in <kbd>/usr/local/bin/avida</kbd> and the example configuration files in <kbd>/usr/local/share/avida</kbd></li>
|
||||
</ol>
|
||||
|
||||
### Windows - Visual Studio
|
||||
<ol>
|
||||
<li>Open the CMake GUI</li>
|
||||
<li>Select the top level <em>avida</em> source code directory for the "Where is the source code" option.</li>
|
||||
<li>Specify a director to build the project files and binaries. It is recommended that you create a new empty directory for this path.</li>
|
||||
<li>Select your desired development system (Visual Studio version), if prompted or necessary.</li>
|
||||
<li>Click Configure twice, then click Generate to generate the project files.</li>
|
||||
<li>Open the generated Visual Studio solution file that should now be in your build folder.</li>
|
||||
<li>Build the solution (build the install target, don't use build all).</li>
|
||||
<li>You should find a <em>work</em> directory in your build folder containing the avida.exe and default configuration files.</li>
|
||||
</ol>
|
||||
Some other notes:
|
||||
<ol>
|
||||
<li>In the options panel only APTO_LIB_SHARED, APTO_LIB_STATIC and AVD_CMDLINE should be 'On'. The viewer does not appear to build on Windows at the moment.</li>
|
||||
<li>Can't find the executable? Check the bin/DEBUG or bin/RELEASE directories.</li>
|
||||
</ol>
|
||||
|
||||
## Project Structure
|
||||
The Avida project master repository has been organized in the structure described below. This overview should help locate where the sub-projects you are interested in may be found. See specific sub-project pages for further information.
|
||||
|
||||
<dl><dt>Applications - <kbd>/apps</kbd></dt><dd><dl><dt>Mac OS Viewer - <kbd>/apps/viewer-macos</kbd> </dt><dd>Cocoa-based GUI application supporting Avida and Avida-ED</dd></dl></dd><dt>Avida Core - <kbd>/avida-core</kbd> </dt><dd>The <a href="http://avida.devosoft.org/devguide/projects/avida-core">avida-core</a> and <a href="http://avida.devosoft.org/devguide/projects/avida-viewer">avida-viewer</a> libraries. The heart of Avida.</dd><dt>Libraries - <kbd>/libs</kbd></dt><dd><dl><dt>Apto - <kbd>/libs/apto</kbd> <em>submodule</em></dt><dd>Apto C++ tools library. Data structures and cross-platform support layer.</dd></dl></dd></dl>
|
||||
|
||||
## Contributing to the Repositories
|
||||
There are two main ways to contribute code changes to the repositories of the Avida project. The community at large is encouraged to fork the repositories on <a href="http://github.com/devosoft/avida/">GitHub</a> and to submit pull requests as appropriate. More details about using GitHub is available on their site.
|
||||
|
||||
Core developers who have been granted direct push access will need to utilize the authenticated remote repository path. The authenticated repository is <code>git@github.com:devosoft/avida.git</code>. If you are working from a standard clone of the source code, you may update your <em>push</em> URLs with the following commands:
|
||||
<pre>$ git remote set-url --push origin git@github.com:devosoft/avida.git</pre>
|
||||
|
|
@ -0,0 +1,228 @@
|
|||
<p>
|
||||
This document describes the interaction between organisms and the population.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>The Death of an Organism</h2>
|
||||
|
||||
<p>
|
||||
When an organism is killed off, its location in the population (that is, its
|
||||
population cell) needs to be emptied, the scheduler needs to be notified, and
|
||||
various statistics need to be updated to reflect the recently deceased. All of
|
||||
this is handled with the method below. In a default Avida setup, this method
|
||||
will only be called when a cell needs to be cleared out for a new occupant,
|
||||
but you've already seen this method used when you implemented the kill-related
|
||||
events in a previous homework. We'll see it also called from code displayed in
|
||||
the next section of this document.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
void <span class="class">cPopulation</span>::<span class="method">KillOrganism</span>(<span class="class">cPopulationCell</span>& <span class="object">in_cell</span>)
|
||||
{
|
||||
<span class="comment">// do we actually have something to kill?</span>
|
||||
if (<span class="object">in_cell</span>.<span class="method">IsOccupied</span>() == false) return;
|
||||
|
||||
<span class="comment">// Statistics...</span>
|
||||
<span class="class">cOrganism</span>* <span class="object">organism</span> = <span class="object">in_cell</span>.<span class="method">GetOrganism</span>();
|
||||
<span class="class">cGenotype</span>* <span class="object">genotype</span> = <span class="object">organism</span>-><span class="method">GetGenotype</span>();
|
||||
<span class="object">m_world</span>-><span class="method">GetStats</span>().<span class="method">RecordDeath</span>();
|
||||
|
||||
<span class="object">num_organisms</span>--;
|
||||
<span class="object">genotype</span>-><span class="method">RemoveOrganism</span>();
|
||||
|
||||
<span class="comment">// And clear it!</span>
|
||||
<span class="object">in_cell</span>.<span class="method">RemoveOrganism</span>();
|
||||
if (!<span class="object">organism</span>-><span class="method">GetIsRunning</span>()) delete <span class="object">organism</span>;
|
||||
else <span class="object">organism</span>-><span class="method">GetPhenotype</span>().<span class="method">SetToDelete</span>();
|
||||
|
||||
<span class="comment">// Alert the scheduler that this cell has a 0 merit.</span>
|
||||
<span class="object">schedule</span>-><span class="method">Adjust</span>(<span class="object">in_cell</span>.<span class="method">GetID</span>(), <span class="class">cMerit</span>(0));
|
||||
|
||||
<span class="comment">// Update the archive (note: genotype adjustment may be deferred)</span>
|
||||
<span class="object">m_world</span>-><span class="method">GetClassificationManager</span>().<span class="method">AdjustGenotype</span>(*<span class="object">genotype</span>);
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This method takes as an argument the cell that needs to be emptied. It starts
|
||||
off by making sure that the cell in question actually has an organism in it to
|
||||
be killed. If not, it stops right there. If so, it records some statistics
|
||||
about that organism's life, and updates its counter of living organisms to
|
||||
reflect that there is one fewer.
|
||||
</p>
|
||||
<p>
|
||||
Once the statistics are finished, the cell itself is cleared with the
|
||||
<span class="class">cPopulationCell</span>::<span class="method">RemoveOrganism</span>()
|
||||
method (in which the pointer to the organism it once contained is set to NULL).
|
||||
At this point if the organism is not the currently running CPU it will be
|
||||
deleted. Otherwise, a flag is set that marks the organism for deletion after
|
||||
the current instruction has finished executing. Finally, the scheduler (which
|
||||
is the object that doles out CPU cycles to the individual organisms) is updated
|
||||
to reflect that this cell is now empty.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Activating an Organism in a Specific Cell</h2>
|
||||
|
||||
<p>
|
||||
If an organism is going to be placed into a specific cell of the population,
|
||||
the method ActivateOrganism can be called on the population, telling it the
|
||||
location in memory of the organism to be placed and the cell to place it in.
|
||||
This method will call the <span class="method">KillOrganism</span>() method
|
||||
to make sure the cell is unoccupied. This method is called from the
|
||||
<span class="method">Inject</span>() method as well as
|
||||
<span class="method">ActivateOffspring</span>(), described below.
|
||||
Here is the ActivateOrganism method:
|
||||
|
||||
<pre>
|
||||
void <span class="class">cPopulation</span>::<span class="method">ActivateOrganism</span>(<span class="class">cAvidaContext</span>& <span class="object">ctx</span>, <span class="class">cOrganism</span>* <span class="object">in_organism</span>, <span class="class">cPopulationCell</span>& <span class="object">target_cell</span>)
|
||||
{
|
||||
<span class="object">in_organism</span>-><span class="method">SetOrgInterface</span>(new <span class="class">cPopulationInterface</span>(<span class="object">m_world</span>));
|
||||
|
||||
<span class="comment">// If the organism does not have a genotype, give it one! No parent</span>
|
||||
<span class="comment">// information is provided so we must set parents to NULL.</span>
|
||||
if (<span class="object">in_organism</span>-><span class="method">GetGenotype</span>() == NULL) {
|
||||
<span class="class">cGenotype</span>* <span class="object">new_genotype</span> = <span class="object">m_world</span>-><span class="method">GetClassificationManager</span>().<span class="method">GetGenotype</span>(<span class="object">in_organism</span>-><span class="method">GetGenome</span>(), NULL, NULL);
|
||||
<span class="object">in_organism</span>-><span class="method">SetGenotype</span>(<span class="object">new_genotype</span>);
|
||||
}
|
||||
<span class="class">cGenotype</span>* <span class="object">in_genotype</span> = <span class="object">in_organism</span>-><span class="method">GetGenotype</span>();
|
||||
|
||||
<span class="comment">// Save the old genotype from this cell...</span>
|
||||
<span class="class">cGenotype</span>* <span class="object">old_genotype</span> = NULL;
|
||||
if (<span class="object">target_cell</span>.<span class="method">IsOccupied</span>()) {
|
||||
<span class="object">old_genotype</span> = <span class="object">target_cell</span>.<span class="method">GetOrganism</span>()-><span class="method">GetGenotype</span>();
|
||||
|
||||
<span class="comment">// Sometimes a new organism will kill off the last member of its genotype</span>
|
||||
<span class="comment">// in the population. Normally this would remove the genotype, so we</span>
|
||||
<span class="comment">// want to defer adjusting that genotype until the new one is placed.</span>
|
||||
<span class="object">old_genotype</span>-><span class="method">IncDeferAdjust</span>();
|
||||
}
|
||||
|
||||
<span class="comment">// Update the contents of the target cell.</span>
|
||||
<span class="method">KillOrganism</span>(<span class="object">target_cell</span>);
|
||||
<span class="object">target_cell</span>.<span class="method">InsertOrganism</span>(*<span class="object">in_organism</span>);
|
||||
|
||||
<span class="comment">// Update the archive...</span>
|
||||
<span class="object">in_genotype</span>-><span class="method">AddOrganism</span>();
|
||||
|
||||
if (<span class="object">old_genotype</span> != NULL) {
|
||||
<span class="object">old_genotype</span>-><span class="method">DecDeferAdjust</span>();
|
||||
<span class="object">m_world</span>-><span class="method">GetClassificationManager</span>().<span class="method">AdjustGenotype</span>(*<span class="object">old_genotype</span>);
|
||||
}
|
||||
<span class="object">m_world</span>-><span class="method">GetClassificationManager</span>().<span class="method">AdjustGenotype</span>(*<span class="object">in_genotype</span>);
|
||||
|
||||
<span class="comment">// Initialize the time-slice for this new organism.</span>
|
||||
<span class="object">schedule</span>-><span class="method">Adjust</span>(<span class="object">target_cell</span>.<span class="method">GetID</span>(), <span class="object">in_organism</span>-><span class="method">GetPhenotype</span>().<span class="method">GetMerit</span>());
|
||||
|
||||
<span class="comment">// Special handling for certain birth methods.</span>
|
||||
if (<span class="object">m_world</span>-><span class="method">GetConfig</span>().<span class="object">BIRTH_METHOD</span>.<span class="method">Get</span>() == POSITION_CHILD_FULL_SOUP_ELDEST) {
|
||||
<span class="object">reaper_queue</span>.<span class="method">Push</span>(&<span class="object">target_cell</span>);
|
||||
}
|
||||
|
||||
<span class="object">num_organisms</span>++;
|
||||
|
||||
<span class="comment">// Statistics...</span>
|
||||
<span class="object">m_world</span>-><span class="method">GetStats</span>().<span class="method">RecordBirth</span>(<span class="object">target_cell</span>.<span class="method">GetID</span>(), <span class="object">in_genotype</span>-><span class="method">GetID</span>(),
|
||||
<span class="object">in_organism</span>-><span class="method">GetPhenotype</span>().<span class="method">ParentTrue</span>());
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The first thing we do build a new interface object and attach it to the
|
||||
organism object. Next we check to see if the organism has already been
|
||||
assigned its genotype. If an organism was born from a parent in the population,
|
||||
it will have been assigned a genotype by the time this method is called. If it
|
||||
does not have a genotype, however, the classification manager object will be
|
||||
called to look up any genotypes that match this genome. The classification
|
||||
manager will either return an exact match, or else create a new genotype, add it
|
||||
to the archive, and return its pointer. In either case, we now have a genotype
|
||||
for this organism.
|
||||
</p>
|
||||
<p>
|
||||
Before we erase the organism currently in this cell, we want to keep track of
|
||||
what genotype it was part of for use in updating the archive later. We then
|
||||
kill the organism in the cell (as described above) and insert the new one.
|
||||
The <span class="class">cPopulationCell</span>::<span class="method">InsertOrganism</span>()
|
||||
method will setup the organism based on the environmental conditions of this
|
||||
cell (mutation rate, tasks rewarded, etc), and store the organism for future
|
||||
use.
|
||||
</p>
|
||||
<p>
|
||||
We then adjust the genotype to let it know a new organism of its type has
|
||||
been created, and tell the classification manager that it should also adjust
|
||||
the genotypes to reflect their new abundances (one genotype has grown by one,
|
||||
the other has shrunk, so the genotype ordering may change). Other maintenance
|
||||
we need to do at this point includes adjusting the scheduler to let it know the
|
||||
merit of this new organism, and the <code>reaper_queue</code> if we keep track
|
||||
of the birth order of organisms so that we can always kill off the oldest in
|
||||
the population.
|
||||
</p>
|
||||
<p>
|
||||
Finally, we adjust some more statistics by incrementing the number of
|
||||
organisms in the population and let the statistics object know that a new
|
||||
organism was born, with all of its information. Remember, if this cell was
|
||||
already occupied, KillOrganism() would have decremented it, so this will
|
||||
properly reflect the number of organisms alive in the population at any moment.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Placing an Offspring in the Population</h2>
|
||||
|
||||
<p>
|
||||
When an organism gives birth, we must collect some relevant statistics,
|
||||
which can best be accomplished in the population object. Then we must
|
||||
place the offspring into its own cell in the population. This is all done
|
||||
with the <span class="class">cPopulation</span>::<span class="method">ActivateOffspring</span>
|
||||
method. This method takes as arguments the parent organism and child genome
|
||||
that we're working with. It is called by the divide command via the
|
||||
population interface. As this method is quite long, refer to it in the source
|
||||
code in <kbd>cPopulation.cc</kbd> while reading the remainder of this section.
|
||||
</p>
|
||||
<p>
|
||||
The first step in activating an offspring involves performing some book keeping
|
||||
on the parent's phenotype via the <span class="method">DivideReset</span>()
|
||||
method. After this, the child genome is submitted to the birth chamber. The
|
||||
birth chamber is responsible for handling the details of reproduction, such as
|
||||
genome recombination in sexual populations. The
|
||||
<span class="method">SubmitOffspring</span>() method will add organism objects
|
||||
to the <span class="object">child_array</span> for each offspring produced.
|
||||
</p>
|
||||
<p>
|
||||
The next section of code is in charge of finding where in the population each
|
||||
child organism should be placed. The cell of the parent is looked up, and then
|
||||
the <span class="method">PositionChild</span>() method is called to determine
|
||||
the child's cell.
|
||||
</p>
|
||||
<p>
|
||||
If the parent is not about to be killed off (due to being replaced by one of
|
||||
the children), we actually want to do a bit more work -- we need to adjust
|
||||
it in the schedule in case its merit has changed over this gestation cycle,
|
||||
and (if we are on a grid) we want to turn the child so that it is facing
|
||||
its parent.
|
||||
</p>
|
||||
<p>
|
||||
Finally, we collect a bunch of statistics for the parent's genotype object,
|
||||
and we run ActivateOffspring for each offspring produced using the cell we have
|
||||
chosen in order to place the child into the population.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Injecting an Organism into the Population</h2>
|
||||
|
||||
<p>
|
||||
Injecting a genome into the population that does not have a parent (such as
|
||||
with the <code>Inject</code> action) is somewhat easier to deal with.
|
||||
Basically, all that this method needs to do is build the organism with the
|
||||
proper genome, determine its genotype, setup its phenotype, put it into a
|
||||
test CPU to get its initial merit, and activate it! You should be able to
|
||||
go line-by-line through the code to see how exactly this happens for
|
||||
yourself. See
|
||||
<span class="class">cPopulation</span>::<span class="method">InjectGenome</span>,
|
||||
and more importantly
|
||||
<span class="class">cPopulation</span>::<span class="method">InjectGenotype</span>
|
||||
in <kbd>cPopulation.cc</kbd>.
|
||||
</p>
|
||||
|
|
@ -0,0 +1,395 @@
|
|||
<p>
|
||||
This file will cover in more detail some of the concepts needed to understand
|
||||
C++. The goal here is <em>not</em> to make you be able to sit down and write
|
||||
your own program from scratch.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Objects and Classes</h2>
|
||||
<p>
|
||||
An <strong>object</strong> in C++ is a single, conceptual unit that contains
|
||||
<strong>data</strong> (information about the state of that object) and
|
||||
<strong>methods</strong> (functions associated with that class of objects) by
|
||||
which the object is modified or can interact with other objects. The data in
|
||||
an object can be either normal variables (<em>e.g.</em> characters, floating
|
||||
point numbers, or integers) or previously-defined objects. A category of
|
||||
objects is a <strong>class</strong>; an object is a single instance of a class.
|
||||
</p>
|
||||
<p>
|
||||
For example, in Avida one of the most important classes is called <code>cOrganism</code>
|
||||
-- it is the class that all organism objects belong to. Here is an abbreviated
|
||||
version of the cOrganism class declaration (explained further below).
|
||||
|
||||
<pre>
|
||||
class <span class="class">cOrganism</span>
|
||||
{
|
||||
private: <span class="comment">// Data in this class cannot be directly accessed from outside.</span>
|
||||
const <span class="class">Genome</span> <span class="object">m_genome</span>; <span class="comment">// The initial genome that this organism was born with.</span>
|
||||
<span class="class">cPhenotype</span> <span class="object">m_phenotype</span>; <span class="comment">// Maintains the status of this organism's phenotypic traits.</span>
|
||||
|
||||
<span class="class">cOrgInterface</span>* <span class="object">m_interface</span>; <span class="comment">// Interface back to the population.</span>
|
||||
|
||||
<span class="class">cGenotype</span>* <span class="object">m_genotype;</span> <span class="comment">// A pointer to the genotype that this organism belongs to.</span>
|
||||
<span class="class">cHardwareBase</span>* <span class="object">m_hardware;</span> <span class="comment">// The virtual machinery that this organism's genome is run on.</span>
|
||||
|
||||
public: <span class="comment"> // The methods are accessible to other classes.</span>
|
||||
<span class="method">cOrganism</span>(<span class="class">cWorld</span>* <span class="object">world</span>, <span class="class">cAvidaContext</span>& <span class="object">ctx</span>, const <span class="class">Genome</span>& <span class="object">in_genome</span>);
|
||||
<span class="method">~cOrganism</span>();
|
||||
|
||||
<span class="comment">// This batch of methods involve interaction with the population to resolve.</span>
|
||||
<span class="class">cOrganism</span>* <span class="method">GetNeighbor</span>() { return <span class="object">m_interface</span>-><span class="method">GetNeighbor</span>(); }
|
||||
int <span class="method">GetNeighborhoodSize</span>() { return <span class="object">m_interface</span>-><span class="method">GetNumNeighbors</span>(); }
|
||||
void <span class="method">Rotate</span>(int direction) { <span class="object">m_interface</span>-><span class="method">Rotate</span>(direction); }
|
||||
int <span class="method">GetInput</span>() { return <span class="object">m_interface</span>-><span class="method">GetInput</span>(); }
|
||||
void <span class="method">Die</span>() { <span class="object">m_interface</span>-><span class="method">Die</span>(); }
|
||||
|
||||
<span class="comment">// Accessors -- these are used to gain access to private data.</span>
|
||||
const <span class="class">Genome</span>& <span class="method">GetGenome()</span> const { return <span class="object">m_genome</span>; }
|
||||
<span class="class">cHardwareBase</span>& <span class="method">GetHardware()</span> { return *<span class="object">m_hardware</span>; }
|
||||
<span class="class">cPhenotype</span>& <span class="method">GetPhenotype()</span> { return <span class="object">m_phenotype</span>; }
|
||||
<span class="class">cGenotype</span>* <span class="method">GetGenotype()</span> { return <span class="object">m_genotype</span>; }
|
||||
};
|
||||
</pre>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Style and Syntax Guide</h2>
|
||||
|
||||
<p>
|
||||
Don't worry too much about how the syntax works. The code presented above
|
||||
is a definition of a class in C++. It is broken into two parts; one labeled
|
||||
<code>private:</code> for those portions of the definition that can only
|
||||
be interacted with from within the class, and another labeled <code>public:</code>
|
||||
which defines the interface to the outside. In this case, we've made all
|
||||
of the variables private and the methods public.
|
||||
</p>
|
||||
<p>
|
||||
A variable is defined by a description of the type of variable (such
|
||||
a <code>cPhenotype</code>) and then the name of this particular instance
|
||||
of the variable. In this case, since organisms only have one phenotype,
|
||||
we called it merely <code>m_phenotype</code>. Not that because this
|
||||
variable is a <em>member</em> of <code>cOrganism</code> instances, it is
|
||||
prefixed with '<code>m_</code>'.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Methods are slightly more complex. The declaration of a method starts with the
|
||||
type of data the method returns (such as <code>int</code> for integer), or else
|
||||
lists <code>void</code> if there is no return value. Then the method name is
|
||||
given, followed by a set of parenthesis (which are what indicates to C++ that
|
||||
you are declaring a method). Inside of those parentesis, can be
|
||||
<strong>arguments</strong>, which are variables that must be given to the
|
||||
method in order for it to operate correctly. The declaration can stop at this
|
||||
point (ending in a semi-colon) if the method <strong>body</strong> is defined
|
||||
elsewhere. The body of the method is the sourcecode that details how the method
|
||||
operates, and can be included immediately after the declaration (within braces)
|
||||
or be placed elsewhere in the code. Typically short method bodies are included
|
||||
in the class definition, while longer ones are placed outside of it. A method is
|
||||
performed on an object, by listing the object name, followed by a dot ('.'), and
|
||||
then the name of the method to be called with all necessary arguments included.
|
||||
This is explained further below.
|
||||
</p>
|
||||
<p>
|
||||
The C++ language will accept variable names, class names, and method names of
|
||||
any alpha-numeric sequence as long as all names begin with a letter. The only
|
||||
other character allowed in a name is the underscore ('_'). To make reading code
|
||||
easier, we have adopted certain conventions.
|
||||
</p>
|
||||
|
||||
<dl>
|
||||
<dt><span class="object">an_example_variable</span></dt>
|
||||
<dd>
|
||||
Variable names (including object names) are always all in lowercase
|
||||
letters, with individual words separated by underscores. Variables are
|
||||
either user-defined classes, numbers (integers, boolean values, floating
|
||||
point numbers, etc.) or characters (single symbols)</dd>
|
||||
</dd>
|
||||
<dt><span class="method">ExampleMethod</span></dt>
|
||||
<dd>
|
||||
Method names always have the first letter of each word capitalized, with the
|
||||
remainder of the word in lowercase. The one exception to this is Constructors
|
||||
and Destructors, which must have the same name as the class (see below).
|
||||
</dd>
|
||||
<dt><span class="class">cExampleClass</span></dt>
|
||||
<dd>
|
||||
Classes use a similar format to methods, but always begin with a single,
|
||||
lowercase 'c'. Some other specialized types also used this format, but with a
|
||||
different initial letter. For example, an initial 't' indicates a template,
|
||||
which is a special type of class.
|
||||
</dd>
|
||||
<dt>CONSTANT_VALUE</dt>
|
||||
<dd>
|
||||
Any constant values (that is, numerical values that will never change
|
||||
during the course of the run) are given in all upper-case letters, with
|
||||
individual words separated by underscores.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
Different software projects will each use their own style conventions; these
|
||||
are the ones you'll end up working with in Avida. Some exceptions do exist.
|
||||
For example, the C++ language itself does not follow many style rules;
|
||||
built-in C++ names are all lowercase letters, regardless of what they
|
||||
represent. For more details, including spacing and other code formatting
|
||||
standards you must follow in Avida, see the
|
||||
<a href="code_standards.html">Coding Standards</a>.
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Description of Data Elements</h2>
|
||||
|
||||
<p>
|
||||
The section labeled <code>private</code> above lists those data that are unique
|
||||
to each organism; these are objects and pointers that exist <em>inside</em> of
|
||||
an organism object. First, <span class="object">m_genome</span> keeps
|
||||
the initial state of the organism. Since we never want this genome to change
|
||||
over the organism's life, we place a <code>const</code> directive in front of
|
||||
it. The <code>const</code> command exists so that C++ knows to warn the
|
||||
programmer if they accidentally try to change an object (or variable) that
|
||||
is not supposed to be altered.
|
||||
</p>
|
||||
<p>
|
||||
The internal <span class="object">m_phenotype</span> object is used to
|
||||
record the behaviors and abilities that the organism demonstrates during its
|
||||
life. This class has variables to track everything from the tasks performed to
|
||||
the gestation time of the organism and the number of offspring it has ever
|
||||
produced. The <span class="object">m_interface</span> allows an
|
||||
organism to communicate with the environment (either the
|
||||
<span class="class">cPopulation</span> or the
|
||||
<span class="class">cTestCPU</span>) that it is part of. This is used,
|
||||
for example, when an organism is ready to finish replicating and needs its
|
||||
offspring to be placed into the population. If an organism is being run on a
|
||||
test CPU rather than in a proper population object, then this interface will
|
||||
cause the statistics about offspring to be recorded for later use instead of
|
||||
activating it.
|
||||
</p>
|
||||
<p>
|
||||
Next, we have two <strong>pointers</strong>. A pointer is a value that
|
||||
represents ("points to") a location in the physical memory of the computer. A
|
||||
pointer can be identified by the asterisk ('*') that follows the type name. The
|
||||
code "<code>cGenotype* genotype</code>" indicates that the variable
|
||||
<span class="object">genotype</span> points to a location in memory
|
||||
where an object of class <span class="class">cGenotype</span> is
|
||||
stored. In this case, all of the organisms that are of a single genotype all
|
||||
point to the <em>same</em> cGenotype object so that the genotypic information
|
||||
is accessible to all organisms that may need to make use of it.
|
||||
</p>
|
||||
<p>
|
||||
The final data element is <span class="object">m_hardware</span>, a
|
||||
pointer to an object of type <span class="class">cHardwareBase</span>.
|
||||
This variable is a pointer for a different reason than the genotype. Where a
|
||||
single genotype is shared by many different organisms, each organism does
|
||||
possess its own hardware. However, Avida supports more than one type of
|
||||
hardware, where any of them can be at the other end of that hardware pointer.
|
||||
The cHardwareBase class is used as an interface to the actual hardware that is
|
||||
used. This is explained in more detail later in the section on inherited
|
||||
classes. For the moment, the key idea is that a pointer can sometimes point to
|
||||
a general type of object, not just those of a very specific class.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Description of Methods</h2>
|
||||
|
||||
<p>
|
||||
Class descriptions (with limited exceptions) must contain two specific
|
||||
methods called the <strong>constructor</strong> and the
|
||||
<strong>destructor</strong>. The constructor always has the same name as the
|
||||
class (it's called <span class="method">cOrganism</span>(...) in this
|
||||
case), and is executed in order to create a new object of that class. The
|
||||
arguments for the constructor must include all of the information required to
|
||||
build on object of the desired class. For an organism, we need the world
|
||||
object within which the organism resides, the current execution context, and
|
||||
perhaps most importantly the genome of the organism. The method is not defined
|
||||
here, only <strong>declared</strong>. A declared method must be defined
|
||||
elsewhere in the program. All methods must be, at least, declared in the class
|
||||
definition. Note that if there are many ways to create an object, multiple
|
||||
constructors are allowed as long as they take different inputs.
|
||||
</p>
|
||||
<p>
|
||||
Whereas the constructor is called when an object is created, the destructor
|
||||
is called when the object is destroyed, whereupon it must do any cleanup,
|
||||
such as freeing allocated memory (see the section on memory management
|
||||
below). The name of a destructor is always the same as the class name,
|
||||
but with a tilde ('~') in front of it. Thus, the cOrganism's destructor
|
||||
is called <span class="method">~cOrganism</span>(). A destructor can
|
||||
never take any arguments, and there must be only one of them in a class
|
||||
definition.
|
||||
</p>
|
||||
<p>
|
||||
The next group of five methods are all called when an organism needs
|
||||
to perform some behavior, which in all of these cases involves it interacting
|
||||
with the population. For example, if you need to know at whom an organism
|
||||
is facing, you can call the method
|
||||
<span class="method">GetNeighbor</span>()
|
||||
on it, and a pointer to the neighbor currently faced will be returned.
|
||||
Likewise, if you need to kill an organism, you can call the method
|
||||
<span class="method">Die</span>() on it, and it will be terminated.
|
||||
Since each of these require interaction on the population level, the population
|
||||
itself takes care of the bulk of the functionality.
|
||||
</p>
|
||||
<p>
|
||||
The 'Accessors' are methods that provide access to otherwise private
|
||||
data. For example, the method <span class="method">GetGenome</span>()
|
||||
will literally pass the genome of the organism to the object that calls it. In
|
||||
particular, the hardware object associated with an organism will often call
|
||||
<span class="method">GetPhenotype</span>() in order to get the current
|
||||
state of the organism's phenotype and update it with something new the organism
|
||||
has done. Several things to take note of here. In the first three accessors,
|
||||
the name of the class being returned is followed by an ampersand ('&').
|
||||
This means that the actual object is being passed back, and not just a copy of
|
||||
all the values contained in it. See the next section on pointers, references,
|
||||
and values for more information about this. Also, in the very first accessor,
|
||||
the keyword <code>const</code> is used twice. The first time is to say that
|
||||
the object being passed out of the method is constant (that is, the programmer
|
||||
should be warned if somewhere else in the code it is being changed) and the
|
||||
second time is to say that the actions of this method will never change
|
||||
anything about the object they are being run on (that is, the object is being
|
||||
left constant even when the method is run.) The net effect of this is that an
|
||||
object marked const can only have const methods run on it. The compiler will
|
||||
assume that a non-const method being run will make a change to the object, and
|
||||
is therefore an error.
|
||||
</p>
|
||||
<p>
|
||||
This section has contained information about a particular C++ class found
|
||||
in Avida. The next sections will more generally explain some of the
|
||||
principles of the language. If you haven't already, now might be a good
|
||||
time to take a deep breath before you dive back in.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Pointers, References, and Values</h2>
|
||||
|
||||
<p>
|
||||
The three ways of passing information around in a
|
||||
C++ program is through sending a pointer to the location of that information,
|
||||
sending a reference to it, or actually just sending the value of the information.
|
||||
For the moment, lets consider the return value of a method. Consider
|
||||
the three methods below:
|
||||
</p>
|
||||
<pre>
|
||||
<span class="class">Genome</span> <span class="method">GetGenomeValue</span>();
|
||||
<span class="class">Genome</span>* <span class="method">GetGenomePointer</span>();
|
||||
<span class="class">Genome</span>& <span class="method">GetGenomeReference</span>();
|
||||
</pre>
|
||||
<p>
|
||||
These three cases are all very different. In the first case
|
||||
(<strong>Pass-by-Value</strong>), the value of the genome in question is
|
||||
returned. That means that the genome being returned is analyzed, and the exact
|
||||
sequence of instruction in it are sent to the object calling this method. Once
|
||||
the requesting object gets this information, however, any changes made to it do
|
||||
<em>not</em> affect the original genome that was copied. The second case
|
||||
(<strong>Pass-by-Pointer</strong>),only a few bytes of information are returned
|
||||
that give the location in memory of this genome. The requesting object can then
|
||||
go and modify that memory if it chooses to, but it must first 'resolve' the
|
||||
pointer to do so. Finally, the last case (<strong>Pass-by-Reference</strong>)
|
||||
actually passes the whole object out. It is used in a very similar way to
|
||||
pass-by-value, but any changes made to the genome after it is passed out will
|
||||
affect the genome in the actual organism itself! Pass-by-reference does not
|
||||
add any new functionality over pass-by-pointer, but in practice it is often
|
||||
easier to use.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Memory Management</h2>
|
||||
|
||||
<p>
|
||||
Memory management in C++ can be as simple or complicated as the programmer
|
||||
wants it to be. If you never explicitly allocate a chunk of memory, than
|
||||
you never need to worry about freeing it up when you're done using it.
|
||||
However, there are many occasions where a program can be made faster or
|
||||
more flexible by dynamically allocating objects. The command
|
||||
<strong><code>new</code></strong> is used to allocate memory; for example if
|
||||
you wanted to allocate memory for a new genome containing 100 instructions,
|
||||
you could type:
|
||||
</p>
|
||||
<pre>
|
||||
<span class="class">Genome</span>* <span class="object">created_genome</span> = new <span class="method">Genome</span>(100);
|
||||
</pre>
|
||||
<p>
|
||||
The variable created_genome is defined as a pointer to a memory location
|
||||
containing a genome. This is assigned the location of the newly allocated
|
||||
genome in memory, which is the return value of the <code>new</code> command.
|
||||
The Genome constructor (called with new) takes as an argument a single number
|
||||
that is the sequence length of the genome.
|
||||
</p>
|
||||
<p>
|
||||
Unfortunately, C++ won't know when we're done using this genome. If we
|
||||
need to create many different genomes and we only use each of them once,
|
||||
our memory can rapidly fill up. So, we need tell the memory management
|
||||
that we are finished with the current object. Thus, when we're done using
|
||||
it, we type:
|
||||
</p>
|
||||
<pre>
|
||||
delete <span class="object">created_genome</span>;
|
||||
</pre>
|
||||
<p>
|
||||
And the memory pointed to by the created_genome
|
||||
variable will be freed up.
|
||||
</p>
|
||||
<p>
|
||||
An excellent example of when allocation and freeing of memory is employed
|
||||
in Avida is with the genotype. Every time a new genotype is created during
|
||||
evolution, Avida needs to allocate a new object of class cGenotype. During
|
||||
the course of a run, millions of genotypes may be created, so we need to be
|
||||
sure to free genotypes whenever they will no longer be needed in the run.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Inherited Classes</h2>
|
||||
|
||||
<p>
|
||||
One of the beauties of C++ is that well written code
|
||||
is inherently very reusable. As part of that, there is the concept
|
||||
of the <strong>class inheritance</strong>. When a new class is built in C++,
|
||||
it is possible to build it off of an existing class, then referred to as
|
||||
a <strong>base class</strong>. The new <strong>derived</strong>
|
||||
class will have access to all of the methods in the base class, and can
|
||||
<strong>overload</strong> them; that is, it can change how any of those
|
||||
methods operate.
|
||||
</p>
|
||||
<p>
|
||||
For example, in the Avida scheduler, we use a class called
|
||||
<span class="class">cSchedule</span> to determine which organism's
|
||||
virtual CPU executes the next instruction. Well, this cSchedule object is not
|
||||
all that clever. In fact, all that it does is run through the list of
|
||||
organisms that need to go, lets them each execute a single instruction, and
|
||||
then does it all over again. But sometimes we need to make some organisms
|
||||
execute instructions at a faster rate than others. For that reason, there are
|
||||
several derived classes, including
|
||||
<span class="class">cIntegratedSchedule</span>, which takes in a merit
|
||||
value for each organism, and assigns CPU cycles proportional to that merit.
|
||||
Since this new class uses cSchedule as its base class, it can be dynamically
|
||||
plugged in during run time, after looking at what the user chooses in the
|
||||
configuration file.
|
||||
</p>
|
||||
<p>
|
||||
If a method is not implemented in a base class (left to be implemented in the
|
||||
derived classes) it is called an <strong>abstract</strong> method. If a base
|
||||
class does not implement <em>any</em> of its methods and is only used in order
|
||||
to specify what methods need to be included in the derived classes, it is
|
||||
referred to as an <strong>abstract base class</strong> (or sometimes an
|
||||
<strong>interface class</strong> or <strong>protocol</strong>) and is used
|
||||
simply as a method contract for derived classes. An example in Avida where this
|
||||
is used is the organism interface with the environemnt. The class
|
||||
<span class="class">cOrgInterface</span> is an abstract base class,
|
||||
with <span class="class">cPopulationInterface</span> and
|
||||
<span class="class">cTestCPUInterface</span> as derived classes. This
|
||||
organization allows for organism objects to interact with both the population
|
||||
and the test environment, without having to write separate code for each.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Other C++ Resources:</h2>
|
||||
|
||||
<ul>
|
||||
<li><a href="http://www.intap.net/~drw/cpp/">Online C++ Tutorial</a></li>
|
||||
<li><a href="http://www.cplusplus.com/doc/tutorial/">Another Tutorial</a></li>
|
||||
<li><a href="http://www.quiver.freeserve.co.uk/OOP1.htm">Object Oriented Concepts Tutorial</a></li>
|
||||
<li><a href="http://www.research.att.com/~bs/glossary.html">A Glossary of C++ Terms</a></li>
|
||||
</ul>
|
||||
|
|
@ -0,0 +1,268 @@
|
|||
<p>
|
||||
The environment source code consists of several main components: resources,
|
||||
reactions, and task triggers, plus the libraries that maintain each of these.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Task Entries</h2>
|
||||
|
||||
<p>
|
||||
A task library is composed of a collection of entries, each of which fully
|
||||
describes a single task that can be used to trigger reactions.
|
||||
</p>
|
||||
<pre>
|
||||
typedef <span class="class">double</span> (<span class="class">cTaskLib</span>::*<span class="object">tTaskTest</span>)(<span class="class">cTaskContext</span>*) const;
|
||||
|
||||
class <span class="class">cTaskEntry</span> {
|
||||
private:
|
||||
<span class="class">cString</span> <span class="object">m_name</span>; <span class="comment">// Short keyword for task</span>
|
||||
<span class="class">cString</span> <span class="object">m_desc</span>; <span class="comment">// For more human-understandable output...</span>
|
||||
<span class="class">int</span> <span class="object">m_id</span>;
|
||||
<span class="class">tTaskTest</span> <span class="object">m_test_fun</span>;
|
||||
<span class="class">cString</span> <span class="object">m_info</span>; <span class="comment">// extra info (like the string or whatever to match)</span>
|
||||
|
||||
public:
|
||||
<span class="method">cTaskEntry</span>(const <span class="class">cString</span>& <span class="object">name</span>, const <span class="class">cString</span>& <span class="object">desc</span>, int <span class="object">in_id</span>, <span class="class">tTaskTest</span> <span class="object">test_fun</span>, const <span class="class">cString</span>& <span class="object">info</span>);
|
||||
: m_name(name), m_desc(desc), m_id(in_id), m_test_fun(test_fun), m_info(info)
|
||||
{
|
||||
}
|
||||
~<span class="method">cTaskEntry</span>() { ; }
|
||||
|
||||
const <span class="class">cString</span>& <span class="method">GetName</span>() const { return <span class="object">m_name</span>; }
|
||||
const <span class="class">cString</span>& <span class="method">GetDesc</span>() const { return <span class="object">m_desc</span>; }
|
||||
const int <span class="method">GetID</span>() const { return <span class="object">m_id</span>; }
|
||||
const <span class="class">tTaskTest</span> <span class="method">GetTestFun</span>() const { return <span class="object">m_test_fun</span>; }
|
||||
const <span class="class">cString</span>& <span class="method">GetInfo</span>() const { return <span class="object">m_info</span>; }
|
||||
};
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Task entries are very straight-forward. They consist of a name, a description,
|
||||
a unique ID number, and a method from the task library (cTaskLib) that they
|
||||
are associated with. This method looks at the inputs the organism has taken
|
||||
in, the values it has output, and returns a number between 0.0 and 1.0
|
||||
representing how well the task was performed. Currently, all task tests will
|
||||
return an exact zero or one, but fractions are possible if there
|
||||
is a quality component associated with the task.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Task Libraries</h2>
|
||||
|
||||
<p>
|
||||
Here is an abridged version of the task library class that manages all of the
|
||||
individual entries:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
class <span class="class">cTaskLib</span> {
|
||||
private:
|
||||
<span class="class">Apto::Array</span><<span class="class">cTaskEntry</span>*> <span class="object">task_array</span>;
|
||||
|
||||
public:
|
||||
int <span class="method">GetSize</span>() const { return <span class="object">task_array</span>.<span class="method">GetSize</span>(); }
|
||||
|
||||
<span class="class">cTaskEntry</span>* <span class="method">AddTask</span>(const <span class="class">cString</span>& <span class="object">name</span>, const <span class="class">cString</span>& <span class="object">info</span>);
|
||||
const <span class="class">cTaskEntry</span>& <span class="method">GetTask</span>(<span class="class">int</span> <span class="object">id</span>) const;
|
||||
|
||||
void <span class="method">SetupTests</span>(<span class="class">cTaskContext</span>& <span class="object">ctx</span>) const;
|
||||
inline double <span class="method">TestOutput</span>(const <span class="class">cTaskEntry</span>& <span class="object">task</span>, <span class="class">cTaskContext</span>* ctx) const;
|
||||
|
||||
private:
|
||||
double <span class="method">Task_Echo</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const;
|
||||
double <span class="method">Task_Add</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const;
|
||||
double <span class="method">Task_Sub</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const;
|
||||
|
||||
double <span class="method">Task_Not</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const;
|
||||
double <span class="method">Task_Nand</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const;
|
||||
double <span class="method">Task_And</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const;
|
||||
<span class="comment">// ... And a whole bunch more ...</span>
|
||||
|
||||
};
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The task library contains an array of task entries that define all of the
|
||||
rewarded (or otherwise acted upon) tasks in an environment.
|
||||
</p>
|
||||
<p>
|
||||
The <span class="method">TestOutput</span>() method can only be run with
|
||||
as <span class="class">cTaskContext</span> object that has been initialized
|
||||
with the <span class="method">SetupTests</span> method. It will test the
|
||||
specific task passed in and return the 0.0 - 1.0 quality measure of how well
|
||||
that task was done with the most recent output.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Below is a sample task-tester implementation:
|
||||
|
||||
<pre>
|
||||
double <span class="class">cTaskLib</span>::<span class="method">Task_Add</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const
|
||||
{
|
||||
const int <span class="object">test_output</span> = <span class="object">ctx</span>-><span class="object">output_buffer</span>[0];
|
||||
for (<span class="class">int</span> <span class="object">i</span> = 0; <span class="object">i</span> < <span class="object">ctx</span>-><span class="object">input_buffer</span>.<span class="method">GetNumStored</span>(); <span class="object">i</span>++) {
|
||||
for (<span class="class">int</span> <span class="object">j</span> = 0; <span class="object">j</span> < <span class="object">i</span>; <span class="object">j</span>++) {
|
||||
if (<span class="object">test_output</span> == <span class="object">ctx</span>-><span class="object">input_buffer</span>[<span class="object">i</span>] + <span class="object">ctx</span>-><span class="object">input_buffer</span>[<span class="object">j</span>]) return 1.0;
|
||||
}
|
||||
}
|
||||
return 0.0;
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This case tests to see if the organism has performed an addition operation.
|
||||
It compares all pairs of inputs summed together against the most recent
|
||||
output of the organism. If there is a match a full reward (1.0) is given.
|
||||
If no match is found, no reward is given (0.0).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The <span class="method">SetupTests</span> method performs some
|
||||
precomptution for all of the logic tasks, creating the value
|
||||
<span class="object">logic_id</span> within the task context. The
|
||||
<span class="object">logic_id</span> has 256 possible values, each of which
|
||||
can only be associated with a single logic task. These tests look more like:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
double <span class="class">cTaskLib</span>::<span class="method">Task_AndNot</span>(<span class="class">cTaskContext</span>* <span class="object">ctx</span>) const
|
||||
{
|
||||
const int <span class="object">logic_id</span> = <span class="object">ctx</span>-><span class="object">logic_id</span>;
|
||||
if (<span class="object">logic_id</span> == 10 || <span class="object">logic_id</span> == 12 || <span class="object">logic_id</span> == 34 ||
|
||||
<span class="object">logic_id</span> == 48 || <span class="object">logic_id</span> == 68 || <span class="object">logic_id</span> == 80) return 1.0;
|
||||
return 0.0;
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If the logic ID is on the list, the task has been done, otherwise it hasn't.
|
||||
In each case, the outside world needs to request a test of which tasks have
|
||||
been performed, and the library just replied with a numerical answer.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Building a Reaction</h2>
|
||||
|
||||
<p>
|
||||
The reaction class keeps track of all of the information associated with
|
||||
a single possible environmental reaction. Each reaction must have a unique
|
||||
name and a unique numerical ID associated with them. In addition to those
|
||||
data, a reaction object also has a task that acts as its trigger, a list of
|
||||
other requisites that must be met for the trigger to work, and a list of
|
||||
processes that will occur if the reaction goes off. The cReaction object
|
||||
acts a a single place to store all of this information.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Resources</h2>
|
||||
|
||||
<p>
|
||||
Resources are a little more complicated than task entries to manage
|
||||
and understand. An object of type <span class="class">cResource</span>
|
||||
contains 19 pieces of data, and the associated accessors. Like all of the
|
||||
other individual units we have discussed, resources have a unique
|
||||
<span class="object">name</span> and numerical
|
||||
<span class="object">id</span>. For all resource we store the quantities
|
||||
associated with their <span class="object">inflow</span>,
|
||||
<span class="object">outflow</span>, and
|
||||
<span class="object">initial</span> count (each stored as a
|
||||
double) as well as the <span class="object">geometry</span> of that resource.
|
||||
|
||||
<p>
|
||||
For spatial resources we need to be able to describe how a resource
|
||||
exists in space so we store data for:
|
||||
<ul>
|
||||
<li>
|
||||
<span class="object">inflowX1</span>,
|
||||
<span class="object">inflowX2</span>,
|
||||
<span class="object">inflowY1</span>, and
|
||||
<span class="object">inflowY2</span> to describe a rectangle where
|
||||
resources flow in.
|
||||
</li>
|
||||
<li>
|
||||
<span class="object">outflowX1</span>,
|
||||
<span class="object">outflowX2</span>,
|
||||
<span class="object">outflowY1</span>, and
|
||||
<span class="object">outfowY2</span> for a rectangle where resources
|
||||
flow out.
|
||||
</li>
|
||||
<li>
|
||||
<span class="object">cell_list</span> is a list of individual cells with
|
||||
their own initial, inflow and outflow values.
|
||||
<li>
|
||||
<span class="object">xdiffuse</span> and
|
||||
<span class="object">ydiffuse</span> describe how fast resources will
|
||||
flow from cells of higher amounts of that resource to cells with
|
||||
lower amounts of that resource.
|
||||
</li>
|
||||
<li>
|
||||
<span class="object">xgravity</span> and
|
||||
<span class="object">ygravity</span> describe the preferential flow of
|
||||
resource in a given direction.
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
This class describes the dynamics of a resource, not its current count
|
||||
(since, for example, we might want local resources where each cell
|
||||
would have its own count). However, every time a
|
||||
resource is needed, any changes in its quantity from the last time it was
|
||||
used can be calculated using these numbers.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Tying it all together: The Environment</h2>
|
||||
|
||||
<p>
|
||||
The cEnvironment class is used to maintain the details of how the environments
|
||||
work using the classes described above and a few others. Below is an
|
||||
abbreviated version of this class:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
class <span class="class">cEnvironment</span> {
|
||||
private:
|
||||
<span class="comment">// Keep libraries of resources, reactions, and tasks.</span>
|
||||
<span class="class">cResourceLib</span> <span class="object">resource_lib</span>;
|
||||
<span class="class">cReactionLib</span> <span class="object">reaction_lib</span>;
|
||||
<span class="class">cTaskLib</span> <span class="object">task_lib</span>;
|
||||
<span class="class">cInstLib</span> <span class="object">inst_lib</span>;
|
||||
<span class="class">cMutationRates</span> <span class="object">mut_rates</span>;
|
||||
|
||||
public:
|
||||
<span class="class">bool</span> <span class="method">Load</span>(const <span class="class">cString</span>& <span class="object">filename</span>);
|
||||
|
||||
<span class="comment">// Interaction with the organisms</span>
|
||||
<span class="class">bool</span> <span class="method">TestOutput</span>(<span class="class">cAvidaContext</span>& <span class="object">ctx</span>, <span class="class">cReactionResult</span>& <span class="object">result</span>, <span class="class">cTaskContext</span>& <span class="object">taskctx</span>,
|
||||
const <span class="class">tBuffer</span><int>& <span class="object">send_buf</span>, const <span class="class">tBuffer</span><int>& <span class="object">receive_buf</span>,
|
||||
const <span class="class">Apto::Array</span><int>& <span class="object">task_count</span>, const <span class="class">Apto::Array</span><int>& <span class="object">reaction_count</span>,
|
||||
const <span class="class">Apto::Array</span><double>& <span class="object">resource_count</span>) const;
|
||||
};
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The private data members include all of the libraries needed to specify
|
||||
the environment, plus its mutation rates. The
|
||||
<span class="method">Load</span>() method takes a filename
|
||||
(<kbd>environment.cfg</kbd> by default) and will fill out all of the libraries
|
||||
in this environment. The most important feature of this class is the
|
||||
<span class="method">TestOutput</span>() method, which takes in all sorts
|
||||
of information about the current state of the organism that has just done
|
||||
an output and fills out an object of type
|
||||
<span class="class">cReactionResult</span> with information about what
|
||||
happened. It also directly returns a bool that will indicate if there have
|
||||
been any changes at all. The specific information it uses to determine
|
||||
the results are the inputs the organism has taken in and the outputs it has
|
||||
produced -- both needed to determine what tasks have been done, and therefore
|
||||
what reactions may have been triggered. This information is encapsulated in
|
||||
the task context <span class="object">taskctx</span>. The organism's
|
||||
previous <span class="object">task_count</span> and
|
||||
<span class="object">resource_count</span> are also needed to determine
|
||||
if the reactions requisites have been met. And finally the
|
||||
<span class="object">resource_count</span> available to the organisms is
|
||||
needed to determine how much of each resource can be used in the reactions.
|
||||
</p>
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
<p>
|
||||
This document discusses the implementation of the cInstruction and Genome classes.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>The cInstruction Class</h2>
|
||||
|
||||
<p>
|
||||
This class is used to represent a single instruction within a genome. The
|
||||
private portion of this class consists of a single number that uniquely
|
||||
identifies the type of instruction, and the public section
|
||||
has a number of helper methods that allow us to work with that number.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
class <span class="class">cInstruction</span> {
|
||||
private:
|
||||
unsigned char <span class="object">m_operand</span>;
|
||||
|
||||
public:
|
||||
<span class="comment">// Constructors and Destructor...</span>
|
||||
<span class="method">cInstruction</span>() : <span class="object">m_operand</span>(0) { ; }
|
||||
<span class="method">cInstruction</span>(const <span class="class">cInstruction</span>& <span class="object">inst</span>) { *<span class="object">this</span> = <span class="object">inst</span>; }
|
||||
explicit <span class="method">cInstruction</span>(<span class="class">int</span> <span class="object">in_op</span>) { <span class="method">SetOp</span>(<span class="object">in_op</span>); }
|
||||
<span class="method">~cInstruction</span>() { ; }
|
||||
|
||||
<span class="comment">// Accessors...</span>
|
||||
<span class="class">int</span> <span class="method">GetOp()</span> const { return static_cast<int>(<span class="object">m_operand</span>); }
|
||||
void <span class="method">SetOp</span>(<span class="class">int</span> <span class="object">in_op</span>) { <span class="method">assert</span>(<span class="object">in_op</span> < 256); <span class="object">m_operand</span> = <span class="object">in_op</span>; }
|
||||
|
||||
<span class="comment">// Operators...</span>
|
||||
void <span class="method">operator=</span>(const <span class="class">cInstruction</span>& <span class="object">inst</span>) { <span class="object">m_operand</span> = <span class="object">inst</span>.<span class="object">m_operand</span>; }
|
||||
<span class="class">bool</span> <span class="method">operator==</span>(const <span class="class">cInstruction</span>& <span class="object">inst</span>) const { return (<span class="object">m_operand</span> == <span class="object">inst</span>.<span class="object">m_operand</span>); }
|
||||
<span class="class">bool</span> <span class="method">operator!=</span>(const <span class="class">cInstruction</span>& <span class="object">inst</span>) const { return !(<span class="method">operator==</span>(<span class="object">inst</span>)); }
|
||||
|
||||
<span class="comment">// Some extra methods to convert too and from alpha-numeric symbols...</span>
|
||||
<span class="class">char</span> <span class="method">GetSymbol</span>() const;
|
||||
void <span class="method">SetSymbol</span>(<span class="class">char</span> <span class="object">symbol</span>);
|
||||
};
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
As stated above, the only private datum is a numerical value that identifies
|
||||
this instruction. The name <span class="object">m_operand</span> is the term
|
||||
that is used for a command name in an assembly language. Most normal assembly
|
||||
languages have both an operand and arguments associated with each full command.
|
||||
In Avida, the commands have no arguments, and hence they just consist of a
|
||||
single operand. The data type used for this is <code>unsigned char</code>. A
|
||||
char is an 8 bit number, so when one is unsigned, it represents a number from 0
|
||||
to 255. As Avida is currently implemented, we are limited to 256 distinct
|
||||
instructions. To the outside world, we treat the instruction operand like an
|
||||
integer, so it would be easy to modify this class were we ever to need more
|
||||
than 256 instructions in the set. The only reason to limit it to 8 bits
|
||||
internally (rather than the 32 of an int) is to save memory when we have a very
|
||||
large number of instructions throughout a population. Instructions already
|
||||
make up over half of all the memory resources used by Avida.
|
||||
</p>
|
||||
<p>
|
||||
The public methods begin with the <span class="method">GetOp</span>() and
|
||||
<span class="method">SetOp</span>() methods, which are standard accessors.
|
||||
Next, we have a collection of methods that begin with the word 'operator'.
|
||||
These are used to define how the corresponding symbols should be treated
|
||||
when applied to objects of this class. For example, the method
|
||||
<span class="method">operator==</span>() is called when we try to compare
|
||||
an object of type cInstruction to another. We have full control over the
|
||||
definition of this method, just like any other.
|
||||
</p>
|
||||
<p>
|
||||
Finally, we have a pair of methods that convert instructions to and from
|
||||
alphanumeric characters (symbols). These methods are used to print instructions
|
||||
out in a maximally compressed format, and to load them back in. The order of
|
||||
symbols used are the letters 'a' through 'z' in lowercase, followed by an
|
||||
uppercase 'A' through 'Z' and finally the numbers '0' through '9'. If there
|
||||
are more than 62 possible instructions, all the rest are assigned a '?' when
|
||||
printed out, and cannot be read back in properly from this format.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>The Genome class</h2>
|
||||
|
||||
<p>
|
||||
A genome is a sequence of instructions. The following class maintains this
|
||||
sequence as an array, and provides a collection of methods to manipulate the
|
||||
total construct.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
class <span class="class">Genome</span>
|
||||
{
|
||||
protected:
|
||||
<span class="class">Apto::Array</span><<span class="class">cInstruction</span>> <span class="object">genome</span>;
|
||||
int <span class="object">active_size</span>;
|
||||
|
||||
public:
|
||||
<span class="method">Genome</span>() { ; }
|
||||
explicit <span class="method">Genome</span>(int <span class="object">_size</span>);
|
||||
<span class="method">Genome</span>(const <span class="class">Genome</span>& <span class="object">in_genome</span>);
|
||||
<span class="method">Genome</span>(const <span class="class">cString</span>& <span class="object">in_string</span>);
|
||||
virtual <span class="method">~Genome</span>();
|
||||
|
||||
virtual void <span class="method">operator=</span>(const <span class="class">Genome</span>& <span class="object">other_genome</span>);
|
||||
virtual bool <span class="method">operator==</span>(const <span class="class">Genome</span>& <span class="object">other_genome</span>) const;
|
||||
virtual bool <span class="method">operator!=</span>(const <span class="class">Genome</span>& <span class="object">other_genome</span>) const { return !(<span class="object">this</span>-><span class="method">operator==</span>(<span class="object">other_genome</span>)); }
|
||||
virtual bool <span class="method">operator<</span>(const <span class="class">Genome</span>& <span class="object">other_genome</span>) const { return <span class="method">AsString</span>() < <span class="object">other_genome</span>.<span class="method">AsString</span>(); }
|
||||
|
||||
<span class="class">cInstruction</span>& <span class="method">operator[]</span>(int <span class="object">index</span>) { <span class="method">assert</span>(<span class="object">index</span> >= 0 && <span class="object">index</span> < <span class="object">active_size</span>); return <span class="object">genome</span>[<span class="object">index</span>]; }
|
||||
const <span class="class">cInstruction</span>& <span class="method">operator[]</span>(<span class="class">int</span> <span class="object">index</span>) const { <span class="method">assert</span>(<span class="object">index</span> >= 0 && <span class="object">index</span> < <span class="object">active_size</span>); return <span class="object">genome</span>[<span class="object">index</span>]; }
|
||||
|
||||
virtual void <span class="method">Copy</span>(int <span class="object">to</span>, int <span class="object">from</span>);
|
||||
|
||||
int <span class="method">GetSize</span>() const { return <span class="object">active_size</span>; }
|
||||
<span class="class">cString</span> <span class="method">AsString</span>() const;
|
||||
};
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The protected variable <span class="object">genome</span> is an array
|
||||
containing an object of type cInstruction at each position. The second
|
||||
variable <span class="object">active_size</span> denotes the number of
|
||||
instructions in this array that are currently being used. The fact that
|
||||
these variables are "protected" instead of "private" means that any
|
||||
class derived from <span class="class">Genome</span> will also have direct
|
||||
access to the variables. In particular, the class
|
||||
<span class="class">cCPUMemory</span> extends Genome, adding methods to
|
||||
alter the array length and new variables to keep track of information about
|
||||
each instruction.
|
||||
</p>
|
||||
<p>
|
||||
Three constructors allow for a new Genome object to be specified by either a
|
||||
genome length, a previously created genome, or else a string -- a sequence
|
||||
of symbols representing each instruction in order.
|
||||
</p>
|
||||
<p>
|
||||
The operators created for manipulating genomes include both assignment
|
||||
(setting one genome equal to another) and comparison (testing to see if
|
||||
two genomes are identical.) Additionally, there are two
|
||||
<span class="method">operator[]</span> methods. This means that if you
|
||||
have an object of type Genome, you can index into it to retrieve a single
|
||||
instruction. Thus, if the object was called <code>initial_genome</code>, the
|
||||
statement <code>initial_genome[15]</code> would return the instruction at
|
||||
position fifteen in the genome. This occurs by calling one of these methods
|
||||
with the appropriate integer. The difference between these two operator
|
||||
methods is that one of them is for mutable genomes (i.e. those that can be
|
||||
modified) -- a reference to the instruction in question is returned allowing
|
||||
it to be altered. The other index operator (operator[] method) is for const
|
||||
genomes, which can never be changed so only the value of the instruction is
|
||||
returned.
|
||||
</p>
|
||||
<p>
|
||||
The <span class="method">Copy(</span>) method is a shortcut to copy memory
|
||||
from one position in the genome to another. This method will later be
|
||||
<strong>overloaded</strong> (that is, replaced with a newer version) by
|
||||
cCPUMemory such that the proper flags will be copied, with the instruction
|
||||
and others will be set to indicate the copied instruction for future tests.
|
||||
<span class="method">GetSize</span>() returns the length of the genome, and
|
||||
<span class="method">AsString</span>() returns a string who has symbols in
|
||||
each position that correspond to the the instruction in the same position in
|
||||
the genome.
|
||||
</p>
|
||||
|
|
@ -0,0 +1,233 @@
|
|||
<p>
|
||||
This document examines the details of commands directly involved in
|
||||
replication.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>1. Allocation of Offspring Memory</h2>
|
||||
|
||||
<p>
|
||||
The very first instruction in most heads-based organisms is <code>h-alloc</code>,
|
||||
which will allocate space for an offspring to be placed into. If you look at
|
||||
the file <kbd>source/cpu/cHardwareCPU.cc</kbd>, you will see that this
|
||||
instruction is associated with the method
|
||||
<span class="class">cHardwareCPU</span>::<span class="method">Inst_MaxAlloc</span>().
|
||||
What this means is that the organism will automatically allocate as much
|
||||
space as it possibly can, without having to first calculate its needs. When
|
||||
the organism is finished copying itself and divides off its child, any excess
|
||||
allocated memory will automatically be discarded.
|
||||
<p/>
|
||||
<p>
|
||||
This Inst_MaxAlloc() method will determine the maximum amount of extra space
|
||||
that an organism is allowed to allocate, and then run the Allocate_Main()
|
||||
function passing in that amount. Allocate_Main is a very long method which is
|
||||
mostly just check to make sure that everything going on is legal, and then
|
||||
initializes the new memory that was allocated as per the configuration file:
|
||||
random, default instruction, or leave as it was in the previous organism that
|
||||
used it (for "necrophelia").
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>2. Initial Self-Analysis</h2>
|
||||
|
||||
<p>
|
||||
Most of the initial self-analysis done on Avida organisms is with the
|
||||
<code>search</code> instruction or one of its variants. In the heads based
|
||||
instruction set, we call this <code>h-search</code> and associate it with the
|
||||
method <span class="class">cHardwareCPU</span>::<span class="method">Inst_HeadSearch</span>().
|
||||
</p>
|
||||
<p>
|
||||
The search type instructions read in the template (series of nops) that
|
||||
follows it, determine the complement template, and find that complement
|
||||
elsewhere in the genome. It then sets the registers BX and CX to be the
|
||||
distance to the found template and the size of that template respectively.
|
||||
Finally, we place the flow control head at the end of the template found in
|
||||
order to reference it later on. Obviously this last step only occurs
|
||||
in the heads-based search.
|
||||
</p>
|
||||
<p>
|
||||
The first search instruction executed by a heads organism is typically used
|
||||
to locate the end of its genome. The search will place the flow-head at
|
||||
the end of the genome, which the organism will use to move the write head to
|
||||
this point as well. This is done with the <code>mov-head</code> instruction.
|
||||
</p>
|
||||
<p>
|
||||
If the <code>mov-head</code> instruction is followed by a <code>nop-C</code> it
|
||||
will move the write head to the flow head, and ideally be ready to start
|
||||
copying itself into the newly allocated space for the offspring.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>3. The Copy Loop</h2>
|
||||
|
||||
<p>
|
||||
The copy loop is the heart of any organism. It consists of a setup,
|
||||
a copy segment to copy one or more instructions, a test segment to determine
|
||||
if the loop has finished, and a 'jump' type instruction to move back to
|
||||
copy the next line.
|
||||
</p>
|
||||
<p>
|
||||
In a hand written organism, the setup is an <code>h-search</code> command with
|
||||
no template to direct its behavior. The default when this instruction does not
|
||||
have a template is to just drop the flow-head at the very next instruction,
|
||||
which is what it is used for here -- it places the flow head at the beginning
|
||||
of the portion of code that will actually be looped through copying each line.
|
||||
</p>
|
||||
<p>
|
||||
The copy segment is typically just a single <code>h-copy</code> instruction
|
||||
that will read in an instruction from the location of the read-head, and write
|
||||
it out to the location of the write-head. It will then advance both heads to
|
||||
the next positions in the genomes. Take a look at the source code for the
|
||||
method <span class="class">cHardwareCPU</span>::<span class="method">Inst_HeadCopy</span>().
|
||||
</p>
|
||||
<p>
|
||||
The first thing that happens in this method is the variables
|
||||
<span class="object">read_head</span>,
|
||||
<span class="object">write_head</span>, and
|
||||
<span class="object">cpu_stats</span> are setup as references to the
|
||||
appropriate objects in the hardware and organism (that is, any modifications
|
||||
to these references change the actual objects, not just a local copy of them).
|
||||
This is so that we have easy to use variables locally for those objects that
|
||||
we are working with. The read_head and write_head are then adjusted to make
|
||||
sure they are in a legal position on the genome (if, for example, the last
|
||||
instruction changed the organism's size, the heads might no longer be
|
||||
pointing to memory that still exists).
|
||||
</p>
|
||||
<p>
|
||||
Next, the instruction at the read head is recorded in the variable
|
||||
<span class="object">read_inst</span>, and we test to see if this should
|
||||
be mutated to some other value. If a mutation does occur, we change the
|
||||
read_inst variable to a random value, increment the mutation count, and mark
|
||||
flags at the instruction position of the write head to denote the mutation.
|
||||
After we determine what instruction was read (be it a correct reading or not),
|
||||
we call the <span class="method">ReadInst</span>() method, which is simply
|
||||
used to keep track of the most recent template copied. This template is used
|
||||
to help detect the end of the organism, which we shall discuss in a moment.
|
||||
</p>
|
||||
<p>
|
||||
Finally, we collect the statistics that another copy command was executed
|
||||
in this organism, finish the write by placing this instruction at the position
|
||||
of the write head (and setting its flag as being a copied instruction) and
|
||||
then advancing both heads to their next positions.
|
||||
</p>
|
||||
<p>
|
||||
After an organism executes one of these copies it has to test to see if it
|
||||
is done copying itself. The heads based organisms will typically do this
|
||||
with the aid of the <code>if-label</code> instruction, which tests to see if
|
||||
the most recent label copied is the complement of the one that follows it.
|
||||
If so, it will execute the next instruction (often a divide), otherwise it
|
||||
will skip that next instruction and execute a <code>mov-head</code> that will
|
||||
jump the instruction pointer back to the flow head that was placed at the
|
||||
beginning of the copy loop. It will continue this copy-test-jump cycle
|
||||
until all the lines have been copied.
|
||||
</p>
|
||||
<p>
|
||||
A common adaptation is "unrolling the loop".
|
||||
In the hand-written version discussed above, each instruction must have
|
||||
three instructions executed to copy it: <code>h-copy</code>,
|
||||
<code>if-label</code>, and <code>mov-head</code>. But what if a second
|
||||
<code>h-copy</code> command were inserted after the first? Now the program
|
||||
would be one line longer, so it would have more to copy, but each time
|
||||
through the loop would now copy two instructions while executing four --
|
||||
that means that on average only two instructions need be executed to copy
|
||||
one. A *huge* savings. The main drawback to the organism is that its
|
||||
length will need to be a multiple of two, or else the test to see if it is
|
||||
finished won't occur at the proper time. This loop unrolling becomes less
|
||||
and less beneficial each time the organism does it, so it won't go completely
|
||||
out of control.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>4. Dividing off the Child</h2>
|
||||
|
||||
<p>
|
||||
When an organism finishes copying itself, it needs to divide off its
|
||||
child using a divide command. In the heads based instruction set, this is
|
||||
the <code>h-divide</code> command which calls the
|
||||
<span class="class">cHardwareCPU</span>::<span class="method">Inst_HeadDivide</span>()
|
||||
method.
|
||||
</p>
|
||||
<p>
|
||||
This method will use the read head to determine the starting location of the
|
||||
offspring, and the write head to determine its end. This is logical because
|
||||
these are the locations that the heads should be in right after the copy loop
|
||||
has finished. Everything after the write head is cut off and discarded as
|
||||
"extra lines". This information is passed into the Divide_Main method
|
||||
which does the bulk of the work for divide (and is called by all of the various
|
||||
divide instructions in all of the sets).
|
||||
</p>
|
||||
<p>
|
||||
The <span class="class">cHardwareCPU</span>::<span class="method">Divide_Main</span>()
|
||||
method is therefore what we are most interested in. It begins by calculating
|
||||
the size of that child that would result from the divide point and the
|
||||
extra_line count that were passed into it, and runs
|
||||
<span class="method">Divide_CheckViable</span>() to make sure that all of
|
||||
these values are legal (that is that both parent and child are reasonable
|
||||
sizes for organisms, and reasonable sizes in relationship to each other -- for
|
||||
definitions of reasonable as found in the configuration file). If any of
|
||||
them are not legal, the method returns false.
|
||||
</p>
|
||||
<p>
|
||||
From this point on, we know the divide is legal, so we just need to process
|
||||
it. We create a variable called <span class="object">child_genome</span>,
|
||||
which we use to construct the child genome. We use a reference to a Genome
|
||||
object inside of the organism so that this child genome is attached to its
|
||||
parent organism and will be easily accessible from other places where it will
|
||||
be needed later. We're not going to be doing all of the work on it right in
|
||||
this method. We initialize the child genome to the section of the parents
|
||||
genome that was created for it. We then run
|
||||
<span class="method">Resize</span>() on the parent genome to get
|
||||
rid of all of this extra space (both child and extra lines).
|
||||
</p>
|
||||
<p>
|
||||
The <span class="method">Divide_DoMutations</span>() method will test and
|
||||
(if needed) process any divide mutations that may occur. There are many of
|
||||
them, so this method is quite long. It is followed by
|
||||
<span class="method">Divide_TestFitnessMeasures</span>(), which will run the
|
||||
offspring through a test CPU for special options that may be set in the
|
||||
genesis file (such as mutation reversions). Obviously this is very processor
|
||||
intensive since it would occur with every birth, so tests are only performed
|
||||
if required. Both of these methods are left to the reader to step through
|
||||
themselves.
|
||||
</p>
|
||||
<p>
|
||||
If we are using extra costs associated with the first time instructions are
|
||||
used, those costs a reset now that a divide has occurred, and must be paid for
|
||||
again on the next divide cycle.
|
||||
</p>
|
||||
<p>
|
||||
After a divide, we mark that we no longer have a mal (Memory ALlocation)
|
||||
active. If the parent is reset (i.e., we have two offspring, not a parent
|
||||
and child) we need to make sure not to advance the IP of the parent. The
|
||||
reset parent has its IP placed at the beginning of its genome, and we want
|
||||
to leave it there to execute the very first instruction.
|
||||
</p>
|
||||
<p>
|
||||
Finally, we tell the organism to activate the divide and do something with
|
||||
the child. Give the child to the population (or the test CPU as the case
|
||||
may be) to be dealt with, and reset the parent if we're splitting into two
|
||||
offspring.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>5. Other Bits</h2>
|
||||
|
||||
<p>
|
||||
In the description of this life-cycle, one issue that has not been discussed is
|
||||
where these organisms would perform their computations. In truth, there isn't
|
||||
a fixed time other than it must be before the divide occurs, since merit is
|
||||
recalculated on a divide. In practice it will typically be placed right before
|
||||
the copy loop, but there are plenty of exceptions.
|
||||
</p>
|
||||
<p>
|
||||
Ideally, in the longer term, an organism's life will be composed of much
|
||||
more than just replication and computations -- they will have to interact with
|
||||
each other and have more interactions with the environment. In a
|
||||
multi-threaded model, organisms will be doing many activities at the same
|
||||
time.
|
||||
</p>
|
||||
|
|
@ -0,0 +1,108 @@
|
|||
<p>
|
||||
This document discusses how to implement your own tasks to use as triggers
|
||||
for reactions in the environment.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>1. Build the prototype of the method that will be used to test the new task</h2>
|
||||
|
||||
<p>
|
||||
For this step, you will be editing the task library found in the files
|
||||
<kbd>cTaskLib.cc</kbd> and <kbd>cTaskLib.h</kbd> in the directory
|
||||
<kbd>source/main/</kbd>. Start by adding the prototype of your new test
|
||||
function to the cTaskLib class in the header file. The data that will be
|
||||
tested is all stored within task context that is passed into this function.
|
||||
This function will output a double that represents the <em>quality</em> with
|
||||
which the task is performed. This is a number between 0 and 1 that
|
||||
determines the fraction of the bonus that should be received. For tasks that
|
||||
are either successful or not, this will only return 0.0 or 1.0.
|
||||
</p>
|
||||
<p>
|
||||
For example, if we were going to create a task that tests if the organisms
|
||||
could double one of their inputs, we might call that task 'times2'. We would
|
||||
then add the line to this file:
|
||||
</p>
|
||||
<pre>
|
||||
double <span class="method">Task_Times2</span>(<span class="class">cTaskContext</span>& <span class="object">ctx</span>) const;
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If possible, place it near other tasks of the same type. In this case,
|
||||
I choose to place it directly after Task_Echo(), since this is also an
|
||||
easy task for the organisms to perform.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>2. Build the body of the method that will be used to test the new task</h2>
|
||||
|
||||
<p>
|
||||
We next go into the code (<kbd>cTaskLib.cc</kbd>) file, and add the body of our
|
||||
new method. We search for cTaskLib::Task_Echo(), since our new prototype
|
||||
followed this method in the header file, and place the body of our function
|
||||
immediately after it.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
double <span class="class">cTaskLib</span>::<span class="method">Task_Times2</span>(<span class="class">cTaskContext</span>& <span class="object">ctx</span>) const
|
||||
{
|
||||
const <span class="class">tBuffer</span><<span class="class">int</span>>& <span class="method">input_buffer</span> = <span class="object">ctx.</span><span class="method">GetInputBuffer</span>();
|
||||
const <span class="class">int </span><span class="object">test_output</span> = <span class="object">ctx</span>.<span class="method">GetOutputBuffer</span>()[0];
|
||||
const <span class="class">int</span> <span class="object">input_size</span> = <span class="object">ctx</span>.<span class="method">GetInputBuffer</span>().<span class="method">GetNumStored</span>();
|
||||
for (<span class="class">int</span> <span class="object">i</span> = 0; <span class="object">i</span> < <span class="object">input_size</span> ; <span class="object">i</span>++)
|
||||
{
|
||||
if ( <span class="object">test_output</span> == 2 * <span class="object">input_buffer</span>[<span class="object">i</span>])
|
||||
{
|
||||
return 1.0;
|
||||
}
|
||||
}
|
||||
return 0.0;
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
The most recent output is always placed at the beginning of the output
|
||||
buffer, so we store it in the variable
|
||||
<span class="object">test_output</span> to compare it against all of the
|
||||
different inputs. We then have a for-loop that goes from 0 to the number
|
||||
of inputs stored in the input buffer. Inside the body of the loop, we
|
||||
test for each input if twice that input is equal to the output. If so,
|
||||
then the task was successful and we return a 1.0. If all of the tests
|
||||
fail and we exit the loop, then we return a 0.0.
|
||||
</p>
|
||||
<p>
|
||||
These test methods should be carefully written so that they run as fast
|
||||
as possible. In particular, if a task requires that an output be
|
||||
compared to multiple inputs at a time (i.e., the tasks Add or Subtract),
|
||||
then this can become combinartoically explosive. For the moment, we
|
||||
keep control on this problem by only allowing three different inputs
|
||||
in the input buffer, but in the future this number may need to become
|
||||
higher.
|
||||
</p>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>3. Attach our new method to the name of its trigger</h2>
|
||||
|
||||
<p>
|
||||
This next step is also done in the code file, inside the
|
||||
<span class="class">cTaskLib</span>::<span class="method">AddTask</span>()
|
||||
method. Again, we want this to be in the same place, so we locate the
|
||||
task 'echo' that its supposed to follow, and add in the new line.
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
else if (<span class="object">name</span> == "times2")
|
||||
<span class="method">NewTask</span>(<span class="object">name</span>, "Times2", &<span class="class">cTaskLib</span>::<span class="method">Task_Times2</span>);
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This line will attach the name to the description "Times2" (which
|
||||
could have been a little more detailed, but should be 40 characters or less)
|
||||
as well as the function that should be called when that name is listed as a
|
||||
trigger to a reaction.
|
||||
</p>
|
||||
<p>
|
||||
You are now ready to use your task!
|
||||
</p>
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
<p>These place limits on when an organism can successfully issue a divide command to produce an offspring.</p>
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr class="important">
|
||||
<td valign="top"><strong><code>OFFSPRING_SIZE_RANGE</code></strong></td>
|
||||
<td>This is the maximal difference in genome size between a parent and offspring. The default of 2.0 means that the genome of the child must be between one-half and twice the length of the parent. This it to prevent out-of-control size changes. Setting this to 1.0 will ensure fixed length organisms (as long as you also change the other settings detailed in <a title="How to Set Up Fixed-Length Organisms" href="https://github.com/devosoft/avida/wiki/Setting-up-fixed-length-organisms">How to Set Up Fixed-Length Organisms</a>).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> MIN_COPIED_LINES <br />MIN_EXE_LINES </code></strong></td>
|
||||
<td>These settings place limits on what the parent must have done before the offspring can be born; they set the minimum fraction of instructions that must have been copied into the offspring (vs. left as default) and the minimum fraction of instructions in the parent that must have been executed. If either of these are not met, the divide will fail. These settings prevent organisms from producing pathological offspring. In practice, either of them can be set to 0.0 to turn them off.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>REQUIRE_ALLOCATE</code></strong></td>
|
||||
<td>Is an allocate required between each successful divide (in virtual hardware types where allocate is meaningful)? If so, this will limit the flexibility of how organisms produce children (they can't make multiple copies and divide them off all at once, for example). But if we don't require allocates, the resulting organisms can be a lot more difficult to understand.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>REQUIRED_TASK</code></strong></td>
|
||||
<td>This is a bit of a hack. It allows the user to set the ID number for a task that <em>must</em> occur for a divide to be successful. At -1, no tasks are required. Ideally, this should be incorporated into the environment configuration file. NOTE: A task can fire without triggering a reaction. To add a required reaction see below.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>IMMUNITY_TASK</code></strong></td>
|
||||
<td>Allows user to set the ID number for a task which, if it occurs, provides immunity from the required task (above) -- divide will proceed even if the <code>REQUIRED_TASK</code> is not done if <code>IMMUNITY_TASK</code> <em>is</em> done. Defaults to -1, no immunity task present.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>REQUIRED_REACTION</code></strong></td>
|
||||
<td>Allows the user to set the ID number for a reaction that <em>must</em> occur for a divide to be successful. At -1, no reactions are required.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>IMMUNITY_REACTION</code></strong></td>
|
||||
<td>Allows the user to set the ID number for a reaction that, if it occurs, provides immunity from the required reaction (above) -- divide will proceed even if the <code>REQUIRED_REACTION</code> has not been performed as long as the <code>IMMUNITY_REACTION</code> <em>has</em> been performed. Defaults to -1, no immunity reaction present.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>REQUIRE_EXACT_COPY</code></strong></td>
|
||||
<td>Requires the offspring to be an exact copy of the parent -- <em>before</em> divide mutations are imposed. At first glance this setting looks very similar to the <code>STERILIZE_UNSTABLE</code> setting in the Mutation Reversion group of settings. However, <code>REQUIRE_EXACT_COPY</code> allows any kind of divide mutation (see <a title="Mutation Settings" href="http://avida.devosoft.org/wiki/documentation/configuration-and-command-reference/avida-cfg-the-avida-configuration-file/mutation-settings/">Mutation Settings</a>)-- point, insertion, deletion, slip, etc. It does not allow before-divide mutations such as copy mutations. On the other hand, <code>STERILIZE_UNSTABLE</code> allows <em>any</em> kind of mutation, as long as the organism would be able to perfectly copy itself in the absence of mutations.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Many other requirements can be imposed. See avida.cfg for <code>MIN_GENOME_SIZE, MAX_GENOME_SIZE, REQUIRE_SINGLE_REACTION, REQUIRED_BONUS, REQUIRED_RESOURCE, REQUIRED_RESOURCE_LEVEL, REQUIRED_PRED_HABITAT, REQUIRED_PRED_HABITAT_VALUE, IMPLICIT_REPRO_BONUS, IMPLICIT_REPRO_CPU_CYCLES, IMPLICIT_REPRO_TIME, IMPLICIT_REPRO_END</code>, and <code>IMPLICIT_REPRO_ENERGY</code>.</p>
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
<a name="Overview"><h2>Overview</h2></a>
|
||||
<p>
|
||||
The energy model provides an organism with a metabolic rate, which is proportional to its stored energy (shown below).
|
||||
|
||||
An organism with a higher metabolic rate will pay more energy to execute instructions than one with a lower rate.
|
||||
|
||||
An organism must pay both virtual CPU cycle and energy costs to execute instructions.
|
||||
|
||||
As instructions are executed the organism's stored energy level is reduced.
|
||||
|
||||
Energy can be taken up by the organism when it completes a task, among others.
|
||||
</p>
|
||||
|
||||
<center>
|
||||
Metabolic Rate = Stored Energy / <a href="#NUM_INST_EXC_BEFORE_0_ENERGY">NUM_INST_EXC_BEFORE_0_ENERGY</a>
|
||||
</center>
|
||||
|
||||
<a name="Settings"><h2>Settings</h2></a>
|
||||
<p>
|
||||
The settings below are defults from <code>avida.cfg</code>
|
||||
<pre>
|
||||
### ENERGY_GROUP ###
|
||||
# Energy Settings
|
||||
<a href="#ENERGY_ENABLED">ENERGY_ENABLED</a> 0 # Enable Energy Model. 0/1 (off/on)
|
||||
<a href="#ENERGY_GIVEN_ON_INJECT">ENERGY_GIVEN_ON_INJECT</a> 0 # Energy given to organism upon injection.
|
||||
<a href="#ENERGY_GIVEN_AT_BIRTH">ENERGY_GIVEN_AT_BIRTH</a> 0 # Energy given to offspring upon birth.
|
||||
<a href="#FRAC_PARENT_ENERGY_GIVEN_AT_BIRTH">FRAC_PARENT_ENERGY_GIVEN_AT_BIRTH</a> 0.5 # Fraction of perent's energy given to offspring.
|
||||
<a href="#FRAC_ENERGY_DECAY_AT_BIRTH">FRAC_ENERGY_DECAY_AT_BIRTH</a> 0.0 # Fraction of energy lost due to decay during reproduction.
|
||||
<a href="#NUM_INST_EXC_BEFORE_0_ENERGY">NUM_INST_EXC_BEFORE_0_ENERGY</a> 0 # Number of instructions executed before energy is exhausted.
|
||||
<a href="#ENERGY_CAP">ENERGY_CAP</a> -1 # Maximum amount of energy that can be stored in an organism.
|
||||
# -1 means the cap is set to Max Int
|
||||
<a href="#APPLY_ENERGY_METHOD">APPLY_ENERGY_METHOD</a> 0 # When should rewarded energy be applied to current energy?
|
||||
# 0 = on divide
|
||||
# 1 = on completion of task
|
||||
# 2 = on sleep
|
||||
<a href="#FRAC_ENERGY_TRANSFER">FRAC_ENERGY_TRANSFER</a> 0.0 # Fraction of replaced organism's energy take by new resident
|
||||
<a href="#LOG_SLEEP_TIMES">LOG_SLEEP_TIMES</a> 0 # Log sleep start and end times. 0/1 (off/on)
|
||||
# WARNING: may use lots of memory.
|
||||
</pre>
|
||||
</p>
|
||||
|
||||
<a name="Description of Settings"><h2>Description of Settings</h2></a>
|
||||
<strong><a name="ENERGY_ENABLED">ENERGY_ENABLED</a></strong>
|
||||
<p>
|
||||
Flag that disables/enables the us of the energy model.
|
||||
|
||||
0 = off, 1 = on
|
||||
</p>
|
||||
|
||||
<strong><a name="ENERGY_GIVEN_ON_INJECT">ENERGY_GIVEN_ON_INJECT</a></strong>
|
||||
<p>
|
||||
How much energy is given to an injected organism.
|
||||
|
||||
This number should be large enough to sustain the population until it can gather its own energy through tasks, etc..
|
||||
</p>
|
||||
|
||||
<strong><a name="ENERGY_GIVEN_AT_BIRTH">ENERGY_GIVEN_AT_BIRTH</a></strong>
|
||||
<p>
|
||||
How much energy is given to an organism when it is born.
|
||||
</p>
|
||||
|
||||
<strong><a name="FRAC_PARENT_ENERGY_GIVEN_AT_BIRTH">FRAC_PARENT_ENERGY_GIVEN_AT_BIRTH</a></strong>
|
||||
<p>
|
||||
Fraction of the parent(s) energy which is taken from the parent and given to the offspring at birth.
|
||||
</p>
|
||||
|
||||
<strong><a name="FRAC_ENERGY_DECAY_AT_BIRTH">FRAC_ENERGY_DECAY_AT_BIRTH</a></strong>
|
||||
<p>
|
||||
Fraction of energy that decays on birth.
|
||||
</p>
|
||||
|
||||
<strong><a name="NUM_INST_EXC_BEFORE_0_ENERGY">NUM_INST_EXC_BEFORE_0_ENERGY</a></strong>
|
||||
<p>
|
||||
Number of instructions an organism can execute before it runs out of energy assuming no new energy.
|
||||
|
||||
Note: if instructions have energy costs > 0 then this options needs to be altered accordingly.
|
||||
</p>
|
||||
|
||||
<strong><a name="ENERGY_CAP">ENERGY_CAP</a></strong>
|
||||
<p>
|
||||
Maximum amount of energy that can be stored in an organism.
|
||||
</p>
|
||||
|
||||
<strong><a name="APPLY_ENERGY_METHOD">APPLY_ENERGY_METHOD</a></strong>
|
||||
<p>
|
||||
Specifies when newly received energy is applied to the organism energy store and metabolic rate.
|
||||
|
||||
Note: the <code>sleep</code> instruction can also be used as an eat instructions if needed.
|
||||
</p>
|
||||
|
||||
<strong><a name="FRAC_ENERGY_TRANSFER">FRAC_ENERGY_TRANSFER</a></strong>
|
||||
<p>
|
||||
Fraction of a replaced organism's energy transfered to the replacing organism.
|
||||
</p>
|
||||
|
||||
<strong><a name="LOG_SLEEP_TIMES">LOG_SLEEP_TIMES</a></strong>
|
||||
<p>
|
||||
Logs start and end times, in updates, of all executions of the <code>sleep</code> instruction.
|
||||
|
||||
Note: can use a lot of memory.
|
||||
</p>
|
||||
|
|
@ -0,0 +1,902 @@
|
|||
<p>
|
||||
This is the setup file for the task/resource system in Avida.
|
||||
</p>
|
||||
<p>
|
||||
Six main keywords are used in this file, RESOURCE, <a href="Gradient-resources">GRADIENT_RESOURCE</a>, REACTION, CELL, MUTATION, and SET_ACTIVE. Their formats are:
|
||||
</p>
|
||||
<pre>
|
||||
<a href="#RESOURCE">RESOURCE</a> resource_name[:options] {resource_name ...}
|
||||
<a href="gradient.html">GRADIENT_RESOURCE</a> gradient_resource_name[:options] {gradient_resource_name ...}
|
||||
<a href="#REACTION">REACTION</a> reaction_name task [process:...] [requisite:...]
|
||||
<a href="#CELL">CELL</a> resource_name:cell_list[:flow]
|
||||
<a href="#MUTATION">MUTATION</a> name trigger scope type rate
|
||||
<a href="#SET_ACTIVE">SET_ACTIVE</a> type name new_status(default=true)
|
||||
</pre>
|
||||
|
||||
<h2>Resources</h2>
|
||||
<p>
|
||||
All entries on a resource line are names of individual resources. Resources can have a global quantity depletable by all organisms or can have quantities that vary from cell to cell. The resource name <code>infinite</code> is used to refer to an undepletable resource. There are two basic commands to set up a general resource: RESOURCE and CELL. In addition, <a href="gradient.html">GRADIENT_RESOURCE</a> is a specific instance of RESOURCE which allows the user to specify a cellular distribution of quantities that change (aka move) over time in an Avida run.
|
||||
</p>
|
||||
|
||||
<h3><A name="RESOURCE">RESOURCE Command</A></h3>
|
||||
|
||||
<p>The syntax for the Resource command is:</p>
|
||||
|
||||
<pre>RESOURCE resource_name[:options] {resource_name ...}</pre>
|
||||
|
||||
<Blockquote>
|
||||
<P>
|
||||
Where <code>resource_name</code> is a unique name of the resource. This name may be used by the <code>CELL</code> command to further define the resource or in the <code>REACTION</code> to define which resource is consumed/created
|
||||
by a reaction.
|
||||
</P>
|
||||
<P>
|
||||
Where <code>options</code> is a colon delimited list of factors that modify the
|
||||
resource. The following chart specifies these options.
|
||||
</P>
|
||||
</Blockquote>
|
||||
<div align="center">
|
||||
<p> </p>
|
||||
<h3>Table 1: <span>Resources Options</span></h3>
|
||||
<p>
|
||||
(<span class="resall">blue</span> variables used for all resources
|
||||
while <span class="resspatial">red</span> variables are only used for
|
||||
spatial resources)
|
||||
</p>
|
||||
<table border="1" cellpadding="2">
|
||||
<tr>
|
||||
<th>Argument</th>
|
||||
<th>Description</th>
|
||||
<th>Default</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">inflow</td>
|
||||
<td>
|
||||
The number of units of the resource that enter the population over
|
||||
the course of an update. For a global resource this inflow
|
||||
occurs evenly throughout the update, not all at once. For a
|
||||
spatial resource this inflow amount is added every update
|
||||
evenly to all grid cells in the rectangle described by the
|
||||
points (inflowx1,inflowy1) and (inflowx2,inflowy2).
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">outflow</td>
|
||||
<td>
|
||||
The fraction of the resource that will flow out of the population
|
||||
each update. As with inflow, this happens continuously over the
|
||||
course of the update for a global resource. In the case of a
|
||||
spatial resource the fraction is withdrawn each update from
|
||||
each cell in the rectangle described by the points
|
||||
(outflowx1,outflowy1) and (outflowx2,outflowy2).
|
||||
</td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">initial</td>
|
||||
<td>
|
||||
The initial abundance of the resource in the population at the
|
||||
start of an experiment. For a spatial resource the initial
|
||||
amount is spread evenly to each cell in the world grid.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">geometry</td>
|
||||
<td>
|
||||
The layout of the resource in space.<br>
|
||||
<em>global</em> -- the entire pool of a resource is
|
||||
available to all organisms<br>
|
||||
<em>grid</em> -- organisms can only access resources in
|
||||
their grid cell. Resource can not flow past the edges of the
|
||||
world grid. (resource will use spatial parameters)<br>
|
||||
<em>torus</em> -- organisms can only access resources in
|
||||
their grid cell. Resource can flow to the opposite edges of the
|
||||
world grid. (resource will use spatial parameters)
|
||||
</td>
|
||||
<td>global</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">deme</td>
|
||||
<td>
|
||||
Is this resource going to be used by a deme. (<em>True</em> or
|
||||
<em>False</em>)
|
||||
</td>
|
||||
<td>
|
||||
false
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">energy</td>
|
||||
<td>
|
||||
Is this an energy resource. The energy model must be used.
|
||||
(<em>True</em> or <em>False</em>)
|
||||
</td>
|
||||
<td>
|
||||
false
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">inflowx1</td>
|
||||
<td>
|
||||
Leftmost coordinate of the rectangle where resource will flow
|
||||
into world grid. If not specified but an inflow rate is specified,
|
||||
an x-coordinate will be determinstically assigned.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">inflowx2</td>
|
||||
<td>
|
||||
Rightmost coordinate of the rectangle where resource will flow
|
||||
into world grid. If not specified, inflowx1's value will be used.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">inflowy1</td>
|
||||
<td>
|
||||
Topmost coordinate of the rectangle where resource will flow
|
||||
into world grid. If not specified but an inflow rate is specified,
|
||||
a y-coordinate will be determinstically assigned.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">inflowy2</td>
|
||||
<td>
|
||||
Bottommost coordinate of the rectangle where resource will flow
|
||||
into world grid. If not specified, inflowy1's value will be used.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">outflowx1</td>
|
||||
<td>
|
||||
Leftmost coordinate of the rectangle where resource will flow
|
||||
out of world grid.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">outflowx2</td>
|
||||
<td>
|
||||
Rightmost coordinate of the rectangle where resource will flow
|
||||
out of world grid. If not specified, outflowx1's value will be used.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">outflowy1</td>
|
||||
<td>
|
||||
Topmost coordinate of the rectangle where resource will flow
|
||||
out of world grid.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">outflowy2</td>
|
||||
<td>
|
||||
Bottommost coordinate of the rectangle where resource will flow
|
||||
out of world grid. If not specified, outflowy1's value will be used.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">xdiffuse</td>
|
||||
<td>
|
||||
How fast material will diffuse right <em>and</em> left. This flow
|
||||
depends on the amount of resources in a given cell and amount in
|
||||
the cells to the right and left of it. (0.0 - 1.0)
|
||||
</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">xgravity</td>
|
||||
<td>
|
||||
How fast material will move to the right <em>or</em> left. This
|
||||
movement depends only on the amount of resource in a given cell.
|
||||
(-1.0 - 1.0)
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">ydiffuse</td>
|
||||
<td>
|
||||
How fast material will diffuse up <em>and</em> down. This flow
|
||||
depends on the amount of resources in a given cell and amount in
|
||||
the cells above and below it. (0.0 - 1.0)
|
||||
</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resspatial">ygravity</td>
|
||||
<td>
|
||||
How fast material will move to the up <em>or</em> down. This
|
||||
movement depends only on the amount of resource in a given cell.
|
||||
(-1.0 - 1.0)
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p> </p>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
An example of a RESOURCE statement that begins a run with a fixed amount of the
|
||||
(global) resource in the environment, but has no inflow or outflows is:
|
||||
<pre>
|
||||
RESOURCE glucose:initial=10000
|
||||
</pre>
|
||||
</p>
|
||||
<p>
|
||||
If you wanted to make this into a chemostat with a 10000 equilibrium
|
||||
concentration for unused resources, you could put:
|
||||
<pre>
|
||||
RESOURCE maltose:initial=10000:inflow=100:outflow=0.01
|
||||
</pre>
|
||||
</p>
|
||||
<p>
|
||||
If you want a resource that exists spatially where the resource enters
|
||||
from the top and flows towards the bottom where it exits the system,
|
||||
you could use:
|
||||
<pre>
|
||||
RESOURCE lactose:geometry=grid:initial=100000:inflow=100:outflow=0.1:\
|
||||
inflowx1=0:inflowx2=100:inflowy1=0:inflowy2=0:outflowx1=0:outflowx2=100:\
|
||||
outflowy1=100:outflowy2=100:ygravity=0.5
|
||||
</pre>
|
||||
</p>
|
||||
<p>
|
||||
Defining a resource with no parameters means that it will start at a zero
|
||||
quantity and have no inflow or outflow. This is sometimes desirable if you
|
||||
want that resource to only be present as a byproduct of a reaction.
|
||||
Remember, though, that you should still have an outflow rate if it's in
|
||||
a chemostat.
|
||||
|
||||
|
||||
</p>
|
||||
|
||||
<h3><a name="CELL">CELL Command</a></h3>
|
||||
<p>
|
||||
Using Cell can help increase the detail of a spatial resource. Any cell in a
|
||||
grid can be given their own initial amount of a resource, inflow amount and
|
||||
outflow rate. These values are in addition to any other values set for the
|
||||
spatial resource for the entire for the grid (diffusion and gravity for
|
||||
instance). The command has the format:
|
||||
</p>
|
||||
<pre>CELL resource_name:cell_list[:options]</pre>
|
||||
<p>
|
||||
<Blockquote>
|
||||
Where <code>resource_name</code> is the name of the spatial resource that this
|
||||
cell command will modify. If this resource has not been defined yet, a new
|
||||
resource with this name will be created.
|
||||
</P>
|
||||
<p>
|
||||
Where <code>cell_list</code> is comma delimited list of cells that will be set.
|
||||
We treat the grid like a one dimensional array where 0 is the upper left corner,
|
||||
world_x - 1 is the upper right corner, and (world_x * world_y) - 1 is the
|
||||
lower right corner. As well as single cell you can also enter a range of
|
||||
cells by using the format a..b.
|
||||
</P>
|
||||
<P>
|
||||
Where <code>options</code> is a colon delimited list of factors that modify the
|
||||
resource. The following chart specifies these options.
|
||||
</P>
|
||||
</Blockquote>
|
||||
|
||||
<div align="center">
|
||||
<p> </p>
|
||||
<h3>Table 4: <span>Cell Options</span></h3>
|
||||
<table border="1" cellpadding="2">
|
||||
<tr>
|
||||
<th>Argument</th>
|
||||
<th>Description</th>
|
||||
<th>Default</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="rescell">inflow</td>
|
||||
<td>
|
||||
The number of units of the resource that enter a cell at the end of an
|
||||
update.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="rescell">outflow</td>
|
||||
<td>
|
||||
The fraction of the resource that will flow out a cell each update.
|
||||
</td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="rescell">initial</td>
|
||||
<td>
|
||||
The initial abundance of the resource in a cell at the start of an
|
||||
experiment.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p> </p>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
An example of setting two cells in the glucose spatial resource:
|
||||
</P>
|
||||
<pre>CELL glucose:20,50:initial=100:inflow=10:outflow=0.1</pre>
|
||||
|
||||
<P>
|
||||
An example of setting a 3 x 3 square of cells in the middle of a a maltose
|
||||
spatial resource (assuming a 10 x 10 world):
|
||||
</P>
|
||||
<pre>CELL maltose:33..35,43..45,53..55:initial=500:inflow=5:outflow=0.01</pre>
|
||||
|
||||
<h2>Reactions</h2>
|
||||
|
||||
<p>
|
||||
Reactions are set to allow organisms to consume or produce resources when those
|
||||
organisms preform certain tasks. Reactions can be used to reward (or punish)
|
||||
organisms for performing tasks or to set up a "food web". They
|
||||
are described by the task that triggers them, the processes they
|
||||
perform (including resources used and the results of using them), and
|
||||
requisites on when they can occur.
|
||||
</p>
|
||||
|
||||
<h3><A NAME="REACTION">REACTION Command</A></h3>
|
||||
<pre>REACTION reaction_name task[:argument:...] [process:...] [requisite:...]</pre>
|
||||
<blockquote>
|
||||
<p>
|
||||
Where <code>reaction_name</code> is a unique name for a reaction.
|
||||
</P>
|
||||
<P>
|
||||
Where <code>task</code> is the name of the task that must be be performed to
|
||||
trigger the reaction. A list of common tasks is listed in Table 3.
|
||||
</P>
|
||||
<P>
|
||||
Where <code>argument</code> is a list of specific arguments needed by the
|
||||
particular task.
|
||||
</P>
|
||||
Where <code>process</code> is a colon delimited list of information about how
|
||||
resources are consumed/produced. Process settings are described in Table 4.
|
||||
</P>
|
||||
<p>
|
||||
Where <code>requisite</code> is a colon delimited list describing when
|
||||
reactions can be triggered. Requisite settings are described in Table 5.
|
||||
</blockquote>
|
||||
<p>
|
||||
Each reaction must have a task that triggers it. Currently, eighty tasks
|
||||
have been implemented, as summarized in the following table (in approximate
|
||||
order of complexity):
|
||||
</p>
|
||||
|
||||
<div align="center">
|
||||
<p> </p>
|
||||
<h3>Table 5: <span>Available Tasks</span></h3>
|
||||
<table border="1" cellpadding="2">
|
||||
<tr>
|
||||
<th>Task</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">echo</td>
|
||||
<td>
|
||||
This task is triggered when an organism inputs a single number and
|
||||
outputs it without modification.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">add</td>
|
||||
<td>
|
||||
This task is triggered when an organism inputs two numbers, sums them
|
||||
together, and outputs the result.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">sub</td>
|
||||
<td>
|
||||
This task is triggered when an organism inputs two numbers, subtracts
|
||||
one from the other, and outputs the result.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">not</td>
|
||||
<td>
|
||||
This task is triggered when an organism inputs a 32 bit number,
|
||||
toggles all of the bits, and outputs the result. This is typically
|
||||
done either by nanding (by use of the <tt>nand</tt> instruction) the
|
||||
sequence to itself, or negating it and subtracting one. The latter
|
||||
approach only works since numbers are stored in twos-complement
|
||||
notation.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">nand</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are 'nanded' together in a bitwise fashion, and the result is output.
|
||||
Nand stands for "not and".
|
||||
The nand operation returns a zero if and only if both inputs are one;
|
||||
otherwise it returns a one.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">and</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are 'anded' together in a bitwise fashion, and the result is output.
|
||||
The and operation returns a one if and only if both inputs are one;
|
||||
otherwise it returns a zero.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">orn</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are 'orn' together in a bitwise fashion, and the result is output.
|
||||
The orn operation stands for or-not. It is returns true if for each
|
||||
bit pair one input is one <em>or</em> the other one is zero.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">or</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are 'ored' together in a bitwise fashion, and the result is output.
|
||||
It returns a one if either the first input <em>or</em> the second input
|
||||
is a one, otherwise it returns a zero.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">andn</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are 'andn-ed' together in a bitwise fashion, and the result is output.
|
||||
The andn operation stands for and-not. It only returns a one if
|
||||
for each bit pair one input is a one <em>and</em> the other input is
|
||||
not a one. Otherwise it returns a zero.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">nor</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are 'nored' together in a bitwise fashion, and the result is output.
|
||||
The nor operation stands for not-or and returns a one only if both
|
||||
inputs are zero. Otherwise a zero is returned.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">xor</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are 'xored' together in a bitwise fashion, and the result is output.
|
||||
The xor operation stands for "exclusive or" and returns a one
|
||||
if one, but not both, of the inputs is a one. Otherwise a zero is
|
||||
returned.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">equ</td>
|
||||
<td>
|
||||
This task is triggered when two 32 bit numbers are input, the values
|
||||
are equated together in a bitwise fashion, and the result is output.
|
||||
The equ operation stands for 'equals' and will return a one if both
|
||||
bits are identical, and a zero if they are different.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">logic_3AA-<br />logic_3CP</td>
|
||||
<td>
|
||||
These tasks include all 68 possible unique 3-input logic operations,
|
||||
many of which don't have easy-to-understand human readable names.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p> </p>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
When describing a reaction, the <code>process</code> portion determines consumption
|
||||
of resources, their byproducts, and the resulting bonuses. There are several
|
||||
arguments (separated by colons; example below) to detail the use of a resource.
|
||||
Default values are in brackets:
|
||||
</p>
|
||||
|
||||
<div align="center">
|
||||
<p> </p>
|
||||
<h3>Table 6: <span>Reaction Process Specifications</span></h3>
|
||||
<table border="1" cellpadding="2">
|
||||
<tr>
|
||||
<th>Argument</th>
|
||||
<th>Description</th>
|
||||
<th>Default</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">resource</td>
|
||||
<td>
|
||||
The name of the resource consumed. By default, no resource is being
|
||||
consumed, and the 'max' limit is the amount absorbed.
|
||||
</td>
|
||||
<td>infinite</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">value</td>
|
||||
<td>
|
||||
Multiply the value set here by the amount of the resource consumed
|
||||
to obtain the bonus. (0.5 may be inefficient, while 5.0 is very
|
||||
efficient.) This allows different reactions to make use of the
|
||||
same resource at different efficiency levels.
|
||||
</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">type</td>
|
||||
<td>
|
||||
Determines how to apply the bonus (i.e. the amount of the resource
|
||||
absorbed times the value of this process) to change the merit of the
|
||||
organism.
|
||||
<br /> <em>add</em>: Directly add the bonus to the current merit.
|
||||
<br /> <em>mult</em>: Multiply the current merit by the bonus (warning: if
|
||||
the bonus is ever less than one, this will be detrimental!)
|
||||
<br /> <em>pow</em>: Multiply the current merit by 2<sup>bonus</sup>.
|
||||
this is effectively multiplicative, but positive bonuses are
|
||||
always beneficial, and negative bonuses are harmful.
|
||||
<br /> <em>enzyme</em>: Add bonus * resource / (resource + ksubm) to the current merit.
|
||||
This is gives a Michaelis-Menten enzyme type reward where bonus is the K<sub>cat</sub>
|
||||
and the K<sub>m</sub> is entered. Does not work with unlimited resources.
|
||||
<br /> <em>energy</em>: Add the bonus energy to the organism's energy waiting to be applied buffer. Bonus energy can be applied on completion of a reaction, execution of the sleep/eat instruction, or when the organisms divides. See <a href="energy_model.html">Energy Model</a> documentation for more information.
|
||||
</td>
|
||||
<td>add</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">max</td>
|
||||
<td>The maximum amount of the resource consumed per occurrence.</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">min</td>
|
||||
<td>
|
||||
The minimum amount of resource required. If less than this quantity
|
||||
is available, the reaction ceases to proceed.
|
||||
</td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">frac</td>
|
||||
<td>The maximum fraction of the available resource that can be consumed.</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">product</td>
|
||||
<td>
|
||||
The name of the by-product resource. At the moment, only a single
|
||||
by-product can be produced at a time.
|
||||
</td>
|
||||
<td>none</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">conversion</td>
|
||||
<td>The conversion rate to by-product resource</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">inst</td>
|
||||
<td>
|
||||
The instruction that gets executed when this reaction gets performed. If
|
||||
you do not want an organism to be able to have the instruction in their
|
||||
genome, you still must put it in the instruction set file, but set its weight
|
||||
to zero. The instruction is executed at no cost to the organism.
|
||||
</td>
|
||||
<td>none</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">lethal</td>
|
||||
<td>Whether the cell dies after performing the process</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">random</td>
|
||||
<td>Whether any produced resource is placed randomly in the world instead of the focal cell.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">depletable</td>
|
||||
<td>
|
||||
Whether this resource is consumed by reactions.
|
||||
</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">phenplastbonus</td>
|
||||
<td>
|
||||
Specify how to handle phenotypic plasticity at run-time.
|
||||
This option may significantly slow an Avida experiment.
|
||||
When requested in many of the settings below (*), task
|
||||
bonuses will be adjusted by the plasticity
|
||||
of each organism's genotype. Requisites will still be
|
||||
honored, making true task completion information ambiguous.
|
||||
<br /> <em>default</em>: Do not attempt to use the genotype's task plasticity.
|
||||
<br /> *<em>nobonus</em>: Do not give a bonus to non-static tasks.
|
||||
<br /> *<em>fracbonus</em>: Scale the bonus by how static the task is.
|
||||
<br /> *<em>fullbonus</em>: Always reward a task when it is detected.
|
||||
</td>
|
||||
<td>
|
||||
default
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">ksubm</td>
|
||||
<td>
|
||||
K<sub>m</sub> for an enzyme reaction.
|
||||
</td>
|
||||
<td>
|
||||
0.0
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p> </p>
|
||||
</div>
|
||||
|
||||
|
||||
<p>
|
||||
If no process is given, a single associated process with all default
|
||||
settings is assumed. If multiple process statements are given, <em>all</em> are
|
||||
acted upon when the reaction is triggered. Assuming you were going to set
|
||||
all of the portions of process to be their default values, this portion of
|
||||
the reaction statement would appear as:
|
||||
<pre>
|
||||
process:resource=infinite:value=1:type=add:max=1:min=0:frac=1:product=none:conversion=1
|
||||
</pre>
|
||||
</p>
|
||||
<p>
|
||||
This statement has many redundancies; for example, it would indicate that the
|
||||
associated reaction should use the infinite resource, making 'frac' and 'min'
|
||||
settings irrelevant. Likewise, since 'product' is set to none, the
|
||||
'conversion' rate is never considered.
|
||||
</p>
|
||||
<p>
|
||||
The <code>requisite</code> entry limits when this reaction can be triggered. The
|
||||
following requisites (in any combination) are possible:
|
||||
</p>
|
||||
|
||||
|
||||
<div align="center">
|
||||
<p> </p>
|
||||
<h3>Table 7: <span>Reaction Requisite Specifications</span></h3>
|
||||
<table border="1" cellpadding="2">
|
||||
<tr>
|
||||
<th>Argument</th>
|
||||
<th>Description</th>
|
||||
<th>Default</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">reaction</td>
|
||||
<td>
|
||||
This limits this reaction from being triggered until the other
|
||||
reaction specified here has been triggered first. With this, the
|
||||
user can force organisms to perform reactions in a specified order.
|
||||
</td>
|
||||
<td>none</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">noreaction</td>
|
||||
<td>
|
||||
This limits this reaction from being triggered if the reaction
|
||||
specified here has already been triggered. This allows the user to
|
||||
make mutually exclusive reactions, and force organisms to "choose"
|
||||
their own path.
|
||||
</td>
|
||||
<td>none</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">min_count</td>
|
||||
<td>
|
||||
This restriction requires that the task used to trigger this reaction
|
||||
must be performed a certain number of times before the trigger will
|
||||
actually occur. This (along with max_count) allows the user to
|
||||
provide different reactions depending on the number of times an
|
||||
organism has performed a task.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">max_count</font>
|
||||
<td>
|
||||
This restriction places a cap on the number of times a task can
|
||||
be done and still trigger this reaction. It allows the user to
|
||||
limit the number of times a reaction can be done, as well as
|
||||
(along with min_count) provide different reactions depending on the
|
||||
number of times an organism as performed a task.
|
||||
</td>
|
||||
<td>INT_MAX</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">min_tot_count</td>
|
||||
<td>
|
||||
This restriction requires that the total number of tasks performed by
|
||||
the organism must be at least this high before this reaction will trigger.
|
||||
This (along with max_tot_count) allows the user to provide different
|
||||
reactions depending on how many tasks an organism performs.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">max_tot_count</td>
|
||||
<td>
|
||||
This restriction places a cap on the number of tasks an organism can do
|
||||
and still trigger this reaction. It allows the user to limit the number
|
||||
of tasks that will be rewarded, as well as (along with min_tot_count) provide
|
||||
different reactions depending on the number of tasks an organism performs.
|
||||
</td>
|
||||
<td>INT_MAX</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">reaction_min_count</td>
|
||||
<td>
|
||||
This restriction requires that the reaction must be performed a certain number
|
||||
of times before any rewards are given. The restriction refers to the number of
|
||||
times the specific reaction has been triggered, regardless of how many times
|
||||
the referenced task has been performed. The reaction process specs max and min
|
||||
will restrict reactions and their counts, not tasks.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">reaction_max_count</td>
|
||||
<td>
|
||||
This restriction caps the number of times an organism can perform the reaction,
|
||||
effectively limiting the number of times a reaction will be rewarded. The
|
||||
restriction refers to the number of times the specific reaction has been triggered,
|
||||
regardless of how many times the referenced task has been performed. The reaction
|
||||
process specs max and min will restrict reactions and their counts, not tasks.
|
||||
</td>
|
||||
<td>INT_MAX</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">divide_only</td>
|
||||
<td>
|
||||
This command decides when a task will be checked, if the value is 0 the task
|
||||
will only be checked when an organism executes an IO. If the value is 1 the task
|
||||
will only be checked when the organism divides. If the value is 2 the task will be
|
||||
checked at both times.
|
||||
</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">parasite_only</td>
|
||||
<td>
|
||||
This command only allows parasites to get credit for the reaction, not host organisms.
|
||||
</td>
|
||||
<td>False</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p> </p>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
No restrictions are present by default. If there are multiple requisite
|
||||
entries, only *one* of them need be satisfied in order to trigger the
|
||||
reaction. Note though that a single requisite entry can have as many
|
||||
portions as needed.
|
||||
</p>
|
||||
|
||||
<h2>Examples</h2>
|
||||
|
||||
<p>
|
||||
We could simulate the pre-environment system (in which no resources were
|
||||
present and task performance was rewarded with a fixed bonus) with a file
|
||||
including only lines like:
|
||||
<pre>
|
||||
REACTION AND logic:2a process:type=mult:value=4.0 requisite:max_count=1
|
||||
REACTION EQU logic:2h process:type=mult:value=32.0 requisite:max_count=1
|
||||
</pre>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
No RESOURCE statements need be included since only the infinite resource is
|
||||
used (by default, since we don't specify another resource's name)
|
||||
# To create an environment with two resources that are converted back and
|
||||
forth as tasks are performed, we might have:
|
||||
<pre>
|
||||
RESOURCE yummyA:initial=1000
|
||||
RESOURCE yummyB:initial=1000
|
||||
REACTION AtoB gobbleA process:resource=yummyA:frac=0.001:product=yummyB
|
||||
REACTION BtoA gobbleB process:resource=yummyB:frac=0.001:product=yummyA
|
||||
</pre>
|
||||
</p>
|
||||
<p>
|
||||
A value of 1.0 per reaction is default. Obviously <code>gobbleA</code> and
|
||||
<code>gobbleB</code> would have to be tasks described within Avida.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A requisite against the other reaction being performed would prevent a
|
||||
single organism from garnering both rewards in equal measure.
|
||||
</p>
|
||||
<p>
|
||||
As an example, to simulate a chemostat, we might have:
|
||||
<pre>
|
||||
RESOURCE glucose:inflow=100:outflow=0.01
|
||||
</pre>
|
||||
</p>
|
||||
<p>
|
||||
This would create a resource called "glucose" that has a fixed inflow rate of
|
||||
10000 units where 20% flows out every update. (Leaving a steady state of
|
||||
50,000 units if no organism-consumption occurs).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Limitations to this system:
|
||||
<ul>
|
||||
<li>
|
||||
Only a single resource can be required at a time, and only a single
|
||||
by-product can be produced.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The default setup is:
|
||||
<pre>
|
||||
REACTION NOT not process:value=1.0:type=pow requisite:max_count=1
|
||||
REACTION NAND nand process:value=1.0:type=pow requisite:max_count=1
|
||||
REACTION AND and process:value=2.0:type=pow requisite:max_count=1
|
||||
REACTION ORN orn process:value=2.0:type=pow requisite:max_count=1
|
||||
REACTION OR or process:value=3.0:type=pow requisite:max_count=1
|
||||
REACTION ANDN andn process:value=3.0:type=pow requisite:max_count=1
|
||||
REACTION NOR nor process:value=4.0:type=pow requisite:max_count=1
|
||||
REACTION XOR xor process:value=4.0:type=pow requisite:max_count=1
|
||||
REACTION EQU equ process:value=5.0:type=pow requisite:max_count=1
|
||||
</pre>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This creates an environment where the organisms get a bonus for performing
|
||||
any of nine tasks. Since none of the reactions are associated with a
|
||||
resource, the infinite resource is assumed, which is non-depeletable.
|
||||
The max_count of one means they can only get the bonus from each reaction
|
||||
a single time.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A similar setup that has 9 resources, one corresponding to each of the nine
|
||||
possible tasks listed above is:
|
||||
<pre>
|
||||
RESOURCE resNOT:inflow=100:outflow=0.01 resNAND:inflow=100:outflow=0.01
|
||||
RESOURCE resAND:inflow=100:outflow=0.01 resORN:inflow=100:outflow=0.01
|
||||
RESOURCE resOR:inflow=100:outflow=0.01 resANDN:inflow=100:outflow=0.01
|
||||
RESOURCE resNOR:inflow=100:outflow=0.01 resXOR:inflow=100:outflow=0.01
|
||||
RESOURCE resEQU:inflow=100:outflow=0.01
|
||||
|
||||
REACTION NOT not process:resource=resNOT:value=1.0:frac=0.0025
|
||||
REACTION NAND nand process:resource=resNAND:value=1.0:frac=0.0025
|
||||
REACTION AND and process:resource=resAND:value=2.0:frac=0.0025
|
||||
REACTION ORN orn process:resource=resORN:value=2.0:frac=0.0025
|
||||
REACTION OR or process:resource=resOR:value=4.0:frac=0.0025
|
||||
REACTION ANDN andn process:resource=resANDN:value=4.0:frac=0.0025
|
||||
REACTION NOR nor process:resource=resNOR:value=8.0:frac=0.0025
|
||||
REACTION XOR xor process:resource=resXOR:value=8.0:frac=0.0025
|
||||
REACTION EQU equ process:resource=resEQU:value=16.0:frac=0.0025
|
||||
</pre>
|
||||
</p>
|
||||
|
||||
<H2>Other Commands</H2>
|
||||
<h3>SET_ACTIVE Command</h3>
|
||||
<p>
|
||||
Allows user to activate or deactivate a reaction. If this command is not
|
||||
used all reactions are active.
|
||||
</p>
|
||||
<pre>
|
||||
<a name="SET_ACTIVE">SET_ACTIVE</a> type name new_status(default=true)
|
||||
</pre>
|
||||
<blockquote>
|
||||
<P>
|
||||
Where <code>type</code> is the type of command to activate/deactivate.
|
||||
Currently <b>REACTION</b> is the only choice.
|
||||
</P>
|
||||
<p>
|
||||
Where <code>name</code> is the name of the item to activate/deactivate.
|
||||
</p>
|
||||
<p>
|
||||
Where <code>new_status</code> sets if the item is active (0 or FALSE will
|
||||
deactivate).
|
||||
</Blockquote>
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
The events file controls events that need to occur throughout the course of a run. This includes the output of data files as well as active events that effect the population (such as extinction events or changes to the mutation rate).
|
||||
|
||||
|
||||
|
||||
File Formats
|
||||
|
||||
This file consists of a list of events that will be triggered either singly or periodically. The format for each line is:
|
||||
|
||||
<code>type timing event arguments</code>
|
||||
|
||||
The type determines what kind of timings the event will be based off of. This can be immediate [i], based on update [u], or based on generation [g].
|
||||
|
||||
The timing should only be included for non-immediate events. If a single number is given for timing, the event occurs at that update/generation. A second number can be included (separated by a colon ':') to indicate how often the event should be repeated. And if a third number is listed (again, colon seperated) this will be the last time the event can occur on. For example, the type and timing `u 100:100:5000` would indicate that the event that follows first occurs at update 100, and repeats every 100 updates thereafter until update 5000. A type timing of g 10:10 would cause the event to be triggered every 10 generations for the entire run.
|
||||
|
||||
The event is simply the name of the action that should be performed, and the arguments detail exactly how it should work when it is triggered. Each action has its own arguments. See the <a href="List-of-actions">List of Actions</a> for details about all of the available options.
|
||||
|
||||
Some examples:
|
||||
|
||||
<code>i Inject</code>
|
||||
Inject an additional start creature immediately.
|
||||
|
||||
<code>u 100:100 PrintAverageData </code>
|
||||
Print out all average measurements collected every one hundred updates, starting at update 100.
|
||||
|
||||
<code>g 10000:10:20000 PrintData dom_info.dat update,dom_fitness,dom_depth,dom_sequence </code>
|
||||
Between generations 10,000 and 20,000, append the specified information to the file dom_info.dat every ten generations. Specifically, the first column in the file would be update number, second is the fitness of the dominant genotype, followed by the depth in the phylogentic tree of the dominant genotype, and finally its genome sequence.
|
||||
|
||||
[List of Actions](List-of-actions)
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
* [[Example Configs]]
|
||||
* [[Creating a Flame Graph]]
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
<p>This section relates Avida to other files that it requires.</p>
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr class="important">
|
||||
<td valign="top"><strong><code>DATA_DIR</code></strong></td>
|
||||
<td>The name (or path) of the directory where output files generated by Avida should be placed.</td>
|
||||
</tr>
|
||||
<tr class="important">
|
||||
<td valign="top"><strong><code> EVENT_FILE <br />ANALYZE_FILE <br />ENVIRONMENT_FILE </code></strong></td>
|
||||
<td>These settings indicate the names of all of the other configuration files used in an Avida run. See their documentation for more information about how to use these files.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
<p>This section covers all of the basic variables that describe the Avida run. <strong>You will probably not need to change these settings.</strong></p>
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> RANDOM_SEED </code></strong></td>
|
||||
<td>The random number seed initializes the random number generator. You should alter only this seed if you want to perform a collection of replicate runs. Setting the random number seed to zero (or a negative number) will base the seed on the starting time of the run -- effectively a random random number seed. In practice, you want to always be able to re-do an exact run in case you want to get more information about what happened.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> POPULATION_CAP </code></strong></td>
|
||||
<td>The carrying capacity of the population (in number of organisms), removing random organisms when new organisms are born. Use 0 for no cap.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> POP_CAP_ELDEST </code></strong></td>
|
||||
<td>Also applies a population cap, but removes the oldest organisms in the world.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Other general settings are described in the avida.cfg file itself: <code>VERBOSITY, SPECULATIVE,</code> and <code>POP_CAP_ELDEST</code>.</p>
|
||||
|
|
@ -0,0 +1,243 @@
|
|||
<div align="center">
|
||||
<h1>Gradient Resources</h1>
|
||||
</div>
|
||||
Gradient resource format is:
|
||||
<pre> GRADIENT_RESOURCE gradient_resource_name[:options] {gradient_resource_name ...}</pre>
|
||||
<h2>Gradient Resources</h2>
|
||||
Like other resources, gradient resources are defined in the <a href="http://avida.devosoft.org/wiki/documentation/configuration-and-command-reference/the-environment-file/">Environment File</a> and all entries on a gradient resource line are names of individual resources. Gradient resources are a type of spatial resource, some of the main difference being that gradient resources can move (standard gradient resources and halo gradient resources) and can affect org movements (hills and barriers).
|
||||
|
||||
Currently moving gradient resources are only supported for bounded grid environments.
|
||||
|
||||
<hr />
|
||||
|
||||
<h3><a name="GRADIENT_RESOURCE"></a>GRADIENT_RESOURCE Command</h3>
|
||||
The syntax for the Gradient Resource command is:
|
||||
<pre>GRADIENT_RESOURCE gradient_resource_name[:options] {gradient_resource_name ...}</pre>
|
||||
<h4>Habitats:</h4>
|
||||
The habitat a resource represents controls both the specifications of the resource (i.e. moving or stationary, orbiting or bounded within a defined area) and any effect of the resource on the organisms (i.e. blocking or slowing movement). Currently there are 4 habitats implemented: gradient, hills, barriers, and nests.
|
||||
|
||||
<h4>Gradient Resources: Standard and Halo</h4>
|
||||
Standard gradient and halo resources allows the user to specify resource distributions which change over time. If movement is enabled, the conical resources move around the Avida grid. This movement may be confined to an orbit around a specified anchor cell on the Avida grid (halos) or within a defined bounding box (standard). Gradient resource cones can be capped with a plateau cylinder of a determined height wherever cone height meets or exceeds the value of 1. In terms of actual resource value, this is analogous to slicing the cone at height 1 and then setting the actual resource value (plateau) in the sliced area to some flat value. Organisms can use sense instructions to detect resources on all parts of the cone, but they can only consume the resources where the value is >= min value in the associated reaction or collect instruction. Typically, the min value is set so that only the plateau area of the cone can be consumed. When an organism consumes any part of the cone, the cone can be set to stop moving until a predifined number of updates (=decay) has passed or all consumable resource (all cells with value >= 1) has been consumed. The cone is then refreshed at some random location within the specified boundaries. An odd but useful quirk is that if decay is set to 1, you can have walking wounded resources.
|
||||
|
||||
<h4>Barriers: Random, Vertical, and Horizontal</h4>
|
||||
Barriers are far simpler than halo and standard gradient resources. Barrier resources are simply meant to represent walls which block movement. Barriers are only implemented to be created randomly within the grid (the first block is set down in a random cell, then the next block set in a connected random, E-W, or N-S cell, and so on). For a vertical or horizontal barrier, the build direction is randomly selected at the start and the build continues in that direction until all the blocks are placed. If the end of the world is reached and there are still blocks to place, we go back to the original cell and build in the opposite direction. For random barriers, a random direction is selected at the start. Then, the direction of the build continues unchanged with a 95% probability, and a new random build direction with 5% probability. The user can also specify and exclusion area by using halo_inner_radius and halo anchors.
|
||||
Because barriers can be generated in the middle of a run, we allow orgs already standing on a barrier (which should only happen if they are born on a barrier or if a barrier was created underneath them) to continue moving. In other words, they can exit a barrier, but orgs cannot enter one. If an org (not already on a barrier) tries to enter a barrier cell, movement fails and a 0 is returned to the ?BX? register. Orgs can also make use of the sense-faced-habitat instruction to find the most restrictive habitat type in the faced cell. This will return a 1 if the 'worst' resource in the faced cell is a hill, a 2 if a barrier is in the faced cell, and a 0 if no hills or barriers are in the faced cell.
|
||||
|
||||
<h4>Hills</h4>
|
||||
Hills are simply meant to represent areas which slow movement. Hills are only implemented to be created randomly within the grid. The center block for each occurance of a hill is set down in a random cell, then the rest of the block is drawn in a circle around the center point using a random radius selected from within the config set radius range. The user can also specify and exclusion area by using halo_inner_radius and halo anchors. The effects on movement are determined by the resistance config setting. This is implemented as the probability of successfully moving while on a hill is equal to 1/resistance. As such, on average, an org on a hill with resistance = 4, will have to execute 4 move instructions to move one cell.
|
||||
|
||||
<h4>Nests</h4>
|
||||
Nests are standard gradient resources, but by declaring a gradient resource to be a nest, the resource will 'hidden' from long-distance sensing instructions such as look-ahead. Dens
|
||||
Dens are unhidden nests that are visible to instructions like look-ahead.
|
||||
|
||||
<h4>Predatory Resources</h4>
|
||||
Predatory resources are gradient resources with teeth. See SetPredatoryResource in the events list of actions.
|
||||
|
||||
<div align="center">
|
||||
|
||||
|
||||
<h3>Table 1: <span>Gradient Resource Options</span></h3>
|
||||
<strong>black</strong> variables apply to all gradient resource types,
|
||||
<span class="resall"><span style="color: #1c019c">blue</span></span> variables apply to standard and halo gradient resources
|
||||
<span class="reshalo"><span style="color: #029c1c">green</span></span> variables apply only to halo resources
|
||||
<span class="reslocate"><span style="color: #9c6800">brown(ish)</span></span> variables apply to halo resources, hills and barriers
|
||||
<span class="resbarrier"><span style="color: #9c1c01">red</span></span> variables apply only to barriers
|
||||
<span class="reshills"><span style="color: #9c1ffe">purple</span></span> variables apply only to hills
|
||||
<span class="restopo"><span style="color: #01819c">blue-green</span></span> variables apply to all topographic features (hills, barriers, dens)
|
||||
|
||||
<table border="1" cellpadding="2">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Argument</th>
|
||||
<th>Description</th>
|
||||
<th>Default</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>habitat</strong></td>
|
||||
<td>Type of gradient resource. This determines most of the behaviors and effects of the resource.0 = gradient (standard or halo), 1 = hills, 2 = barriers, 3 = nests(hidden), 4 = dens(visible), 5 = predatory, > 5 = other gradient resource (used to differentiate different 'kinds' of food.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>refuge</strong></td>
|
||||
<td>Is the resource a refuge (predation prevented)?</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">peakx</td>
|
||||
<td>Initial x-coordinate of cone peak cell. Only affects non-moving peaks. For moving peaks, random coordinates within appropriate bounds will be used.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">peaky</td>
|
||||
<td>Initial y-coordinate of cone peak cell.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">height</td>
|
||||
<td>Height in terms of resource value of the cone at the peak center. This affects values along the slope of the cone where the value of any cell on the slope = height/(distance to center + 1). Note that the height of the plateau may supersede the height of the cone, lowering or raising all cell resource values within the plateau to the plateau value. Since slope is height/distance, for a cone having a plateau and a height set to 10, the plateau will be the region of cells 10 or fewer cells from the center.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>plateau</strong></td>
|
||||
<td><span style="color: #1c019c">Standard and Halo</span>: Actual initial height in terms of resource levels wherever cone height is greater or equal to 1. This will supersede the cone height in eligible cells. A value of -1 turns this option off. <span style="color: #9c1c01">Barriers</span> and <span style="color: #9c1ffe">Hills</span>: Height of the topographic feature. Apart from when plateau = 0 (off) and plateau > 0 (on), the plateau value has no effect outside of providing values for drawing/rendering.</td>
|
||||
<td>-1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">spread</td>
|
||||
<td>Radius of the cone in terms of cells (i.e. extent of cone base). Because the spread starts counting the center cell as radius == 0, a spread of 4 will have 9 cells along the E-W/N-S axes (center cell + 4 cells either side). However, the height of this same resource would need to be == 5 to cover the same area with res value >= 1 (since we add 1 to distance from center cell for height).</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">decay</td>
|
||||
<td>Number of updates until gradient resource is refreshed after an organism initially consumes resources in the cone. The refresh will occur even if the plateau has not been completely consumed. If decay = 0, the peak will be regenerated at a new random location every update, regardless of whether any has been consumed. If decay = 1, the cone will never actually be regenerated, but will move continuously. If decay > 1, resources move until some has been consumed. Movement will then halt until decay # updates (including current) have passed and the cone will then be regenerated in a new random location.</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">min_x</td>
|
||||
<td>Leftmost coordinate of the rectangle in which resource will move randomly. The resource will stop moving left and bounce in a new random direction (inside the rectangle) when the edge of the plateau hits min_x. The case is the same for max_x, min_y, and max_y.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">max_x</td>
|
||||
<td>Rightmost coordinate of the rectangle in which resource will move randomly.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">min_y</td>
|
||||
<td>Topmost coordinate of the rectangle in which resource will move randomly.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">max_y</td>
|
||||
<td>Bottommost coordinate of the rectangle in which resource will move randomly</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>threshold</strong></td>
|
||||
<td>This set how other parts of avida interact with the resource, specifically look instructions (for now). In the look instructions, anything at or above this value will be treated and counted as an 'edible' cell.</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">move_a_scaler</td>
|
||||
<td>Measure of resource movement smoothness taken from the variable "A" in equation 1 from <a href="http://cs.gmu.edu/~eclab/tools.html#DF-1">Morrison and DeJong's</a> DF-1 Algorithm. Values range from 1 to 4. Values from 1 to around 3 yield smooth movements, while larger values yield chaotic movement. In the current implementation of gradient resources, this value is largely irrelevant, but move_a_scaler = 1 means no movement and the common setting for moving peaks is 3.8.</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>updatestep</strong></td>
|
||||
<td><span style="color: #1c019c">Standard and Halo</span>: How many updates to wait until changing gradient resouce movement direction. Resources move in random directions, only changing course if they bounce or when updatestep is reached. Low updatestep numbers result in chaotic peak movements (and peaks tend not to travel very far overall). <span style="color: #9c1c01">Barriers</span> and <span style="color: #9c1ffe">Hills</span>: How many updates to wait until regenerating the topographic features at new locations. Any value less than 1 (or >= the number of updates in the run) will turn off regeneration.</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="reshalo"><span style="color: #029c1c">halo</span></td>
|
||||
<td>Determines if this is a halo gradient. Instead of moving in a predetermined box, halo resources move randomly in an orbit around some fixed anchor cell. 1 if true, 0 if false. Halos do not use the bounded box (min_x, max_x, min_y, max_y) variables. Instead, they rely on the radius and width definitions to determine movement bounds. Note that orbit distances are in terms of cells, so orbits are rectangle in Avida. A diagonal line of cells count as the same distance as a straight line of cells.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="reslocate"><span style="color: #9c6800">halo_inner_radius</span></td>
|
||||
<td><span style="color: #029c1c">Halo</span>: Closest (in number of cells) the inner edge of a plateau of a halo resource can be to the anchor cell. If no plateau is set, then this will just be the closest the center peak cell can be to the anchor, i.e. the minimum orbit. If plateau is set, minimum orbit will be halo_inner_radius + height (since radius of plateau = height). If you want a plateau of size 10 to be centered on the anchor point, you would need to set halo_inner_radius = -10. If you want the same peak to orbit the anchor point with no space between the plateau and the anchor, halo_inner_radius would be set to 10.
|
||||
<span style="color: #9c1ffe">Hills</span>: Closest any part of any generated hill can be to the given anchor point. For hill placement, the box defined by the anchor point, inner_radius, and hill radius define an exclusion zone for placement of the hill center point and build of the hill.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="reshalo"><span style="color: #029c1c">halo_width</span></td>
|
||||
<td>How wide in cells the orbit is. The farthest the outer edge of the plateau can be from the anchor cell is halo_inner_radius + halo_width. If halo_width = 2 * height, halo resouces will travel in a fixed orbit, randomly changing orbit direction every updatestep. If halo_width > 2 * height, halo resources will travel along a random orbit between halo_inner_radius and halo_inner_radius + halo_width, changing EITHER orbit or orbit direction every updatestep.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="reslocate"><span style="color: #9c6800">halo_anchor_x</span></td>
|
||||
<td>X-coordinate of the anchor cell. For <span style="color: #9c1ffe">hills</span> this is simply the center point of any exclusion zone and does not otherwise determine where the hill is drawn.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="reslocate"><span style="color: #9c6800">halo_anchor_y</span></td>
|
||||
<td>Y-coordinate of the anchor cell.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">move_speed</td>
|
||||
<td>How 'fast' the gradient moves in the grid. Since gradient resources are built on spatial resources and spatial resources are only checked once per update, move_speed actually determines how far, in number of cells, the cone is moved between updates, not in an update. Thus move_speed > 1 will cause peaks to 'jump' ahead. Move speeds less than 1 will 'pause' resources for the abs(move_speed) number of updates between moves. This can be valuable if organisms, due to combinations of genome length and time slicing, are slow to react to resource moves and cannot otherwise keep up with the resource.</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">common</td>
|
||||
<td>In determining the cell values within the plateau, do we treat them as a common (= 1) resource, or as individual cells (= 0)? If common = 1, and any plateau cells are depletabled by organisms, at each update we look to see how much of the plateau was consumed, divide that by the number of cells in the plateau, subtract that amount from the plateau value at the beginning of the previous update (before depletion), and set all plateau cells to this new value. Thus, at the updates, the effects of depletion is spread out across all plateau cells. Peak height is then recalculated to reflect the <em>change in</em> this value and the entire cone is redrawn, while preserving the original extent of the plateau. If common = 0 resource depletions affect only individual plateau cells and the peak slopes are not changed.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">initial</td>
|
||||
<td>Initial value for all plateau cells. If set to -1 (default), initial cell values will be set == plateau.</td>
|
||||
<td>-1.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">plateau_inflow</td>
|
||||
<td>Inflow rate of resources within the plateau. This amount will be added to each cell in the plateau at each update, regardless of common setting. Maximum value for plateau cells (if set at >= 0) remains original plateau value. If common = 1, the inflow is added to the current peak height and height is reset to the new value. All values in the peak are then recalculated, but keeping the original extent of the plateau. Maximum value for height (for cone shape) remains capped at original height value.</td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">plateau_outflow</td>
|
||||
<td>Outflow rate of resource within the plateau. The quantity of resources = outflow * height will be removed from each cell in the plateau at each update, regardless of common setting. Minimum resulting value for plateau cells is 0. If common = 1, the outflow quantity is subtracted from the current peak height and height is reset to the new value. All values in the peak are then recalculated, but keeping the original extent of the plateau. Minimum resulting value for height (cone shape) is 0.</td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">cone_inflow</td>
|
||||
<td>Inflow rate of resources for individual cells in the cone. This amount will be added to each cell in the cone at each update. The value for a cell will never exceed that expected based on cone height and distance from center (that is, this is a refill rate as much as it is an inflow). Will not affect height of the cone (as in plateau_inflow) and will not affect any plateau cells (use plateau_inflow and/or gradient_inflow for that). </td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resall">cone_outflow</td>
|
||||
<td>Outflow rate for non-plateau cells </td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<tr>
|
||||
<td class="resall">gradient_inflow</td>
|
||||
<td>Inflow rate of resources for individual cells in the cone scaled by distance from peak center. This amount / (this_distance + 1) will be added to each cell in the cone at each update. The value for a cell will never exceed that expected based on cone height and distance from center (that is, this is a refill rate as much as it is an inflow). Will not affect height of the cone (as in plateau_inflow) and will not affect any plateau cells (use plateau_inflow for that). Can be combined with cone_inflow and cone_outflow and / or plateau_inflow and plateau_outflow. </br>
|
||||
To 'grow' a cone, set the height to spread + 1, add gradient inflow, set initial to 0, and set plateau to be max desired reachable height. Cells in the cone will 'grow' at different rates, with cell height growth stopping when the cell value reaches the plateau value.</td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<td class="resall">floor</td>
|
||||
<td>Minimum value for cells within the cone. Cells that would otherwise have lower values (based on distance from center) will be set to this value. Floor does not affect plateau cells. Rather, it is intended to keep values along the spread from dropping below 1 for experiments where cell values along the slopes would affect merit rewards.</td>
|
||||
<td>0.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="restopo"><span style="color: #01819c">count</span></td>
|
||||
<td>The number of hills or walls/barriers to generate.</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="restopo"><span style="color: #01819c">max_size</span></td>
|
||||
<td>The maximum wall size in number of blocks(cells) or maximum hill radius. Actual hill and wall sizes will be determined by a random number selected between min and max (inclusive), minus any blocks placed off-world or overlapping with other blocks of the same resource (or self for walls, if config = 0).</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="restopo"><span style="color: #01819c">min_size</span></td>
|
||||
<td>The minimum wall or hill size.</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="resbarrier"><span style="color: #9c1c01">config</span></td>
|
||||
<td>The orientation of the wall. 0 = random (all blocks placed randomly, but neighboring, relative to previous block), 1 = vertical (rand N or S from seed block), 2 = horizontal (rand E or W from seed block), 3 = vertical from seed (peakx, peaky) to S, 4 = horizontal from seed (peakx, peaky) to W.For hills, if config == 1, generate 1 hill at the peakx X peaky coordinates.</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="reshills"><span style="color: #9c1ffe">resistance</span></td>
|
||||
<td>This is implemented as a simple way of impacting the speed with which orgs can move through/across a hill. On average, an org on a hill will have to execute a number of move instructions equal to the resistance setting to move one cell.Setting resistance to 0 for a wall allows orgs to pass through it (creating a linear landmark rather than a barrier).</td>
|
||||
<td>1.0</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
</div>
|
||||
An example of setting a halo gradient of cone height 10 and radius 180. The plateau height is 1, meaning that the actual resource height is 1 at cells where the cone height is at least 1. Movement is smooth and is updated every 200 updates. The anchor cell is at 189, 249, and it moves no closer than 10 cells away from the anchor and no farther than 30. The resource is immediately refreshed after it has been consumed by at least one organism.
|
||||
<pre>GRADIENT_RESOURCE food1:height=10:spread=180:plateau=1:decay=1:move_a_scaler=3.8:updatestep=200:halo=1:halo_inner_radius=10:</br>halo_anchor_x=189:halo_anchor_y=249:halo_width=20:move_speed=1</pre>
|
||||
An example of a gradient which will initialize at 189, 249 and is bounded by a 200x200 cell box. The cone height is 20, but the radius is only 10 cells. The plateau is of height 2, and the resource moves only every 10000 updates.
|
||||
<pre>GRADIENT_RESOURCE nest1:peakx=189:peaky=249:height=20:spread=19:plateau=2:decay=1:min_x=125:max_x=375:min_y=125:max_y=375:</br>
|
||||
move_a_scaler=1:updatestep=10000</pre>
|
||||
Examples of barrier resources. Both will create 5 randomly placed vertical or horizontal walls, each between 10 and 200 cells long. For each barrier instance, the initial 'seed' block will be placed in a random cell. Then the build direction (N or S for the first, E or W for the second) will be chosen and the next block placed in the corresponding neighboring cell until the (randomly chosen) target size is met or the edge of the world is reached. All walls will be dismantled and new sets generated every 250 updates.
|
||||
<pre>GRADIENT_RESOURCE vert_walls:habitat=2:plateau=1.5:updatestep=250:count=5:max_size=200:min_size=10:config=1</pre>
|
||||
<pre>GRADIENT_RESOURCE horiz_walls:habitat=2:plateau=1.5:updatestep=250:count=5:max_size=200:min_size=10:config=2</pre>
|
||||
An example of a hill resource. This will draw 10 randomly placed hills every 1000 updates, with each individual hill having a radius between 50 and 125 cells. No hills will be drawn/placed within 10 cells of the center of the world (49, 49). When crossing any of these hills, an organism, on average, will have to take two steps for every one cell traversed.
|
||||
<pre>GRADIENT_RESOURCE hills:habitat=1:plateau=0.2:updatestep=1000:count=10:max_size=125:min_size=50:halo_inner_radius=10:</br>halo_anchor_x=49:halo_anchor_y=49:resistance=2</pre>
|
||||
|
||||
<hr />
|
||||
|
|
@ -0,0 +1,170 @@
|
|||
These programs were written as supplementary material for The Evolutionary Origin of Complex Features from 2003: http://myxo.css.msu.edu/papers/nature2003/. Here are programs that will trigger the nine default logic tasks with the default instruction set.
|
||||
|
||||
|
||||
<!-- saved from url=(0061)http://myxo.css.msu.edu/papers/nature2003/logic_programs.html -->
|
||||
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"></head><body bgcolor="#FFFFFF">
|
||||
|
||||
<p>
|
||||
<big>
|
||||
The following hand-written programs perform the various one- and
|
||||
two-input logic operations. These programs appear to be the shortest
|
||||
ones to perform these operations that do not depend on the initial
|
||||
content of stacks and registers (whose initial contents are represented
|
||||
by a '?' below). However, it has not been proven that these are the
|
||||
shortest programs. None of these programs permit self-replication;
|
||||
rather, they merely perform a calculation.
|
||||
</big>
|
||||
|
||||
<br><br>
|
||||
</p><center>
|
||||
|
||||
<table border="1" width="90%">
|
||||
<tbody><tr><th colspan="7" bgcolor="CCCCFF"><big>ECHO</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td> ? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>IO </th><td>? </td><td>Y </td><td> ? </td><td>? </td><td> X
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>NOT</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>push </th><td>? </td><td>X </td><td>? </td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 3</th><th>pop </th><td>? </td><td>X </td><td>X </td><td>? </td><td>
|
||||
</td></tr><tr><th> 4</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 5</th><th>nand </th><td>? </td><td>~X </td><td>X </td><td>? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>IO </th><td>? </td><td>Y </td><td>X </td><td>? </td><td> ~X
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>NAND</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>IO </th><td>? </td><td>X </td><td>Y </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 3</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 4</th><th>nand </th><td>? </td><td>X nand Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 5</th><th>IO </th><td>? </td><td>Z </td><td>Y </td><td>? </td><td> X nand Y
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>OR_N</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>IO </th><td>? </td><td>X </td><td>Y </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 3</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 4</th><th>nand </th><td>? </td><td>X nand Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 5</th><th>nand </th><td>? </td><td>X or ~Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>IO </th><td>? </td><td>Z </td><td>Y </td><td>? </td><td> X or ~Y
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>AND</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>IO </th><td>? </td><td>X </td><td>Y </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 3</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 4</th><th>nand </th><td>? </td><td>X nand Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 5</th><th>push </th><td>? </td><td>X nand Y </td><td>Y </td><td>X nand Y, ? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>pop </th><td>? </td><td>X nand Y </td><td>X nand Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 7</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 8</th><th>nand </th><td>? </td><td>X and Y </td><td>X nand Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 9</th><th>IO </th><td>? </td><td>Z </td><td>X nand Y </td><td>? </td><td> X and Y
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>OR</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>push </th><td>? </td><td>X </td><td>? </td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 3</th><th>pop </th><td>? </td><td>X </td><td>X </td><td>? </td><td>
|
||||
</td></tr><tr><th> 4</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 5</th><th>nand </th><td>~X </td><td>X </td><td>X </td><td>? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>nop-A </th><td colspan="5">
|
||||
</td></tr><tr><th> 7</th><th>IO </th><td>~X </td><td>Y </td><td>X </td><td>? </td><td> X
|
||||
</td></tr><tr><th> 8</th><th>push </th><td>~X </td><td>Y </td><td>X </td><td>Y, ? </td><td>
|
||||
</td></tr><tr><th> 9</th><th>pop </th><td>~X </td><td>Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>10</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th>11</th><th>nand </th><td>~X </td><td>~Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>12</th><th>swap </th><td>Y </td><td>~Y </td><td>~X </td><td>? </td><td>
|
||||
</td></tr><tr><th>13</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th>14</th><th>nand </th><td>Y </td><td>X or Y </td><td>~X </td><td>? </td><td>
|
||||
</td></tr><tr><th>15</th><th>IO </th><td>Y </td><td>Z </td><td>~X </td><td>? </td><td> X or Y
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>AND_N</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>IO </th><td>? </td><td>X </td><td>Y </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 3</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 4</th><th>nand </th><td>? </td><td>X nand Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 5</th><th>nand </th><td>? </td><td>X or ~Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>push </th><td>~X </td><td>X or ~Y </td><td>Y </td><td>~X or Y, ? </td><td>
|
||||
</td></tr><tr><th> 7</th><th>pop </th><td>~X </td><td>X or ~Y </td><td>X or ~Y </td><td>? </td><td>
|
||||
</td></tr><tr><th> 8</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 9</th><th>nand </th><td>? </td><td>~X and Y </td><td>X or ~Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>10</th><th>IO </th><td>? </td><td>Z </td><td>X or ~Y </td><th>? </th><td> ~X and Y
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>NOR</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>push </th><td>? </td><td>X </td><td>? </td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 3</th><th>pop </th><td>? </td><td>X </td><td>X </td><td>? </td><td>
|
||||
</td></tr><tr><th> 4</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th> 5</th><th>nand </th><td>~X </td><td>X </td><td>X </td><td>? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>nop-A </th><td colspan="5">
|
||||
</td></tr><tr><th> 7</th><th>IO </th><td>~X </td><td>Y </td><td>X </td><td>? </td><td> X
|
||||
</td></tr><tr><th> 8</th><th>push </th><td>~X </td><td>Y </td><td>X </td><td>Y, ? </td><td>
|
||||
</td></tr><tr><th> 9</th><th>pop </th><td>~X </td><td>Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>10</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th>11</th><th>nand </th><td>~X </td><td>~Y </td><td>Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>12</th><th>swap </th><td>Y </td><td>~Y </td><td>~X </td><td>? </td><td>
|
||||
</td></tr><tr><th>13</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th>14</th><th>nand </th><td>Y </td><td>X or Y </td><td>~X </td><td>? </td><td>
|
||||
</td></tr><tr><th>15</th><th>push </th><td>Y </td><td>X or Y </td><td>X </td><td>X or Y, ? </td><td>
|
||||
</td></tr><tr><th>16</th><th>pop </th><td>Y </td><td>X or Y </td><td>X or Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>17</th><th>nop-C </th><td colspan="5">
|
||||
</td></tr><tr><th>18</th><th>nand </th><td>Y </td><td>X nor Y </td><td>X or Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>19</th><th>IO </th><td>Y </td><td>Z </td><td>X or Y </td><td>? </td><td> X nor Y
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>XOR</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>IO </th><td>? </td><td>X </td><td>Y </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 3</th><th>nop-C</th><td colspan="5">
|
||||
</td></tr><tr><th> 4</th><th>push </th><td>? </td><td>X </td><td>Y </td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 5</th><th>nand </th><td>? </td><td>X nand Y</td><td>Y </td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>swap </th><td>? </td><td>Y </td><td>X nand Y</td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 7</th><th>nand </th><td>? </td><td>X or ~Y </td><td>X nand Y</td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 8</th><th>swap </th><td>X or ~Y </td><td>? </td><td>X nand Y</td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 9</th><th>nop-A</th><td colspan="5">
|
||||
</td></tr><tr><th>10</th><th>pop </th><td>X or ~Y </td><td>X </td><td>X nand Y</td><td>? </td><td>
|
||||
</td></tr><tr><th>11</th><th>nand </th><td>X or ~Y </td><td>Y or ~X </td><td>X nand Y</td><td>? </td><td>
|
||||
</td></tr><tr><th>12</th><th>swap </th><td>X nand Y</td><td>Y or ~X </td><td>X or ~Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>13</th><th>nop-C</th><td colspan="5">
|
||||
</td></tr><tr><th>14</th><th>nand </th><td>X nand Y</td><td>X xor Y </td><td>X or ~Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>15</th><th>IO </th><td>X nand Y</td><td>Z </td><td>X or ~Y </td><td>? </td><td> X xor Y
|
||||
|
||||
|
||||
</td></tr><tr><td colspan="7">
|
||||
</td></tr><tr><th colspan="7" bgcolor="CCCCFF"><big>EQU</big>
|
||||
</th></tr><tr><th> #</th><th>Inst </th><th>AX </th><th>BX </th><th>CX </th><th>Stack </th><th> Output
|
||||
</th></tr><tr><th> 1</th><th>IO </th><td>? </td><td>X </td><td>? </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 2</th><th>IO </th><td>? </td><td>X </td><td>Y </td><td>? </td><td> ?
|
||||
</td></tr><tr><th> 3</th><th>nop-C</th><td colspan="5">
|
||||
</td></tr><tr><th> 4</th><th>push </th><td>? </td><td>X </td><td>Y </td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 5</th><th>nand </th><td>? </td><td>X nand Y</td><td>Y </td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 6</th><th>swap </th><td>? </td><td>Y </td><td>X nand Y</td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 7</th><th>nand </th><td>? </td><td>X or ~Y </td><td>X nand Y</td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 8</th><th>swap </th><td>X or ~Y </td><td>? </td><td>X nand Y</td><td>X, ? </td><td>
|
||||
</td></tr><tr><th> 9</th><th>nop-A</th><td colspan="5">
|
||||
</td></tr><tr><th>10</th><th>pop </th><td>X or ~Y </td><td>X </td><td>X nand Y</td><td>? </td><td>
|
||||
</td></tr><tr><th>11</th><th>nand </th><td>X or ~Y </td><td>Y or ~X </td><td>X nand Y</td><td>? </td><td>
|
||||
</td></tr><tr><th>12</th><th>swap </th><td>X nand Y</td><td>Y or ~X </td><td>X or ~Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>13</th><th>nop-C</th><td colspan="5">
|
||||
</td></tr><tr><th>14</th><th>nand </th><td>X nand Y</td><td>X xor Y </td><td>X or ~Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>15</th><th>push </th><td>X nand Y</td><td>X xor Y </td><td>X or ~Y </td><td>X xor Y, ?</td><td>
|
||||
</td></tr><tr><th>16</th><th>pop </th><td>X nand Y</td><td>X xor Y </td><td>X xor Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>17</th><th>nop-C</th><td colspan="5">
|
||||
</td></tr><tr><th>18</th><th>nand </th><td>X nand Y</td><td>X equ Y </td><td>X xor Y </td><td>? </td><td>
|
||||
</td></tr><tr><th>19</th><th>IO </th><td>X nand Y</td><td>Z </td><td>X xor Y </td><td>? </td><td> X equ Y
|
||||
|
||||
</td></tr></tbody></table>
|
||||
|
||||
</center><span id="buffer-extension-hover-button" style="display: none;position: absolute;z-index: 8675309;width: 100px;height: 25px;background-image: url(chrome-extension://noojglkidnpfjbincgijbaiedldjfbhh/data/shared/img/buffer-hover-icon@1x.png);background-size: 100px 25px;opacity: 0.9;cursor: pointer;"></span></body></html>
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
Avida is a free, open source software platform for conducting and analyzing experiments with self-replicating and evolving computer programs. It provides detailed control over experimental settings and protocols, a large array of measurement tools, and sophisticated methods to analyze and post-process experimental data.
|
||||
|
||||
The following articles provide a good introduction to Avida:
|
||||
* [Testing Darwian](http://www.carlzimmer.com/articles/2005.php?subaction=showfull&id=1177184710&archive=&start_from=&ucat=8&) by Carl Zimmer (Cover story of Feb 2005 Discover Magazine).
|
||||
* [Twice as Natural](http://myxo.css.msu.edu/lenski/pdf/2001,%20Nature,%20Lenski,%20twice%20as%20natural.pdf) by Richard Lenski (2001)
|
||||
* [Meet the Scientist](http://www.microbeworld.org/index.php?option=com_content&view=article&id=784:mts59-charles-ofria-&catid=37:meet-the-scientist&Itemid=1550) podcast interview of Charles Ofria by Carl Zimmer (2010)
|
||||
|
||||
More detailed materials:
|
||||
* [About Digital Evolution](wiki/About)
|
||||
* [Avida: A Software Platform for Research in Computational Evolutionary Biology](http://www.cse.msu.edu/~ofria/pubs/2009AvidaIntro.pdf) by C. Ofria, D.M. Bryson, and C. Wilke (2009).
|
||||
* The contents of this Wiki
|
||||
|
||||
If you would like to contribute to this documentation, please create an account via the log-in link at the top-right of the page.
|
||||
|
||||
**[New User Information](wiki/New-User-Information)**
|
||||
|
||||
## General Information
|
||||
* [Beginner Documentation](wiki/Beginner-Documentation)
|
||||
* [Overview](wiki/Overview)
|
||||
* [A Guided Tour of the Ancestor and its Hardware](wiki/Default-Ancestor-Guided-Tour)
|
||||
* [Text Viewer](wiki/Text-Viewer)
|
||||
* [Configuration and Command Reference](wiki/Configuration-and-Command-Reference)
|
||||
* [Experiment and Analysis Guides](wiki/Experiment-and-Analysis-Guides)
|
||||
|
||||
|
||||
## Developer Resources
|
||||
* [Developers Guide](wiki/Developers-Guide)
|
||||
* [Getting Started](wiki/Development-|-Getting-Started)
|
||||
* [Avida 3 API](wiki/Avida-3-API)
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
<p>This tutorial will walk you through the steps involved in creating a deme replication event. It assumes that you have basic familiarity with C++ and Avida-ish stuff. There are several different deme replication events. Currently, they include events such as replicate when the deme is full, when the corners are occupied, when a set number of resources has been amassed (the consume-res event). For this tutorial, we'll be using 'consume-res' as an example. To add your new event: </p>
|
||||
<ol>
|
||||
<li>Come up with a few definitions for your deme replication trigger. These need to include the name of the trigger (e.g., <span style="color: #0000ff">consume-res</span>), which will be seen externally, and a deme trigger event constant name used for an enumeration (e.g., <span style="color: #0000ff">DEME_TRIGGER_CONSUME_RESOURCES</span>). The enumeration allows you to refer to your trigger by name, rather than an integer.</li>
|
||||
<li>Add your deme trigger event constant name to the enumerated triggers. To do so, go to <span style="color: #0000ff">Definitions.h</span> and search for enum <span style="color: #0000ff">eDEME_TRIGGERS</span>. Add your item right before <span style="color: #0000ff">DEME_TRIGGER_UNKNOWN</span>. For example,
|
||||
<p><span style="color: #0000ff"> DEME_TRIGGER_CONSUME_RESOURCES, // 10</span></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Define your 'trigger' event as part of the Replicate Demes action. To do that, in<span style="color: #0000ff"> PopulationActions.cc</span> go to the class <span style="color: #0000ff">cActionReplicateDemes : public Action</span>. Add the name of your trigger and a brief description to the comment: </p>
|
||||
<p><span style="color: #0000ff">'consume-res' ...demes that have consumed a sufficienct amount of resources</span></p>
|
||||
<p><span style="color: #000000">Then, add the same trigger to the end of the list of else if statements </span></p>
|
||||
<p><span style="color: #0000ff"> else if (in_trigger == "consume-res") m_rep_trigger = DEME_TRIGGER_CONSUME_RESOURCES</span></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Next, add the code that describes when your replication event will occur. In <span style="color: #0000ff">cPopulation.cc</span>, locate the <span style="color: #0000ff">ReplicateDemes</span> function: </p>
|
||||
<p><span style="color: #0000ff">void cPopulation::ReplicateDemes(int rep_trigger, cAvidaContext& ctx) </span></p>
|
||||
<p>Within this function, add your new trigger both to the comments and to the switch statement. For example, for the 'consume-res' event the following line was added to the comment: </p>
|
||||
<p><span style="color: #0000ff"> 10:'consume-res' ...demes that have consumed a sufficienct amount of resources</span></p>
|
||||
<div> And this case statement was added to the switch statement: </div>
|
||||
<div>
|
||||
<p><span style="color: #0000ff">case DEME_TRIGGER_CONSUME_RESOURCES: {</span></p>
|
||||
<p><span style="color: #0000ff"> // check how many resources have been consumed by the deme</span></p>
|
||||
<p><span style="color: #0000ff"> if (source_deme.GetTotalResourceAmountConsumed() <</span></p>
|
||||
<p><span style="color: #0000ff"> m_world->GetConfig().RES_FOR_DEME_REP.Get()) {</span></p>
|
||||
<p><span style="color: #0000ff"> continue;</span></p>
|
||||
<p><span style="color: #0000ff"> }</span></p>
|
||||
<p>Note that this code is using information about the deme. Clearly, if your method needs information from the deme and that information doesn't exist, you'll also need to write some code to do that... </p>
|
||||
<p> </p>
|
||||
</div>
|
||||
</li>
|
||||
<li>Last, add your new fangled event to the events file (generally events.cfg) and make sure it works. For example:
|
||||
<p><span style="color: #0000ff">u 1:1:end ReplicateDemes consume-res</span></p>
|
||||
</li>
|
||||
</ol>
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
These set the output colors for data files printed in HTML mode.
|
||||
|
||||
See avida.cfg for these settings: <code>COLOR_DIFF, COLOR_SAME, COLOR_NEG2, COLOR_NEG1, COLOR_POS1, COLOR_POS2, COLOR_MUT_POS, COLOR_MUT_NEUT, COLOR_MUT_NEG</code>, and COLOR_MUT_LETHAL</code>.
|
||||
|
|
@ -0,0 +1,333 @@
|
|||
An instruction set is actually a whole set of configurations, usually contained in their own file and included in the avida.cfg file with <code>#include INST_SET=instset.cfg</code>.
|
||||
|
||||
<h2>Specifiying Instruction Sets in avida.cfg</h2>
|
||||
|
||||
<p>Instruction sets are actually part of the avida.cfg file. However, instead of writing the instruction set out in avida.cfg itself, which would be rather long and messy, each instruction set is placed in a separate file. A preprocessor include (of the form <code>#include $filename</code>) is then used to include each instruction set in avida.cfg. Multiple instruction sets may be included.
|
||||
</p>
|
||||
<p>For example, to include the two instruction sets contained in the files instset-heads.cfg and instset-heads-sex.cfg, these lines are placed in avida.cfg:
|
||||
</p>
|
||||
<p>
|
||||
<code>#include instset-heads.cfg</code><br />
|
||||
<code>#include instset-heads-sex.cfg</code>
|
||||
</p>
|
||||
<p>You may optionally name each instruction set as you include it. This allows you to change which file the name refers to when running avida from the command line, using the -def option. The default avida.cfg contains this line:<br>
|
||||
<code>#include INST_SET=instset-heads.cfg</code>
|
||||
</p>
|
||||
<p>This means you may change which file INST_SET refers (for example, change it to instset-heads-sex.cfg) to on the command line like this:<br>
|
||||
<code>./avida -def INST_SET instset-heads-sex.cfg</code><br>
|
||||
</p>
|
||||
<p>In this case, INST_SET is simply a variable name with no special meaning. The line might just as easily been <code>#include BOBS_YOUR_UNCLE=instset-heads.cfg</code></p>
|
||||
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Specifiying the Instruction Set for an Organism</h2>
|
||||
|
||||
<p>Organisms in an avida run may have different instruction sets. Therefore, it is necessary to specify the instruction used by each .org file. At the top of the .org file you must specify the instruction set with the <code>#inst_set</code> keyword, and the hardware type with the <code>hw_type</code> keyword. For example, default-heads.org starts with these two lines:
|
||||
</p>
|
||||
<p>
|
||||
<code>#inst_set heads_default</code><br>
|
||||
<code>#hw_type 0</code>
|
||||
</p>
|
||||
<p><b>Note:</b> the name of the instruction set may not be the same as the name of the file containing the instruction set. (Indeed, one file may contain multiple instruction sets.) The name of the instruction set is defined inside its .cfg file by the INSTSET keyword, which also defines the hardware type.
|
||||
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>The Structure of an Instruction Set File</h2>
|
||||
|
||||
<p>An instruction set consists of a name and hardware type, followed by a list of instructions that belong to
|
||||
that instruction set, each of which may be followed by a series of options that
|
||||
define how that instruction should be used. The exact format is as follows:
|
||||
</p>
|
||||
<p>
|
||||
<code>INSTSET instset-name:hw_type=$hardware_type</code><br />
|
||||
<code>INST inst-name[:options]</code><br />
|
||||
...
|
||||
</p>
|
||||
|
||||
<p>Multiple instruction sets with unique names may be defined in the same file. All <code>INST</code> statements must follow the
|
||||
<code>INSTSET</code> statement defining the instruction set.</p>
|
||||
|
||||
|
||||
<p>The following options may be specified (as <code>name=value</code>, separated by colons):
|
||||
<dl>
|
||||
<dt><strong>redundancy</strong> (default = 1)</dt>
|
||||
<dd>
|
||||
The frequency of the instruction in the set. One instruction with
|
||||
twice the redundancy of another with also have twice the probability
|
||||
of being mutated to. A redundancy of zero is allowed, and indicates
|
||||
that injected organisms are allowed to have this instruction, but
|
||||
it can never be mutated to.
|
||||
</dd>
|
||||
<dt><strong>cost</strong></dt>
|
||||
<dd>
|
||||
The number of CPU cycles required to execute this instruction. One
|
||||
is the default if this value is not specified. CPU costs will pause the
|
||||
thread that executed the costly instruction, not the whole organism and
|
||||
only decrement the pause counter each time the paused thread attempts
|
||||
to run. If multiple threads execute costly instructions, the costs and
|
||||
pause counts are handled independently (i.e. unique pause count for each thread).
|
||||
</dd>
|
||||
<dt><strong>initial_cost</strong></dt>
|
||||
<dd>
|
||||
The additional cost to be paid the first time this instruction is
|
||||
executed. This is used to lower the diversity of instructions
|
||||
inside an organism. The default value here is 0.
|
||||
</dd>
|
||||
<dt><strong>energy_cost</strong></dt>
|
||||
<dd>
|
||||
The number of Energy units required to execute this instruction. Zero is the default if this value is not specified.
|
||||
</dd>
|
||||
<dt><strong>addl_time_cost</strong></dt>
|
||||
<dd>
|
||||
The additional cost in terms of phenotype 'age', but not actual instruction cycles. The default value here is 0.
|
||||
</dd>
|
||||
<dt><strong>prob_fail</strong>
|
||||
<dd>
|
||||
The probability of this instruction not working properly. If an
|
||||
instruction fails it will simply do nothing, but still cost the
|
||||
CPU cycles to execute. The defailt probability of failure is zero.
|
||||
</dd>
|
||||
<dt><strong>inst_code</strong>
|
||||
<dd>
|
||||
String of 1's and 0's defining the numeric value of a instruction as used by certain operations that 'numberate'
|
||||
instruction sequences.
|
||||
</dd>
|
||||
<dt><strong>res_cost</strong>
|
||||
<dd>
|
||||
The cost in units (double) of COLLECT_SPECIFIC_RESOURCE stored in internal bins to execute the instruction. Organisms
|
||||
that execute an instruction with a res_cost higher than what is internally available will die. Res_cost is not
|
||||
applied if an instruction fails. In a multi-resource environment, any and all resources can be converted internally
|
||||
via reactions to a common COLLECT_SPECIFIC_RESOURCE for use with res_cost (COLLECT_SPECIFIC_RESOURCE must still be
|
||||
declared in environment file, likely with initial=0). Note that the use of res_cost typically needs to be coupled with
|
||||
RESOURCE_GIVEN_ON_INJECT and RESOURCE_GIVEN_AT_BIRTH in avida.cfg. The default res_cost is 0.
|
||||
</dd>
|
||||
<dt><strong>post_cost</strong>
|
||||
<dd>
|
||||
CPU cost to be paid AFTER the instruction is executed the first time (e.g. pseudo post-kill handling time in
|
||||
predators). Post costs are only applied if the instruction executes successfully (differs from regular costs).
|
||||
</dd>
|
||||
<dt><strong>bonus_cost</strong>
|
||||
<dd>
|
||||
The cost in units (double) of current bonus to successfully execute the instruction. bonus_cost is not
|
||||
applied if an instruction fails for some other reason. Ultimately this is similar to res_costs when converting a common,
|
||||
specific resource, but much simpiler.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<p> </p>
|
||||
<p>For example, to specify that the nand instruction is both twice as common and twice as expensive as other instructions, you would use this line:</p>
|
||||
<p><code>INST nand:redundancy=2:cost=2</code>
|
||||
|
||||
|
||||
<p> </p>
|
||||
<h2>Description of Default Instruction Set</h2>
|
||||
|
||||
<p>
|
||||
Below are the descriptions of the instructions turned on in the file
|
||||
<kbd>instset-classic.cfg</kbd>. The one-letter codes are assigned
|
||||
automatically to each instruction in the set, so if additional instructions
|
||||
are turned on, the letters given below may no longer correspond to the
|
||||
instructions they are presented with. If more than 26 instructions are in
|
||||
a set, both lowercase and capital letters will be used, and then numbers.
|
||||
Currently, no more than 62 distinct instructions will be represented by
|
||||
unique symbols.
|
||||
</p>
|
||||
<p>
|
||||
Most terminology below that may not be familiar to you has been given a
|
||||
link to a file containing its definition.
|
||||
</p>
|
||||
|
||||
<h3>(a - c) Nop Instructions</h3>
|
||||
|
||||
The instructions <code>nop-A</code> (<b>a</b>), <code>nop-B</code>
|
||||
(<b>b</b>), and <code>nop-C</code> (<b>c</b>) are no-operation
|
||||
instructions, and will not do
|
||||
anything when executed. They will, however, modifiy the behavior of the
|
||||
instruction preceeding it (by changing the [CPU](Glossary-- CPU)
|
||||
component that it affects; see also
|
||||
<a href="Glossary--Nop-Register-Notation">nop-register</a> notation and
|
||||
<a href="Glossary--Nop-Head-Notation">nop-head</a> notation) or act as part
|
||||
of a <a href="Glossary--Label">label</a> to denote positions in the
|
||||
<a href="Glossary--Genome">genome</a>.
|
||||
|
||||
|
||||
<h3>(d) <code>if-n-equ</code></h3>
|
||||
|
||||
This instruction compares the
|
||||
<a href="Glossary-- Nop-Register-Notation">?BX?</a> register to its
|
||||
<a href="Glossary--Complement-Label">complement</a>. If they are not
|
||||
equal, the next instruction (after a modifying
|
||||
<a href="Glossary--nop-instructions">no-operation</a> instruction, if one is
|
||||
present) is executed. If they are equal, that next instruction is skipped.
|
||||
|
||||
|
||||
<h3>(e) <code>if-less</code></h3>
|
||||
|
||||
This instruction compares the <a href="Glossary--Nop-Register-Notation">?BX?</a>
|
||||
register to its <a href="Glossary--Complement-Label">complement</a>. If ?BX?
|
||||
is the lesser of the pair, the next instruction (after a modifying
|
||||
<a href="Glossary--nop-instructions">no-operation</a> instruction, if one is
|
||||
present) is executed. If it is greater or equal, then that next instruction is skipped.
|
||||
|
||||
|
||||
<h3>(f) <code>pop</code></h3>
|
||||
|
||||
This instruction removes the top element from the active
|
||||
<a href="Glossary--Stack">stack</a>, and places it into the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a> register.
|
||||
|
||||
|
||||
<h3>(g) <code>push</code></h3>
|
||||
|
||||
This instruction reads in the contents of the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a> register, and places it
|
||||
as a new entry at the top of the active <a href="Glossary--Stack">stack</a>.
|
||||
The ?BX? register itself remains unchanged.
|
||||
|
||||
|
||||
<h3>(h) <code>swap-stk</code></h3>
|
||||
|
||||
This instruction toggles the active <a href="Glossary--Stack">stack</a> in
|
||||
the <a href="Glossary--CPU">CPU</a>. All other instructions that use a stack
|
||||
will always use the active one.
|
||||
|
||||
|
||||
<h3>(i) <code>swap</code></h3>
|
||||
|
||||
This instruction swaps the contents of the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a> register with its
|
||||
<a href="Glossary--Complement-Label">complement</a>.
|
||||
|
||||
|
||||
<h3>(j) <code>shift-r</code></h3>
|
||||
|
||||
This instruction reads in the contents of the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a> register, and shifts all
|
||||
of the bits in that register to the right by one. In effect, it divides the value
|
||||
stored in the register by two, rounding down.
|
||||
|
||||
|
||||
<h3>(k) <code>shift-l</code></h3>
|
||||
|
||||
This instruction reads in the contents of the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a> register, and shifts all
|
||||
of the bits in that register to the left by one, placing a zero as the new rightmost
|
||||
bit, and trunkating any bits beyond the 32 maximum. For values that require fewer
|
||||
than 32 bits, it effectively multiplies that value by two.
|
||||
|
||||
|
||||
<h3>(l) <code>inc</code> and (m) <code>dec</code></h3>
|
||||
|
||||
These instructions read in the contents of the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a>
|
||||
<a href="Glossary--Registers">register</a> and increment or decrement it by
|
||||
one.
|
||||
|
||||
<h3>(n) <code>add</code> and (o) <code>sub</code></h3>
|
||||
|
||||
These instructions read in the contents of the BX and CX
|
||||
<a href="Glossary--Registers">registers</a> and either sums them together or
|
||||
subtracts CX from BX (respectively). The result of this operation is then placed in
|
||||
the <a href="Glossary--Nop-Register-Notation">?BX?</a> register.
|
||||
|
||||
<h3>(p) <code>nand</code></h3>
|
||||
|
||||
This instruction reads in the contents of the BX and CX
|
||||
<a href="Glossary--Registers">registers</a> (each of which are 32-bit
|
||||
numbers) and performs a <a href="Glossary--Bitwise">bitwise</a> nand
|
||||
operation on them. The result of this operation is placed in the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a> register. Note that
|
||||
this is the only <a href="Glossary--Logic">logic</a> operation provided in
|
||||
the basic Avida instruction set.
|
||||
|
||||
|
||||
<h3>(q) <code>IO</code></h3>
|
||||
|
||||
This is the input/output instruction. It takes the contents of the
|
||||
<a href="Glossary--Nop-Register-Notation">?BX?</a>
|
||||
<a href="Glossary--Registers">register</a> and outputs it, checking it
|
||||
for any <a href="Glossary--Tasks">tasks</a> that may have been performed.
|
||||
It will then place a new <a href="Glossary--Input-Output">input</a> into ?BX?.
|
||||
|
||||
|
||||
<h3>(r) <code>h-alloc</code></h3>
|
||||
|
||||
This instruction allocates additional <a href="Glossary--Memory">memory</a>
|
||||
for the organism up to the maximum it is allowed to use for its offspring.
|
||||
If allocation is successful, the original memory size is loaded into the AX register.
|
||||
|
||||
|
||||
<h3>(s) <code>h-divide</code></h3>
|
||||
|
||||
This instruction is used for an organism to divide off an finnished offspring. The
|
||||
original organism keeps the state of its <a href="Glossary--Memory">memory</a>
|
||||
up until the <a href="Glossary--Heads">read-head</a>. The offspring's memory is
|
||||
initialized to everything between the read-head and the
|
||||
<a href="Glossary--Heads">write-head</a>. All memory past the write-head is
|
||||
removed entirely.
|
||||
|
||||
|
||||
<h3>(t) <code>h-copy</code></h3>
|
||||
|
||||
This instruction reads the contents of the organism's
|
||||
<a href="Glossary--Memory">memory</a> at the position of the
|
||||
<a href="Glossary--Heads">read-head</a>, and copy that to the position of the
|
||||
<a href="Glossary--Heads">write-head</a>. If a non-zero copy mutation rate is
|
||||
set, a test will be made based on this probability to determine if a
|
||||
<a href="Glossary--Mutation">mutation</a> occurs. If so, a random instruction
|
||||
(chosen from the full set with equal probability) will be placed at the write-head
|
||||
instead.
|
||||
|
||||
|
||||
<h3>(u) <code>h-search</code></h3>
|
||||
|
||||
This instruction will read in the <a href="Glossary--Label">label</a>
|
||||
the follows it, and find the location of a
|
||||
<a href="Glossary--Complement-Label">complement</a> label in the code.
|
||||
The BX <a href="Glossary--Registers">register</a> will be set to the distance
|
||||
to the complement from the current position of the
|
||||
<a href="Glossary--Heads">instruction-pointer</a>, and the CX register will
|
||||
be set to the size of the label. The <a href="Glossary--Heads">flow-head</a>
|
||||
will also be placed at the beginning of the complement label. If no label follows,
|
||||
both BX and CX will be set to zero, and the flow-head will be placed on the instruction
|
||||
immediatly following the h-search.
|
||||
|
||||
|
||||
<h3>(v) <code>mov-head</code></h3>
|
||||
|
||||
This instruction will cause the <a href="Glossary--Nop-Head-Notation">?IP?</a>
|
||||
to jump to the position in <a href="Glossary--Memory">memory</a> of the
|
||||
<a href="Glossary--Heads">flow-head</a>.
|
||||
|
||||
|
||||
<h3>(w) <code>jmp-head</code></h3>
|
||||
|
||||
This instruction will read in the value of the CX
|
||||
<a href="Glossary--Registers">register</a>, and the move the
|
||||
<a href="Glossary--Nop-Head-Notation">?IP?</a> by that fixed amount through
|
||||
the organism's <a href="Glossary--Memory">memory</a>.
|
||||
|
||||
|
||||
<h3>(x) <code>get-head</code></h3>
|
||||
|
||||
This instruction will copy the position of the
|
||||
<a href="Glossary--Nop-Head-Notation">?IP?</a> into the CX
|
||||
<a href="Glossary--Registers">register</a>.
|
||||
|
||||
|
||||
<h3>(y) <code>if-label</code></h3>
|
||||
|
||||
This instruction reads in the <a href="Glossary--Label">label</a> that
|
||||
follows it, and tests if its <a href="Glossary--Complement-Label">complement</a>
|
||||
label was the most recent series of instructions copied. If so, it executed the next
|
||||
instruction, otherwise it skips it. This instruction is commonly used for an organism to
|
||||
determine when it has finished producing its offspring.
|
||||
|
||||
|
||||
<h3>(z) <code>set-flow</code></h3>
|
||||
|
||||
This instruction moves the <a href="Glossary--Heads">flow-head</a> to the
|
||||
<a href="Glossary--Memory">memory</a> position denoted in the
|
||||
<a href="Glossary--Nop-Register-Notation">?CX?</a> register.
|
||||
|
|
@ -0,0 +1 @@
|
|||
The default instruction set file for the Heads architecture.
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
<div align="center">
|
||||
<h1>Using Internal Resources</h1>
|
||||
</div>
|
||||
|
||||
<p>Avida has the ability to allow organisms to uptake resources from the environment and keep them in a private store of "resource bins". These internal resources may then be used instead of the normal environmental resources to complete reactions.
|
||||
|
||||
<p>Most configuration of internal resource use is done with config options in avida.cfg, all of which are found in the HOARD_RESOURCE_GROUP. Some more advanced uses require modifications to the environment file as well. There is also a family of instructions which allows organisms to manipulate resources.
|
||||
|
||||
<h2> Turning on internal resources</h2>
|
||||
<p>Most internal resource code is protected by a guard to make sure it does not slow Avida down if internal resources are not being used. In order to use internal resources, you must change a line in avida.cfg:
|
||||
<pre>USE_RESOURCE_BINS 0</pre>
|
||||
to
|
||||
<pre>USE_RESOURCE_BINS 1</pre>
|
||||
|
||||
<h2> Basic resource uptake </h2>
|
||||
<div align="center">
|
||||
<img src="images/inres_basic.gif" alt="The collect instruction moves a resource from the environment to the corresponding resource bin in the organism." />
|
||||
</div>
|
||||
To remove resource from the environment and transfer it into its private store, an organism must execute the <i>collect</i> instruction (or one like it, see below). This instruction should be added to the instruction set.
|
||||
<pre>ABSORB_RESOURCE_FRACTION .0025</pre>
|
||||
This setting controls the fraction of the available environmental resource the organism may absorb. The default value is the same as the default value for the 'frac' reaction specification, so that an organism will remove the same amount of resource from the environment whether it is storing it or using it to complete a reaction.
|
||||
<pre>MAX_TOTAL_STORED -1</pre>
|
||||
This setting defines a cap on the maximum total amount of internal resource an organism can store. The default is -1, indicating that there is no cap.
|
||||
|
||||
<h2> nop-specification </h2>
|
||||
The <i>collect</i> instruction (and most of its variants) determine which resource to affect by looking at the nop instructions which follow it. This specification is robust to both the number of specifying nops (i.e. nop-A, nop-B, and nop-C, but not nop-X) in the instruction set and the number of resources in the environment file.
|
||||
|
||||
<p> <i>collect</i> always affects a single resource. If there are no nops follwing it, it chooses randomly from all the resources. Increasing levels of specification narrow down the range of the resource spectrum from which it chooses randomly. For example, in a three-nop, nine-resource system, <i>collect nop-A nop-B</i> affects resource 1 (remember resource ids are 0-based), which is usually the resource tied to NOR.
|
||||
|
||||
<div align="center">
|
||||
<img src="images/inres_specification.gif" alt="More nops after a collect instruction narrow the range from which the affected resource is chosen." />
|
||||
</div>
|
||||
|
||||
<h2> <i>collect</i> variant instructions </h2>
|
||||
|
||||
<h3> collect-unit-prob </h3>
|
||||
<div align="center">
|
||||
<img src="images/inres_collect-unit-prob.gif" alt="The collect-unit-prob instruction moves 1 unit of a resource to the corresponding internal resource bin." />
|
||||
</div>
|
||||
Resources ought to be harder to uptake as they become more scarce. The original <i>collect</i> instruction models this by uptaking a smaller amount of resource as the resource becomes more scarce. <i>collect-unit-prob</i> models the scarcity issue differently: 1 unit of resource is always collected, but the instruction may fail, and fails more frequently as the resource becomes scarce: the instruction has a probability of succeeding equal to the current units of resource available divided by the COLLECT_PROB_DIVISOR setting. This instruction ignores the ABSORB_RESOURCE_FRACTION setting.
|
||||
<pre>COLLECT_PROB_DIVISOR 1000</pre>
|
||||
This setting defines the divisor for probabilistic collect instructions, which have a chance of (current level of resource) / COLLECT_PROB_DIVISOR of succeeding -- this chance is capped at 1. As it is a divisor, it should not be set to 0.
|
||||
|
||||
<h3> destroy </h3>
|
||||
<div align="center">
|
||||
<img src="images/inres_destroy.gif" alt="The destroy instruction removes a resource from the environment without adding it to the organism's resource bin.">
|
||||
</div>
|
||||
The <i>destroy</i> instruction removes an amount of resource from the environment, but does not add it to the organism's internal resource bin. Like <i>collect</i>, the amount removed is governed by ABSORB_RESOURCE_FRACTION.
|
||||
|
||||
<h3> collect-no-env-remove </h3>
|
||||
<div align="center">
|
||||
<img src="images/inres_destroy.gif" alt="The collect-no-env-remove instruction adds resource to the internal bins without removing any from the environment." />
|
||||
</div>
|
||||
The <i>collect-no-env-remove</i> instruction adds an amount of resource to the internal resource bin of the organism, but does not remove any resource from the environment; it injects extra resource into the system. Even though no resource is removed from the environment, the amount added to the organism is still controlled by the ABSORB_RESOURCE_FRACTION setting.
|
||||
|
||||
<h3> nop-collect </h3>
|
||||
<div align="center">
|
||||
<img src="images/inres_nop-collect.gif" alt="The nop-collect instruction does nothing, but in a nop-specified way." />
|
||||
</div>
|
||||
The <i>nop-collect</i> instruction neither adds resource to the organism nor removes it from the environment. Instead, it provides a no-operation instruction to use in comparison with the other collect instructions. It should be used in place of nop-X for such comparisons; since the collect instructions are nop-specified, they effectively "eat" nops, affecting execution flow as well as dealing with resources (see the <a href="http://avida.devosoft.org/wiki/documentation/configuration-and-command-reference/avida-cfg-the-avida-configuration-file/time-slicing/" title="Time Slicing: how CPU time is distributed among organisms">MAX_LABEL_EXE_SIZE</a> config option). <i>nop-collect</i> affects execution flow in the same way.
|
||||
|
||||
<h3> collect-specific </h3>
|
||||
<div align="center">
|
||||
<img src="images/inres_collect-specific.gif" alt="The collect-specific instruction works like the collect instruction, but is not nop-specified." />
|
||||
</div>
|
||||
The <i>collect-specific</i> instruction is not nop-specified (and so should be compared to nop-X rather than nop-collect). Instead, the resource it affects is determined by the config setting COLLECT_SPECIFIC_RESOURCE.
|
||||
<pre>COLLECT_SPECIFIC_RESOURCE 0</pre>
|
||||
This setting determines which resource the <i>collect-specific</i> instruction affects. (Remember that resources are numbered from 0 in the order they appear in the environment file.) It also specifies which resource should be added to injected or newborn organisms if non-zero amounts are specified by RESOURCE_GIVEN_ON_INJECT or RESOURCE_GIVEN_AT_BIRTH. It should not be given a value outside of the range of resource ids.
|
||||
|
||||
<h3> collect-specific-ratio </h3>
|
||||
Rather than collecting a single specific resource, the <i>collect-specific-ratio</i> instruction collects some amount of all resources. By default, it collects one unit of each resource. A different ratio for a given resource can be specified with the config option NON_1_RESOURCE_RATIOS.
|
||||
<pre><nowiki>NON_1_RESOURCE_RATIOS resource_index1:amount, resource_index2:amount</nowiki></pre>
|
||||
Every time the <i>collect-specific-ratio</i> instruction is executed, the organism executing it collects one of each resource not mentioned in the config setting and the amount specified after the colon for each other resource. (Remember that resources are numbered from 0 in the order they appear in the environment file - resource_index should not be a value outside of the range of resource ids). For instance, a config setting like this:
|
||||
<pre><nowiki>NON_1_RESOURCE_RATIOS 1:2, 3:.5</nowiki></pre>
|
||||
Would result in the organism collecting 1 unit of resource 0, 2 units of resource 1, .5 units of resource 3, and 1 unit of any additional resources.
|
||||
|
||||
<h2> Using internal resources to complete reactions </h2>
|
||||
<div align="center">
|
||||
<img src="images/inres_using.gif" alt="An organism will use internal resources to complete reactions when there is more internal resource than available environmental resource." />
|
||||
</div>
|
||||
Once an organism has internal resources in its resource bins, it may use internal resources instead of environmental resources to complete reactions. An organism will do this when the amount of environmental resources available is less than the amount of internal resource available. How much of the internal resource is used is controlled with the USE_STORED_FRACTION config setting. The amount of environmental resource which is considered may be controlled by the ENV_FRACTION_THRESHOLD config setting.
|
||||
<pre>USE_STORED_FRACTION 1.0</pre>
|
||||
This setting controls the fraction of the internal resource that the organism will use to complete a reaction. By default this 1.0, meaning that the organism will use all the available internal resource to complete a reaction. As a fraction, this value should remain between 0.0 and 1.0.
|
||||
<pre>ENV_FRACTION_THRESHOLD 1.0</pre>
|
||||
This setting controls how much of the available environmental resource the organism should consider when deciding which type of resource to use. By default it is set to 1.0, indicating that the organism should consider all the available environmental resource. As a fraction, this value should remain between 0.0 and 1.0
|
||||
|
||||
<h3> Forcing internal resource use </h3>
|
||||
<div align="center">
|
||||
<img src="images/inres_forcing.gif" alt="If environmental resources are invisible to the organism, it will be forced to use only internal resources to complete reactions." />
|
||||
</div>
|
||||
It is possible to force organisms to always use internal resources to complete reactions -- consequently forcing the population to either use the <i>collect</i> instruction or become pure self-replicators. This can be done by forcing the organisms to believe that no environmental resource is ever available, setting:
|
||||
<pre>ENV_FRACTION_THRESHOLD 1.0</pre>
|
||||
to
|
||||
<pre>ENV_FRACTION_THRESHOLD 0.0</pre>
|
||||
As a precaution, you should also change the 'frac' specification of the REACTIONs in your environment file to be 0.0 (rather than the common .0025 or the default 1.0).
|
||||
|
||||
<h2> Resource sources and sinks </h2>
|
||||
<p>The most common source of internal resource is via <i>collect</i> or one of its variants, in most cases from the environment (but see <i>collect-no-env-remove</i>). However, an organism may also receive new internal resource when it is injected (if RESOURCE_GIVEN_ON_INJECT is set above 0) or when it is born (if RESOURCE_GIVEN_AT_BIRTH is set above 0).
|
||||
<pre>RESOURCE_GIVEN_ON_INJECT 0</pre>
|
||||
This setting specifies the units of the resource given by COLLECT_SPECIFIC_RESOURCE that should be added to an organism when it is injected. The default is to add no resource.
|
||||
<pre>RESOURCE_GIVEN_AT_BIRTH 0</pre>
|
||||
This setting specifies the units of the resource given by COLLECT_SPECIFIC_RESOURCE that should be added to an organism when it is born. The default is to add no resource.
|
||||
|
||||
<div align="center">
|
||||
<img src="images/inres_split.gif" alt="When an organism splits, the two daughter cells each recieve half of the internal resources.">
|
||||
</div>
|
||||
<p>When an organism splits into two daughter organisms, each daughter gets half of the original internal resource store if SPLIT_ON_DIVIDE is set. (If it is set to 0, the resource disappears.)
|
||||
<pre>SPLIT_ON_DIVIDE 1</pre>
|
||||
This setting determines whether the mother cell's resources should be split between its two daughter cells on division. It defaults to true; if set to 0 (false), the mother cell's internal resource simply disappears. This setting has not been tested with DIVIDE_METHODs other than 1.
|
||||
|
||||
<div align="center">
|
||||
<img src="images/inres_death.gif" alt="When an organism dies, its internal resources are returned to the environment." />
|
||||
</div>
|
||||
<p>When an organism dies, its internal resources are returned to the environment if RETURN_STORED_ON_DEATH is set.
|
||||
<pre>RETURN_STORED_ON_DEATH</pre>
|
||||
This setting determines whether an organsim's internal resources are returned to the environment when the organism dies. It defaults to true; if set to 0 (false), the resource simply disappears. This setting has not been tested with deaths not by old age or being overwritten.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
<h1 id="introductiontoparasitesinavida">Introduction to Parasites in Avida</h1>
|
||||
<p>This introduction assumes some basic knowledge about Avida. In particular, familiarity with the basic organism and hardware as described <a href="https://github.com/devosoft/avida/wiki/Default-Ancestor-Guided-Tour">here</a> will be very useful to have.</p>
|
||||
<h2 id="verybriefoverviewofthetranssmthardware">(Very) Brief Overview of the TransSMT Hardware</h2>
|
||||
<p>With that said, parasites currently do not work in the default hardware but rather one that supports better threading capabilities – the TransSMT hardware. The differences aren’t huge, but they deserve their own documentation. Instead, I will just highlight major differences between the hardware types important for parasites, namely memoryspaces and threads.</p>
|
||||
<h4 id="memoryspaces">Memory Spaces</h4>
|
||||
<p>Memory spaces are regions of memory reserved for genetic instructions such as an individual’s genome. To access these memory spaces, organisms execute the <code>Set-Memory</code> instruction followed by one or more <code>Nop</code> instructions specifying which space to use. In this hardware, the genome copy produced during self-replication must also be in a seperate memory space, as well as any thread processes an individual spawns.</p>
|
||||
<h4 id="threads">Threads</h4>
|
||||
<p>Threads in this hardware are distinct code sequences that are executed either in parallel, where all threads execute an instruction per CPU cycle awarded to an individual, or round-robin, where a single instruction from a single thread is exected per awarded CPU cycle and each thread executes in turn. The number of threads an organism is allowed to have, as well as how they are scheduled is controlled by the following config options in the <code>avida.cfg</code> file.</p>
|
||||
<ul>
|
||||
<li>MAX_CPU_THREADS 1 # Maximum number of Threads a CPU can spawn</li>
|
||||
<li>THREAD_SLICING_METHOD 0 # 0 = One thread executed per time slice. # 1 = All threads executed each time slice.</li>
|
||||
</ul>
|
||||
<h2 id="parasitesinthetranssmthardware">Parasites in the TransSMT Hardware</h2>
|
||||
<p>Parasites in Avida are almost identical to hosts, self-replicating by copying their genome instruction-by-instruction into a new memory space. However, instead of dividing this new genome off into the world, parasites attempt to infect a <strong>random</strong> organism in its host’s neighborhood (globaly if <code>BIRTH_METHOD=4</code> or <code>WORLD_GEOMETRY=7</code>, and honoring the <code>WORLD_GEOMETRY</code> if <code>BIRTH_METHOD</code> is set to any other value) with their offspring parasite genome, becoming a new thread on the host organism. Parasites attempt infection by calling the <code>Inject</code> instruction, which is also <code>Nop</code>-modified to identify the memory space the parasitic thread should occupy.</p>
|
||||
<p>In order for infection to succede, the host must be able to accept a new thread in the memory space the parasite is attempting to occupy. This means the host must have fewer than <code>MAX_CPU_THREADS</code> and that the host has not used the memory space specified by the <code>Inject</code> instruction. More than one parasite per host is not currently supported, thus we typicaly set <code>MAX_CPU_THREADS=2</code>. We can eliminate the effect of host-parasite coevolution via memory space allocation and specification (and as any unforseen side-effects such as parasites overwriting host offspring when specificying a particular memory space) by giving parasites memory spaces entirely seperate from their host’s (<code>PARASITE_MEM_SPACES=1</code>).</p>
|
||||
<p>Parasites as well as hosts can perform logic tasks, and we can use their task-based phenotypes to implement additional mechanisms determining if infection will succeed or not. The config option <code>INFECTION_MECHANISM</code> already has several mechanisms implemented. The implemented options have the following behavior:</p>
|
||||
<ul>
|
||||
<li>0 - Infection will succeed independent of task-based phenotypes</li>
|
||||
<li>1 - Infection will succeed if the parasite and host have at least one overlapping task (Inverse Gene-for-Gene)</li>
|
||||
<li>2 - Infection will succeed if the parasite does at least one task the host does not perform</li>
|
||||
<li>3 - Infection will succeed if the parasite and host do the same tasks (Matching Alleles)</li>
|
||||
<li>4 - Infection will succeed if the parasite performs all the tasks the host does as well as at least one additional task (Gene-for-Gene)</li>
|
||||
</ul>
|
||||
<p>To have more control over how many CPU cycles a parasite steals from it’s host, <code>PARASITE_VIRULENCE</code> determines the probability that a CPU cycle will be given to the parasite. Thus, when this option is set to 1, the parasite is completely virulent and overtakes all of its host’s CPU cycles. It is also possible to let the parasites evolve their own virulence by setting <code>VIRULENCE_SOURCE=1</code>, and choosing values for both <code>VIRULENCE_MUT_RATE</code>, which controls the probability of mutating a parasites virulence when a new parasite is born, and <code>VIRULENCE_SD</code>, which is the standard deviation of a normal distribution used to determine how much virulence changes when it mutates.</p>
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<img src="images/host-parasite-both-small.png" alt="Depiction of a Host-Parasite Interaction" />
|
||||
<p> </p>
|
||||
<p> </p>
|
||||
<p> Depiction of a Host-Parasite Interaction</p>
|
||||
<p> </p>
|
||||
<h2 id="eventstypicallyusedwithparasites">Events Typically Used With Parasites</h2>
|
||||
<p><code>InjectParasite</code> is typically called near the beginning of a run to infect a range of cells. It takes a parasite organism file, the memory space label, and the range of cells which should be infected.</p>
|
||||
<p><code>PrintParasiteTasksData</code> and <code>PrintHostTasksData</code> print the tasks performed by parasites and hosts respectively. Similarly, <code>PrintHostPhenotypeData</code> and <code>PrintParasitePhenotypeData</code> split up the phenotype data, such as the Shannon Diversity and Richness of unique host and parasite phenotypes.</p>
|
||||
<h2 id="typicalconfigsettings">Typical Config Settings</h2>
|
||||
<ul>
|
||||
<li>BIRTH_METHOD 4 #Population is well-mixed</li>
|
||||
<li>INJECT_METHOD 1 #Parasite thread is reset on successful infection</li>
|
||||
<li>MAX_CPU_THREADS 2 #Only allow one parasite per host</li>
|
||||
<li>INFECTION_MECHANISM 1 #Parasites infect hosts when they have at least one overlapping task</li>
|
||||
<li>PARASITE_VIRULENCE 0.8 #Parasites steal 80$ of their host’s CPU cycles</li>
|
||||
<li>VIRULENCE_SOURCE 0 #Parasites use virulence value from config, instead of evolving it</li>
|
||||
<li>PARASITE_MEM_SPACES 1 #Parasites get their own memory spaces</li>
|
||||
<li>PARASITE_NO_COPY_MUT 1 #Parasites don’t use copy mutation rates, so they can have independent mutation rates</li>
|
||||
<li>REQUIRE_SINGLE_REACTION 1 #Require hosts to perform at least one succesful reaction to reproduce</li>
|
||||
</ul>
|
||||
<p> </p>
|
||||
<p>A set of complete config files and ancestral organisms can be found <a href="https://github.com/zamanlh/AvidaConfigs">here</a>.</p>
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,82 @@
|
|||
INPUTS READ
|
||||
Register Functions:
|
||||
1st register == habitat type sought
|
||||
2nd register == travel/sight distance sought
|
||||
3rd register == type of search
|
||||
4th register == resource/org id sought
|
||||
|
||||
Habitat
|
||||
0 == food
|
||||
1 == hills
|
||||
2 == walls
|
||||
3 == hidden resources (hidden from a distance)
|
||||
4 == unhidden dens
|
||||
-2 == organisms
|
||||
fail if == 3 (hidden nests)
|
||||
|
||||
-defaults dependent on organisms type
|
||||
-for pred, default habitat == -2 if invalid habitat input
|
||||
-for prey, default habitat == 0 if invalid habitat input
|
||||
|
||||
Distance
|
||||
-default to 1 if low invalid number (aka negative) input
|
||||
-default to half-log-axis-of-world if high number > half-long-axis
|
||||
|
||||
Search Type
|
||||
-behavior dependent on habitat used
|
||||
-if habitat == 0 or 1 or 2 or 4:
|
||||
0 = look for closest edible res, closest hill/wall, or closest den (values >=1)
|
||||
1 = count # edible cells/walls/hills across entire distance used (values >=1)
|
||||
-1 = total value of resources of habitat used in cells across entire distance used
|
||||
|
||||
-if habitat == -2:
|
||||
0 = closest any org
|
||||
1 = closest predator
|
||||
2 = count predators
|
||||
-1 = closest prey
|
||||
-2 = count prey
|
||||
|
||||
-default to 0 (closest) if invalid input
|
||||
|
||||
ID
|
||||
-find instances of resource with specified resource or org id
|
||||
-when searching for a specific organism, search type is ignored
|
||||
-when searching for a valid specific resource (food/hill/wall/den), the actual habitat type of that resource will be used instead of the input habitat type (if there is a mismatch)
|
||||
|
||||
-default to -1 (no specific target / evaluate all instances of habitat sought) if invalid input
|
||||
|
||||
|
||||
|
||||
OUTPUTS WRITTEN
|
||||
Register Functions:
|
||||
1st register == habitat used
|
||||
2nd register == travel/sight distance used
|
||||
3rd register == search type used
|
||||
4th register == resource / org id used
|
||||
5th register == count seen
|
||||
6th register == values seen
|
||||
7th register == id seen
|
||||
8th register == org forage target seen
|
||||
|
||||
ITEM NOT SEEN (default register return values):
|
||||
1st register == habitat used
|
||||
2nd register == -1
|
||||
3rd register == search type used
|
||||
4th register == resource / org id used
|
||||
5th register == 0
|
||||
6th register == -9
|
||||
7th register == -9
|
||||
8th register == -9
|
||||
|
||||
ITEM SEEN (overwriting/adding to defaults):
|
||||
2nd register == distance used or distance to first object matching search and habitat type
|
||||
5th register == count of organism or resource/hill/wall/den cells with value >=1
|
||||
-will be 1 if search type specified find nearest
|
||||
-will be 1 if looking for (and found) specific organism
|
||||
6th register == org current bonus for first organism (of correct type) seen
|
||||
or == summed value of all cells containing resource type searched for
|
||||
7th register == group id for first organism (of correct type) seen
|
||||
or == resource id of first resource of type searched for
|
||||
8th register == forage target for first organism (of correct type) seen
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
<p>These settings control how and when mutations occur in organisms. The array of options is dizzying, but only the most commonly used are detailed here. Except that <code>POINT_MUT_PROB</code> isn't actually commonly used.</p>
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>POINT_MUT_PROB</code></strong></td>
|
||||
<td>Point mutations (sometimes referred to as "cosmic ray" mutations) occur every update; the rate set here is a probability for each site that it will be mutated each update. In other words, this should be a very low value if it is turned on at all. If a mutation occurs, that site is replaced with a random instruction. In practice this also slows Avida down if it is non-zero because it requires so many random numbers to be tested every update.</td>
|
||||
</tr>
|
||||
<tr class="important">
|
||||
<td valign="top"><strong><code>COPY_MUT_PROB</code></strong></td>
|
||||
<td>The copy mutation probability is tested each time an organism copies a single instruction. If a mutation occurs, a random instruction is copied to the destination. In practice this is the most common type of mutations that we use in most of our experiments. The default value is <code>0.0075</code>, but this is actually higher than you want to use; it is designed to produce pretty results when showing off the viewer. <strong>The value we commonly use for our experiments is <code>0.0025</code>.</strong></td>
|
||||
</tr>
|
||||
<tr class="important">
|
||||
<td valign="top"><strong><code> DIV_INS_PROB <br />DIV_DEL_PROB </code></strong></td>
|
||||
<td>These probabilities are tested once per gestation cycle (when an organism is first born) at each position where an instruction could be inserted or deleted, respectively. Each of these mutations change the genome length. Deletions just remove an instruction while insertions add a new, random instruction at the position tested. Multiple insertions and deletions are possible each generation. By default these mutations are turned off.</td>
|
||||
</tr>
|
||||
<tr class="important">
|
||||
<td valign="top"><strong><code> DIVIDE_MUT_PROB <br />DIVIDE_INS_PROB <br />DIVIDE_DEL_PROB </code></strong></td>
|
||||
<td>Divide mutation probabilities are tested when an organism is being divided off from its parent. If one of these mutations occurs, a random site is picked for it within the genome. At most one divide mutation of each type is possible during a single divide. By default, <code>DIVIDE_MUT_PROB</code> is turned off, and both <code>DIVIDE_INS_PROB</code> and <code>DIVIDE_DEL_PROB</code> are set to <code>0.05</code>, which is a value we often use in our experiments. If you want your organisms never to change in length, obviously, you should turn these insertion and deletion mutations off! (This is not the only thing you need to do; see <a href="https://github.com/devosoft/avida/wiki/Setting-up-fixed-length-organisms" title="How to Set Up Fixed-Length Organisms">Fixed-Length Organisms</a>.)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
See the avida.cfg file itself for more mutation settings (these are all off by default): <code>COPY_INS_PROB, COPY_DEL_PROB, COPY_UNIFORM_PROB, COPY_SLIP_PROB, DIV_MUT_PROB, DIV_UNIFORM_PROB, DIVIDE_UNIFORM_PROB, DIVIDE_SLIP_PROB, DIVIDE_POISSON_MUT_MEAN, DIVIDE_POISSON_INS_MEAN, DIVIDE_POISSON_DEL_MEAN, DIVIDE_POISSON_SLIP_MEAN, INJECT_INS_PROB, INJECT_DEL_PROB, INJECT_MUT_PROB, SLIP_FILL_MODE, SLIP_COPY_MODE, PARENT_MUT_PROB, SPECIAL_MUT_LINE, META_COPY_MUT, META_STD_DEV</code>, and MUT_RATE_SOURCE. Whew.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
<p>This section covers tests that are (mostly) very CPU intensive, but allow for Avida experiments that would not be possible in any other system. Basically, each time a mutation occurs, we can run the resulting organism in a test CPU, and determine if that effect of the mutation was lethal, detrimental, neutral, or beneficial. This section allows us to act on this. (Note that as soon as anything here is turned on, the mutations need to be tested. Turning multiple settings on will not cause additional speed decrease)</p>
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> REVERT_FATAL <br />REVERT_DETRIMENTAL <br />REVERT_NEUTRAL <br />REVERT_BENEFICIAL </code></strong></td>
|
||||
<td>When a mutation occurs of the specified type, the number listed next to that entry is the probability that the mutation will be reverted. That is, the child organism's genome will be restored as if the mutation had never occurred. This allows us both to manually manipulate the abundance of certain mutation types, or to entirely eliminate them.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> STERILIZE_FATAL <br />STERILIZE_DETRIMENTAL <br />STERILIZE_NEUTRAL <br />STERILIZE_BENEFICIAL </code></strong></td>
|
||||
<td>The sterilize options work similarly to revert; the difference being that an organism never has its genome restored. Instead, if the selected mutation category occurs, the child is sterilized so that it still takes up space, but can never produce an offspring of its own.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>STERILIZE_UNSTABLE</code></strong></td>
|
||||
<td>If this toggle is set, organisms <em>must</em> be able to produce exact copies of themselves or else they are sterilized and cannot produce any offspring. An organism that naturally (without any external effects) produces an inexact copy of itself is said to have implicit mutations. If this flag is set, explicit mutations (as described in the mutations section above) can still occur. This particular setting does not seem to be terribly CPU intensive. <strong>You must turn this setting on to ensure <a href="http://avida.devosoft.org/wiki/documentation/configuration-and-command-reference/fixed-length-organisms/" title="How to Set Up Fixed-Length Organisms">fixed-length organisms</a>.</strong></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
== Congratulations, you downloaded Avida! DON'T PANIC! ==
|
||||
Next question, how do you run it?
|
||||
|
||||
Like the rest of this wiki, the page is under construction. Please bear with us as we continue to expand this section.
|
||||
|
||||
===Purpose:===
|
||||
To help make Avida available to new users without an in-person tutorial of what to do and how to do it.
|
||||
|
||||
Avida in its current state runs from the command line on Macs and Linux distributions. If you don't know how to use the command line here are a couple of tutorials you can use to get familiar:
|
||||
|
||||
Mac users:
|
||||
* http://osxdaily.com/2007/02/07/basic-command-line-utilities-tips-commands/
|
||||
* http://smokingapples.com/software/tutorials/mac-terminal-tips/
|
||||
|
||||
Linux users:
|
||||
* http://freeengineer.org/learnUNIXin10minutes.html
|
||||
|
||||
Back to Avida. Assuming you downoaded a stable branch and not a development one, using your terminal, locate the directory(folder) you put Avida in.
|
||||
|
||||
'''To run''' just plain Avida type: ./avida
|
||||
To quit Avida use: ctrl-c
|
||||
To run Avida with the viewer type (tab-completion, its useful): ./avida-viewer
|
||||
To quit Avida from the viewer use: q
|
||||
|
||||
If you are using the viewer and want information on all the commands head over to Avida-Viewer.
|
||||
|
||||
===Configuration Files===
|
||||
|
||||
Now that you have run Avida, lets look at some of the other files included with the program. (Non command line users, the command to look at the files in the directory is: ls ) The following files should be present in the directory:
|
||||
|
||||
* analyze.cfg
|
||||
* avida.cfg
|
||||
* environment.cfg
|
||||
* events.cfg
|
||||
* instset-heads.cfg
|
||||
* instset-heads-sex.cfg
|
||||
* instset-transsmt.cfg
|
||||
* instset-transsmt.cfg
|
||||
* default-heads.org
|
||||
* default-heads-sex.org
|
||||
* default-transsmt.org
|
||||
|
||||
Lets break that down now. Default Avida runs use: avida.cfg, environment.cfg, events.cfg, instset-heads.cfg and default-heads.org. The other files are for special cases such as sexual reproduction and other things this writer does not understand.
|
||||
|
||||
===avida.cfg:===
|
||||
|
||||
This file is really really big. Don't let it scare you. Most of it you can ignore to start. There are a few things you might want to look at. Open the file with your favorite (or your UNIX guru's favorite) text editor from the command line (nano, emacs, vi) to be hip or be a square and use a GUI like TextEdit, TextWrangler, or gedit. Back to things you can change in avida.cfg. There are three sections Topology, Mutation and Reproduction Group. Each section is marked off by ###name###.
|
||||
|
||||
Topology has 3 items of interest to new users: WORLD_X, WORLD_Y & WORLD_GEOMETRY. X & Y control the size of world, and geometry controls how the grid is set up (torodial, bounded, etc). World size inevitably limits the population size while the geometry effects the placement of new offspring.
|
||||
Mutation has many items of interest to new users. One of the first things to try changing in this section is the mutation rate, per copy. The default is set to 0.0075 mutations per instruction written during replication. This is much higher than most researchers use. Many researchers (that I know) 0.0025 for this setting. If you are feeling adventurous you can change the type of mutations ( insertion, deletion, slip etc). Refer to the Mutation Settings for more information/ideas.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
Avida is a software platform for experiments with self-replicating and evolving computer programs. It provides detailed control over experimental settings and protocols, a large array of measurement tools, and sophisticated methods to analyze and post-process experimental data.
|
||||
|
||||
In Avida, each digital organism is a self-contained computing automaton that has the ability to construct new automata. The organism is responsible for building the genome (computer program) that will control its offspring automaton and handing that genome to the Avida world. Avida will then construct virtual hardware for the genome to be run on and determine how this new organism should be placed into the population. In a typical Avida experiment, a successful organism attempts to make an identical copy of its own genome, and Avida randomly places that copy into the population, typically by replacing another member of the population.
|
||||
|
||||
In principle, the only assumption made about these self-replicating automata in the core Avida software is that their initial state can be described by a string of symbols (their genome) and that it is possible through processing these symbols to autonomously produce offspring organisms. However, in practice our work has focused on automata with a simple [http://en.wikipedia.org/wiki/Von_Neumann_architecture von Neumann architecture] that operate on an assembly-like language inspired by the Tierra system. Future research projects will likely have us implement additional organism instantiations to allow us to explore additional biological questions.
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
<table border="1" cellpadding="2">
|
||||
<tr><th>Keyword</th><th>Description</th></tr>
|
||||
<tr><td><code>update</code</td><td>Current Update</td></tr>
|
||||
<tr><td><code>sub_update</code</td><td>Instructions executed within update</td></tr>
|
||||
<tr><td><code>generation</code</td><td>Average Generation in Population</td></tr>
|
||||
<tr><td><code>entropy</code</td><td>Genotype Entropy (Diversity)</td></tr>
|
||||
<tr><td><code>species_entropy</code</td><td>Species Entropy (Diversity)</td></tr>
|
||||
<tr><td><code>energy</code</td><td>Average Inferiority (Energy)</td></tr>
|
||||
<tr><td><code>dom_merit</code</td><td>Ave Merit of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_gest</code</td><td>Ave Gestation Time of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_fitness</code</td><td>Ave Fitness of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_repro</code</td><td>Ave Repro-Rate of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_length</code</td><td>Genome Length of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_copy_length</code</td><td>Copied Length of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_exe_length</code</td><td>Executed Length of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_id</code</td><td>ID of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_name</code</td><td>Name of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_births</code</td><td>Birth Count of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_breed_true</code</td><td>Breed-True Count of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_breed_in</code</td><td>Breed-In Count of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_breed_out</code</td><td>Breed-Out Count of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_num_cpus</code</td><td>Abundance of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_depth</code</td><td>Tree Depth of Dominant Genotype</td></tr>
|
||||
<tr><td><code>dom_sequence</code</td><td>Sequence of Dominant Genotype</td></tr>
|
||||
<tr><td><code>num_births</code</td><td>Count of Births in Population</td></tr>
|
||||
<tr><td><code>num_deaths</code</td><td>Count of Deaths in Population</td></tr>
|
||||
<tr><td><code>breed_in</code</td><td>Count of Non-Breed-True Births</td></tr>
|
||||
<tr><td><code>breed_true</code</td><td>Count of Breed-True Births</td></tr>
|
||||
<tr><td><code>bred_true</code</td><td>Count of Organisms that have Bred True</td></tr>
|
||||
<tr><td><code>num_cpus</code</td><td>Count of Organisms in Population</td></tr>
|
||||
<tr><td><code>num_genotypes</code</td><td>Count of Genotypes in Population</td></tr>
|
||||
<tr><td><code>num_threshold</code</td><td>Count of Threshold Genotypes</td></tr>
|
||||
<tr><td><code>num_species</code</td><td>Count of Species in Population</td></tr>
|
||||
<tr><td><code>thresh_species</code</td><td>Count of Threshold Species</td></tr>
|
||||
<tr><td><code>num_lineages</code</td><td>Count of Lineages in Population</td></tr>
|
||||
<tr><td><code>num_parasites</code</td><td>Count of Parasites in Population</td></tr>
|
||||
<tr><td><code>num_no_birth</code</td><td>Count of Childless Organisms</td></tr>
|
||||
<tr><td><code>tot_cpus</code</td><td>Total Organisms ever in Population</td></tr>
|
||||
<tr><td><code>tot_genotypes</code</td><td>Total Genotypes ever in Population</td></tr>
|
||||
<tr><td><code>tot_threshold</code</td><td>Total Threshold Genotypes Ever</td></tr>
|
||||
<tr><td><code>tot_species</code</td><td>Total Species ever in Population</td></tr>
|
||||
<tr><td><code>tot_lineages</code</td><td>Total Lineages ever in Population</td></tr>
|
||||
<tr><td><code>ave_repro_rate</code</td><td>Average Repro-Rate (1 / Gestation)</td></tr>
|
||||
<tr><td><code>ave_merit</code</td><td>Average Merit</td></tr>
|
||||
<tr><td><code>ave_age</code</td><td>Average Age</td></tr>
|
||||
<tr><td><code>ave_memory</code</td><td>Average Memory Used</td></tr>
|
||||
<tr><td><code>ave_neutral</code</td><td>Average Neutral Metric</td></tr>
|
||||
<tr><td><code>ave_lineage</code</td><td>Average Lineage Label</td></tr>
|
||||
<tr><td><code>ave_gest</code</td><td>Average Gestation Time</td></tr>
|
||||
<tr><td><code>ave_fitness</code</td><td>Average Fitness</td></tr>
|
||||
<tr><td><code>ave_gen_age</code</td><td>Average Genotype Age</td></tr>
|
||||
<tr><td><code>ave_length</code</td><td>Average Genome Length</td></tr>
|
||||
<tr><td><code>ave_copy_length</code</td><td>Average Copied Length</td></tr>
|
||||
<tr><td><code>ave_exe_length</code</td><td>Average Executed Length</td></tr>
|
||||
<tr><td><code>ave_thresh_age</code</td><td>Average Threshold Genotype Age</td></tr>
|
||||
<tr><td><code>ave_species_age</code</td><td>Average Species Age</td></tr>
|
||||
<tr><td><code>max_fitness</code</td><td>Maximum Fitness in Population</td></tr>
|
||||
<tr><td><code>max_merit</code</td><td>Maximum Merit in Population</td></tr>
|
||||
</table>
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
This page is a list of random trivia that you probably wish you would have known *before* your experiments failed for an obscure reason:
|
||||
|
||||
* Printing genomes during a run changes the outcome of the run. Printing genomes passes orgs through the test cpu. The test cpu process pulls random numbers from the context. Thus, a run cannot be repeated if events calling print genomes are introduced, removed, or otherwise changed.
|
||||
* The ZeroMutations action does not work on update 0. It gets overridden by the configs. It also does not take effect immediately. Or rather, it immediately sets all mutation rates to zero -- but these can only take effect when the organism actually checks them; in many cases, this is only when an organism divides (see [Mutations Settings](Mutations-Settings). Technically you won't have a 0 mutation rate until all the currently-living organisms have been replaced.
|
||||
* The default behavior of BIRTH_METHOD=3 (replace empty local cells) is to replace the parent if no cells are empty. (Generally, if you wish to allow only empty cells, you must also set ALLOW_PARENT to 0. However, this does not work for BIRTH_METHOD=3 yet.)
|
||||
* The default behavior for what happens when demes divide (DEMES_DIVIDE_METHOD=0) is for *both* the source and target deme to be replaced.
|
||||
* Selecting to leave the state of the mother untouched (DIVIDE_METHOD=0) in fact only leaves part of the mother's state untouched. Specifically, it leaves the pointers and register values intact. Almost everything else is reset, though.
|
||||
* If you have a limited spatial resource with no diffusion that is inflowing on a part of the grid with no organisms (an empty deme for example), it's quantity of resource in the environment doesn't get reported, despite the rate of inflow. (AWC -- 3/29/12)
|
||||
* When offspring are allocated, their genomes are initialized to be entirely nop-A instructions. As a result, the count of nop-A across all genomes does not actually reflect the frequency with which nop-A is being used, because it includes these placeholder nop-As from offspring that are in the process of being created.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
These settings control how creatures are born and die in Avida.
|
||||
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>BIRTH_METHOD</code></strong></td>
|
||||
<td>The birth method sets how the placement of a child organism is determined. Currently, there are six ways of doing this -- the first four (0-3) are all grid-based (offspring are only placed in the immediate neighborhood), and the last two (4-5) assume a well-stirred population. In all non-random methods, empty sites are preferred over replacing a living organism. See the avida.cfg file itself for details.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> DEATH_METHOD <br />AGE_LIMIT </code></strong></td>
|
||||
<td>By default, replacement is the only way for an organism to die in Avida. However, if a death method is set, organisms will die of old age. In method one, organisms will die when they reach the user-specified age limit. In method 2, the age limit is a multiple of their length, so larger organisms can live longer.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>ALLOC_METHOD</code></strong></td>
|
||||
<td>During the replication process in the default virtual CPU, parent organisms must allocate memory space for their child-to-be. Before the child is copied into this new memory, it must have an initial value. Setting the alloc method to zero sets this memory to a default instruction (typical nop-A). Mode 1 leaves it uninitialized (and hence keeps the contents of the last organism that inhabited that space; if only a partial copy occurs, the child is a hybrid if the parent and the dead organism, hence the name necrophilia). Mode 2 just randomizes each instruction. This means that the organism will behave unpredictably if the uninitialized code is executed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><strong><code>DIVIDE_METHOD</code></strong></strong></td>
|
||||
<td>When a divide occurs, does the parent divide into two children, or else do we have a distinct parent and child? The latter method will allow more age structure in a population where an organism may behave differently when it produces its second or later offspring.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>GENERATION_INC_METHOD</code></strong></td>
|
||||
<td>The generation of an organism is the number of organisms in the chain between it and the original ancestor. Thus, the generation of a population can be calculated as the average generation of the individual organisms. When a divide occurs, the child always receives a generation one higher than the parent, but what should happen to the generation of the parent itself? In general, this should be set the same as divide method.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
See the avida.cfg file for further settings: <code>DIVIDE_FAILURE_RESETS, PREFER_EMPTY, ALLOW_PARENT, DISPERSAL_RATE, DEATH_PROB, AGE_LIMIT, AGE_DEVIATION, EPIGENETIC_METHOD, RESET_INPUTS_ON_DIVIDE, INHERIT_MERIT,</code> and <code>INHERIT_MULTITHREAD</code>.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
These settings control internal resources for organisms: how much can be collected at once, limitations on the amount that can be stored, how the internal resources are used to acquire task rewards, and the internal resource state of new organisms. Details are available in the avida.cfg file itself.
|
||||
|
||||
For more information on resource uptake, see <a href="Internal-resources" title="Internal Resources: an explanation and guide to use">Internal Resources: an explanation and guide to use</a>.
|
||||
|
||||
See avida.cfg for these settings: <code>USE_RESOURCE_BINS, ABSORB_RESOURCE_FRACTION, MULTI_ABSORB_TYPE, MAX_TOTAL_STORED, USE_STORED_FRACTION, ENV_FRACTION_THRESHOLD, RETURN_STORED_ON_DEATH, SPLIT_ON_DIVIDE, COLLECT_SPECIFIC_RESOURCE, RESOURCE_GIVEN_ON_INJECT</code>, and <code>RESOURCE_GIVEN_AT_BIRTH</code>.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
Example analyze programs, with explanations.
|
||||
|
||||
* [[Analyze Mode : Working with Batches|Working With Batches]]
|
||||
* [[Analyze Mode : Testing a Genome Sequence|Testing a Genome Sequence]]
|
||||
* [[Analyze Mode : Using Variables|Using Variables]]
|
||||
* [[Analyze Mode : Finding Lineages|Finding Lineages]]
|
||||
* [[Analyze Mode : Building Your Own Commands|Building Your Own Commands]]
|
||||
* [[Analyze Mode : Try It Yourself Exercises|Try It Yourself Exercises]]
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
In almost all of our experiments, organisms that are all the same length are easier to analyze. We are often willing to be a little less natural to be much more understandable! Here are the avida.cfg settings you will need to change from the default:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td><code>DIVIDE_INS_PROB</code> and <code>DIVIDE_DEL_PROB</code></td>
|
||||
<td>Insertion and deletion mutations should be turned off; <strong>change these settings to 0.0</strong>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>OFFSPRING_SIZE_RANGE</code></td>
|
||||
<td>Offspring should be exactly the same size as their parents; <strong>change this setting to 1.0</strong></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Although technically not necessary to keep organisms at a fixed length, there is one more option you probably want to change. One of the main reasons to use fixed length organism is to avoid having to calculate alignments -- you can just line the genomes up. Without the <code>STERILIZE_UNSTABLE</code> option, organisms may have bizarre implicit mutations which break the assumptions of this easy alignment.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td><code>STERILIZE_UNSTABLE</code></td>
|
||||
<td>Sometimes organisms have messed-up reproduction cycles that actually causes them to grow or shrink by copying an instruction multiple times or skipping over it entirely. These are not insertion and deletion caused by the process of division, but inherent in the organism's copy loop, so they are not turned off when you turn off <code>DIVIDE_INS_PROB</code> and <code>DIVIDE_DEL_PROB</code>. Avida can, however, check for organisms that are not able to make perfect copies of themselves (i.e. before mutations are imposed) and sterilize them so they do not produce offspring, and this is the setting that turns that checking on. <strong>Change it to 1</strong>, i.e. "yes".</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
<p>These settings control how Avida monitors and deals with genotypes in the Test CPU.</p>
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>THRESHOLD</code></strong></td>
|
||||
<td>For some statistics, we only want to measure organisms that we are sure are alive, but its not worth taking the time to run them all in isolation, without outside effect (and in some eco-system situations that isn't even possible!). For these purposes, we call a genotype "threshold" if there have ever been more than a certain number of organisms of that genotype. A higher number here ensures a greater probability that the organisms are indeed "alive".</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>TEST_CPU_TIME_MOD</code></strong></td>
|
||||
<td>Many of our analysis methods require that we be able to run organisms in isolation. Unfortunately, some of these organisms we test might be non-viable. At some point, we have to give up the test and label it as non-viable, but we can't give up too soon or else we might miss a viable, though slow, replicator. This setting is multiplied by the length of the organism's genome in order to determine how many CPU-cycles to run the organism for. A setting of 20 effectively means that the average instruction must be executed twenty times before we give up. In practice, most organisms have an efficiency here of about 5, so 20 works well, but for accurate tests on some pathological organisms, we will be required to raise this number.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
<p>The viewer has a number of one character commands that can be typed while the program is running. Often the most common commands are shown on the screen between square brackets (for example <strong>[Q]</strong>). A list of the most common commands:</p>
|
||||
<ul>
|
||||
<li><strong>Q</strong>-- Quit the program</li>
|
||||
<li><strong>M</strong>-- Switch to the map screen which shows a map of the population's fitness, merit, etc.</li>
|
||||
<li><strong>S</strong>-- Switch to the statistics screen which shows information about the population and the dominate organism</li>
|
||||
<li><strong>A</strong>-- Switch to the analyze screen</li>
|
||||
<li><strong>Z</strong>-- Switch to the zoom screen which shows detail about one organism</li>
|
||||
<li><strong>H</strong>-- Switch to the histogram screen which shows the abundance of genotypes/species in the population</li>
|
||||
<li><strong>E</strong>-- Switch to the environment screen which shows the resources and reactions in the world</li>
|
||||
<li><strong>O</strong>-- Switch to the options screen which shows current settings</li>
|
||||
<li><strong>B</strong>-- Blank the screen</li>
|
||||
<li><strong>CTRL-L</strong>-- Redraw the screen</li>
|
||||
<li><strong>C</strong>-- Choose a different CPU to examine in detail</li>
|
||||
<li><strong>X</strong>-- Extract organism and write a file of that organism</li>
|
||||
<li><strong>P</strong>-- Pause/Unpause a run</li>
|
||||
<li><strong>N</strong>-- Step forward one update</li>
|
||||
<li><strong><</strong> and <strong>></strong>-- Move to a different page in a given screen</li>
|
||||
<li>arrow keys -- let you move around a map</li>
|
||||
</ul>
|
||||
<p>Available key strokes are shown on the screen (note that the number of keys at the top screen will vary based on the width of the screen):</p>
|
||||
<p><img class="aligncenter size-full wp-image-274" src="images/Text_View_Navigation.jpg" alt="Map Screen shows each organism as colored charecter" width="650" height="650" /></p>
|
||||
<p>Draft Documentation based on: "Avida User's Manual" C. Ofria, C.T. Brown, and C. Adami in <em>Introduction to Artificial Life</em> by C. Adami:</p>
|
||||
<p>For the most part the text interface to Avida is simple and straightforward to use; most of the options available are listed on the screen. For example at all times there is a menu bar at the top of the screen which lists the current update and the keys to press to go to any of the most used Avida screens. These sections further explain each screen:</p>
|
||||
<h2>The Stats Screen</h2>
|
||||
<p>This screen displays all of the current statistics about the ongoing run. A typical snapshot of the screen looks like this:</p>
|
||||
<p><img class="aligncenter size-full wp-image-276" src="images/Text_View_Stats_Mode.jpg" alt="Map Screen shows each organism as colored charecter" width="565" height="564" /></p>
|
||||
<p>Starting at the upper left column of the screen the first block of statistics describes the current state of the soup. These statistics are defined as follows:</p>
|
||||
<ul>
|
||||
<li>Tot Births indicates the number of organisms which have been born during the past update.</li>
|
||||
<li>Breed True is the total number of organisms currently in the soup which are exact copies of their parents</li>
|
||||
<li>Parasites is the total number of organisms which have displayed parasitic behavior (i.e. the number which have executed instructions outside of their own memory).</li>
|
||||
<li>Energy is the log of the ratio between the fitness of the dominant genotype and the average fitness in the soup.</li>
|
||||
<li>Max Fitness is the highest fitness which can be found in the soup. During equilibrium this will usually be approximately the same as the fitness of the dominant genotype.</li>
|
||||
<li>Max Merit is the highest merit which can be found in the soup. Since this gives no indication as to the replication abilities of this organism it is typically not a very revealing quantity.</li>
|
||||
</ul>
|
||||
<p>To the right of the soup status column we have some information about the dominant genotype. This section simply lists the name of this genotype, its ID, its Species ID and its age (how many updates it has existed for). The first three of these statistics are purely for identification purposes.</p>
|
||||
<p>On the right side of the screen more statistics are given for a number of common measurements on the dominant genotype as well as the average across all genotypes.</p>
|
||||
<p>In the middle left side of the screen we have information about the various taxonomic levels in Avida; we give the current abundance of each in the Current column, the total number of each that have existed over the entire run in the Total column, the average number of updates each have existed in the Ave Age column and finally the entropy of each in the Entropy column.</p>
|
||||
<p>Finally along the bottom of this screen we list the total number of organisms which have completed each of the assortment of tasks available in Avida. These numbers reflect only those organisms which have actually finished the task so even if every organism in the soup is capable of completing a task not all of them may be listed because the newborns would not have finished it for the first time.</p>
|
||||
<h2>The Histogram Screen</h2>
|
||||
<p>This screen is a histogram of the most abundant genotypes or species (use '</p>
|
||||
<p><img class="aligncenter size-full wp-image-270" src="images/Text_View_Hist_Mode_1.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common organisms" width="567" height="307" /></p>
|
||||
<p>The first number here represents the fitness of the organism; this is the relative replication rate as compared to the other organisms in the population.</p>
|
||||
<p>Next comes the name of the genotype (For example 096-aaacf). This is an identifier for the genotype and the name of the file it will be saved under if it is extracted. The number portion (before the dash) of the name is the length of the code for that genotype and the letter sequence after the dash gives a unique identifier for it. These are never repeated throughout a single run.</p>
|
||||
<p>The repeated '#' after the name is the actual histogram; the number of characters which appear here is the relative current abundance of the genotype This allows quick recognition of which genotypes are dominant in the soup.</p>
|
||||
<p>Finally each line ends with a number which is the exact abundance of organisms currently within this genotype.</p>
|
||||
<p>If species information is being recorded (i.e. the SPECIES_RECORDING flag in the avida.cfg file is set to 1 or 2) the Genotype Abundance and Species Abundance Views might look like:</p>
|
||||
<p><img class="aligncenter size-full wp-image-271" src="images/Text_View_Hist_Mode_2.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common organisms" width="566" height="314" /></p>
|
||||
<p>Notice that the '#' have been replaced with letters that represent the species of this genotype so any two lines with the same letter are of the same species.</p>
|
||||
<p><img class="aligncenter size-full wp-image-272" src="images/Text_View_Hist_Mode_3.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common species" width="565" height="280" /></p>
|
||||
<h2>The Environment Screen</h2>
|
||||
<p>This screen shows reactions and resources that are defined in the environment.cfg file. An example of the Reaction View:</p>
|
||||
<p><img class="aligncenter size-full wp-image-268" src="images/Text_View_Env_Mode_1.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common organisms" width="562" height="288" /></p>
|
||||
<p>One the left side of the main screen is a list of all the defined reactions. To the right is the number of organisms that have completed this reaction. Using the up and down arrow keys one of the reactions is highlighted. If there are any resources associated with the selected reaction they are displayed in the bottom pane.</p>
|
||||
<p>The Resource View is similar:</p>
|
||||
<p><img class="aligncenter size-full wp-image-269" src="images/Text_View_Env_Mode_2.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common organisms" width="560" height="288" /></p>
|
||||
<p>In this case the resource names are shown with the inflow amount, outflow rate and total quantity of that resource in the environment. The reaction(s) associated with this resource are shown in the bottom pane.</p>
|
||||
<h2>The Options Screen</h2>
|
||||
<p>This screen lists all of the options which are both currently available and were used to initialize this run. A typical screen looks like:</p>
|
||||
<p><img class="aligncenter size-full wp-image-275" src="images/Text_View_Opt_Mode.jpg" alt="" width="566" height="560" /></p>
|
||||
<p>The upper left corner of this screen gives information about the active genotype in the soup and the remainder of the upper portions of the screen list values from the avida.cfg file and what they were initialized to.</p>
|
||||
<p>The lower part of the screen (within a box) shows the special options available to the user They are:</p>
|
||||
<p>[H]istogram Screen: This will go to the histogram screen described above.</p>
|
||||
<p>[B]lank Screen: This option will clear the screen making avida run marginally faster (since it will not be wasting much CPU time on the display).</p>
|
||||
<p>[R]edraw Screen: If the screen gets garbled this will erase it and refresh all text which is supposed to appear.</p>
|
||||
<p>[C]hoose New CPU: This option will put avida in map screen with the cursor on the screen Position the cursor over the CPU you would like to select and press enter. Additionally in the Windows version of avida the mouse can be used to select CPUs while in this screen. A single click highlights the CPU targeted and a double click selects it as the new active CPU and exits from this screen. The selected CPUs inner workings and genome can then be viewed in the Zoom screen (see below).</p>
|
||||
<p>[E]xtract organism: This will save the genotype of the active organism (the one currently selected) to a file by the same name as the genotype An extracted organism will include all of its statistics as comments (gestation time fitness tasks completed etc) and can be loaded into another soup without modifying the file.</p>
|
||||
<p>[P]ause: Freezes activity in the soup but still allows navigation through the interface and examination of the soup. Additionally many screens have additional options when the soup is paused.</p>
|
||||
<p>[N]ext Update: When paused this will advance the soup a single update.</p>
|
||||
<h2>The Zoom Screen</h2>
|
||||
<p>This screen contains all of the information about the state of the active CPU has three views (CPU Stats Zoom, Component Zoom and Genotype Zoom). This screen is especially useful while avida is paused The space bar will cause the active organism to advance a single instruction and the return key will cause it to advance a full update In this way the execution of the organism can be fully examined.</p>
|
||||
<h3>CPU Stats Zoom View</h3>
|
||||
<p>Here is a typical screen shot:</p>
|
||||
<p><img class="aligncenter size-full wp-image-277" src="images/Text_View_Zoom_Mode_1.jpg" alt="Shows a screen with thirty or so variables and their values" width="487" height="334" /></p>
|
||||
<p>The column on the left of the screen gives all of the current statistics for this CPU and the right of the screen contains information about the actual hardware in the CPU; the memory the stack the registers and the I/O buffers. The execution statistics recorded here are:</p>
|
||||
<ul>
|
||||
<li>GenotypID, Geno Name, SpeciesID: identifies the organism</li>
|
||||
<li>Fitness: As described elsewhere fitness is the relative replication rate of this organism.</li>
|
||||
<li>Gestation: This is the gestation time for the organism (the number of instructions it needs to execute in order to copy itself) If the organism has not copied itself a zero appears here.</li>
|
||||
<li>Cur Merit: This is the merit which the organism is currently building during this gestation cycle Every time a new task is completed this value will increase appropriately When a divide occurs the current merit will be reset to its base value (typically the organism size)g and the value it was at before the divide will be used to determine how much CPU time it should get.</li>
|
||||
<li>Flags: There are a number of flags within a CPU which can be set; a corresponding letter will appear in this field when this is the case The flags are A: Allocated (the organism has allocated memory for itself which it has not yet divided off) I: Injected (the organism was injected into the soup by the user) M: Mutated (an instruction has been struck by a point mutation) P: Parasite (the organism has executed code from within anothers memory) T: True Copy (the organism is an exact copy of its parent).</li>
|
||||
<li>Location: The X/Y coordinate of the current organism</li>
|
||||
<li>Facing or Executing: This attribute gives the direction in which the organism is pointed. Facing indicates that instructions which involve other organisms will use the organism at this X/Y coordinate while Executing means that the code in the specified organism is actually being run (parasitically) by this organism's CPU.</li>
|
||||
<li>Age: The number of updates that this organism has lived.</li>
|
||||
<li>Executed: The number of instructions this organism has executed since it was born.</li>
|
||||
<li>Last Divide: The number of instructions this organism has executed since its last divide.</li>
|
||||
<li>Offspring: The number of offspring which this organism has produced.</li>
|
||||
<li>Thread: Current/Total threads</li>
|
||||
<li>IP: Instruction pointer indicates the next site in the memory to be executed.</li>
|
||||
<li>AX - CX: Content of the registers.</li>
|
||||
<li>Stack: Content of the top element of the stack.</li>
|
||||
<li>Memory: The current (and two following) instructions</li>
|
||||
</ul>
|
||||
<h3>Component Zoom View</h3>
|
||||
<p><img class="aligncenter size-full wp-image-278" src="images/Text_View_Zoom_Mode_2.jpg" alt="Shows a screen with thirty or so variables and their values" width="488" height="339" /></p>
|
||||
<p>This view consists of a number of panes that can be accessed by using the TAB key.</p>
|
||||
<p>The top left pane shows the genome of the current organism. The number at the top box shows how many instructions are in the memory. The bottom box shows the individual instructions, if they are executate or were copied, and the location of the flow, write and read heads. Instructions can be edited here as well.</p>
|
||||
<p>The top middle pane shows a miniature version of the map view around the current organism.</p>
|
||||
<p>The bottom left pane shows the content of the registers, the Stack and the input values used by the organism.</p>
|
||||
<p>The bottom right pane shows general information atou the organism</p>
|
||||
<h3>Genotype Zoom View</h3>
|
||||
<p><img class="aligncenter size-full wp-image-279" src="images/Text_View_Zoom_Mode_3.jpg" alt="Shows a screen with thirty or so variables and their values" width="487" height="336" /></p>
|
||||
|
||||
<h3>The Map Screen</h3>
|
||||
|
||||
<p>The Map screen displays the spatial representation of the population of organisms in Avida. The grid itself is toroidal and typically will not fit entirely on the screen. You can use the arrow keys to adjust which part of the map appears on the screen. (On computers using a "curses" interface the arrow keys will often not function properly; instead, you can use the number keys 8, 2, 4 and 6 to move up, down, left and right respectively.) <strong>You reach the Map Screen by pressing the 'M' key.</strong></p>
|
||||
<p>Here is an example map screen (showing genotype view on a color terminal):</p>
|
||||
<p><img class="aligncenter size-full wp-image-273" src="images/Text_View_Map_Mode.jpg" alt="Map Screen shows each organism as colored character" width="487" height="605" /></p>
|
||||
<p>Many different features can be displayed by the different map views. <strong>You can cycle through these views with the less-than and greater-than keys (< and >)</strong>, as shown at the bottom-right of the map screen.</p>
|
||||
<p><strong>Genotype View</strong>: This view of displays the genotype of the organism at each location. Each organism is displayed as a hash mark ('#'); organisms with the same genotype have the same "color". (Hash marks might be bold; the bold version of a color represents a different genotype than the not-bold version. The bold and not-bold genotypes are not related in any particular way -- we're just using the bold versions as a way to get more "colors".)</p>
|
||||
<p>As long as there are enough colors, each genotype has its own color, no matter how many or how few organisms have that genotype. When there are more genotypes than colors, the most abundant genotypes get their own colors, and all other genotypes are represented by a white not-bold hash mark (or by '+' if you cannot display color). Which color is marking a genotype doesn't have any meaning at all. (You can see the fitness, id, hash mark, and number of organisms for each of the most-abundant genotypes on the <a title="The Histogram Screen" href="http://avida.devosoft.org/wiki/documentation/general-information/the-text-viewer/the-histogram-screen/">Histogram Screen</a>, which you can reach by pressing the 'H' key.)</p>
|
||||
<p><strong>Breed True View</strong>: This view simply displays a bold or not-bold hash mark ('*' or '-' if you can't display colors) for each organism, indicating whether it is an exact copy of its mother (bold white hash mark, or '*') or not (normal white hash mark, or '-').</p>
|
||||
<p><strong>Parasite View</strong>: This view displays a bold or not-bold white hash mark ('*' or '-' if you can't display color) for each organism, indicating whether it is a parasite (bold white hash mark, or '*') or not (normal white hash mark, or '-').</p>
|
||||
<p><strong>Forager View</strong>: If you know what this view shows, please edit this page!</p>
|
||||
<p><strong>Avatar View</strong>: If you know what this view shows, please edit this page!</p>
|
||||
<p><strong>Territory View</strong>: If you know what this view shows, please edit this page!</p>
|
||||
<p><strong>Mutation View</strong>: This view displays a bold or not-bold white hash mark ('*' or '-' if you can't display color) for each organism, indicating whether it has been hit by mutations (bold white hash mark, or '*') or not (normal white hash mark, or '-').</p>
|
||||
<p><strong>Thread View</strong>: This view displays the number of the thread that each organism is currently executing. For runs where organisms have only one thread (which is typical), all the numbers will be 1.</p>
|
||||
<p><strong>Modified View</strong>: If you know what this view shows, please edit this page!</p>
|
||||
<p><strong>Lineage View</strong>: This view displays the lineage of the organism at each location; each color corresponds to a single lineage. (Presumably the choice of colors and what happens when there are more lineages than colors is very similar to the way colors are handled in Genotype View.)</p>
|
||||
|
||||
<h3>The Histogram Screen</h3>
|
||||
|
||||
<p>This screen is a histogram of the most abundant genotypes or species (use '</p>
|
||||
<p><img class="aligncenter size-full wp-image-270" src="images/Text_View_Hist_Mode_1.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common organisms" width="567" height="307" /></p>
|
||||
<p>The first number here represents the fitness of the organism; this is the relative replication rate as compared to the other organisms in the population.</p>
|
||||
<p>Next comes the name of the genotype (For example 096-aaacf) This is an identifier for the genotype and the name of the file it will be saved under if it is extracted The number portion (before the dash) of the name is the length of the code for that genotype and the letter sequence after the dash gives a unique identifier for it These are never repeated throughout a single run.</p>
|
||||
<p>The repeated '#' after the name is the actual histogram; the number of characters which appear here is the relative current abundance of the genotype This allows quick recognition of which genotypes are dominant in the soup.</p>
|
||||
<p>Finally each line ends with a number which is the exact abundance of organisms currently within this genotype.</p>
|
||||
<p>If species information is being recorded (i.e. the SPECIES_RECORDING flag in the avida.cfg file is set to 1 or 2) the Genotype Abundance and Species Abundance Views might look like:</p>
|
||||
<p><img class="aligncenter size-full wp-image-271" src="images/Text_View_Hist_Mode_2.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common organisms" width="566" height="314" /></p>
|
||||
<p>Notice that the '#' have been replaced with letters that represent the species of this genotype so any two lines with the same letter are of the same species.</p>
|
||||
<p><img class="aligncenter size-full wp-image-272" src="images/Text_View_Hist_Mode_3.jpg" alt="Histogram Screen shows a bar graph where showing the abundance of the 11 most common species" width="565" height="280" /></p>
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
<p>These settings describe exactly what an update is, and how CPU time is allocated to organisms during that update.</p>
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>AVE_TIME_SLICE</code></strong></td>
|
||||
<td>This sets the average number of instructions an organism should execute each update. Organisms with a low merit will consistently obtain fewer, while organisms of a higher merit will receive more.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>SLICING_METHOD</code></strong></td>
|
||||
<td>This setting determines the method by which CPU time is handed out to the organisms. Method 0 ignores merit, and hands out time on the CPU evenly; each organism executes one instruction for the whole population before moving onto the second. Method 1 is probabilistic; each organism has a chance of executing the next instruction proportional to it merit. This method is slow due to the large number of random values that need to be obtained and evaluated (and it only gets slower as merits get higher). Method 2 is fully integrated; the organisms get CPU time proportional to their merit, but in a fixed, deterministic order.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>BASE_MERIT_METHOD</code></strong></td>
|
||||
<td>This setting determines the base value of an organism's merit. Merit is typically proportional to genome length otherwise there is a strong selective pressure for shorter genomes (shorter genome => less to copy => reduced copying time => replicative advantage). Unfortunately, organisms will cheat if merit is proportional to the full genome length -- they will add on unexecuted and uncopied code to their genomes creating a code bloat. This isn't the most elegant fix, but it works.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>MAX_LABEL_EXE_SIZE</code></strong></td>
|
||||
<td>Labels are sequences of nop (no-operation) instructions used only to modify the behavior of other instructions. Quite often, an organism will have these labels in their genomes where the nops are used by another instruction, but never executed directly. To represent the executed length of an organism correctly, we need to somehow count these labels. Unfortunately, if we count the entire label, the organisms will again "cheat" artificially increasing their length by growing huge labels. This setting limits the number of nops that are counted as executed when a label is used.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><strong><code>MAX_CPU_THREADS</code></strong></td>
|
||||
<td>Determines the number of simultaneous processes that an organism can run. That is, basically, the number of things it can do at once. This setting is meaningless unless threads are supported in the virtual hardware and the instructions are available within the instruction set.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
See the avida.cfg file for more options: <code>SLICING_BURST_SIZE, BASE_CONST_MERIT, MERIT_BONUS_INST, MERIT_BONUS_EFFECT, FITNESS_VALLEY, FITNESS_VALLEY_START, FITNESS_VALLEY_STOP, DEFAULT_BONUS, MERIT_DEFAULT_BONUS, MERIT_INC_APPLY_IMMEDIATE, TASK_REFRACTORY_PERIOD, FITNESS_METHOD, FITNESS_COEFF_1, FITNESS_COEFF_2, THREAD_SLICING_METHOD, NO_CPU_CYCLE_TIME, PRECALC_PHENOTYPE, FASTFORWARD_UPDATES, FASTFORWARD_NUM_ORGS</code>, and <code>GENOTYPE_PHENPLAST_CALC</code>.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
This section covers all of the basic topology variables that describe the structure of the world.
|
||||
|
||||
<table border="1">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td valign="top"><strong><code> WORLD_X <br />WORLD_Y </code></strong></td>
|
||||
<td>The settings determine the size of the Avida grid that the organisms populate; the world consists of <code>WORLD_X * WORLD_Y</code> cells. In <a href="http://avida.devosoft.org/wiki/documentation/configuration-and-command-reference/avida-cfg-the-avida-configuration-file/reproduction-settings/" title="Reproduction Settings: Birth and Death">mass action mode</a> the shape of the grid is not relevant, only the number of organisms that are in it.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
See the avida.cfg file for more settings: <code>WORLD_GEOMETRY, SCALE_FREE, SCALE_FREE_ALPHA,</code> and <code>SCALE_FREE_ZERO_APPEAL</code>.
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
<h2><strong>Using sexual reproduction with mating types</strong></h2>
|
||||
<p>Although by default, reproduction in Avida is asexual, Avida can be configured to allow organisms to reproduce with sexual reproduction. By default, when sexual reproduction is turned on, any organism can mate with any other organism. However, Avida is also capable of sexual reproduction with two distinct mating types (e.g., males and females), mimicking the mating systems found in many biological organisms, in which only matings between opposite mating types are successful. (Note: this page is intended as an overview of how to implement these distinct mating types and their associated configuration options, not as an exhaustive guide to all of the other options involved in sexual reproduction in general).</p>
|
||||
<p><br />First, you will need to turn on mating types in avida.cfg:</p>
|
||||
<p><code>MATING_TYPES 1</code></p>
|
||||
<p>However, this change by itself is not enough. You will also need to modify your instruction set so that the organisms can set their mating types, by adding the following two instructions to your instruction set:</p>
|
||||
<p><code>INST set-mating-type-male<br />INST set-mating-type-female</code></p>
|
||||
<p>Once an organism sets its mating type, it is irreversible -- repeated execution of a different set-mating-type-X instruction will fail. If you want your organisms to be able to change their mating type during their lifetime, you can add another instruction that lets them de-differentiate, after which they can re-set their mating type to something else:</p>
|
||||
<p><code>INST set-mating-type-juvenile</code></p>
|
||||
<p>Then, you also need to make sure that your organisms are using the proper instruction to divide, or else their mating types may not be checked properly. So you should replace the divide instruction in your instruction set (probably <code>h-divide</code> or <code>divide-sex</code>) with div-sex-mating-type.</p>
|
||||
<p>While we're in the instruction set, you might want to consider adding instructions allowing organisms to conditionally execute instructions based on their phenotypic sex (otherwise, they have no real mechanism to detect what their phenotypic sex is):</p>
|
||||
<p><code>INST if-mating-type-male<br />INST if-mating-type-female<br />INST if-mating-type-juvenile</code></p>
|
||||
<p>Next, you'll need to modify your events file to make sure that the population is initialized with a male and a female organism. You can create a new default organism by modifying default-heads-sex.org (make two, say, default-heads-sex-male.org and default-heads-sex-female.org). Simple add a set-mating-type-male or set-mating-type-female instruction to the beginning of each .org file (you'll probably want it to be the first instruction that they execute, but it doesn't necessarily have to be). Then replace the original divide instruction with the div-sex-mating-type instruction.</p>
|
||||
<p>Now, modify your events file to inject both organisms at the start of the run:</p>
|
||||
<p><code>u begin Inject default-heads-sex-male.org 0<br />u begin Inject default-heads-sex-female.org 1</code></p>
|
||||
<p>At this point, you should be able to get a run going, but read on for some further options and points to consider.</p>
|
||||
<p>-------------------------------------------</p>
|
||||
<h2>What happens during sexual reproduction:</h2>
|
||||
<p>When an organism reproduces sexually, it needs to find a mate. When the first organism in the population successfully divides, its 'offspring' goes into what is called the birth chamber, rather than being placed into the population. This is sort of a waiting area in which organisms can find mates. When another organism divides, Avida checks the birth chamber to see if there are any 'offspring' waiting to find a mate that were generated by a parent of the opposite mating type. If so, then they recombine, and the sexual offspring are placed into the population. If not, then this organism's 'offspring' goes into the birth chamber to wait as well. Because of this waiting process, you can almost think of these 'offspring' as being more like sperm or eggs, that need to join up with a gamete of the opposite type before they can form a zygote together.</p>
|
||||
<p>There are a few options regarding the birth chamber. First, you'll want to set its maximum size -- how many 'offspring' (or gametes) can be waiting in the birth chamber at any given time? The default is 3600, the same as the size of the default population. This can be changed in avida.cfg:</p>
|
||||
<p><code>MAX_GLOBAL_BIRTH_CHAMBER_SIZE 3600</code></p>
|
||||
<p>Another thing to consider regarding the birth chamber is how long 'offspring' or gametes can wait there before dying. The default setting for this parameter (<code>MAX_BIRTH_WAIT_TIME</code>) is -1, meaning there is no limit -- they will remain in the birth chamber indefinitely, until they get picked by a mate. You will almost certainly want to change this. For example:</p>
|
||||
<p><code>MAX_BIRTH_WAIT_TIME 3</code></p>
|
||||
<p>would tell Avida that an 'offspring' or gamete can wait for three updates to be chosen as a mate, but any gametes that are not picked as mates within three updates after they go into the birth chamber will die. In practice, three seems to give good results.</p>
|
||||
<p>One final thing to consider is spatial organization. Currently, the birth chamber has no spatial organization to it; any organism can mate with any other organism regardless of their "physical" location in the population. Since mating has no spatial structure, you therefore may not want any spatial structure in your population at all. To do so, change:</p>
|
||||
<p><code>BIRTH_METHOD 4</code></p>
|
||||
<p>-------------------------------------------</p>
|
||||
<h2>Mate choice:</h2>
|
||||
<p>By default, organisms will choose mates randomly. However, organisms can choose mates based on various phenotypic attributes by executing instructions that confer certain mating preferences. To enable this, simply add one or more of the following instructions to the instruction set:</p>
|
||||
<p><code>INST set-mate-preference-highest-merit<br />INST set-mate-preference-random<br />INST set-mate-preference-highest-display-a<br />INST set-mate-preference-highest-display-b</code></p>
|
||||
<p>For example, suppose a female organism executes a set-mate-preference-highest-merit instruction, and then later divides. If there is more than one male 'offspring' (or sperm) waiting in the birth chamber when she divides, she will pick the one that came from a parent with the highest merit. Likewise, a female that has declared a preference for males with higher values of display A will select the one with the highest value of display A from among the available offspring of males in the birth chamber at the time of her divide.</p>
|
||||
<p>But wait -- what are these displays? Organisms can develop displays by executing instructions, which you will have to add to the instruction set:</p>
|
||||
<p><code>increment-mating-display-a<br />increment-mating-display-b<br />set-mating-display-a<br />set-mating-display-b</code></p>
|
||||
<p>When an organism is born, its value for both display A and display B are both set to 0. Executing an <code>increment-mating-display-A</code> instruction adds 1 unit to its display. Using this method, an organism can only develop a large display by repeatedly executing this increment instruction. The <code>set-mating-display-A</code> and <code>-B</code> instructions, on the other hand, will copy the value of the ?BX? register (which register is used can be nop-modified) into its mating display. So using these instructions, organisms can develop exaggerated displays relatively quickly by using mathematical operations to generate a large value in their registers and then copying it to their displays.</p>
|
||||
<p>Of course, in nature, organisms don't always perceive signals with 100% accuracy. Thus, in Avida, you can introduce noise into an organism's perception of other organisms' signals or phenotypic traits, using the <code>NOISY_MATE_ASSESSMENT</code> config option (0 = noise off [default]; 1 = noise on):</p>
|
||||
<p><code>NOISY_MATE_ASSESSMENT 1</code></p>
|
||||
<p>How much noise is introduced? When an organism assesses a phenotypic trait of a potential mate, the perceived value is drawn from a normal distribution with the mean at the actual value, and with a coefficient of variation of 0.1. This coefficient of variation can be changed with the <code>MATE_ASSESSMENT_CV</code> config option:</p>
|
||||
<p><code>MATE_ASSESSMENT_CV 0.15</code></p>
|
||||
<p>-------------------------------------------</p>
|
||||
<h2>Costs:</h2>
|
||||
<p>In nature, males and females of many animals can differ in certain traits because of sex-specific selective pressures. Avida can reflect this by implementing sex-specific costs for instructions. For example, in many animals, females invest more in reproduction. In Avida, we can make females pay extra CPU cycles to execute an instruction. This is an especially important consideration for the <code>div-sex-mating-type</code> instruction. Making females pay extra CPU cycles to complete division not only reflects the biological characteristics of many species, but also slows down female reproductive rates. As a result of males dividing more quickly than females (on average), the offspring of male organisms (i.e., sperm) will accumulate in the birth chamber. Females, then, will usually not be mate-limited, and will have more opportunities for mate choice -- again reflecting patterns that are often seen in nature. You can do this as follows, by modifying the div-sex-mating-types instruction in the instruction set file:</p>
|
||||
<p><code>INST div-sex-mating-type:female_cost=50</code></p>
|
||||
<p>This will require females to pay an extra 50 CPU cycles to complete their divide statements. Note that another work-around to forcing females to be the choosy sex is with the <code>LEKKING</code> option in avida.cfg. If you set its value to 1, all the offspring of male organisms will always go into the birth chamber -- in other words, males can never choose females as mates; females are always the 'choosers'.</p>
|
||||
<p>Another important element is the cost of mate choice. In nature, mate choice can impose substantial costs on organisms. (For example, spending a lot of time searching for mates rather than mating with the first guy that comes along can put you at greater risk of being eaten by a predator.) You can force females who mate non-randomly to pay even greater CPU costs as follows:</p>
|
||||
<p><code>INST div-sex-mating-type:female_cost=50:choosy_female_cost=50</code></p>
|
||||
<p>In this setup, males will pay 1 CPU cycle for executing a <code>div-sex-mating-type</code> instruction. Randomly mating females will pay an additional 50 CPU cycles. Females who mate non-randomly (e.g., choose the male with the highest merit or highest display A) will pay another 50 on top of that (i.e., 1 + 50 [for being female] + 50 [for being choosy] = 101).</p>
|
||||
<p><br />-------------------------------------------</p>
|
||||
<h2>Memory considerations:</h2>
|
||||
<p>Normally, Avida keeps a record of every genotype (i.e., genome sequence) that has ever existed in the population. This is very useful when you want to trace an organism's lineage back through its ancestors. However, when sexual reproduction is turned on (and especially when separate mating types are turned on), all that recombination generates much more diversity. This means that Avida can take up quite a bit of memory (and will probably crash if you're doing a long run), and will get slower and slower as the run progresses and there are more and more genotypes to keep track of.</p>
|
||||
<p>If you don't need detailed information on organismal ancestry, you can turn off lineage tracking with the following config setting:</p>
|
||||
<p><code>DISABLE_GENOTYPE_CLASSIFICATION 1</code></p>
|
||||
<p><br />-------------------------------------------</p>
|
||||
<h2>Collecting data on mating types:</h2>
|
||||
<p>There are a variety of print actions that can be used to gather data on mating types and mate preferences as your population evolves:</p>
|
||||
<p><code>PrintMatingTypeHistogram</code>: This action will print the number of juvenile, female, and male organisms in the population at the current update</p>
|
||||
<p><code>PrintMatingDisplayData</code>: This action prints the average display values (display-A and display-B) of all of the juveniles, females, and males in the population at the current update</p>
|
||||
<p><code>PrintFemaleMatePreferenceData</code>: This action prints the number of females with each different type of mating preference at the current update</p>
|
||||
<p><code>PrintBirthChamberMatingTypeHistogram</code>: This action prints the number of "sperm" and "eggs" in the birth chamber at the current update</p>
|
||||
<p><code>PrintSuccessfulMates</code>: This action prints the genotypes and some useful phenotypic information (e.g., merit, mating types, displays, preferences) of the parents of all the successful matings that occurred during the current update</p>
|
||||
<p><code>PrintBirthChamber</code>: This action prints the genotypes and some useful phenotypic information (e.g., merit, mating types, displays, preferences) of the parents of all the "sperm" or "eggs" waiting in the birth chamber at the current update</p>
|
||||
<p>(Note: by using PrintBirthChamber to print all the organisms currently waiting to be chosen as mates, and PrintSuccessfulMates to print all the organisms that were successfully chosen as mates, you can estimate sexual selection differentials.)</p>
|
||||
<p>-------------------------------------------</p>
|
||||
<h2>Analyze Mode</h2>
|
||||
<p>There are a few phenotypic attributes that can be used with the DETAIL statement in analyze mode (pretty self-explanatory):</p>
|
||||
<p><code>mating_type</code><br /><code>mate_preference</code><br /><code>mating_display_a</code><br /><code>mating_display_b</code></p>
|
||||
<p>Using these, you can take a genotype and run it through analyze mode to find out what mating type it develops as (useful if there are multiple set-mating-type-XXX instructions in a genome and it's hard to tell which one will be executed first), what kind of mate preference it will exhibit, how large its sexual displays are, etc.</p>
|
||||
<p> </p>
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Bitwise</title>
|
||||
|
||||
<h1>Bitwise</h1>
|
||||
|
||||
A bitwise operation is one in which each bit is treated independently of all the other bits in a number. Thus if a logical AND was performed between two bitstrings, the first bit of the first string would be ANDed to the first bit in the second string, the second bit to the second bit and so on.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : CPU-cycle</title>
|
||||
|
||||
<h1>CPU-cycle</h1>
|
||||
|
||||
A CPU-cycle is the amount of time it takes the <a href="help.CPU.html">CPU</a> of an <a href="help.Organism.html">organism</a> to execute a single <a href="help.Instruction.html">instruction</a> in its <a href="help.Memory.html">memory</a>. CPU-cycles can be thought of as the primary resource in the avida system; more cycles per unit time allow a more rapid expression of the organism's <a href="help.Genome.html">genome</a>.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>CPU Components : CPU</title>
|
||||
|
||||
<h1>CPU</h1>
|
||||
|
||||
Each individual organism in an avida <a href="help.Population.html">population</a> has its own virtual central processing unit (CPU) that executes its <a href="help.Genome.html">genome</a>. An avida CPU consists of a <a href="help.Memory.html">memory</a> space with four <a href="help.Heads.html">heads</a> pointing to specific locaitions in that memory, three <a href="help.Registers.html">registers</a>, two <a href="help.Stack.html">stacks</a>, and <a href="help.Input-Output.html">input</a> and <a href="help.Input-Output.html">output</a> buffers.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
<html>
|
||||
<title>Other Notation : Complement-Label</title>
|
||||
|
||||
<h1>Complement-Label</h1>
|
||||
|
||||
The complement of a <a href="help.Label.html">label</a> is found by taking each
|
||||
<a href="help.nop-instructions.html">no-operation</a> instruction that makes up that label,
|
||||
and shifting it to the next in alphabetical order, looping around at the end.
|
||||
Thus, in the default instruction set, nop-A -> nop-B -> nop-C -> nop-A. The label
|
||||
"nop-B nop-A nop-C nop-C" has the complement "nop-C nop-B nop-A nop-A".
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>CPU Components : Genome</title>
|
||||
|
||||
<h1>Genome</h1>
|
||||
|
||||
The genome of an organism is the original, underlying program that controls the behavior of that organism. The <a href="help.Memory.html">memory</a> space in the <a href="help.CPU.html">CPU</a> of that organism is initialized to the genome, but will change with time. A <a href="help.Genotype.html">genotype</a> is is determined by a unique genome sequence.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Genotype</title>
|
||||
|
||||
<h1>Genotype</h1>
|
||||
|
||||
A genotype is a unique sequence of <a href="help.Instruction.html">instructions</a> that make up a <a href="help.Genome.html">genome</a> of an <a href="help.Organism.html">organism</a>. Any two organisms with identical genomes are considered to be the same genotype.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>CPU Components : Heads</title>
|
||||
|
||||
<h1>Heads</h1>
|
||||
|
||||
Each <a href="help.CPU.html">CPU</a> has four heads associated with it. The first is the instruction pointer (IP) which determines the next <a href="help.Instruction.html">instruction</a> to be executed by the CPU. After each execution, the IP is automaticall advanced (unless the instruction executed dictates otherwise). The second is the read-head (RH), which determines what instruction is copied from a copy command, and then the write-head (WH) determines the position it is copied to. Finally, the flow-head (FH) is used to mark positions in the genome to move the other heads to. The flow-head is commonly used to mark the beginning of a loop to jump the IP back to from the loop's end.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Instruction : IO</title>
|
||||
|
||||
<h1>IO</h1>
|
||||
|
||||
This is the input/output instruction. It takes the contents of the <a href="help.Nop-Register-Notation.html">?BX?</a> <a href="help.Registers.html">register</a> and outputs it, checking it for any <a href="help.Tasks.html">tasks</a> that may have been performed. It will then place a new <a href="help.Input-Output.html">input</a> into ?BX?.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>CPU Components : Input-Output</title>
|
||||
|
||||
<h1>Input-Output</h1>
|
||||
|
||||
Each <a href="help.CPU.html">CPU</a> in avida is supplied with 3 input values of 32 bits each. The <a href="help.IO.html">IO</a> instruction is used by the organisms to get the an input (cyclying through the three options) into a <a href="help.Registers.html">register</a> and to output numbers from a register. Each ouput is compared to all inputs to determing if any <a href="help.Tasks.html">tasks</a> (by default, specified logical computations) have been performed by the organism.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>CPU Components : Instruction</title>
|
||||
|
||||
<h1>Instruction</h1>
|
||||
|
||||
Each position in an <a href="help.Organism.html">organisms</a> <a href="help.Genome.html">genome</a> or a <a href="help.CPU.html">CPUs</a> <a href="help.Memory.html">memory</a> consists of an instruction. Each instruction is associated with a specific function on the CPU when it is executed (expressed); in series these instructions lead to all of the complex behaviors of the organisms.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
<html>
|
||||
<title>Other Notation : Label</title>
|
||||
|
||||
<h1>Label</h1>
|
||||
|
||||
A label (sometimes called a template -- for example, in biology) is a sequence of
|
||||
<a href="help.nop-instructions.html">no-operation</a> instructions used to mark
|
||||
regions of code within a <a href="help.Genome.html">genome</a>. Some instructions
|
||||
(such a <a href="help.h-search.html">h-search</a>) are followed by a label; the
|
||||
<a href="help.Complement-Label.html">complement</a> of that label is then used
|
||||
to match against other labels. See the descriptions of the individual
|
||||
<a href="help.Instruction.html">instructions</a> for how they use labels.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Logic</title>
|
||||
|
||||
<h1>Logic</h1>
|
||||
|
||||
A logic operation has as inputs a collection of bits, and as an output a single bit. The operation itself is a unique map from the input bits to the output bits. In avida, a logic operation is done in a <a href="help.Bitwise.html">bitwise</a> fashion, so that the operation is effectively performed 32 times when a reward is granted.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>CPU Components : Memory</title>
|
||||
|
||||
<h1>Memory</h1>
|
||||
|
||||
A <a href="help.CPU.html">CPU</a> contains a memory space to hold a sequence of <a href="help.Instruction.html">instructions</a> to be executed. The memory space is initialize to the genome of the organism, but it will be modified over the lifetime of the organism, typically as an offspring is produced. As section of the memory is then divided off to initialize the ofpspring.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Mutation</title>
|
||||
|
||||
<h1>Mutation</h1>
|
||||
|
||||
A mutation is a random change of an <a href="help.Instruction.html">instruction</a> from the <a href="help.Genome.html">genome</a> of an <a href="help.Organism.html">organism</a>. There are three main times that mutations can occur; point mutations will happen randomly through time, with and equal probability at every site, copy mutations occur when a site is actively being copied, and divide mutations occur when an organim is splitting off an offspring.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Nop-Head-Notation</title>
|
||||
|
||||
<h1>Nop-Head-Notation</h1>
|
||||
|
||||
A <a href="help.Heads.html">head</a> abbreviation (IP, RH, WH, or FH) surrounded by question marks refers to that head being used as a default, when the <a href="help.Instruction.html">instruction</a> in question is being executed, but if the instruction is followed by a <a href="help.nop-instructions.html">no-operation</a> (nop) instruction, the nop will alter the register used. A nop-A instruction indicates the instruction pointer (IP), nop-B is the read-head (RH), nop-C is the write-head (WH), and there is no way to use the flow-head (FH) unless it is by default.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Nop-Register-Notation</title>
|
||||
|
||||
<h1>Nop-Register-Notation</h1>
|
||||
|
||||
A <a href="help.Registers.html">register</a> name (AX, BX, or CX) surrounded by question marks refers to that register being used by default when the <a href="help.Instruction.html">instruction</a> in question is being executed, but if the instruction is followed by a <a href="help.nop-instructions.html">no-operation</a> (nop) instruction, the nop will alter the register used. A nop-A instruction indicates AX, nop-B is BX, and nop-C is CX.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Organism</title>
|
||||
|
||||
<h1>Organism</h1>
|
||||
|
||||
An organism in avida consists of a unique <a href="help.Genome.html">genome</a> and a <a href="help.CPU.html">CPU</a> that expresses (executes) the code in that genome. A <a href="help.Population.html">population</a> in avida is a collection of these organisms.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Population</title>
|
||||
|
||||
<h1>Population</h1>
|
||||
|
||||
A population in avida is a collection of digital <a href="help.Organism.html">organisms</a> that interact and evolve over time.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
<html>
|
||||
<title>CPU Components : Registers</title>
|
||||
|
||||
<h1>Registers</h1>
|
||||
|
||||
<p>
|
||||
A register is a storage space for a single number.
|
||||
Each classic <a href="help.CPU.html">CPU</a> in Avida contains three registers, each of which is made up of 32 bits. All math-based <a href="help.Instruction.html">instructions</a> opperate on the registers, and various instruction will move the values in the registers around.
|
||||
</p>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
<html>
|
||||
<title>CPU Components : Stack</title>
|
||||
|
||||
<h1>Stack</h1>
|
||||
<P>
|
||||
Each classic <a href="help.CPU.html">CPU</a> in Avida has two stacks used for storage of numbers. The <a href="help.push.html">push</a> and <a href="help.pop.html">pop</a> instructions are used to move numbers between the <a href="help.Registers.html">registers</a> and the stack, and the <a href="help.swap-stk.html">swap-stk</a> instruction toggles the active stack in use.
|
||||
</P>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Other Notation : Tasks</title>
|
||||
|
||||
<h1>Tasks</h1>
|
||||
|
||||
The <a href="help.Organism.html">organisms</a> in avida are granted extra <a href="help.CPU-cycle.html">CPU-cycles</a> for performing specific computations. Every time an organisms <a href="help.Input-Output.html">outputs</a> a number, it is examined against the inputs to determine if any tasks have been compleated. If the number of extra CPU-cycles outweigh the number used to perform the task, the computation will typically be reinforced through natural selection. By default, the tasks in avida are all <a href="help.Logic.html">logic</a> operations that act upon the <a href="help.Input-Output.html">inputs</a> in a <a href="help.Bitwise.html">bitwise</a> fashion.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<html>
|
||||
<title>Instruction : add</title>
|
||||
|
||||
<h1>add</h1>
|
||||
|
||||
<p>This instruction reads in the contents of the BX and CX <a href="help.Registers.html">registers</a> and sums them together. The result of this operation is then placed in the <a href="help.Nop-Register-Notation.html">?BX?</a> register.</p>
|
||||
</html>
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Instruction : dec</title>
|
||||
|
||||
<h1>dec</h1>
|
||||
|
||||
This instruction reads in the contents of the <a href="help.Nop-Register-Notation.html">?BX?</a> <a href="help.Registers.html">register</a> and decrements it by one.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Instruction : h-alloc</title>
|
||||
|
||||
<h1>h-alloc</h1>
|
||||
|
||||
This instruction allocates additional <a href="help.Memory.html">memory</a> for the organism up to the maximum it is allowed to use for its offspring.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Instruction : h-copy</title>
|
||||
|
||||
<h1>h-copy</h1>
|
||||
|
||||
This instruction reads the contents of the organism's <a href="help.Memory.html">memory</a> at the position of the <a href="help.Heads.html">read-head</a>, and copy that to the position of the <a href="help.Heads.html">write-head</a>. If a non-zero copy mutation rate is set, a test will be made based on this probability to determine if a <a href="help.Mutation.html">mutation</a> occurs. If so, a random instruction (chosen from the full set with equal probability) will be placed at the write-head instead.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Instruction : h-divide</title>
|
||||
|
||||
<h1>h-divide</h1>
|
||||
|
||||
This instruction is used for an organism to divide off an finnished offspring. The original organism keeps the state of its <a href="help.Memory.html">memory</a> up until the <a href="help.Heads.html">read-head</a>. The offspring's memory is initialized to everything between the read-head and the <a href="help.Heads.html">write-head</a>. All memory past the write-head is removed entirely.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Instruction : h-search</title>
|
||||
|
||||
<h1>h-search</h1>
|
||||
|
||||
This instruction will read in the <a href="help.Template.html">template</a> the follows it, and find the location of a <a href="help.Complement-Template.html">complement</a> template in the code. The BX <a href="help.Registers.html">register</a> will be set to the distance to the complement from the current position of the <a href="help.Heads.html">instruction-pointer</a>, and the CX register will be set to the size of the template. The <a href="help.Heads.html">flow-head</a> will also be placed at the beginning of the complement template. If no template follows, both BX and CX will be set to zero, and the flow-head will be placed on the instruction immediatly following the h-search.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
<html>
|
||||
<title>Instruction : if-label</title>
|
||||
|
||||
<h1>if-label</h1>
|
||||
|
||||
This instruction reads in the <a href="help.Template.html">template</a> that follows it, and tests if its <a href="help.Complement-Template.html">complement</a> template was the most recent series of instructions copied. If so, it executed the next instruction, otherwise it skips it. This instruction is commonly used for an organism to determine when it has finished producing its offspring.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue