Why implement metrics by a score bonus?
| Case number: | 699969-2010498 |
| Topic: | General |
| Opened by: | GuR0 |
| Status: | Open |
| Type: | Suggestion |
| Opened on: | Saturday, October 3, 2020 - 22:48 |
| Last modified: | Tuesday, October 13, 2020 - 11:33 |
Couldn't it be more usefull to have a metric.GetValue() to give players a chance to create their own goal in recipes?
I'm surprised this wasn't how it was implemented :\
I agree, it would be good (better?) to allow recipes to directly poll the value of the Metric. As it stands now, if you improve any of them significantly, but the score maybe drops by 5 points, then the changes are rejected by recipes because "Score Was Lower".
Having BOTH, then, would permit a "quick" integration with recipes, just to get them compatible.
OR the recipe could take an "involved" approach, where it could compare the prior Metric's value with the new one, in addition to the score before and after, to determine on its own if the drop in score is worth accepting. :)
I feel this as urgent for binding puzzles.
Trying to find good metrics manually is time consuming AND doesn't work well. For example, SASA is very big when the protein is merged onto the target (which is horrible). With recipes, we could try different positions of our designed protein (ending with a simple wiggle all), then calculate (our own) metrics, then try some other position etc.
We would do this early in the game in order to find a good metric. Then the normal actions would occur and metrics could be calculated from time to time in order to evaluate good scoring solutions.
When you let recipes work a full night, it's easy to result in a poor metric the day after. You have to start again using bands or other recipes. This is a waste of precious ressources.
One more suggestion to Score, subscores, bonus system and metrics
We have a "current.GetEnergyScore()" function, a "current.GetSegmentEnergyScore()" and a "current.GetSegmentEnergySubscore()". I miss a "current.GetEenergySubscore()".
But rather i would have all relevant scoring functions defined as subscores, maybe additional as "current.GetBonusSubscore()" or "current.GetMetricSubscore()" - or much better define all as "current.GetSubscore()", including the implementation in the "puzzle.GetSubscoreNames()" function.
What about Something generic like
current.GetSubscore(seg, type, measurement)
?
seg= seg number or 0
If seg = 0 then score is not related to segment (like SASA etc.)
For seg n, any non related subscore would be 0 (better than non listing in order to reduce errors)
type= Energy, sasa, bonding etc
measurement= submetric, subscore
submetric= the real measurement (like current metrics are given). The unit could be available in the wiki or elsewere. Even not knowing the unit, it's usefull for comparing solutions.
Question: I think it's better to keep the metric in it's scientific unit (like negative for Energy)
It's up to the cookers to know the right direction(minimizing or maximizing) the metric should have.
Metric would never be used for "official" scoring.
subscore= this is the subscore or bonus really used by Foldit scoring
Example:
current.GetSubscore(0, SASA, submetric)= 1250
current.GetSubscore(0, SASA, subscore)= 0
current.GetSubscore(1, SASA, submetric)= 0
current.GetSubscore(0, SASA, subscore)= 0
Possible issues:
Is it too long to compute if the cooker tries to capture all possible results?
"for i = 1 to segcount" would start with 0 (all protein), which is miselading
Hi GuR0
Thank you for the suggestion--it has been passed along to the team.