[Top][All Lists]
[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