Problem #8546

[roq]

I wonder if the system should exclude (or credit) problems with ambiguous mates that are say one or two moves longer than the actual solution? For instance:

the solution to #8546 is:

1. Kh7 Rc7 2. Ke8  3.Rc8#

An alternative is:

1. Rh7 Kg8 2. e7 Rf8 3. Rh8+  Kxh8 4. exf8=Q#

The point is of course that when one has found a mate then it doesn't make much sense to look for another one...

I think one should probably be expected to find one and two move mates though!


     
 

[richard]

Ideally I'd like to be able to give at least partial credit for longer mates. I think there is still a justifiable argument that the shorter mate is more aesthetically pleasing, but I acknowledge that at the end of the day, a mate is a mate.

Unfortunately it is not really computationally feasible to do this at the moment. Currently the system deems only mates of equal length to be ambiguous and therefore discarded.  To do this only requires me to look at the 2 best moves in any position.  To find all the moves that may lead to mate from the current position explodes the amount of time required to process problems dramatically.  If it wasn't for the 50 move rule it would be an unsolvable problem in the most general case as some positions allow cycles of moves extending the mating sequence to arbitrary lengths. Some heuristics could be used where you decide you are only interested in the mates that occur up to N moves longer than the shortest mate.  However such a choice seems a little inelegant and might leave the user asking, well my longer mate in N was allowed yesterday, why not N+1? etc.

Exclusion is possible as I can just throw away all positions whose second best move is also a mate. I'm concerned that this would throw too many interesting problems away.  I'm still doing a new problem generation run at the moment. When that is finished and the results uploaded I plan to do an experimental verification run where I see how many problems I would have left if I threw all of those types of problems away. I'm also planning to look at a similar experiment where I see what is left if I also throw away mates whose second best move is not mate but is more than a certain cutoff better than the current position.  Together both experiments run at once could tell me how many mating positions I'd have to kill to avoid not only positions with longer mates but also positions with the "I missed the mate in N but found a Queen sack and still got marked wrong" problem.

Regards,
Richard.

[roq]

I can see that it’s a tricky problem for you. I remember you said in a earlier post that you would like to generate a greater number of harder problems and of course many of the problems that have multiple mates or possible lines are the more difficult ones so you would be throwing a higher % of these away.

I can’t imagine that there is any possible way to write an algorithm that would perfectly select only the most elegant problems – you’d have to program the computer to have a sort of human like aesthetic sense (if you can do that please let me know how!). But maybe instead of  being such a perfectionist and looking for possible 50 move cyclic mates you could use some more simple, seat of the pants, rules that would work in 99% of cases. Just a suggestion, but you might do something like this:

-   If it’s a one or two move mate you must find it precisely - no alternative longer lines or material wins would be considered correct.
-   If it’s a three / four / five move mate, any problems with ambiguos mates two or less moves later are rejected (or credited). Problems with ambiguos material wins >= 5 (ie a rook) would also be rejected / credited if they occur earlier than two moves before the mate.
-   If it’s a longer mate, problems with ambiguos mates within three moves would be rejected (creditied). Problems with ambiguos material wins >= 3 would also be rejected (credited) if they occur earlier than two moves before mate (as before). 

From my experience (growing daily!) that set of rules would have been good for all the ambiguos mate problems I’ve encountered so far and has some sort of aesthetic justification if you look at the kind of comments masters make in chess books when a player doesn’t choose the most precise line (for instance if you choose a complex twenty move mate over a simple mate in one, the master might affix a ?? to the move, but preferring a five move mate to a four move one hardly merits a comment). If you put the rules in the faq, people (or at least those who read faqs) would know what to expect, but in any case it would be pretty transparent.

[richard]

Hi Roq,

I think that is a useful set of heuristics, you could argue for exactly where the thresholds should be, but overall I think it sounds reasonable.  There are still some computational difficulties with some aspects. For example if there is say a mate in 5 , a mate in 15 and a queen sack in 2, if I stick to looking at the 2 best moves I'll miss the queen sack as the chess engine will always prefer the 15 move mate over the queen sack.  This might be fixable by tweaking the chess engine's priorities but then I lose chess engine independence which has been handy to have in the past.  I could start looking at the 3 best moves which would fix that particular issue but not the mate in 5, mate in 15, mate in 20, queen sack in 2 etc.  An alternative would be to say that we only look at 2 best and this means we don't catch everything (like the queen sacks above), however I think its important that the criteria are such that they can be applied consistently across all positions.

Anyways, that is only one aspect of your suggestion, other aspects should certainly be achievable.  I'm still planning to do the experiment I mentioned in my last post. It might turn out that the collateral damage of a stricter rejection policy is not as bad as I expect so we can implement a simpler rejection policy that would reject all the situations your heuristic would (as well as a few others that we'd prefer to leave in, but as long as this number is small enough we can afford to pay the cost, it just takes longer to make the problem database larger).

On reflection I shouldn't be that worried about throwing away "hard problems" in this process. If problems are hard because users are choosing viable alternatives instead of the anointed "best move" then they should be thrown out. 

It is unlikely I'll get to this before Christmas but I'll let you know how things go.  The next problem set update will likely be the last one with the current problem generator and hopefully I can integrate some of the ideas thrown around in this thread (and others) into an updated generator.

Regards,
Richard.