what is the rating value of path dependent evaluation

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: what is the rating value of path dependent evaluation

Post by bob »

BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?

-Sam
No. The problem is the path _below_ the hash hit. Not the path above it. How would you know the remainder of the path from position P to the node where you computed this evaluation??? All you know is that you have a hash hit right now...
You know what went on previously, but not what happens after this position.
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: what is the rating value of path dependent evaluation

Post by bob »

Gian-Carlo Pascutto wrote:
bob wrote:
Gian-Carlo Pascutto wrote: Your criticism makes no sense. Do you use LMR?

If yes, you can store different scores from the same depth, because the underlying searches can have different depths and will end up at different leaf positions. This is ugly, but I think you agree LMR works.

So that's not a valid criticism of this idea.
That is completely unrelated.
It certainly is. From the point of view of a (say) 5 ply search, both LMR and this idea can give different scores depending on the path and store them in the hash, causing further lookups that would have triggered different searches or evals to get values different than they would have otherwise.

Does this mean those ideas don't work? No.

Imagine that instead of doing Uri's idea I'm doing 3 ply LMR searches to evaluate a node. Exactly the same effect. Different path gives different score, but all is stored in the hash anyway.
He is describing computing a path-dependent scoring term, but the hash table can completely hide this, or apply it to all identical positions, whether the path-dependent feature actually exists or not.
Yes, that's perfectly true. Does it matter? Apparently not.
The point is this. In a normal search, after we search position P, and get a result, anytime we re-encounter position P, we are going to do the same search below it. Of course, the draft > depth issue can make this less accurate, but the point remains, given P1 and P2, where the depths are the same, there is no reason I would search P1 and produce result R, and then when I reach P2, not do the same search and get the same R, which is why I don't search below P2. But with path-dependent scoring, this is a problem.

If you don't believe this is a problem, make your 50-move-rule draw stuff work correctly without clearing the hash scores as you near the 50-move draw. Unless you don't store draw scores at all, which takes us right back to where we came in...
Top
Uri Blass
Posts: 10314
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: what is the rating value of path dependent evaluation

Post by Uri Blass »

adieguez wrote:Hi, after seeing the results in searches to fixed depth I didn't want to test it very much, but at least I played some games. This is not a probe but seeing this and seeing that in fixed search depth the node count is increased too much(37%), it discourages me.

3 Amyan : 2505 46 45 184 58.2 % 2448 20.7 %
4 Amyan_with_bonus : 2463 80 79 61 52.5 % 2446 19.7 %
In this case it seems that my idea does not work for Amyan.
Maybe it works for Movei because of different code that I have or because of bugs in the hash but I know based on testing that movei seem to have no problem to solve positions like Fine70(10 10 10 is faster in it).

Movei 10 10 10 fine 70

New game
8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 1

Analysis by Movei00_8_438(10 10 10):

New game
8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 1

