[NewChapter] some data

Case number:699969-996695
Topic:General
Opened by:bob1928
Status:Open
Type:Suggestion
Opened on:Saturday, January 18, 2014 - 19:07
Last modified:Saturday, January 18, 2014 - 21:46

Susume posed the question as what difference there might be in 10 calls of structure.WiggleAll(2) vs 1 call of structure.WiggleAll(20) in NewChapter. This thread attempts some initial effort at an answer.

The spider toxin puzzle was used (being deliciously small). Scores and times were recorded for various combinations of 64 total wiggles (32 calls of wig(2) through 1 call of wig(64); 6 combinations). Within each set of combinations, the same starting point was used. Three of these sets were run starting from puzzle reset, "somewhat settled", and from having been wiggled 250 times at CI=0.5 from that same "somewhat settled" state.

Results are presented graphically in the next few posts. The x-axis is the net number of wiggles (32 of wiggle(2) is 64, as is 8 of wiggle(8), etc). The time plots come from reads of os.time() which only has resolution of 1 sec. leading to some choppiness.

The start from reset case also included a zoom in after the initial jump.

AttachmentSize
reset1.PNG15.66 KB
reset2.PNG16.18 KB
resettime.PNG15.17 KB
(Sat, 01/18/2014 - 19:07  |  2 comments)


bob1928's picture
User offline. Last seen 1 year 5 weeks ago. Offline
Joined: 12/16/2012
Groups: Gargleblasters

Now starting from 'somewhat settled'.

And from crunch with CI=0.5.

It appears the gains depend mostly on how many net wiggles are made and very little on whether done with lots of calls with few iterations or vice versa.

Time results are tougher to summarize. The calls to wig(2) from reset, while weird, are probably not of consequence since this is only done once per attempt. The slopes appear pretty constant.

More work is in progress. Feedback and suggestions are ... un-preventable ;-)

bob1928's picture
User offline. Last seen 1 year 5 weeks ago. Offline
Joined: 12/16/2012
Groups: Gargleblasters

Different Test: incorporated a "threshold wiggle" into DRW+Compress and collected data on how many calls to structure.Wiggle{All}{Selected}(2) were needed to reach a given level of stability.

Initial results with not-so-good choice of cases, but a learning step.

In Timo's wisdom the calls to the native wiggle function are not scattered all over, but contained in a single 'wrapper' function. This makes the modifications fairly simple. I added an 'inner wrapper' to make the test and collect the data.

DRW+Compress was run on lengths 3-5, on NC Spider Toxin, 5 slots, about 3 hrs. Two clients were run. The first with a 'stuck' version of the puzzle (score 8391,zero overall gains in the run) using a 0.05 threshold. The second on a loose version gaining from 7198 to 7855 using a 0.1 threshold. Not a great choice to compare because two things change: threshold and puzzle state, but a start.

The first graphic is a histogram of how many calls of wiggle(2) were needed to reach stability. The second cumulative probability of N or less calls to reach stability. Threshold 0.1 most often finishes in 3-4 calls (6-8 net wiggles), threshold=0.05 takes more calls (not big surprise). Call counts were kept up to 40, the 41st bin is any number of calls over 40 and less than 100. There were some instances taking 100 calls in both runs.

Hope do more runs. These do tie up clients quite a while.

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