infinite score & tt

[Joost Buijs]

Did some debugging and found this:

Code: Select all

root: s(a, b) -32767, 79
1: s(-b, -a) -79, 32767
2: s(-b, -(b - 1)) -32767, -32766 NM
3: s(-b, -a) 32766, 32767
4: s(-b, -(b - 1)) -32767, -32766 NM
5: qs(-b, -a)) 32766, 32767
6qs: (assert)

infinite is 32767 in my code
At the root search() is called with -32767 for alpha and 79 for beta and so on. NM means that a null-move is executed.
So this null move makes a/b go to -32767,-32766. By this alpha ends up being 32766 and thus the assert triggers (

Code: Select all

        if (bestVal < alpha - big_delta) {
                assert(abs(alpha) <= 10000);
                return alpha;
        }

It looks like there is nothing wrong because you are actually returning +INF-1 and not +INF which would be an error.
There is also nothing wrong with storing this value as an upper-bound in your transposition table, although I personally refrain from storing values that lay outside the evaluation boundaries.

In my engine this will only happen during the first iteration of my aspiration search when I search(-INF, +INF) out of laziness.
I guess you are searching with (-INF, beta) after a fail-low and with (alpha, +INF) after a fail-high, otherwise I can not explain the values you show in your example.

[hgm]

It seems the assert is wrong. Why do you expect alpha to remain below 10000 if INF=32767 >> 10000?

Fairy-Max would store a score of +INF for a node wher it could capture the King. A hash cutoff resulting from a hit on that would still save it the trouble of generating moves so it would discover it could capture the King. It stores a score of -INF for a full-width node where it is checkmated. That saves it the work of trying all potential evasions, and finding the King-captures in the daughter node.

[flok]

I can't remember why I had came up with that understanding that |a|/|b| should be <= 10k (it was from the time that I did not kept notes).

I replaced the assert now (also thanks to J. B. Buijs!) by a check for abs(score) <= 10000 || abs(score) == 32766 (because of the -beta, -beta + 1 search by null move).

[hgm]

Is your mate score not larger than 10,000, then? If it is only 10,000, why would you use a search window with limits larger than 10,000 in absolute value? Are you hoping it will return results better than an immediate mate, or worse than being checkmated?

[flok]

Is your mate score not larger than 10,000, then? If it is only 10,000, why would you use a search window with limits larger than 10,000 in absolute value? Are you hoping it will return results better than an immediate mate, or worse than being checkmated?

Well, that was exactly the problem.
The maximum eval score is +/-10000 - 1 ply.

The +/-32766 I saw are a side-effect of the null-move where I call search(-b, -b + 1).

And then also I had scores 9999...10099. Those were caused by the aspiration windows at the top of the tree. So before I call search() there, I clamp a/b at +/-10k.

[hgm]

The maximum eval score is +/-10000 - 1 ply.

Maximum score of the static eval, or mate score?

Either way, something is wrong. If it your mate score is largerthan 10,000, the assert would trigger on every mate score. If it is smaller, then it seems wrong to have alpha or beta larger than 10,000.

[flok]

The maximum eval score is +/-10000 - 1 ply.

Maximum score of the static eval, or mate score?

Maximum score of the eval and 10k - ply_depth for mate score.

Either way, something is wrong. If it your mate score is largerthan 10,000, the assert would trigger on every mate score. If it is smaller, then it seems wrong to have alpha or beta larger than 10,000.

It only became larger then 10k because in the root I would adjust the window to score +/- 50 (iterative deepening) but I did not make sure that a and b were in range -10k ... 10k.
Now that I do, I no longer see scores outside that range during the search. I also added a check to see if alpha == beta.

[flok]

@hgm does that sound sane to you? Or did you just gave up?

[hgm]

In general it is pointless to make the search window larger than the score range you expect. So if even mate scores cannot exceed 10,000, you should allow alpha or beta in the root to go beyond that. In a fail-hard scheme alpha or beta do get returned as scores.

[flok]

In general it is pointless to make the search window larger than the score range you expect. So if even mate scores cannot exceed 10,000, you should allow alpha or beta in the root to go beyond that. In a fail-hard scheme alpha or beta do get returned as scores.

What do you mean?
Is is pointless to make the window too large but then you say that even if the scores cannot exceed that range, you still should allow a/b to go beyond that? Doesn't that contradict?