Move ordering considering moving to attacked squares

[cyberfish]

I would imagine this idea has already been thought of and implemented for a long time since the logic is really simple and makes sense (to me at least), but I don't see it documented anywhere (admittedly I haven't read much).

When ordering moves, is it a good idea to order regular (non capture, non promotion, non killer, non table move) moves that move to a square attacked by enemy pieces after other moves?

[hgm]

That might depend on how much effort it takes to determine if the squares are attacked. There are quite strong engines that do not order the 'regular' moves at all, so apparently it is not that important.

Most pepople get a cutoff in cut nodes with the first 3 moves in 98-99% of the cases. Due to normal move ordering it is very likely that these moves are captures or killers. So only in 1-2% of the cases the cut move comes from one of the regular moves. So there is not too much to gain.

[cyberfish]

Ah I see.

I am thinking about using the information in the eval function, too (for mobility, since a knight moving to a square defended by an enemy pawn should not contribute to the mobility of the knight).

[bob]

I would imagine this idea has already been thought of and implemented for a long time since the logic is really simple and makes sense (to me at least), but I don't see it documented anywhere (admittedly I haven't read much).

When ordering moves, is it a good idea to order regular (non capture, non promotion, non killer, non table move) moves that move to a square attacked by enemy pieces after other moves?

The answer is, if you can make your program faster, by searching fewer nodes, then it is a good idea. Not every program has that attacked squares information handy and computing it might cost more than the search space savings.

[sje]

If you have the right bitboards available, the move ordering adjustment is simple and fast. But it's not new; the technique was discussed in the Chess 4.x write-up from thirty years ago.

The three quick adjustments:

1) If the source square is defended, subtract a penalty

2) If the source square is attacked, add a bonus

3) If the destination square is defended, subtract a penalty

The adjustment amounts can be scaled based on the value of the moving piece.

[mcostalba]

If you have the right bitboards available, the move ordering adjustment is simple and fast. But it's not new; the technique was discussed in the Chess 4.x write-up from thirty years ago.

The three quick adjustments:

1) If the source square is defended, subtract a penalty

2) If the source square is attacked, add a bonus

3) If the destination square is defended, subtract a penalty

The adjustment amounts can be scaled based on the value of the moving piece.

I have done a quick test calculating the branch factor with and without the "Penalize moves to attacked squares" idea.

I have not tested with your more refined one. And I have also not play tested, only checked branch factor, so perhaps my tests are not valid, but I don't see a lot of difference, actually neither a small one.

Perhaps if a move is so bad that puts the piece under attack it is already refuted just the next ply by an opponent good capture, so gain is not big.

I have seen that a powerful ordering is the one that avoids (or delays late in the list) moves that are not easy to refute, moves that needs many ply to be refuted.


Marco