2 Dh5?

[Sven]

My chess program uses an evaluation with Mobility(=MoveCount), KingSafety and MaterialCount only.

Now he playes e4, e5, Dh5 ?

What can I do about this.

A common term is a penalty for too early queen development related to the number of none developed light pieces (knights and bishops), i.e. something like this:

Code: Select all

tooEarlyQueenPenalty = max(1, distance[d1][qSq]) * max(0, 3-nNoneDevLight);

Hi Gert,

shouldn't it be:

Code: Select all

tooEarlyQueenPenalty = distance[d1][qSq] * max(0, nNoneDevLight-3);

which will set the penalty for the white queen to its distance to d1 if no white bishop or knight has been developed yet? I think your first "max" is not necessary since it would result in a penalty of 1 even if the queen has not been developed as well.

Sven

[Gerd Isenberg]

My chess program uses an evaluation with Mobility(=MoveCount), KingSafety and MaterialCount only.

Now he playes e4, e5, Dh5 ?

What can I do about this.

A common term is a penalty for too early queen development related to the number of none developed light pieces (knights and bishops), i.e. something like this:

Code: Select all

tooEarlyQueenPenalty = max(1, distance[d1][qSq]) * max(0, 3-nNoneDevLight);

Hi Gert,

shouldn't it be:

Code: Select all

tooEarlyQueenPenalty = distance[d1][qSq] * max(0, nNoneDevLight-3);

which will set the penalty for the white queen to its distance to d1 if no white bishop or knight has been developed yet? I think your first "max" is not necessary since it would result in a penalty of 1 even if the queen has not been developed as well.

Sven

Oups, i meant bonus for keeping the queen close to her home

[Gerd Isenberg]

My chess program uses an evaluation with Mobility(=MoveCount), KingSafety and MaterialCount only.

Now he playes e4, e5, Dh5 ?

What can I do about this.

A common term is a penalty for too early queen development related to the number of none developed light pieces (knights and bishops), i.e. something like this:

Code: Select all

tooEarlyQueenPenalty = max(1, distance[d1][qSq]) * max(0, 3-nNoneDevLight);

Hi Gert,

shouldn't it be:

Code: Select all

tooEarlyQueenPenalty = distance[d1][qSq] * max(0, nNoneDevLight-3);

which will set the penalty for the white queen to its distance to d1 if no white bishop or knight has been developed yet? I think your first "max" is not necessary since it would result in a penalty of 1 even if the queen has not been developed as well.

Sven

Yes, I don't want to penelize Qc2. Should be number of developed pieces this way around. Sorry for the confusion

Code: Select all

tooEarlyQueenPenalty = max(0, distance[d1][qSq] - 1) * max(0, 3-nDevLight);

[lucasart]

My chess program uses an evaluation with Mobility(=MoveCount), KingSafety and MaterialCount only.

Now he playes e4, e5, Dh5 ?

What can I do about this.

A common term is a penalty for too early queen development related to the number of none developed light pieces (knights and bishops), i.e. something like this:

Code: Select all

tooEarlyQueenPenalty = max(1, distance[d1][qSq]) * max(0, 3-nNoneDevLight);

Hi Gert,

shouldn't it be:

Code: Select all

tooEarlyQueenPenalty = distance[d1][qSq] * max(0, nNoneDevLight-3);

which will set the penalty for the white queen to its distance to d1 if no white bishop or knight has been developed yet? I think your first "max" is not necessary since it would result in a penalty of 1 even if the queen has not been developed as well.

Sven

Yes, I don't want to penelize Qc2. Should be number of developed pieces this way around. Sorry for the confusion

Code: Select all

tooEarlyQueenPenalty = max(0, distance[d1][qSq] - 1) * max(0, 3-nDevLight);

That sounds like a very bad idea. So you suggest:
* a stupid mobility that incentivises the queen to come out early
* a corrective term that penalizes the queen for coming out early

