Code center > Suggestions
Genome structure
Numsgil:
Now that I think of it, you would want store, inc and dec to remove values from the stack even if the condition stack is false. You just wouldn't do anything with those removed values.
Basically, this makes the DNA 100% deterministic. You'd always be able to easily decipher any evolved DNA, because you wouldn't have to worry about wether or not a store in a start block gets executed or not.
shvarz:
Well, it looks like I'm not the only one who has problems with the current genome structure
I think removing cond command is a good idea. The conditional functions (<, >, etc) are by definition conditional and there is no need to separate them structurally from the rest of the DNA.
I also like the idea of some higher-order condition/start commands.
I guess the real question is about the mechanism in which these conditional commands would activate the execution of DNA. Here we have a lot of ideas, one contradicting another.
I have a bit of a problem with this particular approach:
--- Quote ---*.nrg 4000 > 50 .repro store
--- End quote ---
Looks like this will connect conditions only to the closest store commands, while I think that there is a need to execute fairly large chunks of DNA. But I may be wrong. Maybe creating such short-distance connections is the key. It certainly makes evolution easier. But I am not ready to do away with the "start" and "stop" commands.
In answer to Jez:
Bot designers like predictability because they can fine-tune the responses of bots.
You would probably like to write code in the way:
"I see a bot, it's not the same species, it has a lot of energy -> Fire a shot".
During evolution all three conditions must have a very strong selective pressure to remain in the gene. If they don't then they are thrown away and gene is left to fire constantly. Also, mutations within conditions have a high probability of killing the whole gene. Insert something like an extra "<" or even just a number in the wrong place and condition outcome turns into "false" and gene is not activated.
For evolution it is easier to manage this situation if the condition is made more flexible. It is similar to writing code in this way:
"I see a bot -> I consider firing a shot at it (20% probability of firing)
I see a bot -> Maybe I should fire (40% probability of firing)
The bot has a lot of energy -> I am pretty sure firing is a good option (60% probability of firing)
It's not same species -> Even better, I am seriously considering firing a shot (80% probability of firing)
The bot has a lot of energy -> Yeah, looks like firing is the only option ("100% probability of firing)
In this way you can mess up one of these conditions completely and still have a gene that functions at 80% efficiency. You can mix and match conditions so that some conditions drive the probability of gene execution up, while others drive it down, which allows for some fairly flexible logic.
Numsgil:
--- Quote from: shvarz ---I have a bit of a problem with this particular approach:
Looks like this will connect conditions only to the closest store commands, while I think that there is a need to execute fairly large chunks of DNA. But I may be wrong. Maybe creating such short-distance connections is the key. It certainly makes evolution easier. But I am not ready to do away with the "start" and "stop" commands.
--- End quote ---
This is where codules would come in, I think. The way codules would work, you could have a short distance condition control the entrance to a codule which itself contains a large amount of DNA.
For instance, suppose you have a codule that looks like this:
A:
*.nrg 5000 > 50 .repro store
*.nrg 500 < 100 .fdbody store
You could control entry to this codule using something like the following:
*.robage 10 > A ifcall
where ifcall calls the codule only if the current condition is true.
So this really only works at peak efficiency in tandem with codules.
Jez:
Thanks Shvarz,
You are right, I like the - If This then Do That.
Using your example the bot would still have an 80% chance of firing at a friend, I guess you would have to add several 'drop' options as well.
I'm not sure about this approach, the randomness of doing an action, I thought organisms were more defined in their stimulus/reaction.
I am in full support of changing something in some way to help with the problems that you originally outlined, the problems that the current code causes with mutations, just not yet sure if this would be the best approach.
shvarz:
The current functionality would be preserved for bot designers, although the code would look a lot more messy. If you want "If this do this" gene, then just repeat all your conditions 10 times, so that the probability of gene execution goes up to 100%. And I'm sure you can come up with some more elegant solutions as well.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version