Searching correctly with the Nullmove ==> no zugzwang problems anymore
Vincent Diepeveen
The 2 problems with nullmove were:
a) didn't detect zugzwang
b) reduces depth.
Reducing the depth depends on how much you choose R, and is of
course not that a big problem: you search a terribly lot of ply deeper
because of nullmove. Usually far deeper than the extra depth needed
to find the zugzwang using the improvement i found and posted here.
Here attached (since 1 week i now run with windows NT 4.0 workstation,
and i love it although need more memory 32 mb is not enough if you want
to play with a program on ics, and the problem seems i have not found out
yet how to insert files in this msg. This stupid editor attached the
thing i wrote yesterday) diep.log describing it again, hopefully
clearly now and the result which clearly shows that
the improvement doesn't use a trade-off too much, although
a smart tester will see that clearly: the only thing you forbid
is to use no nullmove after 2 nullmoves have been done, and this
clearly is somewhat worse than ALWAYS doing a nullmove.
Nullmove is so terribly cheap!
All tests i did so far the difference is not bigger than 1%.
read on...
Greetings from Vincent
begin 600 Nullmove.log
<encoded_portion_removed>
end
Vincent Diepeveen
Ronald de Man <de...@win.tue.nl> wrote in article
<62q3s6$d...@tuegate.tue.nl>...
> "Vincent Diepeveen" <di...@xs4all.nl> writes:
>
> >a smart tester will see that clearly: the only thing you forbid
> >is to use no nullmove after 2 nullmoves have been done, and this
> >clearly is somewhat worse than ALWAYS doing a nullmove.
>
> Not clear to me.
>
> >Nullmove is so terribly cheap!
>
> >All tests i did so far the difference is not bigger than 1%.
>
> It seems that you are comparing your approach (of forbidding a nullmove
> after 2 nullmoves) with the approach of never forbidding nullmove.
> But both are a lot more expensive than always forbidding nullmoves
> after a nullmove. So you should probably compare it with that.
No forbidding nullmove after a nullmove in Diep is worse than
never forbidding a nullmove. ONly at depths > 10 ply.
Not before.
Idea: You do a nullmove and don't know whether you may do the
nullmove. Now by doing another nullmove you get quickly answer whether
this nullmove is allowed, which is faster then doing a normal move, which
gives a bigger search tree before you see whether nullmove may be done
(will give cutoff).
> What happens is that the second nullmove can sometimes make the first
nullmove
> fail low where it would fail high without the nullmove. Then the
> tree obviously gets bigger.
>
> >read on...
>
> Sorry, I didn't read it, but I can believe the 1% difference if you
> compare it with always doing nullmoves. It would be interesting
> to know what difference you get if you always forbid nullmove after
> a nullmove (of course: only forbid it at the next ply after the nullmove,
> not at the other plies).
>
> >Greetings from Vincent
>
> Ronald de Man
>
>
Ronald de Man
"Vincent Diepeveen" <di...@xs4all.nl> writes:
>a smart tester will see that clearly: the only thing you forbid
>is to use no nullmove after 2 nullmoves have been done, and this
>clearly is somewhat worse than ALWAYS doing a nullmove.
Not clear to me.
>Nullmove is so terribly cheap!
>All tests i did so far the difference is not bigger than 1%.
It seems that you are comparing your approach (of forbidding a nullmove
after 2 nullmoves) with the approach of never forbidding nullmove.
But both are a lot more expensive than always forbidding nullmoves
after a nullmove. So you should probably compare it with that.
What happens is that the second nullmove can sometimes make the first nullmove