Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Crafty suggestions?

0 views
Skip to first unread message

Zachary Brown

unread,
Sep 11, 1997, 3:00:00 AM9/11/97
to

A few days ago I posted a long list of things I felt could be improved in
Crafty's positional scoring routines. I expected a response explaining
which suggestions were good and which were bad, but now I think maybe my
post was offensive in some way. I love Crafty, and I'd like to help make
it better, that's all. Sorry, Robert, if I inadvertantly insulted you.

Zack


Robert Hyatt

unread,
Sep 14, 1997, 3:00:00 AM9/14/97
to

Zachary Brown (zbr...@lynx.dac.neu.edu) wrote:
: A few days ago I posted a long list of things I felt could be improved in

: Zack


Sorry.... I don't get offended by posts. But in this case, I didn't
see it. We had a week of hades with our inn news daemon, and it is
possible that I never even saw the post. Feel free to either post it
again or email it to me and I'll respond...

The only other thing I can think of is that I *might* have responded
via email if it seemed to be of non-general interest. That is something
I don't do often because most people have invalid email addresses to
avoid the increasing level of spam we see. I don't respond via email
often, however, because of this. So no idea what happened.

Zachary Brown

unread,
Sep 14, 1997, 3:00:00 AM9/14/97
to

In article <5vfl9h$a...@juniper.cis.uab.edu>,

Oh! ... Well then here is the entire thing again:

----------------------------------------

I've been looking over the comments to the Crafty source code,
particularly the evaluation routines:

1) there doesn't seem to be anything having to do with "distant
opposition" or "triangulation" in there. Having the distant opposition
basically means that the kings are an odd number of squares apart, with
your opponent to move. It is a key idea in pawn and knight-and-pawn
endgames, along with triangulation. Since triangulation us generally a
theme only in blocked positions that are harder to handle for brute force
methods, it is even more important to be aware of such positional
features (having multiple accesses to a penetration point in a blocked
position as opposed to the opponent's single access).

2) It would be really useful to have the evaluation routine be able to tag
certain moves as more or less worthy of examination based on positional
features. For instance, if there is a good outpost for the knight, but the
knight can't get there in less than five moves or so, the program is
likely to never make the effort, as I've found in my games with Crafty,
even in positions where I was completely tied up and all Crafty had to do
was loop its knight around and land on a key square to destroy me. If the
existence of a good outpost would cause Crafty to generate a list of moves
that would take a piece there eventually (given the pawn configuration),
the initial moves of those series could be given higher value in the
search than other moves. This feature (tagging moves) in Crafty would be
the first step toward having an actual planning engine.

3) The "trade bonus" of trading pieces but not pawns when ahead in
material, or pawns but not pieces if behind, seems like it could be even
more refined, to avoid exchanging certain pieces even if ahead in
material. In a blocked position, bishops should be exchanged for knights,
especially if there are outposts, while knights should be kept. A trade
that leads to bishops of opposite color should be avoided unless the trade
gives a very bad color weakness to the opponent. Also, well placed pieces
in general should not be traded off, especially not to poorly placed
pieces of the opponent.

4) The bishop trap at a2 or h2 could be generalized to anywhere on the
board where the pawn configuration is condusive.

5) The evaluation of king safety, I think, focuses too much on the king's
likely castled position. Holes in the pawn cover, a bishop that guards the
holes of having pushed g2-g3, these things seem to limit the scope of king
safety to just the castled position itself. But I have seen many games in
which a defensive setup was built for the king all over the place. To
speak in more general terms, control and overprotection of the squares
near the king and open lines leading to the king, would already take
account of the special cases of castled position that are already coded,
and make Crafty less predictable.

An evaluation of what specific pieces in the opponent's camp are most
dangerous to the King, and which pieces in our own camp can best meet that
danger, could also help. But maybe that idea needs to be developed more
later.

6) In the king evaluations, looking for a trapped rook can be stated more
generally as well. It seems like if the King is blocking any of its own
pieces, especially with a bunch of pawns nearby to hamper the piece
further, that should receive extra penalty, especially in the middle
game, when the King can not always move around freely to accomodate the
needs of its pieces. That's a more general way of stating it, I think.

7) Knight outpost and centralization seems fine, but for Bishops, I would
add that keeping the bishop pair is good in general, but with a very
blocked position in which one bishop is clearly worse, the bishop pair
should be less highly valued.

8) In addition to checking if the king is hemmed in by rooks on the
7th/8th rank, a similar value might be put on the ab/gh files, as well as
the rare case of the king moving all the way up to the 1st/2nd rank on
the opponent's side.

9) For evaluating Queens, it looks like a ragged enemy king position is
not the only reason to keep Queens on the board. Any ragged pawn
structure, or when the opponent or ourselves has many pawn weaknesses or
hanging pieces, is a reason to keep the Queens on, since Queens are the
best pieces for multiple attacks or multiple defenses.

