Most important eval elements

[bob]

It's impressing to hear how much OilThink gets from mobility. In my engine (Sjakk) I don't get much gain from mobility at all. So I was wondering if anyone could give me some advice on what are the most important factors to have in a mobility evaluation?

Regards
Jacob

We get a modest gain from mobility, but only for knights, bishops and rooks. Any attempt at doing mobility for the queen lowers Elo measurably. We weight the squares a piece can reach based on distance from the center, so that attacking central squares is worth more than attacking squares on the edge of the board.

[Don]

I think what you are saying is not 100% accurate as your evaluation function takes into account free and hanging pawns too, right?

Correct, I mentioned it in my source code, that is the only non-mobil eval. But actually it's an indirect mobility eval. Hanging Pawn can't move, so very bad mobility and free pawn have a good mobility, of course.

I plan to implement it that way and so I have the 100% mobility eval.

Does your program count material? Then it's still not 100% mobility.

It does count material, but it does not use piece square tables. I suspect that for a program this strong, it contains the minimum evaluation.
{snip}

I cleaned up the quoting for everyone here.

Evaluation for chess is as much art as science. I have often dreamed of a simple unifying concept for evaluation, as opposed to scores of separate hacks for different things. Something that could produce a very conceptually clean evaluation function.

For example "preprocessed piece square tables" is a single concept type of eval. It was the secret of really fast programs many years ago - before the search begins, build a set of piece square tables that are "optimized" as much as possible for the current position.

You can simulate mobility, pawn structure, and just about everything with this type of scheme, but only in a very crude way. A "fixed" table has a lot of limitations and cannot adapt to really deep searches where the final position can be so different from the initial position that was used to build the tables from.

I have considered hybrid approaches. One idea I tried and rejected is to have a separate piece square table for each individual pawn structure. The tables could be stored in the pawn structure hash table. However, you lose the benefit of incremental updating - when the pawn structure changes you must reset the score. Then you still have the issue of different game phases - the same pawn structure in the endgame and opening should produce a different evaluation score. Such a scheme is not very cache friendly, but that might not be so much of an issue these days. This is still a compromise scheme but could produce a very conceptually clean evaluation function.

[OliverBr]

We get a modest gain from mobility, but only for knights, bishops and rooks. Any attempt at doing mobility for the queen lowers Elo measurably.

This doesn't make any sense. Of course, an active queen attacking lot of squares is better than a trapped on in the corner of the board.
I guess in your case the mobility for queen conficts with other evaluations and that's why it lowers elo. This is the only logical explanation.

We weight the squares a piece can reach based on distance from the center, so that attacking central squares is worth more than attacking squares on the edge of the board.

This is very important and not implemented in OliThink yet. For Olithink every square has the same importance (not using any square tables). I am wondering if changing that could improve it even more ....

[Dann Corbit]

We get a modest gain from mobility, but only for knights, bishops and rooks. Any attempt at doing mobility for the queen lowers Elo measurably.

This doesn't make any sense. Of course, an active queen attacking lot of squares is better than a trapped on in the corner of the board.
I guess in your case the mobility for queen conficts with other evaluations and that's why it lowers elo. This is the only logical explanation.

We weight the squares a piece can reach based on distance from the center, so that attacking central squares is worth more than attacking squares on the edge of the board.

This is very important and not implemented in OliThink yet. For Olithink every square has the same importance (not using any square tables). I am wondering if changing that could improve it even more ....

Not saying it will happen in a real game:
[d]4k3/2p1p2n/2PpP3/2pBp3/2P1P3/2PQP3/2PKP3/r7 w - -

[Don]

We get a modest gain from mobility, but only for knights, bishops and rooks. Any attempt at doing mobility for the queen lowers Elo measurably.

This doesn't make any sense. Of course, an active queen attacking lot of squares is better than a trapped on in the corner of the board.
I guess in your case the mobility for queen conficts with other evaluations and that's why it lowers elo. This is the only logical explanation.

