Re: [gnugo-devel] GNU Go as an oracle

[bump]

> > The biggest obstacle is speed. The schemes I have in mind would be
> > too slow currently and also require multiple GNU Go processes
> > communicating by unix pipes so there will be portability
> > problems. So when this stuff is ready to go into the engine it will
> > have to be a configure option turned off by default.
> 
> But then the different processes do not share caches/persistent caches
> etc? (Or else if you want one process with different threads, then
> we will probably have to rewrite a lot of stuff to clashes.)

The process inherits the caches from the parent when it forks. Since I'm
thinking about semilocal search, the persistent cache is less important.

> I think the main problems are the same. Your metamachine basically knows
> nothing about strategic effects, atari-atari moves etc. Also it does
> not use the fine tuned influence code as far as I understand.

We need to rewrite gtp_experimental_score to use the influence code.

Dan