10) EvaluateDevelopment() seems too geared toward "normal" development,
putting pawns in the center, penalizing early movement of the Queen, and
so on. It seems as though giving a bonus for having more
development than your opponent, and for control rather than just
occupation of the center, are more versatile general rules.

11) In the section on pawn analysis, I didn't see anything about fewer
pawn islands being better than more.

I hope these suggestions help.

Zack

brucemo

unread,
Sep 21, 1997, 3:00:00 AM9/21/97
to

Zachary Brown wrote:

> 1) there doesn't seem to be anything having to do with "distant
> opposition" or "triangulation" in there. Having the distant opposition
> basically means that the kings are an odd number of squares apart, with
> your opponent to move. It is a key idea in pawn and knight-and-pawn
> endgames, along with triangulation. Since triangulation us generally a
> theme only in blocked positions that are harder to handle for brute force
> methods, it is even more important to be aware of such positional
> features (having multiple accesses to a penetration point in a blocked
> position as opposed to the opponent's single access).

This was an interesting post, but I'd like to comment on some of the
suggestions.

First, in some cases it is easy to compute who has the opposition, but in
many other cases it is much harder to do this. Search will usually figure
out K&P endings, pretty well.

I think a term that simply gave a bonus to the side not on move, if the
kings were two squares apart on some axis, would be a mistake a lot of the
time and of little use a lot of the remaining time. It'd be interesting to
see if I am wrong though.

> 3) The "trade bonus" of trading pieces but not pawns when ahead in
> material, or pawns but not pieces if behind, seems like it could be even
> more refined, to avoid exchanging certain pieces even if ahead in
> material. In a blocked position, bishops should be exchanged for knights,
> especially if there are outposts, while knights should be kept. A trade
> that leads to bishops of opposite color should be avoided unless the trade
> gives a very bad color weakness to the opponent. Also, well placed pieces
> in general should not be traded off, especially not to poorly placed
> pieces of the opponent.

Probably already does this, indirectly.

> 4) The bishop trap at a2 or h2 could be generalized to anywhere on the
> board where the pawn configuration is condusive.

The reason the Bobby-trap function works is that it comes up a lot. Other
cases don't come up as much.

Several of the suggestions I snipped are in the same category. I think
there are a lot of heuristics that are technically correct, but will weigh
down your search without providing sufficient knowledge compensation.

It is very important to recognize that wPh2, wBh3, wKe2 bKg7 is a draw, but
it is not as important to recognize that wPg6 bPg7 bKh8 wBg3 wKg1 is a draw.

You'll save games if you put this second one in, but it won't come up very
much, and you have to wonder what you could have spent the time checking for
this case doing.

> 11) In the section on pawn analysis, I didn't see anything about fewer
> pawn islands being better than more.

This one I think I actually disagree with. Pawn-island counting is
incredibly easy to do, anyone can do it, in a few seconds. I've watched
event games on ICC where someone has kibitzed a comment that more or less
tried to define the position by simply counting pawn islands, and I think
this is often a mistake. Dynamic possibilities often make up for minor
structural flaws such as this. Often a game may revolve around an effort to
give yourself an extra pawn island -- an outside passed pawn. So is it
worth a bonus? I don't think so, I'd rather let the rest of the eval
function figure it out.

bruce

Robert Hyatt

unread,
Sep 22, 1997, 3:00:00 AM9/22/97
to

brucemo (bru...@seanet.com) wrote:
: Zachary Brown wrote:

: > 1) there doesn't seem to be anything having to do with "distant


: > opposition" or "triangulation" in there. Having the distant opposition
: > basically means that the kings are an odd number of squares apart, with
: > your opponent to move. It is a key idea in pawn and knight-and-pawn
: > endgames, along with triangulation. Since triangulation us generally a
: > theme only in blocked positions that are harder to handle for brute force
: > methods, it is even more important to be aware of such positional
: > features (having multiple accesses to a penetration point in a blocked
: > position as opposed to the opponent's single access).

: This was an interesting post, but I'd like to comment on some of the
: suggestions.

: First, in some cases it is easy to compute who has the opposition, but in
: many other cases it is much harder to do this. Search will usually figure
: out K&P endings, pretty well.

: I think a term that simply gave a bonus to the side not on move, if the
: kings were two squares apart on some axis, would be a mistake a lot of the
: time and of little use a lot of the remaining time. It'd be interesting to
: see if I am wrong though.

I simply don't believe in "side-to-move" bonuses. The only real "opposition"
code Crafty has is in the special-case KP vs K code. Which is really not
used anyway since KPK tablebases solve this perfectly anyway. Distant
opposition has too many exceptions, positions where the position is drawn
no matter who has the opposition, because of the way the pawns happen to be
blocked. I don't want to reach such a position intentionally, only to discover
it is drawn when I thought I was winning.

: > 3) The "trade bonus" of trading pieces but not pawns when ahead in


