A feature that is missing for me is the support of CTG book, and secondly the ability to open several books in the same chessboard.
Finally unlike kibitzer's engines, something that is expected for several years.
Most wanted missing features for a chess GUI
Moderators: hgm, Rebel, chrisw
-
- Posts: 284
- Joined: Tue Aug 13, 2013 9:44 am
-
- Posts: 27817
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Most wanted missing features for a chess GUI
This was just discussed in another thread, and the concensus seemed to be that this would actually be a rather undesirable thing, which serious testers would never use. Because it corrupts the test results by awarding wins to engines in end-games they would never be able to win by themselves (and draws in end-games they would have lost).kasinp wrote:For starters: an option to have GUI adjudicate the game once a tablebase position is reached. Without playing out silly 50-move sequences of K+R vs. K+R endgames as it can happen in Fritz GUI today.
The K+R vs K+R is easily solved by specifically recognizing that (and a few similar) cases, and adjudicating those after a few moves (to weed out short tactical wins). Like WinBoard's 'Trivial Draws' adjudication does.
What would be the use of multiple books? Would you want to combine their moves? The books could specify conflicting information.phenri wrote:A feature that is missing for me is the support of CTG book, and secondly the ability to open several books in the same chessboard.
Finally unlike kibitzer's engines, something that is expected for several years.
What do you mean by "unlike kibitzer's engines"?
Last edited by hgm on Tue Dec 17, 2013 9:15 am, edited 1 time in total.
-
- Posts: 41473
- Joined: Sun Feb 26, 2006 10:52 am
- Location: Auckland, NZ
Re: Most wanted missing features for a chess GUI
I use the tablebases adjudication feature in ChessGUI.hgm wrote:This was just discussed in another thread, and the concensus seemed to be that this would actually be a rather undesirable thing, which serious testers would never use. Because it corrupts the test results by awarding wins to engines in end-games they would never be able to win by themselves (and draws in end-games they would have lost).kasinp wrote:For starters: an option to have GUI adjudicate the game once a tablebase position is reached. Without playing out silly 50-move sequences of K+R vs. K+R endgames as it can happen in Fritz GUI today.
The K+R vs K+R is easily solved by specifically recognizing that (and a few similar) cases, and adjudicating those after a few moves (to weed out short tactical wins). Like WinBoard's 'Trivial Draws' adjudication does.
I'll be blowed if I'm going to waste computer time and power watching KR v KR or other such endings play out to a 50 move draw at a longish time control.
That's why I no longer use Arena.
gbanksnz at gmail.com
-
- Posts: 27817
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Most wanted missing features for a chess GUI
Well, like I said, in WinBoard KR vs KR or other such endings would never be played out to a 50-move draw, (if the user wishes so). Without the need to corrupt the test results.Graham Banks wrote:I'll be blowed if I'm going to waste computer time and power watching KR v KR or other such endings play out to a 50 move draw at a longish time control.
-
- Posts: 41473
- Joined: Sun Feb 26, 2006 10:52 am
- Location: Auckland, NZ
Re: Most wanted missing features for a chess GUI
The impact on test results would be very tiny, so not really an issue of concern.hgm wrote:Well, like I said, in WinBoard KR vs KR or other such endings would never be played out to a 50-move draw, (if the user wishes so). Without the need to corrupt the test results.Graham Banks wrote:I'll be blowed if I'm going to waste computer time and power watching KR v KR or other such endings play out to a 50 move draw at a longish time control.
gbanksnz at gmail.com
-
- Posts: 27817
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Most wanted missing features for a chess GUI
Have you actually measured that, or is it just wishful thinking?
My guess would be that on top engines it indeed might not matter too much, as these know very well how to win or defend complex end-games. But for weaker engines the impact could be far larger.
I know you test engines down to ~2000 Elo. And I know from experience that micro-Max habitually bungles KRPKR, which is a very common end-game (~10%?). Erasing the difference with an engine that can handle KRPKR perfectly by adjudicating at the 5-men level must lead to a sizable error in their rating difference.
Top engines would of course usually use tablebases themselves, so they would play instantly anyway after reaching 5-men. So it might not hurt there, but it also seems there is little benefit there.
Anyway, why engage in dubious practices if it is not necessary at all? Choosing between two evils is ill adviced when there is also a 'good' on the menu!
My guess would be that on top engines it indeed might not matter too much, as these know very well how to win or defend complex end-games. But for weaker engines the impact could be far larger.
I know you test engines down to ~2000 Elo. And I know from experience that micro-Max habitually bungles KRPKR, which is a very common end-game (~10%?). Erasing the difference with an engine that can handle KRPKR perfectly by adjudicating at the 5-men level must lead to a sizable error in their rating difference.
Top engines would of course usually use tablebases themselves, so they would play instantly anyway after reaching 5-men. So it might not hurt there, but it also seems there is little benefit there.
Anyway, why engage in dubious practices if it is not necessary at all? Choosing between two evils is ill adviced when there is also a 'good' on the menu!
-
- Posts: 3245
- Joined: Thu Mar 09, 2006 9:10 am
Re: Most wanted missing features for a chess GUI
There is a feature in ChessGUI that was suggested by Ray.hgm wrote: This was just discussed in another thread, and the concensus seemed to be that this would actually be a rather undesirable thing, which serious testers would never use. Because it corrupts the test results by awarding wins to engines in end-games they would never be able to win by themselves (and draws in end-games they would have lost).
...
It lets engines play out mating moves to within a user-defined range from checkmate before GUI adjudication kicks in. This verifies that the mating engine knew what it was doing.
I shall add an alternative approach which lets engines play out a user-defined number of mating moves before adjudication. The logic is: if an engine can go from "mate n" to "mate in n-x", where x is not very small, it wasn't by chance.
ChessGUI never adjudicates "mate in more than 50".
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
http://www.chess.hylogic.de
-
- Posts: 27817
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Most wanted missing features for a chess GUI
This definitely improves matters. (At least, from the viewpoint of unfair adjudication. Of course it also loses part of the time-saving advantage.) But it only solves part of the problem: won positions that the engine cannot win in practice. There are also theoretical draws that the engine doesn't know how to draw. KRKR belongs to those.
Tablebased adjudication just seems a complex and poor solution for a problem that has a simple and much more satisfactory solution. KRKR really is a special case in terms of the stupidity needed to lose it (together with KBKN, KNKN, KBKB* and KNNK). Other end-games are not like that at all.
Tablebased adjudication just seems a complex and poor solution for a problem that has a simple and much more satisfactory solution. KRKR really is a special case in terms of the stupidity needed to lose it (together with KBKN, KNKN, KBKB* and KNNK). Other end-games are not like that at all.
-
- Posts: 284
- Joined: Tue Aug 13, 2013 9:44 am
Re: Most wanted missing features for a chess GUI
hgm wrote:What would be the use of multiple books? Would you want to combine their moves? The books could specify conflicting information.phenri wrote:A feature that is missing for me is the support of CTG book, and secondly the ability to open several books in the same chessboard.
Finally unlike kibitzer's engines, something that is expected for several years.
What do you mean by "unlike kibitzer's engines"?
Hi HGM
because "A picture is worth a thousand words" (the yellow part is a photo montage)
best regards
-
- Posts: 27817
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Most wanted missing features for a chess GUI
Well, the picture does not tell everything. Is this just interactive analysis with multiple engines? Or is the idea that you have 'spectator engines' analyzing when a 'main engine' is doing something else (like playing against a human, or on an ICS)?
As to the book:
OK, I see multiple sets of book moves are listed in the display. Is displaying them all you want to do, or should they actually be used for something?
As to the book:
OK, I see multiple sets of book moves are listed in the display. Is displaying them all you want to do, or should they actually be used for something?