Standard candles

[hgm]

The HGM golden rules is to relegate as much to the engine as possible - that it the xboard philosophy. You cannot have it both way! You have this rule when it's convenient and the other rule when bashing other protocols.

That is not true at al. You made that up in the firts place, and I have denied it from the beginning. XBoard includes many functions aimed at making engine design simpler. Such as converting engine Thinking Output to SAN before displaying it, sorting the PVs of the same depth by score for multi-PV, etc.

But it only makes sense to do things in the GUI that engines have in common. Move-legality checking is not amongst those, as each engine plays according to its own rules. So the best subdivision is letting everything that requires rule knowledge be handled by the engine (or a referee engine), and anything that doesn't by the GUI. That is not 'as much as possible'. It is in fact 'as little as is absolutely necessary'.

Anyway, what choice would I have if I did not want to use xboard for this? I really don't have much confidence that I could convince GUI authors to support this handshaking protocol for this esoteric feature and it's so easy to simply implement it in an engine.

For hiding time odds no new protocol is needed at all. And it is actually a common request by people that want to play human vs engine, and think it unsettling when the engine instantly replies.

But it's really a non-issue. You CAN have it both ways. It's simple to implement it in an engine and an engine author can ALSO or INSTEAD OF implement the version that requires GUI support that you advocate. In this way an author can have a version guaranteed to work or he can choose the method that only work with xboard or he can do both.

Yes, you can have it both ways. But that doesn't mean that it is a good thing to do. The more engines implement it, the less the pressure on GUI authors to implement it for the benefit of all. It is just a recipe for creating chaos.

[Robert Pope]

I agree that for the NIT feature the engine has to be involved. (But fortunately it can be trivially implemented, with only changes in the routine that reads the clock.) But normal time odds can be implemented entirely in the GUI; it can just multiply all times by a factor before sending them to the engine, and multiply by the inverse factor when receiving them.

My statement specifically addressed the possibility to hide such time odds (or implicit time odds cause by NIT) from the user by inserting delays. That should better be left to the GUI.

It seems to me that time odds is different than a constant engine. The odds factor would have to be different for every computer. Even then, time odds scaling would at best be a rough approximation of the goal (e.g. a 10K nps engine on all machines). On the other hand, if an engine author want his engine to run at exactly 10K nps, he can implement that very precisely and objectively.

[Don]

I agree that for the NIT feature the engine has to be involved. (But fortunately it can be trivially implemented, with only changes in the routine that reads the clock.) But normal time odds can be implemented entirely in the GUI; it can just multiply all times by a factor before sending them to the engine, and multiply by the inverse factor when receiving them.

My statement specifically addressed the possibility to hide such time odds (or implicit time odds cause by NIT) from the user by inserting delays. That should better be left to the GUI.

It seems to me that time odds is different than a constant engine. The odds factor would have to be different for every computer. Even then, time odds scaling would at best be a rough approximation of the goal (e.g. a 10K nps engine on all machines). On the other hand, if an engine author want his engine to run at exactly 10K nps, he can implement that very precisely and objectively.

My primary reason for wanted this feature in a reference program (probably Stockfish 4) is so that we can benchmark all the old hardware we have right now - before it becomes too impractical. In fact the source code could even be modified to provide hardware specific references. For example one reference point could be defined as:

July 2006 Intel Conroe E6300 1.86 GHz

There would be an internal conversion table which would make the program play AS IF it were running on one of these machines. Note that this is already over 7 years OLD!

It might sound silly now but in 20 or 30 years assuming we kept the source code of SF 4 maintained to keep up with newer compiler technologies and possible deprecation features of the C standard used now future generations of people might thank us.

It kills me to think that we have lost the source to most of the great chess programs of the past. Many of them are commercial of course and perhaps the authors would never allow this but we should have representatives of the top programs from every year or two. Having the source code is better than running these programs on emulators - which makes them very difficult to test against modern programs on modern interfaces. With the source code we can always update the code to run on UCI or xboard or whatever protocol we are using in the future.

[hgm]

