[Top][All Lists]
[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