1.Ka1-b2 Ka7-a8 2.Kb2-c3 Ka8-b7
± (1.06) Depth: 18 00:00:01 29kN
1.Ka1-b1
± (1.07) Depth: 18 00:00:01 30kN
1.Ka1-b1
± (1.36) Depth: 18 00:00:01 32kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 18 00:00:02 33kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 18 00:00:02 33kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 19 00:00:02 35kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 19 00:00:02 35kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 20 00:00:02 37kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 20 00:00:02 37kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 21 00:00:02 40kN
1.Ka1-b1 Ka7-b8 2.Kb1-c2 Kb8-c8 3.Kc2-d2 Kc8-d8 4.Kd2-c3 Kd8-c7
± (1.36) Depth: 21 00:00:02 40kN
1.Ka1-b1
+- (1.66) Depth: 22 00:00:02 44kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6
+- (1.66) Depth: 22 00:00:02 52kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6
+- (1.66) Depth: 22 00:00:02 54kN
1.Ka1-b1
+- (1.96) Depth: 23 00:00:02 56kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (1.96) Depth: 23 00:00:02 59kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (1.96) Depth: 23 00:00:02 60kN
1.Ka1-b1
+- (2.26) Depth: 24 00:00:02 67kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 24 00:00:02 71kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 24 00:00:02 72kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 25 00:00:02 76kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 25 00:00:02 77kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 26 00:00:02 82kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 26 00:00:02 84kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 27 00:00:02 91kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.26) Depth: 27 00:00:02 95kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6
+- (2.26) Depth: 28 00:00:02 109kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6
+- (2.26) Depth: 28 00:00:02 110kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-e7 15.f4-f5
+- (2.48) Depth: 29 00:00:02 133kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-e7 15.f4-f5
+- (2.48) Depth: 29 00:00:02 133kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.48) Depth: 30 00:00:02 143kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.48) Depth: 30 00:00:02 144kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-e8 15.f4-f5 Ke8-e7
+- (2.70) Depth: 31 00:00:02 177kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-e8 15.f4-f5 Ke8-e7
+- (2.70) Depth: 31 00:00:02 178kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.70) Depth: 32 00:00:02 197kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (2.70) Depth: 32 00:00:03 197kN
1.Ka1-b1
+- (3.00) Depth: 33 00:00:03 253kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-g7 15.f4-f5 Kg7-f7
+- (3.31) Depth: 33 00:00:03 310kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-g7 15.f4-f5 Kg7-f7
+- (3.31) Depth: 33 00:00:03 310kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-e7 15.f4-f5 Ke7-d8 16.Kg5-g6 Kd8-c7
+- (3.43) Depth: 34 00:00:03 375kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-e7 12.Kh5-g6 Ke7-e8 13.Kg6xf5 Ke8-f7 14.Kf5-g5 Kf7-e7 15.f4-f5 Ke7-d8 16.Kg5-g6 Kd8-c7
+- (3.43) Depth: 34 00:00:03 375kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (3.43) Depth: 35 00:00:03 407kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (3.43) Depth: 35 00:00:03 407kN
1.Ka1-b1
+- (3.73) Depth: 42 00:00:05 2227kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (3.73) Depth: 42 00:00:05 2669kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (3.73) Depth: 42 00:00:06 2670kN
1.Ka1-b1
+- (4.03) Depth: 43 00:00:06 3982kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-g5 Kf7-g7 15.f4-f5 Kg7-f7 16.f5-f6 Kf7-f8
+- (4.16) Depth: 43 00:00:07 4846kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-g5 Kf7-g7 15.f4-f5 Kg7-f7 16.f5-f6 Kf7-f8
+- (4.16) Depth: 43 00:00:07 4847kN
1.Ka1-b1
+- (4.46) Depth: 44 00:00:09 6167kN
1.Ka1-b1
+- (5.16) Depth: 44 00:00:10 7097kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-f6 15.Ke4-d3 Kf6-f7 16.Kd3-c4 Kf7-e7
+- (5.90) Depth: 44 00:00:11 7909kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-f6 15.Ke4-d3 Kf6-f7 16.Kd3-c4 Kf7-e7
+- (5.90) Depth: 44 00:00:11 7909kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (5.90) Depth: 45 00:00:12 8394kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (5.90) Depth: 45 00:00:12 8395kN
1.Ka1-b1
+- (6.20) Depth: 46 00:00:14 9689kN
1.Ka1-b1
+- (6.90) Depth: 46 00:00:16 11380kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-f6 15.Ke4-d3 Kf6-f5 16.Kd3-c4 Kf5xf4
+- (8.33) Depth: 46 00:00:20 14752kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-f6 15.Ke4-d3 Kf6-f5 16.Kd3-c4 Kf5xf4
+- (8.33) Depth: 46 00:00:20 14752kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (8.33) Depth: 47 00:00:21 15653kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (8.33) Depth: 47 00:00:22 15653kN
1.Ka1-b1
+- (8.63) Depth: 48 00:00:28 20383kN
1.Ka1-b1
+- (9.33) Depth: 48 00:00:43 30369kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-f6 15.Ke4-d3 Kf6-f5 16.Kd3-c4 Kf5xf4
+- (9.58) Depth: 48 00:00:54 38214kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2 Ka6-b6 5.Kc2-d2 Kb6-c7 6.Kd2-d3 Kc7-b6 7.Kd3-e3 Kb6-c7 8.Ke3-f2 Kc7-d8 9.Kf2-g3 Kd8-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-f6 15.Ke4-d3 Kf6-f5 16.Kd3-c4 Kf5xf4
+- (9.58) Depth: 48 00:00:54 38215kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (9.58) Depth: 49 00:00:56 39497kN
1.Ka1-b1 Ka7-a8 2.Kb1-b2 Ka8-a7 3.Kb2-b3 Ka7-a6 4.Kb3-c2
+- (9.58) Depth: 49 00:00:56 39497kN

