[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] arend_3_9.1: reading patch
From: |
Arend Bayer |
Subject: |
Re: [gnugo-devel] arend_3_9.1: reading patch |
Date: |
Wed, 11 Sep 2002 17:05:07 +0200 (CEST) |
Gunnar wrote:
> Arend wrote:
> > There is another obvious problem, namely generating those moves also
> > takes time. And with more such changes we will more generate more such
> > moves that will not get used.
>
> This is an important point.
On the other hand, the splitting up in separate batches also is
sometimes inefficient. double_atari_chain_moves,
break_chain2_efficient_moves and break_chain2_moves all duplicate some
work (looking up neighbours with exactly two liberties -- not completely
negligeable if I remember the latest profile I looked at correctly).
> > Once this is done, one could also think about moving the trymove() loops
> > from defend?() to do_find_defense(); then defend?() would be called to the
> > generate the move list that should be tried -- maybe split up in two
> > separate batches to decrease the run-time cost in the frequent cases
> > where the obvious moves are sufficient.
>
> In the end I think we can do without the defend?() functions too. I'm
> envisioning some table driven approach deciding which move generators
> to call for various numbers of liberties.
Ah, that makes sense. Probably best to start doing this only after all
trymove() loops have been moved inside defend?/attack?.
> > Gunnar suggested having only one trymove() loop for attack/defense, resp.,
> > a while ago. I guess this is how we could get there.
>
> Maybe I forgot to say that even if we only have one trymove() loop, we
> can still have an outer loop splitting the move generation into
> multiple batches.
Well, while working on this patch I finally managed to realize this,
too :-)
For now, I think I will install the patch and keep your comments in mind
once I spend some more time on this.
Arend