Code center > Suggestions
Mutation Protection method- in voting
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:
--- Quote from: bacillus ---And how many of those would have a strong opinion in this matter
--- End quote ---
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:
--- Quote from: 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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version