gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Semeai node limits


From: Jens Yllman
Subject: Re: [gnugo-devel] Semeai node limits
Date: Fri, 17 Mar 2006 08:10:40 +0100 (CET)
User-agent: SquirrelMail/1.4.5

> On Mar 13, 2006, at 12:22 PM, Gunnar Farnebäck wrote:
>
>> Dan wrote:
>>> Perhaps the semeai nodes should be increased but 2000 is
>>> too much. The current default is 500.
>>
>>
> <snippage>
>
>> With 1000 nodes I measure a regression slowdown by 9% and with 1500 a
>> slowdown by 17%.
>>
>> /Gunnar
>>
> Regressions are not run often ... it would be more pertinent to ask a)
> whether gnugo picks better moves with a higher node limit, and b)
> whether the cost time-wise is acceptable for ordinary usage.
>
> If the moves are not better, that would be a topic for investigation;
> it suggests a brittle algorithm which has been tweaked to work at
> certain settings, but not under deeper study.

For me it often feels that many changes in pattern values and patterns are
to 'highlight' something soon enough with the current depth/nodes/cache
settings. Not to realy make GNU Go stronger. Because changing
depth/nodes/cache makes GNU Go as clueless as before.

That not to say all work that is done is stupid. But maybe more work
should go into more 'intelligence'. It feels little bit stupid of me to
say this who never have time to contribute.

Maybe a study of regressions that change when changing depth/nodes/cache
would show that pattern values should not be static. Maybe some pattern
values should maybe slowly decrease when more analyzing is done. Or maybe
there should be patterns that have diffrent versions depending on how much
analyzing is done. With that I mean that maybe some patterns need more
restrictions than today. But at lower settings not have time for that.
Just some thoughts. Have anybody done anything like genetic algorithms or
autotuning on pattern values??

Jens





reply via email to

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