Author: Miguel A. Ballicora
Date: 10:48:30 11/13/01
Go up one level in this thread
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. 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. 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.