R · Quarto setup

Getting R, RStudio/Posit Cloud, and Quarto running for the simulation labs

This page gets you to a working setup for the simulation strand of the course: a copy of R, a place to write and run it, and Quarto to turn a plain-text file into a small report. Once it is running, you will not think about it again — the labs assume only that you can open a .qmd, run a code chunk, and read the result.

Keep one thing in view the whole time. In this course, simulation supports probability reasoning; it is not the center. A lab never replaces a derivation — it lets you watch a result you reasoned about by hand emerge from generated data, and so it is a check on your thinking and a way to build intuition. The software exists to serve the probability, not the other way around. If a setup detail ever feels like more trouble than the idea it is meant to illustrate, you are spending effort in the wrong place; come back to the idea.

What to install

You need three free pieces. None of them costs anything, and no paid platform is required for this course — the syllabus does not use Cengage, WebAssign, or MyLab, so you will not be asked to buy or register for a publisher’s homework system. Everything below is open and free.

R — the language that actually does the computing. This is the engine. Download it from the Comprehensive R Archive Network (CRAN) at https://cran.r-project.org, choosing the build for your operating system. You install R once and rarely touch it directly afterward.
A place to write and run R. Pick one of two paths:
- RStudio Desktop (now published by Posit) — a free editor that runs on your own machine. Get it from https://posit.co/download/rstudio-desktop/. Install R first, then RStudio; RStudio finds the R you already installed.
- Posit Cloud — the same editor in a web browser, nothing installed locally. Sign up at https://posit.cloud. The free tier is enough for this course, and it is the simplest route if installing software on your computer is awkward (a shared machine, a locked-down laptop, a tablet). Posit Cloud comes with R and Quarto already in place, so if you go this way you can skip most of the “discoverable” snag below.
Either path is fine. Use whichever you will actually open. Many students start on Posit Cloud and never leave; that is a perfectly good outcome.
Quarto — the tool that takes a .qmd document (prose plus code) and renders it into a finished report, running the code as it goes. Recent versions of RStudio ship Quarto inside them, so you may already have it. If you need it on its own, install it from https://quarto.org/docs/get-started/. On Posit Cloud, Quarto is already there.

That is the whole stack: R does the math, RStudio or Posit Cloud is where you sit, and Quarto turns your work into a document. You do not need anything else — no LaTeX install, no paid account, no extra package beyond base R, since every lab in this course is written in base R on purpose.

Make R discoverable by Quarto

This is the snag that trips people up, so it gets its own section. Symptom: you have R, you have Quarto, but when you try to render a .qmd with an R chunk in it, Quarto reports that it cannot find R, or it renders the prose but skips the code. The cause is almost always that Quarto does not know where R is installed — the two were installed separately and have not been introduced.

The fix, in order of how often it works:

Render from inside RStudio. When you open a .qmd in RStudio and click Render, RStudio hands Quarto the location of the R it is already using. This alone resolves most cases, and it is the workflow the labs assume. If you only ever render from inside RStudio, you may never see this problem.
Check the install order. If you installed RStudio before R, RStudio may be pointing at nothing. Reinstall or repoint: in RStudio, look under Tools → Global Options → General for the R version it has selected.
Confirm Quarto can see R from a terminal. Open a terminal (the Terminal tab in RStudio works) and run:
```
quarto check
```
This prints what Quarto found — including whether it located R. If R shows up as missing here but you know it is installed, the two are installed in places that do not know about each other; the RStudio route above sidesteps it.
On Posit Cloud, this section usually does not apply — R and Quarto arrive pre-connected, which is exactly why the cloud route is the low-friction option.

You do not need to memorize any of this. You need it once, and then it stays fixed.

Your first reproducible report

Here is a complete, minimal .qmd you can copy into a new file to confirm the whole chain works. It writes a one-line front matter, a sentence of prose, and a single simulation chunk with a fixed seed. The chunk estimates a probability by simulation — the kind of thing every lab does — using the recurring commuter case from the notes: the shuttle is on time with probability \(0.81\), so being late has probability \(0.19\). The simulation just flips a weighted coin many times and counts.

