DiscoCheck 4.2

[lucasart]

Hi,

what made your engine play 3. ... Na6. This looks like a very weak move even given the search limit of 1000 nodes. It doesn't really move the knight to a good spot and it also does not help to increase the mobility of the other pieces.

I just had a look at my (much weaker) engine. I have not implemented a search node limit but a ply 3 search uses about 1000 nodes in that position and it suggests 3. ... e6

It probably doesn't save the day but looks more natural. If you look into this you might get some ideas to further improve your monster.

Thomas...

I'll have a look to see if there isn't a bug hidden there. But I suspect it's the correct behaviour. The thing is that at low depths, move count pruning kicks in, and the move ordering is stupid, because the history and refutation tables haven't been taught how to order moves very much. If I improve this (by initializing history tables more properly, like with eval increment + SEE), there will be no ELO impact, and it will play better at shallow depths. But I like the fact that reducing the depths makes it play really weaker, and capable of blunders. It's hard to find programs that one can beat these days. Skill levels and multi-PV are definitely on my todo list.

PS: I played the revenge in 2048 nodes, and lost it... Obviously, I wasn't very proud, so I didn't post that PGN

[tpetzke]

PS: I played the revenge in 2048 nodes, and lost it... Obviously, I wasn't very proud, so I didn't post that PGN

Embarrassing, isn't it. I implemented skill levels in my GUI, basically just skill level 1 = search 1 ply, 2 = 2 plies ... 10. So the GUI sends a "go depth x" instead of the usual time control

I have a hard time to beat level 1, and managed only once or twice to beat level 2. So I had to implement a "probability to pick a random move" scheme for the lower levels where the response from the engine is ignored and the GUI plays a random move from its own move generator.

This helped

Thomas...

[jd1]

PS: I played the revenge in 2048 nodes, and lost it... Obviously, I wasn't very proud, so I didn't post that PGN

Embarrassing, isn't it. I implemented skill levels in my GUI, basically just skill level 1 = search 1 ply, 2 = 2 plies ... 10. So the GUI sends a "go depth x" instead of the usual time control

I have a hard time to beat level 1, and managed only once or twice to beat level 2. So I had to implement a "probability to pick a random move" scheme for the lower levels where the response from the engine is ignored and the GUI plays a random move from its own move generator.

This helped

Thomas...

Interesting. I am about 2100-2200 OTB elo, and I win about as many as I lose against Toga II at depth 9 or so (as long as I have about 15 minutes for the entire game) ...

Jerry

[lucasart]

Thanks, Lucas. This one seems to work under Arena, however, from the command line, after issuing 'uci', 'new' and 'go' it crashes.

Don't worry, it's perfectly normal. You messed up the UCI commands:

- 'uci' is useless: all it does is show some info and options. only useful for the GUI (or to know which options are available and what are their current values).
- 'new' is not a valid UCI command.
- 'go' should *always* be preceeded by a 'position' command (as well as an isready, but you can skip that in interactive mode when typing directly to the engine).

Here's a sample session, to clarify:

Code: Select all

$ uci
id name DiscoCheck 4.2
id author Lucas Braesch
option name Hash type spin default 16 min 1 max 8192
option name Clear Hash type button
option name Contempt type spin default 25 min 0 max 100
uciok

$ setoption name Hash value 32
$ ucinewgame
$ position startpos moves e2e4 c7c5

$ go depth 5
info score cp 59 depth 1 nodes 30 time 0 pv b1c3
info score cp 20 depth 2 nodes 151 time 0 pv d2d4 g8f6
info score cp 47 depth 3 nodes 760 time 1 pv b1c3 b8c6 f1e2
info score cp 15 depth 4 nodes 1176 time 2 pv b1c3 b8c6 f1e2 g8f6
info score cp 31 depth 5 nodes 1430 time 2 lowerbound
info score cp 31 depth 5 nodes 1972 time 3 pv b1c3 b8c6 f1e2 g8f6 g1f3
bestmove b1c3

$ quit

don't type the '$' obviously. this is just to distinguish the commands you type ($) from what the engine answers.

[tpetzke]

Interesting. I am about 2100-2200 OTB elo, and I win about as many as I lose against Toga II at depth 9 or so (as long as I have about 15 minutes for the entire game) ...

Jerry

Yes, this probably tells more about my chess skills than about my programmer skills. I have no rating and I rarely play OTB. When I play against iCE I usually also think only a few seconds about a move. Usually the goal is not to win but to spot some strange behavior. The move 3. ... Na6 from Lucas game would have caught my attention as iCE is not suspected to play such a move. Even with a ply 1 search it should try to increase the mobility of its pieces.

If you want you can give it a try. If you win ply 9 games against Toga you will probably crush iCE easily.

www.fam-petzke.de/downloads/mace_gui_02.zip

Thomas...

[hgm]

Note that whether 'uci' or 'isready' can be skipped might be engie-dependent, and Lucas' remarks should only be taken to refer to DiscoCheck. It would be a perfectly valid UCI design to wait with allocating memory for a hash table until you receive the 'isready', to be sure that any attempts of the GUI to set hash size through sending a 'setoption Hash' have been received before you start to allocate it. Such an engine would crash when it receives a 'go' command without having first seen an 'isready', as its hash memory is not yet existent.

For engines that support multiple protocols it would be a very natural thing to consider the 'uci' command as the trigger to switch to UCI mode, and they might stay in WinBoard mode or using their own interactive text-based interface if you don't send it. So in general, when you try to run UCI engines from the command line, always start with

