gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] influence speed exactness tradeoff


From: Arend Bayer
Subject: Re: [gnugo-devel] influence speed exactness tradeoff
Date: Wed, 26 Jun 2002 23:03:17 +0200 (CEST)

On Wed, 26 Jun 2002, Gunnar Farneback wrote:

> We have made similar tradeoffs before, e.g. setting the fourlib_depth
> to 0 during make_domains(). In my experience these have often caused a
> fair amount of trouble, especially when inaccurate results have
> poisoned the caches.

This one has the advantage, of course, that it does not lead to
incorrect cache lookups, as the remaining_depth is stored there.

> > I will probably also try out two more exactness-speed tradeoffs, to make
> > owl and influence reading calls less expensive:
> >  * disable all (including legal) ko captures (as all the helper
> >    functions do not even test for ko results, this seems a reasonable
> >    thing to do).
>
> I'm doubtful about this and also about the premise. Although there are
> no explicit tests for KO_A and KO_B in the constraints, there's an
> important distinction between "== WIN" and "!= 0".

Hmm. Is that distinction really that big? Of course, disallowing all
illegal ko captures (which saves about 10% of reading nodes) is the same
as changing "== WIN" to ">= KO_A".
Anyway, in both cases, "== WIN" and "!= 0", you could still disallow all
ko captures for one side from the very beginning. Double kos aside (and I
doubt we should worry about double kos in an owl pattern helper), you
can't get WIN with any line that includes a (legal or not) ko capture.

> >  * disable passes
>
> Can you explain what you mean here? It's vital that the defender is
> allowed to pass in certain seki positions or where the only local
> moves are to fill in one of two one-space eyes.

It is also expensive. I once tried it out and manually disabled all passes,
and it reduced the number of reading nodes by ~20% (I didn't check whether
this was caused by changes in the owl computations though, as far as I can
remember).
Once we use Trevor's matchpat_goal_anchor for owl pattern matching (this
is still somewhere on my personal to do list...), a _vast_ majority of the
time used for owl computations will be spent in the reading code. My
general impression a that we should guess a little more often so that we
can compute more owl nodes per second. Of course, I have nothing to back
up this opinion.

I missed that case with two one-point eyes though, I had only thought
about sekis.  So I'd guess this it is not acceptable at all to disallow
passes when testing owl_safe_move. For the owl pattern helpers, I still
think it might be worth trying out.

Another thing one could try is finding some heuristics in reading.c
deciding when we don't need to try the pass move.

Arend






reply via email to

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