(so k, 13.09.2009)


analysis by Movei default fine 70


New game, Friend mode
8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 1

Analysis by Movei00_8_438:
1.Ka1-b2 Ka7-a8 2.Kb2-c3 Ka8-b7 3.Kc3-d3 Kb7-c7 4.Kd3-c4
± (1.06) Depth: 19 00:00:01 33kN
1.Ka1-b1
± (1.07) Depth: 19 00:00:01 36kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
± (1.07) Depth: 23 00:00:02 66kN
1.Ka1-b1
± (1.37) Depth: 24 00:00:02 73kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
± (1.37) Depth: 24 00:00:02 78kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
± (1.37) Depth: 24 00:00:02 78kN
1.Ka1-b1
+- (1.67) Depth: 25 00:00:02 86kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-f7 12.Kg5xf5 Kf7-e7
+- (2.34) Depth: 25 00:00:02 97kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-f7 12.Kg5xf5 Kf7-e7
+- (2.34) Depth: 25 00:00:02 97kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (2.34) Depth: 26 00:00:02 105kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (2.34) Depth: 26 00:00:02 105kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-f7 12.Kg5xf5 Kf7-e7 13.Kf5-g6 Ke7-d7 14.f4-f5
+- (2.46) Depth: 27 00:00:02 122kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-f7 12.Kg5xf5 Kf7-e7 13.Kf5-g6 Ke7-d7 14.f4-f5
+- (2.46) Depth: 27 00:00:03 122kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (2.46) Depth: 28 00:00:03 133kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (2.46) Depth: 28 00:00:03 134kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-e7 12.Kg5xf5 Ke7-f7 13.Kf5-g5 Kf7-g7 14.f4-f5 Kg7-f7
+- (2.61) Depth: 29 00:00:03 162kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-e7 12.Kg5xf5 Ke7-f7 13.Kf5-g5 Kf7-g7 14.f4-f5 Kg7-f7
+- (2.61) Depth: 29 00:00:03 162kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (2.61) Depth: 30 00:00:03 181kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (2.61) Depth: 30 00:00:03 181kN
1.Ka1-b1
+- (2.91) Depth: 31 00:00:03 215kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-e7 12.Kg5xf5 Ke7-f7 13.Kf5-g5 Kf7-e7 14.f4-f5 Ke7-d7 15.f5-f6 Kd7-e8 16.Kg5-g6
+- (3.30) Depth: 31 00:00:03 262kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-e8 11.Kh4-g5 Ke8-e7 12.Kg5xf5 Ke7-f7 13.Kf5-g5 Kf7-e7 14.f4-f5 Ke7-d7 15.f5-f6 Kd7-e8 16.Kg5-g6
+- (3.30) Depth: 31 00:00:04 262kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-e7 15.Ke4-d3 Ke7-f6 16.Kd3-c4 Kf6-f5
+- (9.20) Depth: 46 00:00:55 41128kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-e4 Kf7-e7 15.Ke4-d3 Ke7-f6 16.Kd3-c4 Kf6-f5
+- (9.20) Depth: 46 00:00:55 41128kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (9.20) Depth: 47 00:01:00 44806kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (9.20) Depth: 47 00:01:00 44806kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-g5 Kf7-g7 15.f4-f5 Kg7-f7 16.f5-f6 Kf7-f8
+- (9.44) Depth: 48 00:01:15 56172kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-c7 6.Kd2-d3 Kc7-b7 7.Kd3-e2 Kb7-c7 8.Ke2-f2 Kc7-d7 9.Kf2-g3 Kd7-e7 10.Kg3-h4 Ke7-f6 11.Kh4-h5 Kf6-f7 12.Kh5-g5 Kf7-g7 13.Kg5xf5 Kg7-f7 14.Kf5-g5 Kf7-g7 15.f4-f5 Kg7-f7 16.f5-f6 Kf7-f8
+- (9.44) Depth: 48 00:01:15 56173kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (9.44) Depth: 49 00:01:31 69240kN
1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8
+- (9.44) Depth: 49 00:01:31 69241kN

