null move

[hgm]

Well, the (un)do_move is pretty essential. I cannot smell where you intend them to be if you have unusual code. Normally they surround calls to search()...

Then it seems the code is correct, (provided you call the first search() with one ply extra reduction, depth-4 rather than depth-3, to account for that do_move). Provided that beta_cutoff is not used elsewhere to imply you would have a beta cutoff in the current node.

[Henk]

search(beta - 1, beta) <> -search(-beta, -(beta -1)) and -search(-beta, -(beta -1)) is correct or not ? Or has my_color parameter effect on comparing values with alpha or beta in your code.

[flok]

Sorry for the confusion. I considered just copy/pasting the real-code but as it is a bit "special" I thought it may only make things more confusing

Regarding the re-use of the beta_cutoff variable: if it is set, then the whole current instance of search() should abort and use the bestVal upto that point. So it cannot be reset I think? I mean: the null-move check can not-set it, but it won't reset it.

Sorry that I'm so precise with this: I have the feeling that I made only a small bug with major consequences.

[flok]

search(beta - 1, beta) <> -search(-beta, -(beta -1)) and -search(-beta, -(beta -1)) is correct or not ?

Please note that the color was not swapped at the point where search() was invoked for null-move and thus the negating not required (nor the negating of beta and swapping)

[hgm]

Regarding the re-use of the beta_cutoff variable: if it is set, then the whole current instance of search() should abort and use the bestVal upto that point. So it cannot be reset I think? I mean: the null-move check can not-set it, but it won't reset it.

You use beta_cutoff here to indicate that what normally is the the daughter node has had the null move fail high. That means the move played in the current node (with do_move) fails low here. So beta_cutoff should definite not be used to imply you can cut off here. You can just skip searching other replies to that same move because it is now refuted. You must still search replies to other moves that are not refuted by their null-move reply. If a null move refutes move A, it does not imply it refutes any other move B.

[Henk]

search(beta - 1, beta) <> -search(-beta, -(beta -1)) and -search(-beta, -(beta -1)) is correct or not ?

Please note that the color was not swapped at the point where search() was invoked for null-move and thus the negating not required (nor the negating of beta and swapping)

Ok. But what does your do move do. If first player performed a legal move which is accepted then it is opponents turn and move is evaluated from the side of the opponent and after undo move you have to translate that result back to the side of the first player.

[flok]

Well it skips that move.

[Henk]

Well it skips that move.

So first player to move then skip move and then again first player is to move. So the topic is skip move not null move. For after a null move of first player it's the second players turn.

[flok]

I'm not sure what you're saying.

What happens:

- a for-loop iterating through all moves
- do move
- skip opponent color and do a reduced set with current color
- if null-move did not produce a beta-cutoff
- do a full search
- undo move

[bob]

Hi,

Regarding null moves. I noticed that my chess program fails horribly when null moves are enabled. E.g. doing moves like a2-a3 or h2-h4.
I would like to describe what I'm doing, maybe someone spots the problem?

My chess program has a search(depth, color, alpha, beta) function. Furthermore it has an evaluate(color) function which returns the score of a position seen from the `color' point of view.
While doing a search, it calls itself with

Code: Select all

score = -search(depth - 1, opponentColor, -beta, -alpha)
if (score > bestVal) { bestVal = score; }
if (score > alpha) { alpha = score; if (score > beta) beta_cutoff = true; }

bestVal is the score that is eventually returned by the search() function.
So far so good.

Now for the null-move.
First I check if depth > 3 (e.g. there are more than 3 moves left before we enter quiescence search, I also check for being-in-check-status), then I invoke search:

Code: Select all

score = search(depth - 3, color, beta - 1, beta);

So I invoke it with the current color and a very small window
I don't negate the values because (and I'm not sure about this) the search is invoked with the current color (e.g. not the opponent).
Then, I do:

Code: Select all

if (score > beta) { beta_cutoff = true; bestVal = score; }

So no updating of alpha/beta or bestVal when there's no beta-cut-off.
I also don't update the transpositiontable because it is an incomplete search.

Any ideas?

regards

You are using the wrong color. When you play a null-move, it changes side-to-move, so that your opponent makes two consecutive moves. You are not doing that with the code shown.