Big-O Notation

Context: FIT1008_MOC, FIT1058_MOC, FIT2004_MOC · the asymptotic-analysis toolkit — the bounds, the dominance method, the combining algebra, the growth ladder FIT2004 emphasis: all three bounds stated formally with witnesses; a bound is judged valid or invalid, separately from whether it is tight; the notation is orthogonal to the case (best/worst) — fixing one does not fix the other.

Quick Revision

  • 🎯 Objective: describe order of growth as ➔ keep the dominant term, drop constants, compare by scalability.
  • 📦 Core Components: // ➔ upper/lower/tight | dominance ➔ limit test | algebra ➔ sum/product | class ladder.
  • ⚡ Key Constraint: ; a valid bound need not be tight ( is TRUE); the polynomial vs exponential line is the tractability frontier.

📝 Core

1. Big-O (Asymptotic Upper Bound)

  • Definition ➔ .
  • Set membership ➔ is a set; "" abuses ”=” for .
  • Sequence form (FIT1058) ➔ .

2. Big-Omega & Big-Theta (Lower / Tight)

ClaimThere existSuch that,
  • ➔ to disprove a claim break either side; to prove one exhibit both constants.
  • Strict versions ➔ little-o (), little-omega ().
  • Typical usage, not a law ➔ is usually how a problem’s intrinsic difficulty is stated and how an algorithm’s exact rate is; meeting ⟹ optimal. But all three apply to any function — is applied to one algorithm’s cheapest case throughout the W1 applied sheet.

3. Asymptotic Analysis (Dominance Method)

  • Mechanism ➔ keep the single dominating term, discard constants + lower-order terms.
  • Limit test ➔ : | | .
  • Boundary ➔ dangerous when stays small or constants are enormous (pair with benchmarking).

4. Properties (Combining Algebra)

  • Sum ➔ (sequential code / branches).
  • Product ➔ (nested loops); .
  • One-sided ➔ manipulate upper bounds only; transitivity chains through helpers (no lower bound — use ).

5. Complexity Classes (Growth Ladder)

  • Ladder ➔ .
  • Tractability line ➔ polynomial vs exponential = tractable vs intractable (P-vs-NP frontier).
  • Doubling ➔ (scalable); (catastrophic); class jumps need a new idea, not micro-optimisation.

6. Validity vs Tightness, and Case-Independence

  • Valid ≠ tight ➔ is an upper bound, not the upper bound ➔ is TRUE (), merely loose. “Quote the tightest bound” is style advice, not a truth condition.
  • is where looseness becomes falsity ➔ the same function is not : fails since .
  • Notation ⊥ case ➔ bound a function; best/worst select which function. “Insertion is ” is meaningless until you say which case.
  • “Any operation is …” quantifies over ALL inputs ➔ must bound the dearest case and the cheapest; a over “any operation” holds only if the two share an order. Fixing the case restores — BST insertion admits none over all insertions (cheapest , dearest ), yet worst-case insertion is cleanly .

⚙️ Core Implementation

🔹 Dominant-term reasoning + log rules

🔹 The combining algebra on real code

⚖️ Core Decision Matrix

NotationBoundConditionLimitDescribes
upperceiling — bounds the dearest case
lowerfloor — bounds the cheapest case
tightexact rate — needs both to agree
strict upper—strictly slower
strict lower—strictly faster

When It Flips: doubling — unchanged · · · · squared. exists when best=worst (Merge Sort ); quicksort has no single ( avg, worst) — the same reason "any BST insertion" has none.

⚠️ Common Mistakes

  • 💡 Marking a loose bound FALSE ➔ for a quadratic is true; the definition asks only that some exist.
  • 💡 Upgrading to for free ➔ needs the matching ; check is bounded away from , not merely finite.
  • 💡 Quantifier slip on “any” ➔ “any operation is ” is a claim about the cheapest operation — one input falsifies it.
  • 💡 Naming a bound without naming a case ➔ always pair them (“worst-case ”).

✍️ Practice

🧠 Active Recall