RE: [gnugo-devel] More on minimum values

[Evan Berggren Daniel]

> Actually, I have a couple other questions. Nobody replied to my post in
> Evan's previous thread, so I'll repeat the questions here : there's
> already a mechanism to differentiate minimum values. Why are we
> insisting on adding another one ? If the proposed one is better, why
> keep the old one then ? What about simply changing the current one so
> that it includes J patterns too ?

The current version makes a very small impact, and I wanted the random
values to play a smaller role than that for my testing.  So that's why not
just make it encompass everything.  Also, I didn't want my patch to impact
endgame moves.  Maybe it should, but I wasn't looking for those.  Also, I
believe my version is better.  Consider the case of two J moves, valued at
24.9 and 25.1.  Both get a minimum value of 25.  If the current method
was extended, the lower valued move, being less than the minimum value,
would get an increase in its minimum value of 24.9 / 200 = .125, making it
valued at 25.125, higher than the second move.  This is very small, but
increasing the size of the scaling would make the effect pronounced.  Two
moves with the same minimum valuation should never be reordered in my
opinion, and my mechanism avoids this.  I see no reason that we couldn't
eliminate the current version and replace it with my new version.

Evan Daniel