Code center > Suggestions

.sexrepro reimplemented in 2.43.1

<< < (3/11) > >>

shvarz:
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".

Numsgil:

--- 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.
--- End quote ---

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.
--- End quote ---

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...
--- End quote ---

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).
--- End quote ---

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.

EricL:

--- 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.
--- End quote ---
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.
--- End 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.  


--- 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.
--- End 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.

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.
--- End quote ---
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).
--- End quote ---
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).

MacadamiaNuts:
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.

Numsgil:

--- 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.
--- End quote ---

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.
--- End quote ---

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.
--- End quote ---

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.
--- End quote ---

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.
--- End quote ---

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.
--- End quote ---

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


--- Quote ---...the .sexrepro value determining sex...
--- End quote ---
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).
--- End quote ---

Yes, I think these are good reasons for pursuing that course.

Navigation

[0] Message Index

[#] Next page

[*] Previous page