[computer-go] Making Java much faster

[David Doshay]

On 30, Nov 2006, at 4:47 PM, Unknown wrote:

> On Thu, 2006-11-30 at 14:44 -0800, David Doshay wrote:
>>
>> Also, my data shows that if I doubled the time allowed for playing,
>> thus "using" the time gained from faster execution for doing deeper
>> lookahead, the results did not improve, but actually got worse.
>>
>
> To me, this just seems like horizon-effect in disguise.
> Once you exhaust your ability to evaluate, you cannot see through the
> fog. The horizon is dictated by the inability to evaluate correctly.
> (try fuzzing up the evaluation results by 0.01-1 stone just by adding
> some noise, to get my point. You will see the horizon come closer)
>
> Using multiple instances of gnugo to do the evaluation for you, still
> sticks you to the (#1) minimax+evaluation model, even if you apply the
> slave-gnugo processes only for "local" problems (not mentioning
> interactions, or how to identify subproblems)
>
> Having slave processes to do your tsumego- or MC-evaluations for you,
> still keeps you dependent on their evaluation noise. Adding CPU's wont
> help to beat the noise, IMHO. It just pushes your horizon upto the  
> point
> where the fog hits you.
>
> This is the point where I would like to introduce a paradigm shift.
> But I cannot invent one, presently.
>
> HTH,
> AvK
>
> (#1) by "minimax", I mean minimax-variants, including alpha-beta. They
> are all the same.

Well, I suppose that you could call anything that happens "out there" in
the lookahead a horizon effect, but I do not see it that way in this  
case.
Our ability to do a static board evaluation is not a function of how  
deep
the lookahead is, but always is the same poor function. It really does
simply come down to how often the opponent evaluates the board in a
completely different way than we expect, and thus plays differently than
we had checked in any of our lookahead branches. Our data is clear that
if we correctly predict the opponent's moves we have a high win rate.

I do share your desire , and so far your inability, to invent a new
paradigm for programming Go.

Cheers,
David