gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] regressions and bugs


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] regressions and bugs
Date: Sat, 08 Dec 2007 21:05:20 +0100
User-agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071008)

Emanuele Cisbani wrote:
> 2007/12/6, Gunnar Farnebäck <address@hidden>:
> [...]
>> I'm not sure how best to handle this test, possibly change it to
>> tactical reading tests, but for now you can leave it and make a note
>> about the problem.
>
> Ok, same task to do for me, as above.
> But in this case if we accept a failure we can miss eventually
> a bigger mistake of GNU Go if the result become for example
>
> 1 FAILED: Correct '1 1 (PASS|A9|C9)', got '0 0 F9'
>
> How can we manage this risk?

One possibility is to include a relaxed test which doesn't check the
move, using a regexp like
#? [1 1 (.*)]

>> In general the interaction between tactical reading and semeai reading
>> is complicated when there are few liberties in the semeai. Sometimes
>> the tactical reading gets it wrong and fools up everything. With
>> sufficient liberties the tactical reading doesn't get involved and the
>> semeai reading can do its work as intended.
>
> Consequently to your assertions I'm lead to think the tactical reading
> function should be inhibited when semeai reading is invoked by the
> analyze_semeai regression test function. It's correct?

Strictly speaking it's the dragon amalgamation that would need to be
inhibited (which in turn uses tactical reading results) but there's no
way to do that. However, it's possible to call the semeai reading code
in a tactical mode using the GTP command tactical_analyze_semeai. On
the other hand that code is mostly unused within the engine, I
believe, so I'm not sure how well it works or how relevant it is to use
it for testing.

/Gunnar




reply via email to

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