Arena "sd=9999"

[Laurens Winkelhagen]

Ideally the winboard protocol would support an 'sd -1' command to set the maximum search depth (back) to infinite.

[hgm]

The true problem is that 'infinite' is not supported by hardware. If you ask for a TC of billion minutes, your computer will crumble to dust before producing a move. So 1 billion minutes is a very satisfactory representation of infinite time, like 9999 is a very satisfactory representation of unlimited depth.

You claim that there exist engines that cannot handle a new command? That is by definition a bug. The new command can come at any time in WB protocol, to force a reset of the engine. WinBoard would send a new before it would sent the engine a new level command, when the user selected a new time control...

What exactly is the bug in WB protocol that you perceive?

Protocol v3 will probably never be implemented, apart from a few features (such as the debug feature, which I already did implement). Most of it I did not like, and when puting up the few features that I considered useful (e.g. multi-session TC) for discussion, it turned out that others do not like the way v3 proposed to implement them at all. And I have already implemented several badly needed features that were not addressed in v3 at all (e.g. SMP cores and memory size).

[Christopher Conkie]

The true problem is that 'infinite' is not supported by hardware. If you ask for a TC of billion minutes, your computer will crumble to dust before producing a move. So 1 billion minutes is a very satisfactory representation of infinite time, like 9999 is a very satisfactory representation of unlimited depth.

You claim that there are engins tht cannot handle a new command? That is by definition a bug. The new command can get at any time in WB protocol, to force a reset of the engine. WinBoard would sent a new before it would sent the engine a new level command, when the user selected a new time control...

What exactly is the bug in WB protocol that you perceive?

Protocol v3 will probably never be implemented, apart from a few features (such as the debug feature, which I already did implement). Most of it I did not like, and when puting up the few features that I considered useful (e.g. multi-session TC) for discussion, it turned out that others do not like the way v3 proposed to implement them at all. And I have already implemented several badly needed features that were not addressed in v3 at all (e.g. SMP cores and memory size).

Hehe

I knew you would bite. I only quoted what you said in an earlier post and what Martin said.

Don't shoot the messenger.



For what it is worth, there will be an Arena 3.

[Christopher Conkie]

Ideally the winboard protocol would support an 'sd -1' command to set the maximum search depth (back) to infinite.

What a good idea. Maybe Daniel and/or HG could consider that suggestion.

Christopher

[hgm]

Wel, messenge the question to Martin, then, because I am still curious why he thinks there is a bug.

Note that WB protocol does not specify that you cannot send multiple sd commands during a game. It does not even specify that you cannot send multiple level commands during the same game. It just does not specify how multiple level command, or level commands after the game has started, should be interpreted. I fixed that omission in my clarified version of the protocol, but this seems to meet with much resistance.

Anyway, in the given situation (before the game has started), it seems silly not to send a new, and resort to a kludge to represent infinity instead.

Ideally the winboard protocol would support an 'sd -1' command to set the maximum search depth (back) to infinite.

Actually sd 0 is considered as such in WinBoard internally, so it will never be sent to the engine (relying on new to do the job).

[Laurens Winkelhagen]

Hmm, I think I'm misunderstood in part (not that there is anything new about that^^)

not sure which messages are a reply to whom but:

- I would propose that one could send 'sd -1' in the middle of a game, to countermand previous 'sd' commands. This would be usefull to limit playing strenght of an engine mid-game. Of course -infinite- is not the correct word, but would you consider: unlimited?

- 'sd 0' as a command to engines could have the same effect naturally.

- unfortunately all of this would require a new feature to be set by winboard engines to allow for backward compatibility. Unprepared engines could react in unforseen ways. I dislike the need to communicate a new feature to be honest.

[Christopher Conkie]

Wel, messenge the question to Martin, then, because I am still curious why he thinks there is a bug.

We are just joshing with you.

I've showed him what you wrote.

Christopher

[hgm]

