[Top][All Lists]

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

Re: [Bug-gnubg] Re: Race database and bearoff DB

From: Øystein O Johansen
Subject: Re: [Bug-gnubg] Re: Race database and bearoff DB
Date: Tue, 1 Oct 2002 09:04:29 +0200


Yes, I really agree with Joseph here. Can anyone provide any race positions
where it misplays the positions? If this is a problem I think we should
rather make Joseph's osr (*) algorithm available for gnubg. This alogorithm
is very good, and it's not that slow. Basically, what it does is that it
rolls out each side independently to get a roll distribution for each side.
These two roll distributions are combined to give the cubeless winning

I have still not seen this routine make any errors in the race evaluation,
though I have seen the race network make some bad evaluations in tricky
positions. (I must admit I don't believe this bad evaluations by the race
network makes the overall strength of gnubg much worse. I really think the
overall strength still lays in improving the crashed network.)


(*) osr = One Side Rollout

                    ver.net.nz           To:     "Albert Silver" 
                    Sent by:             cc:     "GNUBackgammon bug reporting" 
<address@hidden>, (bcc: Øystein  
                    bug-gnubg-adm        O Johansen)                            
                    address@hidden           Subject:     [Bug-gnubg] Re: Race 
database and bearoff DB                 

Again, this is not entirely new. The suggestion to enhance the race DB is
based on the assumption that the bot misplays those positions. I would like

to see the evidence for that. I think I will start an effort to measure the

race net error just to make sure (similar to the crashed net). Also, I find

it hard to belive the bearoff database is insuffcient.

Can you pose this Q to Neil? i.e. can he provide a set of positions GNU


Albert Silver writes:

> Well, as long as the discussion of the day is the bot's development,
> I'll take advantage and pass on the result of a long discussion I had
> with Kazaross at GG. We were discussing GNUbg in general, and he said he
> had an idea that he thought would significantly improve the bot's play:
> race and bearoff databases.
> He noted that in Snowie 2 and 3, there was a cubeless race DB that went
> up to the 10 point and that took up 294 MB. He said that in his opinion
> a DB that went up to the midpoint would improve the bot's play
> enormously. I said that in chess, any increase in such databases
> increased the size of the files exponentially. For example, a complete
> 5-piece tablebase (every possible position with 5 pieces - including
> kings BTW) would take up about 7.5 GB. This has decreased since the idea
> was first incepted by Ken Thompson, and the 7.5 figure is for the
> Nalimov format. Chessmaster 9000 has a new algorithm that is even more
> efficient, but that's another story. A 6-piece tablebase set would take
> up several terabytes. As it is, in Snowie 1, the race database went up
> to the 11 point, and the file was a mere 392 MB, so nothing cataclysmic
> involved. His suggestion makes sense, though I'm not sure about how this
> could be provided to users.
> The single best source to download the chess tablebases is at the FTP of
> Dr. Robert Hyatt provided by his university, the University of Alabama -
> Birmingham. Otherwise, a user can download a tool and have their own
> machine build the tablebases. For 5 piece sets, this is possible though
> fairly long (a day or more depending on the PC). For any 6 piece set you
> have to download it though as a PC would take months for a single
> configuration.
> Albert

Bug-gnubg mailing list

The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.

reply via email to

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