Well, verifying what you already know is certainly nice. Scientific Laws, Theories, Theorems, you name it, those are the things that make us comfortable and allow us to make predictions. And it sure feels good when it works, no doubt, but... you're not learning anything. Personally, I love those "o.O wait, that's odd..." moments, because they signal the beginning of inquiry and they bring the potential for a new discovery.
|Target||Estimate (not too bad this time)|
So, here is why I felt interested by this one:
- the MFE prediction differs completely from the SHAPE data
- the synthesized structure adopted a FMN-binding capable conformation (which I believe JR was targetting, but I'd bet he wasn't counting on it forming without FMN)
These are the two dot plots of a synthesized design in a past and unrelated switch Cloud lab (just to not name it, 'Lines' by Starryjess). The lower left triangles are distinctively different, and they should be, since they represent the MFE of the respective states.
What about the upper-right triangles?
As far as I can tell, they are identical. Right? Well, this is a little problematic, because, you see, it's just not possible. If you have the exact same sequence and the exact same partition function (dot plot), which means the exact same pairing probabilities, then you cannot get anything else but the exact same MFE structure. So how can they be different?
A few months ago, changes were made to the switch-handling code in EteRNA. The first version (1.0) had a rather sloppy algorithm, and puzzles tagged [switch] are still using this algorithm. A few players became noisy about this problem (alright, alright, yes, it was mostly me, and this is the relevant thread on GetSat), and Jee implemented changes. The first draft of the new version was buggy, and you may find a number of puzzles tagged [switch2.0] among the player-created puzzles. Then, the proper fix got the [switch2.5] tag.
Jee and I had a conversation about the topic while he was working on it. In the context of coding a puzzle-solving bot, I had encountered this problem, and I had chosen to use the available ViennaRNA APIs by using constrained foldings. But Jee insisted to go deeper in the code, and hack inside the library. And as far as I can tell, that's what he did, even though I never understood why he chose this painful path...
... until I realized (very recently) that Jee was absolutely right (in certain positions, you gotta know your shit, right?) and that my simplistic method would only allow for MFE calculations and would never give me access to a proper partition function (dot plot). In the end, I also hacked inside the ViennaRNA library. And this is what allows me to generate following dot plots.
|same as above, but different color-coding (see the discussion page of the dot plot article)|
Now, one question would be: why don't we have this in EteRNA? Since the proper hack in the library has already been done, that ought to be easy...
And another one would be: so what happened with this design? These "improved" dot plots do look fine, and they still don't explain anything...