Cute Chess 0.9.4 released

[PaulieD]

I find that many GUI's put out different tables. That is why I always use Ordo to select the output that "I" want to see.

There was still a really nasty bug causing crashes in tournaments so I've made a bugfix release for 64-bit Windows and Linux: https://github.com/cutechess/cutechess/ ... /gui-0.9.4

There's also a bonus feature - support for the "UCI_Variant" UCI option.

I am not sure if this is normal, but in the tour result in a gauntlet the error was nan even though the score is not 100%

IMHO the table should contain the real points too, not only the percentage
and precision should be at least one decimal for score and draws.

[ilari]

There was still a really nasty bug causing crashes in tournaments so I've made a bugfix release for 64-bit Windows and Linux: https://github.com/cutechess/cutechess/ ... /gui-0.9.4

There's also a bonus feature - support for the "UCI_Variant" UCI option.

I am not sure if this is normal, but in the tour result in a gauntlet the error was nan even though the score is not 100%

Cute Chess' errorMargin algorithm (the same that Stockfish testing framework uses) needs more points on the losing side. Now you have 27 wins and 3 losses. With 4 losses (or 3 losses and a draw) you'll get a result.

And it looks like the percentages could really use more precision, at least one decimal point like Guenther said.

[ilari]

I just ran 2 - 3000 game tournaments with 4 engines each at a time control of 10 +.01. The first was with CutechessGUI 0.9.4, the second with Cutechess-cli 0.8.2
After 6000 games the results were all within error bars between the 2 GUI's.
So it would appear the CuteChessGUI 0.9.4 is "lightweight" also.

Nice Work!
I look forward to further updates.

Cute Chess GUI uses the same lightweight libcutechess library as cutechess-cli that is very efficient at running games and communicating with engines. But in fast games, especially if you open the "Active Games" widget when there are many concurrent games, UI updates like animating the pieces and drawing the evaluation graph will use a lot more CPU than cutechess-cli would.

However, if you keep one CPU core free for Cute Chess, even high CPU load on the GUI should not affect the games because they each run in a separate thread and don't have to wait for the UI.

[PaulieD]

Cute Chess GUI uses the same lightweight libcutechess library as cutechess-cli that is very efficient at running games and communicating with engines. But in fast games, especially if you open the "Active Games" widget when there are many concurrent games, UI updates like animating the pieces and drawing the evaluation graph will use a lot more CPU than cutechess-cli would.

However, if you keep one CPU core free for Cute Chess, even high CPU load on the GUI should not affect the games because they each run in a separate thread and don't have to wait for the UI.

When I run these matches, I close all windows except the main window and, of course, leave a thread open for OS.
I am impressed

[royb]

There was still a really nasty bug causing crashes in tournaments so I've made a bugfix release for 64-bit Windows and Linux: https://github.com/cutechess/cutechess/ ... /gui-0.9.4

There's also a bonus feature - support for the "UCI_Variant" UCI option.

Is there a way to interrupt a tournament and then resume it without having to start the tournament over?

Not at this time.

http://www.talkchess.com/forum/viewtopi ... 92&t=61463

OK, if that gets implemented, then I can make the switch away from Arena, but not until then as I do not have a dedicated computer to run 1000 game matches on for days at a time.

This is so close ... Thank you so much for all you have done!

[hgm]

I just ran 2 - 3000 game tournaments with 4 engines each at a time control of 10 +.01. The first was with CutechessGUI 0.9.4, the second with Cutechess-cli 0.8.2
After 6000 games the results were all within error bars between the 2 GUI's.
So it would appear the CuteChessGUI 0.9.4 is "lightweight" also.

Not sure what that has to do with being 'lightweight', however. Wether the GUI uses up 1%, 5% or 50% of the time should not affect the tourney result in the slightest.

[Laskos]

I just ran 2 - 3000 game tournaments with 4 engines each at a time control of 10 +.01. The first was with CutechessGUI 0.9.4, the second with Cutechess-cli 0.8.2
After 6000 games the results were all within error bars between the 2 GUI's.
So it would appear the CuteChessGUI 0.9.4 is "lightweight" also.

Not sure what that has to do with being 'lightweight', however. Wether the GUI uses up 1%, 5% or 50% of the time should not affect the tourney result in the slightest.

