Author: Robert Hyatt
Date: 18:55:27 06/13/98
Go up one level in this thread
On June 13, 1998 at 16:32:41, Stuart Cracraft wrote:
>Hi,
>
>My program has a strange problem. Perhaps sharing this
>will make a lightbulb light up somewhere... I'm fresh out of bulbs.
>
>I added position-based learning awhile back. The goal
>is to note those positions that are "significantly worse"
>(about 3/4 of a pawn) at the final iteration than the best
>of the previous iterations, mark them PERMANENT in
>the hash table and write them out to disk.
>
>When a new game starts, hash table is zeroed, learned positions
>are read back in and marked PERMANENT.
>
>Fine, it runs well with test positions from Slate's article in
>the ICCA Journal. After three "shocks" it's written out
>3x28 bytes of information and learns plays Slate's examples
>well enough to play all the exact moves as Slate's Mouse program,
>avoiding the bad variations it would have naturally gone into
>and even avoiding a bad move in a position with quite afew
>different pieces and locations than in the learned position
>illustrating the sharing of learning experience in some class
>of overlapping families of related positions in the search-tree.
>
>So I now let it run on ICS. After a time I come back and
>it's written out an ODD number of bytes!!! Impossible.
>It is doing only write()'s of sizeof the hash entry which is
>28 bytes. I use open and read to read it, nothing buffered.
>The effect is when a "bad record" is written, the learn
>file restore stops and the program continues but with
>far fewer learnt positions than are actually in the
>buggy learn file.
>
>The point is: how could it output an odd number of bytes
>to the learn file on disk when the only thing it is written
>is an even number of bytes each time, e.g.
>
>When the last iteration is significantly worse than the best
>previous iteration:
>
> /* set buf to hash table entry plus some additional info, omitted */
> fd = open(filename,O_WRONLY);
> write(fd,buf,28);
> close(fd);
>
should you not OR in O_APPEND with the O_WRONLY flag, so that you only
add to the end?
>and when reading them in at game's start
>
> fd = open(filename,O_RDONLY);
> read(fd,buf,28);
> /* restore buf to hash table here, omitted */
> close(fd);
>
>the fd is not used for anything else except the above
>and is closed after each use
>
>I've tried seemingly everything:
>
> - disable all interrupts during write operation
> - stop using buffered fopen/fwrite/fflush/fclose in favor of
> unbuffered
>
>My learn file position entry is:
>
>typedef struct
>{
> short side;
> int move;
> HashType hashkey;
> int score;
> short flag;
> short depth;
> long nodes;
>} LearnHashSlot;
>
>where HashType is long long. Actually I could shorten
>this and avoid storing *move* and *nodes* since they
>aren't used but I don't see how that will help.
>
>How can write(...) possibly write out an odd number of
>bytes with an even number of bytes specified in its call?
>
>By the way, the learn file positions are read at game startup
>and written out after each appropriate search completes
>by simply appending the latest position learned to the end
>of the file, e.g.
>
> fd = open(...,O_WRONLY)
> lseek(fd,0,SEEK_END);
> write(fd,buf,sizeof(LearnHashSlot));
> close(fd);
>
>Help Obi-Wan-Kenobi!
>
>--Stuart
the above should work. However, you said one thing that sounds wrong,
but you probably wrote it in an unclear way. You said you write out a
position to the learn database when the score drops between the last
iteration and the final iteration. I assume you mean from one *search*
to another search? That's the way I do it.
Also, I'd stop opening and closing the learn file multiple times. Open
it, seek to the end, write a position, seek to the beginning and store
them
in the real hash table when you want...
This page took 0.01 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.