TalkChess.com

Hi,

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

Your program starts to be complicated and it's difficult to understand if inside the flow there are some strange bug.
Adding assert will help you finding them.
If You expect some assertion to be true in some path of code, assert them and let the program check them at runtime.
For example alpha < beta for every node. Alpha +1= beta for scout nodes.
Depth < 0 in q search. Those are generic assert.
For each function you can add assert that you think should be true

I use assert as follows.

1/ Check (systematically) that input variables of functions are within expected range.
This goes a long way already. Start with the most frequently used functions. If you don't who they are, ask the profiler (sort results by descending number of calls). Such functions are going to be things like file_of(int s): it's used almost everywhere, directly or indirectly, so if ever an invalid square value pops up, it will endup in file_of() at some point and trigger the assert.

2/ Document the implicit assumption that the code makes
Whenever there's an implicit assumption, put an assert. For example in an else block, where reaching the else implies that the move is en-passant (let's say), assert that it's en-passant. The assert is both a bug trap, *and* documentation.
In the search, alpha/beta/PVnode relationships etc.

But assert is not enough. It's not because your variables are in range that you don't have bugs. If you're serious about debugging, you should also use Clang sanitizers, or Valgrind at least. It's truly amazing the number of invisible (or very rarely visible and not reproducible) bugs that chess engines have. Even strong engines. Undefined behaviors and subtle bugs are pervasive in C, and even more so in C++. If you're coding in a more robust language like D or C#, you shouldn't have this kind of problem.

What I remember is that adding complete pre- post conditions and invariants makes the program more complex than it's original. And the more complicated the more errors.

Best is to write pure functions but that is not possible.

[throwing exceptions is similar to using goto statements ]

lucasart wrote:I use assert as follows.

1/ Check (systematically) that input variables of functions are within expected range.
This goes a long way already. Start with the most frequently used functions. If you don't who they are, ask the profiler (sort results by descending number of calls). Such functions are going to be things like file_of(int s): it's used almost everywhere, directly or indirectly, so if ever an invalid square value pops up, it will endup in file_of() at some point and trigger the assert.

2/ Document the implicit assumption that the code makes
Whenever there's an implicit assumption, put an assert. For example in an else block, where reaching the else implies that the move is en-passant (let's say), assert that it's en-passant. The assert is both a bug trap, *and* documentation.
In the search, alpha/beta/PVnode relationships etc.

But assert is not enough. It's not because your variables are in range that you don't have bugs. If you're serious about debugging, you should also use Clang sanitizers, or Valgrind at least. It's truly amazing the number of invisible (or very rarely visible and not reproducible) bugs that chess engines have. Even strong engines. Undefined behaviors and subtle bugs are pervasive in C, and even more so in C++. If you're coding in a more robust language like D or C#, you shouldn't have this kind of problem.

Better use F# or even better Haskell if it would not be impractical.

Thank you all guys but I'm more looking for things like "in situation x, check if alpha > score and score < tt val" etc.
Like: in null move, check if alpha = beta - 1 and so on.

flok wrote:Thank you all guys but I'm more looking for things like "in situation x, check if alpha > score and score < tt val" etc.
Like: in null move, check if alpha = beta - 1 and so on.

If you use fail hard you know what to check. But fail hard is slower.

lucasart wrote:Undefined behaviors and subtle bugs are pervasive in C, and even more so in C++. If you're coding in a more robust language like D or C#, you shouldn't have this kind of problem.

nonsense.

if you index local arrays out of bounds, that's your problem.
C# is slower compared to C/C++/D, I don't see how D is more robust than C/C++ except that it zero-initializes by default (not talking about language features).

(if you think so, maybe you should switch to D/C#)

in fact, C++ is of course more "robust" than C, you can use std::array which checks bounds in debug mode and of course more.

Valgrind/DrMemory won't catch all problems, but they're pretty good.

now back to OP: asserts are nice but they also slow your code in debug mode, so too many of them probably hurts

You can find a lot of assert in position.h and position.cpp of Vajolet source code. It's probably not perfect but can give you some idea

If you want to test only parts of your code then you can do things like this:

In an header like basics.h And in a file like move.cpp