Author: Dann Corbit
Date: 11:39:10 01/30/02
Go up one level in this thread
On January 30, 2002 at 04:57:47, Uri Blass wrote: >On January 30, 2002 at 01:56:33, Dann Corbit wrote: > >>On January 30, 2002 at 00:03:19, Robert Hyatt wrote: >>>On January 29, 2002 at 13:58:20, Dann Corbit wrote: >>>>No. His notion is that if you mirror using every symmetry, the total number of >>>>those positions (including ALL reflections) would be less than 2^81 in that >>>>category. >>> >>>OK. You are a math guy. If you allow for 8 symmetries, which is false for >>>positions with pawns, you reduce the number of bits by a factor of 8, which >>>is 3 bits. That is the mistake that is being made here, unless I misunderstand >>>something seriously. IE for king vs king, allowing _all_ possible permutations >>>even with two kings on one square, you get 64^2 positions, which is >>>2^12. If you take into account 8 symmetries, you reduce that to 2^9 positions, >>>not 2^(12/8)... >> >>Let's suppose that you need 170 bits to encode a chess position. Now, with that >>position [for instance], you may have automatically stored 50 permutation of it. >> The net number of bits needed to store each of those 50 positions is 170/50 = >>3.4 bits. > >you said >those positions (including ALL reflections) would be less than 2^81 in that >category. > >Based on the same wrong logic in this case you can say that >those positions(including ALL reflections) would be less than 2^3.4 in that >category. > >It is clearly wrong. Les made an example. Note that he is not talking about all board positions, but a subset of them. ><snipped> >>>How can there be more than 8 "reflections"? you can find symmetry along thhe >>>vertical center, horizontal center, and the two diagonals. >> >>Well, they are actually more than just reflections. > >They are not the same position and I do not see how the fact that there are a >lot of positions that you can get the same position from them help you >practically to generate smaller tablebases. They are not tablebase files in the standard sense. They are "At least as good as this" tables. So, if Les can show a mate in 8, there *might* be a shorter mate, but it will be no worse than a mate in 8. The reason that the tables are much smaller is not that it takes less bits to encode a position. It takes (as you have seen) the same number of bits. But only 1/50th (or whatever) of the positions are needed to be stored. *THIS* is the thing that reduces the size of the files by a constant, large factor. An interesting thing about this approach is that it can use *any* analyzed position and create dozens (or potentially even hundreds) of possible solution moves. Now, the format Les showed is not a good one when the board is full of pieces. That much is clear. But it isn't too bad when there are 3 or 4 pieces on the board. >I am sure that it may be possible to compress the data of tablebases but the >information does not tell me how to do it. I have not gone over the math in Les' document yet, and I am not totally sure what he is trying to say about 2^81. But I do know that his method will compress better than anything else that is available.
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.