High branching factor when mate score is found

[op12no2]

As far as I'm aware, this behavior shouldn't happen. Maybe I'm wrong, but does this mean that there's a bug in my PVS implementation?
jm

Lozza has a standard/simple PVS implementation and seems OK with the position in terms of mate distances. Presumably Myrddin thinks he(?) is further from the root that he really is? - given that having observed a gazillion games between the two, Lozza and Myrddin search to the same depths kindasortaish...

Live link of Lozza analysis (eats cpu) - https://goo.gl/eph5eN

Lozza gets a root score <= alpha at depth 25 so opens up the window to find the mate.

source: http://op12no2.me/toys/lozza/lozza.js

[hgm]

Rather than just trying random things to see if they have an effect, you could try to learn how the engine actually burns this large number of nodes: let it print node counts for every move it searches in the root, or on every pair of moves in the first two ply levels, etc.

I would even suggest to do this for the first four plies in the given position since that would already include pawn promotion on b8.

Indeed, that was what the "etc." tried to communicate.

If one specific variation shows up that consumes many nodes then use the position after these four plies as new subject of test, and repeat the same process from there, etc. If no specific variation shows up, i.e. node burning looks almost evenly distributed, then select any arbitrary line and proceed as above as if this were the "one specific variation".

Of particular interest should be the number of moves searched in cut-nodes. If they have many daughters that split the effort roughly equally, you know something is wrong already without following any of these lines more deeply: all nodes spent on moves searched before the cut-move were totally wasted, and would not have been searched when the cut-move had been searched first.

[mjlef]

Nullmove should be disabled when you are down to K&Ps. At least most programs do it that way, since zugzwang is much more common in K&P endgames. Most programs disable nullmove whenever the side to move has no N, B, R or Q.

[xmas79]

Ok, this may or not be helpful. But Myrddin has always had a similar problem, or at least a problem that looks similar. Sometimes when it reports a mate score, on a subsequent ply it will fail low multiple times and then report a silly mate score like "Mate in 51". Your post led me to investigate this again and I've determined that if I disable the zero-width window search, and just search every node at [Alpha, Beta], then the problem goes away.
...
As far as I'm aware, this behavior shouldn't happen. Maybe I'm wrong, but does this mean that there's a bug in my PVS implementation?

jm

When I started CompChess I exactly found what you described. I registered here just to get a clue on what was happening: bug or what? I ended up doing a very deep analysis on my own, and I had to conclude that I had no bug in my search code. I think it was my first post.

[xmas79]

I'm not allowed to edit my own post anymore. Adding more info here:

This is the main thread: http://www.talkchess.com/forum/viewtopic.php?t=48274
This is my first debug analysis: http://www.talkchess.com/forum/viewtopi ... 210#525210
This is my last comment on the analysis: http://www.talkchess.com/forum/viewtopi ... 404#527404

I think there are few more comments on the 9 pages of the thread also, but salient points should be found in the linked one posts.

[Ed Trice]

I don't understand why my engine is so slow in finding deep mates. Eventually it finds them but the branching factor for the last ply is WAAAAAY higher...

For your mate test, try this.

1. Full width MiniMax without AlphaBeta or ANY of your search-speed up code.
2. Keep move ordering and sort the scores after each depth.
3. If depth > 7, search the last half of the move list to depth-1 instead of depth (thin razor).
4. Ignore transpositions (no hash table).
5. Record nodes, scores, etc.
6. No Quiescence. Leave anything hanging to be resolved at later nominal depths.

If this Bare Bones implementation outperforms your high branching factor code, you can be pretty sure your hash table bounds did more harm than good by always being out of bounds the deeper you searched. The hash table generated no cutoffs because you need exact scores once mates arrive on the scene.