[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] (OT) Position ID documentation
From: |
Massimiliano Maini |
Subject: |
Re: [Bug-gnubg] (OT) Position ID documentation |
Date: |
Thu, 3 Jun 2010 12:01:21 +0200 |
2010/6/3 Øystein Johansen <address@hidden>:
> On Sun, May 30, 2010 at 3:11 AM, bgnj <address@hidden> wrote:
>>
>> This is an interesting problem. I counted all the non-contact positions
>> in
>> order to see if that would get the number of positions down to 64 bits but
>> unfortunately it did not.
I did the computation this way:
# Non-contact positions.
NC_pos = 0
for lop in range(1,23+1):
# Black has 1 checker on point lop, 15-1 checkers on points
# 0..lop (0 meaning off).
# White can be on points lop+1..25 (25 meaning off), but at
# least one is on points lop+1..24. Nobody is on the bar.
NC_pos += Dnm(lop+1,15-1)*(Cnm(24-(lop+1)+1,1)*Dnm(25-(lop+1)+1,15-1))
I get this:
Non-contact positions: 9350831674578000 (9E+15).
Not enough.
Btw, the positions that are game over (15 black or white checkers out) are
simply 2*(Dnm(24+2,15)-1). This gives: 80450690110 (8E+10), very far from
what we need.
> MaX: I like your idea as well. (And I like your python code). 11 points each
> should be enough for any normal position, but remember this is theoretical
> discussion of only academic interest, and you solution is more like a
> pragmatic solution rather than a theoretical perfect solution. :-)
Indeed. But for the theoretical discussion we probably have the answer:
given he delta between the total number of pos and 2^64 (delta is 8.2E16)
it's unlikely that stripping game over and illegal will bring us under 2^64.
Any attempt to separate the pos in 2 or more 'sets' and use different encodings
is not an answer to the theoretical question.
MaX.