I have forgotten what the exact problem is but it has to do with a 32 bit indexI can't see the problem with book size at first read through book_make.cpp
that overflows somewhere.
Moderators: hgm, Rebel, chrisw
I have forgotten what the exact problem is but it has to do with a 32 bit indexI can't see the problem with book size at first read through book_make.cpp
I have DDD for debugging with Cygwin. I suppose I would need to attempt to build a large book first ... how many games are needed before Polyglot will crash?Michel wrote:I have forgotten what the exact problem is but it has to do with a 32 bit indexI can't see the problem with book size at first read through book_make.cpp
that overflows somewhere.
Code: Select all
static void book_clear() {
int index;
Book->alloc = 1;
Book->mask = (Book->alloc * 2) - 1;
Book->entry = (entry_t *) my_malloc(Book->alloc*sizeof(entry_t));
Book->size = 0;
Book->hash = (sint32 *) my_malloc((Book->alloc*2)*sizeof(sint32));
for (index = 0; index < Book->alloc*2; index++) {
Book->hash[index] = NIL;
}
}
Dave_N wrote:I had a look at the Polyglot format and found that it doesn't give a win/loss/draw percentage and instead gives a weight, so I decided to have another look at creating books. My first thought was to modify the polyglot book creation to store white wins in the "weight" variable and draws or black wins in the "learn" variable. I decided to ignore polyglot and look at making my own format from my own pgn tree code...
At the moment I have written a code that will merge games into 1 game with variations, however I cannot detect transpositions. So for example if 2 games take a Ruy Lopez line with the Marshall attack and one line has black playing b5 after a6 and the other has Nf6 first (as in the mainline) then I don't have the games rejoining after the positions become equal, and instead the merged game is a variation of the first.
Obviously I could not compare FEN in a realistic time to detect the transposition so I would need some kind of hash table (probably) unless I create a FEN tree ... I am sure this has been tried before but is it practical?
I am not sure if Cygwin will convert size_t to a 64 bit unsigned int automatically, perhaps some configuring is needed ....Michel wrote:I think the problem was with the mallocs in book clear.
However it might have been with a 32 bit system. The argument to
malloc is size_t. I assume this is 64 bit on a 64 bit system. So then
there should be no problem.
Code: Select all
static void book_clear() { int index; Book->alloc = 1; Book->mask = (Book->alloc * 2) - 1; Book->entry = (entry_t *) my_malloc(Book->alloc*sizeof(entry_t)); Book->size = 0; Book->hash = (sint32 *) my_malloc((Book->alloc*2)*sizeof(sint32)); for (index = 0; index < Book->alloc*2; index++) { Book->hash[index] = NIL; } }
This is one of the things that is still on my (long) to-do list: put a good book-building algorithm into Polyglot. I think I designed a good algorithm for this (indeed using minimax-like back-propagation of the move stats). Pure minimax would only be valid if you prepare a book for 'best-move-only' play. If you want to switch on variety, you will also have to play non-best moves with a finite probability. E.g. you could reduce the probability of the move to be played by a factor 0.9 for every percent it scores less. But that means that the score of a position that has a move that scores 53% and two moves that score 50% is not is not 53% (as it would be in minimax) but (1*53% + 0.729*50% + 0.729*50%)/(1+0.729+0.729). This is worse then the stats of the best move, because the others drag it down, but better than the raw stats of the position, because the inferior moves have lower weight.yoshiharu wrote:What I am really after, though, is a sort of minimax on the opening book, because I am sick and tired of seeing my engine entering some continuation whose stats look great before a critical move, but after that the opponent has a move that *inverts* the stats refuting the whole plan...
Only problem is that I don't know what evaluation to use in this restricted minimax, using the usual stats seems too naive...