Code center > Darwinbots3
IRL DNA
Numsgil:
Self modification is something I'd like to stay away from. I think it would tend to cause more harm than good. Although I do plan to allow bots to modify the mutation rates of codules, or force a mutation, if they want (to model something like what happens when antibodies are being created. Though I don't think mutations are necessarily involved there).
Codules, like sysvars, have numbers assigned to them. "Null" codules fall through to codules beneath them (or are randomly connected, I haven't decided. As long as it forms a long loop it doesn't really matter). Once the first non null codule is found it executes, maybe calls other codules, then exits and the call stack collapses back up the tree. Or if no codules are non null eventually it'll try to call a codule already in the call stack, fizzle, and then the call stack will collapse back up. I might also designate some subset of the codule space for "sub codules" which can only be called from a "parent codule".
So basically a zero bot might evolve a call to codule, say, 172. At first this does nothing. But then maybe there's a mutation which snips off a piece of the main DNA thread and assigns it to codule 14. That call to codule 172 will end up calling codule 14 and that snippet of code will execute. If another codule gets created at, say, 50, that one will execute instead. So it should be pretty easy for evolution to evolve some codule usage.
jknilinux:
--- Quote from: Numsgil ---Self modification is something I'd like to stay away from. I think it would tend to cause more harm than good. Although I do plan to allow bots to modify the mutation rates of codules, or force a mutation, if they want (to model something like what happens when antibodies are being created. Though I don't think mutations are necessarily involved there).
--- End quote ---
-So they can't modify that which is in codules? Only change mutation rates? How, exactly, does evolution view DB3 DNA? How would it switch, for example, 2 DNA strands in the same codule?
--- Quote from: Numsgil ---So basically a zero bot might evolve a call to codule, say, 172. At first this does nothing. But then maybe there's a mutation which snips off a piece of the main DNA thread and assigns it to codule 14. That call to codule 172 will end up calling codule 14 and that snippet of code will execute. If another codule gets created at, say, 50, that one will execute instead. So it should be pretty easy for evolution to evolve some codule usage.
--- End quote ---
-What is the main DNA thread? Is there some sort of main non-codule thread that always executes, and then codules are just interrupt-driven data structures?
Numsgil:
--- Quote from: jknilinux ---
--- Quote from: Numsgil ---Self modification is something I'd like to stay away from. I think it would tend to cause more harm than good. Although I do plan to allow bots to modify the mutation rates of codules, or force a mutation, if they want (to model something like what happens when antibodies are being created. Though I don't think mutations are necessarily involved there).
--- End quote ---
-So they can't modify that which is in codules? Only change mutation rates? How, exactly, does evolution view DB3 DNA? How would it switch, for example, 2 DNA strands in the same codule?
--- End quote ---
What do you mean by two DNA strains in the same codule?
--- Quote ---
--- Quote from: Numsgil ---So basically a zero bot might evolve a call to codule, say, 172. At first this does nothing. But then maybe there's a mutation which snips off a piece of the main DNA thread and assigns it to codule 14. That call to codule 172 will end up calling codule 14 and that snippet of code will execute. If another codule gets created at, say, 50, that one will execute instead. So it should be pretty easy for evolution to evolve some codule usage.
--- End quote ---
-What is the main DNA thread? Is there some sort of main non-codule thread that always executes, and then codules are just interrupt-driven data structures?
--- End quote ---
I'm not sure what you mean by interrupt driven data structures. Imagine that current DB2 DNA. It's like a "main" codule. It gets called once per cycle. From that main codule you can call other codules, like function calls in a C program. The difference is that if you attempt to call a codule already on the call stack it just fizzles. And if you attempt to call a non existent function it calls the "closest" function it knows about. The main codules is probably codule 0 (so that "null" pointers play nice and fizzle).
The codules themselves behave exactly like the main codule. There's no extra magic behind the scenes.
jknilinux:
I guess I'm asking: how does evolution only work on codules and not on DNA commands? Or, like you said, on "beads" and not on the DB assembly itself? That's the goal with codules, right? How is that the same/different?
Also, I was asking what the difference is between the main codule and the others... is it just that the DNA execution begins in the main codule? So is the main codule kinda like the int main(argv, char* argc) function in C?
Numsgil:
The beads in my analogy are individual base pairs (add, store, etc.). Though mutations can work on the codule level as well. So codules can be duplicated, deleted, randomly inserted, etc. But most of the "work" of evolution will be inside the codules doing traditional mutations.
Yes, the main codule is like the int main in C.
I might also create some "system" codules, that are called specially for certain events. They'd operate sort of like a callback. For eyes, for instance, I'm thinking that each object visible to the bot causes a special "vision" codule to fire. Each call of the vision codule would happen by the system, and would change the sysvars sent to the vision codule. After the vision codule has been fired for each visible object, the main codule gets to run. To keep with the C analogy, these system codules are sort of like interrupts. I still have to really think through the implications, but it makes a lot of sense to me right now. The only real downside is that it hard codes some really high level structure to the DNA. I'd be happier if the DNA didn't require imposed high level structure. But I can't think of a nice way to do something like:
--- Code: ---given visible objects, sort based on distance
for each visible object in sorted list
call appropriate reaction codule
--- End code ---
with my current plans for DNA. The main problem is the foreach type loop. I really don't want to expose looping capability to the DNA, not even finite loops where there's definitely a finite number of iterations. It's far too easy for evolution to invent some sort of nest loop that would eat through performance. If you had 3 loops from 1 to 1000, nested in side each other to form a trivial O(n^3) algorithm, it'll take about 3-5 seconds to run per bot per cycle. With the way the DNA currently works, even with plans for Codules, there's a direct link between DNA size and execution time.
I could make it a language rule that loops can't be nested (have nested loops fizzle), but that seems overly arbitrary. And it would make debugging DNA potentially confusing since the rule would have to be enforced across codule boundaries.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version