gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] cache interface


From: Arend Bayer
Subject: Re: [gnugo-devel] cache interface
Date: Sun, 11 Apr 2004 15:30:30 +0200 (CEST)

Well as I said this has cost me several hours of debugging a few times
so if someone once to keep the current interface he would need very good
arguments to convince me...

> On Sun, 11 Apr 2004, Arend Bayer wrote:
> >   *str = find_origin(*str);   <===============
> >
> > It is an understandable optimization, but it changes the variable
> > somewhat behind the back of the calling function, and is thus an
> > interface with bad style.
>
> I think you are right in saying that the interface is bad, since it
> changes the variable through the pointer.  The optimization as such,
> though, is correct.  We want to cache the result of an attack or defense
> of a string, not of a certain stone within the string.



> > In this case, it bite me in the following way: Inge's new cache doesn't
> > do this.
>
> That is definitely a bug.  It should do it.

In my opinion it should not.

> > But of course it is a very bad idea anyway to rely on the caching to make
> > sure the target is normalized to point to the origin, e.g. as the
> > optimization should still work beyond the depth where we do caching.
>
> I am split here.  On one hand I think that the normalization is necessary,
> so I think you are wrong.  On the other hand I think that maybe the
> caching code is not the correct place to do it.  On the third hand it is a
> catch-all of forgotten normalizations so I still think it should be kept,
> or in this case, inserted.

Well my point is exactly that the calling function should take care of
the normalization itself. If you want feel free to add an ASSERT in the
caching code that the normalization has happened before calling it.

Arend





reply via email to

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