Author: Robert Hyatt
Date: 12:24:35 06/02/98
Go up one level in this thread
On June 02, 1998 at 14:02:13, Roberto Waldteufel wrote: > >On June 02, 1998 at 08:09:12, Robert Hyatt wrote: > >>On June 02, 1998 at 03:21:38, Stuart Cracraft wrote: >> >>>So what I hear is that having position-based "learning" >>>is something like saving the position after a really bad >>>drop in the iteration of a score in the hash table with >>>a special flag. When the game ends, write out all >>>such entries to a disk based file. When restarting >>>the program, read in the disk based file into the >>>hash table and set the flags. When searching, if >>>the position turns out to be one of those positions, >>>then what? >>> >>>I could dig out my Slate (one or the other forgot which) >>>article in ICCA on the "Mouse" program -- is that essentially >>>what this Position-Based "Learning" is that some >>>programmers are using to create artificial wins against >>>other programs? If so, any big refinements to Slate's method >>>for the current crop? If no, what are the major differences >>>between Slate's method and the current vogue? >>> >>>Thanks, >>>--Stuart >> >> >>all you have to do is write the hash entry out when the score drops, and >>reload it before each move from then on, or (as I do) load them once and >>flag them as "permanent". That is all you do. Hashing will take care >>of >>the rest, and you will see the "trouble" several plies earlier the next >>time you play the same game, and you will play a different move to avoid >>reaching the position where the score is going to drop. > > >Can you clarify this for me - do you keep a permenant file of "bad" >positions that you add to with each game played? if so, is there not a >risk that eventually the file of permenant positions may become so large >as to clog up the hash table with positions that may be irrelavent to >the current game? Or is the nimber of stored permenant positions too >small to present any problem of this kind. Also, if you make a >modification or improvement to the program, then do you have to start >from scratch with the permenant positions, or do you just assume that >the improved version of the program will misjudge the same positions >that it misjudged before, and so leave the permenant position file >unchanged? > my position file has 65536 entries, and is "wrap-around" once it fills up in a FIFO ring buffer. However, I *never* let it fill up, because I delete it regularly. more later... >I currently use the idea of "infinite depth" in the hash table: with >each entry in the table, the depth has to be stored. If my search finds >a forced mate from a position in the search tree, then this evaluation >is no longer depth-dependant, so I record the position as having the >maximum possible depth, so that it will not get replaced during that >game, but when the game is over I discard the hash table instead of >saving the permenant positions (in my case, good rather than bad >positions). Perhaps I should not discard these positions at the end of >the game? infinite depth for mate/draw is ok. but not for these "learned positions" because you will be unable to "search beyond" them which will cause mistakes... And I wouldn't make them permanent either as you search past such positions they will still stick around. Each entry in my table gets a "ID" field set. this is 3 bits, and is "wrap-incremented" to go in the sequence 1-2-3-4-5-6-7-1-2-3-4-5-6-7-... 0 is excluded as that meand "permanent" (which is a position loaded from the learned file only). I *always* overwrite entries in the table that have a stored ID that is different from the current ID... which lets me overwrite old entries with new ones... > >Roberto this sort of learning was added so that if someone finds a quick exit out of book, book learning won't work. This at least gives it a chance to not play into the same lost game over and over. I only learn positions from the first 10 non-book moves before turning it off...
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.