gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] autolevel bug


From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] autolevel bug
Date: Sat, 28 Sep 2002 11:39:17 -0400 (EDT)

On Sat, 28 Sep 2002 address@hidden wrote:

>
> Evan wrote:
>
> > OK, I think I found the bug.  This should fix it, but it's untested.
>
> I'm not convinced this patch is right. After the patch, the code looks
> like this:
>
>   if (clk.level > CLOCK_CONTRACT_MIN_LEVEL) {
>     if ((predicted_tm - clk.error) > expected_tm)
>       clk.level -= CLOCK_STEP;
>   } else {
>   if ((predicted_tm + clk.error) < expected_tm)
>     clk.level += CLOCK_STEP;
>   }

You're right.  After I sent the patch in, I noticed I'd meant to add the
opposite condition, ie

  if (clk.level > CLOCK_CONTRACT_MIN_LEVEL)
    if ((predicted_tm - clk.error) > expected_tm)
      clk.level -= CLOCK_STEP;
  if (clk.level < CLOCK_CONTRACT_MAX_LEVEL)
    if ((predicted_tm + clk.error) < expected_tm)
      clk.level += CLOCK_STEP;

Which is probably a bug, but not the one I meant to fix.
I've only looked at it a little since then, and haven't figured it out.

Thanks

Evan Daniel

>
> This means that (at least as far as respect_time_contract is
> concerned) the only circumstance where the clock level will be
> increased is if it's already less than or equal to
> CLOCK_CONTRACT_MIN_LEVEL. Thus it can never be increased above
> level 6. This is clearly not Tanguy's intention.  The clock is
> supposed to be increased if the time crunch disappears.
>
> There are actually two functions, respect_time_contract()
> and keep_ahead() where the clk.level can get increased so it's
> possible that I'm wrong but if so can you explain how this is
> supposed to work?
>
> Evan's original post:
>
> > I talked to someone at a local Go club, and he asked me to pass along a
> > bug report with the autoleveling.  He tried compiling 3.2 for his Zaurus,
> > and discovered that sometimes the sutoleveling increases the level even
> > though it's running out of time.  He believes this happens mostly when the
> > variation in time taken exceeds the time remaining, and that somehow this
> > makes it increase the level and lose on time.
>
> Dan
>
>
>
>
>
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnugo-devel
>





reply via email to

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