A Confusion Regarding s_cur and s_best

[keezen]

In the algorithm description of the paper (page 22), $s_\text{cur}$ is globally initialized only once and updated exclusively when the score improves. This causes $s_\text{cur}$ to increase monotonically and always equal $s_\text{best}$. Is this an intentional design choice?

---

Algorithm 1 SkillOpt skill optimization
1: scur ← s0, sbest ← s0, C ← ∅, B ← [ ], mmeta ← ∅
...
20: if scorecand > scorecur then
21: scur ← s˜; scorecur ← scorecand
22: if scorecand > scorebest then
23: sbest ← s˜; scorebest ← scorecand
24: end if
...

[Yif-Yang]

Thanks for the careful reading — you are correct.

Under Algorithm 1 as written, s_cur == s_best and score_cur == score_best are invariants:

• They are initialized to the same skill and score.
• If score_cand > score_cur, then because score_cur == score_best before the update, score_cand > score_best must also hold, so both states are updated to the same candidate.
• Otherwise, neither state changes.

Therefore, on the strictly gated path described by Algorithm 1, the inner score_cand > score_best check is always true whenever it is reached. The current skill is monotonic and remains identical to the best skill. This is a harmless redundancy/clarity issue in the pseudocode rather than a change to the returned result.

The implementation keeps the two states because it also supports optional modes outside Algorithm 1 in which they can genuinely diverge. For example, disabling the gate can force-accept a candidate as the new current skill while retaining the historical best, and an optional ungated slow update can modify the current skill while preserving the validation-best snapshot. Those implementation extensions are not required by Algorithm 1 and should not be used to imply that the distinction is necessary in the paper's strictly gated procedure.

We will clarify this in a paper revision, either by collapsing the two states in Algorithm 1 or by making their joint update explicit and noting why the implementation retains separate bookkeeping. Thank you for catching the ambiguity.

[Yif-Yang]

The repository-guide clarification has now merged in #301 (d6a853a86f3824b40b920c173d4f1075fe409dc4). It explains why current and best remain equal on the strict Algorithm 1 path and distinguishes optional implementation modes in which they can diverge. The reviewed change passed official CI and the integrated strict documentation build.

This completes the repository-documentation part only: #301 does not revise the paper. I am keeping this issue open to track the paper-pseudocode clarification already discussed above, rather than treating a guide update as fulfillment of that separate commitment.