WinBoard Friendly mode

[indrajit_sg]

Hi,

Is there a possibility to implement a feature where I play against a machine with no time control or fixed depth per move?

Regards,
Indrajit

[H.G.Muller]

If there is no time control, why would the engine ever move? All engines I know are written to pretty much use up all time they are granted. (In other words, with the possible exception of NEG 0.3d and Pos 1.19, there probably are no friendly engines, and there is nothing WinBoard can do about that.)

I think what you need is a mode where the engine gets a well-measured (small) amount of time, and the human user so much that he would never be flagged unless he dies during the game. This can already be achieved by setting a ridiculously long time control (e.g. 40 moves / 24 hr), and a very large time-odds factor for the engine (e.g. 1440, so that the engine has to play 40 moves/1 min).

[indrajit_sg]

Thanks, I think this time factor will do just fine.

What I was envisioning is the "Sparring Mode" in Fritz where no clock is used and you get to set a difficulty level for the machine.

[H.G.Muller]

Well, Fritz is not a WinBoard engine, so quite possible it has ways to control its thinking time in other ways then telling it how much time there is on its clock. But in WinBoard protocol that is the only way (unless you want to set a fixed search depth, which I would never recommend).

[matematiko]

Well, Fritz is not a WinBoard engine, so quite possible it has ways to control its thinking time in other ways then telling it how much time there is on its clock. But in WinBoard protocol that is the only way (unless you want to set a fixed search depth, which I would never recommend).

By "FRITZ" he was refering to Fritz as a GUI (Chessbase) not as an engine.

There is a "sparring" mode that can be adjusted from "Real Hard" to "Real Easy" (or something like that). More than likely Fritz accomplishes this by adjusting the level of depthness the engine is allowed to think regardless of the time controls.

Regards,

[imai]

What are the arguments against reducing the strength of an engine by setting the ply depth ?
In doing so you cripple the tactical power of the engine by limiting its horizon and so the user may see deeper than the engine and that can be fun for a lot of weak or starting chess players.
So I would vote for this feature.

[H.G.Muller]

The problem is that the effective ply-depth of a human varies strongly with game phase. Like it would for an engine, when you let it think for a fixed time or number of nodes, except even more so. So limiting the engine to a fixed depth is likely to make it play like a total idiot in the end game, and you would have little trouble winning even the most badly lost end-games, because it would simply allow you to march up your passers until they become unstoppable, without even suspecting there is anything wrong. And by the time you set the depth so large that this is no longer a problem, it is already far past the point where it totally over-plays you tactically in the middle-game.

Btw, it is possible to limit the depth with the aid of the option -searchDepth N. I just do not recommend its use. Time-odds is a better method, until you get into the realm where the engine would have to move faster than your system clock ticks. After that you can play by a fixed number of nodes (for UCI engines that support 'go nodes' and WB engines that support 'nps').

[Roger Brown]

The problem is that the effective ply-depth of a human varies strongly with game phase. Like it would for an engine, when you let it think for a fixed time or number of nodes, except even more so. So limiting the engine to a fixed depth is likely to make it play like a total idiot in the end game, and you would have little trouble winning even the most badly lost end-games, because it would simply allow you to march up your passers until they become unstoppable, without even suspecting there is anything wrong. And by the time you set the depth so large that this is no longer a problem, it is already far past the point where it totally over-plays you tactically in the middle-game.

Btw, it is possible to limit the depth with the aid of the option -searchDepth N. I just do not recommend its use. Time-odds is a better method, until you get into the realm where the engine would have to move faster than your system clock ticks. After that you can play by a fixed number of nodes (for UCI engines that support 'go nodes' and WB engines that support 'nps').

Hello H.G.,

I read the documentation on this times odds feature and I wanted to be sure I got it clear.

I set the time control for the game at say one hour for the entire game. Then I set the time odds factor for engine #1 to 10 and now the engine is sent the message that the game is 6 minutes long. That is what I see happening here.

So the engine will play at full strength but within a context of severely reduced time on its clock. In a game of chess having odds of time should be a winning advantage. I have never used that mode before. Seems I might have to experiment to find a level where the engine might be beatable as on today's hardware an engine at blitz time controls is still a a monster.

However it does address playing an engine at full strength for all of the game instead of facing an idiot at any phase. Of course the embarrassment is when I discover that even at generous time odds that I still cannot survive!

Are there any other methods similar to these not mentioned in the thread (nodes and search depth) which give the user a chance using Winboard?

Edit: Any idea why the times odd setting is not saved when I quit Winboard even though I have save settings on exit checked?

Later.

[H.G.Muller]

-first/-secondTimeOdds are volatile options, i.e. not saved in the settings file. I made it that way because it seems more likely than not that in a new session after one where you used time odds, you would want to use standard times. And even if you wanted to use time odds again, it would be unlikely you needed the same factor.

