Quoting Michael Williams <michaelwilliam...@gmail.com>:
I wonder what would happen if you counted jigo as a loss for both players...
Interesting, it would then avoid all lines that are likely to lead to
a draw. The problem is that it then not be able to see any difference
between a jigo and a loss which may be a problem in a position which
is a clear jigo. What happens deeper in the tree does not matter, if
there is only a few jigo candidate moves and many losing moves, the
program will often pick a losing move.
So I think jigo must be evaluated at least better than losing perhaps
something like 25% or so. But then I need to program some more because
it would change how I update the tree, and that part of the program is
quite messy with all the AMAF updating and so on.
The question is: should jigo be counted balanced for both players or
should one perhaps bias the randomized winner for jigo playout. For
example if the program is winning 60% at root then jigo would count as
win in only 40% of the cases for the color of program in the playouts.
This would perhaps drive the program more towards winning lines when
it wins and towards jigo when it loses.
Magnus
On Thu, Mar 31, 2011 at 6:33 PM, Willemien <wilem...@gmail.com> wrote:
instead of randomsing a jigo maybe it is an idea to count all outcomes
double
- count a win as 2 W
- count a loss as 2 L
this gives the option to
- count a jigo as 1 W and 1 L
On Thu, Mar 31, 2011 at 6:06 PM, <valky...@phmp.se> wrote:
> I used to have "solved"-flags in the tree, but the implementation was so
> messy and caused bugs in interactions with other messy stuff so I removed
it
> and was happy.
>
> I guess introducing some other kind of exploration might be better. Or
maybe
> value jigo as just a little better than losing rather than as 50% but
then
> my simple solution currently is not good enough I would have to change
> datatypes and rewrite a lot.
>
> -Magnus
>
> Quoting René van de Veerdonk <rene.vandeveerd...@gmail.com>:
>
>> Magnus,
>>
>> If you reach a final node, you can mark it as "solved", and never
explored
>> it again. Shouldn't that solve your symptoms? It appears from your
>> description that you do not have such a feature in your tree-search.
>>
>> René
>>
>> On Thu, Mar 31, 2011 at 8:42 AM, <valky...@phmp.se> wrote:
>>
>>> I did not want to spend a lot of time changing Valkyria completely for
>>> integer komi so I made a very simple hack to cope with the fact that I
am
>>> using integers and booleans for all computations of wins/losses in
>>> Valkyria.
>>> The hack is that every time a jigo occurs in a playout I randomize
which
>>> player should win which means the change is very minor to the program.
>>> Thus
>>> I d not to model jigo more than in a statiscal sense.
>>>
>>> I am doing some very deep searches to see what could be good moves for
>>> the
>>> most important lines in the opening book. I am using the 7.5 komi book
>>> because it is the most developed, but it may be that a 5.5 book is
better
>>> if
>>> black is favored by 7.0 komi.
>>>
>>> Anyway I just looked at a deep search spending 10hours of search, where
>>> old
>>> branches of the tree is cut off every time the program runs out of
>>> memory.
>>> (Which may also be a part of the problem). It turned out that search
>>> stuck
>>> to a PV and played to the end over and over again with considering
other
>>> alternatives. Valkyria uses exploration = 0. The game it played over
and
>>> over was 80 ply deep thanks to a small kofight and all move looks
>>> reasonable
>>> although sometimes some moves look a little odd. It does search
>>> alternatives
>>> a little bit in each position but it seems to quickly lock onto
something
>>> giving 50% for sure.
>>>
>>> My question: Is this normal? Without Jigo this would not be possible
>>> because a deep variation to the absolute end of the game would be a
clear
>>> loss for one side and then as the score goes down to 0 the search will
>>> explore many alternatives.
>>>
>>> Could it be that playing alternative moves in this search were all too
>>> risky so that search converges on a very long but guaranteed risk free
>>> jigo?
>>>
>>> I see this as a problem because if this happens a lot the program seems
>>> not
>>> really to search all options probably. It could be that my program has
a
>>> bug
>>> or twoo that causes this problem, so therefor I am curious if anyone
>>> could
>>> reflect on it or have some experience.
>>>
>>> I believe chess programs uses something call "contempt" to avoid
drawing
>>> too much (I think espeically against weaker opponents).
>>>
>>> Best
>>> Magnus
>>> _______________________________________________
>>> Computer-go mailing list
>>> Computer-go@dvandva.org
>>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>>>
>>
>
>
> _______________________________________________
> Computer-go mailing list
> Computer-go@dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
_______________________________________________
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
_______________________________________________
Computer-go mailing list
Computer-go@dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
