1. Effective speeds of the already fairly slow program will be lowered.
This is true. But, as I already told you, I'd prefer a good program that works slowly than a bad program that works faster.
2. You've created race conditions.
Can you be more specific about this point?
3. Genes have clear incentive to multiply in the genome.
No. A gene can reproduce itself only making the bot work successfully and reproduce. There's no reason for a gene to duplicate against the advantage of the bot it is in. A gene must be cooperative towards the entire genome (this is the concept of gene pool). Even in the case of a gene able to actively duplicate itself inside the dna of a robot (in case there will be commands for doing so) duplicating too much will subtract energy and _time_ and lead to a rapid death of the whole organism. So, NOW genes have a clear incentive to multiply themselves in the genome, since time is not a resource. Think of viruses: they rapidly spread in the whole population, and can infect a bot with as many copies of themselves as they want.
I've voted against several ideas on the basis of gene competition alone. Keep competition between genes limited.
Again, genes in general won't compete, as their interest is the robot's interest.
4. Bots with one gene work just as well in the current system as in an ND system.
Yes, this is a problem. I haven't tried it, but I know there's a very strong robot having only one gene. For it there would be no difference between deterministic and nondeterministic execution. There would be two possibilities here: either accept this fact (bots like the One will never evolve in an evo sim, so there's simply no problem) or put a limit to the number of operations that can be performed inside a gene. The limit may be a simple cap or maybe an increasing cost for each subsequent operation.
So in the end you're encouraging bots to either have 50 copies of the same gene or a single gene that does it all. Again, this is not inherintly bad, but I would prefer to see large segments of passive and different DNA develop over large segments of active duplicate DNA. Both are likely to develop something, but if the DNA is encouraged to spread out it makes it more readable and reverse-engineerable.
I'm not sure to understand what you mean. Remember that active copies of the same gene are also subject to mutation. This means that duplicated genes are a good material for evolution. Also, remember that an inactive gene, lacking of any selective pressure, becomes in a few generations a complete junk, and going back from junk to a functional gene is extremely improbable.
In your system a single gene bot gets to execute effectively his entire DNA (which can be just as complex as a multigene bot)
This, again, depends on decisions we may take to discourage too complex genes. But, also, it is a problem which can affect only people programming combat bots, since I don't think that evolution will produce super complex genes.
when it should be that each gene gets to execute as often as all other genes, (including genes in other bots).
Hmmmm... from a certain point of view you're right. This is how things work in the real world. But on the other hand, we should design the program to produce interesting and meaningful results. And making behaviours compete for execution time could be interesting. In Avida, one of the most "serious" alife software, organisms compete for cpu time. The real world works differently, but this choice is interesting, and profound. By contrast, the meaningless energy parameter in DB is really a stupid idea.
This is really the strength of DB. The program isn't making artificial distinctions within the DNA, but the bots end result is what's tested. This is what attracted me to the program. It's so different from all otehr ALife sims that it's found a niche.
DB isn't different from other alife sims. It's just what a true alife sim should be. Now, changing the way dnas are executed to a more coherent and elegant system, which, among other things, introduces time as a resource (think carefully about this: the only significant resource in a world in which matter and energy don't exist, it's time) don't seems to me to change the fundamental properties of fairness and open endedness of the simulation.
There's no reason to follow the rest of the crowd when we're doing just fine in our current system.
It's not a matter of crowds or niches, but of what is and what isn't interesting, elegant, coherent.
For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).
Horrible. :lol:
Backwards compatibility is important to maintain when possible. There isn't anything your system can do that we can't adapt the current language to do just as well with a little imagination and time.
Backwards compatibility is a stupid thing if referred to a program that nobody uses for work but just to tinker a bit with evolution and robot programming - don't you think so? I find this idea simply intolerable. You know what's better, how the program can become more interesting and be a better alife sim... but you do nothing, because of the back compatibility of a few bots... bah.
Anyway, seems to me we're blocked. You'd never accept the nd solution. I've thought of a compromise. It should work this way.
All active genes are executed. The values are read from the memory array, but the store command writes to a list of lists. For example: the operations:
1 10 store
2 20 store
2 20 store
5 50 store
6 50 store
7 50 store
will produce the list
10 ->1
20 ->2,2
50 ->5,6,7
At the end of the complete cycle, the memory array is written with values taken from the list. If a location has more than one value associated, the value to write in the memory array is chosen randomly among the values in the list.
This way, we'll have some of the good effects of nondeterminacy (duplicated genes still active, memory and external effects visible at the same time, genes balancing) but executing all active genes at each cycle. The time effect, which I think would have been interesting, won't be present. To prevent communication between genes in the same cycle I'd also reset stack pointer after each gene.
Comments?