Author: Robert Hyatt
Date: 10:29:46 11/13/01
Go up one level in this thread
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. > >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.