Code center > Suggestions
Eventual improvements to DNA language
Greven:
Oh my god! I got stars alast!!!!!!!! :D :boing: :boing: :boing: :boing:
But what Carlo is thinking is not important, if the community like it, implement it!
But still his opion is to be taken into account, but I think he would like it, it will make DB better in many ways!
Carlo:
--- Quote ---I'd love to get Carlo's take on this. Although I'm afraid I have a feeling what his feelings might be
--- End quote ---
I'd just like to know what is the rational for all this proposals. You say:
--- Quote ---This is the idea I have for expanding the language to make it easier for complex behaviors to be developed and hopefully evolved.
--- End quote ---
and
--- Quote ---These changes hopefully will encourage more complex DNA to develop from both writers and mutations. Most bots today are still very, very simple.
--- End quote ---
That's ok. But you should be more specific about which things exactly would be better, and why. For example: how each of these changes would positively affect mutations? And how programming? What would be possible that isn't possible now, from one point of view or the other? How should mutations handle these new flow control instructions? Etc.
shvarz:
Hmm, I feel like the new syntax is actually going to be more restrictive than the current one. All those rules.... I'd rather relax them. Also, I don't like the idea of Noble genes. I think I have a more elegant solution.
What I would change:
1. "Stop" command should not be required for anything. When the program meets "cond" and "body" and "else", it just assumes that there was a "stop" in front of it.
--- Code: ---cond
blah
start
blah
cond
blah
else
blah
end
--- End code ---
should work just fine. "stop" may still appear, but it does not have to. One possible use for stop would be to separate real DNA from junk.
2. Instead of Noble genes we can simply have nested conditions. There is no need for additional syntax. Conditions place their "execution flags" on somthing like a stack (but not really a stack) with earlier values acting as your Noble genes toward later values. The syntax will be very simple:
--- Code: ---cond
*.nrg 5000 >
cond
*.nrg 7000 <
body
blah
cond
*.nrg 9000 <
body
blah
body
stop
--- End code ---
The last part there is to remove the original conditions flag from stack, so that it does not transfer to the next part of DNA code.
This way you can have multiply-nested conditions without any additional commands.
3. I don't like the select command, because the same can be accomplished using commands that exist already. Keep it simple.
4. Sleep command - no opinion right now.
Numsgil:
--- Quote ---Hmm, I feel like the new syntax is actually going to be more restrictive than the current one. All those rules.... I'd rather relax them.
--- End quote ---
The syntax is backward compatible, so I'm not sure what you mean by more restricitve. At the very most it's as restrictive, unless I'm missing something.
--- Quote ---1. "Stop" command should not be required for anything. When the program meets "cond" and "body" and "else", it just assumes that there was a "stop" in front of it.
--- End quote ---
Very possible. The only problem of course is that we have no way of assigning Junk DNA to stretches of the genome (assuming that is a problem of course), which is what I would like to see happen. In this method, the DNA will or more less be expressed 100% all the time. But as I said before, all we have to do is think up a rule system we like and go with it. I wouldn't be opposed to this idea at all.
--- Quote ---2. Instead of Noble genes we can simply have nested conditions.
--- End quote ---
The only reason I didn't suggest nested conditions of indefinate depth was that it seemed too powerful to me, and caused problems with the syntax of the above stop commands. Again, I'll go with popular opinion on this one. Either one accomplishes the same objective.
Noble genes allow you to quickly and easily see which level a cond, start, etc, is on. As well as clearly defining the roles each is to play, since Noble BODY commands can't perform any store operations.
Also, I see problems if you want to go up a level in the nested structure. Like:
cond
blah
..cond
..blah..
back down to the original level
but then I guess we'd use the stop command?
--- Quote ---3. I don't like the select command, because the same can be accomplished using commands that exist already. Keep it simple.
--- End quote ---
Select makes things easier only if you have long runs of genes all doing the same thing for slightly different values. Such as a multibot assigning tasks for each cycle after it's born. In such a case:
cond
*.robage 0 =
start
stop
cond
*.robage 1 =
start
stop
cond
*.robage 2 =
start
stop
cond
*.robage 3 =
start
stop
becomes:
*.robage select
cond
0
start
stop
cond
1
start
stop
cond
2
start
stop
cond
3
start
stop
stop
Which not only is slightly shorter, but decreases the chance of the genes drifting apart during mutations. That is, all the genes are involved in the same logical operation, so they should probably be grouped in some way inside the genome. If you or mutations change the condition from robage to something else, the effect can effect multiple genes at once, instead of having to go through each one one at a time.
Carlo:
All the ideas are borrowed straight from computer languages. The advantage of select is the same advantage it has in all languages, it helps combine what otherwise would be long stretches of almost identical if statements.
The advantage of sleep is that it allows single genes to work over multiple cycles. I don't know if you've tried coordinating actions that take more than one cycle, but it isn't that easy. sleep definately makes it easier.
Noble genes allows the genome to be constructed as a large Finite State Machine, with much broader states than allowed currently. So you can have 'hunt' mode, 'find a mate' mode, etc, and the appropriate genes are all turned on and off quickly and concisely.
If instead you added the state condition to all genes manually, the chances of these interrelated genes drifting apart through mutations becomes more probable. That's fine for some sims, but others would like to see more specific changes to the details instead of the structure.
The changes in DNA structure allow Junk DNA to form, helps make the structure less rigid, allowing mutations to change order of genes, stop commands, etc. more easily. A stop can be deleted, combining two genes into one, etc.
The sleep command is my favorite. It's relatively simple, but solves alot of the problems of forming complex multibot structures.
shvarz:
--- Quote ---The syntax is backward compatible, so I'm not sure what you mean by more restricitve. At the very most it's as restrictive, unless I'm missing something.
--- End quote ---
Does not your syntax require "stop" after each "cond"? That's an additional rule. Not a big deal for designed bots, but may be an important factor for evolving bots.
--- Quote ---The only problem of course is that we have no way of assigning Junk DNA to stretches of the genome
--- End quote ---
Yes, we do. That's where "stop" command comes in. It stops execution of any meaningful DNA; stuff after "stop" is not expressed untill the next "cond", "start" or "else" is encountered.
--- Quote ---The only reason I didn't suggest nested conditions of indefinate depth was that it seemed too powerful to me
--- End quote ---
I don't think it is too powerful, but let's hear from other people. Remember that for evolving bots having multiple nested "cond"s would be a liability, because it makes DNA very inflexible, essentially leading to dead-ends in evolution.
--- Quote ---lso, I see problems if you want to go up a level in the nested structure. Like:
cond
blah
..cond
..blah..
back down to the original level
but then I guess we'd use the stop command?
--- End quote ---
I am not too good with programming, but I think I see what you mean. I think I tried to solve the same problem by having "body stop" command. In my idea any time "body" command is encountered, the value of an execution flag is removed from the "execution flag stack" and you move up the level of conditions. Is that clear? I think not, so here is an example:
--- Code: ---cond
1 1 =
'execution stack reads "true"
cond
1 2 =
'execution stack reads "false, true"
cond
1 1 =
'execution stack reads "true, false, true"
body
'true is removed from the stack,
'body is not executed, because there is a "false" somewhere in the stack
'execution stack reads "false, true"
blah-blah
else
'false is removed from the stack
'else is executed, because false was just taken out and the higher level condition is true
'stack reads "true"
blah-blah
'here would be the end of the section of DNA to which the very first cond is applied
'but the execution stack still reads "true", so it has to be removed
body
'true is removed from stack, which is empty now
stop
--- End code ---
I certainly hope this makes it clear...
--- Quote ---Select makes things easier only if you have long runs of genes all doing the same thing for slightly different values.
--- End quote ---
I understand the purpose of select command, but still think it is a bad idea. For programming language it makes sense, but as far as artificial life goes, it is counter-productive. The whole thing about AL (as Carlo pointed out, and I agree) is to assemble complex structures from simple rules and elements (also, see my sig). So, if something can be done using existing elements and rules, then I am strongly against introducing shortcuts just for the sake of easier programming.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version