I'm writing my own KPK bitbase code and using Stockfish bitbase.cpp for debugging. I found that Stockfish bitbase code is imperfect; it is unable to classify 17826 positions.
I was able to classify all positions and decide to implement the changes to Stockfish 1.7.1.
kongsian wrote:I'm writing my own KPK bitbase code and using Stockfish bitbase.cpp for debugging. I found that Stockfish bitbase code is imperfect; it is unable to classify 17826 positions.
I was able to classify all positions and decide to implement the changes to Stockfish 1.7.1.
Hi Kongsian,
thanks a lot for this patch. I will test and apply to current development branch.
kongsian wrote:I'm writing my own KPK bitbase code and using Stockfish bitbase.cpp for debugging. I found that Stockfish bitbase code is imperfect; it is unable to classify 17826 positions.
I was able to classify all positions and decide to implement the changes to Stockfish 1.7.1.
diff --git a/bitbase.cpp b/bitbase.cpp
index 801815e..818b679 100755
--- a/bitbase.cpp
+++ b/bitbase.cpp
@@ -152,6 +152,28 @@ namespace {
if(whiteKingSquare == SQ_A8 && pawnSquare == SQ_A7 &&
(blackKingSquare == SQ_C7 || blackKingSquare == SQ_C8))
return true;
+
+ // Case 3: white king in front of white pawn and no opposition
+ if(whiteKingSquare == pawnSquare+DELTA_N &&
+ blackKingSquare == pawnSquare+3*DELTA_N &&
+ pawnSquare < SQ_A5)
+ return true;
+ }
+
+ // Case 4: black king in front of white pawn
+ if(blackKingSquare == pawnSquare+DELTA_N && pawnSquare < SQ_A7)
+ return true;
+
+ // Case 5: rook file
+ if(square_file(pawnSquare) == FILE_A)
+ {
+ if (blackKingSquare == SQ_A8)
+ return true;
+
+ if (square_file(whiteKingSquare) == FILE_A &&
+ square_file(blackKingSquare) == FILE_C &&
+ blackKingSquare > pawnSquare)
+ return true;
}
return false;
Kong Sian
Hello Kongsian,
I am not sure I understand the purpose of this patch. Unless I am missing something, your patch simply adds a few rules for identifying draws which are already detected by the bitbase generation code. The generated bitbase will be (again, unless I am missing something) 100% identical to the one generated by Stockfish 1.7.1. The only thing that perhaps changes is that bitbase generation will be a tiny bit faster.
kongsian wrote:I'm writing my own KPK bitbase code and using Stockfish bitbase.cpp for debugging. I found that Stockfish bitbase code is imperfect; it is unable to classify 17826 positions.
I was able to classify all positions and decide to implement the changes to Stockfish 1.7.1.
diff --git a/bitbase.cpp b/bitbase.cpp
index 801815e..818b679 100755
--- a/bitbase.cpp
+++ b/bitbase.cpp
@@ -152,6 +152,28 @@ namespace {
if(whiteKingSquare == SQ_A8 && pawnSquare == SQ_A7 &&
(blackKingSquare == SQ_C7 || blackKingSquare == SQ_C8))
return true;
+
+ // Case 3: white king in front of white pawn and no opposition
+ if(whiteKingSquare == pawnSquare+DELTA_N &&
+ blackKingSquare == pawnSquare+3*DELTA_N &&
+ pawnSquare < SQ_A5)
+ return true;
+ }
+
+ // Case 4: black king in front of white pawn
+ if(blackKingSquare == pawnSquare+DELTA_N && pawnSquare < SQ_A7)
+ return true;
+
+ // Case 5: rook file
+ if(square_file(pawnSquare) == FILE_A)
+ {
+ if (blackKingSquare == SQ_A8)
+ return true;
+
+ if (square_file(whiteKingSquare) == FILE_A &&
+ square_file(blackKingSquare) == FILE_C &&
+ blackKingSquare > pawnSquare)
+ return true;
}
return false;
Kong Sian
Hello Kongsian,
I am not sure I understand the purpose of this patch. Unless I am missing something, your patch simply adds a few rules for identifying draws which are already detected by the bitbase generation code. The generated bitbase will be (again, unless I am missing something) 100% identical to the one generated by Stockfish 1.7.1. The only thing that perhaps changes is that bitbase generation will be a tiny bit faster.
Hi Tord. If you print out "UnknownCount" in next_iteration(), you will find that it terminates when UnknownCount == 17826. Here it is.
kongsian wrote:Hi Tord. If you print out "UnknownCount" in next_iteration(), you will find that it terminates when UnknownCount == 17826.
True. These are the positions where neither side can force a mate, a stalemate, or a draw by material. Because neither side can mate, they are drawn, and the existing bitbase code already classifies these positions as drawn. You just add some rules that detect them as drawn from the beginning instead of letting the bitbase generation function detect them as drawn. It probably makes bitbase generation a tiny bit faster, but the generated bitbase will be 100% identical (unless there is some bug I cannot see).
kongsian wrote:Hi Tord. If you print out "UnknownCount" in next_iteration(), you will find that it terminates when UnknownCount == 17826.
True. These are the positions where neither side can force a mate, a stalemate, or a draw by material. Because neither side can mate, they are drawn, and the existing bitbase code already classifies these positions as drawn. You just add some rules that detect them as drawn from the beginning instead of letting the bitbase generation function detect them as drawn. It probably makes bitbase generation a tiny bit faster, but the generated bitbase will be 100% identical (unless there is some bug I cannot see).
Yes, these are likely drawn, but the bitbase code currently classify them as UNKNOWN, not drawn. Just dump the Bitbase[] array after generation and you can see that some values are still 0.
kongsian wrote:Hi Tord. If you print out "UnknownCount" in next_iteration(), you will find that it terminates when UnknownCount == 17826.
True. These are the positions where neither side can force a mate, a stalemate, or a draw by material. Because neither side can mate, they are drawn, and the existing bitbase code already classifies these positions as drawn. You just add some rules that detect them as drawn from the beginning instead of letting the bitbase generation function detect them as drawn. It probably makes bitbase generation a tiny bit faster, but the generated bitbase will be 100% identical (unless there is some bug I cannot see).
Yes, these are likely drawn,
No, they are not likely drawn, they are proven to be drawn. That's the whole point of how the process of bitbase generation works. At the point where the number of unclassified positions doesn't change from one iteration to the next, all the remaining positions with a RESULT_UNKNOWN status must be drawn.
but the bitbase code currently classify them as UNKNOWN, not drawn. Just dump the Bitbase[] array after generation and you can see that some values are still 0.
Correct, but the Bitbase[] array is just something that is used temporarily while generating the bitbase. It is immediately discarded afterwards. The bitbase[] array (with a lowercase 'b') is the one that is used later on. In this array, the positions are compressed to a a single bit per position, where 1 represents a win for the side with the pawn and 0 represents a draw. The compression is done by this function, which is called after the bitbase generation is finished:
