Mutation Protection method- in voting

[Numsgil]

It was something I did for the C++ branch.  mrepro, instead of causing reproduction, would influence mutation rates of the next .repro event.  negative values decreased mutation rates, positive numbers increased mutation rates.  I think there was a cost/benefit associated with it (negative values cost time or nrg, positive values save time or nrg).

[jknilinux]

Numsgil:
Alright, maybe that was a bad example. But anyway, you know what I mean.

Also, are you saying that .mrepro was not in the main VB DB?

Peter:
Yes, but what I was saying is that a bot could put it's whole genome inside the mutation protection instruction/codule, and therefore could protect/enhance mutation rates for the entire genome. This is what you wanted, right?

And ya, I admit, I copied and pasted as well. Rushed  

Cyberduke:
Anyway, I hope I clarified. Look here: http://en.wikipedia.org/wiki/DNA_repair#Ra...utionary_change
for a bit more info.

[Numsgil]

mrepro exists in the current version, but it works like .repro does.  The value represents the % of your resources the child gets.  I changed it so mrepro worked as a modifier to .repro instead of working independently.  But it never made it in the VB code.

[Peter]

Peter:
Yes, but what I was saying is that a bot could put it's whole genome inside the mutation protection instruction/codule, and therefore could protect/enhance mutation rates for the entire genome. This is what you wanted, right?

Well, using negative .mrepro would then only protect during reproduction. The genome after the protection instruction would be protected by all kind of mutations. So that is the only difference.

[jknilinux]

Peter:
Yes, but what I was saying is that a bot could put it's whole genome inside the mutation protection instruction/codule, and therefore could protect/enhance mutation rates for the entire genome. This is what you wanted, right?

Well, using negative .mrepro would then only protect during reproduction. The genome after the protection instruction would be protected by all kind of mutations. So that is the only difference.

Well, as far as I know, point mutations are the only mutations that do not occur during reproduction. So, point mutations should be the only difference between -x.mrepro and putting everything inside the mutation protection codule/instruction. And, as far as I know, organisms can repair point mutations as well- see here: http://en.wikipedia.org/wiki/Direct_DNA_damage
So, I still think there should be no difference.

However, maybe we should add a tiny amount of point mutations that none of the mutation protection methods, even on max setting, can protect against. This might be more realistic.  However, that would rule out certain applications of this feature, where you need 100% protection from everything.

By the way, what should we do about viruses? I think mutation protection should be hapless against protecting from viruses, but that eliminates the ability to protect the DNA from anything, which some people might want for certain cases. What do you think?

mrepro exists in the current version.

...

But it never made it in the VB code.

Do you mean it's in the current version of the C++ DB?

[Peter]

Well, as far as I know, point mutations are the only mutations that do not occur during reproduction. So, point mutations should be the only difference between -x.mrepro and putting everything inside the mutation protection codule/instruction. And, as far as I know, organisms can repair point mutations as well- see here: http://en.wikipedia.org/wiki/Direct_DNA_damage
So, I still think there should be no difference.

The .mrepro was just a little suggestion I made (took over from numsgil). I won't make a big point getting it inplemented or not. As I like Eric-idea overall better anyway. It wouldn't have an effect on the other ways trough. So it wouldn't couse any trouble if would be too implented.

However, maybe we should add a tiny amount of point mutations that none of the mutation protection methods, even on max setting, can protect against. This might be more realistic.  However, that would rule out certain applications of this feature, where you need 100% protection from everything.

Just a percentage of mutations that get through that was the original setting too, right.

You get dna-mutations anyway. Any small mistake that could ever happen in RAM and change the dna.

By the way, what should we do about viruses? I think mutation protection should be hapless against protecting from viruses, but that eliminates the ability to protect the DNA from anything, which some people might want for certain cases. What do you think?

Maybe slime..

mrepro exists in the current version.
...
But it never made it in the VB code.

Do you mean it's in the current version of the C++ DB?

Nope,

mrepro exists in the current version, but it works like .repro does. The value represents the % of your resources the child gets. I changed it so mrepro worked as a modifier to .repro instead of working independently. But it never made it in the VB code

VB .mrepro couses normal reproduction exept it creates a mutated child.
C++ .mrepro changes the mutation rate of a reproduction. This never made it in VB.

C++ is disbanded anyway trough.

[jknilinux]

However, maybe we should add a tiny amount of point mutations that none of the mutation protection methods, even on max setting, can protect against. This might be more realistic.  However, that would rule out certain applications of this feature, where you need 100% protection from everything.

