SYZYGY question

[bob]

Ronald:

I have been looking at a quirk for a good while the last couple of days. First, here is the troubling position:

[D]8/8/8/kPK5/p7/8/1P6/8 w - -

I am seeing two oddities.

If I type "go" here, I see the instant results of "b4+ null". The null is the quirk. If I do other positions without EP possible, no problems here.

If I type "b4" instead, Crafty spits out "null" for its move choice.

When I look at the return value from tb_probe_root for the first case white to move, I see a fairly big number that has the move encoded in it. For the second move, I see a return value of "4" which is the "win" flag. But the move info is not encoded which causes that null in the first PV. For the second case, where crafty tries to make a move "null" I again see a return of 4 from the tb_probe_root() function.

Is there something I am doing wrong that could make tb_probe_root() return just a "won" value without the move? It ONLY happens when there is an enpassant possible (in this position, the ep capture is the only legal move as you can see.

What am I doing wrong here or is there a bug in this fairly old code for handling your endgame tables? This dates back to 2016 or so, so anything is possible.

[D Sceviour]

What am I doing wrong here or is there a bug in this fairly old code for handling your endgame tables?

Must be. Nothing wrong here with Schooner and the 6-piece egtb.

Code: Select all

  0	+326.45	1	0:00.00	b6b7

For a guess, maybe try looking at the en passant flags in the move list for an error.

[petero2]

I have been looking at a quirk for a good while the last couple of days. First, here is the troubling position:

[D]8/8/8/kPK5/p7/8/1P6/8 w - -
...
What am I doing wrong here or is there a bug in this fairly old code for handling your endgame tables? This dates back to 2016 or so, so anything is possible.

That sounds like the bug discussed here which was fixed like this.

[syzygy]

What am I doing wrong here or is there a bug in this fairly old code for handling your endgame tables? This dates back to 2016 or so, so anything is possible.

If I am not mistaken, crafty uses the Fathom library. That's where the bug seems to be. Upgrading that code hopefully will help.

[syzygy]

I have been looking at a quirk for a good while the last couple of days. First, here is the troubling position:

[D]8/8/8/kPK5/p7/8/1P6/8 w - -
...
What am I doing wrong here or is there a bug in this fairly old code for handling your endgame tables? This dates back to 2016 or so, so anything is possible.

That sounds like the bug discussed here which was fixed like this.

That doesn't seem to be the problem, since crafty 25.2 has this line in (fantom's) tbprobe.c:

Code: Select all

      int v = (pos1.ep == 0 ? -probe_ab(&pos1, -2, -wdl + 1, success) : -probe_wdl(&pos1, success)); //added mfb

[bob]

What am I doing wrong here or is there a bug in this fairly old code for handling your endgame tables? This dates back to 2016 or so, so anything is possible.

If I am not mistaken, crafty uses the Fathom library. That's where the bug seems to be. Upgrading that code hopefully will help.

Can you give me a link on where to download the latest version? Will try that...

[jdart]

Latest Fathom is here:

https://github.com/jdart1/Fathom

[bob]

OK, got new version in, and that seems to be working. (I did have a bug in my code as well, but it did not show up until the ep bug was fixed. ) I did not think about ep captures coming back from the lookup, and basically all I get is a from and to square, and was adding the moving piece and captured piece manually. Captured piece was board[to], which was a problem because after the ep bug was fixed by the new version of tbprobe, it was giving me a from of a4 and a to of b3, but b3 was empty, which pissed off my MakeMove() code. Once I fixed that, all seems to be working. I am now trying to figure out why, if I include tbprobe.c in the big crafty source compile, it produces a few errors, where when compiled by itself all is OK. I am trying to run those down now before I release the new version.

Edit: found the problem at it now compiles separately or in one large source wad. Will make this available after talking with Mike/Dann and anyone else wanting to provide a new source file...