RE: [Bug-gnubg] Bug: 14 point one-sidedrace databasewithmakebearoff.exe

[Ian Shaw]

> From: Joern Thyssen
> Sent: 11 January 2005 10:36
> 
> On Sun, Jan 09, 2005 at 01:36:02PM -0800, Ned Cross wrote
> > As I recall, the race net is very good, and the 13 point 
> should cover 
> > most common non-contact scenarios, so I would be willing to 
> guess the 
> > 13 point database is the limit of diminishing returns for 
> most users anyway.
> > 

Yes, it is diminishing returns, but some of us pedants like to be able to use 
large databases from time to time, mainly to study epcs.

> > Is there a scenario where having the database to the 14 point or 
> > beyond is truly a performance improvement?
> 
> Actually the performance is worse using the databases as the 
> I/O takes more time than a neural net evaluation.
> 

I think this is true for playing games, but not necessarily so for rollouts. If 
we are doing cubeless rollouts we cab truncate at the one-sided database, thus 
saving a significant number of net evaluations. Maybe I'll try to benchmark 
this one day. (This truncation will also affect the standard error, but I'm not 
sure how or if this is factored into the reported SE.)

Would it speed up the access to have incremental chunks of the database in 
separate files? E.g. one database for up to six points, another for the 7 to 10 
points, and one each per point thereafter.

> Joseph did some comparisons between the 12pt bearoff database 
> and the neural net. For example, 2-ply had an avg error rate 
> of 0.0000209 and made ~4% chequerplay errors for a set of 
> 34000+ positions.
> 
> For 0-ply the percentage of chequerplay errors increases with 
> the "range", e.g., only 4% errors for positions where the 
> outermost chequer is on the 7pt compared to 9.5% for the 
> 12pt. This suggests that the database could be needed for 
> even "longer" races. However, 2-ply lowers the error rate and 
> I think you'll rarely see interesting races where one side 
> has multiple chequers further out than the 13pt (unless he is 
> strugling to save a gammon). 
> 
> Jørn
>