Tragic Mishap’s Proteomic Coding Project

Well...rats...in the above, when you see "dynamic" simply think of my "recursive" method. I couldn't decide how best to describe it. ciphertext

So, it seems that there are two different processes we could considered for the substitution. I'll call one the "static" method, and the other the "recursive" method. In the static method, you would be generating all possible mutations of an input string up to the maximum (or ceiling) allowed number of mutations. Each iteration of mutation would use the same input string and apply any substitution rules that were already applied. Essentially, it would function a lot like a code "cracking" machine. It would attempt to "guess" the mutations possible without repeating results. Your code would need as input, the rules for substitution (e.g. "A" cannot immediately precede "G", "E" can substitute for "R"), the starting sequence, and the maximum number of mutations. This wouldn't reveal all possible combinations (if there were ones beyond the max input value), just what those combinations were. You would essentially have a list of allowed combinations. You could use that list as a "check" for the iterator. Such that if the resultant mutation already existed in the dictionary (possibly from a subsequent execution), then the iteration wouldn't count against the max value. The second method I indicated was a "dynamic" process in that the input string to be mutated was always the resultant from the previous mutation. With the obvious exception being that the system would use the starting sequence provided as input on the first iteration. The processing method wouldn't need to worry about which rules had already been applied. Depending upon your approach to rules and "meta rules" (which govern the programmatic execution of the rules) you could engage a variety of processing behaviors. For instance, you could instruct the application to be either "static" or "dynamic" in its mutation algorithm. You could also instruct the code to restrict its mutation to cycle left to right per codon or maybe by group of codons. You could indicate that you wish the program to mutate the first position only while executing the mutation in dynamic mode. Which means that all the rules (e.g. "E" can substitute for "G", "A" cannot immediately precede "G") would be stepped through for the first position only and the resultant mutation would be the input for the next mutation iteration. The "checks" could have access to the whole string to insure that the rules are applied in the event that there is a "no immediately preceding" scenario, but the substitution would be only for the first codon. In this case, you would see a listing of mutations that only mutated the first codon. Essentially, we are just developing a parser that parses a string and performs a substitution based upon some set of pre-defined rules. ciphertext

It would be easier to continue this on the forum, but for a more complicated and realistic type of code it might make a difference in the calculation. tragic mishap

Would these substitutions likely be in the form of a rule or rules (e.g. “A to G, but not to C”)?

Yes.

Regarding the “max” mutation iteration, is the goal simply to mutate the input sequence during the first iteration; and then mutate the result of the procedure each subsequent iteration?

That's a good point that I had not thought too much about, but with the simple codes I'm suggesting it should not make a difference whether the substitutions occur based on the first or subsequent iterations. I'm interested in the raw probability, and I think we would just assume that the mutations occur at different locations. If they occurred at the same location, it would be the same as reducing the mutation limit by one for each same location substitution, which already included in the calculation. tragic mishap

Regarding your program design, it sounds like you wish to provide the program with a "library" of substitutions as input. Would these substitutions likely be in the form of a rule or rules (e.g. "A to G, but not to C")? The remaining inputs would be the protein sequence that should be mutated (a string type), and then the max number of iterations the mutation process should occur. Regarding the "max" mutation iteration, is the goal simply to mutate the input sequence during the first iteration; and then mutate the result of the procedure each subsequent iteration? As an example: The input for the rules indicate that "A" can never immediately precede a "G", and a "C" can never immediately precede an "A". The input sequence to mutate is "EACRG". The max iterations is 2. So the processing would simply reorder each protein symbol (e.g. E, A, C, R) as a maximum of 2 times. Each iteration would use the results of the previous iteration as the sequence input. Iteration 1: Result = EGCRA Iteration 1: Result = ECRGA Is that what you are thinking? Or are you thinking that the rules would be that you could substitute and "R" for a "G" but not for a "C". In which case you would simply perform an actual substitution for each letter according to the rules and the resultant mutation as input for the next sequence. ciphertext

