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.
Forget the middle slimes for a second. The two slimes that matter most are the leftmost and rightmost ones. How fast can the distance between them shrink?
In one operation, the current minimum can increase by at most , and the current maximum can decrease by at most . So the range can drop by at most per operation.
That gives a lower bound: if the initial range is , you need at least operations. No magic trick beats physics, sadly.
Can we always achieve that bound? Yes: choose somewhere between the current minimum and maximum, for example near the middle. Then every slime left of moves right and every slime right of moves left.
The answer is exactly In integer code, that is (mx - mn + 1) / 2.
Only the spread of the slimes matters:
If all slimes are already at one position, then and the answer is obviously .
Otherwise, look at the leftmost and rightmost slimes. In one operation, the leftmost slime can move right by at most , and the rightmost slime can move left by at most . So the distance between them can shrink by at most per operation.
Therefore, if the initial range is , we need at least
operations. That's the lower bound. Now we need to show it's not just a pessimistic math lecture.
We can always choose between the current minimum and maximum. Then every slime to the left of moves right, and every slime to the right of moves left. So the extremes can be pulled inward by one step each operation.
After operations, no slime needs to move more than steps toward the final meeting point. We just need some integer position that is within distance of every initial slime. Such a position exists exactly when the intervals
all overlap.
Since every lies between and , it is enough that
which means
The minimum such is
So the lower bound is achievable, and that is the answer. The middle slimes were just background extras.
For each test case, scan the array once to find and .
time per test case and
extra memory.
#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 t;
cin >> t;
while (t--) {
int n;
cin >> n;
int mn = 1000000000, mx = -1000000000;
for (int i = 0; i < n; i++) {
int x;
cin >> x;
mn = min(mn, x);
mx = max(mx, x);
}
cout << (mx - mn + 1) / 2 << '\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 t;
cin >> t;
while (t--) {
int n;
cin >> n;
int mn = 1000000000, mx = -1000000000;
for (int i = 0; i < n; i++) {
int x;
cin >> x;
mn = min(mn, x);
mx = max(mx, x);
}
cout << (mx - mn + 1) / 2 << '\n';
}
return 0;
}