Copy the block below (everything between the dashed fences) into a file named, say, first-report.qmd, then click Render in RStudio.

---
title: "My first report"
format: html
---

This report estimates the probability the shuttle is **late** by simulation. The theory says
$P(\text{late}) = 0.19$; the simulation should land near that. Data are synthetic; seed set.


::: {.cell}

```{.r .cell-code}
set.seed(35003)
n <- 100000
# 1 = late with probability 0.19, 0 = on time otherwise
late <- rbinom(n, size = 1, prob = 0.19)
mean(late)   # proportion late — should be close to 0.19
```
:::

A few things to notice, because they recur in every lab:

The #| label: line names the chunk. A label makes errors easier to find and keeps the document organized. Every chunk in this course gets one.
The #| eval: false line means show this code but do not run it — that is the convention for the notes and lab pages on this site, so the page displays the code as teaching rather than executing it. In your own copy you will want the code to run, so when you are working a lab yourself you remove #| eval: false (or change it to true) and click Render.
set.seed(35003) fixes the random-number stream so the result is the same every time you run it. More on why this matters next.

If the rendered report shows a number near \(0.19\), your R, RStudio/Posit Cloud, and Quarto are all talking to each other, and you are ready for the labs.

Reproducibility habits we keep all term

Three small habits make your work trustworthy — to a grader, to a classmate, and to you a week later when you reopen a file and cannot remember what you did. We keep all three from day one.

Always set.seed(35003) before any simulation. A simulation uses random numbers, so without a seed it gives a slightly different answer each run, and no one can reproduce exactly what you saw. Setting the seed pins the random stream: same seed, same draws, same number. Every simulation chunk in this course starts with set.seed(35003) so results are repeatable. The point of a seed is not that \(0.19\) becomes exact — it is that your run and my run agree.
End a working session with sessionInfo(). This one call prints your R version and the packages in use. Pasting that output at the bottom of a report records the exact environment that produced it, so a result can be traced and re-run later. It is a one-line insurance policy:
```
sessionInfo()
```
One file per task. Keep each lab — and each separate question — in its own .qmd, named for what it does (lab-02-monte-carlo.qmd, not untitled (3).qmd). One file per task keeps a stray edit in one place from breaking everything else, and it makes your folder readable at a glance. Small, named, single-purpose files are easier to debug and easier to trust.

These habits cost a few seconds each and save hours. They are the difference between a number you got and a number you can stand behind.

AI Use Note (when you use an assistant)

If you use an AI assistant — for a syntax reminder, an error message you cannot parse, a nudge on structure — you record it briefly, with three parts. The same three-part note appears in every lab, so it is worth getting comfortable with here. The first two parts say what happened; the third is the one that matters.

Field	What it captures
Tool	Which assistant you used (name and, if you know it, version).
Purpose	What you asked it for, in a sentence — e.g. “explain why `rbinom` returned all zeros.”
Verification	How you checked the output yourself — and this is the load-bearing field.

Verification is the part that does the work. An assistant can produce code that runs and is still wrong for your problem, or prose that sounds right and is not. The note is not complete because you wrote down a tool name; it is complete because you can say how you confirmed the answer was correct — you ran the code and the simulated probability matched the theory in the notes, you re-derived the formula by hand, you checked a small case where you already knew the answer. If you cannot describe how you verified something, you have not finished using the assistant — you have only started. Use AI as a tutor you double-check, never as an authority you copy. The understanding has to end up in your head, because the reasoning, not the code, is what this course is about.

Public vs. graded

These notes, the examples, and the practice here are public and ungraded — study material only. No graded prompts, answer keys, rubrics, point values, or due dates appear on this site. Graded checkpoints, quizzes, homework, labs, the midterm, the project, and the final live in Blackboard (the LMS), which is authoritative for due dates, submissions, and grades. If this page and Blackboard ever disagree, follow Blackboard.