Darwinbots Forum
Code center => Suggestions => Dead-End and Solved Suggestion Requests => Topic started by: Botsareus on April 11, 2005, 02:17:26 PM
-
General mutations:
Mutation Rates of mutation rates should change other rates if set to 1 as follows:
This about a*rnd*9
26 ---> 26 + 234*rnd
200 ---> 200 + 1800*rnd
if its over 30000 then its 30001 or 0
etc.
then backwords possible to
30001 - 49092*rnd <----- 0
143 - 234 * rnd <----- 143
1100 - 1800*rnd <------ 1100
Fix less then 1 = 1
etc.
Now if if the mutation rate of mutation rate is high numbers make sure it does not crash the program.
The change of the rate itself should work as it is now, 100 mutation rate of mutation rate should be as powerfull as it is now change the other rates a little.
For the actions part of the gene:
*sysvars accure more often , different all different sysvars , not based on numbers of the program.
*Random numbers get "added" not only "changed" (20 30 store , 40 inc)
*630 <---- memory pointer mutations possible before store inc dec
*630 *200 add <---- this memory locations get "added" and "changed"
-
^^^^ correct formula this time.... thats only use for rate 1
for rate 10 it will be somthing like
a -----> a + rnd*a*1.5 increasing mode.
-
Got to love math.
-
Just program it for me, dont reply.
Reply Shen Reply , its good constructive critisism... Henk help out....
-
'INSERT A NEW VALUE' witch [you]currently[/you] [you]does not work[/you] should do the following things:
1.)Insert New random values ex: (2 3 add 4 store)
2.)Insert New random memory pointers and memory locations ex: (*32 *30 add *34 store)
'CHANGE VALUE' should change memory locations (*132 *130 add ...)
'MUTATION RATE OF MUTATION RATES' crashes the program if the value for it is too high, thats why I set it to 1 to fix the problem.
'MUTATION RATE OF MUTATION RATES' changes 'OTHER RATES' too slow if it is set to '1' the change must be as follows:
the new value of rate = the old value of rate +/- the old value of rate * rnd * 9
If it is less then one it must be set to 1.
'MUTATION RATE OF MUTATION RATES' changes 'OTHER RATES' too slow if it is set to '10' the change must be as follows:
the new value of rate = the old value of rate +/- the old value of rate * rnd * 2
If it is less then one it must be set to 1.
If it is less then one it [you]cannot[/you] be zero , or turned off.
'MUTATION RATE OF MUTATION RATES' changes 'OTHER RATES' too slow if it is set to '100' the change must be as follows:
etc. (apply curve)
'MUTATION RATE OF MUTATION RATES' should change itself with the rates it changes itself now exsept that it cannot make itself 0
-
General mutations:
Mutation Rates of mutation rates should change other rates if set to 1 as follows:
This about a*rnd*9
26 ---> 26 + 234*rnd
200 ---> 200 + 1800*rnd
if its over 30000 then its 30001 or 0
etc.
then backwords possible to
30001 - 49092*rnd <----- 0
143 - 234 * rnd <----- 143
1100 - 1800*rnd <------ 1100
Fix less then 1 = 1
etc.
Now if if the mutation rate of mutation rate is high numbers make sure it does not crash the program.
The change of the rate itself should work as it is now, 100 mutation rate of mutation rate should be as powerfull as it is now change the other rates a little.
For the actions part of the gene:
*sysvars accure more often , different all different sysvars , not based on numbers of the program.
*Random numbers get "added" not only "changed" (20 30 store , 40 inc)
*630 <---- memory pointer mutations possible before store inc dec
*630 *200 add <---- this memory locations get "added" and "changed"
I dont understand explain it to meeeeeeee!!!!!!!!!!111
Na, just kidding!
Mutation rates of mutation rates only changes the other numbers in the form below it. It can't increase or decrease the range of the gaussian distribution that changes numbers.
Note that the largest possible values are -32000 and 32000. Larger numbers are impossible. But if you think about it, you probably never want to store a number in a command greater than about 2000.
I looked at the old mutations code. The reason you never saw negative numbers is that they were purposely given a very small rate. They still appeared, just only rarely. PY fixed this for 2.36.2.
Inserting new values will always be random, and rightly so, but I can see reason to make sysvars change into like sysvars.
Did that cover it?
-
I'll let PY cover your second post, I haven't really messed with mutations much to be honest.
-
Inserting new values will always be random, and rightly so, but I can see reason to make sysvars change into like sysvars.
If a value is mutated that corresponds with a sysvar then it will appear as a sysvar.
This means that if a robot randomly generates the value 1, it will appear as .up in the DNA.
I just ran a 10 second long sim (in 2.36.2) and it did exactly that on the very first reproduction
-
The original mutation system had a special routine to mutate sysvars into other sysvars - if I remember well. All values followed by a store op were considered as sysvars? Probably so. Anyway, there was also an array keeping track of all the sysvars and other (free) memory locations (the usedvars array). The principle was: always mutate a sysvar into another sysvar _already present in the array_. Once in a while, mutate the array by adding a new random memory location. This was to increment the probability of mutating sysvars into other useful memory locations, while leaving open the chance of developing the use of completely new memory location (example, for storing permanent values, etc.). But I think this never happened, anyway :(
-
Carlo:
Once in a while, mutate the array by adding a new random memory location.
It does not happen at all now Carlo, Its like it does not exsist in the code.
How about memory pointers?:
*30 store
*32 inc
This never happens at all also.
Next I was talking about a major problem with the mutation rate at mutation rates
If it is big like 20 or 30 it causes more fatal program crashes.
If it is small like 1 , 2 then it will work but the changes of rates are minor
I want for stuff like 1 , 2 the rates to jump fast from 200 to 1000.
-
How about memory pointers?:
*30 store
*32 inc
This never happens at all also.
Bots, PY just went through and fixed it for 2.36.2. He's said he's fixed it at least 3 times.
If it is big like 20 or 30 it causes more fatal program crashes.
That's a bug with the code. PY might have even already fixed it.
If it is small like 1 , 2 then it will work but the changes of rates are minor
I think you have that backwards. All the numbers represent 1 chance in X. So setting it to 1 means that mutation rates change every time.
I want for stuff like 1 , 2 the rates to jump fast from 200 to 1000.
Why? Mutations work best in gradual form. Very gradual. If a single mutation can make that kind of jump, it's just going to increase the liklihood that mutations won't produce anything interesting.
-
O so Num you are saying that the changes in rates skip generations some times?
Wow , great. :(
It must change every time but the change must very small if the value is high.
and very large if the value is low:
A robot in one generation may deside not to mutate 'copy gene' so it sets it from 200 --> 1500 , should work fine....
only if the value is very very high then it must skip generations and change only by 1.
But the value must always be able to go back up.
If you want to turn mutation rates change of mutation rates off completly then you should set it to 0 and forget about it.
-
PY HAVE NOT FIXED IT YET I HAVE DOWNLOADED DB 2.36.2 FROM THE NEW SERVER ITS STILL BROKEN.
-
O so Num you are saying that the changes in rates skip generations some times?
Wow , great. :(
It must change every time but the change must very small if the value is high.
and very large if the value is low:
A robot in one generation may deside not to mutate 'copy gene' so it sets it from 200 --> 1500 , should work fine....
only if the value is very very high then it must skip generations and change only by 1.
But the value must always be able to go back up.
If you want to turn mutation rates change of mutation rates off completly then you should set it to 0 and forget about it.
No. No no no no no no.
What kind of creature do you know of that mutates every single generation? Are you absolutely crazy?
OF COURSE mutations skip generations some times. In fact, mutations should skip genereations MOST of the time. That's probably your problem Bots. You're trying to run simulations with uber mutation rates. Mutation rates need to be LOW to work. A good rate might be 1 mutation every 6 or 7 generations.
At least, that's how most of the mutation rates tabs work. I don't know how that crazy top value works. I'm just assuming it works like the others. 1 chance in X would see to indicate something like that.
EVERY GENERATION? Holy cow! No WONDER you think mutations are broken.
-
I only say the 'mutation rate of mutation rates' to change the way I explained above.
This has nothing to do with the other rates witch change fine the way they are now.
-
Bots, why are you so fixated on mutation rate of mutation rates? The effect of this option (if there is one at all) should be quite minimal. I really don't see the point of making all this fuss about it.