Code center > Suggestions
Non-Determinstic Bot DNA flow
Numsgil:
Dijkstra, that crazy guy. It's scientists like him that give the whole field a bad name! I mean, how can anyone take you seriously when you start talking about philosophers eating spaghetti? Is it any wonder I switched to from Computer Science to Mathematics? At least ring theory makes sense, and sounds cool and scientific :P
The system you propose does have some strengths, but let me balance you pro list with a con list:
1. Effective speeds of the already fairly slow program will be lowered. This is a simple consequence of only being able to execute part of your genome at a time, which makes the slice of time a cycle represents lower. The longer your genome, the less each gene gets per cycle, so the slower the bot will appear to react (unless you load up genes with a bunch of unrealted instructions, that is, make all bots short bots).
2. You've created race conditions. Which is probably bad. The current system is reliant on the timing of the genes, but it is so in a predictable way, so it doesn't count as a race condition.
3. Genes have clear incentive to multiply in the genome. This can lead to explosive copying of genes and elimination of competitors (delgene everything but yourself). This is not inherintly a bad thing, but the emphasis of the program should be on the behavior of bots more than the competition of genes, and a cancerous runaway gene copying itself could slow the simulation and use up quite a bit of memory.
I've voted against several ideas on the basis of gene competition alone. Keep competition between genes limited. (If you can't see why, I can elaborate further, but my reasons are half forgotten, so I'd have to sit down and reremember it).
4. Bots with one gene work just as well in the current system as in an ND system. Inherantly, you're thinking of genes as one or two command segments, roughly of equal length between all bots. But some modern genes can be monsters. In your example, a gene that does what both genes does is better than the two smaller versions put together.
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.
5. And also there shouldn't be an inordinately huge difference in execution speeds between a single gene bot and a multigene bot, since genes are all supposed to be executing simoltaneosly. In your system a single gene bot gets to execute effectively his entire DNA (which can be just as complex as a multigene bot) while another bot only gets to execute part of his, which implies the genes are running at different clock speeds, which is a fallacy.
That is, you're trying to balance the field by saying each bot gets to execute one gene per cycle, when it should be that each gene gets to execute as often as all other genes, (including genes in other bots). A simple fix is to have a counter for genes that prevent them from activating until after X cycles.
I think you're moving in the direction of sims like Avida, which give organisms a time slice to execute in. For your system to work, all bots must have a finite time slot in which to execute which is roughly equal to all other bots. That is, all 50 of bot A's genes should appear to have executed in the same time period that bot B's one gene did. (Again, all genes happening at the same moment).
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. There's no reason to follow the rest of the crowd when we're doing just fine in our current system.
6. Most of the benefits of your system can be achieved in other ways. For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread). 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.
PurpleYouko:
Maybe the definitions have gotten mixed up.
There may well be more than one defininition of non-determinism in computer science but then that isn't my field so when we start talking about determinism , I see it in terms of physics and chemistry. (my fields)
Determinism at a quantum level is absolute with respect to wave forms and probabilities but it is inherantly impossible to precict the position, and velocity of a single particle so any direct effect that this particle has on any other particle becomes non-deterministic in an absolute sense.
On a macroscopic level, the only thing preventing us from being able to determine the way one single atom of air in one part of the world, effects another single atom in another part of the world, is a lack of information about the all of the physical position, velocity, temperature etc. of all the others in between. If we had the ability to know all of this and the computing power to model it then we would be able to determine the exact effects.
With enough information, we could model all macro-molecule interactions (including DNA/RNA) and see that they become completely predictable based on causality.
The different genes should be found to work in parallel with small strings working in sequence. A particular part of a gene will produce a specific protein based on a specific input. Then that protein can be used for some other action within the sequence.
Sounds like Num's proposed idea and I like it.
I don't see any realism whatsoever in the Daemon system. In a real organism, any gene activates whenever it gets the right input. You can't just arbitrarily stop a chemical reaction! When the right chemicals come together in the right proportions and orientations, THEY WILL REACT
It isn't what I would call elegant. It is closer to what I would call a complete misrepresentation of reality.
Sorry and all that but I hate everything about it.
Carlo:
--- Quote ---1. Effective speeds of the already fairly slow program will be lowered.
--- End quote ---
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.
--- Quote ---2. You've created race conditions.
--- End quote ---
Can you be more specific about this point?
--- Quote ---3. Genes have clear incentive to multiply in the genome.
--- End quote ---
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.
--- Quote ---I've voted against several ideas on the basis of gene competition alone. Keep competition between genes limited.
--- End quote ---
Again, genes in general won't compete, as their interest is the robot's interest.
--- Quote ---4. Bots with one gene work just as well in the current system as in an ND system.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---In your system a single gene bot gets to execute effectively his entire DNA (which can be just as complex as a multigene bot)
--- End quote ---
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.
--- Quote ---when it should be that each gene gets to execute as often as all other genes, (including genes in other bots).
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---There's no reason to follow the rest of the crowd when we're doing just fine in our current system.
--- End quote ---
It's not a matter of crowds or niches, but of what is and what isn't interesting, elegant, coherent.
--- Quote ---For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).
--- End quote ---
Horrible. :lol:
--- Quote ---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.
--- End quote ---
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?
shvarz:
I also agree that we are stuck, I see good points from both sides and only time can tell who's right. So I'm OK with the compromise. It actually does sound a bit like Nums' chromosome idea (which I am not too fond of either btw).
But I have a suggestion, instead of making a lis of lists, why not just say that a gene has 50% chance of over-writing any value in a given memory location? That way it can be done on the fly. My personal preference would be to allow 100% chance of writing something in a memory location if the current value there is 0.
Also, we can introduce some kind of commands that would define the "efficiency" of a gene. Say some mutatable number located immediately before condition - express it as a percent of 32000 and let it represent the probability of over-writing any values by the gene that follows.
Carlo:
--- Quote ---But I have a suggestion, instead of making a lis of lists, why not just say that a gene has 50% chance of over-writing any value in a given memory location?
--- End quote ---
This way, genes with the most chances of having effect would be genes at the end of a dna. If I have four instructions:
1 10 store
2 10 store
3 10 store
4 10 store
4 has 50% probability to be written in 10; 3 has only 25% chances to be written, 1 and two have both 12.5 chances of being written.
Anyway, the idea of always overwriting zeros is unfair (for example, in a counter or a flag 0 and 1 have an equivalent importance); so you'd need anyway a list.
--- Quote ---Also, we can introduce some kind of commands that would define the "efficiency" of a gene. Say some mutatable number located immediately before condition
--- End quote ---
It seems to me that just duplicating genes would be enough...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version