-
Notifications
You must be signed in to change notification settings - Fork 30
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
Search progress visualization (evolving from 'PV board capture results' discussion) #100
Comments
That is by design. The current behavior is natural to me as it is the common style in most Go books. But if you like... (on c9a6377)
To comment in advance, I will NEVER implement the animation of the principal variation. In my opinion, it is useless because long variations are quite unreliable. Instead, if you want to watch the variation move by move, actually play it by pressing the Enter key repeatedly to get a more reliable sequence. You will notice that the result is often different from the original principal variation. |
You're right, but I need to directly modify the function draw_goban_with_variation(canvas, suggest, opts) {
...
const stone2move = (s, i, j) => s.stone && { move: idx2move(i, j), is_black: s.black }
const fake_history = aa_map(displayed_stones, stone2move).flat().filter(identity)
const vgame = require('./game.js').create_game(fake_history)
// different move_count has different pv
if (!R[R.move_count]) {
R[R.move_count] = {
variation,
pv_len: 0
}
} else {
const current_variation = R[R.move_count].variation
let i = 0
// avoid drawing the same pv part
for (i; i < current_variation.length; i++) {
if (current_variation[i] !== variation[i]) {
break;
}
}
R[R.move_count] = {
variation,
pv_len: R[R.move_count].pv_len < i ? R[R.move_count].pv_len : i
}
}
if (!opts.var_end) {
if (R.pv_timeout) {
opts.var_end = R[R.move_count].pv_len
} else {
R[R.move_count].pv_len++
opts.var_end = R[R.move_count].pv_len
R.pv_timeout = true
const timeout = 500
setTimeout(() => {
R.pv_timeout = false
}, timeout)
}
}
variation = variation.slice(0, opts.var_end ||
variation.length
)
variation.forEach((move, k) => {
...
vgame.push({ move, is_black: b })
})
const vstone = vgame.current_stones()
aa_each(displayed_stones, (s, i, j) => { s.stone = vstone[i][j].stone })
... 2023-11-29.21.15.25.mov |
Wow! I've never seen such a fun visualization of the search progress. It looks as if the AI is pondering various options and feeling undecided, just like a human. I'd like to keep this issue open, as other users might also find your movie interesting. |
I've been dreaming of displaying the killer move in my GUI for a long time --- the move whose discovery prompts the AI to change its previous opinion in the search process. But it seems it might require some tweaks to the engine itself and hasn't been realized yet... |
It is worth considering displaying multiple PV charts simultaneously. This has the following advantages:
I have completed the first step, which is to display multiple PVs simultaneously. After clicking on a PV, it can be displayed in original canvas. The next step is to consider adjusting the order and size based on some criteria, such as win rate. If specific data can be recorded, it will be possible to see which step of a change affected the win rate of a PV. This is what you mentioned as the "killer move." The demo video and core code as the following: 2024-02-15.16.15.18.mp4const draw_pv = with_opts((...args) => {
...
for (let i = 0; i < pv_num; i++) {
const c = document.querySelector(`#sub_goban_container_${i}`)
const arg = { ...args[1], ind: i }
draw(c, arg)
}
}, subgoban_mouse) |
The PV change diagram does not show the result of capturing, as shown in the figure.
I want to display the change diagram dynamically. It would be strange if capturing did not have any effect.
The text was updated successfully, but these errors were encountered: