Author Topic: .sexrepro reimplemented in 2.43.1  (Read 17134 times)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
.sexrepro reimplemented in 2.43.1
« on: January 21, 2008, 04:29:51 PM »
.sexrepro has been (re)implemented for the next buddy drop (2.43.1).

DNA may now be decorated with a new command "cross" which is subject to mutation, etc. like all DNA.  This command does nothing other than to define crossover points for when DNA is combined during sexual reproduction.

Currently, the only way to sexually reproduce is for both parents to be near each other at the same time.  Down the road, other methods may be defined where fertilization by one or both parents can be time shifted (e.g. egg laying, shot-based fertilization, etc.).

Currently, there are number of requirements to sexually reproduce:

1) The two bots must be looking at each other with their focus eyes.  That is, each bot's refvars must represent the other.
2) They must both store a positive value (that is not a multiple of 100) into .sexrepro during that cycle (as with .repro, the value gets MODed down the line to determine the percentage of resources to give to the offspring).

There is no requirement that the two bots be of the same species.  Species recogninition and mate selection are and should be a function of the morph and are totally outside the scope and jurisdiction of the simulator code.

The bot with the higher .sexrepro value (before the MOD) is designated the female, the other the male (if they both have the same value, one is chosen as the female randomly).  There are ramifications of this, the most important being that all the nrg and other resources for the offspring are provided exclusivly by the female according to her value in .sexrepro.  The male pays no nrg or other resources for reproducing sexually.  The idea here is that as in nature, reproducing sexually is expensive for females and cheap for males.  Perhaps one day this may lead to male-male competition and sexual selection.

The bot designated as female also plays an important role in many other ways akin to asexual reproduction including:

1) She must have .body > 2
2) There must be space for the offspring to materialize in front of her.
3) The offspring is born with a birth tie to the mother and inherits her velocity.
4) Genetic memory is inherited from the mother only.
5) Custom defined sysvars (e.g. user-defined memory location labels) are inherited from the mother only.
6) Mutation history is mother's side only.
7) "species" level info such as disabled visioin, disabled mutations, etc. are mother side only.
8) offspring inherit their mother's color.

Veggies may reproduce sexually but veggy reproduction limits are respected (and reproduction may be prevented) when the female is a veggy.  Note that veggy males may reproduce sexually with non veggies independent of veggy population limits.  The mother must be a veggy for the offspring to be a veggy.

Crossover is performed by taking alternating sections of DNA from each parent deliniated by cross commands, first one parents DNA and then the other's.  Switching between parent genomes is performed whenever a "cross" is encounterred at that bp location in either parent's DNA.  Which parent the process begins with is chosen at random.  If one parent's DNA is longer than the others, the offspring may or may not inherit the DNA from the longer genome (that DNA which extends beyond the length of the shorter genome) depending upon whether or not the longer parent is providing DNA at the time the end of the shorter is encounterred.  Crossover does not respect gene boundaries.  Crossover points may occur mid gene and/or in non-coding areas.

2.43.1 should be out in a day or two.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #1 on: January 21, 2008, 05:18:13 PM »
Other than the issues I have with using a crossover command (I think the whole methodology is overly complicated and can be done in a far more robust manner without using any new commands), I think when a sexual reproduction event happens, the two bots involved should each get a strand of DNA in a buffer.  The bot would be "fertilized".  Either bot could then either do nothing (ie: behave like a male), or produce a child with the given buffer DNA.

This way you could do hermaphroditic sex (like earth worms), homosexual sex (ie: neither parent produces offspring), or the more traditional male/female sex, with each bot controlling wether it wants to behave as a female or male.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #2 on: January 21, 2008, 08:34:24 PM »
I fail to see how the crossover command is overly complicated.  In fact it strikes me as the epitomy of simplicity as it eligantly allows the the number and position of crossover points to be subject to and exposed to selection as well as forming the basis of a natural species definition.  That is, the probability that an offspring will be viable (contain a well cooridinated set of operating genes) decreases as the difference between the genomes and the relative positions of the crossover points of the parents increases.  IMHO, this creates an effective but natural barrier to sex between greatly disimilar organisms in that the DNA of their offspring are highly unlikly to code for a well adatped organism.  It also has other side effects such as making virus infected bots less likely to produce viable offspring via sex.

My choice of the terms male and female is perhaps unfortunate and you may be reading more into my use of those terms than is warrented.  My thinking was thus:  for this kind of proximity-based sex (as opposed to egg based or other time-shifted reproduction) I thought it best that the offspring be "birthed" from one or the other of the parents.  The species level information (as we currently use the term) as well as genetic memory, space for the offspring and so on needs to come from only one of the parents, otherwise many things (such as graphs) will break or require significant changes.  I also thought continuing with the birth tie concept was appropriate in this case.  So, I'm using the term female for the parent from which this information comes.  I like my implimentation as I think it encourages some interesting dymanics w.r.t. sexual selection, but I'm open to discussion on what specific mechanism we use for choosing which parent this info should be based upon as well as the nrg/resoruce contribution split between parents.
Many beers....

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #3 on: January 22, 2008, 12:10:02 PM »
Sounds good to me.  I'd suggest that "cross" command would not signify a required switch, but rather be a "possible switch" site.  Say a 50/50 probability. This way multiple reproduction events between two identical (not identical to each other, but the same for all repros) bots would give a whole range of possible off-springs. Some of them might turn out to be viable even if bots are very distantly related.
« Last Edit: January 22, 2008, 12:11:46 PM by shvarz »
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #4 on: January 22, 2008, 12:23:45 PM »
Quote from: shvarz
I'd suggest that "cross" command would not signify a required switch, but rather be a "possible switch" site.  Say a 50/50 probability.
Sounds good to me.  It shall be so.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #5 on: January 22, 2008, 10:15:04 PM »
Quote from: EricL
I fail to see how the crossover command is overly complicated.  In fact it strikes me as the epitomy of simplicity as it eligantly allows the the number and position of crossover points to be subject to and exposed to selection as well as forming the basis of a natural species definition.  That is, the probability that an offspring will be viable (contain a well cooridinated set of operating genes) decreases as the difference between the genomes and the relative positions of the crossover points of the parents increases.  IMHO, this creates an effective but natural barrier to sex between greatly disimilar organisms in that the DNA of their offspring are highly unlikly to code for a well adatped organism.  It also has other side effects such as making virus infected bots less likely to produce viable offspring via sex.

Look at real DNA.  There aren't explicit sections in the DNA that tell the strands to cross over during meiosis.  The strands are lined up by outside proteins as best they can be (the more similar the chromosomes, the more sections can get lined up), and "swaps" are made between strands that are lined up together.  In this way any point that has a homologue in the other chromosome is a potential crossing over site: inside a gene, at a gene boundary, or even in the junk DNA.

Other than implementation complexity, I see no reason that we can't use the exact same algorithm nature uses.

Quote
My choice of the terms male and female is perhaps unfortunate and you may be reading more into my use of those terms than is warrented.  My thinking was thus:  for this kind of proximity-based sex (as opposed to egg based or other time-shifted reproduction) I thought it best that the offspring be "birthed" from one or the other of the parents.  The species level information (as we currently use the term) as well as genetic memory, space for the offspring and so on needs to come from only one of the parents, otherwise many things (such as graphs) will break or require significant changes.  I also thought continuing with the birth tie concept was appropriate in this case.  So, I'm using the term female for the parent from which this information comes.  I like my implimentation as I think it encourages some interesting dymanics w.r.t. sexual selection, but I'm open to discussion on what specific mechanism we use for choosing which parent this info should be based upon as well as the nrg/resoruce contribution split between parents.

