Brief parts of draughts

[Krzysztof Grzelak]

How to play short games of draughts between programs into draughts with time 30 seconds to the party.

[MichelG]

Damexchange does not support a time setting below 1 minute/game, so no programms will work at with that time.

Dragon allows 0.9 minutes/game, but does that by ignoring some of the damexchange standard.

Michel

[BertTuyt]

In Damage the minimal time for one move is 1 second (levelsfixedtime 1).
And as stated before the DamExchange minimal game time is 1 minute.
But I recognize the need for faster games.

So if some-one has a suggestion for a DamExchange modification.......,
or a different interpretation for the 3 bytes in GAMEREQ

Bert

[Krzysztof Grzelak]

In Damage the minimal time for one move is 1 second (levelsfixedtime 1).
And as stated before the DamExchange minimal game time is 1 minute.
But I recognize the need for faster games.

So if some-one has a suggestion for a DamExchange modification.......,
or a different interpretation for the 3 bytes in GAMEREQ

Bert

Bert please to make available DamExchange to so that it is possible more quickly to play. Michel thanks for information.

Krzysztof.

[BertTuyt]

DamExchange is a standard used by several programs and therefor it is not possible to write a quick patch for it.
So the only way to introduce something new is when all see the need for the change and there is mutual agreement about the implementation.

A possibility is to ""create"" a new version of the protocol (embedded in the GAMEREQ), which is now 01.
One could add a 02 version of the protocol, with a slightly different GAMEREQ format.
This could be (just as an example) a larger message with more bytes for the game time (which is now 3 bytes).
Maybe 6 bytes will do.

If the resolution is seconds in the new format, the maximum game time is 999999 seconds (277 hours) and the minimum is 1 second.
But maybe someone would like to see games in the milliseconds range....
If one would like to stick to the 3 bytes then the maximum game time would become 999 seconds , which is 16 minutes (maybe this is too short)!

If a program receives a GAMEREQ with a 02 protocol , the DamExchange handler should process the GAMREQ message slightly different.

I don't know what older programs will do with this change, whether they will crash, ignore the change, or whatever....
The new handler should be able to process both the 01 as 02 protocol.

But there could also be alternative (and different options).

Bert

[Rein Halbersma]

DamExchange is a standard used by several programs and therefor it is not possible to write a quick patch for it.
So the only way to introduce something new is when all see the need for the change and there is mutual agreement about the implementation.

A possibility is to ""create"" a new version of the protocol (embedded in the GAMEREQ), which is now 01.
One could add a 02 version of the protocol, with a slightly different GAMEREQ format.
This could be (just as an example) a larger message with more bytes for the game time (which is now 3 bytes).
Maybe 6 bytes will do.

If the resolution is seconds in the new format, the maximum game time is 999999 seconds (277 hours) and the minimum is 1 second.
But maybe someone would like to see games in the milliseconds range....
If one would like to stick to the 3 bytes then the maximum game time would become 999 seconds , which is 16 minutes (maybe this is too short)!

If a program receives a GAMEREQ with a 02 protocol , the DamExchange handler should process the GAMREQ message slightly different.

I don't know what older programs will do with this change, whether they will crash, ignore the change, or whatever....
The new handler should be able to process both the 01 as 02 protocol.

But there could also be alternative (and different options).

Bert

What about the following convention: a GAMEREQ with version 02 and thinking time 000 will send as next message CHAT. That gives 126 extra bytes to play with. In chess, the UCI protocol uses a 4-tuple of wtime/btime/winc/binc (all in msec). If we would adopt that, then with 31 bytes per value, that gives 24.8 days as the maximum limit for all 4 fields.

It is backward compatible with DXP v01 because CHAT message are supposed to be ignored. Also the DLL does not have to be updated because no new message types are being created.

[BertTuyt]

Rein, without checking the nitty-gritty details, I like your idea!

