|
The following explanation is my current opinion on how the Rybka chess program works. It has
not been verified by experts in the field of computer chess. It is mostly a collection of postings made at the chessgames.com
RandomVisitor forum over a period of many months. 07/29/2006 JLJ
21 June 2007 This document is not being updated - see this link
for my current work on this subject
1. Introduction
In December of 2005 the chess program Rybka became publicly
available.
This chess software moved quickly to the top of the computer
chess ratings lists.
On the RandomVisitor forum at chessgames.com I have speculated
that Rybka uses a new way of evaluating the strengths and weaknesses of a chess position, a procedure commonly called an "evaluation
function". A large number of these posts were made in the April-May time frame, so you have to dig a bit to find them. I will
be reposting some of that information here.
Perhaps this is the first in-depth attempt to explain how Rybka works.
On February 11th of this year (2006) I made the following post on the Rybka forum at
chessgames.com:
"I have a guess as to how Vasik Rajlich does his evaluation function for Rybka.
First, let's go over how a traditional chess engine does it's evaluation.
It looks at the position of each piece on the board, and looks up a value in a table to determine whether the piece is in
a good spot or a bad spot on the board. This number is added to the "score" for the position. An additional parameter may
then be added based on how many moves the piece can make, etc.
Unfortunately, this has been tried by the [hundreds] of chess programs
that are out there. The computer moves the knight to the center of the board but does not understand why it is doing this.
It is just trying to maximize a number in a look-up table.
What if, instead of looking up values in a table, we try to incentivize
the behavior of the piece? For example, we could measure and reward the offensive value of a piece by counting the number
of enemy pieces it can attack in 3 moves. We could add a bonus if it has the capability to attack weak or undefended pieces,
or squares around the enemy's King. Likewise, we can count how many of our own pieces we can potentially defend with this
piece in 3 moves, adding a bonus for weak pieces, etc.
Instead of adding a bonus for a rook on the 7th rank, why not instead
count the number of enemy pieces that are in the "line of sight" of the rook, including ones that are hidden behind other
pieces. The computer will then move the rook to the 7th rank only if there are unmoved pawns there and can threaten them.
Why not incentivize pieces that collaborate together? For example, give
a bonus when multiple pieces attack an enemy piece.
Instead of adding a bonus for an open file, why not check and see what
damage a rook could actually do if it in fact moved down the open file deep into the enemy's territory.
This way, by rewarding the offensive, defensive and [collaborative] *capability*
of a piece, rather than just where it is on the board, the engine can actually form plans by seeking positions with the potential
for an advantage. The machine will then try to accumulate small positional advantages like the ones I have mentioned.
The software will carefully check each bonus it is awarding to make sure
the position truly merits it. For example, why award the rook of the 7th rank bonus if there are no unmoved enemy pawns?
Evaluating the potential of a position seems to me to be a lot smarter
than just rewarding the placement of pieces on squares.
The task then is to come up with worthwhile goals like the ones I have
mentioned and ways to measure whether or not you are accomplishing them.
Perhaps this is what Vasik is calling "knowledge". His program is already
taking much longer to evaluate each position than any other chess engine. What else could it possibly be doing during its
evaluation?
Vasik has said,
"I have tried to give Rybka both a knowledgeable
evaluation as well as an effective search. My personal opinion is that Rybka's evaluation is better than that of her main
competitors (and very different)"
Hmmmm... "
2. Explanation of the Algorithm
It is my opinion that Rybka maintains a database of "potential
mobility" for each chess piece 3 moves into the future, for each position it evaluates.
It appears that Rybka updates this database dynamically as
it evaluates each new chess position.
This database lets Rybka reward chess pieces for specific
objectives they can accomplish in the future (such as 1 move away from a pin, 2 moves away from defending a piece or 3 moves
away from attacking a square next to the enemy king).
This contrasts with traditional chess programs, which reward
pieces for nearness to the center of the board or for having a large number of moves they can make (a simplification).
The traditional "quick and dirty" evaluation function rewards pieces for sitting on squares. This
works because a piece's position on the board "generally" translates into an offensive, defensive, and collaborative ability.
Any beginner will tell you that he (or she) would rather have a knight prominently placed in the center of the board rather
than on the back rank, unmoved. He or she may not be able to calculate what the piece can do 4 or 5 moves into the future,
but generally a piece is better in the center than on the edge.
But this type of "evaluation" eventually breaks down when we want to build a high performance system.
There are many cases where a piece may need to temporarily sit on the edge of the board in order to accomplish an objective.
Our search process may miss the opportunity to find this move sequence because our evaluation function penalizes the unfavorable
location of the piece on the board.
The advanced evaluation function calculates maps of what the piece can do several moves into the future.
We establish "objectives" and reward our piece if it has the potential to accomplish these objectives. We reduce our bonus
for each move that it takes the piece to accomplish the objective.
Here are some worthwhile objectives: Attacking enemy pieces, defending friendly pieces, attacking
squares near our opponents king (especially involving collaboration), minimizing our opponents ability to attack squares near
our own king, etc. In this way, we are "getting real" (to quote Dr. Phil) about what the piece can do. The bonus we give the
piece is 1. a more precise estimate of the piece's ability to accomplish objectives that have value and 2. operationally based
on "real" things present on the chessboard. Therefore, our evaluation function will be more accurate. It is still an estimate,
but it is more accurate than simply giving a piece a bonus for sitting on a square.
The traditional evaluation is not specific - it is only an
estimate of the piece's offensive, defensive, and collaborative ability, and can cause the machine to waste time searching
many positions that don't matter.
Let's look at what Claude Shannon (born 1916, died 2001),
the father of information theory (and a pretty smart guy) said about the chess playing computer 56 years ago in his groundbreaking
paper "Programming a Computer for Playing Chess"
http://www.pi.infn.it/~carosi/chess/shannon.txt
Shannon describes in this paper the basic software "structure"
of a modern chess playing computer program. His "evaluation function", described in the Appendix, is a little simplistic.
His last section, number 8 "Another type of Strategy", is
of interest.
"The strategies described above [in his paper]
do not, of course, exhaust the possibilities, In fact, there are undoubtedly others which are far more efficient in the use
of the available computing time on the machine."
"...it [traditional chess engine] plays something like
a beginners (sic) at chess who has been told some of the principles and is possessed of tremendous energy and accuracy for
calculation but has no experience with the game."
"To program such a strategy [an advanced evaluation function]
we might suppose that any position in the machine is accompanied by a rather elaborate analysis of the tactical structure
of the position suitably encoded. ...in short, all the facts [knowledge? JLJ] to which a chess player would ascribe importance
in analysing tactical possibilities. These data would be supplied by a program and would be continually changed and kept up-to-date
as the game progressed. The analytical data would be used to trigger various other programs depending on the particular nature
of the position. A pinned piece should be attacked. ...It is not being suggested that we should design the strategy in our
own image. Rather it should be matched to the capacities and weakness of the computer."
So the idea for Rybka's evaluation function can be traced
back to Claude Shannon's original paper on computer chess, although vague. It would appear to have a sound theoretical backing.
3. A Specification for the Rybka/Advanced Evaluation Function
So, what does Rybka's evaluation function look like? The following is
my speculation:
1. For each position it evaluates, Rybka generates "future mobility"
maps for each piece of the moves it can make 1, 2, and 3 moves into the future. It considers moving pieces out of the
way or capturing pieces in order to accurately calculate this "future mobility".
2. It looks at these maps of potential moves and decides on a general
strategy of Kingside attack, Queenside attack, or whole board attack. The move maps we have generated will tell us if we have
an exposed king, weak pawns, or other “triggers” that indicate such an attack will be to our advantage.
It rewards pieces for having potential moves that fit this plan - for
example, if a Kingside attack is decided on, a piece is given a bonus if it can make moves to reach squares on that side of
the board and deep in the enemy’s territory.
3. King safety for Rybka is also evaluated from these “future mobility”
move maps. We penalize our king if our opponent can move pieces into the 9-square template around our king within a 3
move window. The penalty is larger if the piece can make it there in 1 or 2 moves. We penalize our king if multiple enemy
pieces can attack the same square near our King. Our King is free to move to the center of the board - as long as the enemy
cannot mount an attack. We are likewise free to advance the pawns protecting our King, again as long as the enemy cannot mount
an attack on the Monarch.
4.We award a piece a bonus based on how much territory it covers on the
board (and how much damage it can inflict or defensive support it can provide) in 3 moves. This could be in lieu of any fixed
number like 300 for Bishop, 500 for rook, etc. We define certain squares to be "of interest" and reward our pieces extra if
somehow they can reach this square.
5.We give a piece an offensive score based on the number of enemy pieces
we can attack in 3 moves. We give a piece a defensive score based on how many of our own pieces it can move to defend in 3
moves. Again, this bonus is reduced for each move it takes to potentially defend such piece. This is derived from the move
maps. Extra points are given for weak or undefended pieces that we can threaten.
6.Pieces are rewarded for their ability to perform tactical tricks like pins, forks and
skewers 1, 2 or 3 moves into the future. This information is extracted from the "future mobility" database for each position
examined. Testing will be required to see if the particular tactical trick is worth including in the evaluation function.
7.Pawns are rewarded based on their chance to reach the last rank, what
they can do (pieces attacked and defended in 3 moves, whether or not they are blocked or moveable) and how they sit relative
to their neighbor pawns (doubled, isolated, passed). Pawns are awarded a bonus based on the "potential energy" or future mobility
of a Queen that would result if it made it to the back rank, and of course the bonus is reduced by each move it takes the
pawn to get there.
Notice that we did NOT give any piece a bonus for *sitting on a square*
like a traditional chess program. We rewarded the piece for its ability to accomplish strategic objectives.
Here is the bonus that the traditional chess program "crafty" (by Bob Hyatt) gives
rooks and queens for "sitting on squares". Imagine a chessboard superimposed over these tables.
int rval_w[64] =
-3, -3, 1, 3, 3, 1, -3, -3,
-3, -3,
1, 3, 3, 1, -3, -3,
-3, -3, 1, 3, 3, 1, -3, -3,
-3, -3, 1, 3, 3, 1, -3, -3,
-3, -3, 1, 3, 3, 1, -3, -3,
-3,
-3, 1, 3, 3, 1, -3, -3,
-3, -3, 1, 3, 3, 1, -3, -3,
-3, -3, 1, 3, 3, 1, -3, -3
;
int qval_w[64] =
-10, -8, 0, 0, 0,
0, -8,-10,
-10, 2, 8, 8, 8, 8, 2,-10,
-10,-10, 4, 10, 10, 4,-10,-10,
-10, 2, 10, 12, 12, 10, 2,-10,
0, 2, 10, 12, 12, 10, 2, 0,
0, 2,
4, 10, 10, 4, 2, 0,
-15, 0, 4, 5, 5, 4, 0,-15,
0,
0, 0, 0, 0, 0, 0, 0
;
4. Continued Explanation of Algorithm
If we do things right, the 1st, 2nd and 3rd order mobility maps
that we have generated allow us to properly estimate the positional value of the pieces. We can correctly determine if compensation
exists from sacrificing a piece.
If we do things right, we can tell from our mobility maps whether or
not a piece is safe on a particular square.
The technical difficulty is in the “counting” exercise that
goes into generating the "future mobility" move maps. To save time, we can update the mobility database from the previous
position as we move a piece. Most of the mobility information will remain unchanged, or can be moved around with a programming
structure called a "pointer" as we take into account the new potential moves that result when a piece moves on the chessboard.
Ok, so if we sacrifice a pawn the potential energy of the pawn disappears
and the potential energy of our remaining pieces (hopefully) increases. It is the future mobility of our pieces, and the potential
ability to attack or defend, that compensates for the loss of “material”.
Now that we have precisely defined what kind of positions we are looking
for, the search portion can try out different moves. The engine "knows" how to evaluate the positions.
This evaluation aims at precision by extracting information from the
position of pieces on the board instead of looking up numbers in tables.
So that's a first cut at how Rybka works. Rybka seems to be too precise
to have any other algorithm present in its evaluation function.
Do chess pieces have "potential energy"?
I have written about the "potential energy" of chess pieces and the importance of calculating
it and managing it when determining the value of a chess position. This idea may seem new and hard to fathom, but let's look
at some quotes from the following book
The Power of Full Engagement: Managing Energy, Not Time,
is the Key to High Performance and Personal Renewal by Jim Loehr and Tony
Schwartz:
"Energy, not time, is the fundamental currency of high performance." p.4
"Performance...(is) grounded in the skillful management of energy." p.5
"You must become fully engaged." p. 9
"Energy is the most important individual and organizational resource."
p. 197
"Full engagement is a consequence of the skillful management of energy
in all dimensions." p. 197
Optimal performance requires:
greatest quantity of energy, highest
quality of energy, clearest focus of energy, maximum force of energy. p. 199
"Skillful energy management requires summoning the appropriate quantity,
quality direction and force of energy." p. 199
"a (*chess board*) is simply a reservoir of potential energy that can
be recruited in the service of an intended mission." p. 203
I could go on and on here, but get this book and read it if you doubt
what I say.
5. Summary
I have presented my thoughts on how the Rybka software evaluates the strengths and weakness of
chess positions in order to determine the best move in a chess game.
It would be fair to say that my ideas concerning Rybka's
"evaluation function" have not been reviewed by experts in the field of computer chess. I welcome any and all comments (use
the "Sign my guestbook" feature on my home page).
Appendix: Mobility Maps
Potential energy maps for a King knight in the starting position:
click for larger view
1 move map (black knight represents potential move):
click for larger view
2 move map (moving a piece out of the way or doing nothing takes a move):
click for larger view
3 move map (hope I get this right):
click for larger view
If a piece is on our 3-move map for the knight, then it is possible to
attack it or defend it in 3 moves, which include waiting moves or moves which move a piece out of the way.
So looking at this 3-move map and a diagram of the starting position,
I can tell that we can attack 3 enemy pieces in 3 moves. We can defend 9 of our own pieces in 3 moves (the knight cannot defend
itself).
Here are the "Potential energy" maps for King Bishop in starting position:
click for larger view
1 move map (Black bishop represents a potential move):
click for larger view
2 move map (need to count waiting moves or moving pieces out of the way):
click for larger view
3 move map:
click for larger view
So (looking at a diagram of the starting position) in 3 moves we can
*potentially* attack 4 enemy pieces and defend 6 of our own pieces.
Now things are going to get complicated because we are only considering
pieces in their *present locations*. The pieces we are potentially attacking or defending can also move.
The goal of this exercise is to demonstrate how a machine can be encouraged
to form attacking and defensive plans by *accurately* rewarding the placement of a piece based on its attacking and defensive
potential.
The generation of these "maps" is one step the machine could take. The
assignment of points based on these maps is another issue.
The subject of an "estimator"
I'd like to talk about something called an "estimator". We use estimators everyday but probably don't
think a lot about them.
For example, consider your speedometer on your car. You look at it and
it says "55" and so you think that you are going 55 mph. Well, actually this is an estimate of your speed because something
in your car is counting how many times your axle is turning and then "estimates" your speed by considering the diameter of
your tires. If you change the size of your tires your speedometer will not be accurate. Or if you are spinning your tires
in the snow it may say "30 mph" when you are not even moving.
Consider a thermometer. It is an "estimate" of the room temperature that
is based on a little bit of mercury in a glass tube. If you see a display of thermometers in a store they all will read different
values.
Now consider a chess engine. It "estimates" the winnability of a position
by "looking at" thousands or millions of positions and "scoring" them based on a set of scoring rules. Each chess engine will
score a position different, much like the collection of thermometers in a store display. The engine follows a set of rules
to "stop looking at" future positions when it thinks that the possibility is low that play will follow that path.
But which is correct? Well, an engine produces an "estimate" of the winnability
of the game, and so it could be wrong.
How do you go about estimating the winnability of a game? You do 2 things:
1. You come up with a set of "scoring" rules to precisely define "good"
and "bad" positions and
2. You come up with a set of rules for "stopping" your seach for the
best position. Consider hunting for easter eggs. First you determine the "possible" spots for eggs, then you look in the "likely"
spots, and then you give up when you are tired or out of time. There are likely eggs that you missed, but you got most of
them.
In fact, you probably decide that you are going to base your search along
the lines that maximize your chance for finding an egg.
The clock on the wall "estimates" the time. Your car's gas gauge "estimates" how much gas is in your
gas tank.
Now an estimator involves 3 things - there is a "counting" part, there
is a "calculating" part, and there is a "display" part. Your car's speedometer counts how many times your axle revolves in
one second and then calculates your speed based on what it thinks is the diameter of your tires. Your car then moves a dial
on your dashboard a certain amount to indicate speed. A police officer's radar gun measures the frequency shift in radio waves
bouncing off your car and calculates the speed your car must be going from a formula. It then displays the answer as a number
he can read. The Nielsen company conducts telephone polls and mounts devices to TV sets to "estimate" the number of households
that are watching TV programs. Millions of dollars in advertising revenue trade hands based on these estimates. TV sets are
counted that are in use. Calculations are done based on the statistical distribution of people in cities. The results are
displayed on web pages.
Estimators usually take many years to develop, and go through a refinement
process. People keep estimators that are accurate and do not use estimators that are not accurate. People keep estimators
that are cheap and simple to operate and use. They do not use estimators that are complicated, inaccurate or expensive.
Now a chess engine also has a counting part, a calculating part, and
a display part. A chess engine represents a chess board and pieces using numbers in a way that it understands. There is a
counting exercise where the position of pieces on the board are translated into numbers. These numbers are added up into a
score.
But humans don't want to know the scores of the millions of possible
positions. They want to know how "winnable" the position is for White or Black. This would be the score of the position that
is "most likely to result" after several moves have passed, with each side playing the best they can.
A chess engine will look at certain move sequences, and stop looking
further when it decides that play is not likely to proceed down those lines.
After a period of time, the score of the most likely to happen position
is displayed to the operator, as well as the piece and the move associated with it. It is an estimate, a guess, that resulted
from a counting exercise, a calculating exercise, and a searching exercise.
Continuing our discussion on estimators, and finally getting to how a chess engine determines the
score of a position.
First, they are all different, but many share similarities.
This is how crafty scores a bishop:
Give a bonus for what square
it is on, and add another bonus based on how many moves it can make. Reward the piece for being close to the enemy's king.
Handle unusual cases where bishops are blocking pawns or are filling voids near our own king.
actual "king tropism" code:
tree->w_tropism -= king_tropism_b[Distance(square,
BlackKingSQ)];
Here is the actual table that is used to compute the square bonus. Imagine
this superimposed over the chessboard.
int bval_w[64] =
-16, -16, -8, -8, -8, -8, -16, -16,
-16, 2,
0, 0, 0, 0, 2, -16,
-4, 2, 2, 2, 2, 2, 2, -4,
-4, 2, 4, 4, 4, 4, 2, -4,
-4, 2, 6, 6, 6, 6, 2, -4,
-4, 2, 6,
6, 6, 6, 2, -4,
-16, 2, 4, 4, 4, 4, 2, -16,
-16, -16, 0, 0, 0, 0, -16, -16
;
So, once again, we see evidence that chess engines are not overly concerned
with the exact number of moves it would take to attack or defend a piece. We generally reward it for being "close" to the
enemy's king, being "near" the center of the board, and being able to move freely 1 move into the future.
We handle each piece, giving points for things we generally want this
piece to do. We are lazy so we generally use look-up tables instead of counting things. We give rooks bonuses for sitting
on an open file - regardless if they can actually do anything if they moved down that file.
We now add up all the components of our "evaluation function" to get
the total score for the position under consideration. Sometimes this score is accurate, and sometimes it is not. That's ok.
It's an estimate of the value of the position. We will order our moves based on the estimated score and search a large number
of them. The "bad" moves we will "prune" from our search tree.
Now, this type of estimator has worked well in the past. But can we do
better?
How do you build an estimator?
Well, there is no rule to build an estimator. They are usually constructed
by people who study an effect for a long period of time.
If you want to build an estimator to evaluate the value of a chess position,
you need to begin by looking for things to count that have value, and then figure out a way to scale the value of these "countable"
things that results in a precise "evaluation".
Here is a quick and dirty estimator for the value of a chess position:
Look at the pieces on the board. Give 900 points for a Queen, 500 points
for each rook, 300 points for each Knight and Bishop, 100 points for each pawn.
For a Bishop and knight, give a bonus based on the distance it is from
the center of the board. Give a bonus for being close to the enemy's king.
For each Rook, give a bonus for sitting on an open or half-open file.
Give a bonus for sitting on the 7th rank (regardless of what other piece is near it).
For a queen rook and Bishop, give a bonus for each potential move we
can make. Give a bonus for being close to the enemy's king.
For each King, determine the King safety. This can be as simple as a
bonus for sitting on a corner square such as h1, g1, g2 or h2. Take into account the pawn structure around the king.
For pawns, give a bonus for advancing, and give a large bonus if there
is no pawn blocking a direct advancement to the last rank. For these "passed" pawns, take away points if our opponent can
block the advancement with a piece. Give a penalty for doubled pawns or isolated pawns.
Now, we need to do certain other things, such as "extend" our search
if captures are possible (which might change the material balance).
This simple evaluation function (or variations on it) can be found in
most chess engines. It works surprisingly well. It can be calculated quickly.
Notice that we are not counting the precise attacking, defensive or collaborative
value of the piece. Being near the center of the board "roughly" translates into a good offensive, defensive and collaborative
potential.
Now what if we actually calculated, for each piece, the number of moves
it would take to attack the enemy pieces? What if we calculated the number of moves it would take to defend our own pieces?
Wouldn't this be a more precise "estimate" of the value of the piece? We could give a small bonus if an enemy piece could
be attacked in 3 moves. We could give a larger bonus if the piece can be attacked in 2 moves. An even larger bonus if we can
attack it in 1 move.
This will encourage our computer, which is rather dumb, to move
its pieces to squares where they are "fully engaged" in the battle to outmaneuver the opponent. We will have maximized the
offensive, defensive and collaborative potential of the piece.
Let me now drop my main idea here.
Rybka does not use look-up tables in its evaluation function.
Well, look up tables are an inexact estimator. They can only get you
so far, and someone would have hit on the precise values a long time ago if this method worked.
Vasik found a way to derive the same information by counting things present
in the position of pieces on the board. This is why Rybka is so slow.
However, he can now drastically cut back his search tree (search fewer
positions) because he can now be sure that he is not missing a good move.
That is my idea.
"Database of Future Mobility" Explained
Ok - this idea has to do with the move maps that I discussed on April 12 and 13. This is an advanced
idea dealing with data structures so if you don't get this don't worry.
Let's say we have this position:
click for larger view
Now for the Bishop "future mobility" we set up a table: Upper Left Arm:
c6 b7 a8 anchor: a8
Upper Right Arm:
e6 f7 g8 anchor: g8
Lower Left Arm:
c4 anchor: c4
Lower Right
Arm:
e4 f3 g2 h1 anchor: h1
ok. so we want to regenerate the move map if the Knight on c4 moves to b2. So we look
at our tables and we see that c4 is on our Bishop's mobility map under "Lower Left Arm". We only have to recompute the Lower
Left Arm of the Bishop's mobility, The other "arms" stay unchanged. ok. so what if we move the pawn up to e6? Well, e6 shows
up on our Bishop's mobility map for the upper right arm. We would have to recalculate that, but the rest of the mobility map
remains unchanged. ok. so what if the bishop moves from d5 to f7? Well, the e6 pointer moves from the Upper Right Arm to the
Lower left arm, which also now has an d5 entry, and we have to recalculate the Upper Left Arm and the Lower Right Arm of the
mobility table, but the rest of the Bishop's mobility data structure stays the same.
The point here is that calculating future mobility maps for pieces doesn't
have to be an excessive exercise because most of the future mobility data stays the same from the previous move. If we set
up our data structure correctly, we will immediately know what part of our mobility maps we have to recompute.
This is in response to arguments that calculating "future mobility" is
too processor intensive to work. We would actually reuse most of the mobility information for each piece, so this saves processor
time. This example only deals with one level of mobility, but some will see how I plan to use recursion to extend this idea
to mobility several moves into the future.
Consider the following position:
click for larger view
A traditional chess engine, when asked to evaluate this position, will
give pieces bonuses based on the square it occupies and possibly for the number of moves it can make.
Rybka will know what each piece can do 3 moves into the future. Therefore,
it will "know" that the Bishop can move Be3-d4-a7 and therefore is 1 move away from pinning the Knight to the King. It will
give the Bishop a bonus for this, and an even larger bonus once it moves to e3, since it will then be performing the pin.
A traditional chess engine will figure this out, but only after a few
additional "plys" of search. This will include perhaps many other positions that should not have to be looked at.
Rybka uses "knowledge" of future moves to focus its search. The positions
that are looked at are fewer, but are more likely to be related to the main line of play. This also happens to be similar
to how a human plays chess.
A definition of Knowledge
"Knowledge is a physical, mental or electronic record of relationships
believed to exist between real or imaginary entities, forces and phenomena." Worthington, 2005.
In the context of chess, the "entities" are the chess pieces and the
"forces" are the potential moves of these pieces.
I have speculated that the "knowledge" spoken of by Vasik Rajlich in
his chess engine Rybka is obtained by building a database of the potential mobility of each chess piece 3 moves into the future.
Pieces are then rewarded not by the squares they are sitting on, but what they can actually do. Examples are attacking pieces,
defending pieces, attacking the opponent's King, defending our own King, pefroming pins, forks, skewers and the like. A piece
can even be rewarded if it is 1 move away from performing the pin. This will focus the search function on likely moves. Even
if the pin is not possible (the enemy is preventing us from doing this) the search will look for ways to remove obstacles
so the pin can be performed.
Technically, it can be called a "knowledge focused search", and it is
a new way of constructing a chess engine.
Quotations concerning Knowledge
Rybka claims to have a knowledge-rich evaluation function, so let's look
at some quotations which address knowledge.
Knowledge is power.
Sir Francis Bacon (1561 - 1626), Religious Meditations,
Of Heresies, 1597
Knowledge is only potential power. Napoleon Hill
Knowledge must come through action; you can have no test which is not
fanciful, save by trial. Sophocles (496 BC - 406 BC), Trachiniae
Mankind have a great aversion to intellectual labor; but even supposing
knowledge to be easily attainable, more people would be content to be ignorant than would take even a little trouble to acquire
it. Samuel Johnson (1709 - 1784), quoted in Boswell's Life of Johnson
Imagination is more important than knowledge. Knowledge is limited. Imagination
encircles the world. Albert Einstein
The only source of knowledge is experience. Albert Einstein
There are only two kinds of people who are really fascinating--people
who know absolutely everything, and people who know absolutely nothing. * Oscar Wilde (seems to apply to chess engines)
You can know the name of a bird in all the languages of the world, but
when you're finished, you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's
doing -- that's what counts. I learned very early the difference between knowing the name of something and knowing something.
Richard Feynman (1918 - 1988)
Knowledge + Application = Success Leslie T. Giblin
|
