eval in crafty 20.9

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

eval in crafty 20.9

Postby Giuseppe Cannella » 08 Jun 2006, 09:58

on crafty 20.9
i've add the below code at line 312 of option.c file, so the new "eval" command disply the static evaluation of actual position; the result on initial position is 24, but must be 0!! where is the problem?

thank you
.
.
else if (!strcmp("eval", *args)) {
int value;
value = Evaluate(tree, 1, 0, -2147483647, 2147483647);
printf("\n%d\n",value);
}
/*
************************************************************
* *
* "bookw" command updates the book selection weights. *
* *
************************************************************
*/
.
.
Giuseppe Cannella
 
Posts: 5
Joined: 20 Mar 2006, 10:08
Location: Milan, Italy

Re: eval in crafty 20.9

Postby Tord Romstad » 08 Jun 2006, 10:22

geko wrote:on crafty 20.9
i've add the below code at line 312 of option.c file, so the new "eval" command disply the static evaluation of actual position; the result on initial position is 24, but must be 0!! where is the problem?


Why do you think there is a problem? An advantage of +0.24 for white in the opening position does not seem unreasonable. Glaurung evaluates the same position as +0.16, for what it's worth.

Most programs have a small bonus for the side to move in their evaluation function. I suppose Crafty has such a bonus, too.

Tord
User avatar
Tord Romstad
 
Posts: 639
Joined: 09 Oct 2004, 12:49
Location: Oslo, Norway

Re: eval in crafty 20.9

Postby Uri Blass » 08 Jun 2006, 10:47

Tord Romstad wrote:
geko wrote:on crafty 20.9
i've add the below code at line 312 of option.c file, so the new "eval" command disply the static evaluation of actual position; the result on initial position is 24, but must be 0!! where is the problem?


Why do you think there is a problem? An advantage of +0.24 for white in the opening position does not seem unreasonable. Glaurung evaluates the same position as +0.16, for what it's worth.

Most programs have a small bonus for the side to move in their evaluation function. I suppose Crafty has such a bonus, too.

Tord


It is not unreasonable but I am not sure about most programs.
I do not have a bonus for the side to move in my evaluation because the last time that I tested it I could not prove that it is productive for playing strength.

Note that my evaluation of passed pawns is dependent on the side to move in some cases but I have no general bonus for the side to move.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: eval in crafty 20.9

Postby Guenther Simon » 08 Jun 2006, 13:10

geko wrote:on crafty 20.9
i've add the below code at line 312 of option.c file, so the new "eval" command disply the static evaluation of actual position; the result on initial position is 24, but must be 0!! where is the problem?


The problem is in your thinking. Why do you think that White
makes around 54% in average?

...Moderation stuff removed by moderator. Volker
Guenther
User avatar
Guenther Simon
 
Posts: 794
Joined: 26 Sep 2004, 19:49
Location: Regensburg, Germany

Re: eval in crafty 20.9

Postby bob » 08 Jun 2006, 17:51

First, there is a "score" command that does just that, plus it breaks the score down by piece types as well...

Second, there is a bug in bishop scoring. I am looking at it right now. It likes black's bishops better than whites, which means something slipped in. Since my eval is 100% symmetric, 0 is the right score with identical piece locations for each side.

I'll post the fix when I find it, and 20.14 will be corrected...
User avatar
bob
 
Posts: 156
Joined: 10 May 2006, 17:59

Re: eval in crafty 20.9

Postby bob » 08 Jun 2006, 18:04

Here is the fix. In EvaluateBishops() (evaluate.c) look for the black bishop scoring code, then look for the section on "bad bishops" and make it look like this:

if (SetMask(square) & mask_corner_a8)
score += PopCnt(minus7dir[square] & BlackPawns) * bishop_bad;
else if (SetMask(square) & mask_corner_h8)
score += PopCnt(minus9dir[square] & BlackPawns) * bishop_bad;


Your version has WhitePawns in both of those and it is wrong. This has been in there since we started doing this term so it was a serious bug for the black side... glad you noticed it. I occasionally run symmetry tests which would have caught this, but I have not recently...
User avatar
bob
 
Posts: 156
Joined: 10 May 2006, 17:59

Re: eval in crafty 20.9

Postby Robert Allgeuer » 09 Jun 2006, 19:38

Why would one expect a positive effect of scoring the right to move?
Is it really true that the right to move in a leaf node has a significance for the overall evaluation score of the root move? Isn?t it more just a coincidence based on extensions, whether a specific line is followed up to an odd or even depth?

Robert
Robert Allgeuer
 
Posts: 124
Joined: 28 Sep 2004, 19:09
Location: Konz / Germany

Re: eval in crafty 20.9

