My Engine won't pick up PV's until depth >= 10

[John Major]

'Key' in zobristKey() is used uninitialized.

That is due to the "x ^ y" instead of "x ^= y" kind of bugs in that routine which I mentioned.

Sven

No, uninitialized is uninitialized.

[ZirconiumX]

@ Futility pruning
It needs to return - it wouldn't be pruning otherwise - and it means I don't have to check if there is a legal move.

@ Compiler warnings
I have not tested Magic on anything other than apple g++ 4.0.1 - so if anyone would like to test it on windows - please let me know. Also the fact you have to compile this.cpp was intended.

@ Nps divide by zero
Apologies for this.

@ Nullmove pruning
The 0 - alpha thing was from the chessprogramming wiki.

Matthew:out

[Sven]

'Key' in zobristKey() is used uninitialized.

That is due to the "x ^ y" instead of "x ^= y" kind of bugs in that routine which I mentioned.

Sven

No, uninitialized is uninitialized.

O.k., since VS2010 Express does not print that warning (not even with warning level 4, funny enough) I missed the fact that even after changing the wrong "key ^ ..." lines into "key ^= ..." the variable "key" is uninitialized from the beginning (should be "U64 key = 0;").

Furthermore, I don't remember if it had already been mentioned that the hash key functionality lacks support of castling rights and ep target.

Sven

[Sven]

@ Futility pruning
It needs to return - it wouldn't be pruning otherwise - and it means I don't have to check if there is a legal move.

No. You want to prune one particular move, by not searching its subtree. What your code actually does - apart from the missing unmake that was already mentioned - is to prune that move but also all subsequent moves under the same parent node. Pruning just one move within the move loop is done by skipping the loop body without descending into the subtree, e.g. with "continue".
There are more issues with that futility code, I can't mention all. I propose that you take it out for the moment, since your program won't work with it as it is now.

@ Compiler warnings
I have not tested Magic on anything other than apple g++ 4.0.1 - so if anyone would like to test it on windows - please let me know. Also the fact you have to compile this.cpp was intended.

Does apple g++ 4.0.1 not print all these warnings?

@ Nullmove pruning
The 0 - alpha thing was from the chessprogramming wiki.

No, read again, there you find "-AlphaBeta (0-beta, 1-beta, depth-R-1)" (Null move pruning) which is the same as ... -beta, -beta + 1. The difference is significant.

More problems:
1) Function zobristKey() has a switch over piece but does not work correctly for black pieces. The cases for -PAWN, -KNIGHT etc. are useless, and in the other cases instead of WHITE you should use color.
2) The move generator (function Gen()) crashes immediately when seeing a square with color == current_side and piece == EMPTY. That should be fixed.

After applying all the fixes that were mentioned in this thread to the code you originally gave a link to, Magic actually prints this after playing "e2e4":

Code: Select all

Magic 1.5 by Matthew Brades, Pham Hong Nguyen
d(isplay), Move( in LAN) quit( Magic)

e2e4
info depth 1
info score 50 nodes 22 nps 0 seldepth 0 pv b8c6
info depth 2
info score 0 nodes 170 nps 0 seldepth -12 pv b8c6 b1c3
info depth 3
info score 50 nodes 697 nps 0 seldepth -58 pv b8c6 b1c3 g8f6
info depth 4
info score 0 nodes 3612 nps 0 seldepth -409 pv b8c6 b1c3 g8f6 g1f3
info depth 5
info score 10 nodes 14150 nps 456451 seldepth -1254 pv b8a6 e4e5 a6c5 b1c3 g8f6

info depth 6
info score 90 nodes 77303 nps 452064 seldepth -7916 pv b8c6 e4e5 c6e5 b1c3 g8f6
g1f3
info depth 7
info score 20 nodes 213588 nps 441297 seldepth -21484 pv b8c6 b1c3 a8b8 c3d5 d7d
6 g1f3 g8f6
info depth 8
info score 5 nodes 7328469 nps -73064 seldepth -468103 pv b8c6 g1h3 a8b8 e4e5 e7
e6 h3f4 c6e5 f4e6
bestmove b8c6 ponder g1h3

which is maybe one very small step forward. (I also commented out the futility pruning code, fixed the null move part, corrected the nps output problem, and initialized "int score = 0, moves = 0, R = 0, f_prune = 0;" in AlphaBeta().)

