gnugo-devel
[Top][All Lists]
Advanced

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

Re: arend_1_30.1: Re: [gnugo-devel] Influence crash


From: Arend Bayer
Subject: Re: arend_1_30.1: Re: [gnugo-devel] Influence crash
Date: Wed, 27 Mar 2002 17:02:50 +0100 (CET)

On Wed, 27 Mar 2002, Daniel Bump wrote:

> > This is fixed by increasing MAX_INTRUSIONS, as below. Of course I cannot
> > prove that the new value for MAX_INTRUSIONS is safe, either. But is should
> > be.
> > 
> > Actually, there would be a better solution to handle the "marked intrusions"
> > now (faster and less memory consuming), but I don't think that is an urgent
> > FIXME.
> 
> Wouldn't the thing to do to be limit the number of intrusions
> with a given source_pos?
> 
> Perhaps if a second intrusion is found with the same source_pos,
> discard the one with smaller strength?

Just to make sure we are talking about the same thing (I think the names I
chose might be misleading):

source_pos is the position of the stone "from which the intrusion originates"
strength_pos is the place where the influence source will be added.


A single stone with no close neighbours has at the moment I think 24
intrusions, all of value 30: All direct neighbours, keimas, iken and niken
tobis. If we would limit the number of intrusions for this stone, we might
get a random assymmetry, depending on which intrusion we happen to discard.

The "better solution" I meant above could use the fact the matched intrusions
pattern now come in sorted by source_pos (as they are the pattern anchor).
I don't know whether the influence callback should be allowed to rely on
this.

Arend





reply via email to

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