Author Topic: A Few Suggestions  (Read 5910 times)

Offline Aeolus

  • Bot Neophyte
  • *
  • Posts: 2
    • View Profile
A Few Suggestions
« on: June 11, 2006, 06:50:59 PM »
Judging by the fact that I don't post on here often, you can tell I'm not the best bot programmer. I tend to run evolution sims most of all, and I've thought up a number of things that I thought would help people such as myself.

1. More Scripts
Specifically, the ability to add a robot, the conditions of so many cycles passing, or a certain robot's population reaching a specific height would all be helpful.

2. Fewer Sysvars
One thing I've noticed is because of bot programming, many many sysvars have been created. Unfortunately, this upsets the balance of evolution and the probability of getting the right sysvar in the right place. With each new version, it seems harder and harder for robots to evolve. Some solutions to this are getting rid of some sysvars, making certain sysvars more likely to be added to a bot, and most drastic of all, splitting DB into two versions: Evolution Intensive and Program Intensive.

3. Randomization Features
Currently, the only setting that can mutate are mutation settings. Don't get me wrong, that's a great thing, but in order to evolve a bot capable of surviving in a wide variety of conditions, you have to change the conditions. A randomization feature for nearly all settings would be needed, and the ability to turn of randomization for each setting as well. I don't expect this to happen any time soon, or even in the next versions, but it would be one of the best tools for evolving bots.

Thought these ideas may seem drastic and difficult, I feel that something needs to change in order to keep the Darwin in Darwinbots.
Aeolus, Keeper of the Anemoi, Piratical Pastafarianist.

What Would FSM Do?

There are 00000010 types of people in the world; those who know that binary is an eight digit system, and those who don't.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A Few Suggestions
« Reply #1 on: June 11, 2006, 09:48:40 PM »
1. I agree. I would eventually like to see some scripts available. Perhaps Lua (since it follows VB fairly closely in syntax).

2. This depends a great deal on what version you're referring to. Prior to 2.4 the program chose new sysvars or sysvars to change based on current sysvars. That is, .aimdx would mutate into .nrg or some other sysvar, and never (well, rarely) into 697, or some other "empty" memory location. The fewer sysvars there are the more likely any sysvar is to be selected.

2.4 just chooses numbers between 1 and 1000, which means any sysvar has a 1 in 1000 chance of being selected.

I'll freely admit the memory location to action system is the weak link in the mutation process. The stack works brilliantly for mutations. Since every command reads from or writes to the stack, mutated commands are quite likely to do (or not do) something new.

That said, from a reality standpoint, real organisms aren't terribly good at comming up with novel genomic code either. Most mutations in the animal/plant/fungal/protist world modify instead of create.

I think perhaps the best solution is to increase the domain of acceptable input for as many sysvars as possible. For instance, in the C++ version I'm moding shots be 10 if they're negative and 1000 if they're positive, so almost all values do something if they're stored in .shoot.

That doesn't fix the problem of finding the right sysvar, but it does soothe the issue of using a novel sysvar.

We could half the sysvars. Have 500, or even 250, instead of 1000. With tie commands replacing dozens of tie commands, the new sysvar list is looking rather sparse. And several read and write commands could be combined into one read/write command (.fix and .fixed for instance). That would probably help selecting sysvars, but it's still rather drastic.

3. This would probably be combined into scripts. Depending on how scripts are implemented you could end up with total control of program flow and settings.
------------------------------------------------
Drastic ideas are good, they help shake up the status quo.
« Last Edit: June 11, 2006, 09:49:12 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
A Few Suggestions
« Reply #2 on: June 12, 2006, 12:31:56 AM »
I agree with the thrust of the discussion here.  Here are a couple of steps in that direction:

2.42.6 will be out this week.

2.42.6 mods shot values as Num's describes except that negative shots are essentially mod 7 (it's a tad more complicated than this, but you get the idea).  So, beginning in 2.42.6, each and every possible value that can be placed into .shootval (except 0) will map to some morphological action.  In subsquent releases, I will be walking through other sysvars and as Nums says, similarly expanding the domain of possible inputs so that every mutation does something.  Suggestions here very welcome.  There is a reason biological DNA codons are degenerate....