It also provides an option (with an extra field in CHAT) to add more chat DXP-commands if needed.
So if other programmers, welcome the idea, and there are no hidden booby-traps involved, we could start to discuss the structure of the CHAT time command..................

Bert

[Rein Halbersma]

Rein, without checking the nitty-gritty details, I like your idea!

It also provides an option (with an extra field in CHAT) to add more chat DXP-commands if needed.
So if other programmers, welcome the idea, and there are no hidden booby-traps involved, we could start to discuss the structure of the CHAT time command..................

Bert

Note, I made a silly mistake: 31 bytes is 248 bits, which is way more than 24.8 days We could also do just 10 decimal digits (representing up to 2^33 milliseconds, or 99.4 days) and send those as chars over the wire:

Format something like:

header, 1 byte, 'C'
wtime, 10 bytes, zero-prefixed decimal digits
btime, 10 bytes, zero-prefixed decimal digits
winc, 10 bytes, zero-prefixed decimal digits
binc, 10 bytes, zero-prefixed decimal digits

all the time fields are in msecs, prefixed with zeros.

Example 1: standard 2 hour format = 7,200,000 msecs
C 0007200000 0007200000 0000000000 0000000000

Blitz format, 5 minutes = 300 seconds
C 0000300000 0000300000 0000000000 0000000000

Fisher clock: 1 minutes time, 1 second per move increment
C 0000060000 0000060000 0000001000 0000001000

Ultra fast time controls such as supported by cutechess-cli: 2.5 seconds + 25 msec increments (for 40 moves!)
C 0000002500 0000002500 0000000025 0000000025

Note that the number of moves is still specified in the previous GAMEREQ command.

[MichelG]

I don't think the time should be in the gamerequest message, not in a chat message, as you may want to refuse a short-timed game; at some point even initialising your (hash)tables will take more time than allowed by the game speed.

Adding stuff to chat command just complicates the protocol unnecessarily.

imo the simplest option would be to just add another field to the gamerequest; a 5 byte string, containing the number of milliseconds for the game, and set version [field 2] to "02".

Total game time in seconds would be 60*(thinking time in minutes [field 3]) + 0.001*(thinking time in milliseconds [field 10])

For dragon, i hacked it so that you can send "0.9" or ".05" minutes. That works, but the 3 character limit puts restrictions on the times you can choose.

Michel

[Rein Halbersma]

I don't think the time should be in the gamerequest message, not in a chat message, as you may want to refuse a short-timed game; at some point even initialising your (hash)tables will take more time than allowed by the game speed.

Adding stuff to chat command just complicates the protocol unnecessarily.

imo the simplest option would be to just add another field to the gamerequest; a 5 byte string, containing the number of milliseconds for the game, and set version [field 2] to "02".

Total game time in seconds would be 60*(thinking time in minutes [field 3]) + 0.001*(thinking time in milliseconds [field 10])

For dragon, i hacked it so that you can send "0.9" or ".05" minutes. That works, but the 3 character limit puts restrictions on the times you can choose.

Michel

Why should program startup time matter? As soon as your program is ready, you start doing GAMEACC, and not before.

[MichelG]

Why should program startup time matter? As soon as your program is ready, you start doing GAMEACC, and not before.

I mean the per move startup time.

Dragon for instance resets the killer-heuristics tables, counters, hashtables and other tables before each move. It does this in order to increase reproducability if you need to examine a loss. It also logs and shows each move it plays. Lets say this takes 0.1 seconds for each move. If you play a 75 move game, that is about 7 seconds spend without search.

Now, if you give the program less than 7 seconds per game, it will always run out of time and there is no point in accepting games of less than 7 seconds/75 moves.

Michel

[Rein Halbersma]

Why should program startup time matter? As soon as your program is ready, you start doing GAMEACC, and not before.

I mean the per move startup time.

Dragon for instance resets the killer-heuristics tables, counters, hashtables and other tables before each move. It does this in order to increase reproducability if you need to examine a loss. It also logs and shows each move it plays. Lets say this takes 0.1 seconds for each move. If you play a 75 move game, that is about 7 seconds spend without search.

