Copy Link
Add to Bookmark
Report

Alife Digest Number 023

eZine's profile picture
Published in 
Alife Digest
 · 11 months ago

 
ALIFE LIST: Artificial Life Research List Number 23 Tuesday, June 12th 1990

ARTIFICIAL LIFE RESEARCH ELECTRONIC MAILING LIST
Maintained by the Indiana University Artificial Life Research Group

Contents:

ERL video is now Out Of Stock
A GA Tutorial and a GA Short Course
program source

----------------------------------------------------------------------

Date: Wed, 6 Jun 90 15:26:48
From: ackley@flash.bellcore.com (David H Ackley)
Subject: ERL video is now Out Of Stock

My supply of copies of the ERL video is now exhausted. Please do not
send any more requests as I will be unable to fulfill them. However,
I have submitted the tape to the "video proceedings" of the ALife ][
conference, so, if all goes well, it should become available again via
that channel.

Thanks to all who expressed an interest and sent along kind words. In
response to several questions: The video is not the end of the story.
The chapter we have submitted to the (paper) proceedings answers
burning questions such as: What happened to that video population
AFTER one million steps were reached? Do they live forever? Why or
why not?

| David Ackley Cognitive Science Research Group |
| "Randomness Bell Communications Research Inc.|
| moves in ackley@flash.bellcore.com|
| mysterious ways"
...!bellcore!ackley|

------------------------------


Date: Thu, 07 Jun 90 15:53:03 CDT
From: "Dave Goldberg (dgoldber@ua1vm.ua.edu)" <DGOLDBER@UA1VM.ua.edu>
Subject: A GA Tutorial and a GA Short Course

A tutorial entitled "Genetic Algorithms and Classifier Systems" will be
presented on Wednesday afternoon, August 1, at the AAAI conference in
Boston, MA by David E. Goldberg (Alabama) and John R. Koza (Stanford).
The course will survey GA mechanics, power, applications,
and advances together with similar information regarding classifier
systems and other genetics-based machine learning systems. For further
information regarding this tutorial write to AAAI-90, Burgess Drive,
Menlo Park, CA 94025, (415)328-3123.

A five-day short course entitled "Genetic Algorithms in Search,
Optimization, and Machine Learning"
will be presented at Stanford
University's Western Institute in Computer Science on August 6-10
by David E. Goldberg (Alabama) and John R. Koza (Stanford).
The course presents in-depth coverage of GA mechanics, theory and
application in search, optimization, and machine learning. Students
will be encouraged to solve their own problems in hands-on computer
workshops monitored by the course instructors. For further information
regarding this course contact Joleen Barnhill, Western Institute in
Computer Science, PO Box 1238, Magalia, CA 95954, (916)873-0576.



------------------------------

From: upheisei!rick@attunix.att.com
Date: 1990 Mai 14 Wed 3.70.61 EMT (90/06/08 Fri 08:53 GMT)
Subject: program source

Alifers...

Humbly announcing availability of source for a sort of "toy" program
called "vamv" in the alife archives... Availability is through
anonymous ftp:

iuvax.cs.indiana.edu:~ftp/pub/alife/software/unix/vamv

I hope this isn't too long...

1. Overview

VAMV (Video Alpha Mosaic Virus) is a crude experiment in program
evolution and population dynamics. It is relatively independent of
UNIX(tm) version, but set up for System V (e.g., uses System V getopt()
and setvbuf()) and ANSI terminals or terminal emulators. It is rather
a fore-runner -- an attempt to develop genetic machinery and principles
for a longer-term project. This is a description of Version 1.0.

VAMV displays an "environment" of positions on the screen. Each
position may have an amount of "food" located at it (indicated by "."
on the screen) and/or an "organism" (indicated by an upper-case
alphabetic character; hence the appellation). If both food and an
organism occupy a position, only the organism is displayed; if the
organism moves away, the food is re-displayed. As VAMV runs, it
displays on the screen, changes in locations, food, and the organisms
that occupy the "space".

2. Organisms

An "organism" is a program & registers. Each one consists of some
"preferences" (registers) and 64 bytes of instruction/data space.
Taken together, the instruction space and the registers constitute the
"genetic" (and behavioral) machinery of the organism. The programs are
in a very simple byte-oriented assembly language that is interpreted by
the VAMV program; it consists presently of 16 different instructions.
Organisms reproduce by fission and inherit program counter,
preferences, some "strength", and program instructions (genes) from the
parent. When an organism divides, various mutations may take place in
the genes of the new one.

Rather than creating pre-programmed organisms, the system is
bootstrapped by "pumping". First, "food" is generated pseudo-randomly
(let's say "randomly" for brevity); up to 16 units of food are dropped
at 15% of the locations (by default; see below). A number of random
organisms are created and dropped randomly into the environment. A
clock is started, and on each clock tick, each living organism executes
one instruction. On every 50 clock ticks (called the "major cycle") a
statistical snapshot is taken, and each organism receives a score. The
system may require several (or many) pump attempts before generating
organisms that are viable enough to divide and increase to a stable
level. Several factors may lead to premature "expiration" of an
organism: it may fail to eat, its PC may overflow, it may branch to a
non-existent address (suicide), it may be eaten by another organism,
etc. If the population density is high enough, culling can take place
(under parametric control) to reduce density.

3. Evolution & Mutation

Normally, mutations occur only when an organism divides, but this can
be controlled via a command-line option, which causes the middle-ranked
1/3 of living organisms to be mutated on every major cycle. After the
scoring for each major cycle, the scores and counts of items are reset,
so scores represent how well an organism did during only one cycle, not
overall (if scores were cumulative, then certain organisms would always
do very well, leaving virtually no chance for young organisms to catch
up).

As the VAMV program runs, organisms move around the screen, eating
(both food and each other), dividing, picking up and depositing bits of
food; they may also synthesize food from bits of picked-up stuff and
their own "strength". A file of parameters is read when VAMV is
started up, allowing scores and thresholds of the environment to be
modified. Parameters are included for the number or original organisms
to create, the density at which culling takes place, scores for
successful completion of various instructions. (Scores do not
generally affect things until culling takes place, as culling is the
only operation that checks the scores.)

Normally, organisms are genetically stable in themselves, and
mutations only occur when they breed, in the "new" organism. Division
takes place by copying an organism, then mutating the copy. The
mutation routine works by probabilities of certain types of mutations
happening. For example, there is a 15% probability of two preferences
being swapped; a 75% probability of a bit-flip in one random gene, a
25% probability of a single gene being randomized. (Mutation,
especially percentages of the various types, really should be under
parametric control, and in the future probably will be.)

4. Assembly Language

The assembly language is very simple. Most instructions are two bytes
(a one-byte opcode with a one-byte argument). Most arguments divide
into an "x/y" type, indicating a location relative to the organisms's
location, "-1,3" for example, is an offset of -1 in the X dimension and
3 in the Y dimension. There is no even/odd addressing scheme, so
organisms do evolve that use "arguments" as instructions and vice
versa, depending on their branch and jump instructions. Organisms do
tend to stay within a very small instruction space -- they do *not*
generally make full use of their available space. The assembly
language includes instructions for test, branching, eating, division,
and so forth. Command line options are also available for writing
statistics, printing the assembly code executed by the last "highest
scoring"
organism, and printing "visual snapshots" onto the stderr file
descriptor.

5. The Future...?

The "purpose" of VAMV rather evolved as it was being developed, but
fundamentally is was to build a system of evolving little programs that
adapted themselves to their environment. The form this finally took
was that of populations that "adapt" by "natural selection" and
disperse themselves through the environment by breeding more quickly or
more successfully than other organisms. To maintain their dominance,
populations have to perform certain actions. If food supplies run low,
for example, they cannot as easily divide as if there were adequate
supplies (because division requires "strength", obtained through eating
or food synthesis); so, a population that mainly consumed what was
lying around might, over a few generations, tend to become dominated by
food-producing organisms. The trick to achieving a stable population
that keeps itself at acceptable levels has been in "tuning" the
parameters to achieve a balance between food consumption, synthesis,
and breeding population. Not every tuning will tend to produce
balanced populations or "reasonable" ecologies, and finding one that
does so is rather like the proverbial needle in a haystack. I hope
it's been made easy to twiddle the parameters, re-check old results,
and "re-run" favorite programs (by forcing the same seed into the
pseudo-random number generator).

The point of all this was to develop some techniques for programming
organisms to interact with an environment and make decisions about
behavior based on their current status and that of the local
environment. Some instructions can be used by them in various subtle
ways. A "branch if neighbor at x,y not edible" for example, can be
used to detect a potential "enemy" organism, and branch to another
"phase" of the current program. In practice, organisms do not perform
much (if any) of this "intelligent" processing, it seems. The next
version (in the works) adds 16 more assembly instructions, to bring the
full set to 32; among these are some stack instructions and the
potential for self-modification. The current problem finding a
suitable environment that encourages organisms to use the "nifty"
instructions (like making clever use of their new stack, arithmetic
instructions, and CALL/RET mechanism). Currently, successful 2nd
version organisms still tend to develop very similar strategies to the
1st version. It's beginning to look like the only way to get them to
use the instructions may be to make them more necessary to survival;
currently, organisms can survive by merely eating, dividing, and
possibly synthesizing food.

I hope that the program provides a few minutes of amusement, anyway.
The next version will probably be available shortly... For further
information, suggestions, questions, or comments, please see the
documentation, or write:

Rick McGowan
upheisei!rick@attunix.att.COM
{Sun.COM, Apple.COM, Xerox.COM}!attunix!upheisei!rick

or the alife ML administrators if you can't reach me through those.


------------------------------
End of ALife Digest
********************************
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
= Artificial Life Distribution List =
= =
= All submissions for distribution to: alife@iuvax.cs.indiana.edu =
= All list subscriber additions, deletions, or administrative details to: =
= alife-request@iuvax.cs.indiana.edu =
= All software, tech reports to Alife depository through =
= anonymous ftp at iuvax.cs.indiana.edu in ~ftp/pub/alife =
= =
= List maintainers: Elisabeth Freeman, Eric Freeman, Marek Lugowski =
= Artificial Life Research Group, Indiana University =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
End of Alife Digest
********************************







← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT