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

Continue searching when the result is unclear #209

Closed
ujh opened this issue Nov 8, 2015 · 3 comments
Closed

Continue searching when the result is unclear #209

ujh opened this issue Nov 8, 2015 · 3 comments
Labels
Milestone

Comments

@ujh
Copy link
Owner

ujh commented Nov 8, 2015

When the time for a move is up and the best move is selected it may be beneficial to continue searching a bit longer when the result isn't clear cut.

A possible strategy is as follows:

  1. Select the best move by number of plays
  2. Select the best move by win ratio
  3. If the two aren't the same continue searching for N amount of time if there's still enough time left

See the computer go mailing list archive for inspiration or other solutions. Some bots seem to do this a lot and with M being the amount of time allocated initially for the move the go as far as 3*M for N.

@ujh ujh added the feature label Nov 8, 2015
@ujh ujh added this to the 0.4.0 milestone Nov 8, 2015
@ujh ujh modified the milestones: 0.3.3, 0.4.0 May 1, 2016
@ujh ujh added the 1 - Ready label May 2, 2016
@ujh ujh mentioned this issue Aug 4, 2016
@iopq
Copy link
Collaborator

iopq commented Aug 4, 2016

I tried a similar approach (return the move with the best win ratio), but it didn't improve strength. Maybe searching more is the key here.

@ujh
Copy link
Owner Author

ujh commented Aug 4, 2016

I'm not sure to be honest. I've currently trying a few things and none of them seem to improve the bot. Even the large patterns (#298) isn't really working. I guess the time for easy wins is over.

@ujh
Copy link
Owner Author

ujh commented Aug 8, 2016

Aaaaand it didn't help. 😁 It's probably better to just optimise the variables in time_control instead.

@ujh ujh closed this as completed Aug 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants