Why the asserts never triggered?

[Sven]

I posted my final see_debug(), the corrected version in the other thread. As can be seen, it is very simple to understand and straight forward. It has very few lines.

I strongly disagree. It is far too long and too complex for SEE. I still believe that the following features in your SEE code are not necessary and/or not straightforward:

- caring about "in check" and discovered check (when you are in check during QS then you'd better do some kind of evasion search instead of a classical QS, so pruning losing captures should never become an issue when in check);

- generating moves (you only need all attacks to the target square);

- making/unmaking moves on the board (much too expensive, you only need to add/subtract one piece value per attacker of the target square);

- caring about move legality;

- your algorithm to decide whether the current capture shall be accepted or not, based on the "gain" variable (I still do not see how it works, and it can be written much simpler in a way that everyone understands immediately and that is obviously bug-free without the need for debugging).

My customized bitboard SEE has about 400 lines.

Even worse

Now I don't want to rake my brain to figure why assert(gain <= 0) passed.

I suspect you should, since you move on but keep a potential "troublemaker" in your code.

If you don't understand that assertion then you don't understand why your code works, or if it works at all.

Sven

[Evert]

These discussions have prompted me to look at my own SEE routine again, and I found a number of inefficiencies that I could take care of, which speeds things up nicely. My time-to-depth has decreased about 3% with the same node count (so it's a pure speedup) in various test positions.

My SEE function is only 150 lines though, so it's fairly simple.