Code center > Suggestions
Eventual improvements to DNA language
Numsgil:
This thread is primarily a place for me to record all my thoughts for DNA in one place. But I'd like feedback as well, so instead of just writing it up on my computer, I'm positng it. Most of this was in old posts, some from February, and it was fairly well recieved then, so I'm not too worried.
I recommend printing this out and taking it with you to lunch. It's quite long, even for one of my posts :P Feel free to read and comment on one section at a time.
[span style=\'font-size:11pt;line-height:100%\']DNA STRUCTURE[/span]
This is the idea I have for expanding the language to make it easier for complex behaviors to be developed and hopefully evolved.
First off, the cond-start-stop structure is refined to a cond-stop-body-stop-else-stop structure. For backwards compatibility, 'start' is interpreted as a stop-body command in one (won't be evolved by the DNA, and when it's read in by the parser it will place it at two commands, stop and body).
cond, else and body set a flag that determines how the following DNA is executed (this idea is from shvarz, though it was a while ago). This is called the execution flag. It'll be referenced quite a bit below, so be sure you understand what I mean by flag.
Now, here's the main commands:
1. cond tells the DNA to evaluate and place conditions on the conditions stack, and accept logic commands.
2. else and body tells the DNA to evaluate store, inc, and dec commands.
3. stop command resets the current mode.
cond and body and else are all mutually exclusive. You can't store commands and evaluate conditions in the same section of the DNA. If there is a body command after a cond but before a stop, nothing happens. The reverse is true. (Or we could do it the other way. A body command after a cond switches evaluation types and empties the conditions stack. Either works, so long as it's consistant).
A stop statement is multipurpose. If the execution flag is set to cond, then it will AND together all true/falses on the conditions stack. If the result is true, it sets the condition flag to allow the next body command to be evaluated. If the result is false, it sets the execution flag to allow the next else command to be evaluated.
If the execution flag is set to body when the stop command is called, store, inc, and dec are no longer allowed to operate. In addition, the flag is cleared out, awaiting a new cond statement.
Likewise if the execution flag is set to else when the stop command is called, it's cleared out.
If a stop is called when there's nothing to stop, that is, the execution flag is still clear, nothing happens.
If a body or else is called when the execution flag is already set to body or else, nothing happens.
So here's what I'm thinking basically. It's easier to explain via example.
--- Code: ---cond
*.nrg 5000 >
stop
'some Junk DNA
body
50 .repro store
stop
'some more Junk DNA
else
-1 .shoot store
10 .up store
stop
end
--- End code ---
[span style=\'font-size:11pt;line-height:100%\']Select / Cond[/span]
Similar to regular gene flow, but slightly modified.
Here's a sample segment of DNA
--- Code: ---*.robage select
'(Note that there's no stop here!)
cond
0
start
5 .tie store
stop
cond
1 5
start
5 .deltie store
stop
stop 'this is the stop for the select
--- End code ---
Okay, now that you've seen it, I'll show you how it's working.
Select sets the execution flag for conditions to operate slightly differently. The conditions stack remains off. However, any values put onto the regular stack inside the condition are evaluated against the variable selected for, in this case *.robage. If any of the values are equal to the selected value, the gene is executed.
The second cond above works the same as
--- Code: ---cond
*.robage 1 =
*.robage 5 = or
start
5 .deltie store
stop
--- End code ---
That is, all the evaluations against the selected variable are ORed together.
[span style=\'font-size:11pt;line-height:100%\']Nested conditions (Noble genes)[/span]
These work exactly the same as the regular commands above, but the bodies themselves can't execute store, inc, or dec.
The commands are all the same as all the above, but capitalized. They allow large sections of DNA to be turned on or off.
Basically:
--- Code: ---COND
*.nrg 5000 <
STOP
BODY
gene1
gene2
gene3
STOP
ELSE
gene 4
gene 5
gene 6
STOP
--- End code ---
if *.nrg is less than 5000, then genes 1,2,and 3 will have a chance to be evaluated. Otherwise genes 4,5, and 6 will have a chance. Gene1 still might not excute even if *.nrg is less than 5000 if its condition doesn't evaluate to true.
These uppercase controls I call 'Noble' genes. The regular lower case genes are called 'Pleb' Genes. I haven't worked out exactly how the execution flag will work with these noble genes. Very likely they will have their own seperate execution flag.
The idea is to be able to group large amounts of DNA that are supposed to be run together simply and easily, as well as encouraging them to be near one another.
[span style=\'font-size:11pt;line-height:100%\']Sleep Command[/span]
This is basically a multithreading idea that would work well for DB to coordinate events between multiple cycles.
the syntax is:
number sleep
This will cause the current gene to 'sleep' for number cycles. Once it awakens, it will continue the execution of the gene where it left off.
Something like this to remove a birth tie:
--- Code: ---cond
*.robage 0 =
start
5 .tie store
1 sleep
5 .deltie store
stop
--- End code ---
The gene will not be evaluated while it is sleeping. That is, you cannot have more than one copy of the same gene executing at the same time. This is the price you pay for sleeping: not executing again until you're all done.
For example, this will only allow you to reproduce every 50 cycles:
--- Code: ---cond
start
50 .repro store
50 sleep
stop
--- End code ---
The logistics can be accomplished by a command stack of genes and timers. Shouldn't be too difficult.
[span style=\'font-size:11pt;line-height:100%\']Conclusion[/span]
These changes hopefully will encourage more complex DNA to develop from both writers and mutations. Most bots today are still very, very simple. Archeabacteria knock our socks off! Alot of the above is based on programming languages and computer science theory, but that doesn't mean they can't be useful to organsims.
Since the stop command is used so heavily, it should have a disproportionate chance of developing. Also, since the noble genes should control several smaller genes, noble commands should be less likely to develop. I'll probably need to develop sliders for the different types, or have noble commands be a seperate type altogether.
Endy:
I like the ideas about Noble genes, select, and sleep. Not so sure about all the stops... It's pretty late where I am, I'll try again in the morning to understand it all. :blink:
P.S.
Started porting the wiki over, also checking out wikipedia for ideas to use in ours.
Not that big of a post Nums, only took a few minutes to read. :)
Endy B)
Numsgil:
--- Quote ---Not that big of a post Nums, only took a few minutes to read. :)
--- End quote ---
Must have just seemed bigger in my head. Feels good to put it all in one place.
Greven:
Num this is some very nice ideas! This will certainly make the DNA language much more powerfull! And will make DB better in many ways.
The new 'stop' multi-function is much better.
I just have one worry (maybe more but this one is what first came to my mind):
What happens when the bot evolve a 'select'-command and there are no additional stop, to stop the 'select'? How will the program handle this?
Will it be possibly in this system to have something like this:
--- Code: ---cond [REAL]
0 1 >
stop
[JUNK]
body
1 2 store
cond [JUNK]
stop
--- End code ---
what will this do?
Stop the junk cond or will it stop the real one? or will it not be possible to have this?
(I think it would be great to have this!)
Numsgil:
I'm not sure Greven, I think we just have to pick a rule that we like. I'm in favor of cond, body, etc. not being activated if the execution flag isn't set appropriately. So the last stop would stop the body block since the cond wasn't activated.
That is, you have to finish you current block before you can start a new one. This isn't as hard as it could be since stops are multifunctional. A stop that used to stop a cond can just as easily be made to stop a body or a select.
If you get to the end of your DNA and some parts haven't been 'stop'ed, the program will just close them all anyway. Easy enough.
I'd love to get Carlo's take on this. Although I'm afraid I have a feeling what his feelings might be :rolleyes:
Navigation
[0] Message Index
[#] Next page
Go to full version