Code center > Dead-End and Solved Suggestion Requests

AAA Here it is

<< < (2/4) > >>

Numsgil:

--- Quote ---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"
--- End quote ---
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?

Numsgil:
I'll let PY cover your second post, I haven't really messed with mutations much to be honest.

PurpleYouko:

--- Quote ---Inserting new values will always be random, and rightly so, but I can see reason to make sysvars change into like sysvars.
--- End quote ---

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

Carlo:
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 :(

Botsareus:
Carlo:

--- Quote ---Once in a while, mutate the array by adding a new random memory location.
--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page