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.