Most wanted missing features for a chess GUI

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

User avatar
Matthias Gemuh
Posts: 3245
Joined: Thu Mar 09, 2006 9:10 am

Re: Most wanted missing features for a chess GUI

Post by Matthias Gemuh »

ernest wrote:
Matthias Gemuh wrote:ChessGUI is still at version 0.245g.
Hi Matthias,

When I download from your BigLion site, I still get the same you called 0.245f. :)

a bit difficult to follow... especially since the ChessGui.exe version still appears as 1.0.0.0
Oops ! Maybe I forgot to upload. :oops: Try again.
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
User avatar
hgm
Posts: 27808
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Most wanted missing features for a chess GUI

Post by hgm »

Edmund wrote:Even with egtb access they will not necessarily move instantly - ie if they only have wdl information or if they are trying to lure the opponent into making an error.
That seems pretty pointless to me. Of course they should not blunder away material, or move their pieces to bad places, to keep some pressure. But a 1-ply search (+ QS, and guided to stay in the draw sector) seems already enough to achieve that. So let's be liberal, and allow them to search 5 ply. That would still be an instant move.
carldaman
Posts: 2283
Joined: Sat Jun 02, 2012 2:13 am

Re: Most wanted missing features for a chess GUI

Post by carldaman »

hgm wrote: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.
Well, (just to rehash an old topic) even KQKQ is similar to KRKR: if there is no tactical win found in 3-5 moves, it can be adjudicated as a trivial draw as well.

There is one more trivial draw that needs to be adjudicated, lest it be dragged out for 50/100/150/etc moves: a drawn KPK endgame where the lone King for some reason refuses to capture the last pawn, which then advances one more square, and yet another, and 50 more moves get wasted ad nauseam as the tedious process is repeated. This turns out to be even worse than KRKR, which is pretty much guaranteed to end in no more than 50 moves.

I've seen multiple recent examples of this silliness. Probably 10 moves or so would have to elapse before trivial draw adjudication, in order to weed out won endgames.

CL
carldaman
Posts: 2283
Joined: Sat Jun 02, 2012 2:13 am

Re: Most wanted missing features for a chess GUI

Post by carldaman »

hgm wrote:
Even adding moves only when you get out of book at the end of a line is not satisfactory: as soon as one move was added, it would no longer be out of book in that position, so you would never get any others. So no branching, just a single very deep line.

This is why I added the MC book mode in WinBoard, intended for creating or expanding a book. In this mode it does not try to use the book for strength, and often intentionally forces weak moves in order to explore them, in the hope engines will find an improvement. And often does not play a book move at all, despite the fact it has many available for the position, to see if the engine can come up with a new move, to add that to the book. That differs quite a lot from how you would want a book to affect move choice in normal play. But if you especially conducted matches or tournaments for building a book, you use this book mode with it. (E.g. with a multi-cycle round-robin of engines carefully handicapped by time odds to make them equally strong.)

Isn't this basically already exactly what you want?
Agreed, this has to be an improvement over the old Mchess method. I had no idea there was an 'MC' mode -- sometimes WB's best features are a well kept secret ;)
hgm wrote:
Re: CB deep analysis -- an analysis tree will be created, but this is just a tree of variations (with engines analyzing candidate moves for both sides) within the game notation itself, meaning that no special or separate tree file will be created as a result of deep overnight analysis. All the analysis should be stored within the game notation, at least it's supposed to, if all goes well...
OK, so if I understand this well, the GUI would perform some kind of tree walk with the engine in analysis mode, and record the result as (annotated?) recursive variations in PGN format.

In itself this is not difficult to implement, but the usefulness stands or falls with the algorithm that would be used for walking the tree. How would a GUI decide which alternative moves to try, and how deep it should follow the PV suggested by the engine?
Yes, a tree walk is performed and the resulting variations are recorded in the pgn. There are multiple parameters that help determine how many alternatives are looked at and a threshold can be set for excluding clearly inferior 2nd best moves.
carldaman
Posts: 2283
Joined: Sat Jun 02, 2012 2:13 am