: > material, or pawns but not pieces if behind, seems like it could be even
: > more refined, to avoid exchanging certain pieces even if ahead in
: > material. In a blocked position, bishops should be exchanged for knights,
: > especially if there are outposts, while knights should be kept. A trade
: > that leads to bishops of opposite color should be avoided unless the trade
: > gives a very bad color weakness to the opponent. Also, well placed pieces
: > in general should not be traded off, especially not to poorly placed
: > pieces of the opponent.

: Probably already does this, indirectly.

yes. Bishop mobility is factored in heavily, as well as good outpost
squares for a knight. It generally understands which is better when, although
not perfectly yet...


: > 4) The bishop trap at a2 or h2 could be generalized to anywhere on the


: > board where the pawn configuration is condusive.

: The reason the Bobby-trap function works is that it comes up a lot. Other

: cases don't come up as much.

Am I now famous for this? :) Got my own "trap" named after me? In any
case, Bruce is right. The most common problem case is the bishop taking a
free pawn at one of the squares a2/h2/a7/h7, but getting trapped when the
knight-pawn is pushed. I have seen a couple of games where this happened
at h3 for example, but those are *rare*.

The interesting thing is, after I added code for what Bruce calls the
"Bobby trap", Crafty actually started making this happen more often,
because it suddenly realized that the wayward rook pawn was really
defended by the threat of trapping the bishop, and it would leave the
rook pawn hanging. Many programs politely fell for it. *many*. And
quite a few humans as well. It almost looked like I added code to make
it "tempt" a program into taking the pawn, when, in fact, I had not. But
the search works in strange (and sometimes quite remarkable ways) to take
the "knowledge" it has and apply it in unique ways. This is one example.

:)


: Several of the suggestions I snipped are in the same category. I think

: there are a lot of heuristics that are technically correct, but will weigh
: down your search without providing sufficient knowledge compensation.

: It is very important to recognize that wPh2, wBh3, wKe2 bKg7 is a draw, but
: it is not as important to recognize that wPg6 bPg7 bKh8 wBg3 wKg1 is a draw.

: You'll save games if you put this second one in, but it won't come up very
: much, and you have to wonder what you could have spent the time checking for
: this case doing.

: > 11) In the section on pawn analysis, I didn't see anything about fewer


: > pawn islands being better than more.

It's there, but not as you expect. It is factored in as weak pawns, blocked
pawns, isolated pawns, immobile pawns, and so forth. I think that when you
(if you) get these right, the number of "islands" is irrelevant. IE how
many QP games are won with an isolated D-pawn? How many are lost? The one
thing I don't do very well yet is detect majorities. Crafty is quite good
about figuring out what is blocked and not (13.x in particular has this
code completely rewritten), which pawns are weak and which are not, and it
has a fairly decent understanding of passed pawns and particularly the
"distant" (or outside) passed pawn. What it doesn't understand (yet) is that
a "distant majority" is a "distant passed pawn" if there aren't any troubling
doubled pawns for the opponent. It will learn this before long, once I am
satisfied with all the other new pawn scoring.

: This one I think I actually disagree with. Pawn-island counting is

Komputer Korner

unread,
Sep 22, 1997, 3:00:00 AM9/22/97
to

Can someone with a large database answer this question? Isolated d pawn
winning % for white with the d pawn and a % for black with the d pawn. I
could do it but have other things on my plate like betas.
--
- -
Komputer Korner

The inkompetent komputer

If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.

Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
<605scv$7...@juniper.cis.uab.edu>...

Simon Read

unread,
Sep 22, 1997, 3:00:00 AM9/22/97
to

BR: brucemo (bru...@seanet.com) wrote:
BR> The reason the Bobby-trap function works is that it comes up a lot.
BR> Other cases don't come up as much.
-->
RH: hy...@crafty.cis.uab.edu (Robert Hyatt)
RH> Am I now famous for this? :) Got my own "trap" named after me?
-->
Funny, I read it first and I thought "Bobby" meant "Bobby Fischer".

:)

SSSSSSSimon

c'mon, you know the email address by now: feed...@whitehouse.gov


brucemo

unread,
Sep 23, 1997, 3:00:00 AM9/23/97
to

Robert Hyatt wrote:

> brucemo (bru...@seanet.com) wrote:

> : The reason the Bobby-trap function works is that it comes up a lot. Other
> : cases don't come up as much.

> Am I now famous for this? :) Got my own "trap" named after me? In any
> case, Bruce is right. The most common problem case is the bishop taking a
> free pawn at one of the squares a2/h2/a7/h7, but getting trapped when the
> knight-pawn is pushed. I have seen a couple of games where this happened
> at h3 for example, but those are *rare*.