You should compare this to options like "Has Own Book" and "variant". The timeOdds options are really intended to go with the engine, on its install line (like -fd, -sd). You want each engine to have its own timeOdds, chosen to give itthe desired playing strength, and you dont want time odds of one engine to hang around when you use another engine next time that does not specify time odds on its engine line.

For time odds it is even such that it is not persistent during a session: each time you open the TC dialog it again proposes time-odds factors of 1, even when you were using other factors. (For "Has Own Book" it at least would show you the current setting when you re-open the Common-Engine dialog.)

Each factor two should shave off about 70 Elo points, but thing stopworking properly when you reduce the engine time to around 1/100 sec per move. (Because this is the precision with which clock times are transmitted in WB protocol, and also at which the system clock ticks, which mostengines use for timing decisions. In UCI you can specify the time in msec, but that does not really help if the clock ticksonly 60 times per sec. An engine told to think 5 msec would read the clock, and see "Oh, I have not used any time yet, let's think some more". Until the clock ticks, and then it would think "Oops, now I have used 16 msec, which is 11 more than I had, so I have forfeited now".) So there is alimit to how far you can go with this, and like you say, even at 20 moves per second engines like Fruit and Stockfish are formidable opponents. But you can of course start with amuch weaker engine.

There is little else you can do from a GUI to dumb down an engine, other than limiting its time. Unless the engine has specific options to do that. In that case they should appear in the Engine Settings dialog.

[imai]

H.G.M.,
Thanks for the explanation, as usual clear and to the point. I will try the -TimeOdds factor with -ponder set to false.
Regards

[Roger Brown]

-first/-secondTimeOdds are volatile options, i.e. not saved in the settings file. I made it that way because it seems more likely than not that in a new session after one where you used time odds, you would want to use standard times. And even if you wanted to use time odds again, it would be unlikely you needed the same factor.

You should compare this to options like "Has Own Book" and "variant". The timeOdds options are really intended to go with the engine, on its install line (like -fd, -sd). You want each engine to have its own timeOdds, chosen to give itthe desired playing strength, and you dont want time odds of one engine to hang around when you use another engine next time that does not specify time odds on its engine line.

For time odds it is even such that it is not persistent during a session: each time you open the TC dialog it again proposes time-odds factors of 1, even when you were using other factors. (For "Has Own Book" it at least would show you the current setting when you re-open the Common-Engine dialog.)

Each factor two should shave off about 70 Elo points, but thing stopworking properly when you reduce the engine time to around 1/100 sec per move. (Because this is the precision with which clock times are transmitted in WB protocol, and also at which the system clock ticks, which mostengines use for timing decisions. In UCI you can specify the time in msec, but that does not really help if the clock ticksonly 60 times per sec. An engine told to think 5 msec would read the clock, and see "Oh, I have not used any time yet, let's think some more". Until the clock ticks, and then it would think "Oops, now I have used 16 msec, which is 11 more than I had, so I have forfeited now".) So there is alimit to how far you can go with this, and like you say, even at 20 moves per second engines like Fruit and Stockfish are formidable opponents. But you can of course start with amuch weaker engine.

There is little else you can do from a GUI to dumb down an engine, other than limiting its time. Unless the engine has specific options to do that. In that case they should appear in the Engine Settings dialog.

Hello H.G.,

Thanks!

Helpful and informative as always.

Later.

[Adam Hair]

-first/-secondTimeOdds are volatile options, i.e. not saved in the settings file. I made it that way because it seems more likely than not that in a new session after one where you used time odds, you would want to use standard times. And even if you wanted to use time odds again, it would be unlikely you needed the same factor.

You should compare this to options like "Has Own Book" and "variant". The timeOdds options are really intended to go with the engine, on its install line (like -fd, -sd). You want each engine to have its own timeOdds, chosen to give itthe desired playing strength, and you dont want time odds of one engine to hang around when you use another engine next time that does not specify time odds on its engine line.

For time odds it is even such that it is not persistent during a session: each time you open the TC dialog it again proposes time-odds factors of 1, even when you were using other factors. (For "Has Own Book" it at least would show you the current setting when you re-open the Common-Engine dialog.)

Each factor two should shave off about 70 Elo points, but thing stopworking properly when you reduce the engine time to around 1/100 sec per move. (Because this is the precision with which clock times are transmitted in WB protocol, and also at which the system clock ticks, which mostengines use for timing decisions. In UCI you can specify the time in msec, but that does not really help if the clock ticksonly 60 times per sec. An engine told to think 5 msec would read the clock, and see "Oh, I have not used any time yet, let's think some more". Until the clock ticks, and then it would think "Oops, now I have used 16 msec, which is 11 more than I had, so I have forfeited now".) So there is alimit to how far you can go with this, and like you say, even at 20 moves per second engines like Fruit and Stockfish are formidable opponents. But you can of course start with amuch weaker engine.

