Wait, it's actually orange.
Jokes aside, so glad to finally achieve Master!
| # | User | Rating |
|---|---|---|
| 1 | Benq | 3792 |
| 2 | VivaciousAubergine | 3647 |
| 3 | jiangly | 3631 |
| 4 | Kevin114514 | 3574 |
| 5 | maroonrk | 3521 |
| 6 | strapple | 3515 |
| 7 | Radewoosh | 3461 |
| 8 | tourist | 3428 |
| 9 | turmax | 3378 |
| 10 | Um_nik | 3376 |
| # | User | Contrib. |
|---|---|---|
| 1 | Qingyu | 161 |
| 2 | adamant | 146 |
| 3 | Um_nik | 145 |
| 4 | Dominater069 | 142 |
| 5 | errorgorn | 140 |
| 6 | cry | 138 |
| 7 | Proof_by_QED | 136 |
| 8 | YuukiS | 135 |
| 9 | chromate00 | 134 |
| 10 | soullless | 133 |
Wait, it's actually orange.
Jokes aside, so glad to finally achieve Master!
In this blog, I will share an approach that achieves fewer expected queries than the official editorial.
The standard solution uses exactly 33 queries, but we can do better in most cases.
The editorial performs three independent binary searches.
Each binary search takes at most 11 queries, totaling 33.
To optimize this, we can randomly shuffle all indices at the beginning.
By shuffling, the target positions are uniformly distributed, which often reduces the search range for the second and third binary searches.
Here is the probability distribution of total queries after randomization.
| Queries | Counts | Probabllity |
|---|---|---|
| <= 29 | 46891456 | 3.5% |
| >= 30 | 1286441544 | 96.5% |
| >= 31 | 1212227208 | 90.9% |
| >= 32 | 1027092744 | 77% |
| == 33 | 643170824 | 48.2% |
(There are a total of 1333333000 possible combinations)
As shown in the table, the probability of hitting the 33-query limit is only about 48.2%.
The expected number of queries is approximately 32.1064 .
You can verify it with the following code:
#include<bits/stdc++.h>
#pragma GCC optimize(2)
#define int long long
using namespace std;
int cnt , mx30 , mx31 , mx32 , mx33 , cntt;
double avg;
signed main()
{
ios::sync_with_stdio(0);
ios_base::sync_with_stdio(0);
cin.tie(0);
cout.tie(0);
for(int i = 1 ; i <= 1999 ; i++)
{
for(int j = i + 1 ; j <= 2000 ; j++)
{
for(int k = j + 1 ; k <= 2001 ; k++)
{
cnt = ceil(log2(j)) + ceil(log2(k)) + ceil(log2(2001));
if(cnt >= 30)
{
mx30++;
}
if(cnt >= 31)
{
mx31++;
}
if(cnt >= 32)
{
mx32++;
}
if(cnt >= 33)
{
mx33++;
}
avg += cnt;
cntt++;
}
}
}
cout << avg / cntt << ' ' << cntt << '\n';
cout << mx30 << ' ' << mx31 << ' ' << mx32 << ' ' << mx33;
return 0;
}
Below is the optimized implementation.
#include<bits/stdc++.h>
#pragma GCC optimize(2)
#define int long long
using namespace std;
int t , n , x , l , r , w[2005] , b , c , mid , ans , anss , ansss;
inline bool chk(int x , int y)
{
if(x % 2 == y % 2)
{
return 0;
}
return 1;
}
signed main()
{
ios::sync_with_stdio(0);
ios_base::sync_with_stdio(0);
cin.tie(0);
cout.tie(0);
srand(time(0));
cin >> t;
while(t--)
{
cin >> n;
for(int i = 1 ; i <= n * 2 + 1 ; i++)
{
w[i] = i;
}
random_shuffle(w + 1 , w + n * 2 + 2);
l = 1;
r = n * 2 + 1;
while(l <= r)
{
mid = (l + r) / 2;
cout << "? " << mid;
for(int i = 1 ; i <= mid ; i++)
{
cout << ' ' << w[i];
}
cout << endl;
cin >> x;
if(chk(x , mid))
{
ans = mid;
r = mid - 1;
}
else
{
l = mid + 1;
}
}
c = ans;
ans = w[ans];
l = 1;
r = c - 1;
while(l <= r)
{
mid = (l + r) / 2;
cout << "? " << mid + 1;
for(int i = 1 ; i <= mid ; i++)
{
cout << ' ' << w[i];
}
cout << ' ' << ans << endl;
cin >> x;
if(chk(x , mid + 1))
{
anss = mid;
r = mid - 1;
}
else
{
l = mid + 1;
}
}
b = anss;
anss = w[anss];
l = 1;
r = b - 1;
while(l <= r)
{
mid = (l + r) / 2;
cout << "? " << mid + 2;
for(int i = 1 ; i <= mid ; i++)
{
cout << ' ' << w[i];
}
cout << ' ' << ans << ' ' << anss << endl;
cin >> x;
if(chk(x , mid + 2))
{
ansss = mid;
r = mid - 1;
}
else
{
l = mid + 1;
}
}
ansss = w[ansss];
cout << "! " << ans << ' ' << anss << ' ' << ansss << endl;
}
return 0;
}
(Note: For a more robust randomization, shuffle() with mt19937 is recommended over random_shuffle().)
As you can see, the optimization is so massive that you can barely notice it. But in a world of 33-query limits, 0.9 is a luxury I'm willing to flex.
Thanks for reading!
My friend lijinghui has been banned for making too many submissions. This is his appeal.
Dear Codeforces Administrator,
My account, lijinghui, has been banned due to excessive submissions. I am writing to request an unban.
On the afternoon of March 17th, I was working on two difficulty levels of problem 2002F simultaneously. Since I needed to complete both, I submitted code for each. However, due to the large time constant, I had to optimize the execution time and made many attempts, resulting in an excessive number of submissions. I deeply realize my mistake and sincerely apologize for the burden this placed on the Codeforces judging system.
I assure you that I will not engage in such behavior in the future. I hope that you may consider unbanning my account.
Thank you very much.
The last rollback from Goodbye 2025 Codeforces round starkly reveals a crisis of fairness. My rank jumped from 3141 to 3017, not because my code suddenly optimized itself, but because a large number of cheaters were skipped. It means 124 fraudulent participants were skipped from the top 3000. This indicates that approximately 4.13% of top contestants relied on AI to generate solutions.
Moreover, there must be more cheaters who have not been detected and still steal top rankings and high ratings.
Such behavior does not merely exploit a loophole—it fundamentally ruins the spirit of competitive programming. Platforms like Codeforces are designed to test problem-solving under pressure, creativity, and the rigorous application of algorithms. When code is mass-produced by AI rather than cultivated through careful thought, contestants cheat not only the system but also themselves, missing the growth that comes from struggle and debugging.
Worse, this trend erodes trust across the community. Honest participants see their efforts devalued, while the scoreboard becomes a distorted reflection of true skill. If contests turn into battles of who can best manipulate AI tools, rather than who can think critically and adapt, they lose their purpose as arenas for human intellectual growth.
I urge Codeforces and similar platforms to strengthen plagiarism detection and adopt proactive measures against AI misuse. More importantly, we call on every participant to uphold integrity—because the true reward of competitive programming lies not in a temporary rating, but in the authentic, hard-won brilliance of human thought.
This is no longer just a loophole — it is an existential threat to the credibility of our community. Every skipped cheater represents a stolen moment of genuine effort, a legitimate ranking that was unfairly denied. We cannot remain silent while the arena we cherish is corrupted by AI posing as intellect.
We must act now: first, advocate for stricter, real-time code provenance analysis that detects AI-generated patterns beyond simple plagiarism. Second, as a community, we must cultivate a culture of collective vigilance—where reporting suspicious activity is seen as an act of honor.
The scoreboard should reflect human minds at their most resilient, not the most efficient cheating methods. If we fail to defend this principle, we risk losing the very soul of competitive programming.
There are platforms now using temporary email addresses to register bots.
The pattern of these bots is that they are all unrated and the username is a random number or letter of length 10, and they will submit several times per minute.
I suggest Mike send an email every 200 submissions to all unrated accounts' email to verify this type of bot.
Here are some examples:
0n9nm0y6ho submitted more than 60 submissions in just 20 mintues.
tzqymu69i6 50 summissions in half an hour.
zunbgg8w3g also 60 submissions in half an hour.
I want to know why they are all using Python and have the following code content:
if __name__ == "__main__":
main()
Are they training AI?
These bots seriously affect normal user code submission.
MikeMirzayanov, please ban them.
UPD: They're back. This time it's a random string followed by a random number.
| Name |
|---|


