Author: Enrique Irazoqui
Date: 02:43:44 06/22/00
Go up one level in this thread
On June 21, 2000 at 20:28:57, Christophe Theron wrote: >On June 21, 2000 at 15:14:54, Enrique Irazoqui wrote: > >>On June 21, 2000 at 13:53:13, Christophe Theron wrote: >> >>>On June 21, 2000 at 08:30:59, Enrique Irazoqui wrote: >>> >>>>[D]1r6/1pb1k1p1/4p2p/1p1p4/3Pp2P/1R2P1PB/1P2P1K1/8 b - - 0 1 >>>> >>>>Yesterday I looked at this position that reveals once again how much trouble >>>>programs have in recognizing the importance of blocked pieces. Some programs >>>>pick and drop 1...b4, but none of them realize that the blocked rook is out of >>>>the game until the search makes them see the consequences many hours later. The >>>>evaluation at the initial position or after 1...b4 2.Rxb4 b5 3.Rb3 b4 is almost >>>>the same. It takes 61 minutes for F6a and 335 minutes for Tiger to pick b4, and >>>>much, much longer to fail high. >>> >>> >>>Well, life is unfair. I do have something for this kind of positions in Tiger. >>>Normally Tiger is able to suspect that the rook is in trouble. >> >>Do you have to treat differently the cases of blocked rooks or blocked knights >>and bishops? So many times I hear programmers looking for patterns. Well, this >>is one, isn't it? In the first position, the rook can't move or a pawn will take >>it. In the second and third, the bishop is statically trapped by a chain of >>pawns in a small corner of the board. Technical question from an illiterate: >>wouldn't it make sense to heavily penalize such positions? >> >>For instance, Junior 6a is the program that does best with the first position. >>It picks b4 in 51 seconds and sticks to it forever, but the difference between >>b4 and the next best is only 8/100 of a pawn after 4 hours. So it doesn't quite >>get it, and in the other 3 positions it fails. >> >>>However, for an unknown reason, it looks like it does not work in this here... >> >>Tiger doesn't get the other positions either (no program does). Pattern? >> >>>Sometimes I wonder if adding this kind of knowledge is worth the trouble, as >>>there are so many exceptions, and even cases where the knowledge is counter >>>productive, or is not triggered at the right time! >> >>These positions come from real games, one of them from a computer game, so I >>guess it must be productive to teach them this kind of things. I may be >>exaggerating, but looking at some human-computer games, like the ones lost by >>Fritz in the Dutch championship, it seems clear that blocking positions is an >>efficient anti-computer strategy. But how can a program recognize a general >>blockade if it's incapable of realizing that one piece is trapped? > > > >In the current state of our "art", it is difficult to go further. > >I could simply increase the penalty for such bad pieces, but I guarantee that I >tried already and that it had a big negative impact on the program's style. > >The program was so sensitive to blocked or nearly blocked pieces that it would >push pawns in a insane way just to get some lines open. The result was a very >poor play with pawn structures, and many lost games. > >There are also many positions in which a computer has a blocked piece but still >manages to win the game. Because it can stand positional and tactical pressure >much better than a human player. You, as a human, would definitely avoid these >blocked pieces because you know how much enery it's going to take you to hold >the position. You don't react objectively about "is the position strong or not >for me". You have to manage your mental energy and just avoid the trouble. > >A computer does not have this kind of concern, and this is precisely an >important part of its strength. It will go into an unusual, uneasy position, and >will invent a solution. That's also the strength behind this "no pattern" >entity. > >Well of course in your position it does not work, and the way to solve it would >probably add some more filtering to my blocked pieces recognition, and increase >the penalty in some selected cases (like this one). > > > > >>In my opinion, this also has to do with a more general issue of aesthetics, of >>programs being able to produce some sort of beauty other than announcing mate in >>128. > > > >That's what we (programmers) try to do generally. But we have to do everything >at the same time and it's not easy. Of course I would like my program to produce >beautiful games, but first I would like to avoid being mated in 128 by this >ugly, stupid, fast searcher. Or else I look even more stupid. Then you need tablebases, or else you will be mated in 128. :) So either these positions and so many others are solved by search, and this will take years of Intel help, or programs will keep playing silly in the hands of the Van der Wiels. Frustrating, but I suspect you are right. It reminds me of a conversation with my father many years ago, when I told him that neurology, brain research and not his psychiatry had to be the way to know and to go. "And when someone attempts suicide what do I tell him, to come back in a couple of centuries?" You doctors...! ;) Enrique > > Christophe
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.