From: "Russell Reagan"
Date: 29/07/03 03:59 GMT Daylight Time
Message-id: CqlVa.3137$Oz4.39@rwcrnsc54

"Mhoulsby" -remove- wrote

Interesting. So why bother with tablebases at all?

There are times to use them. For instance, if the current position on the
board is a tablebase position, then it is probably a good idea to use them
(especially with pawn endings). The debate over their usefullness starts
when people start using tablebase results during a search (while the
computer is "thinking"). For instance, let's say that the computer is close
to the endgame, and it is looking 15 half moves ahead. Maybe the first 10
half moves are NOT in the tablebases, but the last 5 moves are. This means
that the program is going to do a _lot_ of reading from the hard drive, and
reading from the hard drive is much slower than reading from the computer's
main memory. The problem is that those scores from the tablebases are 10
half moves away, so many of them won't be used. So there is an advantage of
using tablebases in the search (you have "perfect" knowledge), and there are
disadvantages (it is slower). The result is that using tablebases ends up
giving the same results overall, in the long run. There have been many
people experiment with this. I would suggest searching the Google newsgroup
archives or the Comptuer Chess Club archives for this information if you
want to know more.


I agree entirely with this, and it seems to support precisely what I was
arguing in the subthread to which my link was directed.

This is (part of the reason) *why* programs play badly in endgames - they are
in a quandary, do they go for a TB (if it's an absolutely forcing line which
leads to at least a draw [assuming the position to be roughly level] then the
answer, clearly, would be "yes"). In complex endgames, however, it's rare for
circumstances to be so clear-cut - which explains the quandary which you
describe.


Substantiate not just with near 100% statistics but with *practical
examples*
of programs playing endgames practically as well without tablebases as
they do
with tablebases...

You seem to miss the point. There _are_ practical examples that will give
support for and against tablebases, but that is beside the point.

No, it isn't. It's precisely the point.

If there were 32-man tablebases, then there would be no problem.


There are
two kinds of positions we can talk about here. In positions where you are
not actually in a tablebase position (but you're close), then what I
described above happens, and you get better "knowledge", but you search
slower, so the net effect is that the program doesn't play any stronger. The
other case is that you are in a position that _is_ in the tablebases, and
then it is a good idea to use the tablebases I think.


Clearly.

Most decent chess engines will play very close to the tablebases.

Really? I hadn't noticed (which may simply be my ignorance - if so, please post
examples).

If they
don't choose the "best" move, they still choose a winning move, and that is
enough. I think you will find relatively few cases where a computer
completely has no idea, and causes the game's result to change.

I posted a few in the subthread. There are more....


What I mean
is, I can give you a position where the pawns are completly locked and it is
a clear draw because neither side can make any progress. You can give one
side an extra rook, and the computer will evaluate it as approximately +5
for the side with the rook, and people like you will go around waving their
hands shouting about how horrible computers are at the endgame.

"People like me"? What does that mean. The above is self-contradictory. Here's
why: we have all 5-man and some 6-man tablebases. Now, I'm not sure which 6-man
tablebases exist, because I don't have them loaded on my HD. Let's assume,
however, that we *do* have the tablebase for, say: KPPkpp (which we don't,
since that would imply our having *all* 6-man TBs) How, then, might one
construct a position to which this tablebase pertains in which the pawns are
"completely locked" and neither side may make progress?

If one side has "an extra rook", can you construct *any* position from, say,
KRPkp in which the pawns are locked and the rook does not have the freedom of
the board.

This, I suspect, may be the point which *you* are missing...

But, think
about that situation. The computer may misevaluate the position, but it is
still going to get a draw, just like the human, and tablebases aren't going
to help that.

They would if they existed. That's the point. They don't.


The number of positions where tablebases will change the
result of a game are very few.

The number of positions with respect to which tablebases will change the result
of a game is indeed very few, precisely *because* (as yet) there are *so few
tablebases*. Ergo programs play badly in known endgames positions which are not
tablebases....

I'm sure they exist, and if you post a
hundred of them that doesn't mean computers play the endgame horribly.

Of all the phases of the game, computers play the opening the worst.

Absolutely.

Fortunately most commercial programs have very good opening books :-)


Yup.