Introduction

Weaknesses

• 0 problems last year → severe inactivity.
• Rating below 800 → likely:
  • Slow implementation
  • Panic during contests
  • Weak debugging discipline
  • Weak pattern recognition
  • Poor greedy reasoning

Likely Technical Gaps

At 792 rating, typical weaknesses are:

• Implementation errors (indexing, off-by-one)
• Weak string manipulation
• Poor condition handling
• Not recognizing simple greedy patterns
• Fear of math problems
• No structured upsolving habit

You are likely failing mostly on:

• 800–1000 problems
• Div2 A occasionally
• Div2 B rarely

Psychological Problems

Based on inactivity pattern:

• You probably binge-practiced once.
• Rating dropped.
• Motivation collapsed.
• Long break.
• Guilt cycle.

This is extremely common below 1000.

We fix this with structure.

30-DAY COMEBACK PLAN (792 → 1000)

Goal: Reach stable 1000 rating.

We do NOT rush.

Daily Routine (Minimum 2 Hours)

Weekdays (2 hours)

1. Block 1 (60 min):
   • Solve 3 problems
   • Rating range: 800–1000
2. Block 2 (30 min):
   • Review wrong submissions
   • Rewrite clean solution
3. Block 3 (30 min):
   • Re-solve 1 previously solved problem WITHOUT looking
   • Total: 4 problems/day

Weekend (3–4 hours)

• 1 Virtual Contest (Div3 preferred)
• Upsolve all unsolved A/B after contest
• Solve 2 extra 900–1100 problems

Topic Priority (First 30 Days)

You must master these in order:

1. Implementation
2. Strings
3. Basic greedy
4. Math (gcd, parity, divisibility)
5. Sorting
6. Prefix sums
7. Basic two pointers

Ignore DP. Ignore graphs. Ignore segment trees.

You are building foundations.

Weekly Target

• 20–25 problems/week
• 2 virtual contests/week
• 1 full review day

30 days → ~90 problems

This alone can push you to 1000.

Virtual Contest Strategy

Only:

• Div3
• Old Div2 rounds (rated <1500 difficulty)

During contest:

• 10 minutes max on A
• 20 minutes max on B
• Skip if stuck
• NEVER spend 40 minutes on A

Upsolving Protocol (CRITICAL)

After contest:

For each unsolved problem:

1. Think 20 minutes.
2. Read editorial.
3. Re-implement without copying.
4. Add to mistake log.

If you don’t upsolve, your rating will not grow.

Mistake Log Structure

Create a Google Doc.

For each wrong problem write:

Problem Name:
Rating:
Type:
Mistake Type:

• Logic?
• Edge case?
• Misread?
• Implementation?
• Math gap?

What pattern did I miss?

Review this every Sunday.

90-DAY GROWTH PLAN (1000 → 1300)

Now we build real strength.

Topic Roadmap (Ordered)

1. Greedy patterns
2. Prefix sums advanced
3. Binary search
4. Two pointers deeper
5. Constructive algorithms
6. Basic combinatorics
7. Intro DP (very basic 1D)
8. Simple graphs (BFS/DFS)

Div2 A/B Mastery Strategy

Goal: Solve A in 5–7 minutes.

Training method:

• Take 30 random Div2 A (800–1000)
• Solve all under time limit of 7 minutes each.

Then:

• Take 40 problems rated 1000–1200.
• Solve 2 daily.

Speed Training (3x/week)

Set timer 45 minutes:

• Solve 4 problems rated 900–1100.

Speed > difficulty.

Pattern Recognition Training

After every problem ask:

• Is this greedy?
• Is this counting?
• Is this prefix sum?
• Is this simulation?
• Is this constructive?

Classify every solved problem.

After 200 problems, patterns become automatic.

Weekly Structure (90-Day Phase)

Monday–Friday:

• 3 problems/day (1000–1200)

Saturday:

• 1 virtual contest

Sunday:

• Upsolve + review mistake log
• Re-solve 2 old wrong problems

Target:

• 15–18 problems/week
• 1–2 contests/week

In 3 months → ~200 more problems

You will reach 1200–1300 if consistent.

6–12 MONTH PLAN (1300 → 1600+)

Now you transition from beginner to structured thinker.

When to Start Advanced Topics

Start learning seriously after 1200:

• Binary search on answer
• Graph BFS/DFS variations
• Basic DP patterns
• Greedy proof logic
• Bit manipulation
• Frequency maps

After 1400:

• Segment tree
• Basic number theory
• 2D prefix sums
• Shortest paths

Contest Strategy Evolution

At 1300:

Goal per contest:

• Solve A fast
• Solve B confidently
• Attempt C
• Partial D thinking

Never rush D if B is shaky.

Studying Strong Coders

Pick random 1500–1800 rated user.

After contest:

• Open their submission.
• Compare logic.
• Check:
  • Variable naming
  • Code simplicity
  • Pattern recognition

Do this twice per week.

This accelerates growth massively.

EXACT PROBLEM-SOLVING FRAMEWORK

How Long to Think?

• For 800–1000: 15 minutes max
• For 1000–1200: 25 minutes max
• If no direction → read editorial.
• Struggling 1 hour teaches nothing.

When to Switch Problems

If:

• You feel stuck in implementation detail
• You don’t know what the first step is
• You tried 2 approaches

Switch immediately.

Debugging Faster

Checklist:

1. Edge case n=1?
2. All equal values?
3. Sorted input?
4. Negative numbers?
5. Overflow?
6. Reset variables per test case?

90% of bugs are here.

Post-Contest Analysis Template

After contest write:

1. Which problem wasted most time?
2. Why?
3. Did I panic?
4. Was I slow reading?
5. What pattern did I miss?
6. What will I change next contest?

If you don’t do this, rating stagnates.

CONTEST STRATEGY FOR NEWBIES

Time Allocation (Div3)

0–10 min → A
10–30 → B
30–60 → C attempt
60–90 → fix bugs
Last 30 → re-check all submissions

When to Skip

Skip if:

• You don’t understand problem after 5 minutes.
• You don’t know what data structure to use.

Skipping is strength, not weakness.

Risk Management

Never submit without:

• Testing 3 custom cases
• Checking smallest input
• Checking largest input

Avoid WA chains.

Avoid Tilt After WA

Rule:

After 2 WAs:

• Stop.
• Reread entire problem.
• Re-evaluate logic from scratch.

Do NOT randomly modify code.

Target Metrics:

• Month 1:
  • 90 problems
  • 8 contests
• Month 3:
  • 250 total problems
  • Stable 1200 rating
• Month 6:
  • 400–500 total problems
  • 1400+

PSYCHOLOGICAL DISCIPLINE PLAN

This is the real battle.

Anti-Procrastination Rule

Minimum rule:

• Solve at least 1 problem daily.
• Even on worst day.

Never break the chain twice.

Streak Rebuild Strategy

Start 7-day streak.
Then 14.
Then 30.

You once did 15.
Now aim 30.

Handling Rating Drops

Rule: Rating drop ≠ skill drop.

After bad contest:

• Solve 3 easy problems immediately.
• Regain confidence.

Never quit after a red contest.

Long-Term Motivation

• Shift goal: Not "increase rating".
• Goal: “I solve 20 problems per week.”
• Rating is a byproduct.

Final Reality Check

You are 4 years registered. Rating 792.

If you continue randomly: In 4 more years → same result.

If you follow this strictly:

• 1 month → 1000
• 3 months → 1200+
• 6–9 months → 1500
• 1 year → 1600 possible

But only if you are consistent.

Your problem is not intelligence.

Your problem is structure.

Now build it.

Start today. Solve 3 problems. No excuses.

Question

Explain Halting Problem and Collatz Conjecture

I’ll explain both concepts carefully. They are famous problems in Computer Science and Number Theory, and they illustrate two different kinds of limits:

• limits of computation
• limits of mathematical proof

Halting Problem

The Halting Problem was proven unsolvable by Alan Turing in 1936.

The halting problem asks:

Can we write a program that determines whether any program will eventually stop (halt) or run forever for a given input?

In simpler words:

Given:

• a program P
• an input I

Question:

Will P(I) eventually stop, or will it run forever?

Example Programs

Program that halts

int main(){
    int x = 5;
    return 0;
}

This clearly halts immediately.

Program that does not halt

while(true){
}

This program runs forever.

The Real Question

Can we create a program like this?

HALT(program P, input I)

if P(I) stops
    return "HALTS"
else
    return "RUNS FOREVER"

The halting problem asks:

Can such a universal program exist?

Turing’s Proof Idea (Simplified)

Turing proved no such algorithm can exist.

He used a self-contradiction argument.

Assume a program exists:

HALT(P, I)

that perfectly predicts halting.

Now construct another program:

WEIRD(P):

if HALT(P, P) == "HALTS"
    loop forever
else
    stop

Now ask:

What happens if we run WEIRD(WEIRD)?

Case 1

HALT says WEIRD halts

Then WEIRD will loop forever

Contradiction.

Case 2

HALT says WEIRD runs forever

Then WEIRD will stop

Contradiction again.

Therefore:

HALT cannot exist.

Meaning:

There is no general algorithm that can determine for every program whether it halts.

Why It Matters

The halting problem proves a fundamental limitation of computers.

Even the most powerful computers cannot solve every computational question.

It is a cornerstone concept in Computability Theory.

Collatz Conjecture

The Collatz Conjecture was proposed by Lothar Collatz in 1937.

It is a famous unsolved problem in Number Theory.

Rule

Start with any positive integer n.

Repeat:

If n is even

$$n = n/2$$

If n is odd

$$n = 3n + 1$$

Repeat the process.

Conjecture

The conjecture says:

No matter what positive integer you start with, the sequence will eventually reach 1.

But no one has proven this for all numbers.

Example 1: n = 6

Start: 6

6 is even 6 / 2 = 3

3 is odd 3 × 3 + 1 = 10

10 is even 10 / 2 = 5

5 is odd 3 × 5 + 1 = 16

16 → 8 → 4 → 2 → 1

Sequence:

6 → 3 → 10 → 5 → 16 → 8 → 4 → 2 → 1

Example 2: n = 11

11 → 34 → 17 → 52 → 26 → 13 → 40 → 20 → 10 → 5 → 16 → 8 → 4 → 2 → 1

Even though numbers sometimes increase, eventually they reach 1.

Why It Is Interesting

The rule is extremely simple, yet no one has proved it for all integers.

Computers have tested it for extremely large numbers, but a general mathematical proof is still unknown.

Collatz Algorithm Example

#include <iostream>
using namespace std;

int main(){
    long long n;
    cin >> n;

    while(n != 1){
        cout << n << " ";

        if(n % 2 == 0)
            n = n / 2;
        else
            n = 3 * n + 1;
    }

    cout << 1;
}

Key Difference Between the Two

Feature	Halting Problem	Collatz Conjecture
Type	Proven unsolvable problem	Unproven mathematical conjecture
Field	Computability theory	Number theory
Status	Proven impossible to solve generally	Still open
Idea	Programs may run forever	Number sequence always reaches 1

Simple intuition

• Halting Problem: proves computers cannot solve everything.
• Collatz Conjecture: shows simple math problems can be extremely hard to prove.