This is not entirely true. If engines run at 50%, 75% or 100% speed in one interface or another, it can affect the outcome in case the engines are scaling differently with time control. With ultra-fast games it is an often occurring issue. So, one better keeps the UI as separated as he can from the cores/threads used by engines, and often it's only doable by having a very sparsely CPU hungry UI.

[Ferdy]

There was still a really nasty bug causing crashes in tournaments so I've made a bugfix release for 64-bit Windows and Linux: https://github.com/cutechess/cutechess/ ... /gui-0.9.4

There's also a bonus feature - support for the "UCI_Variant" UCI option.

Run a tour with polyglot book, play each opening twice, depth is up to 6 full moves. At certain move number there is no more book move, so one engine searches a move, but after that the gui uses again the book and found a move in it and plays it.
Perhaps once the book is out of book (first time), do not allow the gui to use the book again, so that the use of book moves is guaranteed to be equal.

[Event "CCVA 2-Stage Tour Nr9"]
[Site "i7-2600K"]
[Date "2016.09.24"]
[Round "1"]
[White "Sjaak II 1.3.1a 64bit"]
[Black "NebiyuAlien 1.45a 32bit"]
[Result "0-1"]
[PlyCount "44"]
[TimeControl "60+1"]
[Variant "crazyhouse"]

1. e4 {book} e5 {book} 2. Nf3 {book} Nc6 {book} 3. Bb5 {book} Nf6 {book}
4. Bxc6 {book} bxc6 {+0.64/14 2.3s} 5. Nxe5 {+0.08/9 2.3s} Qe7 {+1.06/14 2.6s}
6. N@d3 {-0.05/8 2.9s} Nxe4 {+0.94/14 2.7s} 7. Qe2 {-0.26/8 2.5s}
P@d5 {+1.26/13 2.7s} 8. Nc3 {-0.01/8 1.8s} Ba6 {+0.84/12 2.8s}
9. Nxe4 {-0.24/8 2.5s} dxe4 {+4.26/14 2.6s} 10. P@d6 {-2.61/8 1.8s}
Qxe5 {+5.96/13 2.3s} 11. N@f3 {-7.14/7 2.8s} Qd5 {+12.60/13 2.4s}
12. O-O {-11.28/8 2.0s} N@e6 {+13.02/15 2.2s} 13. dxc7 {-13.50/10 3.2s}
B@d6 {+13.10/12 2.2s} 14. Qe3 {-12.46/8 2.2s} N@g4 {+16.92/14 2.1s}
15. Qe2 {-14.53/8 1.7s} exf3 {+19.06/14 2.3s} 16. Qxf3 {-19.67/9 3.0s}
Qxf3 {+20.06/12 1.9s} 17. c8=Q+ {-42.99/7 6.8s} Rxc8 {+25.52/12 1.7s}
18. gxf3 {-M10/7 2.0s} Bxh2+ {+M12/17 2.3s} 19. Kh1 {-M8/60 0.72s}
Nxf2+ {+M10/17 1.7s} 20. Kxh2 {-M6/60 1.2s} Q@h3+ {+M8/19 1.9s}
21. Kg1 {-M4/2 0s} Qg3+ {+M6/27 1.7s} 22. P@g2 {-M2/60 0.007s}
N@e2# {+M4/31 1.8s, Black mates} 0-1

[Event "CCVA 2-Stage Tour Nr9"]
[Site "i7-2600K"]
[Date "2016.09.24"]
[Round "1"]
[White "NebiyuAlien 1.45a 32bit"]
[Black "Sjaak II 1.3.1a 64bit"]
[Result "1-0"]
[PlyCount "87"]
[TimeControl "60+1"]
[Variant "crazyhouse"]

