Re: A Crime by a Board of Old Imposters

Robert Hyatt wrote:

> > To be a bit blunt: sound software engineering practice. The engine and 
> > the GUI perform different functions; functional decomposition mandates 
> > that you separate them with a clearly defined interface, in order to 
> > reduce the total complexity of the system.

> That's my point.  In a _good_ design, you separate, not replicate,
> functionality.

We agree on this. Now the question remains whether the initiative for 
claiming a draw should reside with the engine, or with the GUI.

> If the GUI is going to communicate with the outside
> world, it should be the software component that does that, from claiming
> draws to input and output (display) of moves.  Claiming a draw makes
> no sense for the engine, since it is not "talking" to the end-user.

My view is orthogonal to this. I say that "claiming a draw" is more 
properly viewed as a move (and is therefore more proper to be handled by 
the engine). I'd prefer to see (in the situation where 3-fold repetition 
is a possibility) the following valuation output from the engine, from 
best-to-worse:

1. +0.00   Kb2
2. +0.00   Kb2% { '%' annotates draw claim, threefold repitition }
3. -inf    g4

...where the engine elects to play Kb2, without claiming a draw. It may 
do so according to the rules; however, if it hides behind a GUI that 
tries to be clever, it can't.

> I _still_ don't see why it then matters in this event whether the GUI or
> the engine initiated the draw claim.  The point is that there is a single
> player on the white or black side of the board.  That _player_ has to
> make the decision, it doesn't matter whether it comes from the GUI, the
> engine, or in some cases _directly_ from the hardware (ie a special-purpose
> device like Belle.)

I can see, for reasons of practicality, why this is a nice thing to have 
(although there's still the issue of what to do if the engine and the 
GUI disagree).

However, if I plug my engine into something like Fritz using UCI, this 
will essentially rob me of options.

In the position 1kb5/1p1p4/1P1P4/7p/8/1p1p2P1/1P1P4/K1B5 w - -

Both players can repeat with king moves. They could also advance the 
pawn and lose. It is my contention that claiming a draw based on 
threefold repetition is not the best move; the best move is to move the 
king and wait for what the opponent does (you still have at least a 
draw, no matter what, and perhaps more). This goes for both engines, so 
the game could go on to infinity.

Crucially, with standard minimax, both moves (Kb2 with draw claim, and 
Kb2 without draw claim) resolve to a 0-score. However, not making the 
claim allows the possibility that the opponent will make a mistake; 
given a refined metric of "best" this would be preferable.

If I am ever to write a chess engine, it would want to just move the 
king the b2 (no draw claim). I'd be pretty annoyed if the GUI stepped in 
at a certain point and claimed a draw on my behalf.

> > Fair enough. Of course, the engine must be able to get input and output. 
> > It's only natural to separate this in two parts. I'd say this supports 
> > my view more than that it contradicts it.

> Yes, but my "engine" doesn't do draw offers either.  The front-end
> notices that after playing the move supplied by the engine, that the
> position repeats a position for the third time.  It then says:
>
> "I claim a draw by 3-fold repetition after playing the following move:"
>
> "white(46): Nf3+"
>
> So it would seem that you would want to reject _my_ draw offer as well,
> since the GUI does it without being prompted to do so by the engine at
> all.

No. Your algorithm for deciding when to claim a draw is different than 
mine would be, but it's all soundly within engine territory. You have 
basically delegated responsibility to handle draw claims to a layer 
(within the engine) that sits on top of your search algorithm. At the 
same time, your search algorithm can now rely on a draw claim being made 
by a layer above. That's fine for me.

At the same time, my hypothetical engine would handle this differently, 
by handling the Kb2 move as two different moves (Kb2 and Kb2%), with 
different valuations (although the minimax score for both would be 0.0).

> > > If I were doing a software engineering project, putting the draw
> > > claim stuff in the front-end makes perfect sense. 

> > I disagree. The possibility of a draw claim is something that the 
> > engine's evaluator should be aware of.

> You are mixing apples and oranges.  The engine has to find the best
> move.  And yes, it is aware that the move produces a draw score.  No
> it does not know whether the move repeats the position for the third
> time or what.  It just knows "If I play this move, it leads to a
> position that the search claimed was a draw for some reason."

My hypothetical engine would see two different moves, and be able to 
distinguish between them.

The word "move" has a lot of connotations with moving a physical piece 
from one square to another. But put that aside for a moment. A "move" in 
any game is an action by one of the players that will alter the state of 
the game. Two moves are distinguishable if and only if the state of the 
game after execution of the move differs. Since "Kb1" and "Kb1%", lead 
to a different state of the game (with "Kb1" the game is still in 
progress, with "Kb1%" it's finished) it makes perfect sense to me to 
consider these separate moves.

> The GUI has to recognize _why_ because the search engine doesn't return
> that information.  It just returns a best move and score for that move.
> See why I think the GUI is the _right_ place to actually _make_ the
> draw claim?  The GUI sees the _real_ representation of the chess board,
> with all the history, and can tell exactly why this is a draw.

I would agree that a layer has to sit on top of the move-generator that 
knows the history of the game (to be able to inject moves like "Kb2%"). 
If you like to handle this by delegating this responsibility to the UI 
(or even an external GUI), that's fine; as long as your engine makes 
valid moves. But this is just one solution to the problem (and, in my 
opinion, not the best one).

> Correct.  But it only says "play this move for a draw score".  The draw
> may be _right_ now after this move, or it might be a repetition or endgame
> table draw that is 40 moves away.  The engine doesn't distinguish between
> the two, because it doesn't matter to the alpha/beta search...

Sure, we agree that both Kb1 and Kb1% are valued at 0.0 by the 
alpha/beta metric. But this is not the end of the story: Kb1 is 
preferable over Kb1% in another metric. Your Crafty has a "swindle" mode 
that comes to mind: in drawn position, it will still try to optimize the 
odds for a mistake by the opponent.

> > All this leaves of course the interesting possibility that two chess 
> > programs will get in an infinite exchange of pointless moves, both 
> > refusing to claim the draw, if they can still force the draw later on, 
> > but there's also still a deadly mistake that could be made by the opponent.

> You should always make the move that leads to the draw farthest away, to
> give your opponent a chance to make a mistake.

Ok, so would you agree (in the position given above), that Kb1 without a 
draw claim is the preferred action to take (even if this has been going 
on for 10,000 moves)?

> > I passionately disagree. The claiming or not claiming a draw is a 
> > tactical decision, that naturally belongs with the engine, in my 
> > opinion. It is good software engineering practice to implement 
> > functionality in the right place, not in a place that is (in most 
> > circumstances) able to evoke similar behavior by accident.

> See above.  This is simply wrong.  Until you actually write an alpha/beta
> tree search, it might not be obvious why, but if you read my comments above,
> you will see why it is wrong.

I have read them with great interest. One of us is obviously missing a 
point made by the other side... Or perhaps both uf us :-)

> > - Notwithstanding our almost total disagreement on this (perhaps rather 
> > philosophical) issue, I am grateful that you take the time to explain 
> > your view; at the very least, this forces me to state my thoughts as 
> > clearly as I can.
>
> Me too.  :)

That's nice to know.

Best regards,

  Sidney