Author: Christophe Theron
Date: 07:40:19 12/24/03
Go up one level in this thread
On December 23, 2003 at 20:42:39, Dann Corbit wrote:
>On December 23, 2003 at 18:18:17, Christophe Theron wrote:
>
>>On December 23, 2003 at 17:43:27, KarinsDad wrote:
>>
>>>On December 23, 2003 at 16:53:44, Dann Corbit wrote:
>>>
>>>>On December 23, 2003 at 16:35:02, KarinsDad wrote:
>>>>
>>>>>Another point is that you only need 62 bits to indicate piece/pawn location (the
>>>>>position of the kings is already known).
>>>>
>>>>With these two changes, you need a maximum of 166-4 = 162 bits to store a chess
>>>>position. Is that about what you had achieved befire?
>>>
>>>I do not remember what I had come up with before. At the moment (just messing
>>>around with it today at work since it is the holidays), I am probably in the
>>>ballpark of about 162 bits or so, but that is not verified quite yet (most
>>>standard positions are currently maxing at about 156 bits or so).
>>>
>>>20 bytes is the goal I think.
>>>
>>>Hopefully, I'll have my encoding schemes from before somewhere at home. I don't
>>>think I ever made it to 160 (161 or 162 sounds about right). Something to look
>>>at over my holiday vacation.
>>>
>>>
>>>>At any rate, it limits the maximum possible number of legal board permutations
>>>>to no more than:
>>>>2^162 = 5846006549323611672814739330865132078623730171904 possible positions.
>>>>(about 5.846e48)
>>>>
>>>>This does not (of course) take into account things like the half-move clock and
>>>>position repeat status.
>>>
>>>What is half-move clock???
>>>
>>>I've never considered position repeat status to be critical to position
>>>information, but if you do consider it so, it is normally +2 bits (0 repeats, 1
>>>repeat, 2 repeats). However, I have a way to hide this in the current sized data
>>>encoding as well. Thanks for mentioning it. ;)
>>
>>
>>
>>Welcome back KarinsDad.
>>
>>I don't think that repetition status for the stored position would be of any
>>use. The only useful information for draw-by-repetition or 50-moves-rule
>>detection is the position history itself (in the worst case it could include all
>>the positions of the current game), so I think you can just forget about storing
>>that repetition info in the position itself.
>
>We abandon that information from storage, since it increases the size, and game
>play naturally produces it as a consequence of making the moves. And yet, the
>positions really are distinct. The exact same board layout with the same side
>to move, castle rights etc. can go from being a draw to a checkmate or a loss
>depending on those two pieces of information. Of course you know that, and I am
>stating the obvious. But I want to point out that we are numbering distinct
>board piece distributions and we cannot use this to number chess moves in total.
> We can only say how many distinct combinations there were when ignoring the
>draw by repetition or 50 move rule status. Of course, we *could* add that back
>in, but it adds quite a bit in size. The 100 ply counter needs 7 bits and the
>3-repeats needs 2 bits. Another ten bits! And after all that work wheedling
>down the size.
Please explain how storing anything that has to do with 50 moves rules or
position repetition in the compressed would help avoiding considering the whole
game history.
In any case you cannot avoid, if you want to deal with 50 moves rules or
repetition detection, to have the whole game history available.
So storing anything about these in the compressed position is just a waste of
space.
Christophe
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.