Darwinbots Forum
Code center => Suggestions => Topic started by: EricL 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.
-
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.
-
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.
-
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.
-
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.
-
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.
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).
-
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.
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.
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).
-
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
-
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.
-
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.
-
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".
-
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.
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).
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.
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.
-
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 (http://en.wikipedia.org/wiki/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.
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.
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.
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.
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).
-
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.
-
Why is this important? Well, biological recombination has many nuaunces. Genetic linkage (http://en.wikipedia.org/wiki/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.
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.
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.
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.
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.
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.
...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?
, 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.
-
Hmm, fun discussion.. I personally find both approaches interesting and can't make my mind as to which one would be better.
From a practical point of view, I just want to see something done to get sexrepro working. My worry is that it's just not going to work. The requirements that Eric plans to impose seem to require a fairly complex behavior and I think that there is no chance for sexrepro to evolve on its own.
-
My worry is that it's just not going to work. The requirements that Eric plans to impose seem to require a fairly complex behavior and I think that there is no chance for sexrepro to evolve on its own.
I like the the shot-based fertilization method over the "look at each other" method. So, if there are no objections, I'll change over to that for 2.43.1.
So, how likely is sexual reproduction to evolve on it's own? Well, two things need to happen. Bots need to evolve the placement of a value into .sexrepro and the same or a different line needs to shoot -8 shots.
I don't plan to reset .sexrepro unless sexual reproduction actually occurs (so that males can detect females in heat) so bots need only evolve the DNA to set this sysvar once in a while or have it set via altzheimers or info shots or similar.
Negative shot values are mod 8, so there is a 1 in 16 chance that an evolved shooter will be shooting fertilization shots.
So, it's doesn't stike me that it will be too difficult for sexual reproduction to evolve naturally. Harder than asexual reproduction as it involves two bots and two sysvars, but not radically improbable I think.
Whether selection will favor it is a different question all together...
-
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.
None taken.
I have enough expereice to know how hard it is to build something that complex from scratch that has to be largly complete and reasonbly bug free out of the gate and get it to critical mass, particularily when your chasing a moving target (my fault). I've long argued for the incremental approach of portting the VB version then adding the new physics, but we need not get into that again here. So, I wouldn't go so far as to call DB3 vaporware, but it's gonna take more than some cool new physics to make it real. No offense intended.
Okay, I give. If you can articulate the psuedo code for an effecient crossover algorithm that operates on 2.43 DNA, I'll use it and put the cross operator on hold for the time being.
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?
Correct. Any value in .sexrepro implies your female and that your willing to devote your own expensive resources to reproduction. I plan to use -8 shots for fertilization shots.
-
I'll do you one better and see if I can work out an actual program demonstrating an algorithm. Probably done in C# operating on strings, for simplicity.
I don't take offense at a vaporware-esque attitude towards DB3. I'm keenly aware of the difficulties. However, I think if I can get the physics working like I want (no mean feat, to be sure), the rest should be downhill. Physics is what stopped the C++ version from being "complete".
-
Here is the current crossover routine for reference:
Public Function Crossover(male As Integer, female As Integer, offspring As Integer)
Dim parent As Integer
Dim I As Integer
Dim t As Integer
Dim x As Integer
' The length of the offspring's DNA will be the length of the longer of the parent's DNA
If rob(male).DnaLen > rob(female).DnaLen Then
ReDim rob(offspring).DNA(UBound(rob(male).DNA))
Else
ReDim rob(offspring).DNA(UBound(rob(female).DNA))
End If
'flip a coin as to which parent goes first
If Random(0, 1) > 0.5 Then
parent = female
Else
parent = male
End If
For t = 1 To UBound(rob(offspring).DNA)
' test for hitting the end of one of the parent's DNA
' if we have, then if we are currently on that parent, stop.
' if we arn't, then copy the rest of the DNA from the other parent
If (rob(male).DNA(t).tipo = 10) And (rob(male).DNA(t).value = 1) Or _
(rob(female).DNA(t).tipo = 10) And (rob(female).DNA(t).value = 1) Then
If (rob(parent).DNA(t).tipo = 10) And (rob(parent).DNA(t).value = 1) Then
' DNA copying hit the end of the parent. The offspring's DNA length is the shorter of the two parents.
rob(offspring).DNA(t) = rob(parent).DNA(t)
ReDim Preserve rob(offspring).DNA(t)
Else
' DNA copying is currently on the longer parent. No end hit in copying, take the rest of the longer parent
For x = t To UBound(rob(offspring).DNA)
rob(offspring).DNA(x) = rob(parent).DNA(x)
Next x
End If
Exit Function ' we're done.
End If
' copy the base pair from the current parent
rob(offspring).DNA(t) = rob(parent).DNA(t)
' If we hit a crossover point in either parent then switch parents
If (rob(male).DNA(t).tipo = 9) And (rob(male).DNA(t).value = 5) Or _
(rob(female).DNA(t).tipo = 9) And (rob(female).DNA(t).value = 5) Then
'Flip a coin. 50% chance of switching parents at crossover points
If Random(0, 1) > 0.5 Then
If parent = female Then
parent = male
Else
parent = female
End If
End If
End If
Next t
End Function
-
Attached is an implementation of natural crossing over in C# using strings. There are two variables which can be modified to change the sort of crossing over done: the minimum matching length (defaulted to 3 in this implementation) and the number of crossing over events (user setable at run time in this implementation).
Both of these variables could easily be set by bots to control the sort of crossing over and how it works, and thus would be subject to natural selection. If a bot increases the minimum matching length, for instance, it means that the mate must be genetically less distant for meaningful crossing over to occur. The more crossing over events that occur, the more evenly mixed the two genomes are (and the greater the risk of breaking parts of the DNA). For bots, you'd probably want to express number of crossover events as a probability per matched bp instead of a hard number, so that it scales nicely with genome size.
There's an exe buried deep in this implementation. Run it with these test cases to get a feel for the results:
A: General Washington opened the western US to colonization
B: Washington state is in the western US
A: Hi John, eat boogers and die
B: John loves to eat boogers
A: AAAAAA123456AAAAAA
B: 123BBBBBB456BB
A: ABCdefGHIJ
B: abcdefghij
Implementing this in the VB code with the DNA like it is is going to be a pain, I'll admit. Glad I'm not the one to do it
-
How will this deal with highly repetitive sequences? Some of my bots by now can be represented as:
VV1VVVV2VVVVVVVV3VV4V5v6VVVVVVV7VVVVV
where numbers are real genes and V stands for a virus.
-
It matches the longest sequence possible, then recursively does the same on segments to either end of the match. So in layman's terms it handles highly repetitive sequences very well.
-
Okay, I now have this implemented using shot-based fertilization and Num's crossover algorithm. I want to bake it for 24 hours so 2.43.1 should come out tomorrow barring unforseen issues.
Bots can now shoot -8 sperm shots. There is no cost for this beyond the normal shot cost. The shooter's DNA is copied to the shot (like with viruses). .shootval operates the same way as for other shots.
If a sperm shot impacts a bot, it fertilizes it (shell, etc. has no effect on sperm shots). That is, the sperm DNA is copied to an internal buffer on the impacted bot. Note that the father need no longer be alive at impact time to father offspring. Once sperm is fired, the father is out of the loop.
Currently, bots remain fertilized for 10 cycles. We can change this easily down the road, but it's 10 for now. A new sysvar .fertilized (303) counts down the cycles remaining until the bot is no longer fertilized. If the bot gets shot with another sperm shot while fertilized, that DNA replaces the previous DNA and the .fertilization counter gets set to 10 again.
If a bot sets .sexrepro to a postive value not a multiple of 100 while fertilized, it will sexually reproduce (subject to the normal reproduction constraints w.r.t. body, space and vegginess) giving the offspring the specified percentage of it's resources.
For this version, the crossover variables mentioned in Num's algorithm are internal as follows. The minimum sequence length to match is fixed at 3 base pairs. The maximum number of crossover points is determined by taking the length of the shorter parent's DNA and dividing by 10.
Seems to be working pretty well now. Stay tuned...
-
A couple of additional points:
.sexrepro only gets reset if reproduction is successful.
Reproducing sexually does not zero the fertiliziation counter. Bots may sexually reproduce multiple times (up to 10 times, once per cycle) using the same sperm DNA.
-
I just find it midly disturbing that I could insert my own DNA by info-shotting sexrepro and then firing a -8 shot.
-
I just find it midly disturbing that I could insert my own DNA by info-shotting sexrepro and then firing a -8 shot.
Yup. But at least buy her a drink first....
Rape is mostly a human concept. It's certainly a viable reproductive strategy for many males of many species. Biologists would call it a "sneaker male strategy" or sperm competition or some such. Something like 5% of all salmon for example are fertilized by a "sneaker male" who hides and then darts and in and sprays the eggs before the male the female selected can act. There are insects with barbs on their penises (I kid you not) which evolution has shaped as a cone to scoop out and remove the sperm from the male before them.... Much of sexual selection and sexual apparatus adaptations are rooted in such strategies...
-
Perhaps the explosive shots could be introduced for egg use?
-
Perhaps the explosive shots could be introduced for egg use?
Perhaps I'll add an option for the DNA produced via crossover to replace the "mother's" DNA instead of producing a new bot, perhaps via storing a negative number to .sexrepro. In this way, time shifted reproduction can be accomplish by a "female" bot laying an egg through asexual reproduction. After storing a negative value to .sexrepro, the female's DNA would be coded to do bascially nothing - expending no nrg - until fertilized at which point the egg hatches with the combined DNA from both parents.
Explosive shots are a nice idea, but I don't really see them playing a role in sexual reproduction, unless of course they are filled with Tequilla....
-
Maybe the female simply becomes an egg once properly fertilized by a male. Not quite realistic, but otherwise you could knock other bots out by shooting negative values at them.
Could use explosive shots for firing multiple "sperm" or other types of shots at once. Could be handy for firing at a groups of bots or if you don't have a specific bot you want to shoot.
-
Perhaps the explosive shots could be introduced for egg use?
Perhaps I'll add an option for the DNA produced via crossover to replace the "mother's" DNA instead of producing a new bot, perhaps via storing a negative number to .sexrepro. In this way, time shifted reproduction can be accomplish by a "female" bot laying an egg through asexual reproduction. After storing a negative value to .sexrepro, the female's DNA would be coded to do bascially nothing - expending no nrg - until fertilized at which point the egg hatches with the combined DNA from both parents.
Explosive shots are a nice idea, but I don't really see them playing a role in sexual reproduction, unless of course they are filled with Tequilla....
Or are on fire.
-8 is the sperm, so a sack should be identifiable to a robot's eye. Also, the eggs should be attachable to the mother/farther, so that a random bot doesn't go and try to eat the offspring.
-
Maybe the female simply becomes an egg once properly fertilized by a male.
This is an option given what I am suggesting. That is, there are four ways to reproduce:
1) Asexually as always
2) "Giving birth" sexually via storing a positive value in .sexrepro before or after being fertilized
3) "Laying eggs" by storing a positive value in .repro and then coding the DNA such the egg stores a negative value to .sexrepro and then does nothing else except wait to be fertilized. Every gene is predicated with some trigger that does not get set until .fertilized goes positive. Namely, the only gene or sub-gene firing in the egg is
clearbool
trigger 0 !=
-50 .sexrepro store
*.fertilized 0 !=
1 .trigger store
4) "Becoming the offspring" as you suggest by simply storing a negative value in .sexrepro before or after fertilization
1 and 2 work in 2.43.1. 3 and 4 are post 2.43.1.
Could use explosive shots for firing multiple "sperm" or other types of shots at once. Could be handy for firing at a groups of bots or if you don't have a specific bot you want to shoot.
Right. This is how I see explosive shots working. I.e. We add some generic way for the bot to specify a shot should "explode" at some range. Any shot can potentially be made to explode includng sperm shots. The power or longevity or whatever of the single shot gets divided up amoung the fragments. You loose power but gain hit probability. I'd probably just reuse some of the poff shot code.
-8 is the sperm, so a sack should be identifiable to a robot's eye. Also, the eggs should be attachable to the mother/farther, so that a random bot doesn't go and try to eat the offspring.
By using bots for the egg(s), both of what you indicate are in fact the case. Eggs can be seen and they can be attached and carried around by a parent, before or after fertilization.
-
Could we just make the negative .sexrepro value make a temporarily DNA-disabled offspring (until it's fertilized)? Seems like simpler system, at least to me. Also, I think .shootval should be implemented for -8 shots. Negative=greater range, positive=greater % chance for your DNA to be used.
-
I don't plan to reset .sexrepro unless sexual reproduction actually occurs (so that males can detect females in heat) so bots need only evolve the DNA to set this sysvar once in a while or have it set via altzheimers or info shots or similar.
I love the idea of old asexual bots getting fertilized becouse they're getting a little lightheaded and accidentally store negative value in .sexrepro.
Also, I think .shootval should be implemented for -8 shots. Negative=greater range, positive=greater % chance for your DNA to be used.
I have no objections for increasing the range, but I don't think the tradeoff should be probability of injecting your own dna. I could agree with that, if the probability of injecting your own dna wouldn't rise above 0,5 or the bots would have some countermeasures against it. Maybe increasing range could be made crazy expensive energy-wise, maybe the value of .shootval in the power of 3-4.
EDIT: Or maybe the time stored in the buffer could be larger for -8 shots with shorter range. That way bots could be fertilized much later if needed or from further range more immediately.
I'm not sure if I would like more if .sexrepro was tuned to way it's probably going to remain and work and wait or just to get right to it and experiment with a unfinished version
-
2.43.1 has been released. Negative values of .sexrepro do nothing in 2.43.1.
I do not like the idea of "temporarily DNA disabled offspring". Eggs may want or need to execute DNA. They may want to decide whether to accept fertilization (I.e. set .sexrepro) by a specific male or at a specific time or only when mom is around or just become an asexual offspring after a certain time passes without fertilization or tie to a veggy like an egg sack and grow prior to fertilization (perhaps producing additional eggs) or whatever. Personally, I prefer to see the need for time shifted reproduction evolve naturally out of existing mechanims if possible, ideally because there is a reproductive advantage to doing so e.g. the sea turtle strategy were mom is large and hard to kill, but offspring are weak and small. Mom stockpiles large numbers of low resource offspring over time (mom goes out and hunts between laying) which then all hatch at the same time where maybe 1 in 100 make it to adulthood. That kind of thing.
To this end, I would support a general change such as allowing for asexual reproduction giving less than 1% of parental resources for example.
Adding more range or speed to a shot should IMHO be consistant and work the same for any shot and the cost of this should be simply one of the nrg needed to shoot. The .shootval code is really ugly. Cleaning it up is on my list. When I do so, I'd like to create a straight forward, consistant way for bots to impact the range (I.e. longevity) speed and explosivness of any shot type.
I'm happy to entertain ideas for allowing both the male and the female to impact how long fertilization lasts but I agree that the decision to shoot far and the decision to shoot sperm that surives longer once fertilization occurs should be able to be made independently.
-
2.43.1 has been released. Negative values of .sexrepro do nothing in 2.43.1.
I do not like the idea of "temporarily DNA disabled offspring". Eggs may want or need to execute DNA. They may want to decide whether to accept fertilization (I.e. set .sexrepro) by a specific male or at a specific time or only when mom is around or just become an asexual offspring after a certain time passes without fertilization or tie to a veggy like an egg sack and grow prior to fertilization (perhaps producing additional eggs) or whatever. Personally, I prefer to see the need for time shifted reproduction evolve naturally out of existing mechanims if possible, ideally because there is a reproductive advantage to doing so e.g. the sea turtle strategy were mom is large and hard to kill, but offspring are weak and small. Mom stockpiles large numbers of low resource offspring over time (mom goes out and hunts between laying) which then all hatch at the same time where maybe 1 in 100 make it to adulthood. That kind of thing.
To this end, I would support a general change such as allowing for asexual reproduction giving less than 1% of parental resources for example.
Adding more range or speed to a shot should IMHO be consistant and work the same for any shot and the cost of this should be simply one of the nrg needed to shoot. The .shootval code is really ugly. Cleaning it up is on my list. When I do so, I'd like to create a straight forward, consistant way for bots to impact the range (I.e. longevity) speed and explosivness of any shot type.
I'm happy to entertain ideas for allowing both the male and the female to impact how long fertilization lasts but I agree that the decision to shoot far and the decision to shoot sperm that surives longer once fertilization occurs should be able to be made independently.
There would have to be an effective relationship between eggsize, how many cells/multi-cells within the egg (we should support multi-cellular embriotic development, it would require DNA activation in the egg to work properly) and the amount of energy given to the egg. Eggs in real life need a lot of energy to go for a full birth cycle (anywhere between 15 days to nine months), so the more things required to do before hatching would mean more energy reserves. So would this egg creation be limited to one bot, or could a multi-bot produce a copy of itself, taking with it certain specified memories, such as their enegy or pain, or a loaction of an enemy not killed? I think for Multi-Bot developmental purposes, we should allow for DNA transfer between conspec multi ties that take with it x amount of energy (I.e. .eggnrgm) to some other bot and so on, until all the genes have been collected and placed inside an egg by a single bot. I say it should be for conspec use only, because I could see it as a backdoor in to gaining an unfair advantage, by taking a very powerful strand of DNA and combining it with your own and making some super-mutant bot. Although the idea is not that far from real life, some bacteria are capable of copying missing pieces of DNA from a similair bacteria.
-
Adding more range or speed to a shot should IMHO be consistant and work the same for any shot and the cost of this should be simply one of the nrg needed to shoot. The .shootval code is really ugly. Cleaning it up is on my list. When I do so, I'd like to create a straight forward, consistant way for bots to impact the range (I.e. longevity) speed and explosivness of any shot type.
A bit off topic, but what about a moded percentage based system for shots(range, speed, explosiveness)? Any value could be used by the bot, but it would be reduced to just the last two digits. This way the evolution wouldn't be as likely to get stuck at the ceiling value of 99.
-
To give finer graining, consider this:
0-99 gives x% of nrg, body, etc.
100 - 1099 gives (x - 100) / 10 % of nrg, body, etc.
Or perhaps:
0-99 gives x% of nrg, body, etc.
-1000 to 0 gives -x / 10 % of nrg, body, etc.
-
0-99 gives x% of nrg, body, etc.
-1000 to 0 gives -x / 10 % of nrg, body, etc.
This is essentailly what I was thinking, but across a wider range of negative values. I.e.
-16000 to 0 gives -x / 160 % of nrg, body to an exteranl offspring, etc.
-16001 to -32000 indicates DNA replacement upon fertilization
This allows for the possibility of really low resource offspring/eggs, down to 0.0000625% of resources. A bot with 32000 nrg would produce an offspring/egg with only 2 nrg at the lowest percentage. Not unreasonable in my opinion. I think we should allow for the possibility such tiny offspring/eggs at least.
For .sexrepro. I'd use -16001 to -32000 to indicate sexual reproduction should replace the bot's DNA instead of creating a new offspring. The specific value would not matter. It's the space relative to mutation probability that matters. For .repro, this range would do nothing, as today.
I prefer using negative values as opposed to positive values above 100 as it spreads the offspring percent resource probability more evenly across the space of possible values, giving mutations a better distribution for hitting percentages across the entire range spectrum including a 1/4 chance of being an egg.
-
2/3rds of the stuff I did "not compute" but:
-
I would be careful with DNA replacement. Rape is one thing, but outright forcing another bot to mingle its DNA with your own is something even more brutish. I would ask that a bot destined to be an egg be produced specifically for that cause. Use -16001 to -32000 in sexrepro to mean to produce an egg: it would have all the DNA of the parent, like a normal .repro, but would be available for DNA replacement. Otherwise it could function like a normal bot. DNA replacement would occur either automatically after fertilization or by calling sexrepro (any value), depending on you thoughts.
-
Use -16001 to -32000 in sexrepro to mean to produce an egg: it would have all the DNA of the parent, like a normal .repro, but would be available for DNA replacement. Otherwise it could function like a normal bot. DNA replacement would occur either automatically after fertilization or by calling sexrepro (any value), depending on you thoughts.
Sounds good to me. It will be a few weeks before I get to this (vacation coming up).
-
I'm sure this is because there is more going on but 2.43.1 goes about half as fast as version 2.43z. Is the sex stuff responsible for this alone?
-
I'm sure this is because there is more going on but 2.43.1 goes about half as fast as version 2.43z. Is the sex stuff responsible for this alone?
Shouldn't be directly, but I did make a change to the shot array compact routine to handle -8 shots. That may be it.
I'll do some profiling shortly. It's time. The next drop will have some perf work.
-
Is there a way to push information into memory locations of an egg? Through a tie or info shot?
-
Is there a way to push information into memory locations of an egg? Through a tie or info shot?
Sure. It's just a bot. The only difference between an egg and a bot is that it was 'layed' by it's parent storing a value between -16001 and -32000 inclusive into .sexrepro instead of via normal asexual reproduction using .repro.
-
So which crossover algorithm is going to be used (or is used)? "Num's" or "EricL's" ?
Thank you for your time...
-
The algorithm I demonstrated with the attachment above is the one the current program uses to match DNA strands.
-
Very Cool , So sexrepro works now? (I wish I had access to the program to check it out)
-
Yes, it works. Don't know if anyone's used it in any evo sims yet, but I've certainly seen some league bots that use it.
-
I've been running an evosim with sexually reproducing bots for 1,3M cycles now.
As usual, mutations have broken everything that isn't absolutely necessary for survival and now I'm hoping to see some improvement in the next few million cycles. I set up the bots to fertilize bots of their own species when they had over 2 body. Basicly evolved DNA's behaviour is very much the same as the original, it just uses less bp to do it so mutations have lower probability to break something down.
I've just added shapes that bots can see in one corner of the sim (size 12) and maybe, just maybe they'll evolve more conditions for shooting. That'd be a killer.
The problem is, there isn't any evolution for veggies as bots depend heavily (well, fully) on repopping veggies and kill them quickly. Bots are just adapting to stable conditions. One idea I've been toying with is to add multiple types of veggies to provide a little bit of variety. I think veggie repop randomly chooses which one to drop in. With large enough fields, larger than size 12, it should be possible to create at least semi-stable ecosystem. Thats really hard to hand-code as the species have to be efficient enough to survive and inefficient enough to let some of the other to live too.
I've attached the evosim if someone wants a look at it. It's nothing special really, just the .sexrepro.