Search for a command to run...
Progressive hints first, then the full explanation and implementation when you're ready to cash out.
Review status
AI-generated and still unreviewed. Double-check the details before internalizing them.
Hints
Open only as much as you need to keep the solve alive.
Think like the checker. Keep the set of possible current skills. A mission only changes the state if its difficulty is currently in that set.
For a fixed difficulty , the cheapest useful duration is the gap to the next still-possible skill: choose . Then all possibilities at merge into an existing possibility, so the set shrinks by one.
The bad tradeoff is simple: increasing order has tiny durations but pays the surcharge constantly; decreasing order pays almost no surcharge but creates huge gaps. So we need mostly decreasing chunks, but not one giant chunk.
First make every possible skill congruent to modulo . For each bad residue , remove in decreasing order. Each useful mission has duration .
Then repeat the same idea for modulo , , etc. If current survivors are spaced by , remove the wrong residue classes modulo using duration . With and , exactly layers are enough and the cost fits under .
The important move is to stop thinking about one hidden skill and instead track all possible skills at once.
Initially the possible set is
If we do a mission with difficulty and duration , then only the possibility changes. It becomes . So, at the set level:
if . If , the mission is useless. Very inspirational stuff.
Our goal is to shrink all possibilities below into .
Choosing the duration
Suppose we already decided to use difficulty , and .
The cheapest useful thing is to merge into the next larger possible skill:
Then is already in , so the number of possible skills decreases by . Any larger duration is more expensive and does not help more for this construction.
So from now on, the real problem is: in what order do we delete the numbers from this ordered set?
Why the dumb orders fail
If we delete in increasing order:
every duration is , which is great, but every next difficulty is larger than the previous one, so we pay the tax about times. Dead on arrival.
If we delete in decreasing order:
we almost never pay the tax, but the gaps explode. After deleting , deleting needs duration , then duration , and so on. Also dead.
So we want chunks that are decreasing, while keeping gaps controlled.
The modulo idea
Pick a base . For the large test, we can use
First, we force every possible skill to become congruent to modulo .
For example, if , we delete residue class first:
and then residue class :
Each list is decreasing, so there is no surcharge inside it. Also, every deleted value merges into the next larger value, so every duration is .
After this layer, the only remaining possible skills are congruent to modulo .
Next layers
Now survivors are spaced by . To force them to be congruent to modulo , we do the same thing, but with step size .
More generally, suppose after some layers all remaining values are congruent to modulo .
To upgrade this to modulo , delete the bad residue classes. For , output
while .
Every mission in this layer has duration , because the next still-possible value above is exactly . If , that target residue will be processed later in the same layer; if , it lands in the final residue for this layer.
After the layer, only numbers congruent to modulo survive.
We repeat this while . Once , the only number in congruent to modulo is itself. That means every starting skill has been merged into , so the strategy guarantees success.
Cost
For and :
so we need exactly layers: .
In one layer with spacing , we output at most missions, each of duration , so the duration cost of a layer is at most . Across layers, that is at most
The surcharge happens only when jumping from the end of one decreasing residue-class block to the start of the next one. There are at most nonempty blocks, so the surcharge is below
Total cost is below , safely under .
The number of missions is exactly for the large test, because every value below is deleted once. That is also below .
For , we can just print the tiny sample construction. The problem literally has only two tests, so no need to cosplay as a general-purpose library.
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
void setIO() {
ios::sync_with_stdio(false);
cin.tie(nullptr);
}
int main() {
setIO();
int n;
cin >> n;
vector<pair<int, int>> ans;
if (n == 4) {
ans = {{1, 4}, {3, 1}, {2, 1}, {3, 1}};
} else {
const int m = 63;
for (ll p = 1; p < n; p *= m) {
for (int r = m - 1; r >= 1; --r) {
for (ll y = n - 1LL * r * p; y >= 1; y -= 1LL * m * p) {
ans.push_back({(int)y, (int)p});
}
}
}
}
cout << ans.size() << '\n';
for (auto [y, l] : ans) {
cout << y << ' ' << l << '\n';
}
return 0;
}#include <bits/stdc++.h>
using namespace std;
using ll = long long;
void setIO() {
ios::sync_with_stdio(false);
cin.tie(nullptr);
}
int main() {
setIO();
int n;
cin >> n;
vector<pair<int, int>> ans;
if (n == 4) {
ans = {{1, 4}, {3, 1}, {2, 1}, {3, 1}};
} else {
const int m = 63;
for (ll p = 1; p < n; p *= m) {
for (int r = m - 1; r >= 1; --r) {
for (ll y = n - 1LL * r * p; y >= 1; y -= 1LL * m * p) {
ans.push_back({(int)y, (int)p});
}
}
}
}
cout << ans.size() << '\n';
for (auto [y, l] : ans) {
cout << y << ' ' << l << '\n';
}
return 0;
}