You're famous enough, but in this case I was referring to Fischer :-)

bruce

Dan Thies

unread,
Sep 27, 1997, 3:00:00 AM9/27/97
to

On 14 Sep 1997 09:37:10 -0400, zbr...@lynx.dac.neu.edu (Zachary Brown)
wrote:

>1) there doesn't seem to be anything having to do with "distant
>opposition" or "triangulation" in there. Having the distant opposition
>basically means that the kings are an odd number of squares apart, with
>your opponent to move.

Distant opposition is a fairly complicated business, actually.
Sometimes you don't gain anything from having the opposition "in your
favor." Not only opposition, but also how many free moves each side
has to mark time, is also a factor. When it comes right down to it,
any position where a full-width search would be able to understand
this concept in real time, is also likely to be found in an endgame
tablebase.

>It is a key idea in pawn and knight-and-pawn
>endgames, along with triangulation. Since triangulation us generally a
>theme only in blocked positions that are harder to handle for brute force
>methods, it is even more important to be aware of such positional
>features (having multiple accesses to a penetration point in a blocked
>position as opposed to the opponent's single access).

Again, while this is an important positional concept, Crafty and the
other full-width search programs have to solve this by searching. It
might be worth looking into creating different kinds of search
extensions to use in endings, so that these kinds of things move
within the horizon of the search, but I can't tell you how. :-)

>2) It would be really useful to have the evaluation routine be able to tag
>certain moves as more or less worthy of examination based on positional
>features. For instance, if there is a good outpost for the knight, but the
>knight can't get there in less than five moves or so, the program is
>likely to never make the effort, as I've found in my games with Crafty,
>even in positions where I was completely tied up and all Crafty had to do
>was loop its knight around and land on a key square to destroy me. If the
>existence of a good outpost would cause Crafty to generate a list of moves
>that would take a piece there eventually (given the pawn configuration),
>the initial moves of those series could be given higher value in the
>search than other moves. This feature (tagging moves) in Crafty would be
>the first step toward having an actual planning engine.

This would require some major changes in the search engine. The only
time you'd really be able to "plan" in a full-width program would be
at the root. Knowchess, if it recognized the knight outpost in the
first place, would eventually figure out how to get the knight there -
if, as I said, it recognized the outpost in the first place. This is
not as simple as it might sound.

For a program like Crafty, or Ferret, etc. the problem is trickier,
and would probably involve a decision at the root that the knight
outpost was worth using. They could always use the method that I used
in the older KC to evaluate such things - just put the knight on the
outpost and see if the evaluation returns a better score than the last
search returned, or do a 4-ply+extension search from that position.
If it looks good, then you try searching for a way to get it there, by
adding something to the search - either an extension for the knight,
or you just don't count the knight's moves as a ply until it gets to
the outpost. The problem with this is how to evaluate all these
things at root, and not end up with an intolerable number of
extensions. Usually, there are several good outposts for different
pieces - how do you decide which piece can go where, without a search?

If the knight can get to the outpost within Crafty's search horizon,
then the other question would be whether it evaluates this as better
than any of the alternatives. Obviously, it will be much weaker in
this area at blitz time than at 40/120.

>3) The "trade bonus" of trading pieces but not pawns when ahead in
>material, or pawns but not pieces if behind, seems like it could be even
>more refined, to avoid exchanging certain pieces even if ahead in
>material. In a blocked position, bishops should be exchanged for knights,
>especially if there are outposts, while knights should be kept. A trade
>that leads to bishops of opposite color should be avoided unless the trade
>gives a very bad color weakness to the opponent. Also, well placed pieces
>in general should not be traded off, especially not to poorly placed
>pieces of the opponent.

I think that Crafty and most of its peers get something equivalent to
this anyway, since trading a strong piece for a weaker piece is going
to weaken the position. I don't really like the idea of a swapdown
bonus for computer programs (giving a bonus to trading down when
you're ahead) because it can move you from a position of great dynamic
strength to one where the material advantage is static, but there
might well be compensating static or dynamic disadvantages. There is
a large gap between the late middlegame and the endgame tablebases.
It would make more sense to trade down in the context of creating
additional static advantages, like a pawn majority or even a passed
pawn.

>4) The bishop trap at a2 or h2 could be generalized to anywhere on the
>board where the pawn configuration is condusive.

The trap at a2/h2 is well-known and pretty easy to code for. The
general case is much more complicated - it could be generalized with
rules (I've got a start on this) but rules are hard for full-width
programs to follow. The last thing you want is a huge bonus coming
into the eval for a non-trapped bishop, and you lose a pawn for
nothing.

>5) The evaluation of king safety, I think, focuses too much on the king's
>likely castled position. Holes in the pawn cover, a bishop that guards the
>holes of having pushed g2-g3, these things seem to limit the scope of king
>safety to just the castled position itself. But I have seen many games in
>which a defensive setup was built for the king all over the place. To
>speak in more general terms, control and overprotection of the squares
>near the king and open lines leading to the king, would already take
>account of the special cases of castled position that are already coded,
>and make Crafty less predictable.

Bob messes with king safety all the time, it seems. It's hard enough
to protect a castled king! I'm sure a lot of programs do something
more like what you describe - KC's king safety is very fast (less than
a tenth of a second) and very comprehensive, but there are almost a
hundred hours invested in it. The last time I looked at Crafty in
detail, it was more of an effort to castle safely and avoid creating
some gaping hole in the defense.

>An evaluation of what specific pieces in the opponent's camp are most
>dangerous to the King, and which pieces in our own camp can best meet that
>danger, could also help. But maybe that idea needs to be developed more
>later.

This is not a brute-force idea.

>6) In the king evaluations, looking for a trapped rook can be stated more
>generally as well. It seems like if the King is blocking any of its own
>pieces, especially with a bunch of pawns nearby to hamper the piece
>further, that should receive extra penalty, especially in the middle
>game, when the King can not always move around freely to accomodate the
>needs of its pieces. That's a more general way of stating it, I think.

It's starting to sound like you need to start writing some code, Zack.
Brute-force programs are much better, IMO, at the specific case - the
general case of all these things leads to extreme complication.

>7) Knight outpost and centralization seems fine, but for Bishops, I would
>add that keeping the bishop pair is good in general, but with a very
>blocked position in which one bishop is clearly worse, the bishop pair
>should be less highly valued.

Probably already gotten from the rest of the eval as a side effect.
The cool thing about brute-force programs is how the simple terms can
combine to create complex terms.

>9) For evaluating Queens, it looks like a ragged enemy king position is
>not the only reason to keep Queens on the board. Any ragged pawn
>structure, or when the opponent or ourselves has many pawn weaknesses or
>hanging pieces, is a reason to keep the Queens on, since Queens are the
>best pieces for multiple attacks or multiple defenses.

A pretty good point. OTOH, a serious edge in pawn structure can also
mean that it's time to get everything off and enter a winning king &
pawn ending. Yes, you can do a lot with your queen, but your opponent
can use it to deliver checks and contain your king. It's impossible
to deliver a perpetual check with nothing but a king and pawns.

>10) EvaluateDevelopment() seems too geared toward "normal" development,
>putting pawns in the center, penalizing early movement of the Queen, and
>so on. It seems as though giving a bonus for having more
>development than your opponent, and for control rather than just
>occupation of the center, are more versatile general rules.

I've always used some kind of relative scoring for development,
instead of absolute scoring, since it's better to have a huge lead in
time than a small lead. Control vs. occupation is a tricky question,
though. In every case where "control" is thought to be sufficient in
opening theory, there was a lot of grandmaster practice involved
before the issue was settled. Occupation almost always equals
control, especially in openings that start with 1.e4.

>11) In the section on pawn analysis, I didn't see anything about fewer
>pawn islands being better than more.

Counting pawn islands could help, but this is one of those things that
works well with "all other things being equal" but it's not such a
great goal in itself. With pieces on the board, the number of
"islands" becomes less important. The QGD often leads to an isolated
d-pawn for white, which is not weak because of the open lines white
gets as a result.

Dan

Robert Hyatt

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

Dan Thies (rt...@wt.net) wrote:

: >9) For evaluating Queens, it looks like a ragged enemy king position is

: >not the only reason to keep Queens on the board. Any ragged pawn
: >structure, or when the opponent or ourselves has many pawn weaknesses or
: >hanging pieces, is a reason to keep the Queens on, since Queens are the
: >best pieces for multiple attacks or multiple defenses.

: A pretty good point. OTOH, a serious edge in pawn structure can also
: mean that it's time to get everything off and enter a winning king &
: pawn ending. Yes, you can do a lot with your queen, but your opponent
: can use it to deliver checks and contain your king. It's impossible
: to deliver a perpetual check with nothing but a king and pawns.

My trade bonus now does this. IE, if material is even, but one side's
pawn structure is significantl better than the other's, that side tries
to initiate trades to reach an ending where the advantage results in a
win...

: >10) EvaluateDevelopment() seems too geared toward "normal" development,

: >putting pawns in the center, penalizing early movement of the Queen, and
: >so on. It seems as though giving a bonus for having more
: >development than your opponent, and for control rather than just
: >occupation of the center, are more versatile general rules.

: I've always used some kind of relative scoring for development,
: instead of absolute scoring, since it's better to have a huge lead in
: time than a small lead. Control vs. occupation is a tricky question,
: though. In every case where "control" is thought to be sufficient in
: opening theory, there was a lot of grandmaster practice involved
: before the issue was settled. Occupation almost always equals
: control, especially in openings that start with 1.e4.

: >11) In the section on pawn analysis, I didn't see anything about fewer
: >pawn islands being better than more.

: Counting pawn islands could help, but this is one of those things that
: works well with "all other things being equal" but it's not such a
: great goal in itself. With pieces on the board, the number of
: "islands" becomes less important. The QGD often leads to an isolated
: d-pawn for white, which is not weak because of the open lines white
: gets as a result.

: Dan

Yes... although the term "island" has many meanings. if you mean "islands
of '1'" than Crafty hates 'em. pairs are different if they are mobile...
which is the new idea in 13.x... that is currently "in progress"


Zachary Brown

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

In article <342d4b0...@snews.zippo.com>, Dan Thies <rt...@wt.net> wrote:
>On 14 Sep 1997 09:37:10 -0400, zbr...@lynx.dac.neu.edu (Zachary Brown)
>wrote:
>
>>11) In the section on pawn analysis, I didn't see anything about fewer
>>pawn islands being better than more.
>
>Counting pawn islands could help, but this is one of those things that
>works well with "all other things being equal" but it's not such a
>great goal in itself. With pieces on the board, the number of
>"islands" becomes less important. The QGD often leads to an isolated
>d-pawn for white, which is not weak because of the open lines white
>gets as a result.

I think that is the same as saying that White's position has other factors
which compensate for the weakness---but it is a weakness, nonetheless. The
fundamental strategic strength of a position can be very useful to a
program that can only calculate 10 or 15 plies per move. Avoiding long
term weaknesses can lead to positions in which calculation is more
meaningful (i.e. a strategically lost game cannot be saved by
calculation). Having less pawn islands than your opponent is, among other
things, an endgame advantage, which means that exchanges will tend to
favor me, while Crafty will have no way of knowing that it should avoid
exchanges in that case. Crafty should first of all get a bonus for having
less islands than its opponent, and second of all avoid exchanges if it
has more.

Just a side comment about chess programming in general: it's strange to
hear the various ideas argued in the light of the history of chess itself.
Brute force calculation was really the first stage of chess development,
and the ability to calculate long combinations was seen as the pinnacle of
chess skill, just as it is the most highly valued quality in today's
programs. It's true that today's programs do their calculation with
positional factors in mind while the masters of yesteryear were looking
primarily for mate or a big gain in material, but still I think it's very
similar.

But then a revolution in chess thinking took place in the first third of
this century, primarily with Capablanca, who's understanding of strategy
allowed him to beat the greatest players of the day with ease. He was not
outstanding at calculation, although he was no slouch either, but it was
his understanding of the nature of the position that allowed him to see
his way through.

It seems that chess programs are rapidly reaching a threshold of
diminishing returns as far as depth of calculation, and it will soon
become more and more difficult to increase plies by adding hardware or
reducing positional understanding. Programs already try to narrow the
search with heuristics, and I believe that is the first feeble steps of a
planning engine. It is good to think of it as a planning engine, because
then its inadequacy becomes clear. Only by dealing with the question of
strategy head on can programs hope to reach beyond their calculations, to
the deeper currents of the game.

Zack

>Dan

Robert Hyatt

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

Zachary Brown (zbr...@lynx.dac.neu.edu) wrote:
: In article <342d4b0...@snews.zippo.com>, Dan Thies <rt...@wt.net> wrote:
: >On 14 Sep 1997 09:37:10 -0400, zbr...@lynx.dac.neu.edu (Zachary Brown)
: >wrote:
: >
: >>11) In the section on pawn analysis, I didn't see anything about fewer
: >>pawn islands being better than more.
: >
: >Counting pawn islands could help, but this is one of those things that
: >works well with "all other things being equal" but it's not such a
: >great goal in itself. With pieces on the board, the number of
: >"islands" becomes less important. The QGD often leads to an isolated
: >d-pawn for white, which is not weak because of the open lines white
: >gets as a result.

: I think that is the same as saying that White's position has other factors


: which compensate for the weakness---but it is a weakness, nonetheless. The
: fundamental strategic strength of a position can be very useful to a
: program that can only calculate 10 or 15 plies per move. Avoiding long
: term weaknesses can lead to positions in which calculation is more
: meaningful (i.e. a strategically lost game cannot be saved by
: calculation). Having less pawn islands than your opponent is, among other
: things, an endgame advantage, which means that exchanges will tend to
: favor me, while Crafty will have no way of knowing that it should avoid
: exchanges in that case. Crafty should first of all get a bonus for having
: less islands than its opponent, and second of all avoid exchanges if it
: has more.

