Darwinbots Forum

Code center => Darwinbots3 => Topic started by: jknilinux on September 30, 2008, 09:06:58 PM

Title: Mutation protection
Post by: jknilinux on September 30, 2008, 09:06:58 PM
Hi,

I just noticed that, whenever there is a mutation in real-life organism, it almost never occurs in a vital area, like a metabolic pathway, even though such vital areas make up most of our DNA. Therefore, most organisms must have some sort of mutation protection for their vital genes. So, for DB3, or maybe even the next version of DB2 (since it should be an easy change), we should add a feature where a coder can select which portions of the bot's DNA are vital for life, like the reproduction code, and those portions will be, say, ten times less likely to get a mutation. That way, we will never have to deal with something "evolving" until it's unable to eat. What do you think?
Title: Mutation protection
Post by: EricL on September 30, 2008, 09:14:46 PM
I love this idea.  I have loved this idea for years.  My very first DB post in the Newbie forum years ago was on this subject.

I favor a scheme where DNA can be decorated in some fashion, perhaps with in-line commands that increment or decrement the mutation probability for subsequent base pairs.  I would love to see a concrete and specific suggestion along these lines in the Suggestions forum and would give such high priority for implementation.  Such a discussion may already exist in fact if memory serves.  There has been much discussion on this subject in the past.
Title: Mutation protection
Post by: Numsgil on September 30, 2008, 09:23:26 PM
My thinking for this is that Codules (essentially equivalent to functions in other languages) would have mutation multipliers assigned to them.  I might assign a cost (in nrg or time) during reproduction based on a composite mutation rate, but I'm not sure if that part mirrors real life properly.
Title: Mutation protection
Post by: EricL on September 30, 2008, 09:32:32 PM
I favor an approach that is not tied to gene structure in any way such that any part of a gene, multiple genes, parts there of or any other sequence including non-coding sequences can be so decorated.  Hence my in-line suggestion in which the multiplier/de-multiplier itself is in fact a base pair.  In this way the mutation multiplier/de-multiplier itself can be subject to mutation and protected or increased mutation probability through its own decoration.
Title: Mutation protection
Post by: Numsgil on September 30, 2008, 10:25:30 PM
I'm just not a fan of decorating the DNA stream with no-ops.  It's one thing for the text representation of the DNA to have that stuff done inline, but the final representation in code should not have metadata buried in with the base pairs, IMO.  I just don't like it.  Metadata should sit on top of the base pairs, in the same way that regulatory proteins sit on top of the DNA instead of inline with it.
Title: Mutation protection
Post by: bacillus on October 01, 2008, 07:16:24 PM
I think that, in real life as well as DB, these mutations are seldom seen because they are vital, eg. a bot that evolves a cancerous trait or can't feed anymore will, quite naturally, cease to exist in quite a short time frame.
Title: Mutation protection
Post by: EricL on October 01, 2008, 07:41:54 PM
Quote from: bacillus
I think that, in real life as well as DB, these mutations are seldom seen because they are vital, eg. a bot that evolves a cancerous trait or can't feed anymore will, quite naturally, cease to exist in quite a short time frame.
Actually, you see it all over in nature.  It's one of the causes of codon bias and long repeat sequences.   I.e. Selection has favored coding of our DNA (in conjunction with replication machinery) in a specific way using specific codons and sequences over other synonymous codons and sequences, which by their very nature encode meta-data influencing the mutation probability of those sequences.  Many evolutionary biologists think that a large percentage of all mutations may be self-directed in this way by the genome.
Title: Mutation protection
Post by: jknilinux on October 05, 2008, 09:38:17 PM
So, why don't we add this feature? Everyone here seems to be for it.
Title: Mutation protection
Post by: Numsgil on October 05, 2008, 10:06:31 PM
It's mostly a question of "how".  There are lots of different ways of doing it, but arriving at a way that pleases everyone has been difficult.
Title: Mutation protection
Post by: bacillus on October 05, 2008, 11:41:29 PM
Quote from: EricL
Quote from: bacillus
I think that, in real life as well as DB, these mutations are seldom seen because they are vital, eg. a bot that evolves a cancerous trait or can't feed anymore will, quite naturally, cease to exist in quite a short time frame.
Actually, you see it all over in nature.  It's one of the causes of codon bias and long repeat sequences.   I.e. Selection has favored coding of our DNA (in conjunction with replication machinery) in a specific way using specific codons and sequences over other synonymous codons and sequences, which by their very nature encode meta-data influencing the mutation probability of those sequences.  Many evolutionary biologists think that a large percentage of all mutations may be self-directed in this way by the genome.
Oh, yeah, I remember reading something like that. "DNA for programmers aka. If you're a hammer, everything looks like a nail" or something like that.

