Hi tcocarogallart,Yes, there is a cleaner shortcut, and the good news is you've already spotted the right principle:
a remainder when dividing by d must satisfy 0 ≤ r < d. You just need to know
where in Aks111's algebra to deploy it, so you never have to hunt for a k at all.
Where to insert the bound checkLook at Aks111's line that splits the cases:
3n = 12 + (b - a) with
|b - a| = 3 - either b - a =
3 (giving n =
5) or a - b =
3 (giving n =
3).
That second branch is the one to kill on sight. Here's the move:
The branch demands a - b =
3, so
a ≥ 3 (since b ≥
0). But on this branch n =
3, and a is the remainder when dividing by n - so a is forced into
{0, 1, 2}. The two requirements
a ≥ 3 and
a ≤ 2 can't both hold. The branch dies right there.
No constructing k =
30, no checking mod
5 =
0, no extra arithmetic - one inequality comparison and you're done.
The general DS habitWhenever a remainder problem produces a candidate divisor, immediately check:
"Does this candidate force the remainder to be ≥ the divisor itself?"If yes, kill the branch. Two tiny rehearsals:
- "Remainder
3 when divided by
3" - impossible (max remainder is
2).
- "Remainder
5 when divided by
3" - impossible (max remainder is
2).
Same principle, easy to apply in two seconds.
One caveatYou can't skip the algebra
entirely - you still need 3n =
12 + (b - a) to expose the two candidates and, crucially, which side of the difference is the bigger remainder. That sign is what makes the bound check possible in the first place. But once the candidates appear, you can dismiss n =
3 with the inequality alone.
So Statement (2) cleanly gives
n = 5, matching Statement (1).
Answer: Dtcocarogallart
Bunuel, is there a better way to discard the option that ellicits n=3 (not possible if we have a remainder of 3) before doing the math as was done in the answer above?