SYZYGY question
Posted: Sun Aug 11, 2019 4:21 am
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.
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.
) 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.