Re: Most wanted missing features for a chess GUI

Post by carldaman »

gordonr wrote:
carldaman wrote:Better than what CB has right now, where much meaningful and useful overnight deep analysis will not be stored for some reason.
I guess you're interested in having a decent analysis tree being generated rather than putting all the effort into finding the best move in the root position? I can understand why this would be useful.

I'm just curious because I believe some people use deep analysis in order to only find the best move in a position and do so while using a single engine. Surely analysing just the root is more effective?! Using multiple engines complicates things but even here, surely no need to generate a tree while no disagreement at root.
If I can determine offhand, in a few minutes, that most engines I normally use agree on the same move, I may start the deep analysis with a different root position, where there is disagreement.

If analyzing a corr game, then, even with no clear disagreement at the root position, I may still run several engines in infinite analysis mode first overnight, to make sure there are no hidden deeper threats that may be missed by the subsequent 'deep position analysis', where the engines will only spend several minutes on each position analyzed. The deep analysis is so called 'deep' not so much because of the time spent on each move, but rather this refers to drilling deeper into the position, by exploring multiple alternatives and follow-ups.

The deep analysis is primarily to be used overnight, or when one is not available to interact with the analysis. Otherwise, it's better to steer the analysis oneself, and this is where the real skill comes in - both analytical abilities and chess strength are a big plus at this stage.
gordonr
Posts: 194
Joined: Thu Aug 06, 2009 8:04 pm
Location: UK

Re: Most wanted missing features for a chess GUI

Post by gordonr »

carldaman wrote: If I can determine offhand, in a few minutes, that most engines I normally use agree on the same move, I may start the deep analysis with a different root position, where there is disagreement.

If analyzing a corr game, then, even with no clear disagreement at the root position, I may still run several engines in infinite analysis mode first overnight, to make sure there are no hidden deeper threats that may be missed by the subsequent 'deep position analysis', where the engines will only spend several minutes on each position analyzed. The deep analysis is so called 'deep' not so much because of the time spent on each move, but rather this refers to drilling deeper into the position, by exploring multiple alternatives and follow-ups.

The deep analysis is primarily to be used overnight, or when one is not available to interact with the analysis. Otherwise, it's better to steer the analysis oneself, and this is where the real skill comes in - both analytical abilities and chess strength are a big plus at this stage.
Thanks for that. Just curious, if you do “run several engines in infinite analysis mode first overnight” and no disagreement, do you still do subsequent deep analysis? I agree with “better to steer the analysis oneself”, when possible, but I find it interesting to consider what the human “driver” is doing that is difficult/impossible to automate. I experiment with my own “deep analysis” code which does root only unless disagreement.
ernest
Posts: 2041
Joined: Wed Mar 08, 2006 8:30 pm

Re: Most wanted missing features for a chess GUI

Post by ernest »

Matthias Gemuh wrote:Oops ! Maybe I forgot to upload. :oops: Try again.
Come on, Matthias... still the same!!! :o
User avatar
Matthias Gemuh
Posts: 3245
Joined: Thu Mar 09, 2006 9:10 am

Re: Most wanted missing features for a chess GUI

Post by Matthias Gemuh »

ernest wrote:
Matthias Gemuh wrote:Oops ! Maybe I forgot to upload. :oops: Try again.
Come on, Matthias... still the same!!! :o
http://biglion.bplaced.net/ ? It is 0.245g.


http://biglion.bplaced.net/chess/ChessGUI.zip
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
User avatar
Graham Banks
Posts: 41455
Joined: Sun Feb 26, 2006 10:52 am
Location: Auckland, NZ

Re: Most wanted missing features for a chess GUI

Post by Graham Banks »

Looks like it from here.
gbanksnz at gmail.com
User avatar
Matthias Gemuh
Posts: 3245
Joined: Thu Mar 09, 2006 9:10 am

Re: Most wanted missing features for a chess GUI

Post by Matthias Gemuh »

Graham Banks wrote:
Looks like it from here.
8-) :wink:
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de