Author: Christophe Theron
Date: 11:57:36 06/22/00
Go up one level in this thread
On June 22, 2000 at 05:43:44, Enrique Irazoqui wrote:
>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
That's right. I sometimes (too often I would say) see my program playing
stupidly, and after he has lost the game I feel a big temptation to change the
code in order to fix THIS.
But I refrain from doing so. I have been done that in my early development
stages, and it was always a disaster. An evaluation function is a very finely
tuned thing, and is it really easy to break it.
So I just write down what happened and keep this in my collection of things to
fix. When the problem has happened often enough, I get a better picture of what
is wrong, and I try to fix it by doing as little as I can. This is very
important: change the evaluation as little as possible, just do what's enough to
fix the problem. Sometimes it does not even solve the problem, but the program
is a little bit more aware that there is a problem: the score is more negative
with the new version, but the program does not find the right move. This is
already a step forward. Maybe, earlier in the game, it would have chosen another
path. So maybe the problem is 80% solved.
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.