No, I totally understood what you meant and agreed with what you're saying.  What I'm suggesting is that we separate the fertilization phase from the gestation phase.  And both bots that participate get "fertilized" (instead of arbitrarily picking one to be the "father" (ie: the parent who does not bear the cost of producing the child) and the other to be the mother (ie: the parent who does bear the child).

Bot bots get a meoisis-ified DNA strand in a buffer.  Either/Neither/Both bots can then initiate the "gestation" phase and create a child with that DNA strand (or default to a simple .repro if there is no strand in the buffer).  This gestation phase can occur 1 cycle, 100 cycles, or 100K cycles after fertilization occurs.  In this way bots control how they want to behave (do I bear a child or just give genetic information to another bot that may or may not use it), and when they want to have the baby (now might not be a good time to produce children, even if it is a good time to mate).

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #6 on: January 23, 2008, 01:07:38 AM »
Quote from: Numsgil
Look at real DNA.  There aren't explicit sections in the DNA that tell the strands to cross over during meiosis.  The strands are lined up by outside proteins as best they can be (the more similar the chromosomes, the more sections can get lined up), and "swaps" are made between strands that are lined up together.  In this way any point that has a homologue in the other chromosome is a potential crossing over site: inside a gene, at a gene boundary, or even in the junk DNA.

Other than implementation complexity, I see no reason that we can't use the exact same algorithm nature uses.
I'm certainly open to this, but it sounds hard to implement and what's more, to implement "correctly".   It works in nature because the crossover machinery evolved along with the organism.  It's "inside" the system and subject to selection and mutation like the rest of the organism.   Selection can fien tune it.   I worry about placing unintended limitations on things by implimenting some hard coded homologue sequence alignment algorithm in the simulator that is not subject to selection.  How long should sequences be before beign considerred homologues?  What about slips?  What is the probability of swapping sequences if homologous and how should the degree of homology impact this?

I came up with the crossover operator as simple way to push as much control over the process into the DNA as possible.   Selection can operate on the frequecy and position of crossover points by operating on the cross base pair.  If you have a suggestion for how to do the same with your alignment scheme, I'm all ears, but I think it's important that as much of the alignment and corssover machinery as possible be "inside" the system and subject to selection.  

Quote from: Numsgil
No, I totally understood what you meant and agreed with what you're saying.  What I'm suggesting is that we separate the fertilization phase from the gestation phase.  And both bots that participate get "fertilized" (instead of arbitrarily picking one to be the "father" (ie: the parent who does not bear the cost of producing the child) and the other to be the mother (ie: the parent who does bear the child).
I'm not really fond of using the .sexrepro value to make this determination but I can't really think of anything better at the moment.  It does allow for sexual selection and courtship.  Female bots (I.e. those who primarily use a reproductive strategy of putting more resources into fewer offspring and nuturing them directly I.e. passing on genetic memory through the birth tie and such) can choose to mate with perspective males or not.  They can evaluate the .sexrepro values of perspective mates and decide if the offer is large enough.  Male bots risk something by offerring too much in .sexrepro as a perspective mate might offer a lesser value and make them the female.  There is a prisoners delimma here I think that could lead to some interesting sexual selection dynamics and courtship rituals bewteen perspective mates where they prove their worth through other means before finially placing a value into .sexrepro....

I kind of lean towards using shots for fertilization and time-shifted sex as we already have a mechanism there for storing DNA in the shot.  It's the only place currently where we have a "buffer" to put DNA outside a bot.   Perhaps an egg layign female bot could reproduce asexually in a special "egg" mode where little happens until a sperm shot hits it...

I'm all for adding a gestation period for both sexual and asexual reproduction per the other topic on this.
 
Quote from: Numsgil
Bot bots get a meoisis-ified DNA strand in a buffer.  Either/Neither/Both bots can then initiate the "gestation" phase and create a child with that DNA strand (or default to a simple .repro if there is no strand in the buffer).  This gestation phase can occur 1 cycle, 100 cycles, or 100K cycles after fertilization occurs.  In this way bots control how they want to behave (do I bear a child or just give genetic information to another bot that may or may not use it), and when they want to have the baby (now might not be a good time to produce children, even if it is a good time to mate).
I don't think a bot should be able to hang on to a mate's DNA in a buffer indefinantly.  Sperm only lives so long.  I think sexual reproduction should necessitate coordination in both time and space between parents, be that mammal sex as I've coded (where both need to be in the same place and the same time) or reptile/fish sex per egg offspring and sperm shots (where the male has to fertilize the egg and this act kicks off gestitation).
Many beers....

Offline fulizer

  • Bot Destroyer
  • ***
  • Posts: 198
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #7 on: January 23, 2008, 08:43:03 AM »
the idea of finding a superior fighter then reproducing with it by forcing it via viruses would be amazing and could cause a acccdentel evolution to go ahead millions of cycles is amasing.
also making spermbot shots would be cool they would swim off looking for something to fertilise.
also (again)using the type genes to make different genders would rule
« Last Edit: January 23, 2008, 08:44:34 AM by fulizer »
"If this is coffee bring me tea, If this is tea, bring me coffee"

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #8 on: January 23, 2008, 12:18:21 PM »
Quote
I don't think a bot should be able to hang on to a mate's DNA in a buffer indefinantly. Sperm only lives so long.

Maybe not indefinitely, but why not for a very long time? In some organisms females do grab a bunch of sperm and store it and then use it later on. For example cockroaches - females can produce several generations with sperm they once obtained from a male.
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #9 on: January 23, 2008, 12:45:56 PM »
Well, okay.  Gamet lifespan per se isn't really that big issue for me.  What's more important is the set of possible recepticals for DNA.  I'd like to avoid building some special uninspectable buffer in which gamet DNA resides until needed.  I'd rather use the two recepticals we have already: shots and bots.  If a bot wants to carry around gamet DNA from another for possible future use, it should perhaps tie to an egg/gamet cell specailly produced by a mate and carry it around.  Alternativly, we could devise some means for gamet shots to stick to or reside within bots for some period of time until utilized.
Many beers....

Offline shvarz

  • Bot God
  • *****
  • Posts: 1341
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #10 on: January 23, 2008, 05:16:23 PM »
I don't really care, I just pointed out that this does not have to be the case. I think generalizing existing features is a good idea. The whole "virus" thing does seem to be artificial. I'd much rather prefer something like a "generalized shot with a set of different properties", only some of which make it a "virus".
"Never underestimate the power of stupid things in big numbers" - Serious Sam

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #11 on: January 23, 2008, 11:08:08 PM »
Quote from: EricL
I came up with the crossover operator as simple way to push as much control over the process into the DNA as possible.   Selection can operate on the frequecy and position of crossover points by operating on the cross base pair.  If you have a suggestion for how to do the same with your alignment scheme, I'm all ears, but I think it's important that as much of the alignment and corssover machinery as possible be "inside" the system and subject to selection.

This is obviously a point where we differ in philosophy.  For me, the specifics of crossing over aren't "interesting" in a Darwinian sense.  They've changed very little over billions of years, demonstrating that nature's way is sufficient and probably optimal for the way DNA works.  And doing this matching wrong (called Unbalanced recombination), almost always results in the offspring's death.  Nothing good comes from failure in this regard.

It's like shuffling a deck of cards.  It's the overall result after several iterations that really matters.  In an individual shuffle it's immaterial wether a card from pile A goes before or after a card from pile B, or even wether 20 cards from pile A all get deposited together or shuffled with some from B.  Plus, lots of crossover commands clutter up the DNA, and force old bots to be retrofitted with them before they can have sex.

As for matching up DNA strands, I'm sure there's a way to produce a pretty good match using a hill climbing algorithm.  It doesn't matter, say, if the matching is less than globally optimal.  The fewer areas that are matched, the fewer places get cross over events, and the less likely the resultant DNA will represent a cohesive DNA program.

Here's my first pass at an implementation for matching:

1.  Determine the longest sequence of base pairs that can be matched from strand A to strand B (if there's more than one match, pick one that causes the lengths to match up as much as possible for either strand).

2.  "zip" the two strands together along this match.

3.  Repeat 1 and 2 in such a way that a match must occur so that the DNA strands don't loop back on themselves.   (That is, a match on strand A that is downstream of a previous match must also be downstream of that same match on strand .  Repeat until either all the base pairs are matched in one of the strands, or the remaining strands can't be matched.

Step 1 can be implemented naively at O(n^2) at the least, though maybe there's a library function or existing algorithm that could be used that would cut that down.  It all seems a little complex but very do able to me.

Quote
I'm not really fond of using the .sexrepro value to make this determination but I can't really think of anything better at the moment.

I think it's very simple: both parents get to be moms if they want.  After mating, both bots have the option of producing a kid.  The potential kid's DNA is stored in a buffer.  The simplest method here would be to take the two recombinant DNA strands from the previous discussion and give one to each parent.  The parent can either ignore making a kid (and thus be "male"), or make the kid (and thus be "female").  I think this is the prisoner's dilemma proper.  In your original version, it isn't quite a prisoner's dilemma because the bots don't have the choice of cooperating (both producing kids).

Quote
I kind of lean towards using shots for fertilization and time-shifted sex as we already have a mechanism there for storing DNA in the shot.  It's the only place currently where we have a "buffer" to put DNA outside a bot.   Perhaps an egg laying female bot could reproduce asexually in a special "egg" mode where little happens until a sperm shot hits it...

The transmission of DNA is immaterial to me.  It could be shots, ties, or magic leprechauns.  At some point you have two DNA strands of either parent, and your goal is to mix them.  That's the part that matters to me.

That said, we need to decide what sort of sexual model we're after.  Sex for mammals is very familiar to us.  Two animals get in to proximity, do the horizontal mamba, and then one of them makes a baby after a while.  Sex for fish involves less proximity but the idea is essentially the same.  Sex for worms is a little different: both worms get potentially fertilized.  They both can produce eggs.  Sex for single celled critters is even more fun: the species goes through alternating generations of diploid and haploid.  In the diploid phase, it's like two separate animals join to become one.  The two strands of DNA sort of share control of the organism.  Like in Dragonball Z where the main characters would fuse to become a new, stronger character with character traits of both fuse-ees.

That last form of sex is probably way beyond what present Darwinbots is capable of (though I'm working towards it for DB3), but the first, second, and third each seem equally valid to me.  To you as well I hope.
 
Quote
I don't think a bot should be able to hang on to a mate's DNA in a buffer indefinantly.  Sperm only lives so long.  I think sexual reproduction should necessitate coordination in both time and space between parents, be that mammal sex as I've coded (where both need to be in the same place and the same time) or reptile/fish sex per egg offspring and sperm shots (where the male has to fertilize the egg and this act kicks off gestitation).

Not indefinately, no, but certainly over the life time of the bot.  Ant queens usually mate once when they're in their "new queen" phase (have wings), and the entire colony grows from that initial seed.  In a perfect world a bot would keep an entire store of possible genomes for its children, and choose one at random when it produces a kid.  But I'll settle for storing a single copy until it's needed 100, 1000, or 10000 cycles after the pairing.
« Last Edit: January 23, 2008, 11:11:59 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #12 on: January 24, 2008, 12:10:25 PM »
Quote from: Numsgil
This is obviously a point where we differ in philosophy.  For me, the specifics of crossing over aren't "interesting" in a Darwinian sense.  They've changed very little over billions of years, demonstrating that nature's way is sufficient and probably optimal for the way DNA works.
Yes we differ greatly here.  IMHO, the crossover algorithm has huge bearing on the set of possible offspring organisms reachable from a given set of parents.  If that algorithm is staticly coded into the simulator, then the set of genomes producable by crossing over two specific genomes will be a rather small fixed set that will never change.  What's more, selection is powerless to change this mapping algorthim over time - to operate on the machanics and fine tune what is important and what is not.  The mapping algorithm from parent genomes to the set of possible offspring resides outside the realm of selection.   What I want is a way for selection to operate on the algorithm.

Why is this important?  Well, biological recombination has many nuaunces.  Genetic linkage for example, where genes that reside near each other on a chromosome are less likely to be separated.    What I'm after is a mechanism whereby selection can naturally evolve such nuances.

As an aside, we have this problem where too much is hard coded in the simulator and thus unreachable by selection in many areas.  Take mutation probabilities for example.  We allow for the probability of different types of mutations to mutate, but the type-value way our base pairs are represented impart a bias on mutation probability.  The probability of a point mutaiton resulting in certain base pairs and not others for example is a function of how we represent DNA numbers and operators and sysvars as different types.  My point is that this bias, whatever it is, is hard coded and not subject to selection.  We have codon bias, but it did not evolve - it's a side effect of the way the simulator works.  

Quote from: Numsgil
It's like shuffling a deck of cards.  It's the overall result after several iterations that really matters.  In an individual shuffle it's immaterial wether a card from pile A goes before or after a card from pile B, or even wether 20 cards from pile A all get deposited together or shuffled with some from B.
Yes, but your approach fixes what a card is and in particualr, what defines the boundary between one card and the next in a way that selection can't get at it.  I want selection to be able to change the shape and size of cards as well as the shuffling alghorithm.  

Quote from: Numsgil
Plus, lots of crossover commands clutter up the DNA, and force old bots to be retrofitted with them before they can have sex.
This is a total red herring.  Evolved DNA is already clutterred and if you are reverse engineering evolved DNA produced via sex, then being able to explicitly identify crossover points is advantageous.   If your not evolving bots but still using sexual reproduction, then being able to determine explicitly where the crossover points are in hand coded bots is also obviously desirable.

Old bots don't reproduce sexually, so no retrofit necessary unless you're evolving them in which case the probability that they will evolve a crossover base pair by the time they evolve the use of .sexrepro is high and even if they don't, sex will still produce offspring, just ones that are identical to either parent.

Quote from: Numsgil
1.  Determine the longest sequence of base pairs that can be matched from strand A to strand B (if there's more than one match, pick one that causes the lengths to match up as much as possible for either strand).

2.  "zip" the two strands together along this match.

3.  Repeat 1 and 2 in such a way that a match must occur so that the DNA strands don't loop back on themselves.   (That is, a match on strand A that is downstream of a previous match must also be downstream of that same match on strand .  Repeat until either all the base pairs are matched in one of the strands, or the remaining strands can't be matched.

Step 1 can be implemented naively at O(n^2) at the least, though maybe there's a library function or existing algorithm that could be used that would cut that down.  It all seems a little complex but very do able to me.
I suggest we do this in DB3.  Even if this could be implimented effeciently, it would still be unreachable by selection.  

Quote from: Numsgil
I think it's very simple: both parents get to be moms if they want.  After mating, both bots have the option of producing a kid.  The potential kid's DNA is stored in a buffer.  The simplest method here would be to take the two recombinant DNA strands from the previous discussion and give one to each parent.  The parent can either ignore making a kid (and thus be "male"), or make the kid (and thus be "female").  I think this is the prisoner's dilemma proper.  In your original version, it isn't quite a prisoner's dilemma because the bots don't have the choice of cooperating (both producing kids).
I want to tease out two separate issues here:   1) male/femaleness and 2) time-shifted sexual reproduction.

Let's focus on 1) for the moment.  As above, I'm fine with adding new capabilities for bots to store DNA long term from another in a shot or egg cell or similar and thus enable other modes of sexual reproduciton, but let's talk about male/female independently from that if we can.

On 1), ignoring the possible future addition of gestation times, for real-time proximity based sex (where reproduction happens on the same cycle as fertilization) what if we simply added a new fertilization shot type.   If you want to be male but not female, you shoot fertilization shots (at some low cost to you) and you do not set .sexrepro.  If you want to be female and not male, you set .sexrepro at some value which determines the percetnage of your resources to give the offspring.  Fertilization happens when a fertilization shot hits a bot with a value in .sexrepro.   If you want to be both male and female, you do both things.  You can't fertilize yourself (well, you can, but that's called .repro) but you mate with another doing the same.  

By using fertilization shots instead of my "look at each other" method with the .sexrepro value determining sex, the choice to be male or female is explicit.    It also opens the door for "sneaker males" and other forms fo male-male competition and feamle choice.   Plus, we are setting the stage for time-shifted sex down the road (the fertilization shot might some day be stored long term by the female).
Many beers....

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #13 on: January 24, 2008, 02:18:38 PM »
Meh, I'd suggest equipping some T_Preservans with sexrepro and the cross command as it is now and run them to see how meaningful are the results.

If it works and it produces cool results, I don't mind about it's conceptual value or whatnot.
Sometimes you win, and sometimes you lose...

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
.sexrepro reimplemented in 2.43.1
« Reply #14 on: January 24, 2008, 05:14:30 PM »
Quote from: EricL
Why is this important?  Well, biological recombination has many nuaunces.  Genetic linkage for example, where genes that reside near each other on a chromosome are less likely to be separated.    What I'm after is a mechanism whereby selection can naturally evolve such nuances.

Genetic linkage is supported by both methods.  In biology (and the method I suggest), neighboring genes tend to get transferred together simply because they're next to each other.  If you take strands of DNA, do 10 cross over events, and determine the probability of two base pairs from the same parent strand ending up in the same child strand, I'm sure you'd see the probability increase with proximity.  The link you use actually explains this as the reason.

Quote
As an aside, we have this problem where too much is hard coded in the simulator and thus unreachable by selection in many areas.  Take mutation probabilities for example.  We allow for the probability of different types of mutations to mutate, but the type-value way our base pairs are represented impart a bias on mutation probability.  The probability of a point mutaiton resulting in certain base pairs and not others for example is a function of how we represent DNA numbers and operators and sysvars as different types.  My point is that this bias, whatever it is, is hard coded and not subject to selection.  We have codon bias, but it did not evolve - it's a side effect of the way the simulator works.

I view hard coded solutions as banks for a river.  If everything was in some way mutable, the solution space would be a vast ocean.  Far too open ended to arrive at results that are interesting to any but the staunchest alife advocates.  By narrowing the solution space we focus the selective pressure towards areas that are of interest.  Behaviors instead of abilities become the focus for selection.  Of course, follow this philosophy too far and you end up with something like Ventrella's Darwin pond, where the entire solution space is rather bland and known, but the evolution is quick and easily recognized.  So I think it's a balance, and Darwinbots does a good job of finding that sweet spot between either extreme.

Quote
Yes, but your approach fixes what a card is and in particualr, what defines the boundary between one card and the next in a way that selection can't get at it.  I want selection to be able to change the shape and size of cards as well as the shuffling alghorithm.

But keep in mind the purpose of shuffling: to make cards random (I'm stretching the metaphor at this point, I admit, but bear with me).  In a poker game, player's don't care what shuffling algorithm you use.  The point is to make the cards you're dealt unknown and unknowable.

Quote
This is a total red herring.  Evolved DNA is already clutterred and if you are reverse engineering evolved DNA produced via sex, then being able to explicitly identify crossover points is advantageous.   If your not evolving bots but still using sexual reproduction, then being able to determine explicitly where the crossover points are in hand coded bots is also obviously desirable.

I don't mean to present straw man falacies, but I tend to determine the utility of the DNA as a factor of readability and brevity.  That is, the more you can accomplish, with the least amount of code, and still have a human look at the code and understand what it does.

Adding elements in to the DNA strand that do not perform any actions on stack or memory are wasteful in my estimation.

Quote
I suggest we do this in DB3.  Even if this could be implimented effeciently, it would still be unreachable by selection.

I respect our unspoken agreement to leave either project to the other's trust.  Even if I think your agreement in this area is more from a belief that DB3 is vaporwear.  I'll respect whatever decision you make in the end, for this simple reason that you're the one coding it, but I do not see any advantages to what you propose over what I propose, except ego stroking.  No offense intended.

Quote
On 1), ignoring the possible future addition of gestation times, for real-time proximity based sex (where reproduction happens on the same cycle as fertilization) what if we simply added a new fertilization shot type.   If you want to be male but not female, you shoot fertilization shots (at some low cost to you) and you do not set .sexrepro.  If you want to be female and not male, you set .sexrepro at some value which determines the percetnage of your resources to give the offspring.  Fertilization happens when a fertilization shot hits a bot with a value in .sexrepro.   If you want to be both male and female, you do both things.  You can't fertilize yourself (well, you can, but that's called .repro) but you mate with another doing the same.

That would be a fine, and would certainly allow weird worm sex.

Quote
...the .sexrepro value determining sex...
Am I misunderstanding you here?  Isn't any value in .sexrepro implying that you're being female?  A sperm shot (or whatever you want to call it) probably would use seperate machinery than .sexrepro, right?  Maybe a -8 shot, or .jerk or something crass like that?

Quote
, the choice to be male or female is explicit.    It also opens the door for "sneaker males" and other forms fo male-male competition and feamle choice.   Plus, we are setting the stage for time-shifted sex down the road (the fertilization shot might some day be stored long term by the female).

Yes, I think these are good reasons for pursuing that course.
« Last Edit: January 24, 2008, 05:15:35 PM by Numsgil »