It seems to me that time odds is different than a constant engine. The odds factor would have to be different for every computer. Even then, time odds scaling would at best be a rough approximation of the goal (e.g. a 10K nps engine on all machines). On the other hand, if an engine author want his engine to run at exactly 10K nps, he can implement that very precisely and objectively.

Indeed, time-odds is different from a constant engine. But masking the time-odds, and scaling the constant engine is exactly the same problem, independent of both. To emulate the constant engine only requires the engine to play by nodes, and report its node count.

[abulmo]

I did the same experiment with my own chessgame code, except I only play 200,000 games instead of one million, and get more detailed results: player's color, the origin of the draw, and the game length.
The three players are named like this:
move = play random moves
capture = play random captures/promotions (or a random move if none is available)
mate = play a checkmate in 1 (or a random move if none is available)

My numbers look the same, and the stalemate is the first source of drawn games.

Code: Select all

white capture, black move 
17221 white_mate, 242 black_mate, 56931 stalemate
1262 repetition, 6986 fifty, 17358 insufficient_material
game length : 232.63 +/- 152.18 (4 - 923)

white move, black capture
273 white_mate, 17335 black_mate, 57119 stalemate
1275 repetition, 7017 fifty, 16981 insufficient_material
game length : 232.57 +/- 152.55 (4 - 882)

white mate, black move 
53577 white_mate, 5457 black_mate, 2525 stalemate
1406 repetition, 10365 fifty, 26670 insufficient_material
game length : 225.48 +/- 145.08 (4 - 805)

white move, black mate
5405 white_mate, 53256 black_mate, 2506 stalemate
1348 repetition, 10493 fifty, 26992 insufficient_material
game length : 226.50 +/- 144.29 (4 - 773)

white capture black mate
16738 white_mate, 3967 black_mate, 55023 stalemate
1175 repetition, 6607 fifty, 16490 insufficient_material
game length : 225.09 +/- 154.59 (4 - 926)

white mate black capture
4283 white_mate, 16736 black_mate, 54823 stalemate
1253 repetition, 6579 fifty, 16326 insufficient_material
game length : 224.19 +/- 154.89 (4 - 898)

[hgm]

OK, that is what I suspected. The number of stalemates goes up spectacularly when one side preferentially captures. I think this could be prevented by avoiding capture of the Knights. (Or of any other piece type, but intuitively I feel leaving the opponent Knights would be less dangerous than leaving him anything else.)

[sje]

A new player in a Tale of Two Players

Player Zero will play a randomly selected checkmating move if one is available; otherwise, it will play a randomly selected capture/promotion move if one is available; otherwise, it will play a randomly selected move.

Player One will play a randomly selected move.

What happens in a one million game match between these players? With alternating colors and from the viewpoint of Player Zero, the win/lose/draw/total counts are:

Code: Select all

W/L/D/T: [847,606/2,529/149,865/1,000,000]

[hgm]

If you allow the amount of look-ahead needed to selects moves that checkmate, it would be consistent to explicitly avoid moves that stalemate. Stalemating the opponent is almost never a good idea, as the fact that you can do it strongly suggests you are in the lead. (Exception: KPK with a Rook Pawn.)

[sje]

Four more matches between MaterGrabber and Random:

Code: Select all

W/L/D/T: [848,150/2,513/149,337/1,000,000]
W/L/D/T: [847,410/2,614/149,976/1,000,000]
W/L/D/T: [848,227/2,598/149,175/1,000,000]
W/L/D/T: [847,365/2,620/150,015/1,000,000]

It's interesting that Random can win any games at all.

[Don]

Four more matches between MaterGrabber and Random:

Code: Select all

W/L/D/T: [848,150/2,513/149,337/1,000,000]
W/L/D/T: [847,410/2,614/149,976/1,000,000]
W/L/D/T: [848,227/2,598/149,175/1,000,000]
W/L/D/T: [847,365/2,620/150,015/1,000,000]

It's interesting that Random can win any games at all.

I would be interested in how random up-capture would play (with random checkmate of course.)

You can also build a simple rule interpreter - in a similar style to a paper program (a program that a human can execute unambiguously.) For example if you are in check, try captures of the checking piece first, etc ....

Don