Finding mate fast

[vladstamate]

Hi,

My program has problems when it is under severe time constraints to find simple mates. For example in the position below it eventually went to lose on time:

[D]8/8/8/6KQ/PP6/4Q3/6k1/8 w - -

This happens when I play very fast game (like a game in 20seconds) and when it reaches this point it only allows itself about 1-2ms. In this case it can only search to a depth of 2 or 3 max.

I do have chess extensions, but what are other ways to indicate that some positions are better than others so that it follows those and eventually to find a mate faster?

I think I saw once (was it Scorpio or Sjeng?) a technique where it counts number of squares that the king can move to that are covered by enemy pieces. Anything else to steer the search?

Regards,
Vlad.

[plattyaj]

I must admit I can't see how it can lose in the above position - it's a mate in 1 with a one ply search ... though I will have to see why it took Schola two plies to find that. It should have seen that ...

In the general case I'm looking at adding some knowledge to Schola to box the king in (simple Rook/King Queen/King mates). I suppose something more general might be useful in the endgame, just to keep the moves in the "right direction".

Andy.

[vladstamate]

(I've updated the position)

It looks like indeed there is a bug in my code. It is a mate in one. I think somehow because I have the chess extension, something goes wrong.

Booo, I should have double checked this twice before making the post.

Regards,
Vlad.

[plattyaj]

(I've updated the position)

It looks like indeed there is a bug in my code. It is a mate in one. I think somehow because I have the chess extension, something goes wrong.

Booo, I should have double checked this twice before making the post.

Regards,
Vlad.

Then I edited my post after you edited the position

And immediately realized that Schola won't find mates in one on ply 1 because it just does a qsearch at that depth and I'm not finding mates in qsearch.

Andy.

[Dann Corbit]

Chest solved it in one node. I guess it performed like the GM who said, "I only consider one move - the right one."

8/8/8/6KQ/PP6/4Q3/6k1/8 w - - acn 1; acs 0; bm Qhh3#; ce 32766; dm 1; pv Qhh3#;

[vladstamate]

Hi,

Yes, my problem was also that I could not find mates in one. It kept finding mates in 3 and eventually run out of time. It is fixed now.

Regards,
Vlad.

[Fguy64]

(I've updated the position)

It looks like indeed there is a bug in my code. It is a mate in one. I think somehow because I have the chess extension, something goes wrong.

Booo, I should have double checked this twice before making the post.

Regards,
Vlad.

Then I edited my post after you edited the position

And immediately realized that Schola won't find mates in one on ply 1 because it just does a qsearch at that depth and I'm not finding mates in qsearch.

Andy.

pardon if this is too basic, but I don't follow you. Perhaps this is semantics, but doesn't mate in 1 require 2-ply? One ply for the mating move, and one ply to determine that black has no legal responses?

In my program, mate is not determined by Evaluate(), it is determined
only after possibleMoves returns and empty list, after which isSquareAttackeded() is used on the king position to determine either checkmate or stalemate.

[plattyaj]

pardon if this is too basic, but I don't follow you. Perhaps this is semantics, but doesn't mate in 1 require 2-ply? One ply for the mating move, and one ply to determine that black has no legal responses?

In my program, mate is not determined by Evaluate(), it is determined
only after possibleMoves returns and empty list, after which isSquareAttackeded() is used on the king position to determine either checkmate or stalemate.

Fred, you're correct but whether a one ply search searches to one ply or more depends on the engine. In Schola if it *did* call alpha-beta it would find it even in a one ply search because it would extend one ply due to the check, find there were no replies to the check and return a mate score.

But it doesn't because there's not enough remaining depth so it calls qsearch which, in Schola, doesn't look for checks. Yes that can lead to illegal positions in the search - as usual it's trade offs all the way down.

Another engine (presumably Chest) might try and find all check evasions as part of evaluation and return mate score from there.

So it depends.

Andy.

[Uri Blass]

(I've updated the position)

It looks like indeed there is a bug in my code. It is a mate in one. I think somehow because I have the chess extension, something goes wrong.

Booo, I should have double checked this twice before making the post.

Regards,
Vlad.

Then I edited my post after you edited the position

And immediately realized that Schola won't find mates in one on ply 1 because it just does a qsearch at that depth and I'm not finding mates in qsearch.

Andy.

pardon if this is too basic, but I don't follow you. Perhaps this is semantics, but doesn't mate in 1 require 2-ply? One ply for the mating move, and one ply to determine that black has no legal responses?

In my program, mate is not determined by Evaluate(), it is determined
only after possibleMoves returns and empty list, after which isSquareAttackeded() is used on the king position to determine either checkmate or stalemate.

I believe that no strong program does what you do.
chess programs usually extend checks and in order to extend checks you need to know if a move is checking move or not checking move.

In other words the first thing that you should do after making a move in the search is checking if the move gives a check(in this case you may want to extend).

You also do not need to use expensive function like isSquareAttacked for it and it is better to use the last move in order to save time.

Chess programs usually find mates in depth 1 even in the case that they do not have mate detection in their evaluation function for the simple reason that if the first move is check then they extend.

I prefer to have a special function for mate detection even before evaluating the position so practically I can detect mates in ply 1 even in cases that I do not extend checks(and I do not extend checks for cases when the side that gives the check has a very big material advantage).

Uri

[Fguy64]

(I've updated the position)

It looks like indeed there is a bug in my code. It is a mate in one. I think somehow because I have the chess extension, something goes wrong.

Booo, I should have double checked this twice before making the post.

Regards,
Vlad.

Then I edited my post after you edited the position

And immediately realized that Schola won't find mates in one on ply 1 because it just does a qsearch at that depth and I'm not finding mates in qsearch.

Andy.

pardon if this is too basic, but I don't follow you. Perhaps this is semantics, but doesn't mate in 1 require 2-ply? One ply for the mating move, and one ply to determine that black has no legal responses?

In my program, mate is not determined by Evaluate(), it is determined
only after possibleMoves returns and empty list, after which isSquareAttackeded() is used on the king position to determine either checkmate or stalemate.

I believe that no strong program does what you do.
chess programs usually extend checks and in order to extend checks you need to know if a move is checking move or not checking move.

In other words the first thing that you should do after making a move in the search is checking if the move gives a check(in this case you may want to extend).

You also do not need to use expensive function like isSquareAttacked for it and it is better to use the last move in order to save time.

Chess programs usually find mates in depth 1 even in the case that they do not have mate detection in their evaluation function for the simple reason that if the first move is check then they extend.

I prefer to have a special function for mate detection even before evaluating the position so practically I can detect mates in ply 1 even in cases that I do not extend checks(and I do not extend checks for cases when the side that gives the check has a very big material advantage).

Uri

When I was designing, I thought about stuff like that, about is square attacked being expensive, but I eventually decided that since it was only called when possible moves returned a list of size 0, it wasn't really an issue. But I'll keep your comment in mind as I re-evaluate my methods.

Duly noted about a special function for mate. I'll have to think on this.

It is almost as if my my program finds mate by accident, but i was pleased to be able to detect forced mates as part of the normal course of the algorithm, which at each ply determined possible moves first. I was thinking that as soon as i would start making "separate efforts" to find mate, then things would become innefficient by virtue of the fact there is no mate in the vast majority of normal situations. But as I refine things, I'll be considering these points.