I'm looking to improve my program.
For that I'm adding asserts all over the place to check input variables, outgoing values, and so on.
I've also added an assert that if we're in a null move, then beta == alpha + 1.
My question now is: what other things are there to check for?
regards
The last question also shows why one should not overrate assert(),you already have to now what to look for...
Anyway,you can add asserts for hashtable initialized
board is valid before and after makemove
alpha<beta
remaining depth< limit or your killer and other tables
remaining depth>=0
various checks on a move(squares in range,piece,etc)
Knowing what I am going to test in an assert for me is almost the same as already realizing how I calculated it wrong. I get many errors in my engines, but when I finally smoked them out, they are always in a completely unexpected place, which I never imagined could go wrong, and would never have and the idea for to test it with an assert.
When you have a lot of incrementally updated stuff, it is very advisable to also have a routine to calculate it from scratch, and compare the two.
Check that all scores returned by eval or from the hash are in the range of valid values (-MATE, +MATE).
Sanity check all moves returned from the move generator or the hash., or added to the PV array I.e. a valid piece is on the start square, the dest is not a same-color piece, etc.
I have a check after each move made that the hash code after the move (updated incrementally) matches the value calculated from scratch (not incrementally)
If you have C-style arrays, do a bound check on the index before access. (Or consider using <array> if C++).
mar wrote:if you index local arrays out of bounds, that's your problem.
That's only one of the countless pitfalls. C has tons of undefined behaviour. Like shifting by more than a variable's width, signed integer overflow or pointer aliasing. Together with increasingly hostile compilers, you can't even rely on well-tested code.
Under Linux, GCC offers a lot of sanitizer options that are useful during testing, and I'd advise to use them.
void Move::set( ColorType color, SquareType from, SquareType to,
PieceType piece, PieceType capture,
PromotionType promotion
)
{
ASSERT_MOVE( color == White || color == Black, "Error: bad color in Move::set()" )
ASSERT_MOVE( from >= 0 && from < 64, "Error: bad from in Move::set()" )
ASSERT_MOVE( to >= 0 && to < 64, "Error: bad to in Move::set()" )
ASSERT_MOVE( piece >= Pawn && piece < 8, "Error: bad piece in Move::set()" )
ASSERT_MOVE( capture >= NoPiece && capture != King && capture < 8, "Error: bad capture in Move::set()" )
ASSERT_MOVE( promotion <= PromoteToKnight, "Error: bad promotion in Move::set()" )
move_ = from | (to << 6) | (promotion << 12) | (piece << 14) | (capture << 17) | (color << 20);
}
This is pointless. Just clutters the code for no reason.
Assert already prints the source file name and line when it fires.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
void Move::set( ColorType color, SquareType from, SquareType to,
PieceType piece, PieceType capture,
PromotionType promotion
)
{
ASSERT_MOVE( color == White || color == Black, "Error: bad color in Move::set()" )
ASSERT_MOVE( from >= 0 && from < 64, "Error: bad from in Move::set()" )
ASSERT_MOVE( to >= 0 && to < 64, "Error: bad to in Move::set()" )
ASSERT_MOVE( piece >= Pawn && piece < 8, "Error: bad piece in Move::set()" )
ASSERT_MOVE( capture >= NoPiece && capture != King && capture < 8, "Error: bad capture in Move::set()" )
ASSERT_MOVE( promotion <= PromoteToKnight, "Error: bad promotion in Move::set()" )
move_ = from | (to << 6) | (promotion << 12) | (piece << 14) | (capture << 17) | (color << 20);
}
This is pointless. Just clutters the code for no reason.
Assert already prints the source file name and line when it fires.
Those are pretty bad examples, but sometimes you do want to have a message to go with the assert. I have seen this trick used before:
