Ratings & Comments

Thanks for the clarification.

I was able to re-associate the two existing game logs with your new Wildebeast9 preset and delete the old one.

Great, thank you.  That is what I had expected.  I will update the page to incorporate this.

OK. Thanks!

I would also like clarification about the promotion rules. The way I interpreted the rule as you wrote it, promotion to queen would be mandatory if you didn't have one, otherwise mandatory promotion to wildebeest. Which bothered me, because in my current game with Greg Strong, in one quite possible line, I would prefer wildebeest to queen. Underpromotion is a great mechanic, so it would be nice to be able to promote to lesser pieces if desired.

dax: About promotion, I would prefer the Queen Wildebeast rule, however, if you get a 2nd person to make that request, I will change to code so that promotion can be any lower piece.  I will keep the 1 queen rule though.  :)

Note that the Wildebeest does not have mating potential in your game. (Unlike in Wildebeest Chess, where stalemate also is a win.)

Also note that you do not consistently use the same spelling for the name of the piece, and that the promotion rule as described in the article (twice!) says indeed something entirely different from what Greg wrote. And, to really nitpick, that "all other cases" to that where you do not have a Queen is just the single case where you do have one.

HG:  I took your suggestions and attempted to re-write the section on the promotion.  I think I used the name Wildebeast everywhere, except in the Introduction.  (I can't find the misspelling)  When I wrote the code, I assumed that the Horseman could get to the promotion zone with more ease than a pawn.  I guessed that there would be more promotions in this game.  Can a king and two horseman put a bare king in checkmate?  I will try this and run some tests.  If the answer is yes, I like my promotion rules "as is".  If the answer is no. I probably should fix/adjust the promotion rules.  If you dislike the promotion rule, I am open to suggestions.  I think I have 1 vote from dax for promotion to other pieces like knight, rook, bishop, etc. 

I think the easiest solution is just to make stalemate a win so king + wildebeast can win against bare king.

I don't see any need to change the promotion rules though.  Even if you don't change stalemate, promotion is not an issue.  You are only forced to promote to wildebeast if you do not have a queen, in which case you promote to a queen and can checkmate easily.  The only other case I see is the unusual position where you don't want to promote to a queen because that would stalement immediately, but since the horsemen promote on the 7th rank I don't think that is possible.

Ok, I've found the issue.  It was the result of a recent change.  To limit explosion in the size of the search tree by quiescent search, I was only doing four full plies of qsearch after which I was considering recaptures only. The problem is that I didn't have an exception for instances where the king was in check. So if the king couldn't get out of check with a recapture it was scoring the position a mate.

ChessV now agrees that e5f6 is the best move. e5f6 h6g5 f6f7 e8f7 d3e4 c8e6 f1c4 e6c4 b3c4 a8a5

This would not only bite you when you limit QS depth. Even if you do an unlimited-depth capture search, you would see phantom mates if you don't consider non-capture evasions (interposition or King withdrawal). You either must consider all evasions (effectively switching back to a d=1 search) on a check, or you should allow stand-pat even in the face of a check, assuming that a non-capture evasion that doesn't give away any score always exists. (Which would obviously make you overlook true checkmates in QS. This is not as bad as it sounds, as most checks are indeed not checkmates.)

QS explosion is a serious concern in general variant engines. MVV/LVA sorting might not be good enough to suppress plunder raids if capture modes other than replacement are possible. E.g. Lions in Chu Shogi are disastrous, when they can jump into the opponent's camp to a save square, and then then just sit there eliminating all neighors in combinatorially many different orders. Fire demons are even worse.

Yeah, I was generating all check evasions in QS, I just forgot to make that exception when it switches to recpature only.  I added the limit because the QS explosion was so bad it basically didn't move when I implemented Evolution Chess.

Wow, QS explosion is a serious problem.  Now that I have allowed all check evasions in the QSearch, I have my search stack overflowing very quickly in Gross Chess and my stack supports a depth of 128!  After four plies of QS it considers only recaptures and check evasions and I still had over a HUNDRED plies.  I figured something had to be broken with my 3-fold repetition detection, but not so...  In Gross Chess you can literally have over a hundred consecutive moves of nothing by check evasions and recaptures to the last square without triggering repetition.  I would not have thought it possible had I not spent a couple hours manually stepping though about 50 plies until I was convinced it was for real.  (It has a lot to do with the cannons - you can often escape check by moving into the path of your own cannon to become a screen and check the opponent king.)

So I appreciate your previous message or I would probably have been at a loss as to what to do about this.  I've now switched to this:  first four plies of QS are all captures and check evasions; after four plies it switches to only recaptures and check evasions; after eight plies of QS it starts to allow standing pat even when in check (returning the static evaluation rather than -INFINITY.)  This has stopped the search explosion.  I'm now running a 1600 game Capablanca match against FairyMax to ensure this doesn't hurt my search strength too much.  (Seeing as most games don't have the kind of search explosion problems that Gross does but I'd like to keep the search function the same across games if possible.)

I had similar problems in Shogi, when I tried to search check drops in addition to captures. Some lines just continue forever, and with depth-first that is of course fatal. This looks especially stupid when alternative moves to the infinite line in many places include a mate-in-1, which would have alpha-beta pruned the infinite line had they been searched first. So I tried a scheme with an iteratively deepened QS that would back up score intervals rather than one-sided score bounds (and would return {standPat, INF} for QS nodes with captures that were too deep to search), deepening it until the interval in the QS root collapsed to a single value. This way you would find the closest forcible (through QS moves) mate before searching any deeper lines. But this still wasn't enough to make the problem disappear, so I abandoned that again, and only search captures now.

The problem is that this is really very wrong in games with piece drops. Even recapture exchanges are often meaningless there, as the capture of a protected piece might give the opponent the piece in hand that he needs for an all-check-drops mate, so that you cannot afford to recapture. It seems Bonanza in every QS node first does a 3-ply checks-only search to see if it can checkmate that way, and if it cannot searches only captures (or stand-pat).

Even most engines for orthodox chess limit the search of checks to the first two ply of QS. They are furthermore selective in what checks they search, and usually prune those that can be evaded by a SEE > 0 capture on the checking piece.

It is still an open question for me how, when you have a QS that also is controlled by a depth parameter, you can best increase the tree size in an iterative deepening scheme. The simplest way would be to just keep the QS depth fixed, and iterate the depth of the full-width search as usual. I suspect this is very sub-optimal, though, as it requires the tactics that QS misses because of the depth limitation to be discovered by the full-width part. Which is not only the most expensive thing you could do in the leading plies from the position that was too complex, but adds to the tree everywhere. It leads to the complex tactics being resolved only when the branches ending in simple tactics (presumably the large majority) have already been deepened too, while the resolved score could be such that it upsets the entire tree, making most of the deepened lines irrelevant.

Increasing the depth of individual QS until they converge OTOH leads to very much (possibly infinite) effort on QS that in the end might turn out to have scores that makes the branch leading to them irrelevant. Iteratively increasing the QS depth limit in the tree as a whole before increasing the depth of the full-width search would waste a lot of time walking the same full-width tree in parts where you encounter only QS that have already converged for the current depth limit.

I have the feeling it should be possible to control the search depth with a single parameter from the root, which would both increase the QS depth limit and the full-width depth as it grows. E.g. with a QS that does an M-ply all-capture search followed by unlimited-depth recapture-only, you could keep track of whether the QS actually did prune any captures that were not recaptures. If there were, M was not large enough to converge the QS, and would have to be increased. The search could be made to converge the QS first, before being allowed to search any non-captures. E.g. by counting each QS ply as half a full-width ply, and when an N-ply search is requested, start with a QS there, increasing the QS depth limit to at most 2N. If QS converges before that, it all moves with a d=N-1 reply (or applicably further reduced), if not, it just returns the unconverged QS result (signalling to the parent that it cannot yet switch to full-width).

Nice!

Ben, if you liked the sentry example, here's another one, a bit trickier. White to move and mate in 5: