Code center > Suggestions
New Mutation Paradigm
Carlo:
Are you saying that you may have something like
functional code (---mutation--->) junk dna (----mutation--->) functional code again?
Well, this is a possibility. I don't know whether it would improve things or make them worse. But it surely would make dna more unreadable then they are now. And, it would make it much harder to use evolved dnas from previous versions (you'd have to split off all the junk first). Having a mutation routine which don't have to take in account the actual language (in fact, just an integer parameter...) would be of little comfort.
But I think you're right to some degree. Changing, say, values to pointers and vice versa could be a good thing. But changing instructions to values it's not, because the information you keep just changing one part of the (type, value) couple it's simply meaningless. Like in the case of different ranges in sysvars, the value part of, say, an add instruction has simply no *particular* meaning as a pointer or an immediate value. The only way to become useful is to mutate again in the original type, which is very, very improbable.
So, I think we should take in account all these things and design mutation routines which act in a very very arbitrary way, trying to make changes which could make some sense. I think this is necessary due to the way the DB language is designed now. My fault.
OR...
Or we could completely redesign the DB code to be easier to mutate. Less memory locations. Little, defined and universal ranges for variables. Single effects (no more -1 shots, -2 shots, 0> shots, etc.). Simpler structure (sparse conds, etc.). Etc.
Endy:
I personally think we should just expand DB as much as possible as long as the users have a say in what actually happens during evolution. I'm not sure that we should be too worried about "lethal" mutations being possible. These still naturally occur with a fair amount of frequency in real beings, so why not in DB's?
On a side note we don't really need to worry about the up/dn commands the cost is limited to the amount used, so a bot isn't going to be charged massive amounts of nrg anymore.
Either way sounds cool, I'm sure you guys will hash something good out.
Endy B)
Numsgil:
Real DNA works by triplets. These are then translated into amino acids. So each of these triplets is basically a command.
So our 2 integer unit is very similar to this triplet of real DNA.
Now, real DNA only has like 64 possible codes. Since some complex behavior is hard coded into the DB language, we have a whole lot more.
But the relationship between our commands and real genes are very similar. That is, a single letter change in DNA can result in a new amino acid and protein with absolutely no similarity to the original in function. So if our add command mutates into a *.nrg, it doesn't seem to make alot of sense to us but who knows how the bots will use them.
The only real problem I see is that there might end up being alot of number@numbers floating around in a genome with just about 0% chance of mutating into anything that does anything. In fact, since there are alot more commands that do nothing than commands that do something, it's feasible that there will be a huge influence for all commands to revert to number@numbers.
So we may want to consider setting a specific limit on what kinds of values all sysvars return and use. Say, nothing above 1000. xpos and ypos could return egrid squares, so their values would be between 0 and 800. Etc. Etc. The hardest problem is nrg and body. I'm not sure what to do there.
Interesting problem.
Carlo:
--- Quote ---So if our add command mutates into a *.nrg, it doesn't seem to make alot of sense to us but who knows how the bots will use them.
--- End quote ---
-------
I think there are two points in what you say. The first, is that a point mutation should involve only one of the two values making a dna position, that is "type" or "value".
But this way, add wouldn't mutate into *.nrg, but _always_ in one of the .up or .dn (I don't remember which code represents the add instruction, but is something really near to 0, 1 or 2). You would have mutations unbalanced in favor of the first 10 sysvars or values ranging from 0 to 10 or so.
You cited triplets. Look: you have 4 types of dna pos, and 32000 possible values. 4 means two bits, 32000 means 16 bits. So each pos is represented by:
oo'oooooooooooooooo
^ ^
type value
which makes eighteen bits. Now, if we like to consider this a triplet, we have to split it this way:
oooooo-oooooo-oooooo
this means that mutating the first part means mutating the type (first two bits of the first part of the triplet) together with the value (six more significant bits of the value part). So, if we split it in equal parts (like a triplet is), we have to mutate types and values together. Same thing if we split it in two equal parts.
Therefore, I think that mutating only type or only value in a dna position makes, in general, no sense.
---------
Your second point is about letting mutations produce junk dna, which means unexistant instructions, sysvars, and so on. This, as I already said, means filling up dnas with tons of junk dna. But junk dna is unlikey to become useful again: as I told you, the instruction coded by the number 500 (possible if you let type change without changing the value) will never become, through subsequent (little) mutations, a valid instruction. It may at most go back to where it came from, that is, to an immediate value or to a pointer, through another mutation. This is very improbable (if a dna position has a chance over 1000 to mutate, it has a chance over 1000000 to mutate two times - not to mention it has to mutate the right way). But if the overall result is to have converted an immediate value to a pointer or vice versa, what was the first mutation for? Let's just say that immediate values can only change to sysvar OR be substituted by a completely different instruction.
I see it this way: we should have
a generator of random meaningful sysvars
a generator of random meaningful values
a generator of random meaningful instructions
and point mutating a pos would mean just calling one of these generators and put the (type, value) they return in the pos we want to mutate.
Endy:
It's going to be hard deciding what is "meaningful". Even large numbers could become useful with enough div/sub or vice versa small numbers could become large with mult/add.
Would it be possible to compromise and have an "off" button for the limits on mutations? This should be a viable solution for everyone. We could also simply test the two types and decide which works better.
Okay, enough with mutations, time to play with the Wiki :)
Endy B)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version