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.