Author: G. R. Morton
Date: 21:10:06 03/10/00
Go up one level in this thread
On March 10, 2000 at 22:30:03, Robert Hyatt wrote: >On March 10, 2000 at 22:10:51, G. R. Morton wrote: > >>On March 10, 2000 at 17:24:18, blass uri wrote: >> >>>On March 10, 2000 at 16:36:09, G. R. Morton wrote: >>> >>>>On March 10, 2000 at 15:33:16, Mike S. wrote: >>>> >>>>>I have pasted the wrong FEN string, sorry. I hope it's all ok now. >>>>> >>>>>On March 10, 2000 at 15:28:01, Mike S. wrote: >>>>> >>>>>>[D]8/p1r2R2/1p1k4/7p/8/3P4/PP4K1/8 w - - >>>>>>Shredder 3, on a K6-2/400 with 12 + 4 MB hash (no TB's) switches to Rf5 after >>>>>>2:45, here is the log: >>>>>> >>>>>> 8.01 0:00.38 -0.27 2.Txc7 Kxc7 3.Kh3 Kd6 4.Kh4 Ke5 5.Kxh5 Kd4 6.Kg5 Kxd3 >>>>>>7.Kh4 Kc2 (47.905) 124.4 >>>>>>(...) >>>>>>14.01 0:22.14 -1.62 2.Txc7 Kxc7 3.Kh3 Kd6 4.Kh4 Ke5 5.Kxh5 Kd4 6.Kg5 Kxd3 >>>>>>7.Kf5 Kc2 8.b4 Kb2 9.b5 Kxa2 10.Ke5 (2.529.945) 114.2 >>>>>>14.03 2:45.70 -1.61++ 2.Tf5 (15.096.562) 91.1 >>>>>>14.03 3:57.63 -1.60 2.Tf5 Tc2+ 3.Kf3 Txb2 4.a3 Ta2 5.Ke4 Txa3 6.Txh5 Ta1 >>>>>>(20.829.482) 87.6 >>>>>> >>>>>>But the evaluation is only 0.02 better so far. >>>> >>>>Its disappointing that shredder changes its mind only after nearly 3 minutes >>>>when it is easy to see that RxR loses simply. Now I wish someone would answer >>>>the question about the ?Rc8-c7 Zwischenzug . >>> >>>It is known that programs are weak in some endgames but Rebel won 2 endgames >>>with rooks and opposite colour bishops against humans. >>> >>>shredder also saved a bad endgame with one pawn disadvantage against a GM in the >>>Israeli league. >>> >>>You are right that computers are weak in very simple endgame if they are not too >>>simple to be solved by tablebases but they may be strong in more complicated >>>endgames when both sides have rook and bishop or rook and knight. >>> >>>Uri >> >>Years ago the explanation for the relatively poor endgame play of software was >>that they did not analyze with chunk pattern recognition followed by focused >>checking like humans, but rather had to waste huge amounts of effort on >>worthless exponentially exploding tree branch searching with relatively few >>heuristics to limit it. With very fast PCs and fast searching algorithms like >>we have today this min-max tree search methodology was suppose to triumph, but >>evidently not, as this very simple end game position shows. Now if there are >>such simple endgames that software can?t handle efficiently, there most be even >>more (and more complicated) middle game (probably closed) positions that are >>really not being handled efficiently by software, positions that a great >>pattern recognizer like Kasparov can grasp much quicker. Still, its hard to >>believe such top programs, evaluating 10s or 100s of thousands of positions/sec, >>sometimes can?t find the simple winning plan that a club player can see easily. >>Something else going on? >> >>Best Regards > > >Depends on your perspective. In the endgame discussed, black is winning. White >has to try to find a way to draw since black has the distant passed pawn. If >white trades rooks, it is easier. However, avoiding the trade has its own >problems as white _still_ has to contend with the distant passer... > >The right answer here is probably to not play into a position where you are >almost certainly lost in the first place... :) Yes, black is probably winning anyway as I said in my original post, but its not like these programs are picking ...RxR because they are thinking they're losing anyway and its all the same. If you look at their evaluations, some (like Junior6a) go on thinking for quite a while that they are only about 1/2 pawn down while (most?) humans would much sooner see that ...RxR makes it easier for black. Of course, most humans would be blown away by Junior long before getting this far, but the point is that, suprisingly, human pattern recognition is still not matched in some (even simple) settings. Regards
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.