Code center > Suggestions
Non-Determinstic Bot DNA flow
Carlo:
--- Quote ---First of all, I want to comment on Carlo's notion that we already have junk DNA. This is not exactly true, becasue true junk DNA is not expressed at all, while any "junk code" that evolved bots acquire actually does affect bot's behaviour - at the very least it places some numbers on the stack, which may affect real genes later on. So, when I am talking about junk DNA, I mean DNA that is not processed by program at all.
--- End quote ---
I really can't understand your point. Junk dna is present in DB in form of copies of genes which have been inactivated by mutations in the cond section. So it is really dna which is not processed at all. Take a look at some of an evolved dna files (for example FilansEvolved, though I don't know if it is in the standard distribution). It is full of genes which are never activated.
--- Quote ---duplicate gene >> turn one copy off >> mutate for a while>> turn it back on>> got a new protein.
But then I thought about it some more... In DBs we are forced to use relatively high mutation rates, becasue we don't have time to wait for millions of generations for something good to appear and our population size is several hunderds at most. At these mutation rates, any inactive gene will go into complete mess very quickly and is unlikely to become anything even remotely useful for a bot.
--- End quote ---
And this is true. This is why, for example, there was (is?) a cap at three conditions per gene in the mutation routines (that is, no mutation can insert new conditions in a gene which already has three conds). The less the conditions, the more probable a gene is executed; and when a gene is executed, selection works on it again, so that it stops accumulating junk. The idea was of making possible and fast this cycle:
working gene -> gene duplication -> gene inactivation -> mutation -> gene activation -> working gene
The less the time between gene inactivation and gene activation, the more probable to select interesting features.
I'd like to propose again the non deterministic execution of genes. This means that only one gene should be executed per cycle. The gene to execute would be chosen randomly among the active genes, those which have true conds for that cycle.
Why:
1) there would be no more the mixture of sequential and non sequential execution of genes. Position in dna would count no more.
2) no more the problem of genes writing values in output location, taking effect only in the next cycle. For example, now if you have a gene which passes information through a tie and at the same time writes a flag in a memory location to tell another gene that it has done its job, you have the problem that the flag is immediately readable by the other gene, but the information won't actually pass through the tie until the next cycle. The other gene is activated by the flag if it comes after in the dna; it will be activated only in the next cyle if it comes before in the dna (I hope you understand what I'm saying, today my english is a real shit :))
3) Number of genes would count. As only one gene is executed randomly at each cycle, if the frequent execution of a gene is really important then for a bot is convenient to have multiple working copies of that gene. It's like evolving reaction times: more prompt reaction to events means more copies of a gene.
4) multiple working copies of a gene means also multiple slightly different copies of that gene working. Now, if you have two working copies, slightly different, of the same gene, the one which comes last in the dna "wins"; with non-determinism, you'd have mixes of the different effects.
5) multiple working copies of genes means faster evolution: changing a working gene can result in a new behaviour without destroying the original behaviour (still produced by the copy).
Numsgil:
1. We have more than one definition of Junk DNA going around. Here's the list
* DNA that doesn't execute
* DNA that doesn't exist inside a gene
* DNA that codes for non existant commandsSo shvarz is mainly talking about the second one in this case, while Carlo is talking about the first one.
2. The only problem with one gene/cycle is bots like The One. It's only a single gene long, and it manages to absolutely pulverize everything else. Yikes.
And also it would decrease the period of time 1 cycle represents. The simulation already runs slowly compared to other ALife sims.
I had an idea for synchornous DNA execution a while back. Here's the post.
Basically there are two camps.
1. Each chromosome acts as DNA does now. That is, the genes in the same chromosome execute as if they were in the current system. Then, the effects of the chromosomes are applied at the end of DNA execution. (In case of conflict, we'd have to devise some system. Perhaps randomly pick an action, or something along those lines).
We can create a seperate memory array for each chromosome to allow communication between genes in the same chromosome via memory just like what can happen now. Or not.
2. Each gene acts as an independant unit, and can't use the stack to pass values to other genes. All memory events are applied after DNA execution.
I'm in favor of #1, because it allows current bots to still work. I'd probably eliminate the stack's ability to carry over to further cycles, as well as prevent changes to memory from occuring until after DNA execution is over.
shvarz:
Regarding Carlo's proposal. We don't have to go as far as executing a single gene per cycle. Executing half of all genes would do the trick almost as well. And then of course the problem is that this may lead to consolidating functions into long complicated genes, that is to completely different outcome than proposed by Carlo.
PurpleYouko:
IMO if we were to change the way that the DNA operates such that all of the genes that read TRUE are not always activated then it will completely and utterly screw up any form of bot programming.
All my carefully constructed MBs would be utterly useless as would all functions relying on activation at a precise age. And there are a lot of these.
For me this would make DB a complete waste of time as I am only in it from the genetic engineering side of things. I want my robots to be utterly predictable. I actively use the fact that an internal memory value flag can be used later in the same cycle. Most of my robots wouldn't be able to operate without this.
IMO it is one of the things that makes DB as good as it is.
I like it the way it is now
Comunications could be improved and very likely will be but please not at the expense of programming predictability or else we might just as well have a bunch of randomly moving circles on the screen.
Numsgil:
When I get around to programming chromosomes, this is what I'd like to do:
PY, tell me if this is a huge pain.
Within each chromosome, genes can communicate using the stack within the same cycle, just like now. Each chromosome has its own stack, and each stack is reset every cycle.
Changes to memory locations are saved in a command stack until after all DNA is executed, so all the chromosomes appear to execute at the same time. (THat is, store, inc, and dec don't affect what appears to be in that memory cell, but the effects are still carried out at the end of the cycle).
So same cycle communication has to use the stack, multicycle communication has to use the memory. Right now both can do either, which seems kind of pointless to me. By specializing each, we can encourage different uses of each.
That's what I'd like to have happen. It would mess up a few bots (mostly yours I bet), but it would allow me to create a diploid DNA system for sexual reproduction, which would be a huge step forward for the evolutionary aspect of the program.
We could have a sexual reproduction system that's more than just shuffling every other gene.
Navigation
[0] Message Index
[#] Next page
Go to full version