Author: Robert Hyatt
Date: 15:14:01 11/13/01
Go up one level in this thread
On November 13, 2001 at 13:48:30, Miguel A. Ballicora wrote: >On November 13, 2001 at 13:29:46, Robert Hyatt wrote: > >>On November 13, 2001 at 11:22:47, Uri Blass wrote: >> >>>On November 13, 2001 at 10:13:25, Robert Hyatt wrote: >>> >>>>On November 13, 2001 at 09:16:09, Uri Blass wrote: >>>> >>>>>On November 13, 2001 at 08:31:09, William Penn wrote: >>>>> >>>>>>I suspect this has been discussed before but I didn't pay attention, so please >>>>>>pardon my redundancy. If you could just point me in the right direction, much >>>>>>appreciated... >>>>>> >>>>>>Can't we make some assumptions without compromising very much practical playing >>>>>>strength and significantly reduce the size of the endgame tablebases? For >>>>>>example it seems a waste to generate separate positions for "white to move" and >>>>>>"black to move". >>>>> >>>>>It is also a waste of space to remember the exact number of moves to mate and >>>>>knowing the number of moves divided by 2 is enough and if you know it you can >>>>>calculate the exact number of moves to mate. >>>> >>>>I don't see how that will work. If I probe deeply in the search and get two >>>>mate scores of "mate in X" how will I be sure I take the path toward a mate >>>>that is one move closer than I am at now? Because it is possible that the >>>>next search I do will (at best) be able to find a mate in X-1 if we have real >>>>mate scores, but with this /2 stuff we only find mate in X again and never >>>>move closer. >>> >>>If you do not see a forced mate there is no problem because changing scores of >>>mate in X to mate in different number of moves will change nothing in the move >>>that you choose. >> >>There is a huge problem if you are forced to choose between a mate you can >>see and a mate you can't. you will _always_ choose the mate from the EGTB, >>and since you don't know how deep it is, how do you _guarantee_ that you always >>move closer to the mate, rather than just making moves that stick with a >>mate that is not getting any closer? Perhaps until the 50 move rule will make >>it impossible to reach? >> >>> >>>The only problem is when you see a forced mate and you do not know the exact >>>distance to mate. >>> >>>Even in this case if I ignore the 50 move rule there is no problem in the first >>>move that forced the mate and the 50 move rule is also a problem with the >>>original tablebases. >> >> >>But you have made the problem _much_ worse. If I find what _should_ be a >>mate in 30 or a mate in 31, it will look like a mate in 15. And I may well >>keep going for a mate in 31, never getting closer, until I see the 50 move >>rule counter force me the other way. But now it is too late and it is a >>draw. >> >> >> >>> >>>In the second move I can continue the search in every tablebase hit to see if I >>>can get closer to mate in the next ply and to calculate the exact distance to >>>mate(if I can get closer to mate in the next ply then it is mate in 2x moves and >>>if I cannot do it then it is mate in 2x+1 moves). >> >>That simply won't work _inside_ a search. Probes are already expensive >>enough. Doing an additional 2 ply search to find a mate in N-1 score is >>too expensive. > >No because at this point you do the search on the root. How? The move at the root has 5+N pieces left. I am not yet in a tablebase position there. I am finding these mate scores _deep_ in the tree, and I can't tell a mate in N from a mate in N+1 out there. So serendipity will cause me to play the N or N+1 move. If I happen to choose the N+1 move I might be going for a never-ending cycle since I may never get to 5 pieces at the root, I just keep shuffling pieces to keep the ability to make a capture in the future that gives me a mysterious mate score. > >I do not see that Mate in 31 or mate in 30 is more or less useful when >it is probe on the tree. Even W/L/D will be useful too. >On the root, i think that Uri's idea is wonderful. Once you are at the root, it is fine. Even though it saves 12.5% of the space only (and 1/2 of that for the 6's that will need 16 bit values). But I don't see what to do way out in the tree. If _every_ score is just "winning or losing or drawing" I could see problems. I saw a program in 1970 lose a won game (Coko IV) because it didn't have "ply" encoded into the mate scores and it kept making mate in 2 moves until the opponent promoted a pawn and mated it instead. It seems to me that you have to have _something_ to pull you toward a steadily shorter mate. That is why in Crafty, after announcing a mate in N, I _demand_ that the next search find a mate in N-1, or it must keep searching until it uses the full time limit. Once it finds the N-1 mate, it can stop the search immediately. > >Regards, >Miguel > > > >> >> >> >> >> >>> >>>It means that I need after finiding mate to use special search on every >>>tablebase hit in order to see the exact distance to mate. >> >> >>It also means your basic search depth is going to take such a hit that you >>are probably going to lose many games _before_ you actually get into a tablebase >>position _at the root_. >> >> >> >> >>> >>>Using special search is slower but the program also got closer to mate so I >>>believe that it can practically find the mate. >>> >>>Uri >>> >>> >> >> >>The point _must_ be to win more games. Not fewer. Doing tree searches thru >>tablebase scores is a sure way to lose games due to very shallow searches >>before you actually reach TB positions on the real board. >> >> >> >> >>>> >>>>To save 1 bit, that seems like a tough problem to handle, not to mention that >>>>it will also cost more in the indexing code since the scores won't be on one- >>>>byte boundaries any longer. >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> Surely there is a reasonable simplification in that regard >>>>>>based on symmetry. >>>>> >>>>>Symmetry is used in building the tablebases >>>>> >>>>> >>>>> Promotion of a pawn to less than a Queen is rare and could be >>>>>>disregarded. >>>>> >>>>>This is going to save time in generating the tablebases with pawns but it is not >>>>>going to chnage much the space that is needed for the 3-4-5 piece tablebases. >>>> >>>>It will also produce wrong answers... >>>> >>>> >>>> >>>> >>>>> >>>>> Perhaps castling can be disregarded because it seldom happens in >>>>>>the endgame. >>>>> >>>>>It is already disregarded. >>>>> >>>>> I suppose we must keep en passant(?). I'm guessing that the size >>>>>>could be reduced to perhaps only 1GB for all of the 3-4-5 piece positions vs the >>>>>>current 7GB. >>>>> >>>>>Part of the 7GB is for generating unimportant tablebases of a king and three >>>>>pieces against a king when there is no position with king and 3 pieces against >>>>>king when programs cannot win. >>>>> >>>>>Uri
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.