Postby Uri Blass » 09 Jun 2006, 19:50

Robert Allgeuer wrote:Why would one expect a positive effect of scoring the right to move?
Is it really true that the right to move in a leaf node has a significance for the overall evaluation score of the root move? Isn?t it more just a coincidence based on extensions, whether a specific line is followed up to an odd or even depth?

Robert


The right to move is usually better in chess.

If you get 2 leaf positions that are the same except the side to move then it is clear that you should evaluate white to move as better for white.

I think that bonus for the side to move should be given only when the opponent does not have a threat of check or a threat of good capture because these type of positions are not going to be evaluated as leaf positions when the side that has the threat is to move.

This is nice in theory but the problem is to test it and prove that it works because if the bonus for the side to move is too high it is bad and if the bonus for the side to move is too small then it is possible that being slower is going to cause more demage then the advantage from better evaluation.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: eval in crafty 20.9

Postby Tord Romstad » 09 Jun 2006, 20:23

Robert Allgeuer wrote:Why would one expect a positive effect of scoring the right to move?
Is it really true that the right to move in a leaf node has a significance for the overall evaluation score of the root move? Isn?t it more just a coincidence based on extensions, whether a specific line is followed up to an odd or even depth?


You seem to be confused. We are talking about the static evaluation only, and this is completely unrelated to the search, extensions, odd or even depths (well, this is not entirely true, because some programs have an asymmetric eval, but let's not get carried away), and so on. The static evaluation function is how the program evaluates the position without search.

Consider the situation where the same position occurs at two leaf nodes, with one exception: In the first case, it is the computer's turn to move, while in the second case, it is the opponent's move. Most (or at least some) programs will evaluate the first leaf node as better (from the computer's point of view) than the second. In the vast majority of chess positions, having the move is better than not having the move, which means that it makes sense to include a small side to move bonus in the evaluation function.

Of course there are exceptions - positions where having the side to move is unimportant, or even a disadvantage (i.e. zugzwang positions). This can be said about almost all evaluation rules. There are positions where a doubled pawn is strong, where a knight is well placed in a corner, or where a shattered king shelter is unimportant.

Tord
User avatar
Tord Romstad
 
Posts: 639
Joined: 09 Oct 2004, 12:49
Location: Oslo, Norway

Re: eval in crafty 20.9

Postby Robert Allgeuer » 09 Jun 2006, 23:09

Tord Romstad wrote:You seem to be confused. We are talking about the static evaluation only, and this is completely unrelated to the search, extensions, odd or even depths (well, this is not entirely true, because some programs have an asymmetric eval, but let's not get carried away), and so on. The static evaluation function is how the program evaluates the position without search.



What I meant is that the static score from one leaf position evaluation will eventually be propagated down to the search root as overall score of the search. Depending on whether this specific line was searched to an even or an odd depth this score will have the right to move bonus added or subtracted. One could see the right to move bonus as a modulation of the root score according to whether the best line is searched to odd or even depth.
I think this leads to an effect that the program prefers to play into lines that end in (quiet) positions with its own right to move, i.e. into lines that are searched to odd depths. It may prefer such lines over lines that would trigger another extension and thus evaluate one ply deeper up to an even depth, essentially even losing search depth in the PV. Whether this is good or not I do not know, but at least it would not be obvious to me like this, why this were a desirable effect.

Robert
Robert Allgeuer
 
Posts: 124
Joined: 28 Sep 2004, 19:09
Location: Konz / Germany

Re: eval in crafty 20.9

Postby Tord Romstad » 09 Jun 2006, 23:35

Robert Allgeuer wrote:What I meant is that the static score from one leaf position evaluation will eventually be propagated down to the search root as overall score of the search. Depending on whether this specific line was searched to an even or an odd depth this score will have the right to move bonus added or subtracted. One could see the right to move bonus as a modulation of the root score according to whether the best line is searched to odd or even depth.
I think this leads to an effect that the program prefers to play into lines that end in (quiet) positions with its own right to move, i.e. into lines that are searched to odd depths. It may prefer such lines over lines that would trigger another extension and thus evaluate one ply deeper up to an even depth, essentially even losing search depth in the PV. Whether this is good or not I do not know, but at least it would not be obvious to me like this, why this were a desirable effect.


The above analysis is correct only if the side to move bonus is too big. One of the properties of a good and well-tuned evaluation function is that in a quiescent position, the strongest move shouldn't change the evaluation much. If the strongest move increases the static evaluation function a lot, it means that the position before the move was made was evaluated too lowly.

Now consider an evaluation function without a side to move bonus. In most positions, there will be at least one move which improves the static eval (unless the side to move is in zugzwang). This means that the evaluation function doesn't satisfy the property described in the preceding paragraph. The correct value of the side to move bonus is the amount by which the best move will typically improve the static eval for an evaluation function without such a bonus.

In fact, one could argue that one of the main points of a side to move bonus is to avoid the type of effect you describe. A program without a side to move bonus often will prefer lines of odd depth rather than even depth. This is most obvious when analysing relatively quiet and highly symmetrical positions, like the initial position. Without a side to move bonus, a chess program's eval will typically alternate between high and low from one iteration to the next. A 1-ply search will give white a big plus after 1. e4, while a 2-ply search will return zero with a PV like 1. e4 e5. At 3 plies we are at 1. e4 e5 2. Nf3, with a clear plus for white again, and so on. With a well chosen side to move bonus, the result should be a slight plus score for white at all depths, which is what most strong chess players would consider the correct assesment.

Tord
User avatar
Tord Romstad
 
Posts: 639
Joined: 09 Oct 2004, 12:49
Location: Oslo, Norway

Re: eval in crafty 20.9

Postby Chan Rasjid » 10 Jun 2006, 02:07

Whether the side_on_move at leaves randomly differ from that at root does not affect any decision to have bonus for side_on_move. A search at root generally returns different scores or best moves when evaluation has a bonus for side_on_move and when a similar search has the bonus disabled.

Rasjid
Chan Rasjid
 
Posts: 73
Joined: 23 Feb 2005, 16:36
Location: Singapore

Re: eval in crafty 20.9

Postby Robert Allgeuer » 11 Jun 2006, 22:51

Tord Romstad wrote:...
Now consider an evaluation function without a side to move bonus. In most positions, there will be at least one move which improves the static eval (unless the side to move is in zugzwang). This means that the evaluation function doesn't satisfy the property described in the preceding paragraph. The correct value of the side to move bonus is the amount by which the best move will typically improve the static eval for an evaluation function without such a bonus.



Thanks for your detailed explanations.
Wouldn?t the correct value of a side to move bonus be then half the amount the best move typically improves score in order to hit the average of the ripple effect?
Would in your view the side to move score be typically bigger in the endgame (a move could create an unstoppable passer but also only uselessly shuffle around a bishop) or in the middle game (many different eval terms potentially affected by a single move)?

Robert
Robert Allgeuer
 
Posts: 124
Joined: 28 Sep 2004, 19:09
Location: Konz / Germany

Re: eval in crafty 20.9

Postby mjlef » 16 Jun 2006, 12:08

Tord Romstad wrote:
Robert Allgeuer wrote:Of course there are exceptions - positions where having the side to move is unimportant, or even a disadvantage (i.e. zugzwang positions). This can be said about almost all evaluation rules. There are positions where a doubled pawn is strong, where a knight is well placed in a corner, or where a shattered king shelter is unimportant.

Tord


Hmmm, idea. When the null move returns a score proving that being forced to move is bad, how about subtracting out the right to move score from the eval? It would give a more reasonable score for pruning decisions. I suppose it would not work well at the end of the tree.
mjlef
 
Posts: 64
Joined: 29 Mar 2006, 22:04

Re: eval in crafty 20.9

Postby mjlef » 16 Jun 2006, 12:14

In fact, one could argue that one of the main points of a side to move bonus is to avoid the type of effect you describe. A program without a side to move bonus often will prefer lines of odd depth rather than even depth. This is most obvious when analysing relatively quiet and highly symmetrical positions, like the initial position. Without a side to move bonus, a chess program's eval will typically alternate between high and low from one iteration to the next. A 1-ply search will give white a big plus after 1. e4, while a 2-ply search will return zero with a PV like 1. e4 e5. At 3 plies we are at 1. e4 e5 2. Nf3, with a clear plus for white again, and so on. With a well chosen side to move bonus, the result should be a slight plus score for white at all depths, which is what most strong chess players would consider the correct assesment.

Tord[/quote]

Another worthless idea. During the search, using the evaluation score alone without the side to move bonus, record the chage based on odd and even plaies, and dynamically adjust it using an average. So in say engames where the passed pawns are flying, it might get bigger, but in dull positions without much positional gains hapening, it gets smaller.

Mark
mjlef
 
Posts: 64
Joined: 29 Mar 2006, 22:04

Re: eval in crafty 20.9

Postby Daniel Shawul » 16 Jun 2006, 13:46

I add bonus for the side if it has an attack on the opponent king.
IMO this is important if your engine is aggresive and can dig weaknesses in the opponent's king fortress.
Also i tried to give bonus if the side to move's king is threatened , but this one does not seem to work.
In zugzwang positions, bonus is bad so i don't do it in pawn endgames.
I think that the bonus should be given in parts of evaluation where you want some speculation.

Daniel
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 47 guests