Yes we should test at least play, hint, analysis and rollout. Christian.
On Mon, Mar 9, 2009 at 1:19 PM, 保坂範行 <[email protected]> wrote: >> Having something close to a non-regression test would be just great. >> First idea would be to have it embedded into gnubg's code, maybe as >> a python script. > > I have a naive quesiton. > > Why not let it play gnubg v.s gnubg with a fixed initial seed? > 1) it should reproduce becuase it has fixed initial seed. > 2) seed will be very small to carry around. > 3) we can expect typical occurence of positions as usual daily backgammon > games. > 4) Once captured the evaluation of that match, we can verify later > build with that capture. > > Nori > > > On Mon, Mar 9, 2009 at 9:02 PM, Massimiliano Maini > <[email protected]> wrote: >> >> [email protected] wrote on 09/03/2009 >> 12:55:15: >> >>> Øystein Johansen (OJOHANS) wrote: >>> >> Perhaps we should just disable the mt speed test, until >>> >> somebody fixes it. >>> >> >>> > >>> > Yes! Remove it until further. The speed test should be reworked >>> completely. Today it generates a random position and then evaluates >>> the position -- and repeats this. However, picking a random position >>> is quite strange since you seldom get anything else than contact >>> positions (Take a look at the generated positions, I dare you!). The >>> speed test should have a specified set of positions which represents >>> a typical match. >>> > >>> > -Øystein >>> > >>> Yes, we ought to have an analysed match, a few money games, and a few >>> rolled out positions for people to test speed and correctness on. >> >> Having something close to a non-regression test would be just great. >> First idea would be to have it embedded into gnubg's code, maybe as >> a python script. >> >> The current speed test (withot the bug) is fine enough to measure >> the eval speed (which is not the overall speed you can expect in a rollout). >> For example, it gives you quickly an idea of how much a -O0 build is slower >> than a -03 one. I'm more for fixing it and work on a separate non-regression >> part. >> >> MaX. >> >> _______________________________________________ >> Bug-gnubg mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/bug-gnubg >> >> > > > _______________________________________________ > Bug-gnubg mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/bug-gnubg > _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
