djhbrown wrote:pnprog wrote:on page 25 ..I guess you mean The paths between white D and white A, and between white D and white E, are both blocked by the colour map of the live group black D.
yes! thank you for spotting the typo.
Hi!
I just had a second try at reading your paper. Generally speaking, I find it very difficult to navigate, because the descriptions of the different concepts (functions) are scattered all over your pdf, and keep referring to each others.
This is to be expected for such project, of course, but then, I suggest you to work out a more formal (and exhaustive) documentation of Commonsense Go, in a similar fashion to what is used in the programming world (so not something like Latex).
There are dedicated softwares used to create technical documentation, that output HTML or pdf files with all cross references displayed as pointers/links that make it easy to navigate the documentation.
Sphinx is such a software, and
here is an example of what it can create. I purposely selected an example not related at all to Go, so do not care about the content. But this example is similar to what I believe you could (should) do: You could have a first part with the main concepts/idea and the second part that digs in the details both on the same page (or not, at your convenience).
This is typically the kind of technical documentation programmers are used (comfortable) to work with. And if you want to get their help, I don't think you can avoid this step. Plus, it would help you perform an exhaustive survey of all the concepts at use in Commonsense Go, with a top->bottom approach, from higher level to lower level.
For a similar example that is related to Go, there is the excellent
Gnugo documentation of course. In fact, in the software world, a good documentation is an indicator of a project good health.
That being said, my comment on your paper is that it uses concept that are "easier said than implemented". For examples:
A group with two eyes, or a single eye large enough to be able to form two eyes, is alive.
Any life and death book for beginner contains tons of examples that will challenge our definition/understanding of "single eye large enough to be able to form two eyes" (just think of group alive by seki or by ko, or by ladders). There is probably no easy way to code such concept without going for the exhaustive/recursive search.
And with that definition being already that hard (impossible?) to implement, then working out a "proof of concept" of your map will block at the second step of the cluster map (when the dead stones are noted and the color map redrawn). And so all the following steps (shadow map, groups, path...) cannot be done as well.
To take another example:
territory (x) = size (eyespace (x)) + prisoners (x))
Even without considering the life and death problem already mentioned with
exespace, estimating the
eyespace of a group (I guess here that means the territory it controls) is fairly complicated. Indeed endgame/yose tesuji form an important category go problems by themselves.
And this is without mentioning all the other functions that I (everybody) am eager to see how you propose to implement (semeai(), capture() for example).
I noticed you rely on proverbs a lot, and that's probably not ok for the level of play of LeeSedol (proverbs are a sort of tool/heuristic to compensate for low reading capabilities for us poor amateur players). For example, this:
The counter-goal to surround is save, rather than merely escape, because running with a weak group is generally disadvantageous.
Quite often this is false, like when it's preferable to have a group escape in the center in good shape (even if still weak) instead of being sealed in a corner and 100% alive. A proverb that is
generally true will probably not help that much playing against a pro player.
One more point, it seems to me that your algorithm does not know how to use forcing moves. A simple example I can imagine is to play a forcing move to break a ladder to save a cutting stone. The goal of the forcing move (let's say split a corner enclosure keima) and goal of saving a cutting stone (keep to other groups separated) are not the same. Can your algorithm manage that?
Ko are another situation where you use forcing move (ko threats) to prevent opponent to (temporarily) play a local move (solving the ko).
One last point (that is linked with the former in fact) that is not clear for me:
Code: Select all
until achieved (goal) or refuted (goal)
repeat
(goal; remap; counter; remap)
So when does the algorithm know that a goal is definitively achieved and that the sequence goal/remap/counter/remap can be stopped? For example, after the algorithm comes up with L10 as black against LeeSedol to achieve the goal, the algorithm should now take the perspective of white and try counter it. It should come up with a move that counter it (or as you put it, that takes a step toward the counter goal). I think your algorithm would come up with M10 (and other moves) to capture stones that are on the path. Then your algorithm needs to find a refutation for M10 and so on...
Aren't we headed toward a extensive reading, with your algorithm only performing some pruning of the search tree?
There are still plenty of interrogations left from your paper (one is what about the fuseki? how to decide on the first move as black? can algorithm work to select the good joseki?). And so you will need more than just your paper to convince people to give a try at it.
What you could do is to manually run your algorithm on a 5x5 goban for a complete game, although I guess it would be a lot of work (more work than just leaning programming from scratch and coding your algorithm main concepts).
So for now, my feeling is that your paper is mainly focusing on very high levels reasoning (or "hierarchical reasoning about abstract concepts" as you put it) and conveniently avoid dealing with the real hard stuff.
For that "real hard stuff" (exhaustive reading of local situation and link with global situation), I understand that you expect a simple tool (your mapping heuristic) can help dealing with it, at least most of the time. Am I right?
As for my opinion, I don't think one can find a simple tool to avoid doing the hard job (exhaustive reading of each situation), but maybe I will have to try to read your paper a third time through
May I ask about your level at Go?
You have a good eye for detail. Plus, your drawing is much neater than mine.
-hearted 
The text on p9 should read: