bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Rollouts - some bugs and suggestions


From: Jim Segrave
Subject: Re: [Bug-gnubg] Rollouts - some bugs and suggestions
Date: Tue, 4 Mar 2003 16:33:46 +0100
User-agent: Mutt/1.4i

On Tue 04 Mar 2003 (14:53 +0100), Magnar Naustdalslid wrote:

> Again, thanks for this excellent program. I am using gnubg February
> 15 2003 build, snapshot 030303 and I am happy to see that the weird
> "train" menu has been removed :- ).

> Here are some rollout issues I hope you will consider:

> 1. Will it be possible to do cubeless rollouts with cube-adjusted
>    equities? Sometimes I don't trust gnubg's cube-handling in rollouts
>    with live cube (for example if it doubles after one move, but not
>    after the other, even though I expect a double in both cases).
>    Currently, cubeless rollouts yield only cubeless equities, right?

I'm probably the wrong one to comment here, but:

1) if you don't trust the cube handling, then you can't trust the
   chequer-play according to score.
2) naive question - if gnubg decides one player would cash the game in
   a position because it's a clear pass, then not making a cube
   decision and continuing the rollout will not be correctable by
   trying to guess the cubeful equity from a cubeless one.

Yes, cubeless rollouts will only yield cubeless equities and will be
wrong for cubeful situations because of 1 and 2, above.

> 2. When I analyse a match and do a rollout for a double/take
>    decision, I have to do this BOTH for the doubling decision and for
>    the take decision. It should only be necessary to do one rollout.

The rollout of a doubling decision gives two lines:

(for a double)
player n holds 2 cube (where n is the 'takee')
centred 1 cube

(for a redouble)
player n holds 4 cube (where n is the 'takee')
player m holds 2 cube (where m is the redoubler)

So you get both the double/take and nodouble rollouts together
 
> 3. When I uncheck "Cube decisions use same settings as Chequer
>    play", "Use same settings for both players" or "Use Player0 settings
>    for truncation point", the changes are not saved.

These aren't so much options as time savers when setting rollout
options, so I never saw much point in making them saveable. Is it
really an issue?

> 4. If I use expert level for checker play and world class 33%
>    reduction for cube play, next time I open rollout settings cube play
>    has changed to 25% reduction.

That's a bug. I need someone to explain the code in gtkgame.c:

in EvalWidget, a menu for reduced evaluations is set up with entries

int     text
0       No reduction
2       50% speed
3       33% speed
4       25% speed

The value 1 is deliberately not put into this menu.
The menu value is then loaded with 
gtk_option_menu_set_history( the index of the item), but this is off
by one, since there's no menu item for the value 1.
The same problem occurs for the Analysis and Evaluation settings.

I'm about to commit a fix

> 5. It seems to me that not much time is saved by using using a high
>    level of play for the first few plies and expert for the remainder
>    as compared to using a high level for all the moves. For example, if
>    I choose world class for the first five plies and expert for the
>    rest of the game, I would expect this to be MUCH faster than world
>    class for all the moves.  This does not seem to be the case. Maybe I
>    am missing something.
 
I had the same expectation. When I first put the code in for reduced
evaluations at later plies, I expected the same. The improvement in
performance was a lot less than I would have thought. My guess is that
cacheing is working very well, so that a deeper evaluation will
already have cached values for the upcoming positions (so the deeper
evaluation means evaluating the first move takes longer than the
second, but the second move has all the first rolls already cached). I
think that the actual number of evaluations done is much closer than I
would have thought.


-- 
Jim Segrave           address@hidden




reply via email to

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