order of R.suggest[]

[rexl2018]

Sometimes the R.suggest[0] doesn't seem to be better than R.suggest[1]/R.suggest[2]/R.suggest[3].

During auto-analysis, if the R.suggest[0] is not the best one(or even quite bad one), one step might take long time to be finished.

[kaorahi]

What do you mean by the word "best"? The engines determine the order of suggestions by a kind of total evaluations. Then R.suggest[0] may not have the best score or the maximum visits in some cases. This is not a problem, I think. GUI should respect the engine's recommendations.

Anyway, I agree that we want to use longer time for "difficult" situations. So LizGoban spends additional time when the engine finds a new promising move, unlike Lizzie, KaTrain, and so on. Namely, LizGoban watches the visits of R.suggest[0] (a1b4e6de) instead of the maximum visits or the total visits (555d6bbd) as the criterion in auto-analysis.

[rexl2018]

Thank you very much for the explanation. Would it be somewhat better if we watch the max in R.suggest[]?

[kaorahi]

Why do you think so?

I tried three criteria for auto-analysis.

• (A) Sum of visits over R.suggest[]
  • The engine searches in a constant time for every move.
  • The progress bar keeps a uniform pace.
• (B) Maximum of visits over R.suggest[]
  • The engine searches longer when there are many candidates.
  • The progress bar is slowed down or even stopped for a while in such cases.
• (C) Visits of R.suggest[0]
  • The engine searches further longer when it finds a new nice candidate.
  • The progress bar can even go back in such cases.

Then (C) seems desirable for me. Though the behavior of the progress bar is quite unnatural in (C), I can easily recognize what is occurring actually from the verbose winrate bar and the visits chart at the right bottom corner in LizGoban.

[rexl2018]

Or we can have a configuration for it?

[kaorahi]

Would you answer to my questions?

Anyway, I'd like to keep configurations as small as possible in this project. In my past project, I accepted almost all requests on various configurations and they made debugging too difficult. They tend to cause bugs that appear only in specific configurations and such bugs are often overlooked by the developers.

[rexl2018]

By using (B), as you said the search time will be close to constant, and normally the node with maximum visit is a good(sometimes best) candidate for next move even it is not R.suggest[0]. By using (C), there is small chance that the analysis takes quite long time. I encountered once many days ago, but I forgot which sgf I was using at that time.

Anyway, thanks a lot for sharing this powerful tool. I will close the issue and let's focus on other important things.

[kaorahi]

Thanks for your reply. Please let me know if you notice problems that I may overlook. I have only a portable note PC and I cannot imagine what happens in heavy analyses with GPU.