Author: Tony Werten
Date: 08:57:05 07/14/00
Go up one level in this thread
On July 14, 2000 at 09:24:48, Robert Hyatt wrote: >On July 14, 2000 at 08:55:46, Tony Werten wrote: > >>On July 13, 2000 at 09:11:18, Robert Hyatt wrote: >> >>>On July 12, 2000 at 22:57:29, Dann Corbit wrote: >>> >>>>On July 12, 2000 at 21:57:07, Robert Hyatt wrote: >>>>[snip] >>>>>I don't see how to do that. The CAP data is composed of _very_ deep searches. >>>>>While building a book from millions of games, there is _no way_ to do searching >>>>>at each point in the tree. Even at 1 second per search, 2 million games has >>>>>something like 160 million moves. Doing 160M 1 second searches will take a >>>>>_long_ time. And 1 second is _not_ reliable for choosing book moves. >>>> >>>>In my 2.4 million games, there are about 150 million positions that have been >>>>played. Let's prune back to only consider the 60 million most important. >>>> >>>>We will build a tree with branches using a variable sized array with a technique >>>>similar to that of a skiplist. >>>> >>>>Only one character needs to be stored for each move forward from the root (the >>>>normal chess starting position). We simply sort all possible moves generated >>>>and give the number of a given move as an unsigned char from 0 to 255. We will >>>>also store a two byte ce, and ebm [extrapolated bm] and bm will require an >>>>additional two bytes. >>> >>>before you go on, we are on two different pages. When I said "search" I meant >>>a tree search. The suggestion was to do searches in positions where there is no >>>CAP score, when minimaxing the book. I was pointing out that the typical book >>>is so large, that even 1 second searches make this undoable. Not searching thru >>>the book to minimax it. But searching the millions of positions where there is >>>no CAP score. >>> >> >>I think we are talking about different things here to. I understood CAP also >>evaluated positions in search and not only at leaves. So you don't have to >>search anything anymore, you just have to notice that the PV is not leading to a >>CAP position. Then you use the PV score. ( wich is not as deeply searched as you >>would like but it's always better than what you can search yourself in >>tournement timecontrol ) >> >>Tony > >How do you do this while "minimaxing" the book scores as the book is >created? There will be "zillions" of non-CAP positions you will reach. DO >you search _each_ one to get a score to minimax back to the root? You I now see the difference. I was talking about converting the capdata into an openingbook, you are talking about creating the book from something different and then look up the scores in he capdata if present. That way you have too much positions not present so my idea doesn't work. >certainly >can't minimax the book moves at game time, it would take forever... > >Cray Blitz's old book minimax code took hours to run on a Cray. The first >time I tried to minimax a book with Crafty, it took > 24 hours with no >searching, just propagating book scores back from leaf positions to the >root... ???? I hope this was very long ago, and not in the present Crafty, else you have to be doing something wrong. Tony > > > > >>> >>> >>> >>>> >>>>A few hundred megabytes will store the entire tree in memory. Certainly less >>>>than a gigabyte. A recursive tree walker could propagate window information >>>>back up to higher levels. Now, while this won't be the same as a mini-max, we >>>>can use the data to narrow the window or tag a choice as definitely wrong. For >>>>those that are clearly wrong, we can reevaluate using some other technique. >>>> >>>>It may also be possible to evaluate the tree using a SQL database. Given a 3090 >>>>with a Gig of ram and a few hundred gigs of disk, it might be runnable over a >>>>weekend.
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.