Additionally, 2.42.6 has some fancy dynamic features which can modify incoming energy levels based upon total sim energy and change costs dynamically and automatically over time as a function of bot population.  Such features are focused squarely on evo sims where for example, you want costs to be low or even zero early in the sim, say before evolving a replicator or the ability to feed, but want to raise the selection pressure over time as bots evolve and become more effecient.

Personally, I'm mostly an evo sim guy, so while I'll take feature requests from anybody, most of the new work I'm doing on the 2.4 fork besides fixing bugs is focused squarely on evo sims.   You will probably see loci-specific mutations rates (visable to mutation and selection) for example within a month or so.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A Few Suggestions
« Reply #3 on: June 12, 2006, 01:31:59 AM »
If you check out the "source snapshot" I released a while ago, it contains a read me for sysvar changes I made in the C++ version.  That would be a good start as far as finding some ideas for changes to various sysvars.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A Few Suggestions
« Reply #4 on: June 13, 2006, 01:14:13 AM »
Been thinking about it, and this is my current thought:

Instead of sysvars and memory locations written to and from, have everything be a command, with current state information stored in a hidden Finite State Machine.

Sort of like how OpenGL works.

Sysvar commands would be either read or write. Read commands return information and place it on the stack. Write commands take information from the stack and directly push it into action.

Basically commands would either be input, output, or manipulation.

Alot of sysvars could be condensed or entirely modified. Shots, for instance, could be segregated into nrgShot, bodyShot, etc., removing the need for keeping track of -1, -6, etc. The parameter pased could then be the shot strength, what shootval is currently being used for for -1 and -6 shots. Up, dn, dx, and sx might  be combined into a single command that takes a vector (basically removes an (x, y) pair from the stack).

Here's animal minimalis rewritten in what I would see such a language being:
 
 bang = vector movement command I was talking about above.  It's also additive in this example (shvarz suggested this once, and I think in this example it works):

Code: [Select]
'Good for mutation sims and for newbies to see how a basic bot works.
'Contains everything necessary for it to survive and reproduce.

cond
5 eye 0 >
refeye myeye !=
start
refvel bang
 0 30 bang
 stop
 
cond
5 eye 50 >
refeye myeye !=
start
0 nrgshoot 'default strength energy shot
 0 -30 bang 'erase the added 30 velocity if we get too close
stop

cond
5 eye 0 =
refeye myeye = or
start
314 rnd turnright
stop

cond
nrg 20000 >
start
10 repro
stop

 Obviously alot of work would be needed to go through each and every sysvar and command and try and sort a clear and coherant language from it.  Special care would need to be taken with sysvar names I think.  Alot of them are currently a little obtuse.
 
 We'd probably need to create a kind of ARB to design the language, again similar to how OpenGL operates.  And, while I'm on topic, a way for users to create their own "extensions" would be nice, but I'm not sure how something like that might work.
 
 It plays to the strengths of evolution as I understand it from playing around with Darwinbots.  Random mutation is absolutely terrible at finding a single specific value needed for a specific action.  Most interesting mutations I've seen have been from the DNA manipulating the stack in a new way, and less from finding a new place to store data.
 
 Incredibly drastic suggestion, so I'm not really endorsing it yet.  Just brainstorming.
« Last Edit: June 13, 2006, 01:15:35 AM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
A Few Suggestions
« Reply #5 on: June 13, 2006, 01:58:36 AM »
I've been musing on this too, but I'm too tired right now to type or reply intelligently.  So, I'll be breif.

