Author: José de Jesús García Ruvalcaba
Date: 08:42:25 04/17/99
Go up one level in this thread
On April 17, 1999 at 02:39:37, KarinsDad wrote: >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.". > Once the root position is a tablebase position it does not matter a lot how long it takes a tablebase probe, it can be made even from a slow CD. The problem is when the root position is not a tablebase one, and the program is reaching a lot of tablebase position in the search. That means a huge amount of tablebase probes to make a move. And yes, then the probe time is critical, even at standard time controls. >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.