Syzygy tablebases, work in Stockfish?

[velmarin]

The I downloaded, I made my windows compilation with Intel, I tested with compilations of others.
Something is not right, do not work, at least not work with the codes posted.
Some comparisons Comstock positions.

Code: Select all

Analysis by Stockfish 230913 64: 

69.Re6 
  +-  (3.83)   Profondeur: 1/2   00:00:00 
69.Re6 Fc4+ 70.Rf6 Fb5 71.Re5 Fc6 
  +-  (3.75)   Profondeur: 5/6   00:00:00 
69.Re6 Fc4+ 70.Rf6 Fb5 71.Re5 Fc6 
  +-  (3.75)   Profondeur: 5/6   00:00:00 
69.Re6 Fc4+ 70.Rf6 Fb5 71.Re5 Fc6 
  +-  (3.75)   Profondeur: 5/6   00:00:00 
69.Re6 Fc4+ 70.Rf6 Fb5 71.Re5 Fc6 
  +-  (3.75)   Profondeur: 5/6   00:00:00 
69.Re6 Fc4+ 70.Rf6 Fb5 71.Re5 Fd7 72.Fg6 Rc6 
  +-  (3.67)   Profondeur: 7/8   00:00:00  2kN, tb=1 
69.Re6 Fc4+ 70.Rf6 Fb5 71.Re5 Fd7 72.Fg6 Rc6 
  +-  (3.67)   Profondeur: 7/8   00:00:00  2kN, tb=1 

[syzygy]

Something is not right

See the Readme, "What to expect":
https://github.com/syzygy1/Stockfish

[velmarin]

Something is not right

See the Readme, "What to expect":
https://github.com/syzygy1/Stockfish

Thanks for the reply.

So I assume that the information supplied to the engine at the moment is 0.
I understand nothing.

[syzygy]

So I assume that the information supplied to the engine at the moment is 0.
I understand nothing.

Since the position is a draw, the engine gets to search the moves that do not lose.

In tricky positions this might enable the engine to trick the opponent into making a mistake. If the engine would just play a random drawing move, any advantage that the engine might have (even if the position is a theoretical draw) will usually quickly be lost.

Your 2nd position is not tricky enough for white to make a mistake, but giving up the black pawn will at least look dumb.

[hgm]

For drawn positions this is of course exactly what one should do. But it seems to me that for won positions you would have the problem that the tablebases are no help at all in winning end-games that are generally won, but very difficult to win (like KQKR). Playing by DTZ would guarantee a win, and only suffer from a cosmetic problem that this win would not be the fastest (which playing by the engine eval would also not guarantee...). Which does seem preferable.

[velmarin]

I've seen that work, work well.

In view positions, are on the tables, so the information is erroneous,
I say, the information.

Many users use these engines to analyze, of little help if in a drawn position, the engine says +3 or + 17.

But I find that they work.
It's the way it has done so Ronald and taken.
I'll keep messing with it, I have interest in the project.

[hgm]

Well, the first position you show is a reglementary draw, and the GUI should not even present it to the engine, as FIDE rules specify the game has finished.

The other games can still be won. It would be cosmetically better to let the engine report its 'natural' evaluation score divided by 10 (or even 100). Actually, if the engine was smart enough, it should already have done that without the help of tablebases, as the positions are easily recognizable as drawish.

[velmarin]

The last position has been placed by Vincent lejeune, corresponds to a real game,
Houdini, Stockfish 4, Bouquet, give feedbacks between + 1.7 to +3,

The image corresponds to Comstock (stockfish with Robbobases) drawish perfectly values​​.

How says Ronald (or I understood) bases the engine works perfect, but the information is internal, the user does not see, he has put some examples with horses and I've tried to run bases.
It is what it is.
Maybe we can find some trick, or probe in Eval, ect.

[hgm]

The last position has been placed by Vincent lejeune, corresponds to a real game,
Houdini, Stockfish 4, Bouquet, give feedbacks between + 1.7 to +3,

Well, I guess the last position is not an obvious draw, because it is conceivable that white positions its King on f8, and then his Bishop on e8 (as the black King cannot cover e8 without blocking his own Bishop), chasing awaythe black Bishop from the a4-e8 diagonal, then move away from e8 on that diagonal, so that the Bisop has to defend on e8-h5, and then move to f7 to close that diagonal.

Still pretty embarrassing for the engines that they cannot find it is not possible to make progress on their search alone, though, in such a simple position.

[syzygy]

For drawn positions this is of course exactly what one should do. But it seems to me that for won positions you would have the problem that the tablebases are no help at all in winning end-games that are generally won, but very difficult to win (like KQKR). Playing by DTZ would guarantee a win, and only suffer from a cosmetic problem that this win would not be the fastest (which playing by the engine eval would also not guarantee...). Which does seem preferable.

For a position that is won, the DTZ tables are used to filter out those moves that would throw away the win. This takes into account the 50-move rule (and 3-fold repetition: after the first repetition, it just plays according to DTZ).

So the engine is guaranteed to win the position, and it will avoid 99.9% of the cosmetic problems.

Note that the first version did play strictly according to DTZ and users were terribly confused by the preference for a pawn move over a mate in two. Anyway, I will soon implement an option to enable the old behaviour for positions that are won.

Many users use these engines to analyze, of little help if in a drawn position, the engine says +3 or + 17.

I agree the user should somehow be informed of the tablebase outcome. The problem is that UCI is a restriction here, so it is not immediately clear what is the best solution.

Also note that my Stockfish tree is experimental and unsupported and primarily intended as a quick hack to show how to integrate the tables and probing code into an engine. Still, I am open to good suggestions.