Arasan, repetition and insufficient material

[bob]

Why should it be wrong to claim an immediate draw in analysis mode, if a draw is the optimal result? Playing a move first seems as wrong to me as reporting a mate in 5 (in analysis only) when you can in fact give a mate in 1, just because "the user likes to have as long a PV as possible in analysis mode"...

Can you claim a draw in analysis mode for engines that implements uci protocol? When the gui sends "go infinite" to the engine, the gui is the boss.

Code: Select all

*go
	* infinite
		search until the "stop" command. Do not exit the search without being told so in this mode!

So the engine will send,
info depth 1 score cp 0 time 10 nodes 100 pv 0000 0000 0000 0000
then the gui will send the stop command, and the engine will reply with
bestmove 0000.

In Arasan's case there are still legal moves, I am not talking about game playing, but in analysis mode.

Can you REALLY "think forever"? My program has a depth=128 max ply limit. Every program I have looked at has such a limit. What should it do when that limit is reached?

It really is a shortcoming to demand that an engine send a "move" command always. If you are stalemated or mated, I don't know what you would send. For repetitions/50 move draws, most of us will keep on playing even though we have claimed a draw, but I won't if I am stalemated, as there is nothing I can do, legally.

[jdart]

The protocol doesn't require you to think forever. If the search terminates early you enter the UCI wait state and you don't exit out of it until you receive "stop".

--Jon

[Ferdy]

Where is your way of claiming a draw in analysis mode for UCI engines?

[Ferdy]

Why should it be wrong to claim an immediate draw in analysis mode, if a draw is the optimal result? Playing a move first seems as wrong to me as reporting a mate in 5 (in analysis only) when you can in fact give a mate in 1, just because "the user likes to have as long a PV as possible in analysis mode"...

Can you claim a draw in analysis mode for engines that implements uci protocol? When the gui sends "go infinite" to the engine, the gui is the boss.

Code: Select all

*go
	* infinite
		search until the "stop" command. Do not exit the search without being told so in this mode!

So the engine will send,
info depth 1 score cp 0 time 10 nodes 100 pv 0000 0000 0000 0000
then the gui will send the stop command, and the engine will reply with
bestmove 0000.

In Arasan's case there are still legal moves, I am not talking about game playing, but in analysis mode.

Can you REALLY "think forever"? My program has a depth=128 max ply limit. Every program I have looked at has such a limit. What should it do when that limit is reached?

It really is a shortcoming to demand that an engine send a "move" command always. If you are stalemated or mated, I don't know what you would send. For repetitions/50 move draws, most of us will keep on playing even though we have claimed a draw, but I won't if I am stalemated, as there is nothing I can do, legally.

In UCI protocol the engine may send bestmove 0000, if told to search for a move in a position where there is no legal move. The 0000 is called a nullmove.

[hgm]

Where is your way of claiming a draw in analysis mode for UCI engines?

OK, I see what you mean: the 'bestmove' command would only be received by the GUI when you stop the analysis. While you want something for the GUI to display during the search.

In principle sending an empty PV with a null score would not be illogical, but it might be confusing to users. Having a single null move as PV would be a (IMO less-elegant) solution; it removes the impression that the engine is somehow not working.

The more user-friendly option would just be to notify the users, with

info string position is a draw because of insufficient mating material
info string claim draw by 3-fold repetition

and just print an empty PV:

info depth 15 score cp 0 pv

(Note that it can make sense to continue analysing to ever increasing depth for draw claims, as making those is optional, and it is conceivable that at low depth you think any continuation would make you come out worse, but at some larger depth suddenly discover a winning line.) An alternative might be to print

info depth 9 score cp 0 info rep-draw claim

i.e. put in an info field rather than a PV.

[sje]

My program has a depth=128 max ply limit. Every program I have looked at has such a limit.

Symbolic uses two-way linked lists for all ply-indexed data structures, so it has no MAXPLY constant. Note that if a PV resident in the search tree can be extended via the tablebases, then the value of MAXPLY would have to be in the hundreds or more.

A truly safe MAXPLY value would be around 12K, the maximum game length.

----

A related idea is to have a high watermark variable; set this to zero at the start of a search and then check its value at each node:

Code: Select all

if (watermark < ply)
{
  watermark = ply;
  printf("New high watermark: %d\n", watermark);
};

This can be useful to see when a search might be getting out of control.

[Ferdy]

Where is your way of claiming a draw in analysis mode for UCI engines?

OK, I see what you mean: the 'bestmove' command would only be received by the GUI when you stop the analysis. While you want something for the GUI to display during the search.

In principle sending an empty PV with a null score would not be illogical, but it might be confusing to users. Having a single null move as PV would be a (IMO less-elegant) solution; it removes the impression that the engine is somehow not working.

The more user-friendly option would just be to notify the users, with

info string position is a draw because of insufficient mating material
info string claim draw by 3-fold repetition

This is indeed a great way of sending info to the user of what is the situation on the board/position.

and just print an empty PV:

info depth 15 score cp 0 pv

(Note that it can make sense to continue analysing to ever increasing depth for draw claims, as making those is optional, and it is conceivable that at low depth you think any continuation would make you come out worse, but at some larger depth suddenly discover a winning line.) An alternative might be to print

info depth 9 score cp 0 info rep-draw claim

i.e. put in an info field rather than a PV.

UCI specifies only one info command when sending additional infos, like depth, pv and others.
So probably something like this.
info depth 9 score cp 0 string rep-draw claim

I experimented sending this kind of info when there is 3-fold reps in a position on analysis mode. Winboard did not show this perhaps it did not send the position when there is already 3-fold reps. Arena will not also show this, but if you separate sending of info string <message> from info depth 2 score cp 0 ..., it will show the message in the info string command.



Under Fritz gui, I use v13, it's a bit different, it has Engine Output window where all info string <message> from the engine will be displayed here. I have known this window before but just found out that this is used for info string command for uci engines. There might be other uses of this window.
When this window is opened all info string are recorded, it does not clear, it just keeps on showing there. Now the engine can communicate to the user what it thinks of the pawn structure, talks about the mobility and the threats it has considered.

This could be useful to Fernando.

info string Are you going to play that boring Petroff opening again today?