Lesson 15: Libraries, APIs & Random Values

Warm-Up

Your game needs to roll a six-sided die. Which is correct?

(i)  RANDOM(1, 6)
(ii) RANDOM(0, 6)
(iii) RANDOM(1, 5)

RANDOM(a, b) produces an integer from a to b including both ends. A die shows 1 through 6 → (i). Option (ii) sometimes rolls a 0 (seven outcomes); option (iii) never rolls a 6 (five outcomes).

One function, three-way trap, and it carries 2–3 points on every exam form. The whole skill is: write out the possible values, count them, check the ends. Now let's make that automatic — and meet the libraries that RANDOM itself comes from.

Core Concept

Libraries: don't rebuild the wheel

A software library is a collection of procedures ready to use in your programs. DISPLAY, LENGTH, RANDOM — you didn't write them; they came with the environment. Real-world development leans on libraries for graphics, networking, math, dates — nearly everything.

Why the CED says libraries matter: - They simplify complex tasks — decades of solved problems, already coded. - They save development time — call, don't compose. - They've been widely tested — a library's procedures have survived millions of uses, so they're typically more reliable than fresh code doing the same job.

This is procedural abstraction at ecosystem scale (Lesson 14): you call RANDOM(1, 6) knowing what it does, never how — same contract, written by strangers.

APIs: the instruction manual

An API (Application Program Interface) documents how to use a library: what procedures exist, what parameters they take, what they return, what behavior to expect. Before using a library, a programmer reads its API — knowing how to call a procedure without knowing its internals is exactly the point.

Exam-level claims: APIs document how library procedures connect to and are used by other programs; understanding an API's documentation is essential to using a library correctly. (If a question shows a made-up API description and asks how to call the procedure properly — read the documentation like a contract: parameter order, types, return value.)

RANDOM(a, b): the rules

RANDOM(a, b) returns an integer from a to b inclusive, with each value equally likely. Every call is independent — a fresh roll each time.

The count is b − a + 1, not b − a. RANDOM(5, 9) has five outcomes — forgetting the +1 is this topic's classic error.

Shifting and scaling. RANDOM(1, 6) + RANDOM(1, 6) models two dice — values 2 through 12, not equally likely (7 has six ways; 2 has one). Contrast RANDOM(2, 12): same range, all eleven values equally likely — a different distribution, hence a different (wrong) model of two dice. The exam tests exactly this contrast.

Probability from RANDOM. Each of the b − a + 1 values has equal chance, so P(any specific value) = 1/(b − a + 1), and P(a condition) = (count of qualifying values)/(total values):

IF (RANDOM(1, 10) ≤ 3)     ← true with probability 3/10
{
    DISPLAY ("prize")
}

Values 1, 2, 3 qualify out of ten → a 30% prize chance. Building "an event that happens p% of the time" = choosing a range where the qualifying slice is p% of the outcomes. RANDOM(1, 4) = 1 → 25%. RANDOM(1, 100) ≤ 40 → 40%.

Randomness in programs

