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: Jim Segrave
Subject: Re: [Bug-gnubg] Idea for encoding 2-sided database
Date: Tue, 29 Mar 2005 10:11:39 +0200
User-agent: Mutt/1.4.2.1i

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).

-- 
Jim Segrave           address@hidden





reply via email to

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