bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Bug: Double/Beaver


From: Joern Thyssen
Subject: Re: [Bug-gnubg] Bug: Double/Beaver
Date: Fri, 22 Aug 2003 14:41:21 +0000
User-agent: Mutt/1.4.1i

On Fri, Aug 22, 2003 at 07:57:30AM -0400, Christopher D. Yep wrote
> At 11:21 AM 8/22/2003 +0000, Jørn wrote:
> 
> >gnubg will take any cube position into account, but the forward pruning
> >at the intermediate plies will be performed with the original cube value
> >and cube position.
> >
> >This may give problems in positions where the gammon price changes
> >dramatically upon turning the cube. Examples, are initial doubles in
> >money game with Jacoby rule, and many match scores.
> 
> I think I understand everything else you wrote in the rest of the e-mail , 
> but I'm still unclear about the above paragraphs.  By the first sentence do 
> you mean that if the original cube position is, for example, a centered 
> cube then all checker plays will be chosen based on a centered cube even if 
> the cube gets turned for some (later) dice sequences in the lookahead?

Yes. The cube doesn't get turned in the sense that gnubg does a 0-ply
cube decision, but rather it does minimax over equities for all cube
positions.

> 
> If so, is this the case for both N-ply evaluations and the "no-double" 
> branch of a cube decision rollout (checker plays always based on a centered 
> cube even though the cube will almost always be turned at least once during 
> each rollout game).

No, rollouts will always play according to score. So when doubles or
redoubles occur gnubg will play according to the new cube on the
following moves in that particular trial.


> >I'm not sure if the improvement is "marginally". In your original
> >example the equity change is from -0.107 to -0.118, or around 10%, when
> >we choose another cube value/cube position for the forward pruning.
> 
> Careful how you define improvement.  gnubg improved by 0.011 in this rare 
> position.  If the equity instead had changed from -0.001 to -0.012 I would 
> still say it improved by 0.011 rather than by 1100%.  If the improvement is 
> from 0 to -0.011, it's not an infinite improvement.  If you want, you could 
> call it about a 1.1% improvement.  :-)

OK. If the improvement is always 0.01 in absolute equities then we
should not worry, but if the changes are 10% or more then it's
worthwhile to investigate.

Anyway, it would be interesting to see a reference implementation of the
brute-force minimax for comparison with *-minimax and the forward
pruning.

> >I've made a few notes available from
> >
> ><URL:http://www.gnubg.org/win32/gnubg/gnubg.html#Cubeful%20equities>
> >
> >It would be great if you could expand the chapter. I can provide the
> >texi source for the chapter if you want to work on it.
> 
> Thanks, I just read through this material and will try to read it a second 
> time later today.  Can you send me the texi source?  I promise to work on 
> it in the next week or so.  Thanks.

You can get the texi source from:

<URL:http://savannah.gnu.org/cgi-bin/cvsweb/gnubg/doc/?sortby=date>

The "cubeful equity" chapter is the file

<URL:http://savannah.gnu.org/cgi-bin/cvsweb/~checkout~/gnubg/doc/cubeful.texi?rev=HEAD&content-type=text/plain&sortby=date>

Jørn

Attachment: pgp9hox3Hqgyz.pgp
Description: PGP signature


reply via email to

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