Author: Albert Silver
Date: 12:41:36 06/15/98
Go up one level in this thread
On June 14, 1998 at 11:01:05, Don Dailey wrote:
>On June 12, 1998 at 22:02:33, Albert Silver wrote:
>
>>On June 12, 1998 at 15:18:42, Don Dailey wrote:
>>
>>>On June 12, 1998 at 13:15:04, Johanes Suhardjo wrote:
>>>
>>>>On June 10, 1998 at 17:40:21, Don Dailey wrote:
>>>>>But the "bad bishop" is not quite the same as a bishop lacking
>>>>>mobility. Our bishop was not "bad" in this sense. The classical
>>>>>definition is that your bishop is highly restricted behind a
>>>>>pawn on e3 or d3 (if you are white.) It can be bad in other
>>>>>cases but I think this is the common case. It's more a statement
>>>>>of it being undeveloped, and very difficult to get developed.
>>>>
>>>>The reason I'm looking at bad/good bishop is that I want to speed up my
>>>>program and one place to reduce work is to get rid of bishop mobility
>>>>code (besides, Bob Hyatt often says that it's clear whether mobility
>>>>is the cause or the effect of good positions). Well, looks like this
>>>>is a problem I have to experiment with.
>>>>
>>>>Thanks to all who responded!
>>>>
>>>> Johanes Suhardjo (johanes@farida.cc.nd.edu)
>>>>--
>>>>Paradise is exactly like where you are right now ... only much, much
>>>>better.
>>>> -- Laurie Anderson
>>>
>>>
>>>
>>>That's exactly my reasoning too, I did not want the count squares
>>>type of mobility. So I used the 6th rank attacking definition I
>>>mentioned. Also I have a counting rule for colors of pawns.
>>>Friendly pawns on the same color hurt the bishop, but enemy pawns
>>>on the same color are good. Our rules weight one case more than
>>>the other though. Other than a small general centralization and
>>>advancement bonus, that's all we have. Of course we also have
>>>piece cooperation terms but this applies to the material value
>>>as a more general case.
>>>
>>>- Don
>>
>>Piece cooperation? How do you explain to a program that it's pieces are
>>cooperating?
>>
>> Albert
>
>
>I work from the most general to the specific. It is well known that
>certain pieces work well together. So I assume that if they are on
>the board together, the potential exists for them to work together
>well and they get bonus points for it.
>
I assume you are talking about famous piece combinations in the middlegame such
as Queen and Knight together or in endgames where it is known that as a rule
Rook and Bishop are superior to Rook and Knight. The problem is that while these
are valid and correct pieces of information I don't see them as being general,
but rather as being very specific. This last is I believe worthy of being
included in a program's knowledge but the first? Telling the program to favour
an exchange of a bishop for a knight because the only other pieces on the board
are queens would seem to me to be a double-edged sword which would potentially
be more prejudicial than beneficial.
>But it may very well be that in some given circumstance they are NOT
>working well together. When I can, I try to address these situations
>in more detail.
>
You may be able to balance out the potential disasters by throwing in a number
of exceptions but unless the knowledge provided is absolutely crucial I would
say let searching do it's job. I guess the question is what knowledge outweighs
the loss of depth in the search. Of course, this is only true of "memory
starved" machines as Hyatt once put comparing PCs to Deep Blue. Perhaps in 20
years time the whole idea of worrying about an algorithm slowing down the
program's search will seem ludicrous.
Albert Silver
>A simple example is having two bishops. This in the most general case
>is quite good. But it may not be much use in a highly blocked
>position. So I have more specific terms that try to determine this.
>But having 2 bishops always get a bonus, it represents a long term
>potential even when they are currently NOT working together.
>
>- Don
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.