[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: Jim Segrave
Subject: Re: [Bug-gnubg] Re: Race database and bearoff DB
Date: Tue, 1 Oct 2002 17:20:15 +0200
User-agent: Mutt/1.4i

On Tue 01 Oct 2002 (13:09 +0000), Joern Thyssen wrote:
> On Tue, Oct 01, 2002 at 02:30:41PM +0200, ?ystein O Johansen wrote
> > 
> > > I have ported Joseph's OSR code to a local copy of gnubg,
> > > but I never got around testing it.
> > 
> > Which bearoff database do you use for this? The problem with
> > the porting is that bearoff databases. I ported this as well
> > but I had to use the bearoff database from Joseph, and then
> > where was suddenly two bearoff databases for one program.
> > 
> > (BTW: Should we maybe find a better encoding for the gnubg
> > bearoff database? We don't want to store all these zeros.)
> If we try to compress it, it'll be much harder to read it. We can easily
> compress the current gnubg.bd since it's read into memory and we can
> just read it with functions from libz. However, for the new gnubg_os.bd
> it'll be more complicated since we can't read it into memory. We have to
> use something like fseek to find bearoff equities. Perhaps there is a
> libz_fseek... I'll check.

Ugh. Most compression schemes work on a sliding window over the input
stream, so you'd have to set re-sync points throughout the compressed
file and seek to there, then walk forward to the data you want.

What's the actual structure of the database? There are a lot of
algorithms out there for storing data, indexed files, etc. and we have
a pool of people with the ability to adapt/implement them. With a
better view of what's in the database (and maybe a large enough sample
of raw data), there will be some simple run length encoding scheme to
allow reducing the size without adversely impacting performance

Jim Segrave           address@hidden

reply via email to

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