Author: Robert Hyatt
Date: 11:47:31 06/03/04
Go up one level in this thread
On June 03, 2004 at 11:33:48, Matthew Hull wrote: >On June 03, 2004 at 11:19:18, Robert Hyatt wrote: > >>On June 03, 2004 at 06:29:23, Vasik Rajlich wrote: >> >>>On June 02, 2004 at 22:16:20, Robert Hyatt wrote: >>> >>>>On June 02, 2004 at 18:18:30, Vasik Rajlich wrote: >>>> >>>>>On June 02, 2004 at 16:24:19, Dan Honeycutt wrote: >>>>> >>>>>>On June 02, 2004 at 14:59:34, Robert Hyatt wrote: >>>>>> >>>>>>>On June 02, 2004 at 14:08:44, Dan Honeycutt wrote: >>>>>>> >>>>>>>>On June 02, 2004 at 12:23:29, Robert Hyatt wrote: >>>>>>>> >>>>>>>>>On June 02, 2004 at 06:48:03, Vasik Rajlich wrote: >>>>>>>>> >>>>>>>>[snip] >>>>>>>> >>>>>>>>>>frosting on the cake. >>>>>>>>>> >>>>>>>>>>For an amateur engine though, it's just a distraction. We have enough >of those >>>>>>>>>as it is. The various zero-cost solutions are totally >sufficient. >>>>>>>> >>>>>>>>> >>>>>>>>>What is a "zero cost solution" to the book problem? I've been working >on a >>>>>>>>chess program since 1968. I have _never_ found a "zero cost >solution" to the >>>>>>>>book problem. My current effort is the closest there >can be, because once I >>>>>>>>wrote the code (which did not take months of >effort by the way) it began to >>>>>>>>manage its own book, freeing me from >that responsibility. Net gain in >>>>>>>>productivity was very large. If you >don't learn, you either hand-tune or get >>>>>>>>killed. The former is a huge >time drain, the latter is unpleasant. :) >>>>>>>> >>>>>>>>>I have published a paper in the JICCA explaining _exactly_ how I did >learning. >>>>>>>>So you don't have to start from scratch, which I did. And >even from scratch it >>>>>>>>was hardly a huge effort. The complete learning >code in crafty, book and >>>>>>>>position, importing, exporting, everything is >1200 lines of C with plenty of >>>>>>>>comments. It isn't _that_ hard to do... >>>>>>>>> >>>>>>>>>I'm sure that if I could do it, anyone could do it... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>Just my 2 cents of course ... >>>>>>>>>> >>>>>>>>>>Vas >>>>>>>> >>>>>>>>I think Vas was talking to me, not you. A (near) zero-cost solution is >to get a >>>>>>>collection of high quality games, grind those into a book and >let the engine >>>>>>>play move so-and-so the same percent of the time as >played in the games >>>>>>>collection. Your engine prefers 1 d4 over 1 e4. >Mine has too little experience >>>>>>>to know what it prefers. >>>>>>>> >>>>>>>>Dan H. >>>>>>> >>>>> >>>>>The simplest solution is to let the GUI handle the opening. This provides >an >>>>easy graphical environment for manual tuning, control over compilation >criteria, >>>>controllable learning heuristics, etc. >>>> >>>>That would not be a bad idea, but it is _way_ too late. IE the "crafty" >text >>>engine does _everything_ by itself. Because in real tournaments (like >the WCCC >>>and so forth) I prefer to operate in a console window and type in >commands and >>>moves. IE Xboard/Winboard don't have an easy way to adjust the >time, or specify >>>tournament-type (non increment but with a secondary time >control, sudden death, >>>etc) while crafty supports those just fine. >>>> >>> >>>I suppose crafty is a sort of special case, you already have all of this >stuff, >>maybe back from days when GUIs weren't very good. The big benefit you >get from >>your work is platform independence. An additional benefit is that >you're not >>stuck if the GUI won't do something that you would like. >>> >>>I see letting the GUI handle this stuff as a zero-cost, 95% effective, >solution. > >>Crafty was started late in 1994 right after the last ACM computer chess event >>that was held that year. At that point there were no general-purpose GUIs >>available other than the very simple (at the time) xboard protocol GUI for >unix >and windows... >> >>There's certainly a lot to be said for removing the book stuff from the >engine, >and moving it to another software module which could be the GUI or >even >something separate from the GUI and engine. But the problem with that is >that >there is plenty of research left to do with respect to the opening book >and >opening move selection, including learning. Using a generic black box >removes >any control you might be able to exert when you write the code >yourself... > >> >>> >>>> >>>>> >>>>>Bob, IIRC the crafty .exe has a built in interface, which can be used to >play >>>>games, etc. Without this, a built-in opening book would be really >tough to >>>>maintain & inspect. You should really include the code for this >when talking >>>>about the size of your book & learning algs. >>>>> >>>>>Vas >>>> >>>>I'm not sure what you mean. The source file "book.c" contains all the chess >>>>book stuff, accessing it, building it, etc. The source file "learn.c" >contains >>>all the learning stuff. The text GUI is really main.c + >option.c... >>> >>> >>>If you did arrange for a human to tune your book, could he do it from inside >>>crafty while having some sort of semi-useful tools (ie looking at the >position, >>getting Crafty's eval, etc)? You get this in the Chessbas GUI, and >also to some >>extent in Arena and Chess Assistant. >> >>No, because Crafty was designed for very minimal human intervention in the >>opening book move selection. As that was a goal from the beginning. I later >>added the small books.bin/bookc.bin that I had in Cray Blitz, because several >>users wanted to be able to exert some control on what openings were played... >> >> > > > >How long would you suggest to leave a particular crafty version "alone"? In >other words, when should the learning files be cleared? If the version is not >upgraded, and the hardware is not upgraded, and the machine is on a server >playing automatically, do the learning files require any >maintenance/re-setting? > That is a good question. I clear them for every version. I am trying an experiment on ICC now where I have _no_ start books at all. Just my big book.bin. But I have the newly modified book learning code in aggressive mode so that it will learn when it wins or loses or draws, as well as learning when it leaves the book in a game. I want to see how this aggressive mode works in marking usable pathways thru the big book jungle. I remove position.* every couple of weeks, as well, since that seems to be very "opponent/opening" specific... > > > > >> >> >>> >>>>I rarely talk about "sizes" other than when I mentioned the 1200 lines of >code >>>necessary to implement all the learning stuff I currently do... >>>> >>>> >>>> >>>> >>>> >>>>> >>>>>>> >>>>>>>trust me, that will _not_ work. All of us using automatically-generated >books >>>>>>have tried that, and found it _severely_ wanting. What happens >when move X is >>>>>>played in thousands of games, until someone busts the line >with new analysis. >>>>>>You lose that game every time you play it. That's a >killer. >>>>> >>>>>>For Crafty, playing in basement tournaments and around the internet, >hundreds of >>>>>games a day - yes. For me, playing maybe a dozen tournament >games a day, it's >>>>>an extra loss or two a week. >>>>>> >>>>>>> >>>>>>>Learning solves it cleanly. The better your initial book, the better >your >>>>>>program will perform, but learning _still_ cleans up all the things >that the >>>>>>book screws up for one reason or another. >>>>>> >>>>>>I don't disagree. My book is popularity based but it's structured so I >can >>>>>alter weights - by learning, hand tuning or whatever. It's just that >I have >>>>>other things I feel need work worse. One day I'll get around to >worrying about >>>>>my bad book lines. >>>>>> >>>>>>Dan H.
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.