> There is a de facto standard light playout policy (algorithm).
I have a rough idea of what that might be. And I suspect that keeping this
"de facto standard" implicit has been hiding some actual differences in what
different people think that standard is. Some of my questions arise from trying
to pin down where and why different authors have different ideas of what "the"
standard is. If there has been some explicit standardisation since those papers
were published, I'd be interested in a pointer to that standard and its
rationale.
> If you want to adhere to this standard, then by definition, there are correct
> and incorrect ways to do so. If you just want to design a better playout
> policy, naturally anything is fair game.
Neither, actually!-) If there was a single standard, then implementing that
first would be useful before starting on variations. But only if said standard
was arrived at by community optimization, not by committee or by failure
to examine hypotheses for their validity ("it works in most cases" is no
proof that it works, let alone that there isn't a more complete way to do
the same thing). The more everyone always implements the same thing
because everyone does it that way, the less that way is guaranteed to
be tested for flaws (local extrema, exploration vs exploitation?-).
Mostly, I like to understand what I'm doing and why, instead of just
implementing and optimizing what has been handed down. So I take the
slow, scenic route to writing my own implementation, using coding only
to test and improve my understanding of what I've read while enjoying
the pleasure of finding things out. Usually, that either leads to requests for
clarification/suggestions for possible improvements or to being more
comfortable with "the" standard (because I've tried to shoot it down
and failed - "coming to grips with it";-).
After all that initial learning has settled down, and the basis is solid,
there'll come a time for testing new ideas.
> But how are you going to measure whether it's really better?
By trying to understand the issues in enough depth that I can design
concrete experiments that will test concrete hypotheses?-) And if the
theory is good enough, experiments might not even be necessary in
all cases (or rather, a single proof might cover an infinity of experiments),
though I expect experiments to be helpful in most cases.
> My advice is to keep to this standard for a little while longer, write
> the rest of your engine, run it on CGOS where you can compare it
> directly with programs like myCtestxxx (maintained for that purpose
> by generous individuals) and verify that the other parts work. Then
> start improving the playout policy.
I fully expect to try my code against others at some point (though I
don't have a permanent internet connection atm, so couldn't let anything
run via a server for long). But that isn't urgent yet. What is urgent is not
to build in limiting assumptions (in either code or understanding) that will
be difficult to back out of once there is more code.
Don't get me wrong: I have switched from pure hypotheses to working
on code, though only on the side, and I think the various community
resources (servers, wikis, software, list archives, papers, bibliographies,
..) are great. A FAQ with urls, archive pointers, search keywords, and
glossary would help newcomers (with pointers to it in the list headers
and mailman listinfo page). If the list had a wiki, newcomers like myself
could simply add what they find to a FAQ page on that wiki before we
forget how difficult it was to find in the first place.
Claus
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
