| # | User | Rating |
|---|---|---|
| 1 | Benq | 3792 |
| 2 | VivaciousAubergine | 3647 |
| 3 | Kevin114514 | 3603 |
| 4 | jiangly | 3583 |
| 5 | strapple | 3515 |
| 6 | tourist | 3470 |
| 7 | dXqwq | 3436 |
| 8 | Radewoosh | 3415 |
| 9 | Otomachi_Una | 3413 |
| 10 | Um_nik | 3376 |
| # | User | Contrib. |
|---|---|---|
| 1 | Qingyu | 158 |
| 2 | adamant | 152 |
| 3 | Um_nik | 146 |
| 4 | Dominater069 | 144 |
| 5 | errorgorn | 141 |
| 6 | cry | 139 |
| 7 | Proof_by_QED | 136 |
| 8 | YuukiS | 135 |
| 9 | chromate00 | 134 |
| 9 | TheScrasse | 134 |
|
0
About D1, you can reconcile the idea and the code like this: the real constraint isn’t simply “you can’t insert in the middle,” but that any insertion must not break an already satisfied prefix w condition (mex = k). The loop from i = 0 to n − 2 is effectively counting how many insertion positions are safe before the first position where inserting would destroy the existing prefix property. When m = 1, a full segment with mex = k must remain intact, so only the two ends work; when m = 0, as long as the prefix hasn’t reached mex = k yet, inserting won’t affect it, giving i valid positions. From this perspective, the code is implicitly checking the previous w-state rather than explicitly reasoning about “middle vs ends,” so the implementation and the intended logic do line up—just from different angles. |
|
0
it is crazy for me |
|
-14
难:) |
| Name |
|---|


