Author: Uri Blass
Date: 10:52:50 05/20/03
Go up one level in this thread
On May 20, 2003 at 11:11:49, Will Singleton wrote:
>On May 20, 2003 at 02:17:14, Tim Foden wrote:
>
>>On May 19, 2003 at 23:46:58, Will Singleton wrote:
>>
>>>I was trying to figure out why my latest build doesn't do quite as well on
>>>ecm86, and I ran Ruffian on it. To my surprise, Ruffian couldn't solve it, even
>>>given 5 minutes. This is odd, since most other progs can do it in less than 10
>>>seconds. (What I take away from this exercise is that my program must now be
>>>stronger. Otherwise, I'd have to work on the problem, which is much less
>>>interesting than testing new ideas.)
>>>
>>>[D]2r3k1/1nqbrp2/p5pp/1p1Pp1N1/8/1P5P/P1B2PP1/2RQR1K1 w - -
>>
>>I would assume then (from running Green Light), that Nxf7 is the correct move
>>here?
>>
>>The PV is interesting as it contains 9 captures in a row at the start of the PV.
>> Maybe ruffian is pruning if there are more than a certain number of captures in
>>a row (as this is very unlikely to be a good thing).
>>
>>Cheers, Tim.
>>
>>Analysis: GLC3.00, AXP 1.47GHz, 24MB Hash:
>>
>> Game stage: Middle game
>> Current eval: 0.564
>> Ply Time Score Nodes Principal variation
>> 4 0.000 +0.743 5646 Ne4 Qb6 2. Qd2 g5
>> 5 0.010 +0.592 13917 Ne4 Nd6 2. Nf6+ Kg7 3. Qf3 Kh8
>> 5 0.020 +0.592 21231 Ne4 Nd6 2. Nf6+ Kg7 3. Qf3 Kh8
>> 6 0.060 +0.702 54001 Ne4 Qb6 2. Qd2 g5 3. Qb4 Nc5
>> 6 0.070 +0.702 66151 Ne4 Qb6 2. Qd2 g5 3. Qb4 Nc5
>> 7 0.200 +0.709 159535 Ne4 Qb6 2. Bd3 Ree8 3. Qd2 g5 4. Nc3
>> 7 0.310 +1.102 263663 Nxf7 {++} Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+
>> Kxf7 5. Rxc1
>> 7 0.360 +1.745 307058 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1
>> 7 0.370 +1.745 316180 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1
>> 8 0.440 +1.345 388531 Nxf7 {--} Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+
>> Kxf7 5. Rxc1 Nd6
>> 8 0.530 +1.186 460490 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6
>> 8 0.580 +1.186 527044 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6
>> 9 0.841 +1.259 749293 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7
>> 9 1.081 +1.259 966741 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7
>> 10 1.712 +1.299 1514631 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke7
>> 10 2.093 +1.299 1853467 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke7
>> 11 3.985 +1.340 3477228 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke7 7. g4
>> 11 5.377 +1.340 4753269 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke7 7. g4
>> 12 8.251 +1.405 7132424 Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke8 7. Ra7 Bc8
>> 12 11.666 +1.405 10151k Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke8 7. Ra7 Bc8
>> 13 19.798 +1.603 16605k Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke8 7. Ra7 Bc8 8. Rc7
>> 13 25.416 +1.603 21432k Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke8 7. Ra7 Bc8 8. Rc7
>> 14 40.958 +1.591 33530k Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke8 7. Ra7 Bc8 8. Rh7 Nf7
>> 14 58.534 +1.591 49298k Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke8 7. Ra7 Bc8 8. Rh7 Nf7
>> 15 1:50.67 +1.731 89853k Nxf7 Rxf7 2. Bxg6 Qxc1 3. Qxc1 Rxc1 4. Bxf7+ Kxf7
>> 5. Rxc1 Nd6 6. Rc7 Ke8 7. Ra7 Bc8 8. Rh7 Nf7 9.
>> Rg7
>>
>
>Tim,
>
>Interesting. Your line shows a transition to a fairly even endgame, yet GLC
>doesn't see it until the moves are played through.
Why do you think that the endgame is equal.
Ruffian give this opinion but Ruffian is not god.
I believe that white is better.
I do not say that white is winning but it is advantage for white but I agree
that not going to the endgame is better.
Perhaps the problem some
>engines have here is going from middle to endgame. Could be like Tony said, a
>reliance on preprocessing sets up middlegame parameters that aren't valid at the
>end of the pv. Or it could be simply a bug, something that prevents the endgame
>phase from being fully triggered during the search.
>
>At least I know why mine takes a bit longer now. It takes more time to see the
>proper pv (not recapturing with the queen), because I reworked my pawn hash to
>include the endgame parameter.
What does it mean?
Do you evaluate in the pawn hash that the pawn d5 is weak relative to the black
king and white king?
I do not think that it is a question of hash tables and movei of today has no
pawn hash tables.
It is a question of evaluation.
>
>Will
Movei has no special endgame parameters except knowing that in the endgame the
king should be active and some small knowledge about king relative to passed
pawns that is not relevant in the endgame that is discussed.
I do not think that knowing that it is endgame should help computer to know that
the position is equal and I think that programs with endgame parameters should
evaluate the position as better for white for the following reasons:
1)I read that passed pawns are considered as more important in the endgame
and it should increase white's evaluation.
2)I read that rook and 2 pawns against knight and bishop should be considered as
equal in the middle game when it is better for the rook in endgame.
Note that I did not implement this knowledge in movei so movei does not like the
endgame enough to go for it but even movei say that white is better in the
endgame.
Crafty also prefers white in the endgame but I did not test the latest version.
New game
8/1n1b1k2/p6p/1p1Pp3/8/1P5P/P4PP1/2R3K1 b - - 0 1
Analysis by Crafty 19.01:
5...Nd6
± (1.02) Depth: 1/4 00:00:00
5...Nd6 6.Kf1
± (1.12) Depth: 2/4 00:00:00
5...Nd6 6.Rc6 Bxc6 7.dxc6
+- (1.81) Depth: 3/5 00:00:00
5...Ke7 6.Rc6 a5
± (1.36) Depth: 3/5 00:00:00
5...Ke7 6.Rc6 a5 7.Kf1
+- (1.46) Depth: 4/8 00:00:00
5...Ke7 6.Rc6 a5 7.a4 b4
± (1.39) Depth: 5/8 00:00:00
5...Ke7 6.Rc6 a5 7.a4 b4 8.Kf1
+- (1.49) Depth: 6/12 00:00:00 11kN
5...Ke7 6.Rc7 Nd8 7.Kf1 Kd6 8.Rxd7+ Kxd7 9.Ke2
± (1.34) Depth: 7/12 00:00:00 28kN
5...Ke7 6.Rc7 Nd8 7.a4 Kd6 8.Rxd7+ Kxd7 9.axb5 axb5
± (1.17) Depth: 8/14 00:00:00 61kN
5...Ke7 6.Rc7 Nd8 7.a4 Kd6 8.Rxd7+ Kxd7 9.axb5 axb5 10.Kf1
± (1.27) Depth: 9/15 00:00:00 104kN
5...Ke7 6.Rc7 Nd8 7.a4 Kd6 8.Ra7 b4 9.Kf1 Bc8 10.Ra8
± (0.89) Depth: 10/15 00:00:01 323kN
5...Ke7 6.Rc7 Nd8 7.a4 Kd6 8.Ra7 bxa4 9.bxa4 Bf5 10.Rxa6+ Kxd5 11.Rxh6
± (0.94) Depth: 11/18 00:00:02 607kN
5...Ke7 6.Rc7 Nd8 7.a4 Kd6 8.Ra7 bxa4 9.bxa4 Bf5 10.Ra8 Nf7 11.Rf8
± (0.82) Depth: 12/20 00:00:04 1429kN
5...Ke7 6.Rc7 Nd8 7.a4 Kd6 8.Ra7 bxa4 9.bxa4 h5 10.Ra8 Nf7 11.Rf8 Ng5
± (0.91) Depth: 13/23 00:00:07 2762kN
5...Ke7 6.Rc7 Nd8 7.a4 Kd6 8.Ra7 bxa4 9.bxa4 h5 10.Kh2 h4 11.Ra8 Nf7 12.Rf8
± (0.86) Depth: 14/23 00:00:14 6402kN
5...Ke7 6.Rc7 Nd6 7.Ra7 Ne4 8.Rxa6 Nf6 9.a3 Nxd5 10.Rxh6 Nf4 11.a4 Ne2+ 12.Kf1
Nd4 13.axb5 Bxb5+
± (0.85) Depth: 15/25 00:00:35 17356kN
5...Ke7 6.Rc7 Nd8 7.Ra7 Kd6 8.a4 bxa4 9.bxa4 h5 10.h4 Bf5 11.Ra8 Nf7 12.Rf8 Bg6
13.Rg8
± (0.88) Depth: 16/27 00:01:27 44768kN
5...Ke7 6.Rc7 Nd6 7.Ra7 Ne4 8.Rxa6 Nf6 9.g4 Nxd5 10.Rxh6 Nf4 11.Rh7+ Kd6
12.Rxd7+ Kxd7 13.h4 Kd6 14.a4 Ne2+
± (0.92) Depth: 17/30 00:08:49 268472kN
(, eim 20.05.2003)
Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.