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.
Don’t think about the two numbers simultaneously yet. Ask: if one number uses exactly divide-operations, what is the smallest value it can have before doing any final increments?
After divisions, doing no increments gives
Any increments done before divisions are never better than doing suitable increments after those divisions. Division does not magically multiply your +1s — it usually murders them.
For one number , if after divisions its base value is
then reaching any costs exactly
Now choose divisions for and divisions for . Their values become
The best common final value is just , so the extra increments cost .
So the answer is the tiny brute force:
Generate the sequences and same for , then try all pairs. There are at most about values per number.
We have two operations:
increment one number by ,
replace one number by .
At first glance, increments before divisions look tricky because of rounding. For example, maybe adding a little before dividing changes the quotient. Classic floor-function bait. Luckily, it is bait.
Fix one starting number . Suppose a path uses exactly divide-operations and some number of increments, and ends at value .
If we delete all increments from this path, the value after the divisions is exactly
Adding increments somewhere in the path cannot make the final value smaller, so necessarily
Also, each increment can increase the final value by at most . If an increment happens before a division, it may even get destroyed by the floor, because division is a cruel little bastard. Therefore to reach after divisions, we need at least
increments.
And this bound is achievable: do the divisions first, reaching , then increment times.
So for one number , using exactly divisions, the cost to reach is
Let us choose:
Then their base values are
After that, we can only increment. The cheapest common value is obviously
because making both numbers even larger is just wasting operations for sport.
The increment cost is
So for this pair , total cost is
Therefore the answer is
The sequence
has length at most , and since and , that is at most about values.
So we generate all pairs for both and , try every pair, and take the minimum.
For each test case, there are states for and states for .
Thus the complexity is
which is tiny. Memory usage is
#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--) {
ll a, b, x;
cin >> a >> b >> x;
vector<pair<ll, int>> A, B;
int steps = 0;
ll cur = a;
while (true) {
A.push_back({cur, steps});
if (cur == 0) break;
cur /= x;
++steps;
}
steps = 0;
cur = b;
while (true) {
B.push_back({cur, steps});
if (cur == 0) break;
cur /= x;
++steps;
}
ll ans = (1LL << 60);
for (auto [va, da] : A) {
for (auto [vb, db] : B) {
ans = min(ans, (ll)da + db + llabs(va - vb));
}
}
cout << ans << '\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--) {
ll a, b, x;
cin >> a >> b >> x;
vector<pair<ll, int>> A, B;
int steps = 0;
ll cur = a;
while (true) {
A.push_back({cur, steps});
if (cur == 0) break;
cur /= x;
++steps;
}
steps = 0;
cur = b;
while (true) {
B.push_back({cur, steps});
if (cur == 0) break;
cur /= x;
++steps;
}
ll ans = (1LL << 60);
for (auto [va, da] : A) {
for (auto [vb, db] : B) {
ans = min(ans, (ll)da + db + llabs(va - vb));
}
}
cout << ans << '\n';
}
return 0;
}