bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Generate bear off db(s) for Win32


From: Jim Segrave
Subject: Re: [Bug-gnubg] Generate bear off db(s) for Win32
Date: Mon, 2 Dec 2002 13:34:14 +0100
User-agent: Mutt/1.4i

On Mon 02 Dec 2002 (11:42 +0000), Joern Thyssen wrote:
> On Mon, Dec 02, 2002 at 12:21:25PM +0100, ?ystein Johansen wrote
> > >> I don't see any practical reasons why libxml should be needed to build 
> > >> the
> > >> database, since it's not taking matchscore into account. Or am I wrong 
> > again?
> > >
> > >makebearoff needs eval.o for GenerateMoves. eval.o needs matchequity.o
> > >for match equities. matchequity.o needs libxml for parsing match equity
> > >files.
> > 
> > Yes, I see!
> > 
> > >The only way to solve this is by cutting eval.o and matchequity.o into
> > >smaller pieces.
> > 
> > Why doesn't it help if eval.o and matchequity.o is recompiled without 
> > HAVE_XML2 defined?
> 
> It would! But it's impossible with the current structure: We would need
> two different config.h: one for compiling gnubg and one for compiling
> makebearoff. This is very ugly! 
> 
> It's way better to clean up the code: move the XML part of matchequity
> to a new file parsemet.c (or whatever). 

Agreed. But one could always have a flag for building makebearoff:

Makefile:

makebearoff: eval_bearoff.o ...

eval_bearoff.o: eval.c
   cc -DMAKEBEAROFF ... -o evalbearoff.o ... makebearoff.c

Then you could do, at the top of eval.c:

#ifdef MAKEBEAROFF
#ifdef HAVE_XML2
#undef HAVE_XML2
#endif
#endif

 
> > > This might be a good exercise anyway as eval.c is around
> > >6k lines and it contains functions that really don't belong in eval.c
> > >(e.g., PathSearch).
> > 
> > Yes, a cleanup here would be nice. I can take a look at this in the weekend 
> > I 
> > guess. (If no one else voluenteers for the task.)
> 
> I'll clean-up matchequity.c.

How hard would it be to move CalculateHalfPoints and it's support
routines in a separate file? I have a feeling there's some hard but
effective recoding which I am still looking at to reduce execution
time - this is one of the big time consumers and I'd like to try some
things out. Having it separated would make my life easier. 

It's also possible that my ideas won't have any real effect and that
the real time is set by the floating point ops in the neural net. I'd
love to see a profiler output on a per-source-line basis for this
routine (the FreeBSD gprof is less than complete).

-- 
Jim Segrave           address@hidden




reply via email to

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