[computer-go] about commercial Zen
hi all, could anyone help give me a link in English to buy the commercial version of Zen? Now I could only find some websites in Japanese, however, I could not read Japanese Fan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
When SE fails, it is often blatantly obvious: a group is dead or in seki, but judged to be alive; or vice versa. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
Wouldn't one find the correct komi by at worst binary search among komi values? 2010/1/21 Petr Baudis > On Thu, Jan 21, 2010 at 08:39:59PM +, Jacques Basaldúa wrote: > > Petr Baudis wrote: > > > Actually, there is a thread about exactly this on fuego-devel > > > > In fact it is not "exactly this" it is a different approach. > > The post in fuego-devel tries to determine the status of each > > point of the board. That is not a good idea with or without MCTS > > because go is about trading. (Furikawari) > > > > My different approach is determining by "how many points" the > > simulated games are won. Only in yose the IQR becomes narrow > > enough to see how much territory is still in dispute. > > I'm sorry, I was not reading your original mail carefully enough. > > Upside of your approach is that it might be more accurate, downside is > that SE engines like on KGS give you a number but you can also judge > visually if their premises for the number are correct. Many strong > players actually look at SE, but quickly adjust the numbers by checking > which points were misjudged. I think they would prefer slightly less > precise estimate they can further work with to slightly more precise > estimate that's a black box. Confidence interval is great but doesn't > actually solve this problem. > >Petr "Pasky" Baudis > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
On Thu, Jan 21, 2010 at 08:39:59PM +, Jacques Basaldúa wrote: > Petr Baudis wrote: > > Actually, there is a thread about exactly this on fuego-devel > > In fact it is not "exactly this" it is a different approach. > The post in fuego-devel tries to determine the status of each > point of the board. That is not a good idea with or without MCTS > because go is about trading. (Furikawari) > > My different approach is determining by "how many points" the > simulated games are won. Only in yose the IQR becomes narrow > enough to see how much territory is still in dispute. I'm sorry, I was not reading your original mail carefully enough. Upside of your approach is that it might be more accurate, downside is that SE engines like on KGS give you a number but you can also judge visually if their premises for the number are correct. Many strong players actually look at SE, but quickly adjust the numbers by checking which points were misjudged. I think they would prefer slightly less precise estimate they can further work with to slightly more precise estimate that's a black box. Confidence interval is great but doesn't actually solve this problem. Petr "Pasky" Baudis ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Open source real time Go server
Petr Baudis wrote: > This seems like not very productive line of argumentation unless > preceded with more exact definitions of strong. My only claim is that "it is a hard problem". That is unobjectionable no matter how you define strong (obviously: random < strong < perfect) I can't understand why you object on this. > Actually, there is a thread about exactly this on fuego-devel In fact it is not "exactly this" it is a different approach. The post in fuego-devel tries to determine the status of each point of the board. That is not a good idea with or without MCTS because go is about trading. (Furikawari) My different approach is determining by "how many points" the simulated games are won. Only in yose the IQR becomes narrow enough to see how much territory is still in dispute. Stefan Kaitschick wrote: > If resources were no problem, the best way to estimate the score > would probably be to have an MC program find the komi that results > in a 50% winrate. Yes! That is my proposal. Saying an MCTS program is happy (60%) or unhappy (32%) does not inform too much to non-computer-go observers. If you talk about "winning rate" they understand "the probability that the program wins" which is not the case. Telling them the program is happy, but would end being happy if it had to win by 20 additional points is crystal clear. The "correct" way to determine the komi shift would be to try all possible values. Since that is expensive, my proposal estimates the komi shift from one single 20K run by studying the distribution. Of course, it is only an estimation and the other method would be more accurate. Additionally, the estimator gives a confidence interval or remembers the observer that score estimation in move 60 is a fallacy. We have to live with the two facts: * Each board position has a value. (The game satisfies the conditions of the minimax theorem.) * Pretty much every position has a value that is computationally untreatable. And this applies to human estimators as well. They only score according to established practice, which is something that is revised as new empirical evidence shows up. Scoring at move 60 is just an educated guess. (Of course people will more likely accept the guess of a 9d than the guess of a 15k.) The "cool" part is the estimator can tell you the difference when it is just making an educated guess and when most of the territory is already "sold out" with few points in dispute. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
On Fri, Jan 22, 2010 at 1:46 AM, Stefan Kaitschick wrote: >> 2010/1/19 terry mcintyre : >> ( I recall a pro making >>> >>> such an observation; I was willing to accept his expertise on the matter. >>> ) >> >> Any pro making such a comment at move 10 is just grand-standing. I >> have experienced pros making such comments too. You can let such a >> remark pass out of politeness of course, but accepting it because of >> his presumed expertise is extremely naive IMO. I would even be >> suspicious of pros making such comments at move 150. >> >> Mark > > If a pro predicts a half-point win early in the game, that is obviously bs. > But maybe we are just taking his words too literally. > I think it's actually a bigger problem at move 150. > Because at that point he is making a (very shaky) claim to truth. > I just hate the Go-World commentaries where the narrative has one side > making 3 catastrophic mistakes > and the other side coasting to an unshakable 1.5 point win. I always interpreted such statements differently. I'm aware that in some contexts betting on the outcomes of go and other games is very common. I had assumed that such statements were an indication that the speaker would be making a bet along those lines, it the option were available. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
2010/1/19 terry mcintyre : ( I recall a pro making such an observation; I was willing to accept his expertise on the matter. ) Any pro making such a comment at move 10 is just grand-standing. I have experienced pros making such comments too. You can let such a remark pass out of politeness of course, but accepting it because of his presumed expertise is extremely naive IMO. I would even be suspicious of pros making such comments at move 150. Mark If a pro predicts a half-point win early in the game, that is obviously bs. But maybe we are just taking his words too literally. I think it's actually a bigger problem at move 150. Because at that point he is making a (very shaky) claim to truth. I just hate the Go-World commentaries where the narrative has one side making 3 catastrophic mistakes and the other side coasting to an unshakable 1.5 point win. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
>As for other things we'd like to see improved, we could build a list. My pet >peeve is the KGS "score estimator", which is often wildly wrong. I've heard >>complaints about the implementation of the rules, and some have argued that >it is not terribly bot-friendly. A good SE is a terribly difficult problem. It more or less amounts to creating a good evaluation function. As the long pre-MC misery has shown, a good evaluation function is very hard to come by. MC in a nutshell is really "avoid evaluation". If resources were no problem, the best way to estimate the score would probably be to have an MC program find the komi that results in a 50% winrate. Stefan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
