[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: |
Gunnar Farneback |
Subject: |
Re: [gnugo-devel] arend_3_9.1: reading patch |
Date: |
Tue, 10 Sep 2002 22:50:41 +0200 |
User-agent: |
EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode) |
Arend wrote:
> * break_chain2() did some kind of forward pruning that would be a pain to
> do with these revisions. Hence I simply killed that.
Probably a good idea.
> 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.
> However, I still think it is the right thing to do. Probably it is
> best to proceed by converting all the other helper functions into
> .._moves functions, too. Maybe it is best to keep doing this in small
> steps, to make sure we don't hurt the move ordering.
> 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.
> 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.
/Gunnar