problem with syzygy tablebases

[ymatioun]

I'm trying to implement syzygy tablebases in my program, and i came across one positions where syzygy tells me it is a loss, while it is really a win.

This is the FEN: 7R/8/3k3q/P7/8/3K4/8/8 w - - 0 0

White to move, so white rook takes black queen, and wins easily because white is now rook+pawn ahead.

When i call syzygy WDL function (probe_wdl_table), it returns -2, a loss.

Haw anybody seem this sort of problems? Perhaps somebody with functioning syzygy logic could check this position?

FYI, inside "probe_wdl_table" function i see material key of 0xf3d4f6f03036be3d, and i get idx=0x0000000003ceabed from the execution of "idx=encode_pawn(entry,entry->file[f].norm[bside],p,entry->file[f].factor[bside]);" line.

Thanks, Youri.

[syzygy]

When i call syzygy WDL function (probe_wdl_table), it returns -2, a loss.

Call probe_wdl() instead. Probe_wdl_table() is an internal function.

The explanation for -2 is exactly that white has a winning capture. Probe_wdl() checks for these. The compression algorithm assigned a -2 to this position because of heuristics saying that should lead to better compression.

Feel free to ask if you have questions, e.g. relating to the material key. I have realised this part is hardly documented. The idea is that you use your engine's own material key, but I am assuming certain properties that may not be true in all engines.

In particular:
- the highest 10 bits or so of the materlal key should be random (those are used for hashing);
- the material key should not distinguish between bishops on light and dark squares.

If your engine happens to distinguish between light and dark bishops it is going to be a bit messy.

[ymatioun]

I'll try that, thanks!

[syzygy]

Call probe_wdl() instead.

Of course it's a bit more complicated than this. You'll have to modify probe_wdl() to use your engine's move generator. Then from the search you can call probe_wdl().

[ymatioun]

I got it working, and everything looks fine. Thank you for your help.

Youri.

[syzygy]

I got it working, and everything looks fine. Thank you for your help.

Excellent!

[ymatioun]

So, with Roland's help i set-up 5-piece tables, and they all work.

I just tried using 6-piece tables, and i am having problems again.

When i start with position 4k3/8/4b3/5p2/8/3P4/1B1K4/8 w - - 0 0, it crashed on call to probe_wdl() function.

Call history is probe_wdl() calls probe_ab(-2,2,success),
which generates "(at least) all legal non-ep captures" - there are none, so next it calls probe_wdl_table(success), which generates material key=0x9240b954037d0f96, loads appropriate table, proceeds with "encode_pawn" function, and the crashes during call to "decompress_pairs()", trying to access d->sizetable[block] with block=0x62fc0ffa.

My question is: could somebody try this position, to make sure it works with 6-piece syzygy tables? If it does, do you get the same material key as i do?

Thanks.

[syzygy]

Works fine for me, so you have a bug. It is a draw.

The value of the material key depends on how your program calculates its material key. (Some functions in tbprobe.cpp have to be adapted accordingly.)

[ymatioun]

OK, thanks. I'll keep digging.