Null move around (beta-1, beta)

[Tom King]

Hi all,

A 'normal' null move implementation involves doing a reduced depth
search with the standard alpha, beta window. If the score returned from
the reduced depth search is greater than alpha, you raise alpha. If the
score returned is greater than beta, you've got a beta cutoff, so you
return from your search() function immediately.

A couple of questions:

A while back I read (maybe here, maybe CCC) that many programmers were
doing null move searches with a beta-1, beta window. Apparently this
gives slight speedups. When I tried this, I found it affected the
searching of my program significantly. PV's and scores were quite
different. Has anyone else found this, or have I just cocked up in my
implementation?

What about raising alpha when the null move search is greater than
alpha, but less than beta. I do this, but I'm not convinced its a godd
thing. Opinions?
--
Tom King

[Robert Hyatt]

Tom King <t...@hatbulb.demon.co.uk> wrote:
: Hi all,

: A couple of questions:

I have always done the beta-1, beta boundary search. So far as I know,
that seems reasonable, because I either want it to fail high (against beta,
regardless of the lower bound) or not.

I don't use the score however, to raise alpha. Either I fail high and
return beta, or I toss the whole thing out and search with the normal
bounds. What would you do if you raise alpha so that _all_ moves at
this ply fail low, but your score is not the original alpha value? You
don't have a PV move here. You can't play a 'null-move' in the real
game. So I either fail high or ignore the null-move result..

--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170

[Tom King]

In article <7bpho1$pe0$2...@juniper.cis.uab.edu>, Robert Hyatt
<hy...@crafty.cis.uab.edu> writes

Right. I do this, and sometimes find Null Moves appearing in my PV. This
is decidedly dodgy. But when I try the null moves around (beta-1, beta),
the search changes significantly. Some test problems are solved faster,
some slower, and some *much* slower (like 2 or 3 plies later). PV's are
different, and so are scores.

Can't figure this one out at the moment. I've probably got a bug lurking
somewhere in this area..

>don't have a PV move here. You can't play a 'null-move' in the real
>game. So I either fail high or ignore the null-move result..
>
>

--
Tom King

[Bas Hamstra]

In my program it works as good as the full window. Without pruning and
extensions it should give the same result (somewhat easier). However with
pruning (futility pruning in the qsearch for example) search inconsisencies
can and will occur that can lead to a change here and there. That's kind of
"normal". If you get very different scores I would suspect something is
wrong.

And raising alpha isn't done in any program I've seen and doesn't look like
a good idea to me.

Tom King heeft geschreven in bericht ...

[Tom King]

In article <7c9b7s$os4$1...@reader3.wxs.nl>, Bas Hamstra
<bas.h...@wxs.nl> writes

>In my program it works as good as the full window. Without pruning and
>extensions it should give the same result (somewhat easier). However with
>pruning (futility pruning in the qsearch for example) search inconsisencies
>can and will occur that can lead to a change here and there. That's kind of
>"normal". If you get very different scores I would suspect something is
>wrong.
>
>And raising alpha isn't done in any program I've seen and doesn't look like
>a good idea to me.
>

Maybe I'll switch to null move around beta-1 and beta, then. From
discussion here and private discussion, no-one else seems to be raising
alpha, as orignally advocated by Donniger in his ICCA article.

Hmm. More testing required, methinks.

--
Tom King