Arena "sd=9999"

[Laurens Winkelhagen]

hehe yes, I thought I'd read my interpretation somewhere ^^
Thanks hgm, I was beginning to doubt myself:-)

[Laurens Winkelhagen]

...
If I were to implement setting the depth limit through a menu in a future Winboard version (which does seem a good idea, e.g. in the tim-control dialog), I would preceed the sending of new TC parameters by a new command, rather than sending a new level command and trying to countermand any depth or time limit by a second sd or st command.

I'm not sure that's best. This would dis-allow you to change the depth-limit within a game I think, and would make the feature less usefull. (unless maybe if you reinstate the board to the last position in the current game after the new command, but that might cause problems in some engines)

--Laurens

[Richard Allbert]

..

Yes, you have I point... I printed it out but misread that part

I'm only implementing it to use your new logo feature you showed in the CPT

Ciao

Richard

[hgm]

I'm not sure that's best. This would dis-allow you to change the depth-limit within a game I think, and would make the feature less usefull. (unless maybe if you reinstate the board to the last position in the current game after the new command, but that might cause problems in some engines)

I had not considered that yet. Current WinBoard even refuses to pop up the time-control dialog during a game, but gives the message "changing the TC during a game is not implemented" in stead. So if that depth could be set from tht dialog, I would have to 'unlock' that during the game to allow changing the depth there.

It is interesting that Arena assumes that you can send multiple level commands to an engine within the same game, without confusing it. We had a great deal of discussion about this on WB forum in connection with possible implementations of multi-session time controls.

[Christopher Conkie]

Hi Chris,

I've posted the log in the reply to Bob.... Windows vista, latest arena.

Richard

"wo ist das Problem? sd ist keine Suchstufe, sondern eine zusätzliche
Begrenzung. Das Winboard-Protokoll ist einfach schlecht. Nicht umsonst gibt
es UCI...

Und wenn jemand seinen Schachmotor entwickelt, kann Arena natürlich mal
abstürzen.

Mir ist neulich Word abgestürzt, weil ich zu schnell geklickt habe."

Hello from Arena World to Winboarders everywhere.



Christopher

[Richard Allbert]

I don't think the WB protocol is worse than UCI.... UCI is easier to implement, but your engine is a the mercy of the GUI - you don't need any awareness of game state.

I find WB much cleaner... particularly when the games get long!

That being said, the very reason sd=9999 tripped me up was because I was "bending" my lazy uci friendly time implementation to WB

But sd=9999 is still incorrect...

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

When i try it, is seems to stop searching when either the allotted time or depth is reached.

Code: Select all

Crafty v22.8 (1 cpus)

White(1): sd 16
search depth set to 16.
White(1): time 40/1
40 moves/1 minutes primary time control
40 moves/1 minutes secondary time control
White(1): e4
              time used:  25.50
              time surplus   0.00  time limit 1.50 (+0.00) (10.50)
              depth   time  score   variation (1)
               11     0.46   0.17   1. ... Nc6 2. Nc3 Nf6 3. Nf3 e6 4.
                                    d4 Bb4 5. Bd3 Bxc3+ 6. bxc3 d5 7. exd5
                                    exd5
               11->   0.62   0.17   1. ... Nc6 2. Nc3 Nf6 3. Nf3 e6 4.
                                    d4 Bb4 5. Bd3 Bxc3+ 6. bxc3 d5 7. exd5
                                    exd5
               12     0.98   0.27   1. ... Nc6 2. Nc3 Nf6 3. Nf3 e5 4.
                                    d4 exd4 5. Nxd4 Bb4 6. Nxc6 Bxc3+ 7.
                                    bxc3 dxc6 8. Qxd8+ Kxd8
              time=1.50  mat=0  n=823434  fh=87%  nps=548K
              ext-> check=7K qcheck=13K reduce=408K/87K
              predicted=0  evals=627K  50move=0  EGTBprobes=0  hits=0
              SMP->  splits=0  aborts=0  data=0/64  elap=1.50

Black(1): Nc6 
              time used:   1.50

Looks like I let some debug code slip through at some point in time. I added that so that when I run test sets to a specific depth, sometimes I will change something that makes the tree blow up (extension change, etc) and I didn't want the test to run for an hour and then hang on an impossible depth limit. However that will still screw up on things like "easy move" and "in trouble time extension". Makes no sense to send a sd=9999 IMHO...

[hgm]

It escapes me why it would be worse to specify a maximum search depth than an exact search depth. When specifying a limit, you can always make sure the limit is indeed reached by specifying an infinite seach time. But it gives you the flexibility to limit search time and depth at the same time, so that you still will get your engine to move in a decent time in the rare occasions where the search at the given depth blows up (e.g. because of abounding extensions).

A protocol that would only allow specification of an exact depth, and would not pay any attention to time, could never do that.

So it has nothing to do with taste. WinBoard protocol can do everything here that alternatives designs could have done, and on top of it, it can do more. That makes it objectively superior to alternative protocols.

In the v3 protocol proposal, even st and level were defined as orthogonal controls, that could occur together, and would then both be respected. So you could both limit the time for the entire game, but also the time on any single move. A mode of TC that seems to be commonly used in Xiangqi.

[Christopher Conkie]

I don't think the WB protocol is worse than UCI.... UCI is easier to implement, but your engine is a the mercy of the GUI - you don't need any awareness of game state.

I find WB much cleaner... particularly when the games get long!

That being said, the very reason sd=9999 tripped me up was because I was "bending" my lazy uci friendly time implementation to WB

But sd=9999 is still incorrect...

Martin thinks sd=9999 is the best solution (as you read above from him) because you must clear the original depth limiting command somehow. The "new" command messes up some engines. If you send a different depth limit to the engine replacing the original then you do not see sd=9999 (unless of course you literally send sd=9999).

There are options for Fischer mode in Arena with regard to the level "infinite" (which is unsupported by the Winboard Protocol).

"The level 'infinite' does not exist for WinBoard engines. It has to be emulated for them."

Out of interest those options are in the Engines->Manage->Option tab.

As to Arena "assuming" multiple levels within a game, we know that some Winboard person will come along and try just that.....like you did.



We think sd=9999 is a fix for a BUG in the Winboard protocol to prevent the engine continuing with the wrong parameters.

Youve made our day.



Christopher

[Christopher Conkie]

It escapes me why it would be worse to specify a maximum search depth than an exact search depth. When specifying a limit, you can always make sure the limit is indeed reached by specifying an infinite seach time. But it gives you the flexibility to limit search time and depth at the same time, so that you still will get your engine to move in a decent time in the rare occasions where the search at the given depth blows up (e.g. because of abounding extensions).

A protocol that would only allow specification of an exact depth, and would not pay any attention to time, could never do that.

So it has nothing to do with taste. WinBoard protocol can do everything here that alternatives designs could have done, and on top of it, it can do more. That makes it objectively superior to alternative protocols.

In the v3 protocol proposal, even st and level were defined as orthogonal controls, that could occur together, and would then both be respected. So you could both limit the time for the entire game, but also the time on any single move. A mode of TC that seems to be commonly used in Xiangqi.

Where will version 3 appear? When it does it will be implemented in Arena no doubt.