(so k, 13.09.2009)
Top
User avatar
xsadar
Posts: 147
Joined: Wed Jun 06, 2007 10:01 am
Location: United States
Full name: Mike Leany

Re: what is the rating value of path dependent evaluation

Post by xsadar »

bob wrote:
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?

-Sam
No. The problem is the path _below_ the hash hit. Not the path above it. How would you know the remainder of the path from position P to the node where you computed this evaluation??? All you know is that you have a hash hit right now...
You know what went on previously, but not what happens after this position.
The way I picture this path-dependent evaluation, it would be implemented something like this:

Code: Select all

int search(position *Pos, int Alpha, int Beta)
{
  int CurEval = evaluate(Pos);
  int Val;

  ...

  foreach move
  {
     makemove(...);
     Val = search(Pos, -Beta, -Alpha);
     if (Val > CurEval) Val += SmallAmount;
     else if &#40;Val < CurEval&#41; Val -= SmallAmount;
     if &#40;Val > Beta&#41;
     &#123;
       hashStore&#40;..., Val&#41;;
       return Val;
     &#125;
     ...
  &#125;
  ...
&#125;
If this is the way it's done, Val knows nothing about the path from the root to the current node, so it's not stored in the hash table. No problems whatsoever with that. The only thing it does know about is the path from the current node to the leaf nodes, and that's exactly what we DO want to store in the hash table.
Now if the whole path is figured in at the leaf nodes (like we do with mate) rather than node-by-node on the way back to the root (like above), that would indeed cause hash problems, and I agree, even Sam's suggestion wouldn't solve it.
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: what is the rating value of path dependent evaluation

Post by bob »

xsadar wrote:
bob wrote:
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?

-Sam
No. The problem is the path _below_ the hash hit. Not the path above it. How would you know the remainder of the path from position P to the node where you computed this evaluation??? All you know is that you have a hash hit right now...
You know what went on previously, but not what happens after this position.
The way I picture this path-dependent evaluation, it would be implemented something like this:

Code: Select all

int search&#40;position *Pos, int Alpha, int Beta&#41;
&#123;
  int CurEval = evaluate&#40;Pos&#41;;
  int Val;

  ...

  foreach move
  &#123;
     makemove&#40;...);
     Val = search&#40;Pos, -Beta, -Alpha&#41;;
     if &#40;Val > CurEval&#41; Val += SmallAmount;
     else if &#40;Val < CurEval&#41; Val -= SmallAmount;
     if &#40;Val > Beta&#41;
     &#123;
       hashStore&#40;..., Val&#41;;
       return Val;
     &#125;
     ...
  &#125;
  ...
&#125;
If this is the way it's done, Val knows nothing about the path from the root to the current node, so it's not stored in the hash table. No problems whatsoever with that. The only thing it does know about is the path from the current node to the leaf nodes, and that's exactly what we DO want to store in the hash table.
Now if the whole path is figured in at the leaf nodes (like we do with mate) rather than node-by-node on the way back to the root (like above), that would indeed cause hash problems, and I agree, even Sam's suggestion wouldn't solve it.
And that is the exact problem we are discussing. I have run afoul of this in many ICC games, dealing with the 50-move draws. You search like mad in endgames, and store normal scores. And as the game plays out, you begin to close in on the 50-move draw problem. But the hash entries already stored were too far away for that to be important. And you blindly play right into a 50-move draw when you could just push a pawn, reset it, and go on to win.

I had to put in a "invalidate TT score" facility that I invoke as I start to get near the 50 move draws, which solves _most_ of the problems (but not all, obviously).
Top
Karlo Bala
Posts: 373
Joined: Wed Mar 22, 2006 10:17 am
Location: Novi Sad, Serbia
Full name: Karlo Balla

Re: what is the rating value of path dependent evaluation

Post by Karlo Bala »

bob wrote:
xsadar wrote:
bob wrote:
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?

-Sam
No. The problem is the path _below_ the hash hit. Not the path above it. How would you know the remainder of the path from position P to the node where you computed this evaluation??? All you know is that you have a hash hit right now...
You know what went on previously, but not what happens after this position.
The way I picture this path-dependent evaluation, it would be implemented something like this:

Code: Select all

int search&#40;position *Pos, int Alpha, int Beta&#41;
&#123;
  int CurEval = evaluate&#40;Pos&#41;;
  int Val;

  ...

  foreach move
  &#123;
     makemove&#40;...);
     Val = search&#40;Pos, -Beta, -Alpha&#41;;
     if &#40;Val > CurEval&#41; Val += SmallAmount;
     else if &#40;Val < CurEval&#41; Val -= SmallAmount;
     if &#40;Val > Beta&#41;
     &#123;
       hashStore&#40;..., Val&#41;;
       return Val;
     &#125;
     ...
  &#125;
  ...
&#125;
If this is the way it's done, Val knows nothing about the path from the root to the current node, so it's not stored in the hash table. No problems whatsoever with that. The only thing it does know about is the path from the current node to the leaf nodes, and that's exactly what we DO want to store in the hash table.
Now if the whole path is figured in at the leaf nodes (like we do with mate) rather than node-by-node on the way back to the root (like above), that would indeed cause hash problems, and I agree, even Sam's suggestion wouldn't solve it.
And that is the exact problem we are discussing. I have run afoul of this in many ICC games, dealing with the 50-move draws. You search like mad in endgames, and store normal scores. And as the game plays out, you begin to close in on the 50-move draw problem. But the hash entries already stored were too far away for that to be important. And you blindly play right into a 50-move draw when you could just push a pawn, reset it, and go on to win.

I had to put in a "invalidate TT score" facility that I invoke as I start to get near the 50 move draws, which solves _most_ of the problems (but not all, obviously).
How much of HT efficiency can you lose if you include 50-move counter in hash code?
Best Regards,
Karlo Balla Jr.
Top
User avatar
xsadar
Posts: 147
Joined: Wed Jun 06, 2007 10:01 am
Location: United States
Full name: Mike Leany

Re: what is the rating value of path dependent evaluation

Post by xsadar »

bob wrote:
xsadar wrote:
bob wrote:
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?

-Sam
No. The problem is the path _below_ the hash hit. Not the path above it. How would you know the remainder of the path from position P to the node where you computed this evaluation??? All you know is that you have a hash hit right now...
You know what went on previously, but not what happens after this position.
The way I picture this path-dependent evaluation, it would be implemented something like this:

Code: Select all

int search&#40;position *Pos, int Alpha, int Beta&#41;
&#123;
  int CurEval = evaluate&#40;Pos&#41;;
  int Val;

  ...

  foreach move
  &#123;
     makemove&#40;...);
     Val = search&#40;Pos, -Beta, -Alpha&#41;;
     if &#40;Val > CurEval&#41; Val += SmallAmount;
     else if &#40;Val < CurEval&#41; Val -= SmallAmount;
     if &#40;Val > Beta&#41;
     &#123;
       hashStore&#40;..., Val&#41;;
       return Val;
     &#125;
     ...
  &#125;
  ...
&#125;
If this is the way it's done, Val knows nothing about the path from the root to the current node, so it's not stored in the hash table. No problems whatsoever with that. The only thing it does know about is the path from the current node to the leaf nodes, and that's exactly what we DO want to store in the hash table.
Now if the whole path is figured in at the leaf nodes (like we do with mate) rather than node-by-node on the way back to the root (like above), that would indeed cause hash problems, and I agree, even Sam's suggestion wouldn't solve it.
And that is the exact problem we are discussing. I have run afoul of this in many ICC games, dealing with the 50-move draws. You search like mad in endgames, and store normal scores. And as the game plays out, you begin to close in on the 50-move draw problem. But the hash entries already stored were too far away for that to be important. And you blindly play right into a 50-move draw when you could just push a pawn, reset it, and go on to win.

I had to put in a "invalidate TT score" facility that I invoke as I start to get near the 50 move draws, which solves _most_ of the problems (but not all, obviously).
Ok. I guess I did a poor job of reading Uri's description. It does indeed sound like he's passing path information toward the leaf nodes. But it also seems to me that you could get the exact same results -- but without the hash issue -- by only passing path information back toward the root.

I knew the 50-move rule could be an issue, but I haven't really looked into it at all personally. Thus far I've had too many other things to be concerned with. I've also wondered about how much repetition can mess up the hash table. I avoid some of that by checking for repetition before I check for a hash move (and of course, I don't hash the resulting draw score if any), but then the score passed to the parent node is still path dependent.
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: what is the rating value of path dependent evaluation

Post by bob »

Karlo Bala wrote:
bob wrote:
xsadar wrote:
bob wrote:
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?

-Sam
No. The problem is the path _below_ the hash hit. Not the path above it. How would you know the remainder of the path from position P to the node where you computed this evaluation??? All you know is that you have a hash hit right now...
You know what went on previously, but not what happens after this position.
The way I picture this path-dependent evaluation, it would be implemented something like this:

Code: Select all

int search&#40;position *Pos, int Alpha, int Beta&#41;
&#123;
  int CurEval = evaluate&#40;Pos&#41;;
  int Val;

  ...

  foreach move
  &#123;
     makemove&#40;...);
     Val = search&#40;Pos, -Beta, -Alpha&#41;;
     if &#40;Val > CurEval&#41; Val += SmallAmount;
     else if &#40;Val < CurEval&#41; Val -= SmallAmount;
     if &#40;Val > Beta&#41;
     &#123;
       hashStore&#40;..., Val&#41;;
       return Val;
     &#125;
     ...
  &#125;
  ...
&#125;
If this is the way it's done, Val knows nothing about the path from the root to the current node, so it's not stored in the hash table. No problems whatsoever with that. The only thing it does know about is the path from the current node to the leaf nodes, and that's exactly what we DO want to store in the hash table.
Now if the whole path is figured in at the leaf nodes (like we do with mate) rather than node-by-node on the way back to the root (like above), that would indeed cause hash problems, and I agree, even Sam's suggestion wouldn't solve it.
And that is the exact problem we are discussing. I have run afoul of this in many ICC games, dealing with the 50-move draws. You search like mad in endgames, and store normal scores. And as the game plays out, you begin to close in on the 50-move draw problem. But the hash entries already stored were too far away for that to be important. And you blindly play right into a 50-move draw when you could just push a pawn, reset it, and go on to win.

I had to put in a "invalidate TT score" facility that I invoke as I start to get near the 50 move draws, which solves _most_ of the problems (but not all, obviously).
How much of HT efficiency can you lose if you include 50-move counter in hash code?


I'd guess 75% or more, particularly in endgames. Doing that is the same as requiring depth == draft, rather than depth <= draft (as we currently do) when doing a hash table match and checking to see if we can use the result. This is a simple way of encoding the path length into the hash signature and it is a performance killer.
Top
Uri Blass
Posts: 10314
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: what is the rating value of path dependent evaluation

Post by Uri Blass »

<snipped>
xsadar wrote: Ok. I guess I did a poor job of reading Uri's description. It does indeed sound like he's passing path information toward the leaf nodes. But it also seems to me that you could get the exact same results -- but without the hash issue -- by only passing path information back toward the root.
I see no way that you can get the exact same results without the hash issue.

What you suggest is clearly different then what I do.
My idea was simply comparing evaluation at the leaves to evaluation of what happened 2 plies earlier or 4 plies earlier.

I took even number of plies because I want to compare between evaluations when the same side is to move(I relatively do not trust my evaluation to be correct about improvement in the position if it is not the same side to move).

You compare search results with static evaluation so you may often not have the same side to move(even if you search to even depth extensions or pruning may mean that you practically compare difference of odd number of plies).

Uri
Top
User avatar
xsadar
Posts: 147
Joined: Wed Jun 06, 2007 10:01 am
Location: United States
Full name: Mike Leany

Re: what is the rating value of path dependent evaluation

Post by xsadar »

bob wrote:
Karlo Bala wrote: How much of HT efficiency can you lose if you include 50-move counter in hash code?


I'd guess 75% or more, particularly in endgames. Doing that is the same as requiring depth == draft, rather than depth <= draft (as we currently do) when doing a hash table match and checking to see if we can use the result. This is a simple way of encoding the path length into the hash signature and it is a performance killer.
What if instead you somehow made use of the result of: max(0, plycount+depth-100)? (Either storing it or making it part of the key.)
That way it's always zero unless there's a potential for reaching a 50 move draw. You could possibly also consider using acceptable ranges rather than requiring the exact same value. It still may not be worth it though. It's just a thought that came to me just now.
Top

Return to “Computer Chess Club: Programming and Technical Discussions”