[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] possible reading.c speedups
From: |
Arend Bayer |
Subject: |
Re: [gnugo-devel] possible reading.c speedups |
Date: |
Thu, 7 Feb 2002 13:13:22 +0100 (CET) |
> > - Iterative deepening:
>
> this is not so hard to implement, you just have to iterate over the
> depth
> limit.
So how would the results of the previous search get used? Via the results
cache? I think that would at least require the reading functions to be able
to return s.th. like UNKNOWN instead of WIN or LOOSE if the depth limit
is reached before a definite result is known.
> >
> > - Transposition table:
> > This means result caching.
>
> and reusing the transposition move to maximise alpha beta cuts.
Can you explain what you mean by that?
>
> > - Null move heuristic:
> > This idea seems very weird and, given its proven succes, quite cool.
> > However, this is certainly not useful in go.
>
> I think it can be very useful in Go.
> You can view Abstract Proof Search and Lambda Search as a generalization
> of the null move pruning, even if they have something more to select
> interesting moves... In my experiments, Null move pruning makes my
> capture algorithm faster, and it is quite easy to implement.
That really surprises me. Do you pass as attacker or defender or both?
I would have guessed that if you play an arbitrary move (that is not a
self-atari or s.th. like that) would still be better than a pass, so that
there would be no gain (whereas in chess, any move needs to carefully avoid
direct threats/forks/...). This reasoning looks so convincing to me that
I would very much like to understand why I am wrong.
>
> quiescence search is already done in tactical settings, the most simple
> one is hte reading of ladders...
Ah, yes, thats a way to look at it.
Arend