There is little else you can do from a GUI to dumb down an engine, other than limiting its time. Unless the engine has specific options to do that. In that case they should appear in the Engine Settings dialog.

I understand your reasoning. But, I have been forced to use Pradu's tourney manager to actually test how many Elos are gained per doubling of time. Mind you, I am not complaining about this (I am still more comfortable using PSWBTM than the built-in tournament manager and I am thankful that WB allows time-odds.).

Note: I am not doing self-testing, but rather testing a group of engines. That is why I need to use a tournament format.

Adam

[H.G.Muller]

Indeed, external TMs like PSWBTM used to be the only way to play more than a single opponent. Now that I managed to have WinBoard change engine during a session, it became possible to equipit with an intrinsic TM. This is still in an experimental phase, although the aim is to make external TMs superfluous in the long run.

My major worry is reliability in the face of buggy engines. An external TM is quite invulnarable to WinBoard crashes (e.g. triggered by bad engine behavior), because you start a new WinBoardfor any game anyway. But when WB runs the tourney itself, it becomes very important that it can handle even the worst engine behavior without crashing or stalling. It will require a lot of testing with buggy engines to make sure that it is sufficiently error proof.

In some respects PSWBTM is still superior to the intrinsic TM. For instance the possibility to run 'aftergame' and 'afterround' batch files, and the ability to display the pairing scheme and the current standings. OTOH, the intrinsic TM already can dosome thngs that are not possible with PSWBTM. Such as Swiss tourneys, or playing several games of a tourney in parallel.

I still plan to equip the intrinsic TM with -afterGame and -afterRound options, but I still have to think what best to let this options represent. (E.g. should they specify the name of a batch filewith commands, or should they just specify a command stringto be executed by the system.) I would like to have some possibility in -afterGame to refer to the name of the currently playing engines, so that you could selectively kill engines that do not reliably terminate. With PSWBTM I often also used a 'kill list' for rogue engines, but you had no other option there as killing all engines participating in the tourney after every game, even those that did not play in the game.

[Roger Brown]

Indeed, external TMs like PSWBTM used to be the only way to play more than a single opponent. Now that I managed to have WinBoard change engine during a session, it became possible to equipit with an intrinsic TM. This is still in an experimental phase, although the aim is to make external TMs superfluous in the long run.

My major worry is reliability in the face of buggy engines. An external TM is quite invulnarable to WinBoard crashes (e.g. triggered by bad engine behavior), because you start a new WinBoardfor any game anyway. But when WB runs the tourney itself, it becomes very important that it can handle even the worst engine behavior without crashing or stalling. It will require a lot of testing with buggy engines to make sure that it is sufficiently error proof.

In some respects PSWBTM is still superior to the intrinsic TM. For instance the possibility to run 'aftergame' and 'afterround' batch files, and the ability to display the pairing scheme and the current standings. OTOH, the intrinsic TM already can dosome thngs that are not possible with PSWBTM. Such as Swiss tourneys, or playing several games of a tourney in parallel.

I still plan to equip the intrinsic TM with -afterGame and -afterRound options, but I still have to think what best to let this options represent. (E.g. should they specify the name of a batch filewith commands, or should they just specify a command stringto be executed by the system.) I would like to have some possibility in -afterGame to refer to the name of the currently playing engines, so that you could selectively kill engines that do not reliably terminate. With PSWBTM I often also used a 'kill list' for rogue engines, but you had no other option there as killing all engines participating in the tourney after every game, even those that did not play in the game.

Hello H.G.,

That kill process is what I would like you to fine tune.

Where you are running parallel instances of a Winboard tournament and you kill bad.exe, there could be disastrous unintended consequences if bad.exe was active in both (or more) tournaments.



Later.

[Michel]

Hello H.G.,

That kill process is what I would like you to fine tune.

Where you are running parallel instances of a Winboard tournament and you kill bad.exe, there could be disastrous unintended consequences if bad.exe was active in both (or more) tournaments.



Later.

Apparently TerminateProcess does not always terminate a process on Windows. I have never experienced
this myself (Polyglot uses TerminateProcess if all else fails) but it has been reported here.

It would be nice if some windows expert could explain what goes on. Surely there must be
a fool proof way of killing a child process under Windows.

EDIT: Googling does not give anything conclusive. Suggested causes for TerminateProcess to fail seem
to be

- ACCESS DENIED (not enough privileges)
- Process "stuck in kernel mode" (something like "D state" under Linux)
- Process being debugged (need to kill the debugger first)

[Michel]

It would be nice if some windows expert could explain what goes on. Surely there must be
a fool proof way of killing a child process under Windows.

No windows experts on this forum? Or is one simply not supposed to ask this kind of questions
about windows....

Note that on Linux the situation is very easy. SIGKILL kills the process unless it
is stuck in D state. Excepting a kernel bug or hardware problems,
this can only happen is very specific circumstances (like an NFS file system that becomes unresponsive).