Based on my work with my bot (and previously seen “oddities”), I believe there’s an issue in the way that EteRNA handles switches, and if I’m correct, I think it should be fixed rather sooner than later, specially now that the switch puzzlemaker is available. For this discussion, I will take an example, the recently published player puzzle, Basic Double FMN Aptamer by ribonucleic.
As can be seen, the 10-15 pair is supposed to magically disappear in the bound state. I don’t know for sure how the EteRNA engine makes its calculations, but I’m convinced that this pair would also form in the bound state.
When I feed this puzzle to my bot, the first lines of output look like this:
Meaning : for the unbound state, the bot does an unconstrained (normal) fold to get the MFE. In the bound state howewer, it does a constrained fold by forcing each base in the binding site to be as they are supposed to be, either paired (pipes) or unpaired (‘x’). The engine goes then to verify the energy delta between them, but that’s beside the point. Important is that given those calculation parameters, the MFE structure found for the bound state will always have the 10-15 pair formed, provided that it forms in the unbound state. Which makes this puzzle unsolvable for my bot. And I believe that it should be considered as such in its present state.
Now the argument is simply about who’s right. Which is the proper way to handle switches ? I think the method I implemented in my bot is the proper one. If not, I’d like to be proven wrong.
Eterna handles switch as following. In unbound state, simple unconstrained fold. In bound state in compares MFE of unconstrained fold, and that of constrained fold [in the target structure] + binding bonus, and take the one with smaller MFE. [This allows some puzzles to bypass the target structure like the 10-15 pair case you mentioned]
It is indeed incomplete calculation and for the complete optimization binding sites has to be checked internally in ViennaRNA’s dynamic programming This is bit tricky as we cannot use ViennaRNA’s structure constraint. [The binding site should only give bonus as a whole, but the structure constraint applies penalties on each bases]
That’s the part we are currently working on, and it’ll be followed up by the new synthesis results viewer interface.
Hmm, I’m not as familiar with Vienna’s code as you probably are. I do understand what you’re saying about binding site treated as a whole, but I’m not completely following the part where Vienna’s structure constraints mechanism cannot be used directly because of penalties applied to bases. I guess I will have to dissect Vienna’s related code…
This said, I still feel that my method gives more coherent results than the current one.
But thanks already for the explanations, much appreciated.
There’s been apparently quite a few changes in the algorithm, some switches marked 2.0, others 2.5… It’s not quite clear what’s been done and what are the differences…
Considering the latest version, 2.5, I’m still fuzzy about its validity. I hope bigbloto won’t hate me too much, but for the sake of the demonstration, I need to spoil the solution to one of his small 3-states puzzles.
This is the 3rd state of my solution to http://eterna.cmu.edu/game/puzzle/234…. Free energy without bonus is +2.6 kcal, but did you notice the “oddity” ? Wouldn’t this Uracil want to pair with that Adenine by any chance ?
The 2.0 version accidently used the old “HACK” version (1.0). The 2.5 version is th e one that integrated the binding bonus within the dynamic programming itself.
However, the 2.5 version is supposed to work only on the “internal loops” for now. We have restricted the Puzzle maker to only allow binding site at the internal loops, but it seems like few players found a bug to specify the binding site somewhere else. The puzzle in your example is one of them. It has binding site in the hairpin.
When the binding site is not an internal loop, the game automatically falls back to 1.0 HACK version, not fully optimizing the “bound state” as in you example. [it should have had AU paired[.
In short, what you saw was all the work of 1.0 HACK version, due to the bug in the puzzle maker. The new folding engine only works with 2.5 version with binding site in the internal loops. Sorry about all the confusion
Thanks for the clarification, and please, no apologies, we perfectly understand that you guys are busy with other more urgent things. By the way, thanks and kudos to the whole dev team
