Disappointing Null Move search

[lauriet]

Hi,
The $8 in the parameter list is the recapture square. Since 8 is off board in x088 this says there is no recapture to consider.
Nullallowed is true on the first call to either white or blacks move, false in the reduced search in the null move code and true in the normal recursive call within white or blacks move. I think this should be allowing more than one null move in the search path ?
I understand your point on the second exit and will delete it.

Laurie

[Sven]

Nullallowed is true on the first call to either white or blacks move, false in the reduced search in the null move code and true in the normal recursive call within white or blacks move. I think this should be allowing more than one null move in the search path ?

Yes, that seems to reset NullAllowed to "true" one ply below the null move, after a non-null move was made.

But there should be at least *some* positive effect of null move reduction with your implementation. In contrast to that, the numbers you gave say that it increases the tree size for a 7-ply search. So there must be some other problem. Maybe it is somewhere else in the search?

You could count how often null move is actually tried, and compare that to NullCuts. If most null move searches do not lead to a cutoff then it would explain the current behaviour since the additional effort for trying the null move would outweigh its benefit. It could mean that you are not trying the null move after bad moves most of the time.

Have you tried whether the same effect occurs when searching deeper than 7 plies?

You could also try what happens if you calculate the null move reduction dynamically, like in this pseudocode:

Code: Select all

// if (depth > 1) ...

if (depth > 6) R := 3;
else if (depth > 2) R := 2;
else R := 1;

newDepth := depth - 1 - R;

That would increase the reduction from 2 to 3 for a remaining depth of 7 and more, and it would additionally do a null move search at a remaining depth of 2 (i.e., drop into qsearch for the null move). It would require to change your null move condition "depth > 2" into "depth > 1".

If that does not have any positive effect then I'm pretty sure the problem lies somewhere else in your program.

[jwes]

Have you tried stepping through your code to see if it works? Start with a position where the side on move is hopelessly behind, and see if null move is called and returns a value which causes a cutoff.

[lauriet]

Yippy !!! I found the problem....thanks for all your help and suggestions.

In my makemove and unmake move I have:

WhitesMove := NOT Odd(MoveNum).

Of course white always starts the game on movenum = 1 and is on move for every odd move number right ?..........................EXCEPT when you have null move code

So as a result my null move was cancelled with the first makemove call. I was not really doing a null move, just putting in the overhead, which is why the result was worse than no null move. Now I am getting some good results. Search time and nodes visited is about half of vanilla search.
I will now try the R= 2 or 3 stuff, and see what can be done.
Once again thanks for all you help

Regards
Laurie.

[Sven]

I think you should also increment/decrement MoveNum when making/unmaking the null move (and this would already have solved your problem ). Maybe separate functions MakeNullMove() etc. would be appropriate. There will most probably be more that you need to do in MakeNullMove(), e.g. updating the TT hash key due to the change of the moving side, or possibly resetting the 50-moves counter.

Independent from that I think that it is much easier and also safer to toggle the "WhitesMove" variable on each make/unmake (for regular as well as null moves), as in

WhitesMove := NOT WhitesMove

, compared to the less obvious and - as you saw - more error-prone way using Odd(MoveNum). Consider also that later on your engine will be able to start in an arbitrary position given by FEN where also Black may be the moving side; in that case Odd(MoveNum) simply fails.

[lauriet]

Good idea. Thanks.

Next problem is the Transposition Table..........but thats for another thread