Why programs use randomness (the CED's view): variety in games (shuffles, spawns, dice), unpredictability in security contexts, and modeling real-world uncertainty — the foundation of simulations, next lesson. When a question asks "why include RANDOM," the answer ties to modeling variability or producing varied behavior — not "to make the program faster."

Worked Examples

Example 1 (easy): Count the outcomes

Problem: How many different values can RANDOM(3, 11) produce, and what is the probability it produces 11?

Solution: 11 − 3 + 1 = 9 values (3,4,5,6,7,8,9,10,11). Each equally likely → P(11) = 1/9.

Interpretation: Write the +1 every time. When unsure, list a small case: RANDOM(3, 5) → 3, 4, 5 → three values = 5 − 3 + 1 ✓.

Example 2 (medium): Which expression models it?

Problem: A spinner has 8 equal sections numbered 10, 20, 30, ..., 80. Which expression models one spin?

(A) RANDOM(10, 80) (B) RANDOM(1, 8) * 10 (C) RANDOM(10, 80) * 10 (D) RANDOM(1, 8) + 10

Solution: (B). RANDOM(1, 8) → 1..8, ×10 → 10, 20, ..., 80 — exactly the eight section values, equally likely. (A) produces 71 possible values (10 through 80, including 37 and 55 — not on the spinner). (D) gives 11..18. (C) gives 100..800.

Interpretation: Transform-the-range questions: generate the count you need (8 outcomes → RANDOM(1,8)), then scale/shift into position. Check both ends: 1×10 = 10 ✓, 8×10 = 80 ✓.

Example 3 (medium): Probability of a branch

Problem: How often does this display "GOAL"?

r ← RANDOM(1, 20)
IF (r > 15)
{
    DISPLAY ("GOAL")
}

Solution: Qualifying values: 16, 17, 18, 19, 20 → 5 of 20 → probability 1/4 (25%).

Interpretation: Count the qualifying integers by hand — the strict > excludes 15 itself (boundary reading, Lesson 9). r ≥ 15 would qualify six values (30%): one symbol, different answer, both offered as choices.

Example 4 (AP-style): Two calls are two rolls

Problem: Which code correctly displays the sum of TWO dice rolls?

(A)

r ← RANDOM(1, 6)
DISPLAY (r + r)

(B)

DISPLAY (RANDOM(1, 6) + RANDOM(1, 6))

(C)

DISPLAY (RANDOM(2, 12))

(D)

DISPLAY (2 * RANDOM(1, 6))

Solution: (B) — two independent calls, two rolls. (A) rolls once and doubles it (only even sums; 2, 4, ..., 12). (D) is (A) in one line. (C) has the right range but the wrong distribution — every value 2..12 equally likely, whereas real dice make 7 the most common sum.

Interpretation: r + r where r holds one call = the same roll twice (Lesson 7: a variable holds a value). Independent events need independent calls. And range-matching isn't distribution-matching — the exam's deepest randomness question lives right there.

Common Mistakes

1. Off-by-one ranges. RANDOM(0, 6) is not a die (it has 7 outcomes, including 0). Check both endpoints against the device being modeled.
2. Forgetting b − a + 1. RANDOM(5, 9) has 5 outcomes, not 4. The +1 is worth actual points.
3. One call, used twice ≠ two calls. r + r doubles a single roll. Two dice need two RANDOM calls.
4. Equal range ≠ equal model. RANDOM(2, 12) ≠ two dice: uniform vs. peaked-at-7. Match the distribution, not just the endpoints.
5. Boundary slips in probability counts. > 15 vs ≥ 15 on RANDOM(1, 20): 5 vs. 6 qualifying values. Count integers explicitly, respecting the operator.

Practice Problems

x ← RANDOM(1, 3) + RANDOM(1, 3)
DISPLAY (x)

Create PT Connection

Randomness can power a Create PT (a quiz app choosing questions, a game dealing cards) — with one crucial caution: your PT's written responses must describe behavior you can demonstrate. Random behavior varies per run, so in your video, show a run where the feature clearly works, and in written responses describe the range and role of the randomness precisely ("RANDOM(1, LENGTH(questions)) selects a valid index, so every question can be chosen").

Also note the library angle: your PT will inevitably use built-in procedures (display, input, list operations). Rubric-wise that's fine — required, even — but the student-developed procedure must be yours, not a thin wrapper around one library call. myRandom(a, b) that just returns RANDOM(a, b) will not survive scoring; drawCard(deck) that picks a random index, removes the card, and returns it — with selection and iteration in the mix — will.

Mini practice (WR 2(a) style): "Explain how randomness affects your program's behavior across runs." Model: Each run, RANDOM(1, LENGTH(deck)) selects a different card index, so no two games deal the same sequence; the logic that processes the card is identical every run — only the data chosen varies.