The "seldepth" calculation is wrong, it should be something similar to "seldepth = max(seldepth, depth)" at the right places. That causes arbitrary (negative) numbers to appear in the output.

One last word, after doing some quick research I believe that a couple of all these problems may have their origin in the "firstchess" version that you were using as a starting point. This includes e.g. the lack of castling and e.p. support.

Sven

[ZirconiumX]

@ Futility pruning
It needs to return - it wouldn't be pruning otherwise - and it means I don't have to check if there is a legal move.

1) No. You want to prune one particular move, by not searching its subtree. What your code actually does - apart from the missing unmake that was already mentioned - is to prune that move but also all subsequent moves under the same parent node. Pruning just one move within the move loop is done by skipping the loop body without descending into the subtree, e.g. with "continue".
There are more issues with that futility code, I can't mention all. I propose that you take it out for the moment, since your program won't work with it as it is now.

@ Compiler warnings
I have not tested Magic on anything other than apple g++ 4.0.1 - so if anyone would like to test it on windows - please let me know. Also the fact you have to compile this.cpp was intended.

2) Does apple g++ 4.0.1 not print all these warnings?

@ Nullmove pruning
The 0 - alpha thing was from the chessprogramming wiki.

3) No, read again, there you find "-AlphaBeta (0-beta, 1-beta, depth-R-1)" (Null move pruning) which is the same as ... -beta, -beta + 1. The difference is significant.

More problems:
4) Function zobristKey() has a switch over piece but does not work correctly for black pieces. The cases for -PAWN, -KNIGHT etc. are useless, and in the other cases instead of WHITE you should use color.
5) The move generator (function Gen()) crashes immediately when seeing a square with color == current_side and piece == EMPTY. That should be fixed.

After applying all the fixes that were mentioned in this thread to the code you originally gave a link to, Magic actually prints this after playing "e2e4":

Code: Select all

Magic 1.5 by Matthew Brades, Pham Hong Nguyen
d(isplay), Move( in LAN) quit( Magic)

e2e4
info depth 1
info score 50 nodes 22 nps 0 seldepth 0 pv b8c6
info depth 2
info score 0 nodes 170 nps 0 seldepth -12 pv b8c6 b1c3
info depth 3
info score 50 nodes 697 nps 0 seldepth -58 pv b8c6 b1c3 g8f6
info depth 4
info score 0 nodes 3612 nps 0 seldepth -409 pv b8c6 b1c3 g8f6 g1f3
info depth 5
info score 10 nodes 14150 nps 456451 seldepth -1254 pv b8a6 e4e5 a6c5 b1c3 g8f6

info depth 6
info score 90 nodes 77303 nps 452064 seldepth -7916 pv b8c6 e4e5 c6e5 b1c3 g8f6
g1f3
info depth 7
info score 20 nodes 213588 nps 441297 seldepth -21484 pv b8c6 b1c3 a8b8 c3d5 d7d
6 g1f3 g8f6
info depth 8
info score 5 nodes 7328469 nps -73064 seldepth -468103 pv b8c6 g1h3 a8b8 e4e5 e7
e6 h3f4 c6e5 f4e6
bestmove b8c6 ponder g1h3

6) which is maybe one very small step forward. (I also commented out the futility pruning code, fixed the null move part, corrected the nps output problem, and initialized "int score = 0, moves = 0, R = 0, f_prune = 0;" in AlphaBeta().)

7) The "seldepth" calculation is wrong, it should be something similar to "seldepth = max(seldepth, depth)" at the right places. That causes arbitrary (negative) numbers to appear in the output.

8) One last word, after doing some quick research I believe that a couple of all these problems may have their origin in the "firstchess" version that you were using as a starting point. This includes e.g. the lack of castling and e.p. support.

Sven

1) So, roughly if(! <futility prune condition holds>) { <search }?
2) Compiles clean from my end.
3) Apologies, I was working from memory at the time.
4) Apologies.
5) So I need to fix MakeMove() and/or TakeBack()?
6) Yes indeed - though I laughed when it said "nps -73064". Perhaps a max(<nps score>, -<nps score>) is neccesary.
7) Fair enough - I am a chess programming noob.
8) Yes - no castling, nor e.p. I doubt strongly that castling will ever be included - though I either add a second move in the typedef struct t_move_t or I fix this in MakeMove() - what do you think?

Matthew:out