Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Just learning capability?

Author: Dann Corbit

Date: 16:18:45 06/13/00

Go up one level in this thread


On June 13, 2000 at 17:09:12, Mogens Larsen wrote:
>On June 13, 2000 at 16:28:44, Dann Corbit wrote:
>>On June 13, 2000 at 15:58:49, Mogens Larsen wrote:
>>>On June 13, 2000 at 15:40:53, Tom Kerrigan wrote:
>>>>How is an opening book any more or less inherent to a chess program than an
>>>>evaluation function? That's absurd.
>>>>-Tom
>>>
>>>I don't find it absurd at all. A chess program can function without an opening
>>>book, but no without an evaluation function AFAIK. Not comparable IMHO.
>>
>>A chess program needs only one thing to play chess:
>>A legal move generator.
>>
>>No evaluation is needed.  When there are no more legal moves, the game is over.
>
>It doesn't even need a move generator. When there's no more time the game is
>over (sic.).

Exactly.  And (as you can imagine) each level of sophistication requires more
data!

A program that waits for time to expire is as simple as this:

int main(void)
{
while (1) {;}
return 0;
}

A move generator plays legal chess.  Now let's add material evaluation and two
ply look ahead instead of 1.  It still stinks at chess.  Material evaluation is
surely also gained from humans.  After all, what's a queen worth and who says
so?  What about two pawns that form a pair of trousers -- whose idea was that --
did the computer invent that notion?

The really good evaluation functions have a ton of smarts gathered from (you
guessed it) human brains.

Every atom of "brainpower" that a chess program throws at the game of chess came
from human brains.  A huge portion of that data is (in fact) chess knowledge
gathered from expert humans.  A guy who hardly knows the rules of chess writes
an eval function.  Will it be any good?  Not likely.

Trying to separate the data from the programs is absurd.  In fact, if you look
at the C++ object paradigm, you will see the incredibly tight binding between
object data and object methods.  Rather than some cosmic accident founded by an
ivory tower type, this actually reflects reality rather nicely, which explains
the profound impact of OO programming.

Programs *are* _algorithms_ that operate on _data_.  No algorithms, no programs.
 But (equally) no data, no programs either.

When trying to cripple a chess program so that a mere expert can beat it, you
might separate off some pile of data and say, "This is a special pile of data.
It's unfair to use this data."

If you happen to pick the most sensitive data, you are likely to weaken the
program significantly.  However, attacking the endgame tablebase files won't
gain you much.  It will only make the program beat you less artfully in the end.
 And even the opening database data (while - admittedly - more important than
endgame tablebase data) is not the achilles' heel.  If you want to strike at the
heart of a chess program, simply remove the data from the eval function.  Now
we'll see who plays crappy chess.  Essentially, what you will have is my
retarded move generator chess program.  The GM's won't have much problem with
that, but neither will anyone else for that matter.

So I say, target a better set of data -- the eval information.



This page took 0.03 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.