We weight the squares a piece can reach based on distance from the center, so that attacking central squares is worth more than attacking squares on the edge of the board.

This is very important and not implemented in OliThink yet. For Olithink every square has the same importance (not using any square tables). I am wondering if changing that could improve it even more ....

I think it's more important to not give mobility linear weighting. In Komodo, the first square of mobility for a given piece is better than the second square of mobility, which is better than the third square, etc.

This is important to do because if you have a really good bishop that can get 3 more squares, or a horrible bishop that can get 2 more square, you definitely want to develop the bad bishop.

In this way, the program has a sense of developing all it's pieces, a very important general principle of chess. It's almost always best to have your entire army reasonably developed than to have 2 or 3 pieces really well developed but the others are useless.

This may also explain why queen mobility helps Komodo. It's pretty easy to find mobile squares for the queen instead of developing other pieces. But with Komodo the queen wants to get mobile, but not at the expense of the other pieces. When we went with non-linear mobility we were able to be more aggressive in the mobility scores too. So a "reasonably" well developed piece can now get a higher score.

Bob does mobility by giving different weights to the squares - and I think this has some merit too but it's a different concept. We have focused on the non-linear weighting because it gave a shockingly surprising boost to the strength of the program when we implemented it. The two ideas could of course be combined.

[michiguel]

We get a modest gain from mobility, but only for knights, bishops and rooks. Any attempt at doing mobility for the queen lowers Elo measurably.

This doesn't make any sense. Of course, an active queen attacking lot of squares is better than a trapped on in the corner of the board.
I guess in your case the mobility for queen conficts with other evaluations and that's why it lowers elo. This is the only logical explanation.

We weight the squares a piece can reach based on distance from the center, so that attacking central squares is worth more than attacking squares on the edge of the board.

This is very important and not implemented in OliThink yet. For Olithink every square has the same importance (not using any square tables). I am wondering if changing that could improve it even more ....

I think it's more important to not give mobility linear weighting. In Komodo, the first square of mobility for a given piece is better than the second square of mobility, which is better than the third square, etc.

This is important to do because if you have a really good bishop that can get 3 more squares, or a horrible bishop that can get 2 more square, you definitely want to develop the bad bishop.

In this way, the program has a sense of developing all it's pieces, a very important general principle of chess. It's almost always best to have your entire army reasonably developed than to have 2 or 3 pieces really well developed but the others are useless.

This may also explain why queen mobility helps Komodo. It's pretty easy to find mobile squares for the queen instead of developing other pieces. But with Komodo the queen wants to get mobile, but not at the expense of the other pieces. When we went with non-linear mobility we were able to be more aggressive in the mobility scores too. So a "reasonably" well developed piece can now get a higher score.

Bob does mobility by giving different weights to the squares - and I think this has some merit too but it's a different concept. We have focused on the non-linear weighting because it gave a shockingly surprising boost to the strength of the program when we implemented it. The two ideas could of course be combined.

Absolutely.

In Gaviota, mobility is a function of the number or squares safely attacked. I initialize a table at start up based on that function (that has a big slope at the beginning and saturates later). The effect is that the difference between 0 and 1 is much bigger than 10 and 11. having a function helps because it is easier to tune 3 parameters than dozens (for each square).

The problem with the Queen is that if mobility is not controlled, it will try to develop too early.

Miguel

[jacobbl]

Thanks for a lot of good advice.
I was just wondering when you are counting squares, do you count all the squares or just the safe ones. Do you count a square for a rook if it is controlled by an enemy pawn?

Regards
Jacob

[Don]

Thanks for a lot of good advice.
I was just wondering when you are counting squares, do you count all the squares or just the safe ones. Do you count a square for a rook if it is controlled by an enemy pawn?

Regards
Jacob

Komodo does not count squares attacked by pawns as mobile. It DOES count moves to it's own pieces but not pawns. The mobility stops at the first piece it encounters. It does not count mobility to enemy pawns if they are defended by a pawn, but it counts all other captures.