Open Opening Book Standard (OOBS)

[phhnguyen]

...Speed: I don’t have any speed benchmark of OOBS at the moment but they should be significantly slower than Polyglot ones...

An engine needs to query the book before starting each search. Speed becomes extremely important if you're testing ideas by playing games-in-ten-seconds. What would be the overhead of 60 queries?

Steve

On my old computer of 5-year-old, a query may take about 100-200ms with a large book (the sample book of this project). We could speed up, say 10 times if we use smaller books and/or add an index for the column FEN.

From my experience, that speed is good enough for almost all normal uses/tests.

For bullet games of about 10s/games, it depends on your opinion (accept or not that latency) and on chess GUIs. For example, Banksia GUI doesn't count the time for finding opening moves (thus it could play with online books, even it has a timeout threshold). It is especially true for tournaments: it creates game empty records with all opening moves/starting positions before playing.

[hgm]

The time would still add to the duration of the game, though. So your games would last 24 sec instead of 20 sec, and you would do fewer games per hour.

[Steve Maughan]

...On my old computer of 5-year-old, a query may take about 100-200ms with a large book (the sample book of this project).

IMHO that's too slow.

Steve

[Ferdy]

I have downloaded the book-mb3.54.obs.db3 and try to find the stats on this position.


[fen]rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1[/fen]


No record is returned.

Your FEN string should be rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
(missing enpassant)

Right I missed that e.p square. I use python-chess to generate the FEN and EPD and it already removed unnecessary e.p. square.

[mar]

Your FEN string should be rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
(missing enpassant)

Right I missed that e.p square. I use python-chess to generate the FEN and EPD and it already removed unnecessary e.p. square.

this is exactly why I asked about FEN canonicalization, obviously this task is left to the user.
actually, since you can't ep capture on e3, both FENs are actually legit and describe the same position.

in fact, engines get rid of invalid ep squares internally, so I actually prefer the "stripped" FEN - and by the way, polyglot also doesn't hash invalid ep

[phhnguyen]

I used a trick for that, though: it uses the 'learning fileds' of the Polyglot book to store raw WDL statistics that

Good try for keeping more information!

However, the learning field is only 32 bits, thus WDL numbers may have 10 bits each with a max value of about 1024, far below enough for large books, is it?

[phhnguyen]

...On my old computer of 5-year-old, a query may take about 100-200ms with a large book (the sample book of this project).

IMHO that's too slow.

Steve

I have just done a new test with my sample book (in the sample folder). As I have mentioned, the speed of extracting data was about 10-20 FENs per second (100-200ms per FEN). Now, I have created an index for the column FEN. It is purely SQL, using the statement:

Code: Select all

CREATE INDEX BookFEN ON Book (FEN)

The process of creating indexes is so fast, took me only 3 seconds.

The new test took only 18ms to complete 300 FENs or a speed of 16666 FENs per second.

Fast and good enough for any bullet games/purposes, isn’t it?

BTW, the strong point of OOBS is that it keeps all information in clear, meaningful forms. For advanced users, they could develop the book such as testing, trying variants, modifying values, merging, adding, expanding… the tasks they are hard or almost can't do with Polyglot. Later they could convert easily into Polyglot ones whenever they want but not visa versa.

[phhnguyen]

Your FEN string should be rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
(missing enpassant)

Right I missed that e.p square. I use python-chess to generate the FEN and EPD and it already removed unnecessary e.p. square.

this is exactly why I asked about FEN canonicalization, obviously this task is left to the user.
actually, since you can't ep capture on e3, both FENs are actually legit and describe the same position.

in fact, engines get rid of invalid ep squares internally, so I actually prefer the "stripped" FEN - and by the way, polyglot also doesn't hash invalid ep

I see by doing that we may gain little benefit (save some tiny amount of space) but we need to add more code and may have trouble with compatibility with other software.

[Steve Maughan]

...The new test took only 18ms to complete 300 FENs or a speed of 16666 FENs per second...

That's fast enough!

Steve

[hgm]

I used a trick for that, though: it uses the 'learning fileds' of the Polyglot book to store raw WDL statistics that

Good try for keeping more information!

However, the learning field is only 32 bits, thus WDL numbers may have 10 bits each with a max value of about 1024, far below enough for large books, is it?

The weights field already contains 2*wins + draws. So the learn fields only have to store the wins (or draws) and the losses.

So each have 16 bits and that seemed enough to not worry about overflow. A way to treat that is to make use of the fact that the weight is typically 3 times larger than the others. So you could only use 14 bits for W and L, and use the 4 remaining bits as a common exponent for treating the data as floating point. That multiplies the range by 2^15 = 32K.