1) You have way too much time on your hands.
2) I think your proposal is bascially a Turing machine, yes?  Extremly powerful.  Hard to code in.
3) As far as evo goes, I think it's way more critical that the DNA be degenerate than that the grammer be small.  Sysvars arn't base pairs (there's more than 4).  They're not even codons (there's more than 64 or 21, depending on how you count).  They are more like amino acid sequences.  Not quite whole protiens, but higher level than simple amino acids.  And that is fine.  It's all binary at some point, but biology uses higher level contstructs and so should we.  My point is that I think the issue really has a lot more to do with the granulatiry of mutations and degerancy in terms of every possible mutation of a genome being syntacticly correct (which has a lot to do with mutation granulatiry) and semanticly operational (which has a lot to do with degeneracy) than on brevity of grammer.
« Last Edit: June 13, 2006, 01:58:50 AM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A Few Suggestions
« Reply #6 on: June 13, 2006, 03:17:03 AM »
1.  Very very probably

2.  I suppose it is.  I was basically imagining a kind of calculator language.  Or perhaps a Pushdown automaton.  The idea is to pool the currently seperate stack and sysvars.  The seperation seems to me to be relatively unnecesary -- another hurdle for the bot to jump over to get a new action working.

Evolution seems far more successful with the stack than with the memory array.  I think this has to do with the linear nature of the stack.  Where you read from and write to is already decided for you, which helps reduce the solution space without reducing the possible complexity.

We could still have memory for bots to use for various variables.  We could probably get away with like 100, or even a dynamic number depending on the bot's needs.

If we short circuit the [value sysvar store -> action] process to [value sysvar(s) -> action], I think it would make a huge difference.  Alot of sysvars seem to be heading this way conceptually as I work with them anyway.  The new tie commands, for instance, replace a huge number of old sysvars.

Another benefit: there are some inter-related sysvars that need to work in concert; if they were commands instead they could read or write multiple values at once, or even work differently depending on context.

3.  Not sure exactly what you mean by granularity and degeneracy.

Offline Greven

  • Bot Destroyer
  • ***
  • Posts: 345
    • View Profile
A Few Suggestions
« Reply #7 on: June 13, 2006, 06:25:16 AM »
The most drastic and best proposal I have seen.

Basically I see alot of potential in such system mainly:
most what you aleardy have written.
However it will make dna more readable (deciphering a 4000 evoluitic  bot, is just a mess!)

But it will also be easier for newcomers to pick you.
We could make a program that parses old bots, and outputs a bot with the new system.
10010011000001110111110100111011001101100100000110110111000011101011110010110000
011000011000001100010110010111101001110100110010111100101000001000001111001011101
001101001110011011010011100011110100111000011101100100000100110011010011100110110
010110000011100111101001110110111101011101100110000111101001101001110111111011101
01100100000111010011010001100001110111010000010001001000010100001

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A Few Suggestions
« Reply #8 on: June 13, 2006, 11:48:26 AM »
The main advantage I see is that it makes sysvars sysvars and numbers numbers.  You wouldn't get them confused as much as you do now.  There is nothing worse than trying to decipher something like:

5 600 2 div store

As you say it would make the DNA more readable, which would make running evo sims a little easier.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
A Few Suggestions
« Reply #9 on: June 13, 2006, 12:09:54 PM »
Quote from: Numsgil
3.  Not sure exactly what you mean by granularity and degeneracy.

Granularity (of mutations).  Essentially, at what level are mutations possible and is the result of the finest grain mutation still syntacticly and semanticly correct?  In DB, a genome is a sequence of numbers in a text file.  The smallest granulatiry of a mutation is a point mutation which changes one of these numbers, as opposed to say changing an underlying bit in the binary representation of the text file.  Restricting mutations to the former insures that genomes remain at least sytically correct.  Allowing the latter would result in a illegally formated genome and likely crash the program.  This is what I mean be granulatiry of mutations.  It matters not in my opinion how "high level" the DNA grammer is as long as the finest possible mutation respects the grammer syntax rules.  Biological DNA "allows" real point mutations at the real base pair level and this works becuase the DNA encoding is degenerate at that level (see next paragraph).  I'm arguing that sysvars are not really base pairs and that DB as a consequence does not allow real BP mutations, which would be equivalent to bit level changes in the underlying binary, becuase to do so would result in illegally formated genomes.  

Degeneracy.  This term as I am using it is used in genomics (and other coding systems) and refers to to fact that all 64 possible codons in DNA result in legitmate instructions and more importantly, that there are multiple codons which map to the instruction to make the same amino acid (all proteins in DNA based organisms are built from the same 20 amino acids, so except for a couple of special codons like STOP, there are up to 6 different ways I think, 6 different 3 bp sequences,  to encode the instruction to manufacture a specific amino acid).  A coding system which has this property, where there are multiple ways to encode the same instruction, is said to be degenerate.   I am essentially re-iterating and emphasizing your call to insure the domain of all sysvars result in legal, functional actions and ephasizing the importance of this over simply simplifying the grammer.
« Last Edit: June 13, 2006, 12:12:17 PM by EricL »
Many beers....

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
A Few Suggestions
« Reply #10 on: June 13, 2006, 02:19:56 PM »
Quote
There is nothing worse than trying to decipher something like:

5 600 2 div store

That kind of thing doesn't bother me in the least. I sometimes even write DNA that way. If anything I would be happier to lose the name tags.
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline S.o.G.

  • Bot Neophyte
  • *
  • Posts: 10
    • View Profile
A Few Suggestions
« Reply #11 on: June 13, 2006, 04:21:21 PM »
one way to add degeneracy would be to group instructions & sysvars into a manageable set of logical groups and for each group identify a semantic distance for all the other groups. then when mutating an instruction or sysvar, choose the new one from a bell curve distribution of the other groups based on their semantic distance from the group of the original instruction. With the most likely mutation being another instruction in the same group.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
A Few Suggestions
« Reply #12 on: June 13, 2006, 06:21:37 PM »
Quote from: S.o.G.
one way to add degeneracy would be to group instructions & sysvars into a manageable set of logical groups and for each group identify a semantic distance for all the other groups. then when mutating an instruction or sysvar, choose the new one from a bell curve distribution of the other groups based on their semantic distance from the group of the original instruction. With the most likely mutation being another instruction in the same group.
I like this idea, but I think there are two issues here.  What you are suggesting allows for the leap through morphospace due to a mutaion to have locality.  Namely, with your suggestion, mutaions will generally result in small changes in morphology and behaviour rather than wild leaps through the organism space.  This may or may not be important (I'm no expert for sure and even single point mutation changes in biological DNA can often have huge phenotypic impact - think Hox genes - so its not clear to me that a smooth morphospace as far as individual mutations go is really necessary) and may or may not be implementable (its not immediatly clear to me that its feasable to define a set of sysvars/instruction sequences which form a smooth semantic space) but I think this is a slightly different issue than degeneracy.

The genome space can still be degenerate without being continious and smooth.  All we need insure is that to the extent possible, all syntacially possible genomic sequences have some sort of semantic functionality.  Note that "doing nothing" such as how the vast majority of mutated shots (negative valued Shots outside the range -1 to -7) used to be before they were MODed (beginning in 2.42.6) is functionality of a sorts, but the point is that in order to evolve complexity in finite time, the percentage of "do nothing" sequences realtive to the space of all possibible sequences should be small.
« Last Edit: June 13, 2006, 06:22:41 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A Few Suggestions
« Reply #13 on: June 13, 2006, 08:11:21 PM »
Quote from: EricL
...but the point is that in order to evolve complexity in finite time, the percentage of "do nothing" sequences realtive to the space of all possibible sequences should be small.

 I strongly agree with this.

A (perhaps small) part of the problem is that the number of memory locations that do anything at all is so small.
« Last Edit: June 13, 2006, 08:13:00 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
A Few Suggestions
« Reply #14 on: June 13, 2006, 08:51:14 PM »
Quote from: Numsgil
A (perhaps small) part of the problem is that the number of memory locations that do anything at all is so small.
Oooh Oooh.  That is an excellent idea and easy to code too....  On the list for 2.42.7.
« Last Edit: June 13, 2006, 08:52:35 PM by EricL »
Many beers....