iteration counter

Case number:845833-994430
Topic:Game: Display
Opened by:Anonymous
Status:Open
Type:Bug
Opened on:Monday, January 28, 2013 - 05:32
Last modified:Thursday, February 21, 2013 - 19:51

The new main AND the new Dev Prev are still not iterating properly. And Foldit in general is sluggish, jerky and unpredictable.

The 7-segment circle around the stop sign, the "stop it" number displayed, and the actual iterations do not have anything in common. Sometimes, the iteration counter will count to 10 in less than 60 seconds, sometimes it takes over two minutes to change from 1 to 2, and sometimes it just stays at 1. Same puzzle, different puzzle, recipe, hand... it has never worked properly or reported accurately. This may or may not be the problem with some current recipe behavior, but there are currently to many variables to even make an assumption.

I have absolutely no idea how long an iteration should take. Or if a shake iteration should take more or less time than an iteration of wiggle. I have been unable to establish any kind of baseline, because I am still waiting for some "typical" behavior to manifest itself. And waiting...

I cannot for the life of me understand Foldit's refusal to roll back to a more stable version. I suggest the last non-log ci or one of the first two with log ci. You know, back when Foldit was fun. We appreciate all your hard work, but we really are tired of watching "the sausage being made". Can't you work on the bugs behind the scenes? Transparently, and let us and all the noobs who MIGHT have stayed just FOLD? Please?

I won't play, until I can recommend Foldit to my family and friends, without reservation, without apologizing in advance for it's behavior, and promising to fix "whatever it does" to their computers.
Until then:

Sincerely,
k2

(Mon, 01/28/2013 - 05:32  |  11 comments)


brow42's picture
User offline. Last seen 11 weeks 2 days ago. Offline
Joined: 09/19/2011
Groups: None

Why do you say it is wrong? Why do you think iterations were smooth and consistent at any time in the past? The only way I can think of checking is running scripts for specified iterations and recording the scores, and resetting to compare. This is why we asked for the iteration counter in the first place. Iterations are NOT consistent, they've ALWAYS been inconsistent. Without the counter, there's no way to tell if it's on iteration 1 or 100. Of all the things to complain about...

k2d2 (not verified)
k2d2's picture
Groups: None

I have a lot of respect for you. I am evidently not explaining myself well. There was a marked difference with some of the updates. I suggest it as a symptom to give a clue as to where to begin debugging. If you are not noticing any differences from update to update, I can only suggest you watch a little closer. "it" is behaving VERY differently now than when i wrote this, and "it" is also different from when it was introduced.
The efforts to improve it are much appreciated. I can see a difference...

My complaints are mainly about the exponential increase in cpu cycles it takes to run the flurry of updates we were pushed. "it" is one of the most apparent places where erratic behavior exhibited itself, and the inconsistencies are one of the hardest things to overcome for a 2-month noob trying to learn protein and Foldit. It is like taking driver's ed, one day in a Porsche, the next in a dump truck, then a sedan, then a city bus... and even that would be tolerable if one or more of the tires weren't flat on each of the updates er, vehicles. I don't think most vets Fold by hand very much, or I'm pretty sure that there would be more similar complaints.

Joined: 08/24/2011

"I don't think most vets Fold by hand very much, or I'm pretty sure that there would be more similar complaints." I think provocation is not necessary here. I mostly don't care about the iteration counter and always counted wheel turns: 3 wheel turns with no change is an iteration. This has always been rock stable in a year. But you're right on the inconsistent behavior of the counter, just don't look at it.

Joined: 09/21/2011
Groups: Void Crushers

I think the counters are correctly showing the number of iterations.
How long an iteration takes depends on a lot of factors. Puzzle type, puzzle size and more.
Shake is always very slow and it looks like being kwadratic or worse on puzzle size.
Wiggle depends also on how good the backbone is and how much clashing is there.

Joined: 06/17/2010

Provide some sample script code, I not see what you have in mind...
Shake/wigle iteration time depends on puzzle state and it can be 0.1 sec and 10 sec...

jflat06's picture
User offline. Last seen 6 days 23 hours ago. Offline
Joined: 09/29/2010
Groups: Window Group

An iteration can take drastically different amounts of time. For example, in wiggle, one iteration takes however long it takes rosetta's internal minimizer to converge to some threshold of point gain. Generally this means that at the start of a wiggle, the first iterations will take much longer, and as it settles, they'll move faster.

As brow has said, these iteration counters have always behaved this way - they just weren't displayed in the past.

Joined: 05/28/2012

I found with me that the only one i have an issue with is shake. wiggle, rebuild and all the others i can understand, but shake befuddles me with how it does iterations. i might specify one iteration in code but it might do 4-5. i think it has to do with how many accepted poses at shaking are counted. like a rebuild, it might go up in iteration for each different pose it tries, but in code it only goes up by one whenever an accepted pose is found. or so is my interpretation of the iterations for foldit.

Joined: 06/17/2010

"iterations" in shake means how many times function is looking for best pose. One iteration is finding once best pose for all/selected side chains. In 99% cases 2 or more iterations do nothing more (no change) but will try to do it and consume time. It has been described somewhere how it is working "under hood" using monte-carlo because testing all possible positions would consume astronomical amounts of time.

k2d2 (not verified)
k2d2's picture
Groups: None

Thanks. This helps a lot, still not 100% clear, but thanks for trying and caring.

Joined: 09/18/2009
Groups: SETI.Germany

To prevent trouble with that, in my scripts
I mostly override those shake/wiggle iterations by
1.: fetching score before,
2.: calling shake/wiggle only with 1 single iteration (or another small amount),
3.: checking score after this 1-iteration wiggle/shake and
4.: compare both scores
5.: and work with a score threshold.
If there is no significant change,
I don't call wiggle/shake at this point again.

But the catch is already said above:
You need a feeling for the threshold values
(separate for wiggle (bigger score changes) and shake (smaller score changes)),
as it depends on different circumstances.
Even 1 iteration can do much.

Joined: 09/18/2009
Groups: SETI.Germany

But you can't use my trick when using rebuild,
as rebuild considers more states which is has generated
if it runs through in one piece.
Calling rebuild with 1 iteration multiple times makes it behave dumb.

Sitemap

Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Amazon, Microsoft, Adobe, RosettaCommons