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.
SYZYGY question
Moderators: hgm, Rebel, chrisw
-
- Posts: 570
- Joined: Mon Jul 20, 2015 5:06 pm
Re: SYZYGY question
Must be. Nothing wrong here with Schooner and the 6-piece egtb.
Code: Select all
0 +326.45 1 0:00.00 b6b7
-
- Posts: 690
- Joined: Mon Apr 19, 2010 7:07 pm
- Location: Sweden
- Full name: Peter Osterlund
Re: SYZYGY question
That sounds like the bug discussed here which was fixed like this.bob wrote: ↑Sun Aug 11, 2019 4:21 am 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.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: SYZYGY question
If I am not mistaken, crafty uses the Fathom library. That's where the bug seems to be. Upgrading that code hopefully will help.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: SYZYGY question
That doesn't seem to be the problem, since crafty 25.2 has this line in (fantom's) tbprobe.c:petero2 wrote: ↑Sun Aug 11, 2019 7:22 amThat sounds like the bug discussed here which was fixed like this.bob wrote: ↑Sun Aug 11, 2019 4:21 am 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.
Code: Select all
int v = (pos1.ep == 0 ? -probe_ab(&pos1, -2, -wdl + 1, success) : -probe_wdl(&pos1, success)); //added mfb
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: SYZYGY question
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: SYZYGY question
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...
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...