Commonsense Go

[sorin]

If playing on smaller boards, would your heuristics need to change a lot (I mean the definitions for what is a cluster, etc)?
I think it would be useful to simulate your ideas on very small boards, where you hopefully don't need a computer program to test them in a actual game, start to end - maybe something like 5x5 or 6x6 board so it's not too trivial, but small enough to be able to go through a complete game?

That would tell you if your ideas work or not, to some extent.

[djhbrown]

If playing on smaller boards, would your heuristics need to change a lot?

using small boards for software implementation testing offers no advantage, since the algorithms are computationally inexpensive and would work in the blink of an eye; the goal trees are never very big; hierarchical reasoning does not produce combinatorial explosions, as the 4 examples i've published so far illustrate - like my much, much, easier way for children to learn numeracy (click here), Swim works Just like that!

small boards would be quicker to hand simulate, but that's about all.

all the algorithms are independent of board size. the only thing that would need to vary with board size is the multiplier h on p36 used in calculating the value of chance which is used to decide which strategy to adopt. but in any case, f,g and h are user choice variable multipliers.

varying f and g would produce bots with varied playing styles - more conservative or more aggressive - that would be fun to play around with and see what happens.

Code: Select all

let lead = value (me) - value (you);
if lead + chance > 0 then playsafe
else attack

value (x) = f (territory (x),g (influence (x))
               + if white (x) then komi

territory (x) = size (eyespace (x))+ prisoners (x))

