Mathematics for Computer Science (2024)

Course materials and content

  • Links are shared to lecture videos, notes, and the 2018 textbook; problems are praised as concrete and applied (e.g., specs about file systems, messaging, etc.).
  • Some find the “Large Deviations” lecture a missed opportunity: it uses Chernoff bounds but doesn’t clearly define “large deviation” despite the title.
  • The state machines lecture is highlighted as particularly good (invariants, 15‑puzzle).
  • One person asks if units can be taken independently; no clear consensus in the thread.
  • Multiple people ask where official solutions are; none are visible. Suggestions: use an LLM for guidance or ask on Math StackExchange.

Self‑study, motivation, and structure

  • Many express amazement that high‑quality MIT courses are free, yet struggle to complete long playlists without deadlines or grades.
  • Strategies suggested:
    • Treat problem sets as the main learning vehicle, not lectures.
    • Set fixed daily/weekly time slots; expect to need multiple days per lecture at first.
    • Start with simpler resources (e.g., OpenStax, Khan Academy) if background is weak.
    • Use public commitment, self‑imposed deadlines, or even financial stakes for accountability.
    • Be “modest” about level—start with courses where you already know ~50% of the material.
  • Several argue that mentorship and a cohort are crucial for progressing beyond basics in math; others say motivated autodidacts can go far with books + projects.

LLMs as learning tools

  • Proponents: LLMs are excellent for:
    • Explaining concepts at different levels.
    • Back‑and‑forth debugging of understanding.
    • Translating and unpacking notation.
    • Summarizing lectures and generating quizzes.
  • Skeptics: models hallucinate, lack real theory of mind, and can’t reliably guide students to the “right questions.” Without domain knowledge, it’s hard to detect subtle errors.
  • A middle view: treat the LLM as a smart peer, not an oracle; cross‑check and use it to refine your own explanations.

Math vs. software engineering; formal methods

  • One camp says “average software engineers need almost none of this”; they managed fine without using set theory, relational algebra, etc. explicitly.
  • Others argue:
    • Even if you don’t see the math, you’re implicitly using it (types, sets, relations, logic).
    • Understanding math improves clarity, correctness, maintainability, and the ability to design new systems (not just use existing ones).
  • A long sub‑discussion contrasts:
    • Full formal verification vs. “design by contract,” testing, and defensive programming.
    • Runtime assertion checking vs. static proofs.
    • “Lightweight” formal methods and “formal‑methods thinking” as practical middle ground.
  • There is disagreement over using the word “proof” for runtime‑checked contracts; some insist that only static, mathematical proofs qualify.

CS, math, and career context

  • Some see CS as fundamentally a branch of mathematics, so “Mathematics for Computer Science” feels redundant; others note modern CS curricula are often more job‑oriented, closer to software engineering.
  • One commenter plans to formalize the course in Lean; supporters say this increases rigor, critics say it risks prioritizing formalism over conceptual insight.
  • There’s skepticism that MOOCs/OCW alone reliably enable career changes; they appear to serve mostly already‑educated, self‑directed learners.