uci
isready
ucinewgame
...

[lucasart]

It would be a perfectly valid UCI design to wait with allocating memory for a hash table until you receive the 'isready', to be sure that any attempts of the GUI to set hash size through sending a 'setoption Hash' have been received before you start to allocate it. Such an engine would crash when it receives a 'go' command without having first seen an 'isready', as its hash memory is not yet existent.

You're right. That would be perfectly UCI compliant. In fact, it's arguably the best way to proceed. Suppose the default hash is a large value that is intended for high end computers, and we play on some resource limited machine. Then DiscoCheck would crash allocating the default hash, before it gives the chance to the GUI to request a smaller size. The way I fixed that problem is:
- in versions <= 3.7.1, I would delay the hash table allocation to the first "go" command (which is bad because it counts in the engine clock), or the first "setoption name Hash value ..." command.
- in version 4.2, I simply reduced the default hash to a low value of 16 MB, but it's allocated when the program starts (and the program crashes on failure of memory allocation).

I'll probably do what you describe in the next version.

For engines that support multiple protocols it would be a very natural thing to consider the 'uci' command as the trigger to switch to UCI mode, and they might stay in WinBoard mode or using their own interactive text-based interface if you don't send it. So in general, when you try to run UCI engines from the command line, always start with

uci
isready
ucinewgame
...

Yes, indeed. Completely forgot about that. Engine can have Xboard, UCI, as well as its own interactive mode. So it typically considers 'uci' and 'xboard' command to say 'switch to UCI or Xboard mode'. So yes, the minimum comands to type in my previous example, that will work with any UCI compliant engine are:

Code: Select all

uci
isready
ucinewgame
position startpos
go depth 5
quit

the isready after ucinewgame or position commnad, are only for synchronization purposes between the GUI and the engine. In interactive mode it's not a problem, because it completes the task before processing the next input (and even if it did it asynchronously, it would be so fast, there's no way you could type with your keyboard faster than the engine flushes a hash table or parses a position command).

[geots]

Lucas, is there any possible way that you might consider changing the name back to "DoubleCheck"? Any big favor I could do for you- I am even willing to get my hands dirty with Windows.



All the best, my wonderful, charming, intelligent, modest, honest, helpful, kind, generous, thoughtful and dear friend-

george

[lucasart]

PS: I played the revenge in 2048 nodes, and lost it... Obviously, I wasn't very proud, so I didn't post that PGN

Embarrassing, isn't it. I implemented skill levels in my GUI, basically just skill level 1 = search 1 ply, 2 = 2 plies ... 10. So the GUI sends a "go depth x" instead of the usual time control

I think thet using nodes instead of depth is better. The point is that it automatically increases the depth in the endgame as the branching factor becomes smaller. Typically when you play an engine at depth=2, it's easy to win by exchanging pieces and going for an endgame, at which point they really blunder and need more depth.

After 3 failed attempts, I finally managed to beat DiscoCheck at 2048 nodes/move. This time DiscoCheck was allowed an opening book (8 moves). I was actually losing, until it blundered in the endgame.
[pgn]
[White "lucas"]
[Black "Discocheck_4.2_sse4.2"]
[Result "1-0"]

1. e4 c6 2. d4 d5 3. exd5 cxd5 4. Nf3 Nc6 5. Bb5 Nf6 6. O-O Bf5 7. c3 Qb6
8. a4 Rc8 9. b4 Ng4 10. h3 Nf6 11. Ne5 h5 12. Nxc6 bxc6 13. Be2 a5 14. Ba3
g5 15. f4 g4 16. hxg4 hxg4 17. Nd2 Ra8 18. bxa5 Qxa5 19. Bb4 Qa7 20. Nb3
Rb8 21. a5 e6 22. Nc5 Ne4 23. Qa4 Qa8 24. a6 Bxc5 25. Bxc5 Nxc3 26. a7 Nxa4
27. axb8=Q+ Qxb8 28. Rxa4 Rh7 29. Rfa1 Kd7 30. Ra7+ Kc8 31. Ra8 Qxa8 32.
Rxa8+ Kc7 33. Ra7+ Kd8 34. Bb6+ Ke8 35. Ba6 Be4 36. Bb7 Ke7 37. Bxc6+ Kf6
38. Bd8+ Kf5 39. Be8 Kxf4 40. Rxf7+ Rxf7 41. Bxf7 Kf5 42. g3 e5 43. dxe5
Kxe5 44. Kf2 d4 45. Bb3 Bd5 46. Bxd5 Kxd5 47. Ke2 Kc4 48. Kd2 Kb4 49. Kd3
Kc5 50. Bf6 Kc6 51. Kxd4 Kd6 52. Ke4 Kc6 53. Kf5 Kd5 54. Kxg4 Ke4 55. Kg5
Kd5 56. Bd8 Kd6 57. Kf6 Kd7 58. Ba5 Ke8 59. Bb4 Kd8 60. g4 Kc7 61. g5 Kd7
62. g6 Kc6 63. g7 Kd5 64. g8=Q+ Kc6 65. Qc4+ Kb6 66. Bd6 Kb7 67. Qb5+ Kc8
68. Qc6+ Kd8 69. Qc7+ Ke8 70. Qc8# 1-0
[/pgn]

PS: No take back, no playing the same opening twice. No cheating. Promised!