Safe mobility?

[Evert]

That is part of my question. I don't know if safe mobility is good. I do know that my current mobility is not good, and that my program often loses to programs it outsearches by having pieces trapped and not seeing the capture in time.

My engine "Nameless" uses attack maps similar to those in Ed Schroeder's tutorials. It finds piece-wise raw mobility first. If that is below a threshold then it finds safe mobility for the piece. If safe mobility <=1 && safe mobility<raw mobility then the piece is considered trapped and penalized depending upon piece type, safe mobility and location. This obviates special code for trapped bishop etc. This seems common sense, but the engine is too weak for measurement of minor Elo gain at present.

Regards

If the engine is too weak to measure such tiny Elo gains (which shouldn't be true if it's any gain at all, actually, but I suppose you mean it takes a long time to get a statistically significant result), that should tell you that you need to focus on more basic (and boring) evaluation terms first...

[pkumar]

Relying on "common sense", rather then measuring and adopting the scientific method: that's exactly where the difference lies between amateur and strong engines…

Fully agreed. Since the engine is weak, avoiding simple traps seems to be among the first things to do and my engine does it reasonably well. I may cull "common sense" code if the engine becomes strong enough.

Regards

[pkumar]

If the engine is too weak to measure such tiny Elo gains (which shouldn't be true if it's any gain at all, actually, but I suppose you mean it takes a long time to get a statistically significant result), that should tell you that you need to focus on more basic (and boring) evaluation terms first...

Yes, tiny improvements may be hard to detect in presence of other serious weaknesses. I think the evaluation is OK for a weak engine - at least it can distinguish between good and bad positions (as shown by static evaluation components). Search needs a huge improvement. Perhaps measuring small gains would be worthwhile if the engine ever reaches 2800 Elo. It falls short by about 250.

Regards

[ZirconiumX]

Relying on "common sense", rather then measuring and adopting the scientific method: that's exactly where the difference lies between amateur and strong engines…

Fully agreed. Since the engine is weak, avoiding simple traps seems to be among the first things to do and my engine does it reasonably well. I may cull "common sense" code if the engine becomes strong enough.

Regards

Sadly I have found that it is the very act of culling "common sense" code that makes an engine "strong enough".

Lucas is right, and my own experience has borne this out; but I don't think I know what the right tool for the job (such as fixed depth/fixed nodes testing) is often enough to efficiently test.

I suppose while I'm here: I'm sorry Lucas and Daniel (Shawul) for how I acted five years ago. I've come a long way since then.

[Uri Blass]

I was looking at changing my very crude mobility calculation to safe mobility, but it looks very expensive. To do it correctly would seem to require doing a SEE on every square that can be moved to. Do people have quicker ways of doing this or approximations that have most of the benefit of full safe mobility?

Why do you think it is more correct to exclude squares defended by lesser pieces? It's incredible the amount of things that seem logical, but dont work in testing. Start by implementing it, expensively, and messure it at fixed depth and/or nodes testing. If it doesn't even gain elo without accounting for the slowdown, it's going to be a regression with the slowdown accounted for. You will be surprised at the result. I bet it will fail even w/o accounting for the slowdown.

I do not think that excluding defended squares is logical and never thought that it is logical.

Being able to move to these squares if the opponent make a move that remove the defence is an advantage.

Attacking defended pieces is often an advantage that help to find simple tactics.

The piece is defended but later you make a move that attack the defender so the opponent may choose between losing the defender and losing the piece that the defender defends(if the defender move to save itself).

[hgm]

That raises an issue I often wondered about: is it really mobility that is important, or square control? These are similar, but not quite the same. If I aim a Knight at a square the opponent attacks with a Pawn, it cannot actually go therem but it still interdicts the square to opponent Queens and Rooks, and allows 'cheap removal' of any minor the opponent would put there.

The lower the value of the attacker, the larger the number of piece types for which it interdicts the squares it attacks, and thus the more valuable the attack. Indeed lower-valued pieces typically get their mobility weights tuned to larger values. This is often explained by the fact that these pieces tend to have fewer moves, so that extra moves are of relatively larger importance. But one could wonder if that is the correct explanation. It would be interesting to test what the optimal mobility weights would be for a piece that has hight value, but few moves. E.g. because it is a divergent piece, with (say) captures like Queen, but moves only one step diagonally. Such a piece should be worth ~6.5 (Q=9), but it usually would have very few legal moves. And the captures amongst those would usually be losing, as the opponent would not leave his pieces up for grabs, so that safe mobility would even be lower. Would it be very important in that case to optimize its number of non-captures (mobility gets high weight), or would it be important to optimize the number of empty squares it attacks (interdiction).

Another case in point would be a piece that derives its high value from a latent property, such as a hefty promotion in the end-game. E.g. a Bishop that would turn into a Queen on reaching last rank. Would it have the same optimum moblity weight as a normal Bishop? You would probably not be willing to trade it even for a Rook, so it doesn't really contribute much to interdicting access of opponent pieces to the squares it covers.

[Evert]

You cannot disentangle square control and mobility for a normal chess engine, so you lump them together. If I had to guestimate, I would give a relative weight of 2 for squares that are attacked compared to squares that can be moved to, similar to how these affect piece value.
In a regular chess engine, this works out to giving a somewhat lower value to squares that are not "safe".

It makes some sense to at least distinguish:
1. Empty squares that can be safely moved to (not defended)
2. Empty squares that can be safely moved to (inadequately defended)
3. Empty squares that cannot be safely moved to (well defended, SEE<0)
4. Squares occupied by enemy pieces (the inadequately defended ones should be weeded out by qsearch)
5. Squares occupied by your own pieces (further distinguish between more valuable and less valuable, perhaps pawns as well)
6. X-ray attacks through a mobile friendly piece.
7. X-ray attacks through an enemy piece.

And then you can still weigh squares differently depending on the zone of the board, king tropism, the presence of weak pawns and game phase, although you normally don't do that as part of the mobility calculation.

Are all of those distinctions useful? Perhaps not. It would be interesting to tune a very general evaluation function that allows for all of those categories and see what distinctions are useful and what concepts are superfluous. Lot of work though.

[hgm]

You cannot disentangle square control and mobility for a normal chess engine, so you lump them together.

I don't think that is entirely true. Like you could correct mobility for moves to squares attacked by a lower piece of the opponent, you could correct square control by ignoring moves to squares already attacked by a lower piece of yourself.

This is not entirely taken care of by eliminating the contribution of enemy moves to those squares interdicted by having SEE < 0. It might be useful to control squares that are not attacked at all, just to make sure the opponent cannot create a threat by attacking them.

[cdani]

To abundate on how one can ellaborate more all this, I obtained a little win by penalizing a bit minors that cannot go to rival's half.