1. e4 {book} e5 {book} 2. Nf3 {book} Nc6 {book} 3. Bb5 {book} Nf6 {book}
4. Bxc6 {book} dxc6 {+0.12/10 3.5s} 5. Nxe5 {book} Qd4 {+0.81/8 2.1s}
6. N@f3 {-1.06/15 2.8s} Qxe4+ {+0.50/7 2.8s} 7. P@e3 {-1.08/14 2.8s}
B@g4 {+0.59/8 1.6s} 8. Nxg4 {+0.24/14 2.7s} Qxg4 {+0.97/9 2.2s}
9. B@h3 {-0.28/15 2.5s} Qh5 {+0.84/10 2.3s} 10. Bxc8 {-0.60/16 2.7s}
Rxc8 {+0.92/9 2.5s} 11. Nc3 {-0.58/15 2.6s} P@g4 {+1.01/9 2.1s}
12. Nd4 {-0.38/13 2.6s} Bd6 {+0.82/8 1.6s} 13. B@g3 {-0.16/13 2.5s}
Bxg3 {+1.23/8 1.7s} 14. fxg3 {-0.16/15 2.3s} c5 {+0.82/8 2.1s}
15. B@a4+ {-0.06/13 1.9s} c6 {+1.48/8 2.6s} 16. Nxc6 {+0.16/15 2.2s}
bxc6 {+2.88/9 2.0s} 17. P@b7 {+0.36/16 2.2s} Rb8 {+2.88/9 2.9s}
18. Bxc6+ {+1.12/15 2.0s} Kd8 {+3.28/8 3.1s} 19. d4 {+0.24/14 3.8s}
Kc7 {+3.05/8 2.2s} 20. P@d5 {+0.06/13 2.2s} B@b4 {+3.10/7 1.5s}
21. dxc5 {+0.06/12 2.1s} N@e5 {+3.78/7 2.4s} 22. O-O {+0.66/12 2.1s}
Bxc5 {+2.14/7 2.3s} 23. Rxf6 {+3.38/13 1.8s} gxf6 {+4.08/7 2.5s}
24. N@a8+ {+3.00/14 2.1s} Kd6 {+1.30/6 1.2s} 25. Ne4+ {+1.42/14 7.6s}
Ke7 {-0.54/2 0.002s} 26. d6+ {+4.38/13 2.0s} Kf8 {-1.85/6 1.5s}
27. P@c7 {+4.06/13 1.5s} Nxc6 {-2.15/6 2.4s} 28. c8=Q+ {+4.74/11 1.5s}
B@e8 {-3.93/6 2.4s} 29. d7 {+10.50/11 1.8s} B@f2+ {-7.36/5 1.4s}
30. Nxf2 {+18.20/13 1.7s} R@e7 {-16.52/7 2.3s} 31. dxe8=Q+ {+20.74/14 1.8s}
Rxe8 {-18.12/7 2.2s} 32. Qxc6 {+21.72/12 1.8s} Kg7 {-19.17/7 1.9s}
33. N@d7 {+21.92/12 1.8s} N@e6 {-19.45/7 1.9s} 34. Nxb8 {+23.64/12 2.2s}
Rxb8 {-20.18/7 1.3s} 35. R@h4 {+24.80/12 1.3s} P@e2 {-21.30/7 1.1s}
36. Qxe2 {+28.62/12 1.7s} Qe5 {-23.70/7 2.1s} 37. P@c7 {+30.42/10 1.6s}
Nxc7 {-28.46/5 1.1s} 38. Qxc7 {+36.48/11 1.6s} Bd6 {-33.50/5 1.2s}
39. B@h6+ {+49.56/11 1.3s} Kg8 {-M10/7 9.0s} 40. Qxb8+ {+M12/16 1.2s}
N@e8 {-M8/60 0.57s} 41. Qxg4+ {+M10/16 1.7s} P@g5 {-M6/3 0.009s}
42. R@g7+ {+M8/20 1.3s} Kf8 {-M4/2 0.001s} 43. N@d7+ {+M6/24 1.2s}
Ke7 {-M2/2 0s} 44. B@d8# {+M4/30 1.4s, White mates} 1-0

[hgm]

This is not entirely true. If engines run at 50%, 75% or 100% speed in one interface or another, it can affect the outcome in case the engines are scaling differently with time control. With ultra-fast games it is an often occurring issue. So, one better keeps the UI as separated as he can from the cores/threads used by engines, and often it's only doable by having a very sparsely CPU hungry UI.

They would have to scale extremely differently in order to get them outside each other's error bars, at this number of games. I mention 50% as an extreme case. 1% vs 10% would be more typical cases (i.e. the GUI using 1 vs 15 ms/move). There is no way you would see the scaling difference by just giving them 10% less time.

And there is no indication at all that the engines used did indeed scale differently.

[hgm]

Perhaps once the book is out of book (first time), do not allow the gui to use the book again, so that the use of book moves is guaranteed to be equal.

That is a book problem. Trying to solve it in the GUI would be a mistake. If you want to use a neutral 6-move book for starting tourney games, all lines in the book should be 6 moves. Otherwise white can do the last book move, tso that black has one less.