DIR Return Create A Forum - Home
---------------------------------------------------------
The Chess Variant Forum
HTML https://chessvariantforum.createaforum.com
---------------------------------------------------------
*****************************************************
DIR Return to: General Discussion
*****************************************************
#Post#: 675--------------------------------------------------
Re: Games against Programs
By: HGMuller Date: March 28, 2018, 12:18 pm
---------------------------------------------------------
I would say the the gain of 625 is about right, because you gain
a Queen for a Knight. That as a side effect black gates his Hawk
should not discourage you, because it is reasonable to assume he
would gate that Hawk anyway on some later move. So it should at
most be accounted as a tempo gain for black, a small positional
advantage.
That in this particular position the gating possibility can be
destroyed, is a-typical. A program that speculates "he has not
gated it on this move, so now he will never be able to gate it"
for no particular reason (which is what ignoring the value of
hand pieces amounts to) will be wrong in >99% of the nodes where
it makes this speculation. If it would assume that the gating
will simply occur later, it would have been right in 99% of the
cases. But not here, as this position belongs to the other 1%.
Making wrong speculations in static evaluation is in general
very detrimental, because search is very clever to find a path
that has exactly the number of moves to make the position a leaf
where the speculation is made. You would really want to reduce
the fraction of wrong speculations as small as possible. Which
is a real problem when you have to decide about something that
goes one way in ~50% of the cases, and the other way in the
other 50%. Just assuming the average of the possible outcomes
often makes things even worse, as it is wrong in 100% of the
cases.
The common case in Chess is that when you have a piece, you will
be able to hang on to it, if you have the move. And that if you
don't have the move, you will only lose it if the opponent can
capture it immediately. This is why we do QS as we do it: stand
pat or make a capture. You don't assume loss of material unless
the search has proven loss of material. (And that should then
also hold for the gating possibility associated with the
presence of that material.) In the case of forks and skewers
this assumption fails, but fortunately forks and skewers are
pretty rare in the tree.
Another way to look at this is that you should place the 'burden
of proof' on the unlikely result. This is why patterns for
things like a Bishop trapped on a7 by a protected Pawn on b6
helps: such a Bishop will almost always be lost, even though you
still have it, and is thus one of the cases where the default QS
assumption fails. But fortunately one that can be easily
recognized staticly. So you recognize that pattern, and invert
the burden of proof, only counting the Bishop when the search
can see a way to break the pattern without losing it. Another
notorious case is the KQKP end-game with a 7th-rank Bishop Pawn
where the defending King protects the promotion square. The
default assumption with regard to promotion is that a Pawn is
not counted as a Queen, not even on 7th rank. (Although you can
perhaps count it as 2.5 Pawn.) So the side with the Queen would
count itself way ahead as long as the Pawn is still a Pawn, and
it can basically keep up that situation forever by keeping
checking from all over the board, avoiding repetitions. So you
would have to search extremely deep before the program would
recognize it as a draw, much deeper than the program can search
at the move where it commits to the situation. Inverting the
burden of proof, assuming that 7th-rank Bishop Pawns (and Rook
Pawns, for that matter) will promote in KQKP (and thus draw),
unless the Queen is on the promotion square, already solves it.
You don't even have to do complex static tests to see if the
King protects the promotion square, because when he doesn't a
quite shallow search will already be able to see that you can
get your Queen on that square, to revert to normal scoring.
#Post#: 676--------------------------------------------------
Re: Games against Programs
By: GothicChessInventor Date: March 28, 2018, 5:17 pm
---------------------------------------------------------
[quote author=HGMuller link=topic=56.msg675#msg675
date=1522257489]
That as a side effect black gates his Hawk should not discourage
you, because it is reasonable to assume he would gate that Hawk
anyway on some later move. So it should at most be accounted as
a tempo gain for black, a small positional advantage.
That in this particular position the gating possibility can be
destroyed, is a-typical. A program that speculates "he has not
gated it on this move, so now he will never be able to gate it"
for no particular reason (which is what ignoring the value of
hand pieces amounts to) will be wrong in >99% of the nodes where
it makes this speculation. If it would assume that the gating
will simply occur later, it would have been right in 99% of the
cases. But not here, as this position belongs to the other 1%.
[/quote]
I partially agree and I partially disagree. As you indicated,
for the vast majority of the cases, the pieces will get into
play, one way or another.
But is a piece off the board, unable to move, really worth the
full value of its force if it were on the board? Perhaps the
very definition of an overly-hypothetical example, akin to a
pinned piece being temporarily worthless (yet its full value
stays in tact).
What vexes me: Non-leapers behind the wall of pawns can get
permanently stuck with as few as 2 pawn pushes in a locked pawn
chain. They're done. The whole game will play out and they won't
make a move. While not forced, just a few careless moves can
create the situation.
Furthermore, it is possible to play the opening without pushing
a single pawn and be way ahead, as in the example most recently
shown here. The game is Planchet vs. Viswanathan Raman on
Jocly.com and the program's 2 knights deployed, introduced their
Musketeer counterparts, and the Queen was chased around before a
single pawn push. The game was won before the first pawn move.
Using the Compound Piece Evaluator, the program would not think
it was that far behind for most of these lines where Planchet
saw it was ahead by an avalanche and a half.
And the program sacrificed a Knight to create the position shown
here, which it would never have done unless certain the
Musketeer pieces were trapped.
It is a difficult thing to try to program, and I think my
Alpha-Beta-Gamma-Delta search has solved it nicely. It evaluates
the position both ways: with and without compound pieces.
Neither method can fully maximize without some "consent" of the
other evaluator. It is the perfect blend, once all of the
details are fully resolved. The program uses singular extensions
to examine lines that are promising "entombers" of Musketeer
pieces without bogging down the search. Likewise, captures that
delete the compound piece are sought after specifically rather
than just "chance encountered" through the normal searching
process.
I'll see if I can post some examples. What is apparent: A new
way to search was needed.
#Post#: 677--------------------------------------------------
Re: Games against Programs
By: HGMuller Date: March 29, 2018, 3:05 am
---------------------------------------------------------
Well, is a Rook on a1 behind a wall of Pawns really worth a
Rook? Basically the only thing it does is protect one of the
Pawns. The early middle-game is dominated by Knights and
Bishops, which can easily jump over Pawns or sneak between them,
and it takes a long time before Rooks become of any use. Yet,
allowing the corner Rook to be traded for a minor early in the
opening is a losing strategy. It is an empirical fact that the
value of pieces is highly dominated by the value they will have
in the end-game, perhaps for as much as 90%, and only for a
small part by their current activity on the board. Of course the
latter counts for something, and this is why engines use
Piece-Square Tables and calculate mobility as evaluation terms.
But the contribution of those (for a single piece) is typically
in the sub-Pawn range, and over-weighting them makes the engine
pursue a very aggressive, but in the end losing strategy.
So yes, still having an ungated piece is bad, because it has no
mobility, and exerts no board control. But that is hardly
different from keeping your Knights on b1/g1. It isn't really
different from any other undeveloped piece. (Except perhaps that
it also causes a vulnerability that the gating can be made
impossible by capturing the piece on the gating square, so that
the effect is somewhat larger.) Normally PST are used to take
that into account, effectively making the value of pieces
(slightly) dependent on their location on the board. This can
also be done for the value of the ungated piece, making it (say)
30 centi-Pawn lower than what it would be on the back rank.
(Which then again might be 30cP lower than what it would be in
the center.) And adding that discounted value to the compound
piece. If you really want to be subtle, you could dynamically
calculate the 'vulnerability penalty' from how well the opponent
is developed (or just increase it with move number), putting
more urgency on the gating of the piece as the opponent deploys
his pieces, and could possibly direct them at the virgin pieces
on the gating squares. The fact that the ungated piece has no
mobility should be accounted for automatically by the way you
calculate mobility.
Permanent trapping of pieces is an area where engines are
notoriously stupid. IIRC there was an Alpha Zero vs Stockfish
game where Stockfish had trapped its own Bishop on the f1-g2-h3
behind blocked Pawns at e2-f3-g4. Hilarious to human players,
but Stockfish of course insisting that Bishop was still worth a
full Bishop (and embarrassingly losing the game). Other common
cases with weak programs are a Rook on h1 with their King on
f1/g1 (after a check destroyed their castling rights, and they
decided to walk the King to safety behind the f2-g2-h2 Pawn
shield on their own initiative. And in the end-game a white Rook
on a1 with a black Pawn on a2 and a black Bishop on b1. The
point is that such trapped pieces have no future at all, no
matter how long the game continues and how much of the other
pieces disappear. So they will never get to the point where
their normal end-game value will be realized. For programs it is
quite hard to recognize such situations, however. They of course
apply the penalty for the piece being rather inactive at the
moment, but that penalty is tuned (to a rather small value) on
the assumption that sooner or later this situation will be
corrected. Which is almost always true, but not quite. Likewise,
it seems very hard to statically detect situations where you
still have the virgin piece at the gating square, but you will
never be able to gate.
#Post#: 679--------------------------------------------------
Re: Games against Programs
By: GothicChessInventor Date: March 29, 2018, 5:23 pm
---------------------------------------------------------
[quote author=HGMuller link=topic=56.msg677#msg677
date=1522310702]
Well, is a Rook on a1 behind a wall of Pawns really worth a
Rook? Basically the only thing it does is protect one of the
Pawns. The early middle-game is dominated by Knights and
Bishops, which can easily jump over Pawns or sneak between them,
and it takes a long time before Rooks become of any use.
[/quote]
Yes, and this is why I alluded to my remark as being about as
hypothetical as one could get. I knew we each could cite
examples and counterexamples, none of which help us code an
appropriate solution. I did come across a rather nice coding
trick today I should have tried first:
HTML https://preview.ibb.co/k8Mrs7/Hawk_Trap_depth_09_solved.jpg
HTML https://ibb.co/npeNzn
This is the dreaded "White Hawk Threatens Mate And Queen Capture
Simultaneously" position that Planchet could not resolve with a
search to depth 9 previously. Now it finds the correct move,
...d6! in about one second.
The idea I implemented: Adding Piece Deployment moves to the
Quiescence() search! Simple. Quiescence() generates all captures
until there are none, and then performs additional tests to see
if piece drops are available. It does not consider the position
ready for evaluation until all deployment moves have been made,
or none can be made even if given the chance to move twice in a
row (NULL move, kind of), or all deployable pieces have been
captured.
Early on it really bloats the game tree but it finds the moves
leading to the sharpest cutoffs, and compounded with the history
heuristic, it flies through the move list on subsequent search
depths.
#Post#: 683--------------------------------------------------
Re: Games against Programs
By: HGMuller Date: March 30, 2018, 2:19 am
---------------------------------------------------------
Well, as I mentioned at the bottom of my first posting on this
page, it is essential for any search to work well that QS
examines all moves that cause a large immediate score gain (to
test if there is a backlash). If gating a piece 'gains' its
value, that definitely would count as a large immediate score
gain.
So searching the gating moves in QS should definitely ameliorate
things. But it does not solve it entirely; in the same posting I
also mention that you have to prevent the stand pat if there is
such a threat against you (i.e. if the side not to move in QS
can gate). Otherwise you get the same problems as are typical in
searches that do not use a QS at all: the program tries to grab
the most valuable target it can get at the last move before the
horizon, even if it is protected, because it is blind to the
recapture. So the engine would concentrate its efforts on
manoeuvring to get a shot at Q x protected N. When the opponent
still has, say, a Chancellor to gate, he now has the choice to
gate it, (and lose the Knight), or to recapture the Queen.
'Losing' the Chancellor in addition to the Knight, because the
other side will now stand pat (a comfortable Knight ahead) to
make sure the Chancellor gating will remain beyond the horizon.
In reality of course the Chancellor will almost always be gated
on the next move, whatever he plays instead of the stand pat,
leaving him down Q vs N.
Focussing on one particular position is very dangerous. In
computer Chess it is almost always possible to find a search
technique that speeds up finding the good move in that position,
but turns out to weaken the engine in real games. This is even
true for sets of test positions like the WAC test suite: people
that tune their engine to perform best on WAC typically find
this causes a hefty Elo reduction. To measure the merit of any
search strategy you really should play games. Which, admittedly,
is a bit hard for testing a method designed for handling the
gating, as during most of the game you would have nothing to
gate. To make sure the search strategy has an easily measurable
effect on game results, you would have to go through an
artificial situation, where gating is possible for most of the
game. E.g. by giving the players a new piece to gate every 10
moves. Or better, every time the total material on the board has
dropped by ~30 Pawn values (so that they then each get a piece
worth ~7 Pawns back, and the total material still decreases over
the game).
#Post#: 684--------------------------------------------------
Re: Games against Programs
By: GothicChessInventor Date: March 30, 2018, 1:22 pm
---------------------------------------------------------
[quote author=HGMuller link=topic=56.msg683#msg683
date=1522394360]
So searching the gating moves in QS should definitely ameliorate
things. But it does not solve it entirely; in the same posting I
also mention that you have to prevent the stand pat...[/quote]
I already discharge stand pat. I don't restrict where else in
the search I test for gating moves, so it's in Quiescence() and
in the nominal Search() routine. The ONLY instance where my
current setup is vulnerable is if it takes more than 2
consecutive moves to gate a piece AT THE END of running every
non-quiescent position to (otherwise) perfect tranquility at the
current depth + extended depth. The deepest such probe I have
seen so far is 47-ply at nominal depth 13, and there must be
virtually no chance a program could have played best moves in a
pv line that deliberately delayed gating one or more pieces for
so long due to their being greater rewards to reap afterward.
There might be a dozen such positions in all of 64-bits worth of
search space.
[quote author=HGMuller link=topic=56.msg683#msg683
date=1522394360]Focussing on one particular position is very
dangerous. [/quote]
You're jumping to conclusions. I have a growing suite of test
positions that run automated with a single command. I have a
text dump of the results. In each improved code set, fewer nodes
were examined, time to depth decreased appreciably, the pv lines
stabilized and made sense up to 2-ply sooner, the branching
factor decreased, and the numerical score for the line made more
and more sense. If I published all of my tests here, I wouldn't
have enough time to get all of my tests done :)
[quote author=HGMuller link=topic=56.msg683#msg683
date=1522394360]In computer Chess it is almost always possible
to find a search technique that speeds up finding the good move
in that position, but turns out to weaken the engine in real
games. [/quote]
That does not apply here. This is a massive improvement to the
code. Massive. As in worth probably 300 elo compared to the old
program. This was a huge improvement, mostly because the older
technique was so poorly matched to the task at hand. Just look
at the positions the program used to misplay: Losing a Queen for
a Hawk after move 2 of the game after a deep search vs. now it
finds the correct defensive move in 1.5 seconds with NO SPECIFIC
KNOWLEDGE aimed at correcting the miscue. This was search
improvement, not knowledge encoding.
#Post#: 687--------------------------------------------------
Re: Games against Programs
By: HGMuller Date: March 30, 2018, 2:40 pm
---------------------------------------------------------
I don't understand what you mean by "discharge stand-pat".
*****************************************************
DIR Previous Page
DIR Next Page