Quote from: Numsgil
It's mostly a question of "how".  There are lots of different ways of doing it, but arriving at a way that pleases everyone has been difficult.
A good method to do this would be to create a sort of secondary DNA exempt from mutations, or using secondary mutation rates. Regular DNA is transferred to this using a command, sort of like creating an internal virus.
Title: Mutation protection
Post by: jknilinux on October 06, 2008, 05:15:19 PM
Quote from: Numsgil
It's mostly a question of "how".  There are lots of different ways of doing it, but arriving at a way that pleases everyone has been difficult.

Well, I like Ericl's idea of having the mutation rate of different sections being encoded in the DNA. This is the closest we have to real life, instead of having the first 50 BPs being magically un-mutatable, or something.

I'm afraid I might be misunderstanding Numsgil's counterargument, though. Are you saying we shouldn't have metadata in the DNA because of aesthetic reasons?


Anyway, I think that it doesn't really matter which implementation we choose right now. Having any implementation whatsoever should be enough to help evolution drastically.
If there's a big controversy on the subject, then let's just do the simplest implementation, and add the features later that can please everyone.  
Title: Mutation protection
Post by: Numsgil on October 06, 2008, 05:48:41 PM
Quote from: jknilinux
Quote from: Numsgil
It's mostly a question of "how".  There are lots of different ways of doing it, but arriving at a way that pleases everyone has been difficult.

Well, I like Ericl's idea of having the mutation rate of different sections being encoded in the DNA. This is the closest we have to real life, instead of having the first 50 BPs being magically un-mutatable, or something.

I'm afraid I might be misunderstanding Numsgil's counterargument, though. Are you saying we shouldn't have metadata in the DNA because of aesthetic reasons?

It has to do with how I think DNA should be understoood.  In it's purest form I like to think of it as just a string of beads.  The DNA parser starts at the top of the bead string and reads to the end.  Fairly standard.  But what happens when you want to do some mutations or operations on the bead string?  Local mutations are pretty standard and easy to understand, but what about things like splicing two bead strings together?  Or removing a long section of beads?  Or inserting random garbage into the bead string.  Or having a virus insert viral material in to the bead string?

There are two options: 1.  A formal structure needs to be imposed on the beads (you must have a red bead after a blue bead before you can have another blue bead) to keep it in a consistant state.  This is how Darwinbots started.  There are still some relics from this line of thought in how viruses are constructed and inserted.  2.  No formal structure is assumed, and any bead can follow any bead and be a valid bead string.  This is appealing to me, at least, because when something like a zerobot evolves the ability to eat and move and reproduce, it's closer to a truely ex nihilo source instead of being a consequence of simulator provided structure.

But this second methodology breaks down if metadata (by which I mean tags that describe the DNA itself, such as changing the mutation rate for some basepairs or, if we had diploid DNA, changing the dominance/recessiveness of a gene) is itself actually a bead.  It might be that after a few splices the tag that identifies a change in mutation rate is now modifying entirely different DNA.  Which entirely defeates the purpose if you're a bot author and your goal is to make the reproduction gene, or whatever, non mutable.

Instead, there are two solutions that could work well.  The easiest is to give each bp a mutation multiplier.  The hard part is presenting it to the bot writer in a way that isn't confusing.  Another way is to find a natural logical grouping of DNA and have mutation probabilities work on that level.  Which is why I suggest it can work as part of codules.  It's different from the imposed structure of the original program, since an individual codule can contain any DNA combonation and still be valid, and codules can be arranged in any call structure imaginable and still be valid.

I realize the reasoning is a bit weak, but it's hard for me to communicate the reasoning.  It's just a gut feeling.
Title: Mutation protection
Post by: Peksa on October 08, 2008, 04:26:04 PM
how about a new sysvar? 10 .protect store would protect next 10 bps from mutations, either  from 90%, 95%, 100% or some other pre-set percantage of mutations. Both 10 and .protect would be suspectible to mutations. No meta DNA and simple enough. It would be pain to count the bps from programmers point of view but I think it would do well in evolved DNA.
Title: Mutation protection
Post by: bacillus on October 08, 2008, 07:08:06 PM
Would that decrease the total likelihood of mutations, or just shove the extra probability onto the rest of the DNA code?
Title: Mutation protection
Post by: jknilinux on October 09, 2008, 02:00:30 AM
Peksa,

