Author: KarinsDad
Date: 23:39:37 04/16/99
Go up one level in this thread
On April 16, 1999 at 18:04:04, Dave Gomboc wrote: [snip] > >>If you can find algorithms to solve the simple (relatively speaking) endgame >>problems, wouldn't that be a step towards solving more complex ones or even >>making the search/evaluation more sophisticated? > >You haven't convinced me that it would be. Let's take for example h pawns. In KPK, it is easier for the lone king to stop an h pawn (in a lot of positions) than it is to stop an f pawn (assuming all 3 pieces are shifted to the left 2 squares). The h pawn is a special case where if you changed the position to KBPK where the bishop does not control the queening square, you have the same result. So, it would seem that there may (or even should) be other similar special cases where some of the knowledge of the 3 piece position is applicable to a 4 piece position. However, once you get beyond 4 pieces, it becomes extremely difficult for humans to distinguish the "special cases" where this may occur. > >>The how is a totally different matter. That is why I brought up the question in >>the first place. If I knew exactly how, I would put this into my program and >>thumb my nose at all of those fancy programs that are limited to 5 piece >>tablebases. It is extremely difficult to solve for some cases (I do not deny >>this), but I also do not throw in the towel and say, "Oh well, we have >>tablebases, why do we need that?". > >Tablebases encapsulate (roughly) perfect information. That's about as good as >you can do. If you want to construct a decision tree that decides which >positions are mates in 52 and which are mates in 173, feel free, take an ID3 >engine or whatever and hammer at a tablebase. The decision tree it spits out is >extremely unlikely to be of much use to a human chess player, though, so I don't >see a particular purpose in doing so. If you just want to classify "win/draw", >well that would work, but how will you guarantee that progress is made? >Intermediate levels of resolution are possible, but since we have perfect >information, I see no particular reason to give it away. > I do not think that I would want to do any of the things that you mention here. >>I would think that since most of us programmers are not GMs and therefore do not >>have good endgame technique ourselves, that the first place to examine is the >>current tablebases. It would be easier for us to dissect those with a program >>than it would be to figure out algorithms on our own. > >It would be easier to grab a book like "Levenfish and Smyslov: Rook Endings" and >become a GM! :-) > >>Also, if you save hard disk space by calculating the best moves on the fly and >>minimizing the tablebases that we do have (as per my earlier posts), then the 6 >>and 7 piece tablebases will also be smaller and we may find certain ones of >>those that are more easily solved via a 4 piece or 5 piece table (if we can >>re-use the algorithms). > >Calculating the best moves on the fly is something that would have to be done >quickly, i.e. in less than the amount of time the disk I/O you are replacing >would take. Is this possible? Perhaps. Of course, if your tablebases are >preloaded into memory (like Chinook) then you will have a very tough time >searching faster than a hash table lookup. This may be true for blitz, but in more standard times where the program has 3 minutes per move and already has a score from the tablebase, it usually will not matter once it gets to a winning (or drawn) 5 piece position that it takes 1 second, or 5 seconds, or 10 seconds to calculate the best move each time. It will still use a tablebase to get the score for a given position and it will take no extra time to use that in "normal evaluation mode". I totally understand your position of "Well, if you used the tablebases as is, then you would have the move as well.". However, if sophisticated knowledge CAN be gleaned from this type of research, then it may be possible to create partial or entire 6 piece tablebases based on calculations and not on exhaustive search. Instead of this taking 10 years, it might take 1 year. It may also be possible to discover unknown endgame techniques usable by human players. We won't know unless we try it. > >>So, you tell me. Will this take a lot of work similar to the CAPPS (spelling?) >>project? Yup. Will this help make the endgames of programs stronger in the >>future? Probably. Do we know exactly how to do it? No. That's what this forum is >>about: discussing possibilities. >> >>KarinsDad :) > >I'm discussing reasons why a possibility has remained "a possibility" for a long >time. What's wrong with that? :-) Not a thing. In fact, that's why I am here: to discuss various possibilities. And I especially like to do that with people like yourself who stretch MY thinking. KarinsDad :) > >Dave
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.