EGTB probe in search

[zenpawn]

The following seems to work well for me.

Thank you, Pedro. I see you have references to WDL. Does that mean you are using Syzygy in addition to Gaviota?

[Edit] Ah, actually, you must be using the thread safe API mentioned here https://chessprogramming.wikispaces.com ... Tablebases to get cached WDL info.

[Ras]

Perhaps at the level of our engines, the extra knowledge causes it to exclude branches that would otherwise have given good practical chances.

I guess the reason is that most of the probes happen in branches that would have been cut off anyway, simply because 99.9% of the time is spent to find out what positions to avoid.

Imagine you have a 5-man TB, and the board position is K+Q vs. K+R+B+P. If the side with the queen throws it away, that will be a TB position - but you don't need the costly lookup to know that it's bad to give up the queen.

TB makes sense if the outcome isn't already (most probably) determined by the material, like in K+R+P vs. K+R or K+P vs. K. Of course, K+Q vs. K can also be stalemate, or the defending side may take the queen, but that's so rare that I would defer that to the search.

Another thing where TB is useful is K+Q vs. K+R because winning that is so difficult that a TB pays off. But unless that's a position with capture or stalemate possibility (which search would detect), it's sufficient to mark it as won and do the lookup only once the position is actually reached.

[syzygy]

Sadly, I've now tried quite a few of the options described in this thread, including remaining depth > 5, and all of them are giving worse results in matches vs Isa. Perhaps at the level of our engines, the extra knowledge causes it to exclude branches that would otherwise have given good practical chances.

That seems unlikely.

Does probing lower nps even if you limit probing by a lot? Then something seems to be wrong or suboptimally implemented.

Does your engine manage to convert winning TB positions to mate? There are many things that can go wrong in an implementation of probing at the root.

Does your engine correctly deal with TB probes within the search tree? In particular, does each TB hit lead to a cutoff and is the correct value propagated to the parent node? There are again many things that can go wrong in an implementation.

[syzygy]

Imagine you have a 5-man TB, and the board position is K+Q vs. K+R+B+P. If the side with the queen throws it away, that will be a TB position - but you don't need the costly lookup to know that it's bad to give up the queen.

If remaining depth is sufficiently high, the cost of the probe will still be worth it.

But it would indeed make sense to let the remaining depth threshold depend on the material that is on the board.

So first check whether the position is in the TBs (simply by counting pieces left on the board).

Then determine the appropriate remaining depth probe threshold as a function of the material signature of the position. KRPvKR will give a lower threshold than KQPvKN.

[zenpawn]

Sadly, I've now tried quite a few of the options described in this thread, including remaining depth > 5, and all of them are giving worse results in matches vs Isa. Perhaps at the level of our engines, the extra knowledge causes it to exclude branches that would otherwise have given good practical chances.

That seems unlikely.

Does probing lower nps even if you limit probing by a lot? Then something seems to be wrong or suboptimally implemented.

Does your engine manage to convert winning TB positions to mate? There are many things that can go wrong in an implementation.

I did find one bug (a flipped sign in some cases), and it seems to be doing better in the match currently underway. Except for the bug I just fixed, which I found by watching it suddenly throw away a draw, it does convert won TB positions to mate.

[Ras]

If remaining depth is sufficiently high, the cost of the probe will still be worth it.

There shouldn't even be much remaining depth because forward pruning should remove the whole branch quickly. If forward pruning cannot be applied because the eval is close to what's actually on the board, then it doesn't matter because the game is decided anyway.

The only thing where you have be cautious is when the defending side might be heading for KNNK. Apart from that, being up at least the equivalent of a rook is already won and doesn't need a lookup during search. Apart from some studies with opposite bishops and an amazing number of pawns for the superior side, which will never appear in real games.

Of course, e.g. some KQKR positions are draw because of perpetual check or stalemate conditions, but that's so rare that I doubt looking up buys more ELO than the slowdown costs, on average.

