Re: Commonsense Go
Posted: Fri Feb 03, 2017 9:29 am
AlphaGo upended 5000 years of human dominance less than a year ago. It doesn't seem like the time to lament that a theoretically much better go program hasn't yet been implemented.
Life in 19x19. Go, Weiqi, Baduk... Thats the life.
https://lifein19x19.com/
Actually AlphaGo uses the concept of groups in its design at a very fundamental level: the board representation which is the input to the whole system uses a layer that tells what stones are connected in groups. This is described in the Nature paper.Uberdude wrote:Let's make this simple:
GnuGo uses the concept of groups in its design.
Commonsense Go uses the concept of groups in its design.
AlphaGo does not use the concept of groups in its design.
(and just in case AlphaGo does have groups in there somewhere, although not as core part):
The Go AI at https://chrisc36.github.io/deep-go/ is a pure neural net move selector bot (no MCTS or value network as in AlphaGo) so definitely doesn't have groups in its design.
You just aren't "seeing it". Perhaps the reason being that not having enough practical experience in problem solving using software.djhbrown wrote:
Problem reduction is a commonsense way to go about solving a hard problem, by dividing it into two smaller and easier ones, as recommended by Polya's “How to Solve it” [15].
yes, it is. it's a good example of humans applying Polya's principle to solve their problem.Mike Novack wrote:
using a neural net IS precisely an example of "finding the right island".
please google me and check out my cv before defaming my PhD in artificial intelligence and other published work in software development.Mike Novack wrote: You just aren't "seeing it". Perhaps the reason being that not having enough practical experience in problem solving using software.
djhbrown wrote:
please google me and check out my cv before defaming my PhD in artificial intelligence and other published work in software development.
i didn't say that.Mike Novack wrote: ...the LOGIC of what you are saying. If there is a function, which given a board position returns the best next move and there is a second function, which given a board position returns the pair of values, the best next move and what color your underwear is (pick anything) WHY do you say the second function would play stronger go?
This is unlikely that somebody will invest energy and time to implement somebody else ideas if that person is not convinced by your ideas from the beginning.djhbrown wrote:The program is designed, but it's up to others to turn it into software. Could it beat Alphago across the board, and with much less hardware? I think it could
as the Irishman said: "If I were going to Dublin, I wouldn't be starting from here".Mike Novack wrote: I will now more carefully/precisely define a FUNCTION. The function shall be "given a board position*, return a move such that there is no better move" ...
Now assume we have two (very different) computer programs, A and B that both correctly "eval" that function. WHY (for what reason) are you arguing B is better than A?
How is CG coming up with J13 in this particular case, can you please explain in some detail to understand how the various hierarchical systems make a decision among the 290+ legal moves in this position?djhbrown wrote: Let A = Alphago and B = CG and K = Myungwan Kim.
Let p = the position after move 78 in game 4 of Lee Sedol vs Alphago
Then A(p) = 79: K10, .. (DeepMind have never told us what followup move tree Alphago had expected)
, and B(p) = 79: J13, L12; 80: L10, .. (see https://papers.ssrn.com/sol3/papers.cfm ... id=2818149)
, and K(p) = 79: L10, etc (see sgf)
detailed explanations of how CG chose J13 are provided in my papersorin wrote:How is CG coming up with J13 in this particular case, can you please explain in some detail to understand how the various hierarchical systems make a decision among the 290+ legal moves in this position?
I am not sure how is this different from the traditional rule-based systems that have been tried for tens of years in computer-go and led nowhere near a strong player.djhbrown wrote: CG looks at what it thinks is the big picture, computing clusters, groups, territory and influence, from which it figures out what it thinks is happening, and then decides what strategy to adopt. this becomes its goal, which its planning methods try to achieve, in so doing creating a tree of subgoals and so on down to the level of moves. for each of the move candidates it comes up with, it looks to see what it thinks the opp would play in reply and whether it thinks that would refute any of its goals. and then it looks to see whether it thinks it can refute that refutation by its next move and so on.
If you devise a system that would narrow down the candidate moves in such a complex situation like the one in this game, to very few candidate moves including the ones that AlphaGo missed, you already have a winner. That sounds too good to be true though - can you please explain in some detail how do you ensure you are selecting just a few good candidates for very deep analysis (which is required given the complexity of this position)?djhbrown wrote: Note particularly that CG found a justification for J13, namely that it thought white would reply at L12 and then black could play the key killing move of L10 on its next turn. i had simulated CG by hand, and didn't go into other variations CG might have considered (there wouldn't be many).
CG-SWIM does hierarchical (top-down) planning. rule-based programs like ManyFaces don't.sorin wrote:how is this different from the traditional rule-based systems?
hierarchical planning naturally leads to relatively few move candidates, as the example in my paper shows. You can try it for yourself on a game position of your choice - just follow the algorithms and methods, creating hand-written goal trees like the ones in my paper, and you will see that very few move candidates are generated.sorin wrote:how do you ensure you are selecting just a few good candidates?
The key part of my question was not just "few candidates", but "few and good candidates". There are three components to AlphaGo's success:djhbrown wrote:hierarchical planning naturally leads to relatively few move candidates, as the example in my paper shows. You can try it for yourself on a game position of your choice - just follow the algorithms and methods, creating hand-written goal trees like the ones in my paper, and you will see that very few move candidates are generated.sorin wrote:how do you ensure you are selecting just a few good candidates?
http://papers.ssrn.com/sol3/papers.cfm? ... id=2818149