As far as I know, that example you gave IS metadata. This is basically what Ericl and I were for, but Numsgil noted that if the mutation protection is itself mutatable, then it is of no use to the coder to keep a certain stretch of DNA from mutating.

Numsgil,

Quote from: Numsgil
Another way is to find a natural logical grouping of DNA and have mutation probabilities work on that level.  Which is why I suggest it can work as part of codules.  It's different from the imposed structure of the original program, since an individual codule can contain any DNA combonation and still be valid, and codules can be arranged in any call structure imaginable and still be valid.

Would you mind explaining your codule method in greater detail? It sounds interesting.



---

Everyone:

Perhaps we should just implement the easiest one to code for now, and try to please everyone later? I think that this is a very important feature, and if we just start with a single crude implementation now, then maybe it will be perfected soon. Otherwise, I'm afraid it will get caught up in an endless debate on exact implementation, and will remain unimplemented forever, just like it has since Ericl made his first newb post on the subject so long ago.
Title: Mutation protection
Post by: Numsgil on October 09, 2008, 02:10:50 AM
Right, doing something like 10 .protect store is what I'm against.  You want that data attached to the actual base pairs instead of floating around in the DNA. (Though I do think using negative numbers in .mrepro to lower mutations during reproduction (higher cost?) would be cool).

Codules are essentially functions, except that they can't recurse (call themselves or anything that called them) and they operate on the stack instead of using arguments.  In their most abstract, they're essentially macros that you can use as custom commands, and are subject to mutation.  They can contain any (or none I suppose) DNA, from multiple genes to a single number, so they would provide a natural way of grouping like base pairs together, and it's on that level I think mutation multipliers should live.  I think Eric believes this is not fine enough control, and differing mutation probabilities are needed even within codules, should they be implemented.
Title: Mutation protection
Post by: jknilinux on October 09, 2008, 11:47:22 AM
Quote from: Numsgil
...

But this second methodology breaks down if metadata (by which I mean tags that describe the DNA itself, such as changing the mutation rate for some basepairs or, if we had diploid DNA, changing the dominance/recessiveness of a gene) is itself actually a bead. It might be that after a few splices the tag that identifies a change in mutation rate is now modifying entirely different DNA. Which entirely defeates the purpose if you're a bot author and your goal is to make the reproduction gene, or whatever, non mutable.

...

Codules are essentially functions, except that they can't recurse (call themselves or anything that called them) and they operate on the stack instead of using arguments.  In their most abstract, they're essentially macros that you can use as custom commands, and are subject to mutation.  They can contain any (or none I suppose) DNA, from multiple genes to a single number, so they would provide a natural way of grouping like base pairs together, and it's on that level I think mutation multipliers should live.  I think Eric believes this is not fine enough control, and differing mutation probabilities are needed even within codules, should they be implemented.


Well, if I understood your argument against metadata correctly, you think that it would be useless to the coder if the mutation protection is itself mutatable, since it could easily be mutated to protect a different stretch of DNA, etc... However, if the mutation protection instruction could protect itself from mutations by having more than one argument, then this could be easily circumvented. For example:

10 5 5 .protect store

could mean "protect next 10 bps by giving them a 5% mutation rate, and give self a 5% mutation rate." Thus, it protects itself and can therefore be useful for protecting the coder's DNA.

In essence, your codule idea just sounds like

10 5 0 .protect store

Or "protect next 10 bps by giving them a 5% mutation rate, and give self a 0% mutation rate." In which case, the mutation protection is impossible to move or change, just like a codule.

I think this design is more flexible, since it can actually protect DNA in the long run, like you wanted, and it can be moved, added, or deleted through mutation, like what Eric and I wanted. It's all up to the coder.

---

