Code center > Suggestions
Eventual improvements to DNA language
Numsgil:
--- 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.
--- End quote ---
Yes, but current syntax requires start after cond. Remember I'm converting "start" statements into two: stop followed by body.
--- 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:
--- End quote ---
I'd have to work out all the cases to see how it'd work. It seems a bit overly complicated (ironic, I know). If nothing else it becomes difficult to keep it all straight. And I can't imagine what you'd want to nest more than a level on.
--- 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.
--- End quote ---
It's usefulness is such a special case I can't imagine it being unfair in some way. But if that's how people feel, I'll wait to add it until I add an on/off switch for all the commands (so it can be off if you prefer).
Personally I feel if a shortcut is legitimate, that is, it's not a macro, but a different way of approaching a problem, it should be a valid addition.
shvarz:
--- Quote ---Yes, but current syntax requires start after cond. Remember I'm converting "start" statements into two: stop followed by body.
--- End quote ---
So, before there was one command required and now two - things got more difficult for evolution. In my model still only one commands is required.
--- Quote ---I'd have to work out all the cases to see how it'd work. It seems a bit overly complicated (ironic, I know).
--- End quote ---
Yeah, it is not perfect. I hate the fact that "body" is required to go up the level of conditions. Some kind of special command maybe?
--- Quote ---And I can't imagine what you'd want to nest more than a level on.
--- End quote ---
Me neither, but it is a very open system and future-proof, that's why I like it. Having just one level with a special command for it is more restrictive. What if you decide to allow another level later?
What we need is system that is as simple as possible, but one that still allows (at least in theory) the bare minimum:
1. Conditions and executions can go in any order and not necessarily one after another.
2. Nested conditions should be possible.
Numsgil:
Well, in other programming languages you have operators to end the current level and go up.
VB uses 'end X' whre X is whatever block you're ending.
C uses multipupose { and } operators to show when you're entering a new level.
We can use the VB model, but remove the X in end X (one command better than two) and have cond-stop, cond-cond-stop-stop cond-cond-stop-cond-stop-stop,etc.
We'd have to start writing bot code with tabs to keep it all straight, or it becomes a mess.
I'll spend some time thinking how best to implement it.
Back onto the cond-stop method, we'll need a way to end a condition if the above is to work. A stop operator works well for this purpose. Without the stop operators, scope becomes impossible to determine.
That is, without stop:
cond
'condition
body
'do stuff
stop
becomes identical to:
cond
'condition
..body inside condition
..do stuff
..stop
The only way to tell the difference between the two is wethere there's two stops or one at the end, and that makes the DNA language difficult to parse and execute.
shvarz:
You know, I was thinking along the lines of keeping things simple and using stuff that is already available, and I think that even the nested conditions are not necessary. The same effect can be achieved using existing DNA syntax. It is a pain to program them, but it can be done, right?
So, what if all the shortcuts, like nested conditions and your "select" commands are converted into the conventional DNA language when DNA is loaded into a sim? I don't see why it can't be done. It would be a pain to read the DNA back after it evolved, but some tools can be created for converting it back into compressed form. What do you think? This would keep both parties happy.
The only addition to current syntax we would need is to allow stopping of a condition using "stop" command, so that DNA can flow like this:
cond
blah
stop
junk DNA here
start
blah
stop
The stop command would not even be required. As I said, when the program meets cond, start or else commands, it just assumes that there was a "stop" right before it.
There would be no condition stack, just an execution flag, as we discussed. If two conditions go one after another, then the second condition simply over-writes the flag.
Numsgil:
Here's why I wanted Noble genes:
Currently the bots are a collection of equally footed genes. That is fine for simple organisms, where each gene represents an overall strategy, but makes more complex behavior models more difficult.
For instance, say you design a bot with 20 find food genes, 10 find a mate genes, and 3 nothing to do genes. Now say you have a condition in each one *.mood X = to turn on which instruction set you follow.
In the current system, when you run an evo sim, there's nothing to keep those 20 find food genes connected to each other. Over time one is bound to lose that *.mood X = condition. That's fine if you don't care how the bot evolves, but if you're trying to watch it get more complex, you'll be disapointed.
One might argue that the bot will only lose these conditions if it's in its best interest. However, this isn't how mutations work! Mutations select against bad, instead of rewarding good. Simple entropy will eventually move the genes from being so directly related to each other unless doing so makes it fundamentally less fit. But there's no guarentee of that.
If they're related to each other through a noble gene, the chances that the genes will drift apart decreases. They're much more likely to oevolve in context with each other.
If mutations are like small explosions, these new controls are like gun barrels. If you can concentrate the explosions in one direction, you can produce more useful work.
Looked at another way, if there are N possible mutations, there will be P such mutations that wreck any complex, heirarchial behavior system. If the hierarchy is enforced from within the DNA language, then P decreases without effecting N.
So the reason I want these controls is not just ease of programming. I'm hoping mutations can be herded together to encourage genes to mutate not just against the fitness of the bot as a whole, but against how it works with other genes.
I'm not sure this will have the desired effects I'm after. It's not a law I'm espousing here, but a theory.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version