Shame

[Sven]

..., and of course counting all legal moves (the ones that you don't find to be illegal after making them) within the move loop.

Actually in a fail-soft setting you don't even have to do that. You initialize bestScore to -INFINITE, and if there were no legal moves it stays there. And as this happens to be exactly the score you need when you are checkmated, you don't need to do anything. Only stalemate would require a correction of the score to 0, in case it got stuck at -INFINITE.

Yes. I obviously assumed fail-hard by default in the given case. Furthermore, regarding your other remark, there are still some people returning -(INFINITE-ply) instead of your version -INFINITE in case of being checkmated ...

[Robert Pope]

You don't have to iterate over all moves for check detection. Start at the king and see if a knight move will end at a knight, if a slide terminates at a R/B/Q, and if there is a pawn attacking the spot. Build that into a function and you have a relatively fast way of detecting it. Build that code into a function, so you can have a simple "if(inCheck(color)) return alpha;" check.

And yes, mate in N isn't that important by itself, but finding that even simple programs find the result 100x faster is a big deal.

[Henk]

You don't have to iterate over all moves for check detection. Start at the king and see if a knight move will end at a knight, if a slide terminates at a R/B/Q, and if there is a pawn attacking the spot. Build that into a function and you have a relatively fast way of detecting it. Build that code into a function, so you can have a simple "if(inCheck(color)) return alpha;" check.

And yes, mate in N isn't that important by itself, but finding that even simple programs find the result 100x faster is a big deal.

Yes I made a mistake I also have a method that doesn't check all moves but uses the position of the king and bitboards but it is still not very fast.

Strange even if I add a legal move check I still get an infinite loop. Maybe I better stop for today. Too much bugs.

[Sven]

Check extensions only works if you only allow legal moves otherwise you get an infinite loop. (It took me two hours to understand what was going on. So I have had enough misery for today).

No, this is wrong. Check extension means to extend if the own king is in check, not if an illegal move has left the (now) enemy king in check. Also you shall not "allow" illegal moves in general, you make each pseudolegal move and then you check whether that move was illegal, undoing it in case it was. So you never descend into the subtree of an illegal move. The "King capture" principle is an exception, this is also possible but another story. In none of these cases you would get an infinite loop, otherwise you have to fix a bug ...

Checking if a move is legal is costly for you have to iterate over all moves to check if there is a king capture. So I don't like to add that to the search.

Wrong again. Reason for both is that you can check easily if the previous move was legal by checking whether the move left the enemy king in check, and that can be done much cheaper than you think. I believe I already wrote this about 10 times during the past 1-2 years in this forum, last time was only few days or weeks ago. A pseudolegal move can only be illegal in one of these cases:
a) it is a check evasion,
b) it is a king move,
c) it is an en passant capture,
d) or it is a move of a pinned piece.
In all other cases you can skip legality testing completely since the move is legal.

a), b) and c) are trivial to detect, in case of a) since check detection is needed anyway and check extension (which slightly improves strength!) requires it of course. Only d) needs one tiny bit of work. You could detect all pinned pieces prior to move generation and store them in one 64-bit variable (one bit = square of pinned piece of moving side). It will help a lot, you will see.

Solving mate in n puzzles quickly is not that important. I use it to check if alpha beta works correctly.

Apart from that last sentence which contains an important reason (testing!), you certainly need a flawless implementation of check detection and legality checking as one part of a strong search.

[hgm]

Check extensions only works if you only allow legal moves otherwise you get an infinite loop. (It took me two hours to understand what was going on. So I have had enough misery for today).

Ah yes, that sounds familiar. On a check it counter-checked?

The fix is move sorting, however, not testing for legality. When you sort capture of the most-valuable victim first, it should not be possible to play a counter-check before you found the move that captured the King. And the latter should always produce an immediate beta cutoff. When you generate all moves before you start searching any, you could even test for moves that capture the King in the move generator, and abort if you find one. It is a very cheap test to determine if the capture victim is a King. And generating the moves you had to do anyway, to play one.

[Sven]

Henk, please check your PM ...

[Henk]

Yes I now suspect my KingCapture method contains a bug. I think I have to replace it by a slow simple one for which I'm certain that it is correct. If the bug disappears then I know for sure.

[Henk]

Already found the bug(s). I disabled captures of sliders few weeks ago for Queen moves were implemented as the sum of rook and bishop moves.

But the replacement fall back code only worked for captures of non-sliders.

Strange that it took so long to find out something was wrong.

[Henk]

Biggest mistake was that the wrong move generator code was not used in the perft tests. Perhaps because it was slower.

[Henk]

I just tried the mate in 4 and Abbess solved it in well under a second.

Code: Select all

 1   -172       1        132 f2g1
 2   -252       2       3022 f2f1
 3   -231       8      51021 f2f1
 4  32760      28     367038 e4f6
 5  32760      63    1028552 e4f6

I've intentionally not added nullmove, hashtables or anything fancy yet, as I want to make sure the things I do are solid this time around. I do recaptures, check extensions, IID sorting, and that's about it. Pseudolegal move generation, with a not-in-check validation after the move.

I think one thing I realized from working on Beaches is that it is easy to hammer new features on early in the process, and they may improve the engine, even when they are broken.

But then it tends to be harder to go back and look at basic things later on, like move ordering. And after a few layers of these not-quite-right enhancements, your engine starts doing bad things at odd times, which is an even bigger nightmare to track down.

With check extensions plain AB + q search gives:

Code: Select all

Depth  Value   Time
  1  -11508.00   0.019          78   b2b4 
  2  -15171.00   0.046        2039   a3b3 
  3  -12228.00   0.307       25303   a3b3 
  4  9999997.00   2.500      220736   e4f6 
  5  9999997.00   24.172     2015883   e4f6