[computer-go] Effective Go Library v0.101

[Łukasz Lew]

The library is just a bunch of code and You can do whatever You want with it.
I'm realistic, what matters is: what You have learned, does Your program works.
So just get the code and hack it as fast as You can to get some effect
asap, to feed Your motivation, to get more effect fast, etc...

Concerning new versions ... it should be no big deal i guess.
You can just copy some files and hack the copies.

Another option is getting whole repository, so You can commit and
branch locally:

hg clone http://www.mimuw.edu.pl/~lew/hg/
cd libego
<here is Your hacking>

hg commit      (this is local commit)

hg pull (then whenever You want to check for new version)

But repository-solution may be too much for a less than few weeks of
work, it will be just a burden.

So just grab the source, do something and be happy :)
Lukasz

On 2/14/07, Heikki Levanto <heikki at lsd.dk> wrote:
> On Wed, Feb 14, 2007 at 10:57:38PM +0100, ?ukasz Lew wrote:
> > Basically I wanted to implement a board in a hope that more people get
> > attracted to Computer Go. But now this is more or less accomplished.
> > So I decided to implement some kind of set canonical algorithms.
> > But only those most common, I do not intend to make another GnuGo :)
> >
> > I just started UCT, as majority voted for it. Maybe patterns will come next.
> > If You have something to propose, just go ahead :)
>
> I have a question about your philosophy. Do you mean us - the users of
> your library - to take the current version of the code, and start
> modifying it to our needs? Or do you want us to link with the library,
> so that we can upgrade to a later version without branching?
>
> I am asking because I would need a bit different playout routine. I
> could easily hack the library to do what I want, but that would in
> effect be a branch, and lead to maintenance problems later if/when you
> release a better version.
>
> I could also inherit from your classes, and override what I need. That
> would probably require a new header file, or something.
>
> Or I could abstract my needs into a more general interface, submit that
> as a patch, hope you accept it, and then use that.
>
> To get down to earth, I would like to look at the board at the end of
> each playout, calculate something more than just win/loss, and pass that
> info back to who ever called playout. One way to do that would be to
> pass a function pointer and a (void?) pointer to playout, and have it
> call back the function with the board, winner, and the void pointer. If
> that sounds more like C than C++, it is because I am a C programmer. If
> some other C++ idiom could do the same thing, all the better.
>
> Also, you have implemented the mercy rule in the playout code. If the
> library should be used without duplicating the code, this might be
> better left as a settable parameter.
>
> Like I said, I could easily write my own playout. But then I'd have to
> modify the gtp code to call that, and probably change a bit more here
> and there. In the end I would have forked your code, and when you
> release the next version, I would have to merge the changes in, and/or
> decide to go our separate ways.
>
> Perhaps I am worrying too much at such early state. I am just about
> considering to start my own project. But I'd like to do the right thing
> from the beginning.
>
> What do you think?
>
>    Heikki
>
>
>
> --
> Heikki Levanto   "In Murphy We Turst"     heikki (at) lsd (dot) dk
>
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>