Just a percentage of mutations that get through that was the original setting too, right.

You get dna-mutations anyway. Any small mistake that could ever happen in RAM and change the dna.

By the way, what should we do about viruses? I think mutation protection should be hapless against protecting from viruses, but that eliminates the ability to protect the DNA from anything, which some people might want for certain cases. What do you think?

Maybe slime..

Well, I was trying to find a way to implement what I thought you were suggesting. To be honest, I think only having the regular mutation protection without .mrepro will suffice.

You're right- slime works. I never investigated slime before... Just forget I ever asked that.

[Numsgil]

I just mentioned what I did with mrepro because it's somewhat related to what we're talking about.  I'm not trying to suggest that it's a replacement for any of the other ideas talked about; it serves a different purpose.

[jknilinux]

So, apparently we're going to implement a hybrid: Eric's instruction idea with costs, assuming the polls don't change. Although I was hoping that we would get enough votes for us to find that a statistically significant portion of the DB users wanted choice x, because with 6 votes you can't say much about what 3,000 users want, but maybe we can implement the losing ideas once we get the winner working, so it can still be fair ultimately.

I wonder why only 6 people voted... I'd appreciate criticism here...

[Peter]

So, apparently we're going to implement a hybrid: Eric's instruction idea with costs, assuming the polls don't change. Although I was hoping that we would get enough votes for us to find that a statistically significant portion of the DB users wanted choice x, because with 6 votes you can't say much about what 3,000 users want, but maybe we can implement the losing ideas once we get the winner working, so it can still be fair ultimately.

I wonder why only 6 people voted... I'd appreciate criticism here...

I would think becouse there aren't 3000 people. I think there where only a few people who visited last time. My little league-poll also has just 7 people, there aren't that much. I gues you can figure out there are only a few active on this forum.

And I think that the idea of eric is not harder implent then the others. So making more implementation of ideas would be a waste of time anyway. The list of Eric is long enough anyhow.

[jknilinux]

Hi peter,

Thanks for pointing that out. I changed the summaries in the first post now.

I once read somewhere that DB2.44 had been downloaded 3000 times, so that's where 3000 came from.

Anyway, I don't think the problem is that we have only a few people who use the forum. I mean, it's been viewed 182 times.

[bacillus]

And how many of those would have a strong opinion in this matter  

[jknilinux]

And how many of those would have a strong opinion in this matter  

    LOL- Good point  

By the way, could you explain how trying to protect the DNA more than once would cause the Mutation protection instructions to override previous attempts? If you mean that genes after the most recent Mutation protection instruction can only be in that instruction's scope, I don't see how that's a problem. This may be important, since eric's protection instruction idea is winning.

[bacillus]

It's like having code that says:
2.up store
..
5 .up store
the second command would override the first one. If multiple genes invoke .protect, only one of them will resolve at any one time, unless we are going to resolve it while reading through the DNA (which I am not too fond of). It's the same reason 0 .delgene at the end of the DNA works.
And by the way, it seems like my original idea is winning, although if I could, I'd go back and change my vote.

[jknilinux]

It's like having code that says:
2.up store
..
5 .up store
the second command would override the first one. If multiple genes invoke .protect, only one of them will resolve at any one time, unless we are going to resolve it while reading through the DNA (which I am not too fond of). It's the same reason 0 .delgene at the end of the DNA works.
And by the way, it seems like my original idea is winning, although if I could, I'd go back and change my vote.

So, if I understand you correctly, your concern is that a certain stretch of code will only be affected by the most recent mutation protection instruction. This is true of all the submissions, even metacode, and is what we wanted to begin with. It's also most like real-life biology. And why would someone want to combine/multiply/do_something_else the mutation rates if it's nested in multiple mutation protection instructions? The whole reason for putting a mutation protection instruction inside a mutation protection instruction is so that some code will not be affected by the outer mutation protection instruction. So why is this a problem?

2: Well, your original idea is winning, but it just says "make mutation protection have a cost", which is too vague to be a formal submission. Eric's idea is the only well-defined submission that's winning, so that's why eric's idea + costs is so far the winner.

By the way, what would you change your vote to? I'll factor in your new vote for when we finally decide.

Also, I know eric didn't vote, so maybe we should count in his vote as pro-eric?

Also also, I am officially abbreviating Mutation protection instruction as MPI. Tired of typing mutation protection instruction over and over...



EDIT: Announcement: The last day has been changed from Saturday to whenever Eric gets back.