[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]