NOTE: I've never written DBcode before, so don't laugh if I'm not allowed to have three arguments for a command. There are ways to circumvent this and use only one argument.
Title: Mutation protection
Post by: bacillus on October 09, 2008, 11:04:32 PM
I don't like the idea of changing the rate of mutation too much; if anything, it should be treated like internal slime eg. higher protection lasts for a less period of time, and wears down in relation to the amount of protection offered, and the amount of DNA protected. Maybe have something like X .mkenzyme store and Y .protect store, where Y is the amount of base pairs relative to the position of the current base pair to be protected, so that -10 .protect store will protect the previous 10 bps, while 10 .protect store protects the next 10 bps.
Title: Mutation protection
Post by: jknilinux on October 10, 2008, 01:05:22 PM
Quote from: bacillus
I don't like the idea of changing the rate of mutation too much; if anything, it should be treated like internal slime eg. higher protection lasts for a less period of time, and wears down in relation to the amount of protection offered, and the amount of DNA protected.

But that's nothing like real-world Biology. An organism doesn't get increased mutation rates after it lives a long time. Photosynthesis doesn't wear down if a tree lives for a thousand years, because an organism's mutation rate is not dependant on time, amount of DNA, or anything else.

---

Numsgil:

By the way, if Metadata wasn't coded for inside the DNA in a real organism, where would it be stored?

Title: Mutation protection
Post by: Numsgil on October 10, 2008, 01:29:37 PM
It's either a property of the codon itself, (multiple codons, with different possible mutation probabilities, might code for the same amino acid), or it might be regulated by a regulatory protein which sits on the strand of DNA itself, like a glob of clay stuck on my string of beads analogy.
Title: Mutation protection
Post by: jknilinux on October 10, 2008, 01:39:15 PM
Quote from: Numsgil
It's either a property of the codon itself, (multiple codons, with different possible mutation probabilities, might code for the same amino acid), or it might be regulated by a regulatory protein which sits on the strand of DNA itself, like a glob of clay stuck on my string of beads analogy.

Either way, the DNA still governs it's own mutation rate. Having an exon make a protein to protect another peice of DNA by sitting on it is just like saying

x .protect10 store

Or "protect the next X bases by giving them a 10% mutation rate". Whether it's done through proteins or not doesn't matter. Ultimately, in real biology, the DNA is protecting itself, and therefore does contain metadata.
Title: Mutation protection
Post by: Numsgil on October 10, 2008, 01:57:34 PM
No, it's quite different.  That protein might have come from anywhere in the genome.  It get's created, floats around a bit, finds its target, and latches on.  If its target moves, so does it.  If its target doesn't exist, it doesn't bind.  If there are multiple targets, multiple proteins may or may not bind to the site.  The protein may be encoded somewhere in the DNA, so in that regard you're right that the DNA includes it somewhere in itself, and thus regulates itself, but the actual mechanism is not embedded next to thing it wants to protect, which is my point.

Mind you this idea (that organisms can control their mutation rates voluntarily) are new in biological thinking.  They're not quite as dogmatic as some of the more central tenants of evolutionary theory.
Title: Mutation protection
Post by: jknilinux on October 10, 2008, 03:06:17 PM
Quote from: Numsgil
No, it's quite different.  That protein might have come from anywhere in the genome.  It get's created, floats around a bit, finds its target, and latches on.  If its target moves, so does it.  If its target doesn't exist, it doesn't bind.  If there are multiple targets, multiple proteins may or may not bind to the site.  The protein may be encoded somewhere in the DNA, so in that regard you're right that the DNA includes it somewhere in itself, and thus regulates itself, but the actual mechanism is not embedded next to thing it wants to protect, which is my point.

Mind you this idea (that organisms can control their mutation rates voluntarily) are new in biological thinking.  They're not quite as dogmatic as some of the more central tenants of evolutionary theory.

I see your point. However, it sounds like it would be difficult to implement and difficult for evolution to take advantage of (since each "protect codule1" instruction must tie to a certain "codule1" exon, etc...).

How about having the protection instruction that Eric and I were talking about act like a protein, so it can be "glued" to the exon? That way, if one instruction in the exon moves, then the entire codule (including the mutation protection "protein" instruction) moves. You could also have multiple mutation protection protein instructions (MPPIs) for the same codule, like having

10 .protect5 store
9 .protect50 store

in which case the two MPPIs could "compete" for protecting the next exon within the next nine/ten lines***, just like how you said two or more proteins could be assigned the same exon to protect. Here, maybe one of the mutation rates could be randomly chosen out of the two, because the other MPPI couldn't bind to the exon before the first one did.

