Author: Robert Hyatt
Date: 19:34:20 12/12/03
Go up one level in this thread
On December 12, 2003 at 17:13:06, Omid David Tabibi wrote: >On December 12, 2003 at 17:00:20, Robert Hyatt wrote: > >>On December 12, 2003 at 15:10:04, Omid David Tabibi wrote: >> >>>On December 12, 2003 at 13:54:27, Robert Hyatt wrote: >>> >>>>On December 12, 2003 at 12:42:17, Omid David Tabibi wrote: >>>> >>>>>On December 12, 2003 at 11:24:26, Georg v. Zimmermann wrote: >>>>> >>>>>>Exactly, and thats why you should write your own book routine, instead of using >>>>>>part of a commercial package. >>>>> >>>>>I don't see any problems with this. By using the opening book feature of Fritz >>>>>or Shredder, you are merely avoiding a waste of time on something already >>>>>implemented. The big issue is hand tuning the created book, which makes the >>>>>difference between shredder.bok and falcon.bok :) >>>> >>>>You are overlooking the difficulty of choosing a book line also. There are >>>>lots of things to consider. How often it was played, how did the side on >>>>move do in the resulting games, how recent was the opening played or is it an >>>>old move that might have a refutation, etc. >>>> >>>>I've written book code. It takes a lot of time. Not to mention the >>>>learning facilities that you get for free with the Fritz GUI. Which is >>>>yet another important piece of code that you get to avoid writing. >>>> >>> >>>You can similarly argue that everyone should write his own endgame tablebases. >>>As it also takes a lot of time, and is much harder than opening book. >>> >>> >> >>No it isn't. And I have explained this reasoning before. EGTB probes >>themselves are deterministic. Everybody can use the same tables, everybody >>gets the same egtb.cpp probe code, everybody gets the identical same result >>when they call the probe code with the same position. So there is no >>"decision-making" inside there. How you _use_ those results can vary, but >>then that is outside the probes. > >No, I'm not talking about Nalimov access codes, but the actual tablebases. One >can argue that everyone should write his own tablebases, instead of using >Nalimov's... That is a far more complicated task than creating an opening book. > There is _still_ a difference. If you produce a table for KRPKR, you will have _no_ new information not in the Nalimov KRPKR table, nor will the Nalimov KRPKR table have any information yours doesn't have. IE logical equivalency. Books are _not_ logically equivalent. Book selection code is not either. Nor is book learning code. > > >> >>A book is different. I've written lots of book code variations over the last >>few years, each was different, each was a lot of work, and each made real >>decisions about the game. Learning is an example of things done by commercial >>GUIS, and that should _not_ be shared code. >> >>> >>>> >>>>> >>>>> >>>>>> >>>>>>Georg >>>>>> >>>>>> >>>>>>> >>>>>>>I totally disagree with you about this. IMO opening book is one of the most >>>>>>>important parts of the program. Look at the games in Graz, many games were >>>>>>>already decided after the opening phase... >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>Uri
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.