beta3 vs brute force

[Brian the Roman]

I'm running both of my most dedicated machines on the beta 24/7. One other I have intermittently working on the 'normal' folding. My results thus far are better on the normal side (9.69) than on the beta (10.24) even though considerably more effort (at least 5X as much) has been applied to the beta side.

Does anyone else find the same thing?

Are we comparing apples and oranges when doing this because of the different scoring algorithm used?

ms

[m0ti]

I think that my results are similar to yours.

I've got two machines running; the more powerful one is on the beta and the other one in running normal DF.

I've hit a 12.19 in the beta and a 7.54 in the normal one.

I'm not sure though if we started up with beta 3 at the same time as we made the protein switch.

Also, perhaps the move to 100 generations instead of 50 generations would help balance it out? (Howard suggested they may do this since after 50 gens the energies still aren't minimized).

[AMD_is_logical]

Keep in mind that the regular client is producing a lot of structures that are then selected according to how close they are to the "answer". In the long run that isn't very useful because the answer won't be known in advance.

The beta is selecting structures based on crease energy, which is calculated from the generated structure. Thus, the result of the 50 generations has been produced without knowing the answer in advance. Only then are the results being compared with the correct answer.

[Brian the Fist]

Yes you are both correct. Please also remember, we are not just beta testing the software, but the algorithm as well. We plan to use what we learn now to try to tweak the algorithm and make it better (such as going to 100 generations) before we scale up. Also, increasing the initial population (from 500 to 5000 or even more maybe) will improve the chances of getting a decent seed structure I think.

[Brian the Roman]

One suggestion there, Howard, is to not make the # of generations fixed. That is, kep digging down the generations until some set of consecutie generations don't yield a better energy result. This would optimize things.

ms

[TEN-Catdaddy63]

Howard, I have a concern also regarding the Beta. I am seeing times of about 24 hours to complete one set of 50 generations on an XP1800 at home and in the 36-48 hour range on a Celeron 1200, both are 256mb ram and windows 2000 (though the Celerys are set to useram=0). My concern is that once this algorithm becomes the production version with the structures increasing ten fold, it would seem that normal times to complete one set of 50 generations could take from 8-20 days depending on the machine. Users with older, slower machines could see much longer times than that (such as my K6-333 laptop) and lose interest in the project when they are not seeing results. These machines also may not complete a set before the next protein changeover (if the intervals work out to be similar to what we are seeing now.) To an extent, people want to see that they are contributing to the project in a meaningful way (re: stats) so hopefully we can keep these folks with slower machines happy. One way to accomplish this may be to have the algorithm relax faster once it gets stuck in proportion to the speed of the machine. It would seem logical that as we drill down into the protein that relaxing it faster may not give a lesser result once the last generations are reached. Am I off base here? My resources are currently here at DF and I don't plan on going anywhere anytime soon.