Author: Uri Blass
Date: 08:22:47 11/13/01
Go up one level in this thread
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. 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. 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). 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. Using special search is slower but the program also got closer to mate so I believe that it can practically find the mate. Uri > >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.