Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make katago solve dead-alive go problems #261

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

kinfkong
Copy link
Contributor

Make katago to solve dead-alive go problems by adding a new extented GTP command:

  • kata-problem_analyze [player (optional)] [interval (optional)] KEYVALUEPAIR KEYVALUEPAIR
    • this extented GTP command is used for solving life-dead problems.
    • Same as kata-analyze except with the options and fields :
    • Additional possible key-value pairs:
      • topleft M19 - Sets the problem valid area - the top left corner
      • bottomright T14 - Sets the problem valid area - the bottom right corner
    • if topoleft or bottomright is not set, use the full board.

@lightvector
Copy link
Owner

Fascinating. How extensively have you tested this? I have to think there's a chance of some weird side effects - for example suppose that the opponent has just played a huge sente threat that massively outweighs the value of a corner life/death you are trying to analyze. Is the policy prior at all reasonable when restricted to this corner? And does the value net do anything good for the search, or just wildly oscillate as each side is forced to ignore the sente move?

You could have KataGo end up "failing" to solve a simple life and death purely because the MCTS works extremely poorly if all the policy prior is elsewhere, right?

I'm curious if there's a good way to distinguish ko as well.

@kinfkong
Copy link
Contributor Author

I also changed the Sabaki code to make the feature easy to use. And I tested about 10 high Dan problems and it looks so far so good. Anyway, I will do more tests later

@yzyray
Copy link
Contributor

yzyray commented Jul 29, 2020

It seem will crash if limited in small area.like this
微信截图_20200729145837

@kaorahi
Copy link
Contributor

kaorahi commented Aug 2, 2020

Do you have any idea about ko threats? In my past experiences, bots tend to be satisfied with ko solutions and overlook unconditional solutions unless I set appropriate ko threats.

I'm trying another approach to fill the outside region automatically so that the areas are even and only the opponent has ko threats. Is there a better way?

tsumego_frame
(problem in http://www.h-eba.com/heba/tumego/eba1.html)

@awsjgy
Copy link

awsjgy commented Oct 16, 2023

Do you have any idea about ko threats? In my past experiences, bots tend to be satisfied with ko solutions and overlook unconditional solutions unless I set appropriate ko threats.

I'm trying another approach to fill the outside region automatically so that the areas are even and only the opponent has ko threats. Is there a better way?

tsumego_frame (problem in http://www.h-eba.com/heba/tumego/eba1.html)

I've tried this method of yours and there are still problems with certain aspects. For example, when encountering a positively solved robocide question, ai may not do the dead-or-alive question or think it can't be counted because the number of dead-or-alive robberies doesn't match or is less valuable than the other areas outside of the dead-or-alive question. It would be nice to have the freedom to set the number of robberies to a few, or the value of the dead-or-alive question to be greater than the value of the robberies. Another request, some dead-end problems specify eating a certain piece, but the method of choosing a region is often rectangular, which doesn't do this. Because multiple pieces are involved
我尝试过你的这个方法,还是存在问题,某些方面。比如遇到正解打劫杀的题,ai可能会因为死活题劫财数量和死活题之外的区域不匹配或价值不如其他区域,而不做这道死活题,或认为算不出这道题。如果能自由设置劫财数量为几个,或死活题价值大于打劫价值会更好。还有一个请求,有些死活题是指定吃掉某一块棋子,但是选择区域的方法往往是矩形,做不到这一点。因为涉及到多块棋子

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants