Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Endgame code instead of Tablebases

Author: José de Jesús García Ruvalcaba

Date: 08:53:10 04/17/99

Go up one level in this thread


On April 17, 1999 at 02:08:01, KarinsDad wrote:

>On April 16, 1999 at 20:00:08, Les Fernandez wrote:
>
>>
>>Hello and welcome Karinsdad,
>>
>>This subject caught my attention since just about 2 weeks ago I spoke with Dann
>>Corbit, founder of the C.A.P. project about this very question.  I always
>>wondered given a certain endgame position, ie any position which was based on
>>say KR vs kn as Bruce's example, if we understood the theory in this 4 piece
>>ending.  Since we know according to tablebases that positions exist that lead to
>>wins, draws and loses, it implies that atleast in the win case scenario that
>>some logical understanding about that particular set of pieces has to exist.
>>The big question is how do we find it.  Perhaps their may be several viable
>>approaches.  Maybe a piece of software designed to look for pattern recognition,
>>etc.  Anyway I tend to agree that if these collections can be handled via an
>>algorithm vs tablebase that would be a tremendous contribution to the field.
>>And lets say that several collections solutions can be found, then we could
>>remove that part of the egtb thereby shrinking it down as progress is made.
>>Anyway I am glad you brought up the subject for I believe this area of research
>>could be very interesting.
>>
>>Les
>
>Yes, my thoughts exactly. There is an interesting article on Efficient
>Interior-Node Recognition written by Ernst Heinz at
>
>http://wwwipd.ira.uka.de/Tichy/DarkThought/
>
>which illustrates some of the difficulties with just assigning a w/l/d to a
>position (i.e. a "real" score must be assigned), however, that is just the tip
>of the iceberg (Ernst has a lot of really good material there).
>

	Ernst has one the best computer-chess websites. I wish DarkThought a good
performance in the WCCC/

>One of the issues here is whether there would be a real gain by doing this type
>of thing. A counter-position for not doing it is that we already have the 5
>piece tables. Once we get to 6 piece tables (many years down the road), hard
>disk space will be even cheaper, so that is not a problem. The issue I have with
>this position is "So what?". If even one method for solving a certain type of
>chess endgame which can be used by humans is discovered by this type of
>research, then it is worthwhile (and even if this doesn't occur, how can you
>find out that it does not occur if you do not try).
>
>The 4 piece cases are difficult enough. Going to 5 and 6 will probably be a
>nightmare if some fundamental patterns or chunks are not discovered in the 4
>piece cases (ditto the 3 piece cases).
>
>A simple "hard disk" savings estimation may be:
>
>If 50% of the average 3, 4, and 5 piece tablebase case is a win, 35% is a draw,
>and 15% is a loss (just throwing totally unsubstantiated numbers out here), then
>if you may be able to compress the tablebases for this type of solution by 50%
>right off the top since 50% of the positions result in the default result for a
>particular tablebase. Some tablebases might be compressed even more (such as KQ
>vs. K, KR vs. K, KBN vs. K) since half of those tables are automatically the
>default result (i.e. if it is the side with the material advantage to move, that
>side can force a win; and yes, there is a small percentage of cases where this
>is not true for KBN vs. K).
>

	How are the tablebases compressed by 50% in that case? Please elaborate, as I
do not get your point.


>However, since Ernst's paper indicates that you need real scores assigned, it
>may be difficult to come up with a default result mechanism that works well. And
>if this is true, my thoughts on removing the "best move" for a position (and
>saving space that way) is also off since that would have to be replaced with a
>score anyway. So, it is obvious that a lot more thought has to be put into this.
>

	Removing the "best move" from what? Current tablebases (Thompson's, Edwards'
and Nalimov's) do not store a best move for a position.

>And there are other potential issues such as "the algorithmic approach works
>fine, however, it is much slower than looking it up a tablebase, so it is
>unusable in blitz", etc.
>

	Tablebases stored on hard disk are hard to manage, because they are slow to
probe, even at standard time controls. Something even slower would be
practically unusable even at standard time controls. I do not see a big
difference between standard and blitz in this case, as at standard time controls
tablebase probes will be hitting before, because the program has more time to
move and a variation can lead to a tablebase position from a position with a
relitively high amount of pieces on the board.

>I'm hoping though, that two things could be accomplished with research of this
>type. One is to remove some tablebases completely. The second is to discover
>some new endgame theory (i.e. maybe some set of patterns) that humans can apply
>to solving certain types of complex endgame problems.
>
>KarinsDad :)
>
>PS. Has anyone read in the ECE and compared it's findings to the tablebases? And
>if so, have discrepencies been found between the two?



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.