Author: Uri Blass
Date: 06:46:05 02/19/04
Go up one level in this thread
On February 19, 2004 at 08:49:25, Tim Foden wrote:
>On February 19, 2004 at 08:19:30, Dieter Buerssner wrote:
>
>>On February 19, 2004 at 03:03:53, Tim Foden wrote:
>>
>>>On February 18, 2004 at 10:15:28, Mihaly Szalai wrote:
>>>
>>>>[D]1knB4/8/7p/5R2/7K/8/3r4/7B w - - 0 1
>>>>
>>>>White has a very nice play here:
>>>>1. Rb5+ Nb6 2. Bxb6! Rh2+ 3. Kg4! Rxh1 4. Bg1+! Kc7 5. Rb1! Kd7 6. Re1 Kc6 7.
>>>>Rd1
>>>>Kb5 8. Rc1 Ka4 9. Rb1 +-
>>>>
>>>>I wonder how many engines can see this line and how fast.
>>>
>>>The version of Green Light that I ended up with in Graz likes Rb5+ after 28
>>>seconds.
>>>
>>> 15 27.640 +3.205 31454k Rb5+ Nb6 2. Bxb6 Rh2+ 3. Kg4 Rxh1 4. Bg1+ Kc8 5.
>>> Rb1 Kd7 6. Re1 h5+ 7. Kg3 Kc6 8. Rd1 Kb5 9. Rc1
>>> Ka4 10. Kf4
>>>
>>>It gets it after 1 minute 20 seconds. It's not quite the same line as above as
>>>it does h5+ earlier than required (this is a transposition though), but
>>>otherwise looks good:
>>>
>>> 17 1:19.85 +4.657 91517k Rb5+ Nb6 2. Bxb6 Rh2+ 3. Kg4 Rxh1 4. Bg1+ Kc8 5.
>>> Rb1 Kd7 6. Re1 h5+ 7. Kg3 Kc6 8. Rd1 Kb5 9. Rc1
>>> Ka4 10. Rb1 h4+ 11. Kg2 Rxg1+ 12. Rxg1
>>>
>>>I'll have to figure out what allows it to see this when my other versions of
>>>Green Light that are in development do not :)
>>
>>Very impressive! For Yace null move makes a big difference in this pos.
>
>I guess that's because there are a load of moves in a row for B that are
>zugzwang.
>
>>If I
>>analyse the position 5 moves into the line, with null move disabled, it sees
>>that black is lost about 6 depths earlier than with null move enabled. Perhaps
>>you changed something about null move?
>
>Yes, the Graz version has some extra code to switch of null move and it kicks in
>in this position. My other versions do not, so they have trouble seeing it at
>all.
>
>>Or about scoring, when the rook is in the
>>corner with practically no mobility (which, when penalized enough could avoid
>>misleading null move fail highs).
>>
>>BTW. Don't you give KRBKR(+Ps) a drawish score in GLC?
>
>Not quite. I score KRB-KR as drawish. But the pawns cause this to be switched
>off. It's something I planned to look at when time permits, but this position
>prompted me to hava a go this morning. Now it should score KRB-KR as about
>+0.7, KRB-KRP as about +0.4, KRB-KRPP as about -0.5, and KRB-KRPPP as about
>-1.4.
>
>Now, instead of considering Bd5 for ages it only considers Rb5+, and now with
>only a +1.0 score rather than a +3.1 one. It still takes quite 17 plies to see
>the correct PV though (but in much less time)...
>
> 17 37.344 +4.525 48271k Rb5+ Nb6 2. Bxb6 Rh2+ 3. Kg4 Rxh1 4. Bg1+ Kc8 5.
> Rb1 Kd7 6. Re1 h5+ 7. Kg3 Kc6 8. Rd1 Kb5 9. Rc1
> Ka4 10. Rb1 h4+ 11. Kg2 Rxg1+ 12. Rxg1
>
>Cheers, Tim.
>
>Full analysis: GLC 3.01.1.2, 96MB Hash, AXP 2.1GHz:
>
> Game stage: Endgame
> Current eval: 0.391
> Ply Time Score Nodes Principal variation
> 5 0.000 +1.086 7623 Rb5+ Nb6 2. Be4 Rxd8 3. Rxb6+ Kc8 {ht} 4. Rxh6
> 5 0.020 +1.086 10654 Rb5+ Nb6 2. Be4 Rxd8 3. Rxb6+ Kc8 {ht} 4. Rxh6
> 6 0.030 +1.045 18393 Rb5+ Nb6 2. Be4 Rxd8 3. Rxb6+ Kc8 4. Bf5+ Kc7 5.
> Rxh6
> 6 0.030 +1.045 27939 Rb5+ Nb6 2. Be4 Rxd8 3. Rxb6+ Kc8 4. Bf5+ Kc7 5.
> Rxh6
> Generating internal KP-K end-game table...
> Done (0.141 secs)
I see that you generate internal kp-k endgame during the search.
Is it better than generating them when the program starts to run before
searching?
Does having big tables that are not used by the program hurt the speed of the
program?
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.