Matant 5.03 wb2uci file question

[Graham Banks]

I was using Claude's wb2uci file, but when using the time control 40 moves in 75 minutes repeating noticed that after move 40 it would use 11 minutes per move until it was then forced to move almost instantly thereafter.

I've added the option line ExtendLevel=Strict. Is that all I need to do?

What's the difference between LevelExtend=Strict and LevelExtend=Failsafe?

Regards, Graham

[H.G.Muller]

I have seen that behavior in other engines (GNU 5.07 for instance). It is caused by the fact that in Winboard protocol the GUI informs the engine of how much time it still has, but not of how many moves it still has to play in that time!

Some engines (including my own, after my initial implementation of the Winboard protocol) do not count forced moves as moves to which the time control applies. There seems to be some logic in this, as such moves also do not use up any time. The WB protocol specification is rather vague about this, the way it handles the case where you switch colors for the engine suggests that N moves in M minutes should be applied to the moves it actually plays as a result of a search, no matter for which side it is searching.

You then get the effect that, with 40 moves in 75 min, say, the engine gets the first 5 moves forced by the GUI (from the external book) before it starts thinking of its own. It then prepares to play the next 40 moves, i.e. upto move 45, in 75 minutes. So at move 40 it will probably have left some 10 min on the clock for the 5 moves it thinks it still has to play before the next time alotment.

To its surprise, the GUI tells it that before move 41 it now has 10+75 = 85 min on the clock. But it still thinks that it only has to play 5 moves in that time. So it starts to think 15 min per move to make good use of that time, confident that after move 45 (the 40th move it plays) it will get another 75 min.

So when it finally reaches move 45 with only 5-10 min safety time on the clock, it will come as a very unpleasant surptise to it that the GUI now says that it has only 5-10 min for its next 40 moves (46 - 86, as it expects the third time interval to begin at its own 81th move, which is really move 86 of the game). So it now starts to think 5-15 sec per move, in order to make that.

I am not sure that any of the LevelExtend commands would work satisfactorily on an engine that behaves this way.

[Graham Banks]

I am not sure that any of the LevelExtend commands would work satisfactorily on an engine that behaves this way.

Unfortunately they don't, so I've had to pull Matant from my testing.

Thanks for your response and explanation. Much appreciated.

Regards, Graham.

[H.G.Muller]

Well you could always substitute micro-Max....

After all, it beats Clueless 1.4 in my Nunn match, both at 2+0 and 10+0.

[Odd Gunnar Malin]

I've added the option line ExtendLevel=Strict. Is that all I need to do?

What's the difference between LevelExtend=Strict and LevelExtend=Failsafe?

Regards, Graham

Hi.

For computer-computer matches I think it is better to use LevelExtend=none (default) and use (as you do) repeated time/moves or time/game with or without increment.

All these other values are to fool the engine to accept 'normal' timecontrols, remember my focus is (was) on human-computer games and thereby it was important to let the human 'practice' with the timecontrol he will use in his/her next tournament.

Thogh, all engine should be able to use 'failsafe' if they can handle a gui book. All previous moves after timecontrol are feeded as bookmoves with new game etc.

Progresive and strict comes from my testing of engines at that time, and most (if not all) engines could get a level command in the middle of a game either by thinking of it as new timecontrol from here or as a new timecontrol for the hole game started with move one.

So the difference between failsafe and Progresive/Strict, if the engine manage both, is that with failsafe it will clear the hashtable at every timecontrol and possible miss the pondering search there as well. With Progresive/Strict it dont miss anything.

Odd Gunnar

[Graham Banks]

Thanks for the explanation Odd Gunnar.

[H.G.Muller]

Odd Gunnar,

what we are dealing with here, is a behavior that is not covered by any of the options you implemented.

The problem is that the engine does not count the book moves that are forced upon it externally when applying the time control. I applies the control in existence at the moment it recieves the 'go' command only to the remaining moves.

So what is needed as a work-around would be to give the engine not only a new level command at each time control, but to correct the number of moves specified in this level command for the number of moves already played (be it book moves or moves just to restore the position after an attempt to change the time control).

So at 40/40 + 40/25 you would have to give it after (say) 7 book moves a level command that specifies 33/40. And then after the 40th move you would have to give it 40/25 before feeding it the first 40 moves as book moves (not 80/25).

[Odd Gunnar Malin]

The problem is that the engine does not count the book moves that are forced upon it externally when applying the time control. I applies the control in existence at the moment it recieves the 'go' command only to the remaining moves.

Is this 'bug' common?
It seems correct to fix this in the engine, and not mask it with the adapter. Many WB GUI also have gui book (CP, Chess Assistant, Chessmaster).
What happend if it goes into the book again after playing a few move by its own? Start a new game here? You only get a list of moves and a startposition from the GUI so the adapter must keep track of which move the engine did and what was a book move.

Odd Gunnar

[H.G.Muller]

The bug is reasonably common; I designed my own engines this way before I realized that it dit not work, and fixed it. I later moticed that GNUChess 5.07 also behaved this way, and now Matant.

The reason is that this is really what the description of the Winboard protocol suggests you should do:

time N
Set a clock that always belongs to the engine. N is a number in centiseconds (units of 1/100 second). Even if the engine changes to playing the opposite color, this clock remains with the engine.

It is the second sentence that causes the problem: the clocks do not belong to a certain color, they just seem to measure the time spent searching. This makes it logical to also count only the moves spent searching, or the amount of time it spent per move would start to depend on how often you change sides. E.g., if you set 40 moves in 40 minutes, but you would interpret it as that you should not exceed 40 min on your clock before the absolute move number is 40, changing side on each move would force the computer to do 80 moves in this time.

To prevent this kind of thing, I thought it quite natural to make the computer really play 40 moves in 40 minutes, if the level requested this. I.e. count the number of moves you actually do, so that you use the 40 min for the 20 white moves + 20 black moves the engine does. Of course the engine is then out of time at move 20, as it really expected to get new time at that point. After all, it had done 40 moves.

Now the problem is that Winboard does not behave according to the protocol definition. If you change the color during the game, the GUI does NOT swap the clocks of black and white, to make the clock stay with the engine!

The following definition enhances the impression that you start only measuring time. 'Associate' suggest that you keep the time that is on the clock. Otherwise it would have had to say "reset the clock to the time that color still has left on its GUI clock".

go
Leave force mode and set the engine to play the color that is on move. Associate the engine's clock with the color that is on move, the opponent's clock with the color that is not on move. Start the engine's clock. Start thinking and eventually make a move.

Of course Winboard now starts hiding the problem by synchronizing the clock before every move, so it accomplishes what the protocol definition says you should not do. But the protocol does not specify that you will get a time and otim command before every move. Winboard seems to do this, but there are other GUIs using Winboard protocol, and you can never be sure that they will all do it. It is not a requirement.

It is rather strange that Winboard does violate the spirit of its own protocol definition. Especially since it does it in such a way that it no longer works satisfactory with GNUChess. After all, the description says it is a GUI designed for GNUChess...

I am not sure if external books are clever enough to recognize that you return in book. If they do, they must handle it by sending the engine a force command after an earlier go command. And then, when you get out of book for the second time, send it again a go command. The important thing to realize is that with engines programmed like this, the move count is reset to the number specified in the level command every time it receives a go command. The time-remaining is usually as well, but is immediately overruled by new time commands.