Hmm, I think I'm misunderstood in part (not that there is anything new about that^^)

not sure which messages are a reply to whom but:

- I would propose that one could send 'sd -1' in the middle of a game, to countermand previous 'sd' commands. This would be usefull to limit playing strenght of an engine mid-game. Of course -infinite- is not the correct word, but would you consider: unlimited?

- 'sd 0' as a command to engines could have the same effect naturally.

- unfortunately all of this would require a new feature to be set by winboard engines to allow for backward compatibility. Unprepared engines could react in unforseen ways. I dislike the need to communicate a new feature to be honest.

Indeed, adding such a command is asking for backward-compatibility trouble. And for no good reason, as the existing command sd 9999 woud in practice do the same.

My take on this is that there is no logical reason to forbid resetting the time control of an engine mid game.

[bob]

as far as I know you should implement the "sd" command as a limit, not as an order: I mean, the engine should not think deeper than 9999 ply, but it's very much allowed to think less:-)

I must say that if that is true, it is a truly stupid interpretation of that command, which several programs have been using for 20+ years. In Crafty, sd=n says to search N plies deep. Period...

From the defintion of WB protocol v2 on Tim Mann's web page

sd DEPTH
The engine should limit its thinking to DEPTH ply.

/depth or /searchDepth number

Tells the chess engine to look ahead at most the given number of moves when searching for a move to make. Without this option, the engine chooses its search depth based on the number of moves and amount of time remaining until the next time control. With the option, the engine will cut off its search early if it reaches the specified depth.

Seems to me the words 'limit' or 'at most' (underlining is mine) are quite unambiguous. For those still in doubt, we can see how Tim Mann's WinBoard / XBoard implements it, and it always sends both the level command and the sd command (when non-zero argument was requested). The code for this in WB 4.2.7b goes accompanied by the comment:

Code: Select all

    /* Orthogonally, limit search to given depth */

Also here, 'orthogonally' leaves little doubt.

So it seems Crafty (and perhaps several other programs that have been using the sd command for 20+ years ) have a faulty, or at least non-compliant implmentation of sd.

I can add tha both my engines implement sd correctly, i.e. as a limit, that should be obeyed in addition to the time limits specifid by the st or level commands.

In looking at Crafty log files, it _never_ receives any sd=N command from xboard. I am not sure what you are looking at, but I've been running under xboard since 1995, and have not seen this particular thing come up in any versoin of xboard I have used to date. It would have broken Crafty significantly had this been happening.

I think your interpretation is "too narrow". The "at most" came from the issue that at times, you don't need (nor want) to search to the sd=N depth. Such as when you have found a mate and have searched deep enough to know there are no shorter mates to be found.

The way you think it should work makes no sense to me. If you set a time limit, what sense does a depth limit have? If you set a depth limit, what sense does a time limit have? The two really are (or ought to be) mutually exclusive since they are limiting the search in totally different ways. And to assume that this is simply a "max" makes little sense. Who knows what a program will do with st=6 and sd=5??? Is six seconds enough time to reach depth 5? if not, we stop after 6 seconds? If 6 seconds is more than needed to reach depth 5, we stop after 5 plies? That is ambiguous enough to make no sense to me...

But the versions of xboard I use do not have the problem anyway, don't know what version you have that is sending SD along with the level command, but the two versions I have here do not do that...

[Laurens Winkelhagen]

...

But the versions of xboard I use do not have the problem anyway, don't know what version you have that is sending SD along with the level command, but the two versions I have here do not do that...

Actually, we're talking about that command coming from Arena with WB interface here. As hgm discussed, this sequence can't happen in the current winboard / xboard. In that sense, the winboard protocol can afford to 'make no sense' or 'be ambiguous' or even 'allow for truly stupid interpretation of that command'. (edit: it seems I was wrong, I do/did not know how winboard would handle concurrent sd and tc commandline arguments.)

Anyway, what's the deal with the ellipses at the end of your posts? ;-)