Now you have *two* terms that are *correlated*, and hence very hard to tune. what makes much more sense is to have a better mobility.

what I do is simply to score mobility less in the opening than in the endgame for the queen. my mobility is just a good old Fruit-style centered linear mobility

Code: Select all

[nb_squares ag_nb_sq(piece)] * weight(opening/endgame, piece)

And of course, weight(endgame, queen) > weight(opening, queen).

How to count the the number of squares is also very important. My testing results show that:
* you should exclude squares attacked by enemy pawns
* you should also exclude squares occupied by your own pawns
This is somewhat better in testing than the Fruit counting.

I tried many other variations (looking at up attacks, or squares occupied by own pieces, trying to score forward and backward mobility differently) never worked.

[Gerd Isenberg]

That sounds like a very bad idea. So you suggest:
* a stupid mobility that incentivises the queen to come out early
* a corrective term that penalizes the queen for coming out early

Now you have *two* terms that are *correlated*, and hence very hard to tune. what makes much more sense is to have a better mobility.

what I do is simply to score mobility less in the opening than in the endgame for the queen. my mobility is just a good old Fruit-style centered linear mobility

Code: Select all

[nb_squares ag_nb_sq(piece)] * weight(opening/endgame, piece)

And of course, weight(endgame, queen) > weight(opening, queen).

How to count the the number of squares is also very important. My testing results show that:
* you should exclude squares attacked by enemy pawns
* you should also exclude squares occupied by your own pawns
This is somewhat better in testing than the Fruit counting.

I tried many other variations (looking at up attacks, or squares occupied by own pieces, trying to score forward and backward mobility differently) never worked.

May be, specially if you rely on the opening book. I did not mention general queen mobility. A too early queen term is not my idea but is/was common in several chess programs, i.e. Bartel/Kraas/Schrüfer pp 237, which in the 90s was the bible of German chess programmers:

Code: Select all

if ( rank(qSq) > 1 ) // > second rank
   eval -= 2.5 * number of none developed pieces.

Is it outdated?

[Henk]

I still don't know whether mobility should use number of legal moves or number of all moves. Last one can be pre-computed so it's very fast. If I use a mobility that counts only legal moves my chess program seems to play (much) better, but this mobility is a speed bottleneck that makes the program only reach shallow depths.

So I need a pseudo mobility that can be computed very fast and represents (estimates) real or actual mobility.

[Gerd Isenberg]

I still don't know whether mobility should use number of legal moves or number of all moves. Last one can be pre-computed so it's very fast. If I use a mobility that counts only legal moves my chess program seems to play (much) better, but this mobility is a speed bottleneck that makes the program only reach shallow depths.

So I need a pseudo mobility that can be computed very fast and represents (estimates) real or actual mobility.

May be only piece square table, and ignoring queen mob at all - if she has at least one safe square and is not trapped? May be, dependent on your infrastructure, some important square controls of center and near opponent king weighted 1/3/5 or similar for queen/rook/minor control. A pinned or attacked queen is likely a matter of tactics (search, qsearch). Black art of evaluation has no definite answer.

[Henk]

I still don't know whether mobility should use number of legal moves or number of all moves. Last one can be pre-computed so it's very fast. If I use a mobility that counts only legal moves my chess program seems to play (much) better, but this mobility is a speed bottleneck that makes the program only reach shallow depths.

So I need a pseudo mobility that can be computed very fast and represents (estimates) real or actual mobility.

May be only piece square table, and ignoring queen mob at all - if she has at least one safe square and is not trapped? May be, dependent on your infrastructure, some important square controls of center and near opponent king weighted 1/3/5 or similar for queen/rook/minor control. A pinned or attacked queen is likely a matter of tactics (search, qsearch). Black art of evaluation has no definite answer.

I think I need to re-introduce piece square table again. Otherwise I loose to much speed during evaluation. Maybe I should update piece square table during search at some points to prevent that this information gets useless.

