bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Idea for encoding 2-sided database


From: Joseph Heled
Subject: Re: [Bug-gnubg] Idea for encoding 2-sided database
Date: Tue, 29 Mar 2005 21:59:03 +1200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319

I think you will find there are not enough "gin" positions to make this worthwhile. But it will be nice to be prove wrong.

-Joseph

Jim Segrave wrote:
On Tue 29 Mar 2005 (08:27 +0100), Ian Shaw wrote:



From: Jim Segrave [mailto:address@hidden

On Mon 28 Mar 2005 (16:47 +0100), Ian Shaw wrote:

Could we reduce the size of the two-sided database by omitting gin positions?

Gnubg could assume that if the position was inside the

database space
but the result was not stored, then the position is gin. A simple 0-ply evaluation could be used to verify who has won, and

as a sanity check.

I don't know how much effect this would have, but it would have greater benefits for the larger databases because more

positions would be gin.

I've not looked at the code, but I think it calculates where to look as a fixed function of the current position. If that's the case, then you need different indexing of the database, which might not be a gain.


I was thinking the index number would remain the same. If there is no
entry for that index, then the position is gin. Or is the index number
not actually part of the database? Does gnubg just count CRs or commas
or something?


I'm not at all sure what the structure of the bearoff files is. You
might be right that there's a separate index with pointers, in which
case it would be possible to have a value indicating no data (or
pointing to a common entry). I think it might be time for a bit of
scripting to see how many duplicate entries there are (gin being just
one possibility).





reply via email to

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