influence (x) = if weak (x) then 0
                else g (size (shadow (x))

chance = h (size (neutral space))

[djhbrown]

Anyone like an orange?

[djhbrown]

An illustrated dialogue on the essence of intelligence, with Demis Hassabis, patron of Alphago, and Noam Chomsky of MIT. Featuring Demis' favourite move by Alphago, and parrying Lee Sedol's magic wedge.
https://www.youtube.com/watch?v=3RSiORA ... a3Hl1X_v-S

[pnprog]

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?

[djhbrown]

thanks for your thoughts; i will reply to all your questions shortly; for now, i just refer to your main comment:

pnprog: I find it very difficult to navigate

i'm sorry to hear that, because i had put a lot of thought into organising it to make it easy to read. It's written more as a story than a manual, with the intention that it can be read straight through like a book - or watched like a recreational movie. You did follow the viewing advice to read it 2 pages at a time, odd pages on the left? For otherwise, it would indeed be cumbersome to follow.

, because the descriptions of the different concepts (functions) are scattered all over your pdf, and keep referring to each others.

functions do use other functions - that's what a structured program does! The sequence in which they are presented is thematically top-down - so, necessarily, submethods are mentioned before they are defined. i gave them mnemonic names so the reader could guess what they did even before seeing their details. Naturally, if the reader is keen to truly understand Swim, they will have to do some flipping back and forth, because the logical structure of an AI program is not one-dimensional like a string of text or video frames.

i didn't describe the metamethod first, because it would have looked too abstract out of context.

You mention that you like the GnuGo documentation; personally, i found that as excruciatingly ponderous a read as the Cray NQE user manual and Unix man pages

Still, i will take your feedback on board, and may produce a new and improved edition of the paper in the future.

And i will answer all your questions, but that will take me a little while, so please be patient.

[pnprog]

And i will answer all your questions, but that will take me a little while, so please be patient.

Nothing urgent here so take your time.

But maybe you could answer the following question first. I tried to reproduced the first step of your color map, and got something slightly different from you

Please compare the following map with the first map in your paper (page 12)

map0.png (20.97 KiB) Viewed 15590 times

I can notice a few differences at E1, G1 and H19.

Can you confirm this is a mistake in your paper? Otherwise, can you explain why the links should not be colored?

[djhbrown]

[E1, G1 and H19]

You are right again! You have a good eye for detail. Plus, your drawing is much neater than mine.

In the file list, that map is f12.png which is the end of step 2 of pass 1.
48 map images were used to create the colouring animation
in my video of the paper. It wouldn't surprise me if there are more typos en route,
but i'm pretty sure (fingers crossed!) that the final frame (map) -
the one on page 24 of the paper - is accurate.

(But the screenshot tells me that Xubuntu's idea of what its showing me is inaccurate! -
the blurry section beneath the folder window is not visible on the hardware screen;
this might explain why kdenlive sometimes loses sight of the vital project scrollbar
which i can only get back by unmaximising its window (i'm going to play around with manually resetting display size to see if that hackaround works until Xubuntu display manager is debugged).
And it would be nice if this bb painter autoresized images
so they fit in the viewing window... Software is so pernickety! )

Screenshot_2017-04-10_09-55-28.png (912.89 KiB) Viewed 15540 times

[djhbrown]

[more formal (and exhaustive) documentation of Commonsense Go]

pnprog, please let's private message about documentation; i expect it would be perceived as off-topic by some.

As to Swim's logic, thoughts and doubts such as yours are very welcome; i can't possibly have thought of everything. i will reply to the questions/contributions/critiques in your long post one by one, in separate replies.

[no easy way to code [life and death concept without going for the exhaustive/recursive search.]

that's both true and untrue !

true, because unequivocal determination cannot be made without fullwidth search right to the end, not until someone comes up with the Go equivalent of Andrew Wiles' proof of Fermat's Last Theorem, which i think is rather unlikely to happen in the near future.

untrue, because in the case of colour map enclosure, high probability of cluster death is reasonable to foresee without reading. In practice, escapes are only theoretically possible for unenclosed clusters. However, it might be a good idea to add a conservative !!caveat!! to the lad principle on page 15:

Code: Select all

A cluster that does not have 2 eyes, and is
completely surrounded by enemy clusters with
more liberties !!that are members of a strong group!!, 
cannot win a semeai, 
so it is dead.

"Dead" stones are never completely dead until they are captured, so i think Swim makes a decent stab at judging the situation. An example of this is going to come up in my next MiG vid Swimless in Seattle.

Not sure about kos yet - for a ko to save a perceived dead cluster, ko would have to lead to death of cutting stones to work, and a situation like that is unlikely to produce a colour map that fully encloses the cluster, so Swim wouldn't even ask the question. Maybe someone can find a situation which contradicts my inference?

Only after implementation would it be possible to begin behaviour testing to iron out every single wrinkle, as DeepMind had to do after Lee won game 4.

whereas my gutfeel is that the caveat i introduced won't be necessary, it might be.

Go (or was it golf?) is not a matter of life and death; it's much more important than that

[HermanHiddema]

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.

untrue, because in the case of colour map enclosure, high probability of cluster death is reasonable to foresee without reading.

Are you really claiming you've found an easy way to predict, with high probability and without reading, the result of most life & death problems?

That's a rather extraordinary claim, and would require some extraordinary evidence, IMO.

[djhbrown]

Are you really claiming you've found an easy way to predict, with high probability and without reading, the result of most life & death problems?

Upu2

It is a pathetic distortion to take half a sentence out of context and inflate it out of all proportion into a ridiculous straw man, attempting to cover up a blatant misrepresentation by adding a question mark and the word "really"

By this 3rd misanthropic strike at me, the self-proclaimed herminator demonstrates he has learned nothing from Colin Powell http://news.harvard.edu/gazette/story/2 ... h-regrets/

my paper and responses to genuine questions make it clear that Swim's cluster lad perception conservatively only applies to a small subclass of configurations, defined by the predicate described on pp 13-16 and illustrated in 2 of my last 3 videos.

lad doesn't feature in "Demis and Noam", which soberly focusses on the much more weighty and $ignificant debate that has been raging within AI circles (and their bankers) for over a decade, one that that DARPA recently chimed in on, yet which has completely escaped the attention of mass media.

the trifling issue of lad will feature in my upcoming lighthearted Likely Lads vid... come to think of it, that might be a better title

[pnprog]

[E1, G1 and H19]

You are right again! You have a good eye for detail. Plus, your drawing is much neater than mine.

Can you update your definition of color controlled empty point? I mean that part:

An empty point is said to be colour-controlled if at least 3 of its links are coloured and none is enemy coloured.

Because at it stands now, corners points (A1, T1, T19 and A19) cannot become color controlled points per propagation (they have only 2 links).
Because of that, their two neighbors (for A1, they are A2 and B1) can hardly get color color controlled themselves per propagation (they have 3 links, but one to the corner point can cannot be colored).

To continue on your paper's example, here is my result after the propagation is completed (p14 in your paper) strictly following your current definition:

map1.png (23.21 KiB) Viewed 15474 times

One difference with your paper that is not linked with the definition issue I just mentioned is A17.
I guess this one is a mistake. (this link appears during the first stages of the map drawing, then should disappear during the propagation).
Do you agree?

[Solomon]

After launching 1879 holier-than-thou smartarse missiles in 7 years, an average of over 200 a year, polluting 126 pages of valuable bytes, including 3 misanthropic strikes at me, the manifestly ADHD self-proclaimed -hearted herminator evidently has nothing better to do, nothing constructive to contribute, and has learned nothing from Colin Powell http://news.harvard.edu/gazette/story/2 ... h-regrets/

This kind of personal attack is against forum rules, consider this a warning djhbrown. Next one's a ban.

[djhbrown]

[This kind of personal attack is against forum rules, consider this a warning djhbrown. Next one's a ban.

that's fair. i accept the judicial reprimand, and have corrected my offence, which set a bad example to younger viewers.

it's no excuse that i fell into the elephant trap set for me, so it's my own fault that ignorati now have more licence to Carry on up the Khyber snideswiping just within the policy rules as they have been doing for over 2 years, particularly since a constructive contribution to the application of Monte was abjectly misinterpreted by a vendor who i would have thought should have known better, but that's probably because he perceived Google's text-to-voice Japanese accent enunciation to be risible instead of mignon, which i found it to be. it is i who should have known better.

fortunately, BF Skinner discovered that any kind of response is positive reinforcement, so:

"whether 'tis nobler to suffer the slings and arrows of outrageous trolling - Or, by opposing, end them?"

has a clear answer, because schoolyard bullies feed on indignation.

https://www.simplypsychology.org/operan ... oning.html

[djhbrown]

Can you update your definition of color controlled empty point?

Yes! Another good find, thank you. The text on p9 should read:

"An empty point is said to be colour-controlled
if at least 3 of its links
are coloured and none is enemy coloured.
The edge of the board is friendly to both sides,
so an edge point is colour-controlled if
2 of its links are exclusively-coloured,
and a corner point is if just 1 is ".

i'm not completely happy with my rewrite; it feels like there should be a tidier way to express it, whilst still covering all the bases.

there is a related omission on the next page too! it should read:

step 1: a colour-controlled point colours its
links and their endpoints.
step 2a: a link connecting two singly-coloured
points, or a singly-coloured point on
either the second or third line
with neutral link(s) to a neutral edge point, is coloured.
step 2b: a neutral point in the middle/edge/corner, 3/2/1 of whose edges are exclusively-coloured, becomes colour-controlled.

i did have it something like that in an earlier draft, but was trying to make the published version as concise as possible and went a bit too far with the blue pencil - and muddled myself up about how lines are numbered! ie Go board numberings start from 1 instead of 0 (which i daresay a mathematician would claim they should be... what's the name that of that old age disease when you start to forget things?!)

Step 2b is included in the simulation, so the following pages are unaffected.

as regards your query about A17, the link A17-C17 is coloured blue in step 1 of the first pass, for the same reason (ie step 2a) that A16-C17 is yellow.

The A17-C17 link colour shouldn't appear and then disappear, not until until after the map is completed and C17 declared dead, as described on page 15, whereupon after the map is completely redrawn from the beginning, A17-C17 becomes coloured yellow instead.