# Small Competitive Programming Mistakes That Cost Me AC↵
↵
↵
Hi everyone!↵
↵
I am still learning competitive programming, and recently I noticed that many of my wrong submissions were not caused by difficult algorithms.↵
↵
They were caused by very small mistakes.↵
↵
So I decided to collect some of the mistakes that cost me AC, especially for beginners.↵
↵
[cut]↵
↵
## 1. Using `int` when the answer needs `long long`↵
↵
Sometimes every individual value fits inside `int`, but their product or total sum does not.↵
↵
For example:↵
↵
```cpp↵
int n = 100000;↵
int x = 100000;↵
↵
cout << n * x;↵
```↵
↵
`n * x = 10^10`, which does not fit inside a 32-bit `int`.↵
↵
A safer version is:↵
↵
```cpp↵
long long ans = 1LL * n * x;↵
```↵
↵
The important part is `1LL`.↵
↵
---↵
↵
## 2. Forgetting that integer division removes the decimal part↵
↵
Consider:↵
↵
```cpp↵
int x = 25;↵
↵
double p = x / 100;↵
```↵
↵
You might expect `0.25`, but the result is actually `0`.↵
↵
Why?↵
↵
Because `x` and `100` are both integers, so integer division happens first.↵
↵
Correct:↵
↵
```cpp↵
double p = x / 100.0;↵
```↵
↵
---↵
↵
## 3. Floating-point numbers are not always exact↵
↵
Sometimes:↵
↵
```cpp↵
double x = 0.1 + 0.2;↵
```↵
↵
is not stored internally as exactly `0.3`.↵
↵
So comparing doubles using:↵
↵
```cpp↵
if (x == 0.3)↵
```↵
↵
can be dangerous.↵
↵
Usually, use an epsilon:↵
↵
```cpp↵
const double EPS = 1e-9;↵
↵
if (abs(x - 0.3) < EPS)↵
```↵
↵
Also, do not automatically use `round()` everywhere. Use it only when the problem actually asks for rounding.↵
↵
---↵
↵
## 4. An `O(n^2)` idea can look fast on small tests↵
↵
This code may look harmless:↵
↵
```cpp↵
for (int i = 0; i < n; i++) {↵
for (int j = 0; j < n; j++) {↵
// ...↵
}↵
}↵
```↵
↵
But if:↵
↵
```text↵
n = 200000↵
```↵
↵
then the number of operations is roughly:↵
↵
```text↵
4 * 10^10↵
```↵
↵
which is far too much.↵
↵
Before coding, I now try to estimate the complexity first.↵
↵
A useful rough guide:↵
↵
- `n <= 20` → exponential solutions may be possible↵
- `n <= 2000` → `O(n^2)` may be possible↵
- `n <= 2 * 10^5` → usually aim for `O(n log n)` or `O(n)`↵
↵
These are not strict rules, but they are useful estimates.↵
↵
---↵
↵
## 5. `map` can secretly make the solution slower↵
↵
Sometimes we use:↵
↵
```cpp↵
map<int, int> mp;↵
```↵
↵
even when a simple array or vector is enough.↵
↵
`map` operations are approximately:↵
↵
```text↵
O(log n)↵
```↵
↵
while direct array access is:↵
↵
```text↵
O(1)↵
```↵
↵
If values are small enough, this:↵
↵
```cpp↵
vector<int> freq(MAX_VALUE + 1);↵
```↵
↵
can be much faster.↵
↵
Of course, `map` is still useful when keys are large, sparse, or ordered traversal is needed.↵
↵
---↵
↵
## 6. Forgetting edge cases↵
↵
A solution may work on all the examples and still fail immediately because of something like:↵
↵
```text↵
n = 1↵
all values equal↵
answer = 0↵
maximum possible value↵
minimum possible value↵
```↵
↵
Before submitting, I try to test:↵
↵
```text↵
smallest input↵
largest special case↵
all equal↵
strictly increasing↵
strictly decreasing↵
```↵
↵
Not every problem needs all of them, but thinking about these cases catches many bugs.↵
↵
---↵
↵
## 7. Changing a variable while still depending on its old value↵
↵
Example:↵
↵
```cpp↵
a[i] = x;↵
↵
if (condition(a[i])) {↵
...↵
}↵
```↵
↵
Sometimes we actually needed information about the old `a[i]` before replacing it.↵
↵
A safer update pattern is often:↵
↵
```cpp↵
removeContribution(a[i]);↵
↵
a[i] = x;↵
↵
addContribution(a[i]);↵
```↵
↵
This is especially useful in problems with queries and frequency counting.↵
↵
---↵
↵
## 8. Greedy solutions need a reason↵
↵
One of my most common mistakes was:↵
↵
> "Choosing the largest value looks optimal."↵
↵
Sometimes it is.↵
↵
Sometimes it gives WA on test 2.↵
↵
Before using greedy, I now ask:↵
↵
**If I make this choice now, can it make the future worse?**↵
↵
If the answer might be yes, then the greedy idea needs proof.↵
↵
---↵
↵
## 9. Do not optimize before understanding the problem↵
↵
Sometimes I immediately think about:↵
↵
- binary search↵
- DP↵
- graphs↵
- Fenwick trees↵
- advanced data structures↵
↵
while the real observation is just:↵
↵
```text↵
sort the array↵
```↵
↵
or:↵
↵
```text↵
count frequencies↵
```↵
↵
Understanding what the problem is actually asking is often more important than knowing more algorithms.↵
↵
---↵
↵
## 10. Read the statement one more time before submitting↵
↵
This sounds obvious, but many WA submissions come from missing one word:↵
↵
- exactly↵
- at most↵
- at least↵
- distinct↵
- non-decreasing↵
- positive↵
- non-negative↵
↵
Those words can completely change the solution.↵
↵
---↵
↵
## Final thought↵
↵
Competitive programming is not only about learning more algorithms.↵
↵
It is also about making fewer unnecessary mistakes.↵
↵
Every WA or TLE can teach something useful if you understand why it happened.↵
↵
If you know another small mistake that often causes WA/TLE, feel free to add it in the comments.↵
↵
Good luck and happy coding!
↵
↵
Hi everyone!↵
↵
I am still learning competitive programming, and recently I noticed that many of my wrong submissions were not caused by difficult algorithms.↵
↵
They were caused by very small mistakes.↵
↵
So I decided to collect some of the mistakes that cost me AC, especially for beginners.↵
↵
[cut]↵
↵
## 1. Using `int` when the answer needs `long long`↵
↵
Sometimes every individual value fits inside `int`, but their product or total sum does not.↵
↵
For example:↵
↵
```cpp↵
int n = 100000;↵
int x = 100000;↵
↵
cout << n * x;↵
```↵
↵
`n * x = 10^10`, which does not fit inside a 32-bit `int`.↵
↵
A safer version is:↵
↵
```cpp↵
long long ans = 1LL * n * x;↵
```↵
↵
The important part is `1LL`.↵
↵
---↵
↵
## 2. Forgetting that integer division removes the decimal part↵
↵
Consider:↵
↵
```cpp↵
int x = 25;↵
↵
double p = x / 100;↵
```↵
↵
You might expect `0.25`, but the result is actually `0`.↵
↵
Why?↵
↵
Because `x` and `100` are both integers, so integer division happens first.↵
↵
Correct:↵
↵
```cpp↵
double p = x / 100.0;↵
```↵
↵
---↵
↵
## 3. Floating-point numbers are not always exact↵
↵
Sometimes:↵
↵
```cpp↵
double x = 0.1 + 0.2;↵
```↵
↵
is not stored internally as exactly `0.3`.↵
↵
So comparing doubles using:↵
↵
```cpp↵
if (x == 0.3)↵
```↵
↵
can be dangerous.↵
↵
Usually, use an epsilon:↵
↵
```cpp↵
const double EPS = 1e-9;↵
↵
if (abs(x - 0.3) < EPS)↵
```↵
↵
Also, do not automatically use `round()` everywhere. Use it only when the problem actually asks for rounding.↵
↵
---↵
↵
## 4. An `O(n^2)` idea can look fast on small tests↵
↵
This code may look harmless:↵
↵
```cpp↵
for (int i = 0; i < n; i++) {↵
for (int j = 0; j < n; j++) {↵
// ...↵
}↵
}↵
```↵
↵
But if:↵
↵
```text↵
n = 200000↵
```↵
↵
then the number of operations is roughly:↵
↵
```text↵
4 * 10^10↵
```↵
↵
which is far too much.↵
↵
Before coding, I now try to estimate the complexity first.↵
↵
A useful rough guide:↵
↵
- `n <= 20` → exponential solutions may be possible↵
- `n <= 2000` → `O(n^2)` may be possible↵
- `n <= 2 * 10^5` → usually aim for `O(n log n)` or `O(n)`↵
↵
These are not strict rules, but they are useful estimates.↵
↵
---↵
↵
## 5. `map` can secretly make the solution slower↵
↵
Sometimes we use:↵
↵
```cpp↵
map<int, int> mp;↵
```↵
↵
even when a simple array or vector is enough.↵
↵
`map` operations are approximately:↵
↵
```text↵
O(log n)↵
```↵
↵
while direct array access is:↵
↵
```text↵
O(1)↵
```↵
↵
If values are small enough, this:↵
↵
```cpp↵
vector<int> freq(MAX_VALUE + 1);↵
```↵
↵
can be much faster.↵
↵
Of course, `map` is still useful when keys are large, sparse, or ordered traversal is needed.↵
↵
---↵
↵
## 6. Forgetting edge cases↵
↵
A solution may work on all the examples and still fail immediately because of something like:↵
↵
```text↵
n = 1↵
all values equal↵
answer = 0↵
maximum possible value↵
minimum possible value↵
```↵
↵
Before submitting, I try to test:↵
↵
```text↵
smallest input↵
largest special case↵
all equal↵
strictly increasing↵
strictly decreasing↵
```↵
↵
Not every problem needs all of them, but thinking about these cases catches many bugs.↵
↵
---↵
↵
## 7. Changing a variable while still depending on its old value↵
↵
Example:↵
↵
```cpp↵
a[i] = x;↵
↵
if (condition(a[i])) {↵
...↵
}↵
```↵
↵
Sometimes we actually needed information about the old `a[i]` before replacing it.↵
↵
A safer update pattern is often:↵
↵
```cpp↵
removeContribution(a[i]);↵
↵
a[i] = x;↵
↵
addContribution(a[i]);↵
```↵
↵
This is especially useful in problems with queries and frequency counting.↵
↵
---↵
↵
## 8. Greedy solutions need a reason↵
↵
One of my most common mistakes was:↵
↵
> "Choosing the largest value looks optimal."↵
↵
Sometimes it is.↵
↵
Sometimes it gives WA on test 2.↵
↵
Before using greedy, I now ask:↵
↵
**If I make this choice now, can it make the future worse?**↵
↵
If the answer might be yes, then the greedy idea needs proof.↵
↵
---↵
↵
## 9. Do not optimize before understanding the problem↵
↵
Sometimes I immediately think about:↵
↵
- binary search↵
- DP↵
- graphs↵
- Fenwick trees↵
- advanced data structures↵
↵
while the real observation is just:↵
↵
```text↵
sort the array↵
```↵
↵
or:↵
↵
```text↵
count frequencies↵
```↵
↵
Understanding what the problem is actually asking is often more important than knowing more algorithms.↵
↵
---↵
↵
## 10. Read the statement one more time before submitting↵
↵
This sounds obvious, but many WA submissions come from missing one word:↵
↵
- exactly↵
- at most↵
- at least↵
- distinct↵
- non-decreasing↵
- positive↵
- non-negative↵
↵
Those words can completely change the solution.↵
↵
---↵
↵
## Final thought↵
↵
Competitive programming is not only about learning more algorithms.↵
↵
It is also about making fewer unnecessary mistakes.↵
↵
Every WA or TLE can teach something useful if you understand why it happened.↵
↵
If you know another small mistake that often causes WA/TLE, feel free to add it in the comments.↵
↵
Good luck and happy coding!
