bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Suspect bearoff results


From: Joern Thyssen
Subject: Re: [Bug-gnubg] Suspect bearoff results
Date: Sun, 15 Dec 2002 18:03:04 +0000
User-agent: Mutt/1.4i

On Fri, Dec 13, 2002 at 03:01:48PM -0000, Ian Shaw wrote
>     GNU Backgammon  Position ID: qMduAwDYvmgDAA
>                     Match ID   : cAkrAAAAAAAA
>     +24-23-22-21-20-19------18-17-16-15-14-13-+  O: GnuBg
>     |          O  O  O |   |       O  O  O  O |  0 points
>     |                O |   |       O  O  O  O |  
>     |                O |   |          O       |  
>     |                O |   |                  |  
>     |                  |   |                  |  
>     |                  |BAR|                  |v 1 point match (Cube: 1)
>     |                X |   |                  |  
>     |                X |   |                  |  
>     |                X |   |                  |  
>     |          X  X  X |   |             X  X |  Rolled 62
>     |          X  X  X |   | X        X  X  X |  0 points
>     +-1--2--3--4--5--6-------7--8--9-10-11-12-+  X: Ian
> 
> Does it really make no difference what I play here? I guess it's
> possible since the position is so flexible, but I'd like reassurance
> that the database is working correctly.
> 
> Why is there a 2-ply or 0-ply evaluation when it is all being looked
> up in a database? 

It can't calculate cubeful equities using the database (except money
game and a position in the two-sided database).

I agree that for some match scores (like this one), there is no need to
recurse multiple ply as the cube is dead.

> This also takes a lot longer to come up with a hint than if I use the
> race net (temporarily renaming gnubg_os.bd and restart). 

Reading from the two-sided bearoff database is currently quite
inefficient. It's on my TODO list to improve this. gnubg caches
evaluations of positions, but for the one-sided bearoff database we need
to cache one-sided positions as well.

> Is this to be expected? Are the results needlessly looked up multiple
> times for the different plies?

Some bearoff distributions may be needlessly looked up, but as I
mentioned above, we cannot avoid the recursing (except for special match
scores -- which is not implemented).


The race net returns approximately the results as the one-sided bearoff.

You can setup the board after 12/6 7/5 and 11/5 7/5 and using the
"Evaluate" command you get some extra output from the bearoff database.
Here is the bearoff distribution for the to moves:

    2 0.000    0.000
    3 0.000    0.000
    4 0.000    0.000
    5 0.000    0.000
    6 0.002    0.003
    7 0.031    0.031
    8 0.229    0.229
    9 1.044    1.044
   10 3.459    3.458
   11 8.357    8.354
   12 15.311   15.314
   13 21.118   21.117
   14 21.755   21.756
   15 16.394   16.394
   16 8.551    8.551
   17 2.962    2.962
   18 0.674    0.674
   19 0.102    0.102
   20 0.011    0.011
   21 0.000    0.000
   22 0.000    0.000
   23 0.000    0.000
   24 0.000    0.000

These look very similar and as the opponents distribution is the same it
seems fair that the two distributions result in the same winning
probability. 

Jørn



reply via email to

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