Or, the 9 .protect50 store could apply it's mutation rate to only the next nine bps, but let the 10 .protect5 store govern it's (the 9 .protect50 store's) mutation rate. This way, you can never 100% protect a certain exon (since even a 10 .protect0 store is subject to the outside mutation rate, so it could change to 10 .protect200 store) but you can get really close, just like real biology.

The only problem with this idea is that the protected exon must be directly behind the MPPI, like Numsgil pointed out. However, since the MPPI acts like a protein (it's basically an exon that makes a protein that attaches to the parent exon and the next x bps), this is still just like real-world biology. Besides, the fact that the MPPI is right before the exon it protects is not a big deal. Why make code somewhere else that protects code at another place? This does the same thing, evolutionarily speaking. Also, come to think of it, having code at one place protect code at another place sounds like a DB version of goto. Nesting them is a debuggers' nightmare.

Just one instruction, so it's easy to implement and easy for evolution (and coders) to use, but it also has most of the features Numsgil wanted (like binding specifically to one exon, and binding-site competition).
Plus, it can decrease or increase mutation rates, like by having 10 .protect200 store, which would double the mutation rate for the next 10 bps.

Everyone happy?

***- With this method, an MPPI could protect lines of code not directly behind it.
Title: Mutation protection
Post by: Numsgil on October 10, 2008, 03:38:42 PM
I don't like the idea of any sysvar or command influencing mutation rates (of a subset of the DNA anyway).  Having it use the stack and sysvars is not an improvement over just using a command.

What I'm thinking, in the short term, is something like this:

Code: [Select]
[x0]
cond
*.nrg 5000 >
start
50 .repro store
stop
[/x0]

The [] tags would let you specify meta data, that applies for all base pairs until you find the matching closing [/] tags.  (In this example, the x specifies a mutation multiplier, with 0 meaning mutation rates for this section get multiplied by 0).  It would get "compiled" into something like this:

Code: [Select]
(type: flow logic) (value: 1) (mutation multiplier: 0)
(type: sysvar) (value: 236 (or whatever .nrg is)) (mutation multiplier: 0)
etc.
etc.

That is, right now the DNA is stored in memory as a pair of numbers: one describes the type, the other describes what it actually is (cond, start, stop, else share a type but have different values).  To that tuple I would add a float that describes a mutation multiplier.  It defaults to 1.0, but can be modified by special tags.  If we really want, we could have these multipliers subject to mutations as well.  I'm not sure I like the idea (it would get really messy with evolved DNA), but I wouldn't be against it either.

It's not what I'll probably do for DB3, but I think it addresses both Eric and my concerns, with the added benefit that it can be done right now.  Not sure if it addresses your concerns, though.
Title: Mutation protection
Post by: bacillus on October 10, 2008, 05:14:06 PM
Quote from: jknilinux
Quote from: bacillus
I don't like the idea of changing the rate of mutation too much; if anything, it should be treated like internal slime eg. higher protection lasts for a less period of time, and wears down in relation to the amount of protection offered, and the amount of DNA protected.

But that's nothing like real-world Biology. An organism doesn't get increased mutation rates after it lives a long time. Photosynthesis doesn't wear down if a tree lives for a thousand years, because an organism's mutation rate is not dependant on time, amount of DNA, or anything else.

Actually, more than you think. Internally, DNA is tended to by having enzymes which 'remember' certain assigned parts of DNA; if an error is found in these, eg. the sequence doesn't match, it is replaced by the version the enzyme is carrying. This doesn't mean that DNA is immutable though, the backup copy can always mutate. More protection simple means more backups.
Title: Mutation protection
Post by: jknilinux on October 11, 2008, 12:05:34 AM
Quote from: Numsgil
I don't like the idea of any sysvar or command influencing mutation rates (of a subset of the DNA anyway).  Having it use the stack and sysvars is not an improvement over just using a command.

What I'm thinking, in the short term, is something like this:

Code: [Select]
[x0]
cond
*.nrg 5000 >
start
50 .repro store
stop
[/x0]

The [] tags would let you specify meta data, that applies for all base pairs until you find the matching closing [/] tags.  (In this example, the x specifies a mutation multiplier, with 0 meaning mutation rates for this section get multiplied by 0).  It would get "compiled" into something like this:

Code: [Select]
(type: flow logic) (value: 1) (mutation multiplier: 0)
(type: sysvar) (value: 236 (or whatever .nrg is)) (mutation multiplier: 0)
etc.
etc.

That is, right now the DNA is stored in memory as a pair of numbers: one describes the type, the other describes what it actually is (cond, start, stop, else share a type but have different values).  To that tuple I would add a float that describes a mutation multiplier.  It defaults to 1.0, but can be modified by special tags.  If we really want, we could have these multipliers subject to mutations as well.  I'm not sure I like the idea (it would get really messy with evolved DNA), but I wouldn't be against it either.

It's not what I'll probably do for DB3, but I think it addresses both Eric and my concerns, with the added benefit that it can be done right now.  Not sure if it addresses your concerns, though.

Well, if it's true that everyone else likes this idea, then I like this idea. Like I said, I think the most important thing is to get it coded. Once we've done that, then we can add features to make everyone happy. I would hate for this feature to go the way of Duke Nukem Forever.

EDIT: So, everyone, which method for Mutation Protection are you in favor of?

1: Numsgil's idea of having codules of the form "[xmutation_rate] ...protected BPs... [/xmutation_rate]"

2: Ericl's idea of having a new instruction, of the form "number_of_lines_to_protect .protect store"

3: A hybrid idea, like my MPPI instruction (Feel free to add another, but I'm not aware of any)

4: Something totally different

TELL US WHAT YOU THINK [a href=\'index.php?showtopic=2947\']HERE![/a]



I think the most important problem with this idea is that evolution will have a hard time taking advantage of it, since it seems more delicate than "10 .protectx store".
And besides, I don't see anything this can do that 10 .protectx store can't, or vise-versa. So, if they're equivalent, why not implement the easier one? See below.

Quote from: Numsgil
But this second methodology breaks down if metadata (by which I mean tags that describe the DNA itself, such as changing the mutation rate for some basepairs or, if we had diploid DNA, changing the dominance/recessiveness of a gene) is itself actually a bead.

Sorry for bringing up an old post, but why would having metadata in the DNA break the second methodology? If you're afraid the Mutation Protection instruction will get separated from it's exon, then just "glue" it there, like in my MPPI-based idea above.

But, like I said, if everyone else likes this idea, I like it.

Maybe I'm just too tired to think clearly about it!  




Bacillus-
In that case, it's only dependent on the cell having, like, 5 ATP per month, to run that enzyme whenever a stray UV ray hits that DNA. I think that's negligible.
Besides, in relation to your original comment:

Quote
I don't like the idea of changing the rate of mutation too much. If anything...

The rate of mutation can change quite quickly in a population. For example, if memory serves me correctly, the average mutation rate in a bacteria culture will go up as the amount of food decreases, since the bacteria have "evolved to evolve" to find new food sources.
Title: Mutation protection
Post by: Numsgil on October 11, 2008, 12:39:23 AM
Quote from: jknilinux
Quote from: Numsgil
But this second methodology breaks down if metadata (by which I mean tags that describe the DNA itself, such as changing the mutation rate for some basepairs or, if we had diploid DNA, changing the dominance/recessiveness of a gene) is itself actually a bead.

Sorry for bringing up an old post, but why would having metadata in the DNA break the second methodology? If you're afraid the Mutation Protection instruction will get separated from it's exon, then just "glue" it there, like in my MPPI-based idea above.

But, like I said, if everyone else likes this idea, I like it.

Maybe I'm just too tired to think clearly about it!  

I have no idea   I've been a bit burned out lately, and my mind's felt like mush trying to work through anything left brain, so the reasoning might be full of holes.
Title: Mutation protection
Post by: ikke on October 11, 2008, 03:19:50 AM
Maybe I'm the outcast here, but I am not in favour of coding mutation rates. To me there two ways to mutaton protection: evolve it or program copy protection. In my evo sims the most fatal mutation I can track with the graphs is a breakdown of the reproduce condition, resulting in exploding population, and certain death of all the offspring (I use kilobody nrg with low energy levels, so a veggie needs a minimum body size to survive). I have seen strains evolve that don't break down explosively but bubble at regular intervals. Also I noticed that the explosions occur less and less often. With my current zerobot evolution I haven't seen this behaviour alltogether, which says something about the strenght of natural vs manmade code. I would be sad to see this gone by creationist intervention.

As for coding copy protection I would favour a command that allows for checking gene equality. A but has two copies of a gene and checks for equality. Or a gene has a a stored vs actual hashvalue, whatever. Die on inequality, or maybe even allow repairing if genes are identified as defects and the coder is smart enough to program the bot to figure out how to tget back to normal...
Title: Mutation protection
Post by: jknilinux on October 11, 2008, 03:58:23 AM
Quote from: ikke
Maybe I'm the outcast here, but I am not in favour of coding mutation rates. To me there two ways to mutaton protection: evolve it or program copy protection. In my evo sims the most fatal mutation I can track with the graphs is a breakdown of the reproduce condition, resulting in exploding population, and certain death of all the offspring (I use kilobody nrg with low energy levels, so a veggie needs a minimum body size to survive). I have seen strains evolve that don't break down explosively but bubble at regular intervals. Also I noticed that the explosions occur less and less often. With my current zerobot evolution I haven't seen this behaviour alltogether, which says something about the strenght of natural vs manmade code. I would be sad to see this gone by creationist intervention.

As for coding copy protection I would favour a command that allows for checking gene equality. A but has two copies of a gene and checks for equality. Or a gene has a a stored vs actual hashvalue, whatever. Die on inequality, or maybe even allow repairing if genes are identified as defects and the coder is smart enough to program the bot to figure out how to tget back to normal...

Your copy protection just sounds like a universal halved mutation rate for that species, assuming every gene has a duplicate error-checker version.
If you want only some genes to have copies, then it's basically regular mutation protection only for those certain genes, but you're limiting the mutation protection to either the regular mutation rate or 1/2 the regular mutation rate, if I understand you correctly.

Also, this will be an added feature, not a requirement, so you could easily continue your evolved mutation protection sims by simply switching the feature off.

Thanks for the input, and let me know if I missed something.
Title: Mutation protection
Post by: jknilinux on October 11, 2008, 04:44:39 AM
I'm sending this topic over [a href=\'index.php?showtopic=2947\']here[/a], mainly so I could add a poll, but also because it's more of a suggestion for DB2 than DB3. Sorry for any inconvenience!
Title: Mutation protection
Post by: ikke on October 11, 2008, 04:40:18 PM
Quote from: jknilinux
Your copy protection just sounds like a universal halved mutation rate for that species, assuming every gene has a duplicate error-checker version.
If you want only some genes to have copies, then it's basically regular mutation protection only for those certain genes, but you're limiting the mutation protection to either the regular mutation rate or 1/2 the regular mutation rate, if I understand you correctly.
This may be the effect of the method I described, but it was not the point I was trying to make. In essence I believe that mutation protection should be a part of the genome of the species, not some magic outside it. While I sympathise with your goal I do not like the way you want to achieve it. To me it seems you are proposing a magical shield against mutations. As said I would like to see mutation protection seated within the genome. Properly defined base pairs with the combined ability to protect against mutation may surprise us by recombining into new functions in a way magic will never.
Title: Mutation protection
Post by: jknilinux on October 11, 2008, 09:13:23 PM
Quote from: ikke
Quote from: jknilinux
Your copy protection just sounds like a universal halved mutation rate for that species, assuming every gene has a duplicate error-checker version.
If you want only some genes to have copies, then it's basically regular mutation protection only for those certain genes, but you're limiting the mutation protection to either the regular mutation rate or 1/2 the regular mutation rate, if I understand you correctly.
This may be the effect of the method I described, but it was not the point I was trying to make. In essence I believe that mutation protection should be a part of the genome of the species, not some magic outside it. While I sympathise with your goal I do not like the way you want to achieve it. To me it seems you are proposing a magical shield against mutations. As said I would like to see mutation protection seated within the genome. Properly defined base pairs with the combined ability to protect against mutation may surprise us by recombining into new functions in a way magic will never.

DB has tons of "magic" in it, simply because we're simulating this on old PCs and it would be impractical to simulate every RNA, protein, and phospholipid in a real cell. That's why movement, for example, works magically, instead of simulating actual flagella, even though simulating them would allow for evolution to modify them in neat ways. So, I think we should try to port as many features from real biology in to DB as completely as possible, and one of these features is having the mutation rate as an analog gradient, which is not possible in your implementation.

However, you do have a good point, so I'll add it to the poll. Thanks!
Title: Mutation protection
Post by: d-EVO on December 08, 2008, 12:47:50 PM
how about seting the mutation details bor certain parts of the DNA as pre script to the actual code.

this will be optional and not run in the actual dna.
eg

defmr 95 36 50

95 is the chance of the mutation (measured in percent or somthing like that) and 36 to 50 is the position in the dna it protects.

what do you think?