Maybe I can help you refine your requirements into a specification that can be used as a basis for a prototype. My area of expertise is in cloud application development. At the least, I could help you articulate a design/technical document that we could prototype. I think that a programmer with experience in proteomics or bioinformatics would be able to develop a better program, but I don't mind providing you with some assistance early on in your prototyping. ciphertext

Thanks for highlighting this, scordova. I have been busy with work and the REASONS conference this weekend. I have another 12-hour shift ahead of me so more detailed comments will have to wait till tomorrow. Looks like I need to pay more attention to the forum! ciphertext, I am not in the least a programmer. The "PROGRAM INPUT" was intended to convey three separate inputs: a code for which amino-acid substitutions are allowed (which was "compiled" manually from real point mutations in protein sequences), the sequence to be mutated and the maximum number of allowed mutations. The code itself is intended to be variable, that is not hard-coded into the program so it can be adjusted to achieve the result corresponding to experimental results like Axe's. tragic mishap

JGuy, you may find these related notes helpful to that video: Do centrioles generate a polar ejection force? - Wells J. - 2005 Excerpt: Centrioles consist of nine microtubule triplets arranged like the blades of a tiny turbine. Instead of viewing centrioles through the spectacles of molecular reductionism and neo-Darwinism, this hypothesis assumes that they are holistically designed to be turbines. Orthogonally oriented centriolar turbines could generate oscillations in spindle microtubules that resemble the motion produced by a laboratory vortexer. The result would be a microtubule-mediated ejection force tending to move chromosomes away from the spindle axis and the poles. http://www.ncbi.nlm.nih.gov/pubmed/15889341 The Spindle Assembly Checkpoint Mechanism and the Consequences of its Dysfunction - J. Mclatchie - Dec. 10, 2013 The spindle assembly checkpoint pathway is an elegantly engineered surveillance system for protecting the cell from the adverse consequences of improper kinetochore-microtubule attachment. Proper attachment of kinetochores to microtubules is monitored by tension-sensing and by detection of attachment of the ends of the microtubules to the kinetochores. Even a single unattached kinetochore is sufficient to trigger the wait anaphase signal, which inhibits activation of the APC that drives entry into anaphase. Impairment of the spindle assembly checkpoint pathway can result in aneuploidy, a contributor to cancer and developmental abnormalities such as Down’s syndrome. http://jmclatchie.blogspot.co.uk/2013/12/the-spindle-assembly-checkpoint.html DNA - Replication, Wrapping & Mitosis - video https://vimeo.com/33882804 bornagain77

O/T (new D.I. video): https://www.youtube.com/watch?v=NNvXTassmHM JGuy

Sounds like it would be a fun diversion. What isn't apparent from the requirements, is what are the "rules" for substitution. In your "pseudo-code" you have

PROGRAM INPUT: SEQUENCE:... CODE: ...

What is expected as program input? Should the program do any processing at all during the sequence portion? If so, what are the rules for sequencing? Or, are you saying that sequence: EGA is the program input? What functionality are you wanting to represent for code in your pseudo-code? Is that the section for which you are attempting to solicit assistance in developing? Are the values that follow the code section (e.g. EDHN, GSC, AVIT, etc...) the results of processing performed in the code section, or something other? It seems that those are the "mutations" that you are trying to derive and then use in calculation later (e.g. 3+2+3 = 8 + 1 = 9 total mutations). I think a more clear "spec" would need to be developed before you project would be capable of automation through programming. In addition, you would need to provide a mechanism to identify how mutation occurs (character substitution?) that could be replicated in computer code. You would need to delineate the operating rules (e.g. "A" could bind to "G" but not ever to "E"). Such that when the mutation (i.e. string concatenation of characters) occurred, you could insure that no incorrect bindings were generated (e.g. "AG" but not "AE"). Sounds a bit like grammar doesn't it (e.g. "i" before "e" except after "c")? ciphertext

Try contacting Gil Dodgen if you can't find anyone. This looks like it would be easy for him. JGuy