gnugo-devel
[Top][All Lists]
Advanced

[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




reply via email to

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