Author: Dann Corbit
Date: 15:21:56 03/03/06
Go up one level in this thread
On March 03, 2006 at 17:14:26, Odd Gunnar Malin wrote: >On March 03, 2006 at 16:46:13, Dann Corbit wrote: > >>On March 03, 2006 at 16:24:49, Odd Gunnar Malin wrote: >> >>>On March 03, 2006 at 13:59:27, Jay Urbanski wrote: >>> >>>>I'd like to get some comments on an idea that's been growing in the back of my >>>>head for some time now. The problem is that of opening books. We now have two >>>>open protocols for communication between engine and GUI with Winboard and UCI - >>>>but every GUI has chosen to go the route of a proprietary book format - >>>>presumably to lock users into that GUI. (Even Arena does this, something that >>>>puzzles me since it is free) This may be good for the vendors business models, >>>>but it bad for users since it limits choice. >>>> >>>>So what is the engine author to do? They can: >>>> >>>>A. Pick a GUI to support (and alienate users of other GUIs) >>>>B. Make an engine book (with almost certainly less features than the GUI books) >>>>C. Support all the GUIs (way too much effort, and almost certainly inconsistent >>>>quality of books) >>>> >>>>All of these have their shortcomings, so my proposal is the establishment of an >>>>open book format. The idea is that with one format option "B" could be a lot >>>>more attractive, especially if enough features were put into the book >>>>specification. >>>> >>>>A common objection to this idea is "It won't fly without support from the GUI >>>>vendors, and none of them will support it". I agree none of the GUI vendors are >>>>likely to support it at first (except maybe Arena?) but I contend that if enough >>>>engine authors support it, *and* we could get a decent book editor/viewer >>>>written so that users could view the book, tweak it, etc - it wouldn't matter >>>>whether the GUI authors support it. And if it became popular enough, the GUI >>>>vendors might add it as a feature due to customer demand. >>>> >>>>So I'd like comments/feedback/criticism from everyone. Book authors especially, >>>>what features would need to be present to make it a good format? As a user I >>>>would defnintely want book learning and an intuitive but flexible syntax to >>>>weight moves. >>>> >>>>Would an existing format like Polyglot be a good starting point? Would the >>>>Arena team consider donating the .ABK format as the basis? Would anyone be >>>>willing to donate programming skill & time toward a decent book editor/viewer? >>>> >>>>Am I the only one who cares about this? :) >>> >>>Isn't it easier to agree on some import rules for importing pgn-files, eg. !, ?! >>>etc. after the move are interpretet as the same in all gui when importing. >>>ChessPartner have another system that also could be considered, it allow you to >>>specify a score for each line in the pgn file. >>> >>>The problem I have is that I create my books as games with variations in a DB >>>program (CA for me). Then I have to make all sorts of converting to be able to >>>import it into the GUI I want to play with, ChessMaster, Shredder, ChessPartner >>>or even Fritz. I'm maybe excentric but I usually use the GUI that was attended >>>to the engine when I bought it. >>> >>>Maybe there is some shortcomming for the few who run engine-engine matches, but >>>for the big bunch that use the programs main feature it is realy enough with the >>>few scoring you get from a pgn-file (??,?,?!,<none>,!,!!). If the GUI in >>>addition have the ability to import Black and White into a repertoire for the >>>engineplayer so you can use a single book for both color when training, I think >>>all may needs should be taken care of. >>> >>>Odd Gunnar >> >>Suppose that a move is marked !! but your engine loses when choosing that move >>ten times in a row (a very real possibility if it is a good move but your engine >>does not know the plan). Wouldn't it be nice to have a book format that >>understands statistical inferences and knows it ought to switch to something >>else? > >Ten game in same line? wouldn't that take a year to come tru if the book have a >few lines. If the !! are missplaced you can easely correct it and import it >again to each gui. > >If you realy want to practice against the line the engine lose, why want you the >gui to avoid this? Neither the gui or the engine have any soul so I don't think >they care. > >Else I'm a fan of a good position learning, designed to give variation to the >player even if he start from a middle- or endgame position. > >I undestand from the other post that the main focus is on engine-engine games, >but for me an engine is only a tool for the human-player to train or get some >relaxed games from. > >Some scenary: >You want to create a thematic tournament and need some practice, then you can >create a training-book without thinking what gui the players prefere to use. > >Your team will play against the next opponent in the league next week, then as a >captain, or trainer, you want to prepare the players for this match. > >You have study an opening and want some practice on this. > >You will enter a tournament and create a trainingbook for this based on the >repertoire of your expected opponents. > >The !, ?? etc. is to have some control of how often each line are selected, >maybe one opponent play 1.f4 and 5 usually start with 1.e4, of course you want >the engine to play the 1.e4 line mostly because there would be more lines in >there. What you suggest is also fully supported by the model that I proposed, which has provision for NAGs.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.