I don't think the # of islands is relevant. It is more a concept of which
pawns are weak, and which are mobile. And how the islands are situated
(ie do I have an extra island, but it is on the a-b file, while my opponent
has only a b-pawn, giving me a majority and eventual passed pawn on the
a/b file? I try to analyze all of this in detail, although it is not
perfect yet...


: Just a side comment about chess programming in general: it's strange to


: hear the various ideas argued in the light of the history of chess itself.
: Brute force calculation was really the first stage of chess development,

: and the ability to calculate long combinations was seen as the pinnacle of

Dan Thies

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

On 28 Sep 1997 07:14:18 -0400, zbr...@lynx.dac.neu.edu (Zachary Brown)
wrote:

>In article <342d4b0...@snews.zippo.com>, Dan Thies <rt...@wt.net> wrote:
>>Counting pawn islands could help, but this is one of those things that
>>works well with "all other things being equal" but it's not such a
>>great goal in itself. With pieces on the board, the number of
>>"islands" becomes less important. The QGD often leads to an isolated
>>d-pawn for white, which is not weak because of the open lines white
>>gets as a result.
>

>I think that is the same as saying that White's position has other factors
>which compensate for the weakness---but it is a weakness, nonetheless. The
>fundamental strategic strength of a position can be very useful to a
>program that can only calculate 10 or 15 plies per move. Avoiding long
>term weaknesses can lead to positions in which calculation is more
>meaningful (i.e. a strategically lost game cannot be saved by
>calculation).

No, it is the same as saying that the isolated pawn is a source of
strength in the position, and it can often become a passed pawn.

>Having less pawn islands than your opponent is, among other
>things, an endgame advantage, which means that exchanges will tend to
>favor me, while Crafty will have no way of knowing that it should avoid
>exchanges in that case. Crafty should first of all get a bonus for having
>less islands than its opponent, and second of all avoid exchanges if it
>has more.

I think you're blowing a single element out of proportion, Zack. The
only way to get into this question safely is to get into it
thoroughly, which is a pretty large undertaking. With a whole lot of
other tems in the evaluation to prevent a pawn-island score from
screwing things up, sure, it makes sense. By itself, I'd question
whether it's a win or not.

>Brute force calculation was really the first stage of chess development,
>and the ability to calculate long combinations was seen as the pinnacle of
>chess skill, just as it is the most highly valued quality in today's
>programs. It's true that today's programs do their calculation with
>positional factors in mind while the masters of yesteryear were looking
>primarily for mate or a big gain in material, but still I think it's very
>similar.

As long as you don't include Morphy, who understood things about the
game that most of us still don't get. Most of the "masters" of
yesteryear (before Lasker, Tarrasch, Schlecter, etc..) were patzers by
the standards of today's chess.

>It seems that chess programs are rapidly reaching a threshold of
>diminishing returns as far as depth of calculation, and it will soon
>become more and more difficult to increase plies by adding hardware or
>reducing positional understanding. Programs already try to narrow the
>search with heuristics, and I believe that is the first feeble steps of a
>planning engine. It is good to think of it as a planning engine, because
>then its inadequacy becomes clear. Only by dealing with the question of
>strategy head on can programs hope to reach beyond their calculations, to
>the deeper currents of the game.

I agree with this, which is why I stopped working on Shannon-type
programs altogether. I think we are still far, far away from seeing a
planning program beat a deep-search program, though. It takes a lot
of time to implement knowledge, when you're talking about a need to
codify as many as 100,000 concepts.

Dan (Knowchess)

Dan Thies

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

On 28 Sep 1997 00:16:48 GMT, hy...@crafty.cis.uab.edu (Robert Hyatt)
wrote:

>Dan Thies (rt...@wt.net) wrote:
>: >9) For evaluating Queens, it looks like a ragged enemy king position is

>: >not the only reason to keep Queens on the board. Any ragged pawn
>: >structure, or when the opponent or ourselves has many pawn weaknesses or
>: >hanging pieces, is a reason to keep the Queens on, since Queens are the
>: >best pieces for multiple attacks or multiple defenses.
>
>: A pretty good point. OTOH, a serious edge in pawn structure can also
>: mean that it's time to get everything off and enter a winning king &
>: pawn ending. Yes, you can do a lot with your queen, but your opponent
>: can use it to deliver checks and contain your king. It's impossible
>: to deliver a perpetual check with nothing but a king and pawns.
>

>My trade bonus now does this. IE, if material is even, but one side's
>pawn structure is significantl better than the other's, that side tries
>to initiate trades to reach an ending where the advantage results in a
>win...

Which seems correct to me - if you've got much better pawns, it's time
to clear the heavy pieces off and win the game. Although with the
early results from Covax's little endgame test, this might not be the
best "computer strategy." About half of the programs tested so far
couldn't find any of the keys.

>: >11) In the section on pawn analysis, I didn't see anything about fewer

>: >pawn islands being better than more.
>
>: Counting pawn islands could help, but this is one of those things that
>: works well with "all other things being equal" but it's not such a
>: great goal in itself. With pieces on the board, the number of
>: "islands" becomes less important. The QGD often leads to an isolated
>: d-pawn for white, which is not weak because of the open lines white
>: gets as a result.
>

>Yes... although the term "island" has many meanings. if you mean "islands
>of '1'" than Crafty hates 'em. pairs are different if they are mobile...
>which is the new idea in 13.x... that is currently "in progress"

There are a lot of factors to pawn structure - it took 2 months for me
to get done with the rules I got from reading Kmoch, and those are
mostly superficial. It's hard to understand the pawn structure by
only looking at your own pawns.

Dan

Dan Thies

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

On 28 Sep 1997 17:41:51 GMT, hy...@crafty.cis.uab.edu (Robert Hyatt)
wrote:


>I disagree with the "island" idea for the following reason. I have
>white pawns on a2 and b2 and d2. you have black pawns on b7 and c7
>and d7. Which side would you rather play with the kings on the g-file?
>That white majority is (can be) critical. It depends on whether it is
>mobile. But just because I have two islands and you have one doesn't mean
>that I'm worse here.

"All other things being equal," pawn islands are important - but a
simple count of pawn islands is not very good by itself. If you
randomly throw six pawns down for both players, "number of islands" is
going to be less relevant than majorities, mobility, and passers.

A weak pawn island is weak for many reasons, not weak just because it
exists.

Dan

Jim Caccamise

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
<60lpi5$h...@juniper.cis.uab.edu>...
<<<...snipped...>>>

>
> I don't think the # of islands is relevant. It is more a concept of
which
> pawns are weak, and which are mobile. And how the islands are situated
> (ie do I have an extra island, but it is on the a-b file, while my
opponent
> has only a b-pawn, giving me a majority and eventual passed pawn on the
> a/b file? I try to analyze all of this in detail, although it is not
> perfect yet...
>
Number of pawn islands is relevant, as are pawn majorities, doubled
pawns, backward pawns, isolated pawns, passed pawns, outside passed
pawns, blockcaded pawns, etc. - and they are all related. But, it's
understandable that you take a subset of these factors that are most
import and/or easiest to evaluate. I agree that other factors are more
relevant than pawn islands. But, a "perfect" evaluator should also
consider the pawn islands relationships.
--
Jim Caccamise
( Remove X from e-mail address, anti-spam )

Robert Hyatt

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

Jim Caccamise (Xc...@magicnet.net) wrote:
: Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article

I disagree with the "island" idea for the following reason. I have


white pawns on a2 and b2 and d2. you have black pawns on b7 and c7
and d7. Which side would you rather play with the kings on the g-file?
That white majority is (can be) critical. It depends on whether it is
mobile. But just because I have two islands and you have one doesn't mean
that I'm worse here.

that's the reason why I don't count islands, I try to analyze what is
weak, what is blocked, and what is not. It might be a "quick and dirty"
methodolgy (counting islands) but it doesn't seem to be the right way.

Martin: what's your IM take on this? Do you ever count islands, or
do you evaluate other things instead? Ditto for Rune or any other strong
human that plays here. This might be a good topic, and I might learn how
to make Crafty better as well...

Jim Caccamise

unread,
Sep 28, 1997, 3:00:00 AM9/28/97
to

Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
<60m4sv$l...@juniper.cis.uab.edu>...

> I disagree with the "island" idea for the following reason. I have
> white pawns on a2 and b2 and d2. you have black pawns on b7 and c7
> and d7. Which side would you rather play with the kings on the g-file?
> That white majority is (can be) critical. It depends on whether it is
> mobile. But just because I have two islands and you have one doesn't
mean
> that I'm worse here.
>

Of course, I agree with this example. But, I said all factors are
important and related. Actually an important factor which I included in
the etc. pawn factors is King(s) distance. (I actually thought about
explicitly including this because of it's importance, but decided against
it since the other listed factors where independent of distant piece
influences.) Just because the island concept is outweighed by other
factors in this (and many) examples doesn't mean it's meaningless.

> that's the reason why I don't count islands, I try to analyze what is
> weak, what is blocked, and what is not. It might be a "quick and
dirty"
> methodolgy (counting islands) but it doesn't seem to be the right way.
>
> Martin: what's your IM take on this? Do you ever count islands, or
> do you evaluate other things instead? Ditto for Rune or any other
strong
> human that plays here. This might be a good topic, and I might learn
how
> to make Crafty better as well...
>

Strong players consider pawn islands, but weight the importance
appropriately. Frequently, this is of minor importance, where offsetting
factors exist or can be created.
I already agreed that their are more important factors to be
considered first. But, this doesn't mean that pawn island considerations
are irrelevant.

0 new messages