Feature/fix issue425

[JoshuaGreen]

This is my proposed fix for Issue #425. In that Issue the problem is that when Popeye is run on

BeginProblem
title Popeye 4.85 printed dummies as total invisibles in the solution
author Andrew Buchanan
pieces white kg1 bg7 pf2 duf8 black ka1 pc2d4
Stipulation h#6
Option Intelligent 2 movenum
Condition PromOnly Q R S B DU
EndProblem

line 288 of optimisations/intelligent/mate/generate_doublechecking_moves.c attempts to examine GuardDir[Dummy-Pawn] which, of course, doesn't exist.

This fix abstracts the GuardDir interface, allowing us to easily provide a guard_dir_struct for any piece we may eventually desire, constructed in whatever way is most convenient. (For now, I've only added Dummy, in the way that I feel is appropriate.) This update also allows us to add some asserts so that we can catch similar errors going forward.

Though I believe these changes are worthwhile, and they do eliminate the invalid accesses in the Issue, I do want to mention a few points. That line of code looks for GuardDir[Dummy-Pawn], but no other parts of the code seem to do so. It finds Dummy in pieces_pawns_promotee_sequence[pieces_pawns_promotee_chain_orthodox], which certainly seems odd (to me) as Dummy isn't an orthodox piece. Thus, it's conceivable that Dummy shouldn't be appearing there, that there's a bug elsewhere that's causing this to happen that should be fixed. Someone who better understands this infrastructure should weigh in here.

[thomas-maeder]

Thanks for this fix.

What do you think of simply extending GuardDir to [nr_piece_walks-Pawn] instead?
Or, while we are at it, to [nr_piece_walks] and removing the -Pawn indexing)?

Seems simpler, and would prepare us for extending intelligent mode to more piece types in the future (a constantly requested feature, even if the requests don't agree on what piece types :-) ).

[JoshuaGreen]

There's nothing wrong with either of those alternatives.  Indeed, a big benefit of abstracting the GuardDir interface is that we can implement this however we want while remaining free to change that implementation whenever necessary.  I'll trust your judgment on the most natural fix at this time, keeping possible future updates in mind.