Author Topic: Reproduction  (Read 3310 times)

Offline Elite

  • Bot Overlord
  • ****
  • Posts: 532
    • View Profile
Reproduction
« on: January 25, 2006, 12:05:58 PM »
Here are some suggestions concerning reproduction:


Rather than .mrepro being like normal .repro you could have the number stored into .mrepro as the mutation rate.
So:
0 .mrepro store
would produce an unmutated copy
And say:
100 .mrepro store
would produce very mutated progeny
You could have the energy shared between parent and ofspring as a simple 50 default, or you could have an additional sysvar controling that like .shootval for .shoot

Alternatively, you could use .mrepro as the .shootval style sysvar that controls the mutation rate of .repro (proportional to the current set mutation rate, and energy is expended altering it)
So
-64 .mrepro store
50 .repro store
would produce a relatively mutation-free ofspring
And
64 .mrepro store
50 .repro store
would produce a relatively mutated offspring


Another suggestion is a .divide command. Storing a number into .divide would split one bot into several, with the number in .divide specifying the number of bots:
4 .divide store
would split one bot into four, with the energy, body shell, poison and everything else being split between them. All the bots that come out of a divide would be subject to mutation.


Finally, a .shuffle command. If two conspecs were within a certain distance, then one could:
.shuffle inc
And both bots' genes would be exchanged without reproduction taking place. Probably for a future Darwinbots with chromosomes.



Doable?
« Last Edit: January 25, 2006, 12:06:27 PM by Elite »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Reproduction
« Reply #1 on: January 25, 2006, 02:29:02 PM »
Quote
Here are some suggestions concerning reproduction:


Rather than .mrepro being like normal .repro you could have the number stored into .mrepro as the mutation rate.
So:
0 .mrepro store
would produce an unmutated copy
And say:
100 .mrepro store
would produce very mutated progeny
You could have the energy shared between parent and ofspring as a simple 50 default, or you could have an additional sysvar controling that like .shootval for .shoot

Alternatively, you could use .mrepro as the .shootval style sysvar that controls the mutation rate of .repro (proportional to the current set mutation rate, and energy is expended altering it)
So
-64 .mrepro store
50 .repro store
would produce a relatively mutation-free ofspring
And
64 .mrepro store
50 .repro store
would produce a relatively mutated offspring
I think the second would work better than the first, as it would keep more in flavor with the rest of the commands.

What units would the numbers stored in mrepro represent though?  Like doees 100 mrepro mean 100 times the normal mutation rate?  2 times?

Quote
Another suggestion is a .divide command. Storing a number into .divide would split one bot into several, with the number in .divide specifying the number of bots:
4 .divide store
would split one bot into four, with the energy, body shell, poison and everything else being split between them. All the bots that come out of a divide would be subject to mutation.

Biologically I don't think this has an equivelant, at least that I know of.  Most cells divide into two.

That said, Darwinbots isn't necessarily biological.  I'm willing to entertain/explore the idea.

Quote
Finally, a .shuffle command. If two conspecs were within a certain distance, then one could:
.shuffle inc
And both bots' genes would be exchanged without reproduction taking place. Probably for a future Darwinbots with chromosomes.

To me this falls under the realm of Horizontal Gene Transfer.  There are logistical problems I'm not sure how to figure out.  Specifically, the exchange of genes should be largely an agreement by both bots, and it should be possible for malicous, self replicating code to hijack this process, like viruses do.
« Last Edit: January 25, 2006, 02:29:12 PM by Numsgil »

Offline Elite

  • Bot Overlord
  • ****
  • Posts: 532
    • View Profile
Reproduction
« Reply #2 on: January 25, 2006, 04:38:16 PM »
.mrepro as a .shootval style sysvar was my favorite option anyway  :)

So how about this:

Code: [Select]
.mrepro                   mutation rate (multiplier)               nrg cost
   -16                                0.0625                           8
   -8                                 0.125                            6
   -4                                 0.25                             4
   -2                                 0.5                              2

-1 to 1                               1            0 (or 1) + cost of store

    2                                  2                               1
    3                                  3                               1
    4                                  4                               1

Bots wanting high-fidelity offspring will have to spend ever more energy to stop the mutations from creeping in. They use negative numbers in .mrepro

Bots wanting mutated offspring need not pay the extra cost, since extreme mutation is hardly a major advantage (and the ability already exists). They can put any positive multipier into .mrepro

This way, the user still retains control over the rate of evolution via mutation  :) and the bots can also evolve an optimum evolution rate  :)
« Last Edit: January 25, 2006, 04:53:33 PM by Elite »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Reproduction
« Reply #3 on: January 25, 2006, 05:03:02 PM »
I like this idea.

I think realistically a finer gradient should be used.  Mutation rates above about 10x or so are simply not useful.  I would assign a value of 1000 or so for 10x mutation rates, with either a linear or quadratic relationship back down to 0.

Likewise something similar in the negative direction.
« Last Edit: January 25, 2006, 05:03:27 PM by Numsgil »

Offline Elite

  • Bot Overlord
  • ****
  • Posts: 532
    • View Profile
Reproduction
« Reply #4 on: January 25, 2006, 05:10:12 PM »
OK, that would do fine  :D

You already have the code in place to alter the mutation rate (albeit at the start of the sim) and you have a .mrepro command in place. How difficult would something like this be to implement? (It could be a nightmare for all I know having not seen the actual coding)

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Reproduction
« Reply #5 on: January 25, 2006, 05:12:20 PM »
It's actually not all that hard.  Under maybe two dozen lines of code.

However, I myself am somewhat busy with the C++ port.  If you would like to see it in practice sooner than a month or two, maybe PY could implement it in 2.37's source.