So my stance is that during search, the lookup should be limited to positions that are on the verge between draw or not draw. Anything else can be done with static eval.

[syzygy]

If remaining depth is sufficiently high, the cost of the probe will still be worth it.

There shouldn't even be much remaining depth because forward pruning should remove the whole branch quickly. If forward pruning cannot be applied because the eval is close to what's actually on the board, then it doesn't matter because the game is decided anyway.

By remaining depth I mean the value of the "depth" parameter in the recursive search(alpha,beta,depth) call. The subtree searched by that call will not be pruned away to nothing just because the position is very bad or very good compared to alpha and beta. Unless "depth" is low and you do a lot of reductions.

The only thing where you have be cautious is when the defending side might be heading for KNNK. Apart from that, being up at least the equivalent of a rook is already won and doesn't need a lookup during search.

As I said, in such cases it is not about the extra precision (the eval will get it right anyway) but about the reduction in the size of the tree searched. Nodes not spent on subtrees cut away by TB probes can be spent on other parts of the tree. Of course it is critical here that the cost of the probe is outweighed by the size of the tree cut.

So you are overlooking the biggest benefit of TB probing: reduction of the size of the search tree.

[Ras]

So you are overlooking the biggest benefit of TB probing: reduction of the size of the search tree.

Hm yes, I've been somewhat contradicting myself in argueing that the trees should be cut off by pruning AND that the search should find tactical issues like stalemate or captures.

I found one quite outdated article on that topic: http://horizonchess.com/FAQ/Winboard/weaktablebase.html . The issue is that harddisks and not SSDs are examined. Today, the access time should be down from 13ms to maybe 50µs, a factor of 260. However, the operating system calling overhead is still there.

Plus that a good deal of the lookup tables will be in the disk cache. Especially under Linux which likes to dedicate most unused RAM to caching.

And that's where things become unfair: if a TB engine practically allocates a lot of disk cache memory, then the fair comparison without TB would be to enlarge the hash tables by the same amount.

Or, it opens up another possibility for engines that don't use TB in search: starting a background worker thread during their own search which just looks up TBs that are totally irrelevant for the position in question, only for trashing the disk cache and slowing down engines that use TBs in search. So when it's the other engine's turn, it won't get the free lunch of the disk cache. That's a bit evil, of course, but not more evil than allocating lots of memory behind the back.

[pedrox]

The following seems to work well for me.

Thank you, Pedro. I see you have references to WDL. Does that mean you are using Syzygy in addition to Gaviota?

[Edit] Ah, actually, you must be using the thread safe API mentioned here https://chessprogramming.wikispaces.com ... Tablebases to get cached WDL info.

I use TB Probing code (tbprobe-0.4.zip)
https://sites.google.com/site/gaviotach ... e/download

I had to slightly adapt the tbprobe.c file to make it work with my internal representation of the chessboard. In my engine the file is called etgb.c.

In the package comes a makefile file (I think I modified it) to create a libgtb.a with the access code to gaviota, I prefer to have this code outside the engine code and not have to compile it with the engine, in my engine I have versions of this library for most operating systems. At least I think there are 2 other engines that use this system.

And for the code during the search I tried to follow the advice of its programmer (Miguel) that gave in some thread of the forum.

If you want to have library or look at my code you can download my engine (danasah 6.5).
https://sites.google.com/site/danasah/e ... h-z-engine

[syzygy]

And that's where things become unfair: if a TB engine practically allocates a lot of disk cache memory, then the fair comparison without TB would be to enlarge the hash tables by the same amount.

There is no reason to take into account "fairness" when improving a chess engine by adding TB support. Chess engines are used for analysis etc.

Of course TB usage may be something to take into account when setting up an engine-engine match. Whether it will be "fair" to let an engine use TBs will depend on the hardware context and on what you want the chess match to measure. If you don't want a chess engine to profit from TBs when playing another engine, then just disable them.