2 Dh5?

Discussion of chess software programming and technical issues.

Moderator: Ras

Sven
Posts: 4052
Joined: Thu May 15, 2008 9:57 pm
Location: Berlin, Germany
Full name: Sven Schüle

Re: 2 Dh5?

Post by Sven »

Gerd Isenberg wrote:
Henk wrote: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
Posts: 2251
Joined: Wed Mar 08, 2006 8:47 pm
Location: Hattingen, Germany

Re: 2 Dh5?

Post by Gerd Isenberg »

Sven Schüle wrote:
Gerd Isenberg wrote:
Henk wrote: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
Posts: 2251
Joined: Wed Mar 08, 2006 8:47 pm
Location: Hattingen, Germany

Re: 2 Dh5?

Post by Gerd Isenberg »

Sven Schüle wrote:
Gerd Isenberg wrote:
Henk wrote: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
Posts: 3241
Joined: Mon May 31, 2010 1:29 pm
Full name: lucasart

Re: 2 Dh5?

Post by lucasart »

Gerd Isenberg wrote:
Sven Schüle wrote:
Gerd Isenberg wrote:
Henk wrote: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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
Gerd Isenberg
Posts: 2251
Joined: Wed Mar 08, 2006 8:47 pm
Location: Hattingen, Germany

Re: 2 Dh5?

Post by Gerd Isenberg »

lucasart wrote: 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
Posts: 7251
Joined: Mon May 27, 2013 10:31 am

Re: 2 Dh5?

Post by 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
Posts: 2251
Joined: Wed Mar 08, 2006 8:47 pm
Location: Hattingen, Germany

Re: 2 Dh5?

Post by Gerd Isenberg »

Henk wrote: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
Posts: 7251
Joined: Mon May 27, 2013 10:31 am

Re: 2 Dh5?

Post by Henk »

Gerd Isenberg wrote:
Henk wrote: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
Posts: 3241
Joined: Mon May 31, 2010 1:29 pm
Full name: lucasart

Re: 2 Dh5?

Post by lucasart »

Gerd Isenberg wrote:
lucasart wrote: 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)).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
Henk
Posts: 7251
Joined: Mon May 27, 2013 10:31 am

Re: 2 Dh5?

Post by Henk »

lucasart wrote:
Gerd Isenberg wrote:
lucasart wrote: 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.