Hide winrate bar etc. / Coloring of move evaluations

[qcgm1978]

Add more options in the View menu, as shown in the video. 屏幕录制2023-10-23 01.11.58.webm

const view_menu = menu('View', [
        ...
        menu('Stone', stone_style_submenu()),
        menu('Suggest number', suggest_num_submenu()),
        store_toggler_menu_item('Lizzie style', 'lizzie_style'),
        store_toggler_menu_item('Coordinates', 'always_show_coordinates'),
        store_toggler_menu_item('Expand winrate bar', 'expand_winrate_bar', 'Shift+B'),
        store_toggler_menu_item('Winrate mapping line', 'winrate_mapping_line',),
        store_toggler_menu_item('Show winrate bar', 'show_winrate_bar',),
        store_toggler_menu_item('Enable minor suggest', 'enable_minor_suggest'),
        store_toggler_menu_item('Enable Position-Dependent Action arrow', 'enable_pda_arrow'),
        ...
])

[kaorahi]

I'm happy you seem to be enjoying extension of lizgoban. :-)

But I am very very careful to add options/configurations/preferences in this project. In a past project, I accepted almost all requests on various configurations and they made debugging too difficult.

https://github.com/kaorahi/lizgoban/blob/915ed3269400c1a0559f3cf95cabc0d00e11378a/NOTE.txt#L16-L19

Preferences are also kept as small as possible because they make user-support difficult. They also cause bugs that appear only in specific preferences and such bugs are often overlooked by the developers.

By the way, I wonder what is the difference between [View] > [Main] and [View] > [Suggestions] in the menu.

For you information, "PDA" is the acronym of playoutDoublingAdvantage in Katago's gtp_example.cfg. See also the following description ("KataGo" section in the help menu of lizgoban).

Small blue up/down triangles on suggestions indicate the most preferred moves by "AIs for handicap games" as the stronger/weaker side in the first impression. "Moves like the stronger side" are also shown by sharper triangles in the winrate bar. (They are disabled on slow machines.)

[qcgm1978]

I misunderstood the meaning of the arrows, I thought PDA is the abbreviation of Position-Dependent Action. It is possible that there is no difference between Main and Suggestion boards, I should directly configure on the Suggestion board. In addition, about the representation of the next move, it is possible to consider using more conspicuous colors to represent points where the winning rate rises or falls sharply, they represent the winning move or losing move of this game, as shown in the figure.

function get_good_bad_color(h) {
    if (!h.anytime_stones) {
        return
    }
    let color 
    const winrate = h.data.winrate
    const is_black = h.anytime_stones[0].is_black
    const cur_winrate = is_black ? R.b_winrate : (100 - R.b_winrate)
    const variable_winrate = cur_winrate - winrate
    if (variable_winrate > 40) {
        color = RED
    } else if (variable_winrate < -40) {
        color = GREEN
    }
    return color
}

[kaorahi]

(Not sure if I fully understood your comment...)

The "next move" has two evaluations: (1) as a "candidate move" (child node) before it's actually made, and (2) as the "board state" (root node) after the move is made. Generally, (2) is more accurate. Specifically, bad moves often receive inaccurate evaluations in (1) due to limited visits. So it makes sense to rely more on (2) than on (1).

Right now, we use (2) only if (1) is missing --- namely, when the AI thinks the move is so bad it doesn't even consider it. The idea of "always showing (2) if available" is worth considering. How to display this in the interface is another issue.

[qcgm1978]

I'm not sure what "we use (2) only if (1) is missing" means, but I found that it currently returns the winning rate of all available points. It can be determined by h.next_move whether it is the "board state" (root node) after the current move is made. Then, the winning rate of that point can be compared to draw different colors.

[kaorahi]

If you are interested, see add_next_played_move_as_fake_suggest in powered_goban.js for the above "we use (2) only if (1) is missing".

There seem to be several independent concerns on the coloring of the suggested candidates.

(A) winrate / score I prefer score-based coloring to winrate-based coloring, as the latter gives only poor information in handicap games.

(B) discrete / continuous I've thought that using all colors in the continuous spectrum is better because it gives more information. But I also realize that using only several selected colors is easily recognizable at a glance. I am currently a bit unsure about this point.

(C) vivid / pale I understand that vivid coloring is generally more appealing and favored by many users. But, I personally prefer pale coloring for candidate moves since it makes it easier to mentally revert to the original board setup.

(D) change from the last opponent's move / my last move Most GUIs determine the coloring of each candidate move based on the change in evaluations before and after the move, in other words, comparison between the board setup after the nth move and the (n+1)th move. But, lizgoban uses the (n-1)th and (n+1)th moves for comparison as it matches better with how I intuitively see things. Typically, the best move is colored green. If the opponent makes a poor move, punishing moves are highlighted in cyan. Conversely, if we play a bad move followed by a punishing move from the opponent, all candidate moves are displayed in red, indicating that there's no way to recover from the damage.

In addition to these concerns, we also need to consider the visits of each candidate for coloring, as the evaluations can be unreliable if the number of visits is small.

[qcgm1978]

I'll take a look at the add_next_played_move_as_fake_suggest function. I'm not familiar with the use of Go AI.

The win rate seems to be a more widely accepted metric that's easier to understand than the score.

I think simple colors are more intuitive for videos that are easier to understand. Since the win rate chart already shows the difference between the two sides, I don't think it's necessary to use too many colors to represent the change.

I'm mainly considering how I would use this myself, which may not be the same as the project's requirements.

I've implemented the effect shown in the figure below locally. The next best move is represented by a green circle with a filled center, and the next mistake is filled with red.

[kaorahi]

I'm glad that you are interested in lizgoban, but I'm afraid it might be too complicated for those who are not familiar with Go AI. I enjoy experimenting with various new ideas for Go GUI in this project, resulting in a pile of uncommon features that might confuse AI beginners.

Have you tried other GUIs? For example, Ogatak is another Electron-based GUI and its appearance is much cleaner. I believe KaTrain is the most popular GUI these days.

[qcgm1978]

It's okay. I'm mainly interested in using the chess piece expression function in this project to learn more about Go AI. I'm really grateful to have found this project, and I posted the issue to share my thoughts. Thanks for your helpful reply.