# STAT 350 Webbook — Future Work This document outlines four improvements to the STAT 350 webbook that would strengthen the existing material without expanding the course scope. None of these add new statistical topics — they deepen and connect what is already there. --- ## 1. Cross-Reference Network Between Chapters ### The Problem The inference chapters (9–13) average roughly 6 internal cross-references per chapter. Chapter 11 has only 1. When the text says "recall from the previous chapter" or "as we saw earlier," it almost never links to the specific lecture where the concept was introduced. Students reading nonlinearly — reviewing for an exam, returning to a topic after weeks — have no hyperlinks to follow back to the prerequisite material. The webbook format makes this trivially easy with `:ref:` and `:doc:` directives. The infrastructure exists; it's just underused. ### What to Do **Pass 1 — Backward links in Chapters 9–13.** Read each lecture in the inference block and identify every point where it relies on a concept from an earlier chapter. Add a `:ref:` link to the specific lecture (not just the chapter index). Priority targets: | Lecture | Relies on | Link target | |---------|-----------|-------------| | 9-2 (CI, σ known) | Sampling distribution of x-bar | 7-2 | | 9-5 (CI, σ unknown) | t-distribution introduction | 9-5 introduces it, but link back to CLT motivation in 7-3 | | 10-1 (HT errors/power) | CI interpretation | 9-2 | | 10-2 (z-test) | Standard normal quantiles | 6-4 | | 10-3 (t-test) | CI with t, degrees of freedom | 9-5 | | 11-1 (two-sample intro) | Single-sample CI and HT framework | 9-1, 10-1 | | 11-3 (pooled t) | Pooled variance concept | Could reference 3-3 (variance) and 10-3 (single-sample t) | | 11-4 (Welch t) | Why pooling fails under unequal variance | 11-3 (contrast) | | 12-1 (ANOVA intro) | Two-sample t as a special case | 11-3 | | 12-3 (F-test / t² relationship) | t-test mechanics | 10-3, 11-3 | | 13-2 (regression) | Variance decomposition ideas | 12-2 (SSB/SSW) | | 13-3 (diagnostics) | Normality checking methods | 6-4 (normal distribution), worksheet 10 | | 13-4 (prediction) | CI vs. CB distinction | 9-4 | **Pass 2 — Forward "you'll use this later" links in Chapters 4–8.** At key moments in the probability and sampling distribution chapters, add a short forward reference so students know why the current material matters. These should be light — a parenthetical or a one-line admonition, not a paragraph. Examples: - In 7-2 (sampling distribution of x-bar): *"This result is the foundation of confidence intervals — see :ref:`9-2-ci-sigma-known`."* - In 5-4 (variance properties): *"The rule Var(aX + b) = a²Var(X) will reappear when we standardize test statistics in :ref:`10-2-ht-for-mean-sigma-known`."* - In 4-3 (conditional probability): *"Bayes' rule, which follows from these ideas, appears in :ref:`4-4-law-of-total-probability-and-bayes-rule` and connects to how we update beliefs with data — a theme that runs through the entire inference block (Chapters 9–13)."* **Pass 3 — Sidebar cross-references in exercises.** When an exercise in a later chapter re-uses a technique from an earlier one (e.g., a Ch 12 exercise requires computing a sample variance), add a `:ref:` hint pointing to the relevant earlier lecture. This is especially helpful for students who struggle with a step that isn't the focus of the current exercise. ### How to Implement This is a grep-and-read task. Search each inference lecture for phrases like "recall," "as we showed," "from earlier," "we know that," and "previously." Each hit is a candidate for a `:ref:` link. Also search for formulas or concepts that first appeared in an earlier chapter (e.g., any appearance of `\bar{X} \sim N(\mu, \sigma^2/n)` in Ch 9+ should link back to 7-2 where it was derived). Estimated scope: ~80–120 links across 20 lectures. Each is a small edit — inserting a `:ref:` directive into existing prose. --- ## 2. Deeper Integration of Chapter 8 (Experimental Design) ### The Problem Chapter 8 has 7 lectures and over 5,000 lines of content covering experimental design, sampling design, and bias. It is well-written and thorough. But it is structurally isolated from the rest of the course: - No worksheet is dedicated to experimental design. - Exam solutions rarely test design concepts in depth. - The connection to the inference chapters is stated in the course roadmap ("ensures necessary conditions are met for Ch 7 to hold") but not reinforced in the actual text of Chapters 9–13. - Students likely perceive it as a standalone interlude between the probability block and the inference block. ### What to Do **A. Add design-awareness prompts to inference lectures.** At the beginning of key worked examples in Chapters 9–13, add a brief design context that references Chapter 8 concepts. The goal is not to turn every inference example into a design lesson, but to remind students that the validity of the inference depends on how the data were collected. Concrete examples: - **Ch 9 CI example:** Before computing the interval, add one sentence: *"This inference is valid because the 40 specimens were selected by simple random sampling from the production line (see :ref:`8-6-sampling-design`). If they had been convenience-sampled from a single shift, the confidence interval would not generalize to the full production population."* - **Ch 11 two-sample example:** *"The two groups were formed by random assignment to treatment conditions (see :ref:`8-2-experimental-design-principles`), so differences in the response can be attributed to the treatment rather than pre-existing group differences."* - **Ch 12 ANOVA example:** *"The completely randomized design (see :ref:`8-3-basic-types-of-experimental-design`) ensures that the ANOVA F-test is comparing treatment effects rather than confounded variables."* These are 1–2 sentence insertions. They cost almost nothing in lecture length but repeatedly signal that design and inference are not separate topics. **B. Create a worksheet (or extend an existing one) that connects design to inference.** A worksheet that presents a study description and asks students to: 1. Identify the design type (CRD, blocked, matched pairs, observational). 2. Identify potential confounders or biases. 3. Determine which inference procedure is appropriate given the design. 4. Explain why a different design would require a different procedure (e.g., paired t-test for matched pairs vs. independent two-sample t-test for CRD). This bridges Chapter 8 into the inference block and reinforces the "choose the right procedure" skill that the final exam tests. **C. Add a "Design Check" step to the hypothesis testing workflow.** The course teaches a four-step workflow: (a) parameter identification, (b) hypothesis statement, (c) calculation, (d) decision and conclusion. Consider adding a Step 0: *"Verify that the study design supports the chosen inference procedure."* This could be introduced once in 10-1 or 10-2 and then referenced (not repeated) in later chapters. It mirrors what practitioners actually do and connects the design chapter to every inference procedure that follows. ### Estimated Scope - 8–12 one-sentence design-context insertions across Chapters 9–13 - 1 new worksheet (or 1 extended worksheet section), roughly 200–400 lines - 1 small addition to the hypothesis testing workflow in 10-1 or 10-2 --- ## 3. Strengthen the Conceptual Narrative in Chapters 11–12 ### The Problem Chapters 1–10 do an excellent job of motivating each concept before introducing mechanics. But as procedural variants multiply in Chapters 11–12, the writing becomes more formulaic: here's the setting, here's the test statistic, here are the conditions, here's the R code. The *why* of choosing between procedures gets less narrative space than the *how* of executing each one. Specific places where the narrative thins: - **11-3 vs. 11-4 (pooled vs. Welch):** The mechanical difference is clear. What is underdeveloped is the *decision*: when would you choose pooled over Welch, and what are the real consequences of choosing wrong? The Welch test is almost always the safer default — this practical guidance could be stated more directly. - **11-5 (paired t-test):** The procedure is well-explained. What is less developed is the *recognition* problem: given a study description, how do you determine whether the data are paired or independent? This is the hardest part for students and the most common exam error. - **12-1 to 12-3 (ANOVA):** The decomposition of variability (SSB, SSW, SST) is mechanically thorough. What could be stronger is the intuitive framing: ANOVA asks whether the between-group variability is large relative to the within-group variability. The signal-to-noise ratio interpretation of the F-statistic could be developed more before the formulas arrive. - **The "these are all the same thing" narrative is missing.** The single-sample t-test, the two-sample t-test, ANOVA, and regression are all special cases of the general linear model. The course doesn't need to teach the GLM, but a recurring motif — "notice this has the same structure as what we did before, just with more groups / a continuous predictor" — would help students see the unity rather than memorizing four separate procedures. ### What to Do **A. Add "Decision Guide" admonitions to Chapters 11–12.** At the beginning of each procedure lecture (11-3, 11-4, 11-5, 12-1), add a short admonition that answers: *"When do I use this instead of the alternatives?"* Frame it as a decision, not just a definition. Example for 11-4: > **When to use the Welch t-test** > > Use the Welch (unpooled) procedure when you are comparing the means of two independent groups and you either (a) cannot verify equal population variances or (b) have evidence that variances differ. In practice, the Welch test is the safer default — it is nearly as powerful as the pooled test when variances are equal and much more reliable when they are not. **B. Add "Recognition" exercises to Chapter 11.** Write 3–5 exercises that present a study description and ask: *"Is this a paired design or an independent-samples design? Explain your reasoning."* These are conceptual — no computation needed — but they target the most common student error on exams. **C. Add "Connecting Thread" callouts.** At 3–4 key moments, insert a short callout that connects the current procedure back to the previous one: - End of 11-3 (pooled): *"Notice that when k = 2, the ANOVA F-test in Chapter 12 will reduce to exactly this pooled t-test squared. The two-sample comparison is a special case of comparing multiple groups."* - End of 12-3 (F-test): *"The F = t² identity confirms that ANOVA with two groups is the same test as the pooled two-sample t-test. Chapters 11 and 12 are not separate procedures — they are the same idea at different scales."* - Start of 13-1 (regression intro): *"In Chapters 11–12, the predictor was categorical (which group?). Now the predictor is continuous (what value of x?). The inferential logic — decompose variability, form a ratio, compare to a reference distribution — is identical."* ### Estimated Scope - 4 "Decision Guide" admonitions (~50–100 words each) - 3–5 recognition exercises (~30–50 lines each) - 3–4 connecting-thread callouts (~2–3 sentences each) --- ## 4. More Real-World Data in Chapters 11–13 ### The Problem The descriptive chapters (2–3) use real datasets effectively — `mtcars`, `iris`, and other built-in R datasets provide genuine context. But the inference examples in Chapters 11–13 increasingly rely on constructed textbook data: "a random sample of n = 25 widgets has mean 47.3 and standard deviation 5.1." These examples are computationally clean, which is pedagogically useful for introducing a procedure. But they lack the context and messiness that make statistical reasoning meaningful. The course's stated philosophy is that statistics is about "making well-informed decisions based on evidence" and "understanding uncertainty." Textbook data with round numbers and no backstory doesn't exercise that muscle. ### What to Do **A. Replace 1–2 constructed examples per chapter with real-data examples.** The goal is not to replace all constructed examples — clean data is essential for first exposure to a procedure. But each chapter in the 11–13 block should have at least one worked example where: - The data comes from a real study (published paper, government dataset, or campus research). - The context is described enough that students understand what question is being answered and why it matters. - The numbers are not perfectly round, so students practice realistic computation. - The interpretation connects back to the original research question, not just "reject H0." Sources for real data: - **R built-in datasets:** `sleep` (paired t-test, Ch 11), `PlantGrowth` (one-way ANOVA, Ch 12), `cars` or `faithful` (regression, Ch 13). These are already available without loading packages. - **Published studies:** Datasets from JASA, The American Statistician, or Journal of Statistics Education that are freely available and have clear context. - **Purdue-relevant contexts:** Engineering quality control, agricultural field trials, pharmaceutical bioassay — contexts that match the student population. **B. Add context paragraphs to existing constructed examples.** Where replacing the data is not practical (e.g., the numbers are carefully chosen to illustrate a specific point), add a motivating paragraph that frames the problem in a realistic setting. Instead of: > *"A sample of 30 observations has mean 112.4 and standard deviation 8.7. Test whether the population mean differs from 110."* Write: > *"A manufacturing engineer suspects that the tensile strength of a new alloy formulation differs from the specification target of 110 MPa. She tests 30 specimens from the production run and records a sample mean of 112.4 MPa with a standard deviation of 8.7 MPa. Is there sufficient evidence that the true mean tensile strength differs from the target?"* The computation is identical. The framing is not. **C. Include at least one example per inference chapter where the conclusion is "fail to reject."** Real data doesn't always give clean rejections. Students need to see worked examples where the evidence is insufficient, the confidence interval is wide, or the effect is too small to detect — and to see how a statistician interprets and communicates that result. This also reinforces the practical significance discussion and the distinction between "no evidence of an effect" and "evidence of no effect." ### Estimated Scope - 3–4 example replacements or additions (one per chapter in 11–13, possibly one in 9 or 10) - 5–8 context paragraph rewrites on existing examples - Each new example requires R verification of all numerical claims (consistent with current standards) --- ## 5. Align Examples and Context with the Student Population ### Who Takes This Course Spring 2026 enrollment data reveals two distinct populations depending on delivery mode — and neither looks like the generic "intro stats" audience most textbooks assume. **Online section (n = 235):** | Segment | Share | Implication | |---------|-------|-------------| | Computer Science | ~48% of majors | The dominant group by a wide margin | | AI / Data Analytics / Cybersecurity | ~10% | Closely related to CS; data-native | | Engineering (Mech, Aero, Biomed, Civil, Construction, Electrical) | ~18% | Familiar with mathematical modeling; motivated by physical systems | | Mathematics / Statistics / Actuarial Science | ~12% | Comfortable with abstraction; want rigor | | Business / Economics / Management | ~5% | Decision-oriented; want practical takeaways | | Other Science (Physics, Biology, Planetary, Health) | ~7% | Varied; generally lab-science oriented | Nearly **two-thirds** of the online section are CS, AI, or data-adjacent majors. Another fifth are engineers. **Flipped section (n = 60):** | Segment | Share | Implication | |---------|-------|-------------| | Computer Science (incl. CS Honors, AI) | ~33% | Still the largest single group, but not dominant | | Integrated Business & Engineering | ~22% | The second-largest block; decision-oriented, quantitative business focus | | Actuarial Science | ~17% | Risk-oriented; comfortable with probability; motivated by professional exams | | Biomedical Engineering | ~7% | Lab-science oriented; familiar with experimental protocols | | Mechanical Engineering | ~5% | Physical systems; modeling and measurement | | Mathematics / Applied Math | ~10% | Comfortable with abstraction; may want more rigor | | Other (Physics, Applied Stats, Bus Analytics, Exploratory) | ~6% | Varied | The flipped section is strikingly more diverse. CS drops from 58% to 33%. Business-adjacent students (IBE + Actuarial + Bus Analytics) jump from ~5% to **~40%**. Engineering representation roughly doubles in proportion. **The combined picture:** Across both delivery modes (~295 students), the course serves three large blocks — CS/AI (~45%), business/actuarial (~15%), and engineering (~15%) — with math/stats (~10%) and other fields (~15%) filling the remainder. The "social science / humanities student taking a required stats course" archetype that many intro stats textbooks are written for is essentially absent. But the two sections differ enough that examples pitched exclusively to CS students will miss nearly half the flipped classroom. ### The Problem The current examples and application contexts are broadly generic — manufacturing quality control, medical trials, agricultural yields, generic "widget" measurements. These are fine as neutral illustrations, but they don't leverage the fact that the overwhelming majority of students have strong computational intuition and are heading into fields where statistics intersects directly with their daily work. A CS student who sees a hypothesis test applied to API response times, model accuracy metrics, or A/B test conversion rates will immediately understand *why* this material matters to them. An engineering student who sees ANOVA applied to sensor calibration across manufacturing lines connects the procedure to something they've seen in a lab. The current examples rarely make these connections. ### What to Do **A. Build a domain-tagged example bank.** For each major inference procedure (CI, HT, two-sample, paired, ANOVA, regression), develop 2–3 alternative worked examples drawn from domains that match the student population. The example bank should cover all three major blocks, not just CS: | Domain | Combined share | Example contexts | |--------|---------------|------------------| | **CS / Software** | ~45% | A/B testing (conversion rates, click-through), algorithm runtime comparison, bug detection rates, API latency before/after deployment, model accuracy across architectures | | **AI / ML** | ~8% | Comparing classifier accuracy across training set sizes, hyperparameter tuning (is the difference in loss significant?), bias auditing (does model error differ across demographic groups?) | | **Business / Actuarial** | ~15% | Insurance claim amounts (CI for mean loss), portfolio return comparison (two-sample), quality control in supply chain (ANOVA across suppliers), pricing model accuracy (regression), actuarial loss reserving | | **Engineering** | ~15% | Tensile strength across alloys (already used), fuel efficiency across engine configs, sensor drift over time, thermal resistance of materials, biomedical device calibration | | **Math / Stats** | ~10% | Simulation coverage probabilities, Monte Carlo estimation accuracy, convergence rate comparisons | The actuarial/business column is particularly important given the flipped section composition — these students are heading into fields where risk quantification, loss modeling, and decision analysis under uncertainty are daily work. Statistics is not a prerequisite they have to get through; it *is* the core skill. Examples from insurance, finance, and operations research will resonate strongly. These don't need to replace every existing example. The goal is to have at least **one domain-relevant example per chapter** in the inference block (Ch 9–13) that students from each major block can immediately map to their own field. A good target: each chapter has one CS-flavored example, one business/actuarial example, and one engineering example, with the existing neutral examples retained as the primary teaching vehicle. **B. Add "Why This Matters for You" callouts at chapter transitions.** At the opening of each inference chapter (9, 10, 11, 12, 13), add a short motivating callout that connects the chapter's topic to the students' likely careers. These should be concrete and specific, not vague. Examples: - **Ch 9 (Confidence Intervals):** *"If you deploy a machine learning model and measure its accuracy on a test set, that accuracy is a point estimate. A confidence interval tells you how much that number could change with a different test set — critical information before you ship the model to production."* - **Ch 10 (Hypothesis Testing):** *"A/B testing — the standard method for evaluating product changes at companies like Google, Netflix, and Amazon — is a direct application of hypothesis testing. The null hypothesis is that the new version performs the same as the old one. The p-value tells you whether the observed difference is larger than you'd expect from random variation alone."* - **Ch 11 (Two-Sample):** *"Does the new caching layer actually reduce API response time, or is the improvement within normal fluctuation? Two-sample inference gives you the framework to answer this with data instead of intuition."* - **Ch 12 (ANOVA):** *"When you're comparing more than two algorithms, architectures, or configurations, running pairwise t-tests inflates your false positive rate. ANOVA handles the multiple-group comparison correctly, and Tukey's HSD tells you which specific pairs differ."* - **Ch 13 (Regression):** *"Regression is the foundation of predictive modeling. Every linear model, generalized linear model, and neural network you'll encounter in a machine learning course is an extension of what you learn here."* These are 2–3 sentences each. They don't change the content — they change the framing. **C. Use computational language where it's natural.** The CS-heavy population is comfortable with terms like "function," "parameter," "iteration," "convergence," and "optimization." The course already uses some of this language (e.g., "estimator" maps naturally to "function that takes data and returns a value"). Lean into it more explicitly where it helps: - Frame the sampling distribution as "what happens if you run the same experiment many times" — CS students think in loops and simulations. - Frame the CLT as "the averaging operation is remarkably robust to the input distribution" — this resonates with students who think about algorithm robustness. - Frame hypothesis testing as "a decision procedure with a controlled false positive rate" — this maps directly to binary classification metrics (precision, recall, FPR) that AI students already know or will learn soon. This is not about dumbing down the statistics — it's about using the conceptual vocabulary that 60%+ of the class already has. **D. Consider one CS-specific extended example that threads through multiple chapters.** A single dataset or scenario that appears in Chapter 9 (estimate the mean response time), Chapter 10 (test whether it exceeds an SLA threshold), Chapter 11 (compare response times before and after a code change), and Chapter 13 (model response time as a function of request payload size) would demonstrate that these are not four separate techniques but four views of the same inferential framework — applied to a problem every CS student will encounter professionally. This is a larger undertaking but would be a signature feature of the course. ### What Not to Do - **Don't make the course "stats for CS."** In the flipped section, CS is only a third of students — business/actuarial and engineering together make up nearly half. Even in the online section, 40% are non-CS. The goal is to diversify the example portfolio so every major block sees itself reflected, not to swing from generic examples to CS-only examples. - **Don't use CS jargon that excludes non-CS students.** A/B testing is accessible to everyone. "Stochastic gradient descent convergence" is not. - **Don't compromise rigor for relevance.** The examples should be statistically genuine — real effect sizes, realistic sample sizes, plausible variance structures. A fabricated "A/B test" with n=10 per group and a 20% conversion rate difference teaches bad intuition about what real A/B tests look like. ### Estimated Scope - 5–8 new worked examples across Chapters 9–13 (each requires R verification) - 5 chapter-opening callouts (2–3 sentences each) - Scattered language adjustments where computational framing is natural - Optional: 1 threading example across 4 chapters (larger effort, high payoff) --- ## Priority and Sequencing | Priority | Item | Effort | Impact | |----------|------|--------|--------| | 1 | Cross-reference network (Item 1) | Medium — many small edits | High — immediately improves navigation and reinforces connections for every student | | 2 | Narrative strengthening in Ch 11–12 (Item 3) | Low-medium — targeted insertions | High — addresses the weakest part of the course's best feature (the "why before how" philosophy) | | 3 | Student-population alignment (Item 5) | Medium — new examples + callouts | High — directly serves the 60% CS/AI majority without excluding others | | 4 | Real-world data in Ch 11–13 (Item 4) | Medium — requires sourcing data and verifying computations | Medium-high — aligns examples with the course's stated values; overlaps naturally with Item 5 | | 5 | Chapter 8 integration (Item 2) | Medium — new worksheet + scattered insertions | Medium — strengthens an underconnected chapter, but students may not notice unless exam weight also shifts | Items 1 and 2 can be done independently and in parallel. Items 4 and 5 (real-world data and student-population alignment) overlap significantly and should be tackled together — when sourcing new examples, choose domains that match the enrollment. Item 3 could be started any time but has the largest single deliverable (new worksheet). The threading example proposed in Item 5D is the highest-effort single piece but would be the most distinctive improvement to the course.