Re: [Bug-gnubg] BUG: One sided rollout for epc

[Øystein Johansen]

Christian Anthon wrote:
> On 05/27/2009 12:20 PM, Ian Shaw wrote:
>> I notice that the number of trials for the one-sided rollout that gives
>> the epc is only 546. Considering that it is extremely fast, shouldn't it
>> be increased by default to 1296. Even 46656 (36 ^ 3) only takes a second
>> or less on my 2 GHz PC. (Perhaps the rollout terminates at the one-sided
>> database, and since mine extends to the 13 point there is a very early
>> termination.)
>>
>>   
> I believe mine does 5760, and we don't want to do too many by default as
> the race widget needs the results before it can be shown.
>> Hmm. Just rolled out position AQAAAABwd3cAAA (315 pips) and got an epc
>> of 252.966, wastage -62.034. There can't be a negative wastage, so
>> something must be wrong.

(Slightly off topic)

BTW: What when the roll distribution get wider that 32 rolls? I'm not
sure how many rolls it's possible to use in a normal situation, but
theoretically it should be pipcount / 3 + 1. How are such position
handled in the database? Will the sum be less than 1.0 (or 65535 in
short type) for the distribution or will the 32nd element store "31
rolls or more".

For long databases, like 13 point, I'm sure this is a source of error.
How significant it is, I'm not sure -- I need to analyse this. Also, as
the distribution gets wider, the 16 bit precision mist also be
considered. With smaller values a 1 / 65535 part can be very high
compared to the probabilities.

Thinking....
Hmmm.... Maybe a normal distribution scheme is better for long databases?

-Øystein

signature.asc
Description: OpenPGP digital signature