Strange negamax behaviour

[Karlo Bala]

I have just tried your recommendations, but with no success. I decided to test alphabeta without quiescence search, and it actually began giving more reasonable lines like:
[pgn]1. Nc3 Nf6 2. e4 e5 3. Nf3 Bb4 4. Ne2 Nxe4 *[/pgn]

Although this is far from optimal, I think it is a huge improvement since it really doesn't loose material the same way, and doesn't give away material as black. Therefore, i think all of this is an error in quiescence search after all, and the mistakes in the above PGN are a mixture between very minimal evaluation and shallow search depth.
What do you think? Could quiescence be the culprit?

Without qSearch, the last move in the PV almost always will be a (stupid) capture.

As I said, you should start the search at the position after 1. Nc3 Nf6 2. e4 to see if the engine will capture the pawn on e4.

If you want to test qSearch just start the search with depth=0

[hgm]

Code: Select all

		if (ss->pos->ply > MAXDEPTH - 1) {
			return Eval::evaluate(ss->pos);
		}

What is that supposed to do ?

I never call eval() in the search, except for pruning purposes.

It guards the data structure. Many arrays are limited to MAXDEPTH (MAXPLY).
If such a limit is reached you can not go deeper in the tree, so you return the static eval.

This is pretty much a 'never happens' event when MAXPLY is suitably chosen, and when it happens, it is almost certainly not in a menaingful line, so that it doesn't really matter what you return. So for simplicity I usually return 0 in this case.

[Sven]

One common error is that Evaluate() always returns a score from White viewpoint while negamax based search (also in quiescence()) expects a score from the viewpoint of the moving side.