Now, if you give the program less than 7 seconds per game, it will always run out of time and there is no point in accepting games of less than 7 seconds/75 moves.

Michel

OK, I understand. But you could either make Dragon's cleanup behavior conditional on the requested time control, or simply decline requests for ultra fast games. I don't think that the dxp standard should depend on what a single program (yours, mine or anyone else's) chooses to support. Chess has shown that ultra fast games are both possible and beneficial. The dxp standard should not prevent them.

[MichelG]

OK, I understand. But you could either make Dragon's cleanup behavior conditional on the requested time control, or simply decline requests for ultra fast games. I don't think that the dxp standard should depend on what a single program (yours, mine or anyone else's) chooses to support. Chess has shown that ultra fast games are both possible and beneficial. The dxp standard should not prevent them.

Indeed it should not. And dragon can play a move within a few hundred microseconds if it is configured to do that. Below that, the network stack damexchange is running on will be the limiting factor. Ideally i would like to see games running at between 5 and 30 seconds per game.

Lets consider a match between 2 programs:
Engine A is very simple, single threaded and has no advanced data structures such as hash-tables, killer tables and logfiles.
Engine B is an advanced multithreaded and and complex program, with extensive tables.

Lets match those at 1 second per game. Only to find out that engine B is playing at 1 ply and still running out of time, and engine A is working at 6 ply and winning everything. Now program A beats B at 1 second per game, 100%.

But at 1 minute per game, B beats A 100%. The results would be correct: A excels at very fast games, and B at slow games.

This is not necessarily what you wanted to know: which program is better, given a reasonable amount of playing time.

Ofcourse this has nothing to do with protocol design, but it is one this to consider when playing very fast matches. Programmers will have to optimise move setup-time in order to win these fast matches.

Michel

[Ed Gilbert]

I agree with Michel. Playing very fast games will only show you which programs excel at fast games. Kingsrow spends many milliseconds at each move doing things other than searching. It will do poorly at game times averaging less than 1sec/move.

I do sometimes use very fast games to test one version of kingsrow against another, when I have changed something like the eval that does not affect the non-search overhead. For this purpose I send a fractional minute in the GAMEREQ field, like "0.5". This was suggested on the forum here some time ago (Michel?) and I think it's a good solution. The released version of kingsrow does not support this enhancement.

-- Ed

[Rein Halbersma]

I agree with Michel. Playing very fast games will only show you which programs excel at fast games. Kingsrow spends many milliseconds at each move doing things other than searching. It will do poorly at game times averaging less than 1sec/move.

Maybe for the current draughts programs that is true, but if you would remove some of the intermediate table cleanup and logging stuff that would change. I think that the experience of chess programs clearly shows that ultra fast games are very good predictors for longer time controls. Stockfish runs thens of thousands of games per day in its testing.

I do sometimes use very fast games to test one version of kingsrow against another, when I have changed something like the eval that does not affect the non-search overhead. For this purpose I send a fractional minute in the GAMEREQ field, like "0.5". This was suggested on the forum here some time ago (Michel?) and I think it's a good solution. The released version of kingsrow does not support this enhancement.

-- Ed

If we are going to change the GAMEREQ format, and not go for the GAMEREQ + CHAT follow-up I outlined above, then I would prefer make maximum use of the 127 bytes that a message can take. The current GAMEREQ is 94 bytes (excluding trailing zero), so that leaves 33 bytes at the end, and 3 bytes for the current thinking time field. I would prefer to replace the 3 byte time field with 4 fields of 9 bytes (formatted as zero-prefixed decimal digits), followed by the remaining fields of the current GAMEREQ. That leaves time intervals of 1 millisecond up to 1^10 = 115 days. This should make GAMEREQ future proof.

Individual engines that cannot cope with ultra short games, can simply decline such requests.