gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] The killer heuristic


From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] The killer heuristic
Date: Sat, 25 Jan 2003 19:57:14 -0500 (EST)

On Sat, 25 Jan 2003, Arend Bayer wrote:

> Evan wrote:
>
> > On Sat, 25 Jan 2003, Arend Bayer wrote:
> > >
> > > Below are numbers from CVS at the same time. It seems your patch saves
> > > about 1.5% on average.
> > > (There are also some deviations for owl nodes and connection nodes,
> > > not sure where they come from.)
> >
> > I assume they come from cases where the new ordering results in a
> > different move being returned by attack() or find_defense().  Sometimes
> > the actual move is used, eg in the owl code the result of attack() on the
> > origin of the dragon is tried as an owl attack.  This also occurs with
> > other changes to tactical move ordering, eg my move ordering tuning patch
> > from a while ago had a small regression delta.
>
> I _think_ what you are saying is incorrect. Your patch only effects
> results of do_attack when called from a defend? function. But the
> externally visibly behaviour of attack() and find_defense() should not
> change at all.
>
> I think it is a platform dependency. The relatively large deviations
> in connection nodes (0.5%) can be explained from floating point rounding
> problems in readconnect.c. As for owl nodes I am not sure.

Floating point rounding problems is an interesting thought...  is there a
way to compile things to do IEEE floating point instead of platform
dependent, to test this out?

As for move ordering affecting the result returned -- in general I think
you are correct.  The killer heuristic does not come into play at the top
level; no move is suggested to the top level functions.  However, I think
the persistent reading cache changes this:

Suppose the top level reading functions are called at stackp == 0.  The
results are cached for stackp == 0, stackp == 1, etc, several levels down.
The deeper results _are_ dependent on the killer heuristic.  Then, the owl
code is run.  Owl tries a move, and asks the tactics code about something.
The tactics code finds a cached result, because it had already previously
tried the same move owl did, and returns the move to owl.  This move is
then used in the owl computations, and it is different depending on
whether or not the killer heuristic is in effect.

I think that's all consistent...  I could have something wrong though.

Evan Daniel




reply via email to

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