TalkChess.com

Isn't it enough to just use probe_wdl() in the search (excluding QS) ?
Is there a non trivial gain (elo-wise) in the root_probe() stuff ?

I'm really considering implementing syzygy TB in DiscoCheck. It has all the nice properties that I like and no other TB has:
* 5-men WDL holds in 378 MB only!
* probing code is: open source, concise, portable, non intrusive, and fast!

lucasart wrote: I'm really considering implementing syzygy TB in DiscoCheck. It has all the nice properties that I like and no other TB has:
* 5-men WDL holds in 378 MB only!
* probing code is: open source, concise, portable, non intrusive, and fast!

Meh...scorpio bitbases 'has all the nice properties that you like'.
* 5-men WDL holds in 200 MB only!
* probing code is: open source, concise, portable, non intrusive, and fast!
Something else I don't get is, this 'philosophy of not using bitbases' which is utter BS if you ask me. It is more like I don't want to be associated with someone elses code if it don't get much elo for me (though chess community wants your engine to have it!). I don't envy if someone's TBs become popular but you don't have to go and unfairly criticize other TBs that has been serving good in the past.
Peace!

lucasart wrote:Isn't it enough to just use probe_wdl() in the search (excluding QS) ?

You have to do something special once the game has reached a tablebase position. Otherwise all won positions look the same and the search will often not make progress.

So one option is to simply stop probing once the root position has 6 (or 5) pieces or less.

Another option is to use root_probe(), but for this the DTZ tables need to be present. This function filters out moves that would lose half a point or more (taking into account the 50-move rule).

There is now a fallback for when DTZ tables are not present: root_probe_wdl(). This also filters out bad moves, but it cannot guarantee progress. If this fallback is used, I let the search do probes for positions that have one piece less than what is currently on the board.

Other schemes are of course possible.
- it might be a good idea to selectively use probe_wdl() in the qsearch, e.g. for material configurations that are known to be difficult to get right in the evaluation. And it might be a good idea not to probe near the leaves in the regular search for material configurations that are known to be easy to get right in the evaluation.
- there is a choice for what to do with won/lost positions that are drawn under the 50-move rule (probe_wdl() returns values -2, -1, 0, 1, 2). You could choose to ignore the 50-move rule and just regard those as won/lost. Or you can use the fact that the engine knows how to keep a draw and is rather likely to win within 50 moves those winning positions that are drawn under the 50-move rule. (If you don't want to use DTZ tables, you probably want to ignore the 50-move rule).

Is there a non trivial gain (elo-wise) in the root_probe() stuff ?

If you don't take any special measures when the root position is in the tablebases, this will definitely affect Elo because the engine will draw positions that are won. The Elo gained by having the DTZ tables around is likely to be very small, though. (I have considered only having DTZ tables for tablebases with non-trivial wins, i.e. where probe_wdl() might not make sufficient progress or where the 50-move rule may come into play, but in the end I did not see much reason for that. The 6-piece DTZ tables are only a bit larger than the WDL tables (for 7-piece they might even be smaller) and they can be stored on almost arbitrarily slow drives without loss of performance.)

@Daniel

Unfortunately Scorpio bitbases do not come with a license. This has for example prevented their inclusion in Debian. I know you say they are open source, but as long this is not written in a license it carries no weight.

lucasart wrote:Is there a non trivial gain (elo-wise) in the root_probe() stuff ?

No one to my knowledge has ever shown a non-trivial gain from any tablebases with an engine with decent endgame evaluation. We need a good implementation of tablebases to do proper testing, but the multitude of different Stockfish versions is inhibiting this. It can be done, of course, but it takes some will power.

Michel wrote:@Daniel

Unfortunately Scorpio bitbases do not come with a license. This has for example prevented their inclusion in Debian. I know you say they are open source, but as long this is not written in a license it carries no weight.

Oh I didn't know that but I vaguely recall someone in the past have asked me about it by email, and I said yes you can use it. They are free to use for any purpose, even for distributing on a CD commercially, which I thought would be better conveyed without any kind of licence attached. I guess I should have attached some kind of licence to be formal. Maybe I did have some BSD style licence, but somehow it got lost when the egbbs are hosted in different places. I just wanted to give total freedom and not send me email when people want to use them. Well if a licence is preferred, i guess I can add it but don't know how to add already distributed egbbs. I can update the github repo with a the least restrictive licence possible.
Hope I am not hijacking this thread.

Dirt wrote:

lucasart wrote:Is there a non trivial gain (elo-wise) in the root_probe() stuff ?

No one to my knowledge has ever shown a non-trivial gain from any tablebases with an engine with decent endgame evaluation. We need a good implementation of tablebases to do proper testing, but the multitude of different Stockfish versions is inhibiting this. It can be done, of course, but it takes some will power.

It is really not the fault of TBs though. 99% of the games end in middle game or the game is already won when they reach it. So they do 'not help' much basically because they are not probed (used) much, which kind of defeats the purpose. OTOH they are awesome for endgame analysis, which is why many chess players want an engine to support them. So if society wants your engine to support TBs, you simple should yield and not be philosophical about it

I have added a BSD license and removed some clauses that I thought were too restrictive and updated the git repo.
I don't know how restrictive this license is but I would be glad to modify it as required because I don't want to drive anyone away.
----------------
Copyright (c) 2005 - 2013 Daniel Shawul Abdi
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-----------------------

Daniel Shawul wrote:

lucasart wrote: I'm really considering implementing syzygy TB in DiscoCheck. It has all the nice properties that I like and no other TB has:
* 5-men WDL holds in 378 MB only!
* probing code is: open source, concise, portable, non intrusive, and fast!

Meh...scorpio bitbases 'has all the nice properties that you like'.
* 5-men WDL holds in 200 MB only!
* probing code is: open source, concise, portable, non intrusive, and fast!
Something else I don't get is, this 'philosophy of not using bitbases' which is utter BS if you ask me. It is more like I don't want to be associated with someone elses code if it don't get much elo for me (though chess community wants your engine to have it!). I don't envy if someone's TBs become popular but you don't have to go and unfairly criticize other TBs that has been serving good in the past.
Peace!

Sorry, I didn't realize that Scorpio's EGBB were open source. I thought the probing code came in binary form only, as a Windows DLL. 200 MB is very compact indeed: is that bitbase information comparable to a WDL table (result of the game, accounting for 50-move rule) ?

lucasart wrote:Sorry, I didn't realize that Scorpio's EGBB were open source. I thought the probing code came in binary form only, as a Windows DLL. 200 MB is very compact indeed: is that bitbase information comparable to a WDL table (result of the game, accounting for 50-move rule) ?

As far as I know, those 200 MB represent the "smaller half" of each table, which is about a third of both sides. The disadvantage is that probing a position for the wrong side to move translates into 1 ply of probes for the right side.

My DTZ tables also store the "smaller half" of each table, which is not a problem because the DTZ tables are only probed at the root.