The site has moved to a new server, and there are now some issues to fix. Please report anything needing fixing with a comment to the homepage.

The Chess Variant Pages

[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order Earlier
Threatened Pawn Chess. Pawns start in threatened positions. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2019-09-09 UTC

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).

Greg Strong wrote on 2019-09-08 UTC

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.)

Greg Strong wrote on 2019-09-02 UTC

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.

H. G. Muller wrote on 2019-09-02 UTC

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.

Greg Strong wrote on 2019-09-02 UTC

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

Greg Strong wrote on 2019-09-01 UTC

At a search depth of 19, ChessV thinks white is up by a pawn and a quarter.  It actually playes d3e4, not e5f6.

The start of the PV is: d3e4 d6e5 d1d8 e8d8 f1c4 h6g5 c5b6 g4f3 a1a4 c8d7 c4b5 a8a6 ...

c4b5 is a blunder.  I'm concerned with it making a blunder in the PV at ply 11 when it has completed a depth 19 search.  Seems I have a problem somewhere, maybe in the transposition table.

But back to the original position - Stockfish 9 to a depth of 28 thinks white is up by a pawn and a half and likes e5f6 as the best move.  e5f6 g8f6 h3g4 e4d3 g5f6 d8f6 a1a4 b6b5 a4a2 b8c6 c1b2 fge7 h8g8


Kirill Kryukov wrote on 2005-02-19 UTC
Ouch, I meant rook at h8 is locked and easily lost.

Kirill Kryukov wrote on 2005-02-19 UTCGood ★★★★
This array is fun, but it seems that white can win by 1.exf6. I can't find
a good defense for black. Rook at a8 is locked and can later be taken by
white bishop. In some variants the rook survives, but the black's
position is falling apart anyway. Black is a piece down, or lost rook and
some pawns for a bishop, or something similar in all lines. This is highly
tactical position, so it's difficult to say, too many possible variations.
Can anyone suggest how black should play after 1.exf6 ?

I enjoyed this variant anyway. It is also a good test for chess engines,
many go crazy in this position, especially those having too agressive
search extension on capture.

8 comments displayed

Later Reverse Order Earlier

Permalink to the exact comments currently displayed.