Winboard Forum

Hi,

A couple of quick questions..

1.
For the new version of Lime (UCI), I have implemented pondering. It works fine in the Fritz GUI, and under Arena, but when using Polyglot + winboard, I get a terrible delay when the pondering is cancelled, either with a miss or a hit, and the normal search restarted. This causes the engine to use three seconds more each move than intended. I tried the 'SyncStop' workaround from the readme, but no difference. Is this normal, or is it just Lime?

2.
To make my opening books, I wrote a couple of functions - one to strip a pgn file into the following format...

e2e4e7e5g1f3b8c6f1b5
d2d4d7d5g1f3c7c5

etc...

The second function then converts all of these positions into hash keys, and writes the move that follows. The keys and move are written to a text file.

When playing, Lime needs to comare its hash key, 64 bit, with the list of keys in the text file.

E.g

In text file..

471941866 g1f3

Then, I assign a pointer to the number part of the line '471941866'
and compare the two using the following:

Code: Select all

     unsigned __int64 tkey
      tkey = atol(temp);
      if (tkey == game->hashkey)
      {//--found a match, store g1f3 as a possible book move--//}


My question is with the atol() function - is it ok to use this function for converting the text numbers into 'longs'? The __int64 is 'long long'.

The proper way to do this is using binary files, I imagine, but I just can't understand how they work (yet!). More reading of the textbooks required.

Thank you in advance for your replies,

Richard

Hi Richard,

Richard Allbert wrote:My question is with the atol() function - is it ok to use this function for converting the text numbers into 'longs'?

try atoi64() for MSVC++ and atoll() for GCC (if required). I really don't know if they are kind of standard and available on your platform, but just give it a try ...

Sven

Thanks! Compiled and works. I didn't realise atoll() existed.

Thanks again,

Richard

PS Really must do this with binary files - the look up costs 0.3s with text files!

Richard Allbert wrote:e2e4e7e5g1f3b8c6f1b5
d2d4d7d5g1f3c7c5

I'd recommend to use some separators, maybe spaces:
e2e4 e7e5 g1f3 b8c6

For two reasons:
1. The file becomes more human-readable.
2. Parsing code becomes easier - it has not to track promotions now. And notation for promotions requires 5 characters, don't forget!

Saving 20% of file size is nothing compared to saving your coding and debug time

Vladimir Medvedev wrote:I'd recommend to use some separators, maybe spaces:
e2e4 e7e5 g1f3 b8c6

2. Parsing code becomes easier - it has not to track promotions now. And notation for promotions requires 5 characters, don't forget!

Thanks for the reply.

I'm only interested in the opening, so I only write the first 20 moves (for both white and black), and so I didn't think promotions would become an issue. In the odd case that a promotion does occur, the function detects this as an 'illegal move' and the line is discarded.

But it is all irrelevant - last night on the chesswar broadcast, Pradu 'walked' me through binary file writing and reading, so the openings book is now a much faster binary file!

Richard

Richard Allbert wrote:I'm only interested in the opening, so I only write the first 20 moves (for both white and black), and so I didn't think promotions would become an issue. In the odd case that a promotion does occur, the function detects this as an 'illegal move' and the line is discarded.

I am not an expert in opening theory, but as far as I know there are some opening lines shorter than 20 moves which require promotions as correct play. Unfortunately, I can't post an example now, I need to lookup in DB.

Binary book is fine, it can be very fast (binary search is the simplest way to implement). But plain text opening files can be useful as well. You can use them for opening repertoire control, experiments with uncommon moves, edit them easily etc. In GreKo I have possibility to use both solutions, binary and plain-text opening book.

Vladimir Medvedev wrote:

Richard Allbert wrote:I'm only interested in the opening, so I only write the first 20 moves (for both white and black), and so I didn't think promotions would become an issue. In the odd case that a promotion does occur, the function detects this as an 'illegal move' and the line is discarded.

I am not an expert in opening theory, but as far as I know there are some opening lines shorter than 20 moves which require promotions as correct play. Unfortunately, I can't post an example now, I need to lookup in DB.

Binary book is fine, it can be very fast (binary search is the simplest way to implement). But plain text opening files can be useful as well. You can use them for opening repertoire control, experiments with uncommon moves, edit them easily etc. In GreKo I have possibility to use both solutions, binary and plain-text opening book.

Promo in 20 moves!

I stand corrected.

Thanks!

Richard