Safe mobility?

[jwes]

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?

[AlvaroBegue]

I don't count moves to squares that are covered by an enemy pawn. This is very easy to implement.

I have also tried not counting moves to squares covered by a less-valuable enemy piece, but this did not help in my engine. Still, you may want to try that as a cheap replacement for safe mobility.

[cdani]

Also for queen mobility helps a tiny little to avoid squares attacked by minor/rooks.

[Evert]

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?

If you use bitboards this is not so difficult. Simply calculate mobility in the order from least valuable to most valuable and keep a bitboard of attacked squares for both sides. Safe destination squares are those not (yet) set. With a bit more effort, you can even distinguish squares that are multiple-attacked and do a crude SEE. I don't expect this to be worth much though.

Note that you can in general give safe and unsafe squares different weights, but the latter are not useless.

[Ferdy]

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?

It is indeed expensive, but the point is not only about safe mobility, but you can use now the attack info in other areas like calculation of king safety and threats.

[lucasart]

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.

[Henk]

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 already tried that and applied it recursively say five times. So you see engine placing its pieces on best squares but failing tactically. It would even have been better to only count material. Chess is mainly tactics.

[jwes]

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.

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.

[pkumar]

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

[lucasart]

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

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