Checking safe squares sounds expensive to me.

[lucasart]

That sounds like a very bad idea. So you suggest:
* a stupid mobility that incentivises the queen to come out early
* a corrective term that penalizes the queen for coming out early

Now you have *two* terms that are *correlated*, and hence very hard to tune. what makes much more sense is to have a better mobility.

what I do is simply to score mobility less in the opening than in the endgame for the queen. my mobility is just a good old Fruit-style centered linear mobility

Code: Select all

[nb_squares ag_nb_sq(piece)] * weight(opening/endgame, piece)

And of course, weight(endgame, queen) > weight(opening, queen).

How to count the the number of squares is also very important. My testing results show that:
* you should exclude squares attacked by enemy pawns
* you should also exclude squares occupied by your own pawns
This is somewhat better in testing than the Fruit counting.

I tried many other variations (looking at up attacks, or squares occupied by own pieces, trying to score forward and backward mobility differently) never worked.

May be, specially if you rely on the opening book. I did not mention general queen mobility. A too early queen term is not my idea but is/was common in several chess programs, i.e. Bartel/Kraas/Schrüfer pp 237, which in the 90s was the bible of German chess programmers:

Code: Select all

if ( rank(qSq) > 1 ) // > second rank
   eval -= 2.5 * number of none developed pieces.

Is it outdated?

Yes:
(i) it violates the good principles explained by Tord here (that many beginners should read carefully before coding an eval)
http://chessprogramming.wikispaces.com/ ... Philosophy
(ii) it's typically a "shallow" eval term that attempts to mitigate the horizon effect. Such terms rarely scale well, and while they may have been good 20+ years ago, today they are harmful with engines reaching extraordinary search depths.

When it comes to the eval, before adding anything, we should always remember that:
* search is knowledge (ie. work on the search before working on the eval. or fix your first order problem before tackling your second order problem).
* less is more (a consequence of (i) and (ii)).

[Henk]

That sounds like a very bad idea. So you suggest:
* a stupid mobility that incentivises the queen to come out early
* a corrective term that penalizes the queen for coming out early

Now you have *two* terms that are *correlated*, and hence very hard to tune. what makes much more sense is to have a better mobility.

what I do is simply to score mobility less in the opening than in the endgame for the queen. my mobility is just a good old Fruit-style centered linear mobility

Code: Select all

[nb_squares ag_nb_sq(piece)] * weight(opening/endgame, piece)

And of course, weight(endgame, queen) > weight(opening, queen).

How to count the the number of squares is also very important. My testing results show that:
* you should exclude squares attacked by enemy pawns
* you should also exclude squares occupied by your own pawns
This is somewhat better in testing than the Fruit counting.

I tried many other variations (looking at up attacks, or squares occupied by own pieces, trying to score forward and backward mobility differently) never worked.

May be, specially if you rely on the opening book. I did not mention general queen mobility. A too early queen term is not my idea but is/was common in several chess programs, i.e. Bartel/Kraas/Schrüfer pp 237, which in the 90s was the bible of German chess programmers:

Code: Select all

if ( rank(qSq) > 1 ) // > second rank
   eval -= 2.5 * number of none developed pieces.

Is it outdated?

Yes:
(i) it violates the good principles explained by Tord here (that many beginners should read carefully before coding an eval)
http://chessprogramming.wikispaces.com/ ... Philosophy
(ii) it's typically a "shallow" eval term that attempts to mitigate the horizon effect. Such terms rarely scale well, and while they may have been good 20+ years ago, today they are harmful with engines reaching extraordinary search depths.

When it comes to the eval, before adding anything, we should always remember that:
* search is knowledge (ie. work on the search before working on the eval. or fix your first order problem before tackling your second order problem).
* less is more (a consequence of (i) and (ii)).

The more material the more mobility. So they are dependent. Should I remove mobility or materialCount or both.