Darwinbots Forum
Code center => Suggestions => Topic started by: Elite on July 31, 2006, 02:24:41 PM
-
Hiya everyone, just returned from holiday
Let's get together and decide what we want to do about sexual reproduction in DB
Here's my idea to start things off:
Firstly, meiosis: reproduction that splits the bot into two bots, splitting the DNA of the bot at a certain point and giving each portion to one of the bots. This would be achieved via the sysvar .meio, with the number stored indicating where in the DNA the split occurs
Secondly, give bots the ability to shuffle their genes, moving genes around their genome. This way they can 'line up' their genes into two halves for meiosis.
Bots should also have the ability to copy their own genes. The importance of this will become clear later.
Finally, recombination: two bots can, via a tie, merge into one bot and merge their DNA together, with the bot that initialized the recombination's DNA simply being added to the end of the other bot's DNA
.reco will fire a tie forward, which, if it hits anything, will initiate recombination
*********
Here's how sexual reproduction would work:
First, line up your genes into two halves (if necessary)
Next, split your DNA using meiosis
Then, have each 'half-bot' to find a 'half-bot' of the 'opposite sex'
Then, have the halves recombine into one bot
It works better still for MBs, which can afford to have specialist sex cells
*********
Here's the best part - implications of this system:
1) Different species cannot breed easily
If one bot accidentally recombines with a bot of a different species you're left with a bizare hybrid, which will probably be missing large chunks of vital DNA, and be run by two conflicting DNA 'half-bot' programs
2) Viruses emergy as a natural consequence
A virus would be a single gene (or several) that copied itself, sent the copy to the end of the genome, and split it off with meiosis, only to have the new SG bot recombine with the first bot it saw.
3) Incresed evolutionary benifits of sex, including true speciation
*********
What does everybody think of that?
-
I have issues giving bots too much information about the structure of its DNA, especially numerically, and doublely especially on the "gene" level. Insertions and deletions are going to make doing something to the Xth base pair terribly obsolete. You need a system that's just a set of universal rules that allow the desired behavior to come about.
Ideally you'd have some system that's fairly emergent, without alot of control from the bots. The trick I think is to decide what we want and go backwards from there, comparing with biology as a base line.
Actual meisos goes something like this: (it's been a while, so point out errors I make) Chromosomes are lined up with each other. Like chromosomes find each other through their centromeres, which act as a kind of key in groove, only connecting to the sister chromatid.
The sister chromosomes begin zipping up along several sites to each other. If there isn't a proper match at a zipping up site, the zipping stops. Crossing over events occur along these zipped up sites only.
After crossing over, the chromosomes are seperated and each goes in one of the new cells.
From this I would imagine something like this for Darwinbots: (assuming a Haploid standard, which seems to be the norm for ALife). Two DNAs find each other (the specifics change depending on if you're macroscopic or microscopic). The DNA is lined up, and several random locations start trying to find corresponding matches. That is, location 1 on DNA A has "stop cond *.eye5 0 > start". This tries to find a match in DNA B. If a match is found, the DNA's are "zipped" up, checking the previous and next base pairs for a match. This continues until it either runs out of DNA to zip or the DNAs don't match anymore, in which case it stops.
The bots would then specify a number of crossing over events (maybe just average the requested crossing over events of the two parents), which would perform crossing over (http://en.wikipedia.org/wiki/Crossing_over) the same way biological DNA does along any zipped up regions.
The two DNAs are then seperated and either put back into the parents (for microscopic) or one is put into a new bot (macroscopic).
This avoids explicitly defining sex, and other abstract concepts (funguses for instance have a very interesting life cycle with some very complex "genders". Some have hundreds of genders.)
There are a few fudges in this system compared with natural systems. The largest being that bots are specifically limited to haploidity (polyploidity seems an impossible problem, specifically in deciding how to handle dominant/recessive/codominant in a fair way). Polyploidity would be easy to add, though, if we ever figured out an adequate system.
If bots could program their zipping up mechanisms, maybe through some sort of codule, you could add quite a bit of control to the bots without giving them explicit information about their DNA.
I do agree that ties would be the logical choice for coupling with a mate. To mate I imagine it would need to be a double agreement, like launching nuclear missiles. Both bots have to agree. Perhaps a single sysvar called .sexrepro (original I know). 0 or negative values imply no consent to mate. Positive values indicate a number of crossing over events. I dunno, I might have to think about it.
Ideally there would be a checkbox in the options between macroscopic and microscopic behavior (new child or DNA swap). If the sysvars behave the same for both, that would be even better. Bots designed for one could still operate as another.
-
How about the DNA matches up by finding regions in which the DNA matches, and then splits the DNA into sections where the DNA doesn't match, then chooses an 'allele' at random from the unmatching parts
This is hard to explain
Example:
Bot1
h r j d n v r g k h t r e s b j y o g d s w e h g k h p g r e s g p p o r d w t x n t o p l
Bot2
h r j d n o I y t r v j b g h f d w e h p o d v d x b j r d w t x y y r e
Match points colour coded
DNA in-between match points shuffled
Example offspring:
Bot3
h r j d n v r g k h t r e s b j y o g d s w e h p o d v d x b j r d w t x n t o p l
This might be something similar to what you're getting at, although not specifying crossover points
-
Title change: From "Sexual Reproduction (Again)" to "Sexual Reproduction Focus Group"
Are we in agreement that the system should involve meiosis and then fertilisation/recombination, rather than a simpler system whereby bots exchange genes without intermediate meiosis?
Resources:
Sexual Reproduction (http://en.wikipedia.org/wiki/Sexual_reproduction)
Genetic Recombination (http://en.wikipedia.org/wiki/Genetic_recombination)
-
Here's how I understand "real" crossing over to work (there are some limitations to my medium, so bear with me):
The two DNA strands couple:
a b c d e f g h I j k l m n o p
A B C D E F G H I J K L M N O P
A site is chosen:
a b c d e f g h I j k l m n o p
A B C D E F G H I J K L M N O P
The DNA strands downstream (or upstream, I'm using downstream without loss of generality) "swap":
a b c d e f g h I j K L M N O P
A B C D E F G H I J k l m n o p
The result doesn't sound too exciting, but if you do that several times the result is a relatively cohesive way to shuffle the DNA that minimizes damage to genetic code.
Elite, your way isn't much different as far as impact to the DNA, I'm just saying this is more or less how actual crossing over goes about its business. Although your method might have a different effect on Genetic Linkage (http://en.wikipedia.org/wiki/Genetic_linkage).
-
So the bots find each other and swap?
*********
The general idea behind my first idea:
1) The Bot DNA is cut into two strands and the bot splits into two, with each bot getting a strand
2) Bots of opposite 'sexes' (ie. different halves of DNA) find each other and 'mate'
3) The DNA is recombined
That way, only similar bots can reproduce successfully, since they will have the right gene halves
Bot1
a b c d e f g h I j k l m n o p
Bot1a
a b c d e f g h
Bot1b
I j k l m n o p
Bot2b
I J K L M N O P
Bot1a+Bot2b
a b c d e f g h I J K L M N O P
Something like that?
No harm in collecting a couple of methods together
-
I'm just a little wary of creating anything that can be construed as "sexes". Real animals don't have to have sexes. That they do should be seen as a choice on evolution's part instead of a requirement.
Any bot of the same species as another bot should theoretically be able to mate. If they can't, it should be a consequence of the decisions the bot has made (size restrictions perhaps) or behavioral limits (self policed genders in effect).
----------------------------------------------------
Cutting a bot's DNA isn't analogous to the split in real DNA, because all bots are at present haploid, hence the need to fudge around a bit.
-
I'm just a little wary of creating anything that can be construed as "sexes". Real animals don't have to have sexes. That they do should be seen as a choice on evolution's part instead of a requirement.
I see your point. OK, let's go for the no meiosis method then. DB doesn't need to be an exact mirror of real life ...
Hence the need to fudge around a bit.
*********
OK, let's take your crossover method
How about matching up the sections where the DNA matches ...
h r j d n v r g k h t r e s b j y o g d s w e h g k h p g r e s g p p o r d w t x n t o p l
h r j d n o I y t r v j b g h f d w e h p o d v d x b j r d w t x y y r l
... and using this as a guide to place in a random number of crossover points within the portions where the DNA matches, for each strand. This prevents code from getting accidentally mushed in with an entirely seperate piece of code
If not enough DNA matches are found to accomadate the crossover points (ie. non conspecs) then how about having the program just place the points randomly anyway, mushing the DNA and probably leading to a non-viable offspring?
That sound OK?
BTW, How's the C++ version coming on?
The introduction of codules will make this tons easier. Just swap the coresponding codules arround
-
... and using this as a guide to place in a random number of crossover points within the portions where the DNA matches, for each strand. This prevents code from getting accidentally mushed in with an entirely seperate piece of code
That's more or less what I was thinking, so I agree
If not enough DNA matches are found to accomadate the crossover points (ie. non conspecs) then how about having the program just place the points randomly anyway, mushing the DNA and probably leading to a non-viable offspring?
That sound OK?
That would probably work.
BTW, How's the C++ version coming on?
The introduction of codules will make this tons easier. Just swap the coresponding codules arround
After I fixed my computer by getting a new motherboard, I started working for my father doing his IT stuff. Then I started a job at Walgreens. I hardly have time to eat and sleep, let alone the time and mental faculty needed to code, so it's not progressing very rapidly. Things should calm down in a week or two and I can get started.
All that's really left to do is ties. 10 or 15 hours of work tops. I just don't have the time or energy to do it. Kinda frustrating.
-
How about matching up the sections where the DNA matches ...
h r j d n v r g k h t r e s b j y o g d s w e h g k h p g r e s g p p o r d w t x n t o p l
h r j d n o I y t r v j b g h f d w e h p o d v d x b j r d w t x y y r l
... and using this as a guide to place in a random number of crossover points within the portions where the DNA matches, for each strand. This prevents code from getting accidentally mushed in with an entirely seperate piece of code
There is a problem with this in that for populations and genomes as small as what we are using, conspecs are likely to differ by perhaps only one or two base pairs, when they differ at all. Most of the genome of the individuals within a species will be identical and crossing over these portions will have no effect. For this reason and for those mentioned about the problems with defining/assuming specific universal genome structures, I prefer cross over without regard to genome structure in all cases (I.e. essentially random in both the number of cross over points and the locations - more on this below).
As previously mentioned, this has the effect of self-defining species in that the crossing over of similar genomes will have a higher probability of resulting in a viable organism then will the cross over of radically disimilar genomes. That is, it is unlikly that two organismsms of wide genetic distance will be able to produce viable offspring. Selection will determine how far is too far and we will have a species boundary. Sterile hybrids between recently branched but distinct species are an intermediate possibility, but selection will strongly favor mating with bots that have similar genomes and wouldn't it be cool if species recognition adaptations evolve one day as a result. A cross over point in the middle of a gene between two individuals of the same species won't matter much since it is likely that the other half of the gene is the same or sufficiently similar that the resulting gene will still function in the offspring. In cases where there are off by one type errors due to insertion mutations or other genetic differences between the parents, the resulting offspring may have a modest crossover mutation, which may or may not be deleterious. This could lead to the evolution of non-coding interons, the purpose of which would be to increase the possibility of retaining the original gene function in the offspring in cases where the crossover does not exactly line up due to differences in parential genomes. Random crossover also has the fucntion of creating a poor man's version of haplioid alleles.
But this all begs the question as to whether sexual reproduction should be entirely part of the engine, entirely coded for within the genome of sexually reproducing species or perhaps something inbetween. IMHO, in an ideal world, everything would be evolved and in the genome. The whole notion of sex and all the mechanisms there of would evolve naturally with the engine providing only the most basic world physics and chemistry necessary to enable it - say the ability of one organism to make it's DNA available to another, via a tie or perhaps as a new shot of type "gamate" which can contain all or part of an organism's DNA. But the entire notion of sex, sexes, crossover, alleles, diploidity, etc would evolve out of that basic ability naturally if and only if selection favored it. Crossing over would be under organism control, selection could operate on the number and location of crossover points, whether they were random, whether some genetic structure was assumed in crossover, sex ratios, etc.
Unfortunatly, given the limits of the system in terms of environmental diversity/complexity and of the CPU power available today, I expect we would be waiting a long time for all this to evolve since it is unclear to me at least what selection forces are necessary to favor sex in the first place. (I'm not the only one BTW. From what I can tell, what advantage there may be in sexual reproduction is a hot area of research. At first blush, it would seem that selection should favor asexual reproduction exclusivly since in sexual reproduction, only half of an organism's genes are passed on to an offspring. All else being equal, genes which favored asexual reproduction over sexual reproduction would become more numerous so there must be some important advantage conveyed by sexual reproduction. Some of the therories I have read about are nonobvious and involve such things as parasite resistance but I think the jury is still out for sure.)
So, I assume for expediecy sake, we want sexual reproduction including crossover to be handled pretty much entirely by the engine in that all an organism need evolve is invocation of .sexrepro or equivalent and the responsibility of doing the crossover and creating the offspring with the resulting DNA will be handled by the engine instead of by the organism. While it is tempting to say that the genome should be responsible for deciding what parts of it's DNA to combine with another's, this might add considerably to the difficulty of letting a successful cross over strategy evolve naturally. I'm all for allowing the organism to provide some sort of optional hints to the engine which serve to guide or control cerain aspects of crossover and letting selection operate on these, perhaps average crossover length for example, but I for one cannot come up with good ways for how selection would effectively operate on this.
This split between what the engine does and what the organims must evolve is consistant by the way with where we draw the line on other engine/genome responsibility splits. For example, the engine today handles all the various tasks of creating a new organism with the DNA of the parent during asexual reproduction including DNA copying and so on. An asexual organism need not evolve it's own DNA copying machinery in order to reproduce. I think it would be inconstistant of us to say that sexual reproduction must evolve in it's entirty but that asexual reproduction need not.
So, what remains is to decide on what specific mechanisms are available for bots to decide how and when to have sex. I suggest two methods:
Mammal sex I.e. tie method. Both parents have to be in the same place at the same time. They form a tie. They both have to be willing to have sex on the same cycle. If both call .tiesexrepro or equivalent on the same tie on the same cycle, the engine performs crossover and an offspring is formed endowed with the sum of the nrgs passed by its parents. A birth tie is formed to (and genetic memory loaded from) the one which passed the larger nrg value.
This approach could allow male/femaleness to evolve as bots of the same species can evolve different strategies for how much nrg to invest in fertilization and how often to attempt to have sex (initially, the only difference between males and females would be in the value of a single base pair governing how much nrg to invest in sexually produced offspring). Females for example, might evolve the strategy of investing a lot of nrg in each offspring but being choosy in the bots they mate with (since they invest so much in each offspring) say only mating with bots with nrg levels above a certain level as a test of fitness. Males on the other hand may take the differnet approach of investing very little nrg in each offspring, but attempting to mate often and with anything that will allow it. Selection can favor both strategies.
The delayed fertilization method. Both parents do not have to be in the same place at the same time. One parent lays an egg (which would be represented simply be a normal asexually produced offspring but with a couple of flags set that the engine would use and perhaps an "I'm an egg" refvar that others could use for recognition. That is, unlike say using a shot for the egg, the egg would be visiable, could be eaten by preditors, is subject to costs, can die if not fertilized, repsects corpse mode, etc) using .sexrepro or equivalent endowing it with it's DNA and some amount of energy. The offspring's DNA DOES NOT EXECUTE (only environmental costs apply - so it can die if not fertilized within some time frame) until it is fertilized by another bot at which time the engine crosses over the DNA of the parents and forms the new offspring with the new DNA and the offspring begins to execute. Fertilization happens via a tie as above. In fact, dumb bots need not know the difference between an egg and a mate - the egg can be thought of as calling .sexrepro every cycle (come fertilize me!) - the only difference is that when sex occurs, the egg becomes the offspring, no third bot is created. Or perhaps we really do kill the egg and create the offspring anew, complete with birth tie....
Note that fertilization could also occur via a new "gamate" shot type if we wanted. I would suggest this as a V2 feature since 1) it's not necessary initally 2) it's hard to hit really small bots with shots and eggs are likely to be small and 3) I don't know how birth ties and genetic memory should work in such cases.
Sorry to be long winded, but this subject is super interesting. Nums, I think this topic of sexual v. asexual reproduction in Alife simulators would be a good one for an acedemic paper...
-
So, I assume for expediecy sake, we want sexual reproduction including crossover to be handled pretty much entirely by the engine in that all an organism need evolve is invocation of .sexrepro or equivalent and the responsibility of doing the crossover and creating the offspring with the resulting DNA will be handled by the engine instead of by the organism. While it is tempting to say that the genome should be responsible for deciding what parts of it's DNA to combine with another's, this might add considerably to the difficulty of letting a successful cross over strategy evolve naturally. I'm all for allowing the organism to provide some sort of optional hints to the engine which serve to guide or control cerain aspects of crossover and letting selection operate on these, perhaps average crossover length for example, but I for one cannot come up with good ways for how selection would effectively operate on this.
As a relatively easy way to control the amount of "mixing", you can allow the bots to specify the number of crossover events. A sufficiently large number of crossover events and you have a pretty even 50/50 chance for inheriting either one or the other of an allele. Lower numbers offer greater cohesion between parents' DNA fragments.
Mammal sex I.e. tie method. Both parents have to be in the same place at the same time. They form a tie. They both have to be willing to have sex on the same cycle. If both call .tiesexrepro or equivalent on the same tie on the same cycle, the engine performs crossover and an offspring is formed endowed with the sum of the nrgs passed by its parents. A birth tie is formed to (and genetic memory loaded from) the one which passed the larger nrg value.
This approach could allow male/femaleness to evolve as bots of the same species can evolve different strategies for how much nrg to invest in fertilization and how often to attempt to have sex (initially, the only difference between males and females would be in the value of a single base pair governing how much nrg to invest in sexually produced offspring). Females for example, might evolve the strategy of investing a lot of nrg in each offspring but being choosy in the bots they mate with (since they invest so much in each offspring) say only mating with bots with nrg levels above a certain level as a test of fitness. Males on the other hand may take the differnet approach of investing very little nrg in each offspring, but attempting to mate often and with anything that will allow it. Selection can favor both strategies.
The delayed fertilization method. Both parents do not have to be in the same place at the same time. One parent lays an egg (which would be represented simply be a normal asexually produced offspring but with a couple of flags set that the engine would use and perhaps an "I'm an egg" refvar that others could use for recognition. That is, unlike say using a shot for the egg, the egg would be visiable, could be eaten by preditors, is subject to costs, can die if not fertilized, repsects corpse mode, etc) using .sexrepro or equivalent endowing it with it's DNA and some amount of energy. The offspring's DNA DOES NOT EXECUTE (only environmental costs apply - so it can die if not fertilized within some time frame) until it is fertilized by another bot at which time the engine crosses over the DNA of the parents and forms the new offspring with the new DNA and the offspring begins to execute. Fertilization happens via a tie as above. In fact, dumb bots need not know the difference between an egg and a mate - the egg can be thought of as calling .sexrepro every cycle (come fertilize me!) - the only difference is that when sex occurs, the egg becomes the offspring, no third bot is created. Or perhaps we really do kill the egg and create the offspring anew, complete with birth tie....
This is basically what I mean when I say "macro" and "micro" sexual reproduction. Macroscopic sex involves two parents creating one child (at a time, multiple children per litter generally involves multiple eggs). Microscopic sex involves "fusing" of two cells (sperm and egg, or equivelant for things like fungus spores).
The only thing I would have issue with is that if we allow both systems in the same simulation, they need to be equally weighted. If one is easier to use, we'll see that one being favored, skewing any conclusions the evosim would allow us to draw. Which brings up the issue of what to do if one parent wants to fuse and the other wants to mate. We could have the cell that wants to fuse entirely donate its bodily resources to the child, basically just replacing its DNA, and forming the birth tie with the bot that wanted to mate.
Another option is to use the same sysvars for both, and change the way sex behaves on the options screen. Wether it creates a new child or fuses. This has the benefit of directly allowing parallel sims to run that are in every way identical except in how sex works.
Nums, I think this topic of sexual v. asexual reproduction in Alife simulators would be a good one for an acedemic paper...
I definately think so. I think the real interest is if we can evolve a sexual critter or not. If we can't, we know that we're missing something in our simulation that spurs real organisms into sex. If we can, we know we've captured it. Either way, we'd narrow down a pretty good idea of the possible causes for the evolution of sex.
-
so how would we initiate the mixing?
In the rather primitive .sexrepro command that has been knocking about in BD since carlo coded it way back, a bot simply takes the DNA of the nearest (physically) bot and splices it with its own.
That doesn't seem right.
I think we could use some kind of modified shot as a sperm cell. it would basically contain a link back to the entire DNA of its originator then each bot could have a kind of mirror DNA slot where recieved sperm could be stored until used. Possibly an incoming sperm shot could displace the existing reference DNA.
Another option would be to do a similar thing via ties. maybe the competing males could grab the females with ties and inject her with their sperm (bit like mating squids). The point that all the bots are most likely heraphrodites will just serve to make this more interesting and a whole lot more confusing
Any other ideas?
-
If we take bots to be microscopic, single celled creatures, shots are too small to be sperm. If we take bots to be macroscopic creatures, like mice, shots are too big (sort of).
Ties definately make the most since in this case IMO. A 'coupling'
-
What if we take the bots to be inorganic or electrical lifeforms with no real analogies to actual biological lifeforms (that we know of) whatsoever?
That is actually the way I think of them mostly. It make things a lot easier to get a handle on if you don't need to completely mirror known natural stuff.
Besides, if a virus can hold a portion or all of a robot's dna then a sperm the same size could also do it.
-
If bots are inorganic, sexual reproduction has no analog and we're back to square one.
The thing is, no one knows exactly why sexual reproduction is so nearly universal, especially in higher organisms. If we start departing too much, I think we're less likely to stumble on the correct combination that makes sexual reproduction more than a curiosity.
-
If bots are inorganic, sexual reproduction has no analog and we're back to square one.
What would make you think that?
There is no reason why inorganic life shouldn't reproduce sexually.
If we start departing too much, I think we're less likely to stumble on the correct combination that makes sexual reproduction more than a curiosity.
Agreed but I don't see any problem with using shots as sperm. It is completely analogous to many higher order aquatic organisms. If your only issue is one of scale of the shots then you are artificially injecting a problem that isn't really there by making assumptions about the nature/size of DarwinBots. By this reasoning we should probably scap viruses too.
The exact nature of the beasts has always been completely open so that they are whatever any one user wants them to be. And that's the way they should stay.
To me they are sometimes little machines and at other times they might be fish in a pond. DarwinBots are undefined so we can't really force them into non-existent niches by insisting on adherence to a reality that in many cases can't really apply.
-
What would make you think that?
There is no reason why inorganic life shouldn't reproduce sexually.
We don't know of any non-eukaryotic life that sexually reproduces (I don't even think bacteria are doing it), so we certainly don't have the template, the how, that is important in determining how we want to do sexual reproduction for artificial or alien life.
The only example we have is real life having real sex.
Agreed but I don't see any problem with using shots as sperm. It is completely analogous to many higher order aquatic organisms. If your only issue is one of scale of the shots then you are artificially injecting a problem that isn't really there by making assumptions about the nature/size of DarwinBots. By this reasoning we should probably scap viruses too.
Sperm travel slowly in our frame of reference. Shots travel quickly in the bots' frame of reference. Sperm is incredibly fragile and dies easily, which makes long term transmission impossible. Shots are incredibly impervious until they run out of energy, allowing them to cover great distances. Sperm has to be placed in just the right spot, and mammals have even evolved an effective injection system (the penis). Shots just have to touch a bot and their effects are felt. In real life, the only effective strategy for macroscopic (specifically vertebrate) animals is to get up right close to the mate (or the eggs in the case of external fertilization, but eggs tend to be the same size as the animals, relatively speaking) and fertilize them. More often than not this involves a coupling. A coupling not dissimilar to the sort of coupling you get with ties.
Now, smaller critters do do a sort of mass release of sperm and egg, but this would be better modelled in terms of bots instead of shots, especially if we're imagining the more interesting creatures like the fungi.
It is for these reasons that I would support ties and only ties as the basal mechanism for transmitting large amounts of genetic information (such as the whole genome).
Viruses, since you bring it up, are miniscule compared to sperm. Totally different orders of magnitude. And while this fact does make fast moving shots somewhat unrealistic, viruses are also quite hardy, adept at surviving and spreading themselves around.
The exact nature of the beasts has always been completely open so that they are whatever any one user wants them to be. And that's the way they should stay.
To me they are sometimes little machines and at other times they might be fish in a pond. DarwinBots are undefined so we can't really force them into non-existent niches by insisting on adherence to a reality that in many cases can't really apply.
I perfectly agree, but this undefined nature doesn't exist on all aspects, only when taken as a whole. Shots have no natural analog really, you just have to accept them as a throwback to Darwinbots's idealogical predecessor: C Robots. Ties sort of combine a variety of biological ideas into one mechanism, such as leech like sucking of resources, physical connecting proteins, the elongation of a cell during reproduction, etc.
Sex especially has no context when trying to seperate it from the organisms who participate in it. Sex is a complex process. Science is still wrestling with the basic question of "why?". If we start reinventing how we want our sex to work, it's entirely probable we'll remove a key aspect that is imperitive for sex to become evolutionarily useful, and our efforts will be entirely wasted.
-
We don't know of any non-eukaryotic life that sexually reproduces
We don't know of any non-organic life form period.
Who knows how they will reproduce if we ever discover them?
The only example we have is real life having real sex.
Ha! limiting ourselves to real life is boring.
I want to go way beyond what real life can do. I want to explore fantasy worlds as well as real ones.
Certainly sperms (real life ones) are slow and fragile when they move under their own power but they can be packaged up and ejected with considerable force over a short distance. Shots do the same thing. They die too if they don't hit something within a reasonable time frame.
Besides, if my DarwinBots are inorganic, electrical lifeforms then a shot containing a digital code is totally in-keeping with the reality of the sim. It lives as long as it has enough electrical power to maintain it and if it hits a taget during its limited lifespan then it transfers its pattern to whatever it hits.
Shots have no natural analog really, you just have to accept them as a throwback to Darwinbots's idealogical predecessor
I have been pointing that out for years. There are a bunch of things in DB that have no natural analog. Pretty much all the eye based sensory inputs (apart from distance) would fall into that catagory too.
I don't think we should really concern ourselves with making DBs match real life except where that gives us the best chance of something working right. My philosophy is to give them as many avenues as possible to do whatever they need do and let them choose how to do it themselves. Realistic? Not realistic? Doesn't make a lot of difference to me.
Incidentally, some pretty weird stuff happens in real life too.
In some fish such, as guppys and a few other live bearers, the female can carry a package of sperm for a couple of years and use it to fertilise mamy many batches of young. How do they keep the fragile sperm alive? I have no idea. I expect somebody does though. I just never bothered to look for the info.
-
We don't know of any non-organic life form period.
Who knows how they will reproduce if we ever discover them?
Exactly. We don't know how they'd reproduce. Not only that, we aren't even qualified to guess. Biologists still don't understand why sex exists in the first place. What could possibly be so powerful as to entirely overwhelm The two-fold cost of sex (http://en.wikipedia.org/wiki/Two-fold_cost_of_sex). There are theories, but few of them have much experimental data to back them up.
With some very real drawbacks to sex, we have to be very careful setting up our DB sex. We know that real life sex is successful, we just don't know why. It would seem relatively easy for a group of humans to invent something like sex (say, in an ALife program), miss the point entirely, and create a deleterious method of reproduction. I would strongly recommend following the only existing and proven method of sexual reproduction as closely as possible.
IMO we need to follow the actual process of actual sex as clearly and perfectly as we possibly can in the hopes that be sheer dumb luck our version of sex can overcome the two-fold cost of sex as well.
Since our organisms are all haploid, we're already facing a rather significant difference with real life. Given that we may have already taken too great of liberties in this one single regard, we need to proceed very carefully.
If we create a method of sex that does indeed seem to outweigh that two-fold cost for sex, then we could proceed abstracting the process, seeing how far it can be stretched before it breaks.
Ha! limiting ourselves to real life is boring.
While most of life is boring, surely you're not implying that sex is boring!
-
Nums, it seems to me that you're taking things from the wrong side. The first thing one should ask himself, before doing anything, is: why do I want sex reproduction? A few good reasons to introduce sex reproduction in DB have been formulated in the (helas) past years (I'll list them later); but we can just say that introducing it would change the rules of the simulation and give rise to some desirable effect. What's important with in this plan is that it takes the new feature as a starting point for some (foreseeable and desired) effect.
Now, you're taking things the other way. You say, well, sex repro exists in nature, and it is obviously advantageous (because so many organisms adopt it), though I don't know why. So if I want to introduce it, I have to copy it as accurately as possible from nature, so that I'm sure not to leave out something important.
There's something not convincing me in this argument. If you don't know what's the advantage of reproducing sexually, then you may want to investigate about it; to do so with an artificial life simulator, you should take as a starting point a very general set of rules - flexible enough to allow many different types of reproduction - and observe the outcome of natural selection. The result may consist in organisms with, say, one, two, n chromosomes; or no chromosome at all, but just exchanging floating dna or single genes. In any case, you're interested in the result, whatever it is. You want to explain sexual reproduction, but you don't actually need it. It is your goal, not your starting point; hence you should not code it directly in the simulation.
At the same time, you say you want to hard code sexual reproduction in the simulation - just as a rule that you need for new complexity. This would make sexual reproduction a starting point, not a goal, and you should be able to list the benefits of introducing it.
Now, it's been a long time since we first thought about introducing sex in DB. There are a few reasons for this:
1) many of the organisms we're most familiar with (expecially those showing complex behaviour) reproduce sexually. It is not to say that then reproducing sexually is good; but, as DB should show a parallelism with the real world, it is good for DB to reproduce some major traits of the world, sometimes even directly coding them;
2) sex should enhance evolution, by letting the result of good mutations which may have taken place in different branches of the evolution tree mix together;
3) sex, requiring compatible DNAs to mix, gives rise to real species and speciation, which always lacked in DB. The very concept of species is blurry without sex;
4) sexual selection becomes possible, though still hard. The criteria generally used in the choice of the partner influence evolution.
Now, given these points (2,3,4), it is possible to have an idea of what this kind of sexual reproduction in DB should look like. For 2), sex repro should be able to mix dnas of two (or more) individuals, transferring some genes from one to another, or mixing the genes in a new individual; 3) is the consequence of a reproduction mechanism which requires the source dnas to be similar enough to produce a well-formed destination dna; 4) requires robots to be able to make some kind of choice of the partner(s).
These requirements seem to be not too distant from what the actual .sexrepro command does. The least fulfilled is 4): .sexrepro is very weak in that, partially because it is maybe a too simple mechanism, but also because of intrinsical limitations of DB: things in it simply go too fast and good communication between robots which aren't tied is too difficult. Which should be the elements for a good partner's choice?
Also the algorithm which mixes the two dnas is probably too simple - though working, and not too difficult to improve. Has anybody tried to run extensive simulations making use of (and exclusively of) sexrepro?
Anyway, my point is simply that, before thinking of adding features to DB, one should know exactly what he needs.
Bye,
Carlo
-
I would say my primary motive for desiring sexual reproduction is that others desire it. It is quite common for people to want to run a simulation experimenting with sex. I've seen several users come and go for this reason.
Allowing the sexual reproduction to be created from more basic commands has a problem with backwards compatibility. Not impossible to resolve, but still quite noteworthy. .repro is a perfect reproduction method, as opposed to Avida where the entire genome is concerned with reproduction. If sexrepro is orders of magnitude more complex than .repro, we have a problem of a slanted fitness landscape where sex is concerned.
To resolve it, should we wish, we could generate a sequence of very basic commands to operate on the DNA, and have .repro act as a modifiable macro, perhaps using codules or some such.
I am of the strong opinion that we need to move as much of the program away from the gene as a fundamental unit. DNA should be treated more as a long strip of magnetic tape and less like a collection of pearls on a necklace, if that makes sense. Especially since modern gene structure can be quite peculiar and convoluted.
-
I would say my primary motive for desiring sexual reproduction is that others desire it. It is quite common for people to want to run a simulation experimenting with sex. I've seen several users come and go for this reason.
Well, if you don't know your goal, no surprise you don't have clear ideas on how to reach it.
Allowing the sexual reproduction to be created from more basic commands has a problem with backwards compatibility. Not impossible to resolve, but still quite noteworthy. .repro is a perfect reproduction method, as opposed to Avida where the entire genome is concerned with reproduction. If sexrepro is orders of magnitude more complex than .repro, we have a problem of a slanted fitness landscape where sex is concerned.
I don't see why sexual and asexual reproduction, or even complex/new style repro and old simple .repro, should cohabit in the same simulation. Sex seems to be per se not competitive with asexual reproduction, at least in the DB world. (This don't necessarily means that there's something wrong with DB: maybe sex just needs huge and complex environments to develop and be advantageous). So I would simply allow to run simulations with sexual repro, without worrying about its complexity or competitivity. Later, but much later, one can think of creating a more AVIDA-like control over genetic material to allow, through the same mechanisms, both asexual and sexual repro.
To resolve it, should we wish, we could generate a sequence of very basic commands to operate on the DNA, and have .repro act as a modifiable macro, perhaps using codules or some such.
As I just said, it would be a completely different project. The problems to address now are (at least) those four points I listed in my previous post.
I am of the strong opinion that we need to move as much of the program away from the gene as a fundamental unit. DNA should be treated more as a long strip of magnetic tape and less like a collection of pearls on a necklace, if that makes sense. Especially since modern gene structure can be quite peculiar and convoluted.
That's again another project, which has almost nothing to do with sex.
Bye,
Carlo
-
By the way, could anybody tell me what's so wrong with .sexrepro?
Thanks
-
By the way, could anybody tell me what's so wrong with .sexrepro?
Nothing really (in concept) It just doesn't seem to work.
Also it does not give either parent a real choice in the who the other one will be as it takes the DNA of the nearest bot in physical space to combine with its own.
-
Actually, after some experimentation in 2.37.6 with a .sexrepro-using Animal Minimalis, it doesn't seem that bad at first glance. Slightly buggy in some areas (ie. no reproduction collision detection) but not that bad
My first worry was that the sexreproing bot would combine with a veg or an entirely different bot, but the code seems to prohibit sexual reproduction if the genomes are two dissimilar
My only concern is that, as PY said, there's no way to choose your 'mate' - you just get your DNA yanked out of you if you're nearest
How about having .sexrepro fire a tie forward, which, on hiting another bot, takes that bot's DNA and mixes it with the original bot in a manner similar to the original .sexrepro
That way you can choose your mate by hunting round, say for a bot with more than a certain energy or kills (ie. allows for sexual selection), and then aquiring it's DNA through a sex-tie
-
Actually, after some experimentation in 2.37.6 with a .sexrepro-using Animal Minimalis, it doesn't seem that bad at first glance. Slightly buggy in some areas (ie. no reproduction collision detection) but not that bad
What do you mean precisely with "reproduction collision"?
My first worry was that the sexreproing bot would combine with a veg or an entirely different bot, but the code seems to prohibit sexual reproduction if the genomes are two dissimilar
Hm, no. The code shoudn't prohibit nothing but, as one would expect, if the dnas are too different the reproduction fails - the child isn't able to do anything and dies rapidly.
My only concern is that, as PY said, there's no way to choose your 'mate' - you just get your DNA yanked out of you if you're nearest
Well, ideally the bots should activate their .sexrepro locations just when they've found a good partner and are in contact with it. Activating it and then keeping roaming waiting for a random collision is just the simplest way to reproduce - not the best one. Also, if I'm not wrong, the procedure requires both the bots have their .sexrepro activated, so the collision should be with one who is also willing to reproduce.
How about having .sexrepro fire a tie forward, which, on hiting another bot, takes that bot's DNA and mixes it with the original bot in a manner similar to the original .sexrepro
(Original sexrepro? What sexrepro are we talking about?) . Anyway, the tie isn't a bad idea. By the way, maybe glue would be even better. Has anybody thought of a glue which makes robots stick together without being actually tied, that is, something that just keeps two robots attached until a slight force divides them?
That way you can choose your mate by hunting round, say for a bot with more than a certain energy or kills (ie. allows for sexual selection), and then aquiring it's DNA through a sex-tie
I'd like better a simmetric process, in which both bots are willing to mate and the offspring just belongs in the same way to both partners.
-
why does a bot have to choose?
isn't the fact they, and their 'mate' ...
have survived in a given enviornment enough?
shoudn't the ablity to survive be the determining factor?
any 'choice' should be based upon that, eh?
can we please keep this sort of anthropomorphism ...
the attribution of human/animal motivation, characteristics,
and behavior to the bots to a minimum?
they don't have to look like or behave or conform
to our expectations and ideas of what it should be.
keep it simple:
what works continues ...
what doesn't ends.
that's evolution.
unless one prefers intelligent design.
as far as I know ...
we ain't in kansas anymore toto.
-
why does a bot have to choose?
Because one of the most important mechanisms of natural selection is called sexual selection. Animals tend to evolve features which can increase the probability of being chosen by a partner for reproduction, even if those features are useless or noxious in everyday's life. The usual example of the results of sexual selection is the peacock's tail, but the examples are countless. It is common opinion that sexual selection may have played a major role in the evolution of the human brain itself, favouring language and other kinds of abilities (musical, for example) much beyond the real needs of the species.
A great artificial life simulator designed to play with sexual selection is Ventrella's Darwin Pond.
http://www.ventrella.com/Darwin/darwin.html (http://www.ventrella.com/Darwin/darwin.html)
(though I'm sure that everybody here knows it already )
-
What do you mean precisely with "reproduction collision"?
It's a very minor issue. The bots reproduce whether there's space in front of them or not, while 'normally' bots can only reproduce if there is sufficient space for the offspring.
Hm, no. The code shoudn't prohibit nothing but, as one would expect, if the dnas are too different the reproduction fails - the child isn't able to do anything and dies rapidly.
Well, ideally the bots should activate their .sexrepro locations just when they've found a good partner and are in contact with it. Activating it and then keeping roaming waiting for a random collision is just the simplest way to reproduce - not the best one. Also, if I'm not wrong, the procedure requires both the bots have their .sexrepro activated, so the collision should be with one who is also willing to reproduce.
Ah, that must be the reason. I was wondering why the bots weren't just grabbing veg and nearby bot DNA, but both bots must be sexreproing at the same time, that explains it
(Original sexrepro? What sexrepro are we talking about?)
The one we have now, that you coded
-
Here's a thread (http://darwinbots.proboards20.com/index.cgi?board=general&action=display&thread=1097167221&page=1) from the old DB forum about sexual reproduction
There's some very interesting ideas there to think over
I've had a think, and IMO we need a simple system that doesn't try to model real life too closely, that does the absulute minimum to combine the DNA of two bots, and leave the complicated stuff to evolution and bot-programmers. As Carlo said, sexual reproduction should be a starting point, rather than a result.
You could make a reproduction system that modeled nature exactly, but the only thing you would be able to do with such a system is reproduce in a certain, predetermined way, which may stifle creativity. A simple back-to-basics system that does the bare minimum will undoubtedly have great potential for interesting things which we may not have thought of, for example, as mentioned in the above thread, using .sexrepro as a weapon. Perhaps a bot could use such a system to incorporate the DNA of other species into into it's own, creating deadly hybrids that 'learn' new tricks from other bots.
Responses?
-
This is what I have been trying to say all along Elite ...
keep it simple. Do the basics. But let the bots ...
and their relationship with the enviornment evlove.
Let's go for evolution, not intellegent design!!!
And yes, sexual reproduction works, [at least in our world] ...
it's a good thing. I have no problem at all with that.
We do want to incorporate sexual reproduction.
What I object to is that folks think it is a 'choice' that organisms
make that is based upon something other than survival of the fittest.
The peacocks tail, and other such 'seemingly' nonutilitarian frills ...
continues to exist because it demonstrates that an organism has
prospered in the face of evolutionary pressure ...
that it can afford such luxuries. 'Look at me!"
No animal could afford such luxuries that serve no utilitarian
pupose unless it had indeed become proficient at survival ...
had evolved to become a healthy and viable organism.
It is something that worked. Period.
This same thing underlies why humans are unconsciously attracted
to other humans, to what they find 'beautiful' and attractive in another.
It isn't so much a 'choice' as it is the organisim recognizing the
potential mate is healthy and strong.
If you want to call that 'choice' ... ok.
But it is subconscious, not a conscious 'rational' choice.
These traits and attractions exist and continue to exist only because
they continue to work.
And it is something that has evloved ...
not something designed in from the beginning.
-
First, none of you are getting the way sexrepro was programmed right, and so your conclusions are flawed. This is classic sexrepro in a nutshell:
0. Sex is performed between two bots. The first bot is the one that initiated the sexual reproduction. The next bot is the bot that's next in the reproduction array. Who's next in the reproduction array? The last bot that the initiating bot saw in eye5. If this other bot is not sexually reproducing, sexrepro shouldn't occur.
1. Both bots' centers must be within 2 robsizes of each other. ie: they basically have to be within 1 robot length of touching.
2. Both bots DO NOT have to be sexreproing at the same time. sexrepro isn't cleared every cycle. It's only cleared if the bot successfully sexrepros. Thus an unwary bot could find itself forced to reproduce and contribute all of its energy to an offspring. This could be used as a weapon.
3. Properties are determined by how much each parent contributed during sex. It handles poorly things like species lineage, generation, robot color, and other properties that would probably make more sense by remembering both parents. This basically means that any person trying to figure out what's going on in their sexrepro sim is going to be very confused.
4. The parents' DNA is shuffled every other gene. That means 1st gene comes from mom, second from dad, third from mom, fourth from dad, etc. Any leftover DNA (one parent has more genes than another) is either slapped on the end of the child or not (depending on a 50/50).
5. Ties are formed between mom and child and dad and child.
The problem with the original sexrepro:
1. Selection of mates is too limited. Sexual reproduction needs to be a mostly consensual. You need to be sure exactly who you're mating with.
2. The code was a little sloppy, resulting in it not being maintained, and hence buggy.
3. The code was gene-centric. Post 2.4, the only gene centric DNA commands relate to viruses. The gene structure is just too impossibly complex to do this anymore in a meaningful way. Also simply lining up genes and picking one from either one DNA or the other won't work effectively when you begin to consider large insertions, deletions, and reversals (mutation types that do not cause catastrophic failure in real organisms). If a bot is missing gene 2 you would hope that genes 3, 4, and 5 would still cross over effectively. You hope that gene 2 might even be replaced by a sexual encounter. This isn't possible if you just mindlessly shuffle the 1st genes followed by the second genes, etc.
4. Fails to model any but the macroscopic version of sex. By which I mean a mother and a father copulating to produce a new unique organism. As opposed to microscopic sex that involves two organisms fusing, their haploid DNA becoming diploid. Both should evidently be very different.
----------------------------------------------------
The following is no longer necessarily fact, but is my own personal opinion:
Crossing Over:
The best solution is to line up the DNA based on similar sequences instead of similar positions. You then "twist" the strands in a few random places to shuffle it a bit. Very simple swapping.
This is not complicated. It is in fact ingeniously simple when you consider the number of programatic hurdles to overcome. Any complication people percieve is entirely in their minds. It is in no way more complicated than "swap every other gene", or something similar.
There is a reason the mechanisms of sex have been maintained so well over the course of eukaryotic evolution.
Mechanics of Sex:
Sex needs to be 95% consenual. By which I mean RAPE has a place evolutionarily speaking, but it should be a little difficult. The current system models this reasonably well since sexrepro isn't cleared, but I think clearing it every cycle would be better.
Both bots should be tied to each other. Shots are simply not personal enough. Mating needs to be topologically close, both in time and space. (both bots consent at the same cycle within a set distance boundary, preferablly in indirect or direct physical contact).
Sex should have at least two basic possible results:
1. Both bots fuse, the resulting bots' DNA is an amalgamate of both parent bots. Preferably this would be diploid, and thus keep both parent's DNA intact (so an intact seperation would be possible), but this is probably just wishful thinking. This models the sort of sex we see in funguses and things like sperm and eggs.
2. (Either one or both) bots produce a new unique child with an amalgamate of the two parent's DNA.
Other possibilities should be obvious (multiple parents, for instance), even if not practical to implement or based in reality. But the two above would need to be both included for me to call it reasonable effort.
-
0. Sex is performed between two bots. The first bot is the one that initiated the sexual reproduction. The next bot is the bot that's next in the reproduction array. Who's next in the reproduction array? The last bot that the initiating bot saw in eye5. If this other bot is not sexually reproducing, sexrepro shouldn't occur.
1. Both bots' centers must be within 2 robsizes of each other. ie: they basically have to be within 1 robot length of touching.
This makes sense. Not only they have to physically near, they also have to be watching each other. Romantic, isn't it? This allows a bot to know exactly who is he mating with, even if there are other bots around.
2. Both bots DO NOT have to be sexreproing at the same time. sexrepro isn't cleared every cycle. It's only cleared if the bot successfully sexrepros. Thus an unwary bot could find itself forced to reproduce and contribute all of its energy to an offspring. This could be used as a weapon.
This give bots more control. If they want, they CAN clear sexrepro at every cycle. It's a matter of choice.
3. Properties are determined by how much each parent contributed during sex. It handles poorly things like species lineage, generation, robot color, and other properties that would probably make more sense by remembering both parents. This basically means that any person trying to figure out what's going on in their sexrepro sim is going to be very confused.
This isn't a problem of the simulation in itself, but of its framework. Simply, DarwinBots wasn't designed to keep track of two parents per reproduction. Same for generation, the very concept can't apply to a sexual reproduction. Robot colors can be mixed, or inherited randomly, but hey, who cares? Anyway, minor problems here.
4. The parents' DNA is shuffled every other gene. That means 1st gene comes from mom, second from dad, third from mom, fourth from dad, etc. Any leftover DNA (one parent has more genes than another) is either slapped on the end of the child or not (depending on a 50/50)
.
This is the worst thing in sexrepro. It works as long as there aren't gene duplications or deletions, otherwise it is likely to shuffle off the genome some important gene shared by both robots. It should be substitued by an algorithm lining up similar genes in groups and then taking approximately half of the copies per group.
The problem with the original sexrepro:
1. Selection of mates is too limited. Sexual reproduction needs to be a mostly consensual. You need to be sure exactly who you're mating with.
You can, if you take care of your .sexrepro. And the lesson is: if you give it around to everybody, you can't blame society for being a teen mother.
3. The code was gene-centric. Post 2.4, the only gene centric DNA commands relate to viruses. The gene structure is just too impossibly complex to do this anymore in a meaningful way. Also simply lining up genes and picking one from either one DNA or the other won't work effectively when you begin to consider large insertions, deletions, and reversals (mutation types that do not cause catastrophic failure in real organisms). If a bot is missing gene 2 you would hope that genes 3, 4, and 5 would still cross over effectively. You hope that gene 2 might even be replaced by a sexual encounter. This isn't possible if you just mindlessly shuffle the 1st genes followed by the second genes, etc.
Well, the whole DarwinBots was gene-centric when I added sexrepro, and (to be honest) I don't even know what the actual dnas look like (or could look like). If genes aren't well separated anymore, then things get more complex. But the basic point should be the same: grouping similar sequences and then choosing randomly which to use in the new dna.
4. Fails to model any but the macroscopic version of sex. By which I mean a mother and a father copulating to produce a new unique organism. As opposed to microscopic sex that involves two organisms fusing, their haploid DNA becoming diploid. Both should evidently be very different.
That's a different problem. There are many things the actual repro and sexrepro fail to model, being high level commands that just fire an automated process. But until we focus on organisms behaviour and leave out the details, I don't think that there's any need to model low level sexual haploidy and diploidy. Bots are well defined individuals, like sheep or ants, so they aren't expected to fuse, but to mate.
----------------------------------------------------
The following is no longer necessarily fact, but is my own personal opinion:
Crossing Over:
The best solution is to line up the DNA based on similar sequences instead of similar positions. You then "twist" the strands in a few random places to shuffle it a bit. Very simple swapping.
This is not complicated. It is in fact ingeniously simple when you consider the number of programatic hurdles to overcome. Any complication people percieve is entirely in their minds. It is in no way more complicated than "swap every other gene", or something similar.
I'd start with this, which fixes the actual working of sexrepro without any major change at high level. Then you can add whatever you want, but before making great plans, I'd just fix what's broken.
-
Anyway, I'm leavin' for holidays. Will be back in a week or so.
Good bye!
-
This makes sense. Not only they have to physically near, they also have to be watching each other. Romantic, isn't it? This allows a bot to know exactly who is he mating with, even if there are other bots around.
Not exactly true, which is part of the peculiarity.
When a bot no longer sees any bot, the .lastopp (the bot it saw last) variable isn't reset. Let's say that the bot it wanted to mate with managed to die before it could mate. The other bot will still be pining away for bot #21, whose slot happends to be empty. Since sexrepro isn't reset, it will keep trying to mate with bot #21. Eventually, slot #21 will be filled again, and should that new bot be attempting to mate too, and happen to be relatively close, the bot will end up mating with that bot.
Likewise, it's possible that if bot A and B are mating, bot C could look at bot A and mate with it. Or it could be that they form a threesome, with bot A taking DNA from bot B, who takes DNA from bot C who takes DNA from bot A. Theres no code to deactivate a parent's sexrepro once another bot decides to mate with it until a child is formed, which means its possible a bot could find itself the parent of 5 or 6 children when it only mated once.
These peculiarities are only what I could see in the actual code. There might be many others.
This isn't a problem of the simulation in itself, but of its framework. Simply, DarwinBots wasn't designed to keep track of two parents per reproduction. Same for generation, the very concept can't apply to a sexual reproduction. Robot colors can be mixed, or inherited randomly, but hey, who cares? Anyway, minor problems here.
Minor problems yes, but problems that should be addressed, especially if you want to study the ancestry of a bot (which would be important for studying group genetic drift, or something similar).
Well, the whole DarwinBots was gene-centric when I added sexrepro, and (to be honest) I don't even know what the actual dnas look like (or could look like). If genes aren't well separated anymore, then things get more complex. But the basic point should be the same: grouping similar sequences and then choosing randomly which to use in the new dna.
I'm not blaming you, it worked well when you first created it. It's just outdated anymore.
That's a different problem. There are many things the actual repro and sexrepro fail to model, being high level commands that just fire an automated process. But until we focus on organisms behaviour and leave out the details, I don't think that there's any need to model low level sexual haploidy and diploidy. Bots are well defined individuals, like sheep or ants, so they aren't expected to fuse, but to mate.
Many organisms live half of their life as a haploid individual and the other half as a diploid individual. Both existances are well defined. The most everyday example of such an organism is the Fern (http://en.wikipedia.org/wiki/Fern). This alternation of generations (http://en.wikipedia.org/wiki/Alternation_of_generations) is fundamental to many life cycles.
-
Horray I'm back
Played around with sexrepro myself. The version I'm using has some benneficial changes though. I've increased the distance allowing the bots to mate with bots at a farther radius. I also added a protective feature to make the code check veggie population size before allowing reproduction(fixing a major bug allowing truly super massive plan populations).
I tend to think of it as more like a very primitive crossing over event rather than true sexual reproduction. Realisticly enough a bot that uses both sexrepro and normal repro does better in terms of genetic diversity than typical species. (.repro 1 rnd 2 mult add) ( ie. switches between repro and sexrepro).
Still has problems with weird plant-animal hybrids, these odd super animals kill off their own primitive plant ancestors and well eventually crash the ecosystem.
Been playing around with adding code to delete even or odd halves of a bot's dna, with the intention that then the bots could mix their half with anothers. Can't quite the code right though
On sperm:
I'm guessing here but I think our and other higher animals' sperm is evolved/designed to live short times. The temperatures they survive at are lower than typical core body temeperatures. Still guessing but I think it may be to limit mobility within the body, just me but I wouldn't want one of them winding up interfering with my normal cells .
-
When a bot no longer sees any bot, the .lastopp (the bot it saw last) variable isn't reset. Let's say that the bot it wanted to mate with managed to die before it could mate. The other bot will still be pining away for bot #21, whose slot happends to be empty. Since sexrepro isn't reset, it will keep trying to mate with bot #21. Eventually, slot #21 will be filled again, and should that new bot be attempting to mate too, and happen to be relatively close, the bot will end up mating with that bot.
Just a little bug. Very unlikely to happen, but, to fix it, you can just add to the internal value of lastopp the unique id of the seen bot. And before doing anything with the lastopp value, you should check that the bot in the array slot has the correct unique id. The lastopp stores the array slot instead of the unique id just for speed purposes.
Likewise, it's possible that if bot A and B are mating, bot C could look at bot A and mate with it. Or it could be that they form a threesome, with bot A taking DNA from bot B, who takes DNA from bot C who takes DNA from bot A. Theres no code to deactivate a parent's sexrepro once another bot decides to mate with it until a child is formed, which means its possible a bot could find itself the parent of 5 or 6 children when it only mated once.
Isn't necessary for bots to be both looking at each other in order to mate? And the .sexrepro value should be set to zero once a mating took place. If bot 1 mates with bot 3, bot 2 can't mate with 1 in the same cycle, since when the procedure examines bot 2, bot's 1 sexrepro has been set to zero (it may be that the code actually sets to zero the sexrepro after examining ALL the matings, but then we can just modify a little the code. By the way, yes, having a low slot in the bots array actually has some advantages, but since the slot is chosen randomly, those advantages are equally distributed among all species).
(parents and generation tracking are) Minor problems yes, but problems that should be addressed, especially if you want to study the ancestry of a bot (which would be important for studying group genetic drift, or something similar).
Problems that would become even worse if we introduce diploidy, genes sharing, etc. So, they can't make you look for such kinds of alternatives. Anyway, a serious study of the simulation can be made ONLY through the database recordings, which should just record two parents instead of one to let you keep track of the complete genealogic tree. So, the only thing to do here is duplicating the parent field in the robot's data and record it in the database file. As for the generation data, we can give an indicative value like the mean of the parent's generations + 1 or something like that.
Bye,
Carlo
-
So currently with sexrepro not being reset it could see another bot that has it's sexrepro activated then effectivly it would "hold" that bot's dna until it can afford to reproduce.
This could actually be something of a bennefit in the bot's world. Trying to co-ordinate an exact timing would be pretty difficult otherwise. Still kind of problematic possible having it wind up being some other bot's dna, instead of the desired dna; but then again perhaps useful in it's own way.
Read what Nums wrote again and I had an idea
Maybe add a random gene shuffling ability. This would randomize the gene structure enough that if the bot is missing a particular gene, it might get it back the next sexrepro attempt. (strangely we ourselves have something very similar to this, hmm...)
Perhaps have it be possible both within the bot itself, and make it automatic with the dna sexrepro'd. Maybe have an array of all the bot's genes then randomly pick from this array until there are no more genes.
Family Trees:
Is it really even possible/practical to do a complete dna trace anymore? I'll have sims going with sexrepro, repro and viruses; causing all kinds of gene swapping. Just try imagining creating a complete human dna tree going back through every single ancestor, including all dna picked up from every possible source including the retro-viruses and the animals they got their dna from... I think it's becomming impossible to keep tabs on every single thing going on.
I think Tierra has some sort of mode that turns off certain dna swappings, perhaps it'd be a good idea to add something similar.
-
So what have we agreed on so far?
Can we start to begin formulating a system?
So long as bots have to consent before reproduction, and it is possible to pick a partner with precision, then I see no problem in how the actual reproduction is acchieved. DB is an artificial life sim, and so there's potentially unlimited flexibility in how it maps to real life.
So do we want to acchieve partner selection through:
- Ties?
- Line of sight?
- Shots?
- Proximity/Physical contact?
-
I think the currently implemented rules for sexrepro are almost ok.
This is the way I think sexrepro should be implemented now:
1) Sexual reproduction can be performed by two normal bots through the use of the .sexrepro location, and results in the creation of children bots with a "good mix" (more on this later) of the dnas of the parents.
2) The partner for the mating has to be clearly identified: this is achieved by having bots looking each other.
3) The mating should be generally consensual: both bots should have their sexrepro location activated.
3.1) The .sexrepro location value should express the percentage of his own energy each bot would give to the child. This is particularly interesting because gives birth to a prisoner's dilemma game.
3.2) The .sexrepro location is not reset until a mating occurs (this makes easier to mate if no selection of the partner is made).
4) The mating bots should be in proximity of each other (no "action at a distance").
5) A bot may be involved in only one mating per cycle.
6) After the mating, parents and child are temporarily connected through a reproduction tie (for similarity with asexual repro).
and finally
7) The program should keep track of two parents, recording their IDs
8) The generation value should be discarded when sexrepro is used or substituted by an approx value like (gen par1+gen par2)/2+1 or whatever else
Ok. During the discussion we agreed on the fact that the current way of creating a "good mix" of the dnas of the two parents isn't good at all -it is flawed and, besides, it is gene centric. But Numsgil said he can implement a much more sophisticated dna mixing system, so this should be no problem.
Another point we should consider is how many children should be generated in a mating operation. As the operation of finding a partner is expensive in terms of time and energy, we may decide to allow the creation by the couple of many children at once. The only problem is to decide _how_ the bots may decide to create more children. One possible solution is to allow robots to mate repeatedly with the same partner while the first mating operation isn't yet complete (that is, while the two parents and the children are still connected by reproduction ties); but we don't even have to explicitly allow it if we don't state that two bots can't mate until one of them is still in a mating operation with a third one. So, either we add two rules (robots can't mate until a previous mating is ended BUT they can do it with the same partner) or we simply let bots mate at every time (which is my preferred, I'm for deregulation).
So do we want to acchieve partner selection through:
- Ties?
- Line of sight?
- Shots?
- Proximity/Physical contact?
Couples of bots must be identified by a link of some form connecting them. Shots and proximity won't work since the first are difficult to use and synchronize, and the second is not a 1 to 1 relation. Line of sight and ties would be both ok, but surely the easiest way to identify with precision a couple is to have them looking at each other: it links the two bots, but at the same time leaves them completely free. A tie links two bots, but also has the annoying physical effect of keeping them together. If you consider that the linking operation should take place before bots express their consent to sexual reproduction, you can imagine what a mess would be having horny bots going around linking everybody.
So, who's gonna implement this?
-
3.1) The .sexrepro location value should express the percentage of his own energy each bot would give to the child. This is particularly interesting because gives birth to a prisoner's dilemma game.
I can see your point in this, but I have two points that should be considered:
A. To bots that are mating under microscopic rules, sexual reproduction is really a fusing. Two bots become one. In such a system, the number in sexrepro doesn't really have a meaning. Therefore I think that another variable should hold this information. Leave .sexrepro to information such as relative amount of mixing, or something similar. Something universal to the sexrepro process.
B. Imagine bots that, like worms, cross fertilize each other. So both end up having babies. There should be a way of saying wether you're using repro nrg for your own kid or a kid the other bot makes.
3.2) The .sexrepro location is not reset until a mating occurs (this makes easier to mate if no selection of the partner is made).
The only danger I see is in two bots losing sight of each other and another bot swooping in and mating accidentally. Losing sight of each other is very easy to do. One of the bots could get hit by a flying veggy, or bounce against a wall. It happens alot, even with bots that are designed to follow another bot.
I think it would make more sense to think of sexrepro as a request ("Will you have sex with me?") that must be repeated each cycle. Like a mating call. Sort of.
6) After the mating, parents and child are temporarily connected through a reproduction tie (for similarity with asexual repro).
I would connect only those bots who have contributed resources to the child. The child should be placed such that the distance from child's perimieter to both parents' perimiter is equal. If there is only one contributing parent, the child should be placed as .repro kids are.
7) The program should keep track of two parents, recording their IDs
8) The generation value should be discarded when sexrepro is used or substituted by an approx value like (gen par1+gen par2)/2+1 or whatever else
I think I can devise some sort of tree structure for keeping track of phylogenic trees.
...simply let bots mate at every time (which is my preferred, I'm for deregulation).
That would be my preference as well.
Couples of bots must be identified by a link of some form connecting them. Shots and proximity won't work since the first are difficult to use and synchronize, and the second is not a 1 to 1 relation.
I agree.
Line of sight and ties would be both ok, but surely the easiest way to identify with precision a couple is to have them looking at each other: it links the two bots, but at the same time leaves them completely free. A tie links two bots, but also has the annoying physical effect of keeping them together. If you consider that the linking operation should take place before bots express their consent to sexual reproduction, you can imagine what a mess would be having horny bots going around linking everybody.
And I can see your point here. My only point to point out is that maybe we should allow both line of sight and tieing, if for no other reason than that, should a bot couple wish to mate multiple times, the kid's going to get in the way! If the parents are still tied together, this problem is somewhat circumvented.
So, who's gonna implement this?
I think this is reallt two questions. Where and who.
As to where, the C++ base would make the most sense. It's certainly complete enough for all the features listed here, and it has the two benefits of STL vectors to handle DNA swapping (and keeping that swapping code clean) and a relatively well organized code base. On the other hand, since the code hasn't really been released to general use, let alone properly debugged, the implementation would be little more than proof of concept.
As to who, I am personally of limited free time. I have school and work, and between the two I only really have 2 free days a week. So I can do it, it will just take a while, and take second precedence over finishing the tie code in the C++ version and finally releasing an install of it.
-
A. To bots that are mating under microscopic rules, sexual reproduction is really a fusing. Two bots become one. In such a system, the number in sexrepro doesn't really have a meaning. Therefore I think that another variable should hold this information. Leave .sexrepro to information such as relative amount of mixing, or something similar. Something universal to the sexrepro process.
Sexrepro was originally desgned to give the effect of a macroscopic sexual reproduction, and the rules we defined in this discussion are referred to a macroscopic type of sexual reproduction. Fusing (making two cells become one, with the complete dna of both parents) could be an useful and interesting mechanism, but has very little to do with sexrepro as it has just been defined. So I can't see the point in using the same sysvar both for sexrepro and fusing (other than a nominalistic question). Let's just create another sysvar (.fuse, for example) which does the job.
B. Imagine bots that, like worms, cross fertilize each other. So both end up having babies.There should be a way of saying wether you're using repro nrg for your own kid or a kid the other bot makes.
Why? I can't see the point. The sexrepro takes place between two cells, not two worms. The offspring doesn't belong to one or the other worm, but in equal measure to both parents. By the way, it is interesting to figure out some different reproduction schemas for multicellulars. For example, org A and org B could touch each other with a reproductive cell, and the sexrepro would give birth to the embryonic cell of a new individual, while leaving the reproductive cells intact. Or the reproductive cells may invest all their energy in the offspring, disappearing after the mating. The cells may also be released in the environment like sperms or spores, or the mechanism may be asymmetric, with one organism sending its reproductive cell towards the other waiting for it.
The only danger I see is in two bots losing sight of each other and another bot swooping in and mating accidentally. Losing sight of each other is very easy to do. One of the bots could get hit by a flying veggy, or bounce against a wall. It happens alot, even with bots that are designed to follow another bot.
I'd call it a technique for rape. Obviously sexrepro requires some additional care compared with the "typical darwinbots life" that is just going around almost carelessly and bouncing everywhere. It is possible that sexrepro will require an environment a little bit less competitive and in some way more sluggish, to allow bots to have more control of their movements and their relative positions.
I think it would make more sense to think of sexrepro as a request ("Will you have sex with me?") that must be repeated each cycle. Like a mating call. Sort of.
Well, that's just a matter of taste. Basically, the only difference will be in how much energy the bot will spend to maintain its sexrepro on.
I would connect only those bots who have contributed resources to the child. The child should be placed such that the distance from child's perimieter to both parents' perimiter is equal. If there is only one contributing parent, the child should be placed as .repro kids are.
Both parents will contribute to the child. The least contribution possible is 1% of their own energy, but it will be very rare: if both bots contribute for the 1%, they will simply lose the energy (that given to the child and that necessary for the sexrepro command) and the child.
I think I can devise some sort of tree structure for keeping track of phylogenic trees.
That would be interesting, but not really necessary. It is sufficient for each bot to be recorded in the database with both parent's IDs to rebuild that tree completely when analyzing data.
My only point to point out is that maybe we should allow both line of sight and tieing, if for no other reason than that, should a bot couple wish to mate multiple times, the kid's going to get in the way! If the parents are still tied together, this problem is somewhat circumvented.
To have them both seems useless, and ties are a problem because of what has been said. Anyway, when sexrepro occurrs, a tie is created between parents, but keeping in sight is an ability bots should show to make more children. Id' just take care of children appearing in some point at the left or right of both parents, not in between.
I think this is reallt two questions. Where and who.
As to where, the C++ base would make the most sense. It's certainly complete enough for all the features listed here, and it has the two benefits of STL vectors to handle DNA swapping (and keeping that swapping code clean) and a relatively well organized code base. On the other hand, since the code hasn't really been released to general use, let alone properly debugged, the implementation would be little more than proof of concept.
I haven't seen a working version of the c++ version yet, and if you can work on it just 2 days a week, probably it will take a long time before a usable version is released. The algorithm for swapping dna portions seems trivial in any language (except for the procedure to compare the dnas and find similar portions), and most of the other rules are in the already implemented sexrepro. So maybe you could write out the most difficult part, while others could make up the rest. Any volunteers?
-
Hi, I've been using Darwinbots for a few months now but I haven't actually posted on this forum until now.
Sexual reproduction is something I've been wanting for a while now, simply because all the long-term evolution sims I've run have ended with extinction. As far as I can tell sexual reproduction is a way of diversifying the population - the offspring is not limited to a single parent's genome plus reproductive mutations. And as I've learned over the last few months of running sim after sim after sim, a diverse population is a healthy population; monocultures are fragile and in a closed environment, ultimately a dead end.
I apologise for coming in the middle of this discussion with some ideas, if they're not welcome (or just no good!) just say.
Instead of sexual reproduction allocating a portion of the bot's current nrg to the offspring, perhaps nrg could be allocated to a "sexual reproduction bank" in a similar way to body, slime, shell etc. In this way preparing for reproduction is an investment, requiring "healthy" reproduction-concerned genes as well as general fitness, and selection pressures will favour organisms which allocate an appropriate amount and punish those who do not allocate enough (fewer breeding opportunities), or too much (less nrg available for living). Other bots may be written with or evolve a way use the amount of nrg stored in the bot's sexual reproduction location to gauge its suitability for mating. When the bot is involved in sexual reproduction it converts the value stored in the sexual reproduction location to nrg and passes it to the offspring.
The way I envision the actual reproduction mechanism operating is if a bot passes this sexual reproduction energy to another then the other produces a new bot with blended dna. If the system is set up so that this sexual reproduction energy can be sent via shot and tie then we can allow bot writers and evolution to work out what is best for their particular bot. So a sexual reproduction shot would include an amount of this sexual reproduction energy and the bot's identifier, sexual reproduction via ties would pass sexual reproduction energy and the bot's identifier (or maybe the tie number? Perhaps that might work better from the system's viewpoint). Perhaps the active part (the actual firing of the shot or the tie function) might be best expressed as firing a percentage of the sexual reproduction fund rather than absolute figures. The system generates a new genome from the two bots (perhaps the earlier two-halves method from earlier in this thread) and the bot that recieves the sexual reproduction energy adds the sexual reproduction energy from the shot to its reserve of sexual reproduction energy, converts the total to nrg and gives it to the offspring.
Just my $0.02, and as I said, feel free to tell me to shut up
-
Not at all, feel free to put in up to and including $0.86
My only counterpoint is this question: does it add a new ability? If it's just a segmenting of nrg, it doesn't do anything nrg by itself couldn't do. Body, for instance, is used as a way to increase power. Venom adds a new ability to the bot (venom shots). etc. etc. What does sex nrg do other than exist?
If you can think of a good reason for it to exist, then I wouldn't see any reason for it not to.
-
Been playing with this on and off myself. I'll agree that's its way too easy to abuse the current system.
Some issues:
I've made species of bots that keep track of the other's sexrepro location then mate only if the other's nrg contributation is higher than their own. One bot will be giving 50% and the other a miserly 1%.
Maybe a system like:
BotA: I'm willing to give X nrg
BotB: Well then, I'm willing to give Y nrg
Result: Both parents agree and a baby is formed
It's also possible to ensure all your genes are carried by another bot by simply doubling your geneome.
Ie. AAbbCCddEE (with each letter representing two identical genes)
This bot will always have 1/2 of it's genome carried into the child.
One last problem is the geneome size mismatch problem. A SG bot can take the majority of another's dna during sexrepro. Which explains these infernal plants we wind up with...
For those who like playing here are some genes I've come up with to use sexrepro (last vers)
cond
*.robage 0 =
start
.sexrepro .memloc store
stop
cond
*.memloc 49 >
*.nrg 3000 >
*.sexrepro 0 =
start
50 .sexrepro store
stop
cond
*.nrg 5000 >
*.sexrepro 0 =
start
50 .sexrepro store
stop
-
That brings up a good point. We have to be very careful that any mating between non plants and plants becomes a non plant, or you'll end up with a simulation of immortal bots running around, which isn't good.
-
The good news:
I've gotten sexrepro working beautifully and seemed to have found every nrg related bug it can cause.
The bad news:
Mutations [you]don't[/you][/b] spread.
The story:
Ran DB for an entire day de-bugging it in VB, every so often it'd find a bug. I figured out what was going wrong, fixed it, and it continued on it's merry way.
After the sim reached some 5,000,000 cycles(1000+ bots) I went and took a look. On the plus side no canni's, on the downside no evolution... It appears the half and half system works too well on error correction, the bots would occasionally mutate but the odds were annoyingly high against any mutant dna spreading.
Anyhow I'm working on a version of recombination that will hopefully correct this. Preferably it'd work by switching genes with the nearest neighbors something similar to how it works in real life. I'm guessing this is better than truly random mixing since several interesting/useful mutations require a linear order to have an effect.
The bugs I found during the run mainly concerned huge negative nrg values causing crashes in pain/pleas and refnrg. I borrowed the code:
If Abs(x) > 32000 Then
x = 32000 sgn(x)
To correct the problems.
I also modified the sexrepro code to allowparents to regain some of their gift nrg in cases where the child's nrg exceeds 32000.
Alrighty, gotta get going. I'll send the latest vers of 2.37.7 when I can.
Endy
-
It would be good to see if you could merge your changes into the current version Eric's working on, since I don't think that sexrepro is even activated. Eric seems a little AWOL at the moment, so I don't think he'll mind you tinkering in his code
If you like I can take a look and see if I can get my idea for recombination working in the current version. Shouldn't be too terrible.
-
Not at all, feel free to put in up to and including $0.86
My only counterpoint is this question: does it add a new ability? If it's just a segmenting of nrg, it doesn't do anything nrg by itself couldn't do. Body, for instance, is used as a way to increase power. Venom adds a new ability to the bot (venom shots). etc. etc. What does sex nrg do other than exist?
If you can think of a good reason for it to exist, then I wouldn't see any reason for it not to.
I was trying to come up with something that fitted in with the other features of the darwinbots system. If sex nrg is tracked separately as a "substance" like body, venom, slime etc. it could be transferred, shared and stolen by any of the means which are normally used for those substances, and reproduction would be linked to movement of sex nrg instead of calling an arbitrary function.
This allows the actual form the reproduction takes to be designed into genes using existing commands leading to more flexibility.
I'd say that this method does add a new ability to a bot - a bot which stores sex nrg will be able to initiate sexual reproduction. A bot which doesn't would still be able to participate, with weaker offspring because it wouldn't contribute sex nrg to the offspring's nrg total.
-
Been playing with this on and off myself. I'll agree that's its way too easy to abuse the current system.
Some issues:
I've made species of bots that keep track of the other's sexrepro location then mate only if the other's nrg contributation is higher than their own. One bot will be giving 50% and the other a miserly 1%.
Well, you should think at it in an evolutionary way. If a bot can reproduce successfully giving only 1% of its energy, its genes will spread fast. And therefore it will soon be in competition with other bots which adopt the same strategy. Two bots adopting this strategy wouldn't be able to mate (each one is looking for the other having more energy) so that eventually being able to mate with everybody becomes an advantage again. Seems to produce an ESS (evolutionary stable strategy). Anyway, that's not an issue: observing this kind of effects is precisely what alife simulators are made for.
It would be nice to know the details of such a simulation. Can you tell us more about that? Maybe the graphs of the two populations, the "good guys" and the "higher than my own" guys? (Though probably there isn't a suitable tool for doing that in DB... something to watch for the spreading of a certain portion of dna in the population... good idea...)
Anyway, in real life thing seem to go pretty much this way. Everybody's looking for a partner which he considers to be at least as fit as himself... that's why we often fall in love with people who don't love us, and that's why, as years go on, we are content with something less
BotA: I'm willing to give X nrg
BotB: Well then, I'm willing to give Y nrg
Result: Both parents agree and a baby is formed
People seem to be much less sensible than that. You're way too optimistic about life
It's also possible to ensure all your genes are carried by another bot by simply doubling your geneome.
Ie. AAbbCCddEE (with each letter representing two identical genes)
This bot will always have 1/2 of it's genome carried into the child.
Yes, very important genes could be present in the dna in multiple copies to make the bots sure that they will be present also in the offspring; but having each one of your genes present in the offspring doesn't make the offspring more fit - if those genes arent' good genes. In other words: the only plausible effect is that very important genes are duplicated to ensure their presence in the offspring.
One last problem is the geneome size mismatch problem. A SG bot can take the majority of another's dna during sexrepro. Which explains these infernal plants we wind up with...
Obviously, the result of a mating between a veg and a non-veg has to be a non veg.
-
Good points
I re-ran the sim again and it turns out to be something of a draw. The 1% bot technically won, but the offspring are actually a hybrid species of the two.
Developed this gene to counter the lack of mutation:
cond
*.sexrepro 0 =
*.nrg 5000 >
start
'Approximatly every 10 reproductions, bot mrepro's instead of sexrepro's
50 .sexrepro -10 rnd 1 add 0 floor sub store
stop
Coincidentially this is one of the transfered genes in the hybrid