bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] FW: gnu bug on vista?


From: Christian Anthon
Subject: Re: [Bug-gnubg] FW: gnu bug on vista?
Date: Tue, 10 Mar 2009 13:58:15 +0100

Yes we should test at least play, hint, analysis and rollout.

Christian.

On Mon, Mar 9, 2009 at 1:19 PM, 保坂範行 <address@hidden> 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
> <address@hidden> wrote:
>>
>> address@hidden 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
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/bug-gnubg
>>
>>
>
>
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnubg
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]