Recursion - Building the printArray() Assignment

Comparison matrix

From The assignment, decoded: refill the which means column from what you know. The rest of the table is as it appeared.

Comparison matrix

From How we will spend the hour: every row here is a choice with a cost. Fill the what we do column, then say which row you would actually pick and what you give up for it.

Discussion prompt

How would you print every element of an array with a loop? You could write this in your sleep:

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

Explain Counting off: recursion with people by analogy to something with no Java in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Discussion prompt

Explain A method that calls itself to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Sort into buckets

Every line below is part of the definition of Base case or of Recursive step — one or the other, never both. Put each where it belongs.

Base case

The condition under which the method does NOT call itself - it just stops (returns).; the index has walked past the last element.

Recursive step

The line where the method calls itself on a smaller version of the problem.; print one element, then call yourself with index + 1.

b1

The condition under which the method does NOT call itself - it just stops (returns). For printArray: the index has walked past the last element.

b2

The line where the method calls itself on a smaller version of the problem. For printArray: print one element, then call yourself with index + 1.

Discussion prompt

The recursion skeleton works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".

Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.

Eliminate the wrong options

In printArray, what is the job of the line if (index == array.length) { return; }?

3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.

• A. It prints the last element of the array.
• B. It restarts the recursion from index 0.
• C. It stops the recursion once the index has walked past the last element.
• D. It removes the element at position index from the array.

Survives elimination: C

Why: That line is the base case. Valid indexes run from 0 to array.length - 1, so the moment index equals array.length there is nothing left to print, and returning without another recursive call stops the whole chain.

Check your understanding

In printArray, what is the job of the line if (index == array.length) { return; }?

• A. It prints the last element of the array.
• B. It restarts the recursion from index 0.
• C. It stops the recursion once the index has walked past the last element. (correct)
• D. It removes the element at position index from the array.

Answer: C

Why: That line is the base case. Valid indexes run from 0 to array.length - 1, so the moment index equals array.length there is nothing left to print, and returning without another recursive call stops the whole chain.

Why A tempts people

It prints nothing - it returns before the print line is ever reached. The last element was printed by the previous call, at index array.length - 1.

Why B tempts people

Nothing in the method sets index back to 0. Each call only ever moves the index forward by one.

Why D tempts people

Java arrays have a fixed size and nothing here modifies the array. The method only reads elements.

Predict first

Never trace recursion for the first time on 100 elements. We shrink the problem to 3 elements, trace it perfectly, and then trust the same mechanism at 100.

Commit before you compute: what does Our tiny test array come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Name what we know before running anything

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. arr.length is 3, valid indexes are 0, 1, 2, and the first call starts the index at 0.

Step through it

Step through Our tiny test array one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: index is 0
2. Step 2: index is 1
3. Step 3: index is 2

Put in order

Put the moves of Call 1: printArray(arr, 0) into the order they have to happen.

1. Check the base case: is 0 == 3?
2. Print one element: arr[0] is 7
3. Hand off the rest: printArray(arr, 1)

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. No - so we do NOT stop. We fall through to the work line.

Annotate

Walk the callouts on Call 1: printArray(arr, 0). Each one is a place this is easy to get subtly wrong.

• No - so we do NOT stop. We fall through to the work line.
• Each call handles exactly one element - this call's element is the one at its own index.
• Call 1 is now PAUSED on line 6, waiting for the hand-off to finish. It has not returned yet.

Discussion prompt

Three calls are now paused, each waiting on the one it started. The output so far reads 7 2 9 - and one more call is in flight.

What do you need to know — or decide — before the first line can be written? List everything the problem has to hand you.

Hint: Anything you would have to invent to get started is a thing the problem must supply.

Discussion prompt

Work backwards. The example finished here:

Call 3: printArray(arr, 2)

What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.

Hint: Every quantity in the result had to enter somewhere. Account for each one.

Predict first

printArray(arr, 0) runs on the 3-element array {7, 2, 9}. How many times is printArray called in total, counting the first call?

Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.

Correct: 4 - one per element, plus the base-case call that prints nothing.

Why: Calls at indexes 0, 1 and 2 each print an element, and the fourth call at index 3 hits the base case and returns silently. An n-element array always costs exactly n + 1 calls - the assignment's 100-element array makes 101.

Check your understanding

printArray(arr, 0) runs on the 3-element array {7, 2, 9}. How many times is printArray called in total, counting the first call?

• A. 3 - one call per element.
• B. 4 - one per element, plus the base-case call that prints nothing. (correct)
• C. 9 - one call per element value.
• D. 1 - it is one method, so it is called once.

Answer: B

Why: Calls at indexes 0, 1 and 2 each print an element, and the fourth call at index 3 hits the base case and returns silently. An n-element array always costs exactly n + 1 calls - the assignment's 100-element array makes 101.

Why A tempts people

Close - but the call at index 3 is still a real method call, even though it prints nothing. Without it, nothing would ever stop the chain.

Why C tempts people

The element VALUES (7, 2, 9) never control how many calls happen - only the array LENGTH does. Values are what gets printed, not how far we recurse.

Why D tempts people

Each recursive invocation is a genuine separate call with its own stack frame and its own copy of index. That is exactly why the call stack grows.

Check your understanding

With the base case written as if (index == array.length - 1) return;, what does printArray(arr, 0) output on the array {7, 2, 9}?

• A. 7 2 9
• B. 7 2 (correct)
• C. 2 9
• D. It crashes with ArrayIndexOutOfBoundsException.

Answer: B

Why: The call at index 2 sees 2 == 3 - 1 and returns before reaching the print line, so the last element is silently skipped. The verified run prints exactly '7 2'. Off-by-one base cases do not crash - they quietly drop an element.

Why A tempts people

That is what the CORRECT base case (index == array.length) prints. The early version returns one call too soon to print the 9.

Why C tempts people

The recursion always starts at index 0 and moves forward, so the FRONT of the array is never skipped - it is the last element that gets lost.

Why D tempts people

No index ever exceeds the array bounds here - the method stops too EARLY, not too late. This bug produces wrong output, not a crash, which makes it more dangerous.

Draw it

Draw what Step 1 · Class skeleton and main just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Predict first

Indexes 0 to 99 - not 1 to 100. This same one-past-the-end boundary is exactly where the recursive base case will stand guard later: at index 100.

Commit before you compute: what does Step 2 · Instantiate the 100-element array come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Read the line right to left

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. new int[100] builds a block of 100 int slots, all starting at 0; int[] array names it.

Sort into buckets

These are the pieces of Recursion - Building the printArray() Assignment, out of order. Put each one back under the part of the lesson it belongs to.

Part 1 · What Is Recursion?

The loop version you already know; Counting off: recursion with people; A method that calls itself

Part 2 · Trace It by Hand

Our tiny test array; Call 1: printArray(arr, 0); Calls 2 and 3 ride the same rails

Part 3 · Build the Assignment

The build plan: eight small steps; Step 1 · Class skeleton and main; Step 2 · Instantiate the 100-element array

s1

Part 1 · What Is Recursion? is where Recursion - Building the printArray() Assignment puts The loop version you already know, Counting off: recursion with people, A method that calls itself. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s2

Part 2 · Trace It by Hand is where Recursion - Building the printArray() Assignment puts Our tiny test array, Call 1: printArray(arr, 0), Calls 2 and 3 ride the same rails. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s3

Part 3 · Build the Assignment is where Recursion - Building the printArray() Assignment puts The build plan: eight small steps, Step 1 · Class skeleton and main, Step 2 · Instantiate the 100-element array. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

Put in order

Put the moves of Step 3 · Fill the array into the order they have to happen.

1. Create Random once, OUTSIDE the loop
2. Loop i from 0 while i < array.length
3. Store nextInt(100) + 1 each pass

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. One generator is reused for all 100 numbers - creating it inside the loop works but is wasteful and a bad habit.

Comparison matrix

From Step 3 · Fill the array: refill the i column from what you know. The rest of the table is as it appeared.

Discussion prompt

The rule this trap just fixed:

The bound in nextInt(n) is exclusive: n values starting at 0. Shift the whole window up with + 1 and the range becomes 1 to 100.

Now break it on purpose. Build a case that violates it and follow the consequences until something visibly fails. Where does the failure first show up — and would you have noticed it if you had not been looking?

Hint: The dangerous rules are the ones whose violation still produces an answer. If yours fails loudly, try to find one that fails quietly.

Predict first

Which expression produces a random integer between 1 and 100 inclusive, as the assignment requires?

Commit to an answer, then rate it — certain, fairly sure, or guessing — and write the rating down before you turn the page.

Correct: rand.nextInt(100) + 1

Why: nextInt(100) yields 0 through 99 - one hundred values starting at zero. Adding 1 shifts the whole window to 1 through 100, hitting both endpoints the assignment demands and nothing outside them.

The rating matters as much as the answer: confident-and-wrong is the combination that survives revision, because nothing about it feels like it needs revisiting.

Check your understanding

Which expression produces a random integer between 1 and 100 inclusive, as the assignment requires?

• A. rand.nextInt(100)
• B. rand.nextInt(101)
• C. rand.nextInt(100) + 1 (correct)
• D. rand.nextInt(99) + 1

Answer: C

Why: nextInt(100) yields 0 through 99 - one hundred values starting at zero. Adding 1 shifts the whole window to 1 through 100, hitting both endpoints the assignment demands and nothing outside them.

Why A tempts people

Gives 0 to 99: it can produce a forbidden 0 and can never produce 100. Two separate violations in one call.

Why B tempts people

Gives 0 to 100 - the top end is now right, but 0 can still appear in your screenshot.

Why D tempts people

Gives 1 to 99: no zeros, but 100 itself can never be generated, and the assignment says 100 inclusive.

Predict first

The table runs: System.out.print(array[index] + " ") | 65 41 38 ... - one row, space-separated · System.out.println(array[index]) | one number per line - 100 rows

In Step 6 · Do one small piece of work, given the rows so far: what is the next one — the row where choice is System.out.print(array[index])?

Correct: System.out.print(array[index]) | 654138... - unreadable digit soup

Why: The relationship between the columns, not the individual numbers, is what generates the next row. The assignment says separated by SPACES - println would put every element on its own line.

Sort into buckets

Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.

Holds up

Before writing anything, translate each sentence of the assignment into the code it is really asking for.; How would you print every element of an array with a loop? You could write this in your sleep:; Imagine a line of people who need to count off. Nobody runs a loop. Each person follows one tiny rule: say your number, then tap the next person.

Breaks

"The recursion will just stop on its own when the array runs out, right?" Let's delete the base case and find out:; "Stop AT the last element" sounds right - so this base case is tempting:

sound

These are stated as this lesson states them — each one survives the edge cases Recursion - Building the printArray() Assignment puts it through.

flawed

Each of these is lifted from a trap in this deck: reasonable-sounding, and wrong in a way that only shows up once you rely on it.

Fill in the blanks

From Step 8 · Wire it up in main — one line has had its right-hand side removed. Put it back.

public static void main(String[] args) rand.nextInt(100) + 1;}
}
printArray(array); // the recursive display
System.out.println(); // finish the row cleanly
}

Why: array[i] is what everything below it consumes, so the wrong expression here fails later and somewhere else. printArray can only display what the loop already stored - calling it before the loop would print 100 zeros.

Predict first

The table runs: starts with | 65 41 38 58 13 96 29 9 66 61 ... · how many numbers | exactly 100 · all within 1..100? | yes - smallest seen 2, largest seen 100

In Compile and run, given the rows so far: what is the next one — the row where check on the real output is separated by?

Correct: separated by | single spaces, one row

Why: The relationship between the columns, not the individual numbers, is what generates the next row. IDE users: the Run button does both.

Draw it

Draw what Compile and run just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Check your understanding

Which single line makes printArray a recursive method?

• A. if (index == array.length) { return; }
• B. System.out.print(array[index] + " ");
• C. printArray(array, index + 1); (correct)
• D. int[] array = new int[100];

Answer: C

Why: A method is recursive precisely when it calls itself, and that is the line where printArray invokes printArray. The base case and the print line are essential supporting cast, but the self-call is what earns the word 'recursive' - and it is what the grader will look for in your code screenshot.

Why A tempts people

That is the base case - it is what STOPS the recursion. Necessary for correctness, but a method with only this line never calls itself.

Why B tempts people

That is the one piece of work each call performs. Printing is the method's job, not its recursive structure.

Why D tempts people

That line lives in main and just builds the array. It runs once and involves no method calling itself.

Predict first

A student's program prints '43 43 43 43 43 ...' and then crashes with java.lang.StackOverflowError. Which bug is the most likely cause?

Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.

Correct: The recursive call passes index instead of index + 1.

Why: The same value repeating means the index never advances - every call re-prints its own element and hands off an identical problem, so calls pile up until the stack overflows. Our verified broken run showed exactly this shape: repeated output, then over a thousand identical stack frames.

Check your understanding

A student's program prints '43 43 43 43 43 ...' and then crashes with java.lang.StackOverflowError. Which bug is the most likely cause?

• A. The import java.util.Random; line is missing.
• B. The base case tests index == array.length - 1 instead of array.length.
• C. The recursive call passes index instead of index + 1. (correct)
• D. The array is too large for Java to handle.

Answer: C

Why: The same value repeating means the index never advances - every call re-prints its own element and hands off an identical problem, so calls pile up until the stack overflows. Our verified broken run showed exactly this shape: repeated output, then over a thousand identical stack frames.

Why A tempts people

A missing import is a COMPILE error - the program would never have run at all, let alone printed anything.

Why B tempts people

The off-by-one base case still advances the index every call, so it terminates fine - its symptom is one silently missing element, not a crash.

Why D tempts people

A 100-element int array is about 400 bytes - trivial. The stack overflowed from unbounded CALLS, not from the array's size.

Discussion prompt

Explain Screenshot 1 · The code to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Discussion prompt

Explain Screenshots 2 and 3 · The runs by analogy to something with no Java in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Discussion prompt

A narrow console wraps or scrolls 100 numbers, and a screenshot missing part of the output demonstrates only part of the assignment. Fallbacks, in order of preference:

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

The assignment is done. Now the ownership test: make it print the array backwards - changing nothing but the order of two lines.

What do you need to know — or decide — before the first line can be written? List everything the problem has to hand you.

Hint: Anything you would have to invent to get started is a thing the problem must supply.

Discussion prompt

Work backwards. The example finished here:

Verify against the real run

What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.

Hint: Every quantity in the result had to enter somewhere. Account for each one.

Eliminate the wrong options

Inside a correct printArray, the print line and the recursive call are swapped, so the method recurses first and prints after. Running it on {7, 2, 9} - what happens?

3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.

• A. It prints 7 2 9, same as before.
• B. It prints 9 2 7 - the array backwards.
• C. It crashes with StackOverflowError.
• D. It prints nothing at all.

Survives elimination: B

Why: With the recursive call first, every call dives all the way to the base case before any printing happens; each call then prints its element as the stack unwinds, deepest call first. The verified run outputs exactly 9 2 7. Where a line sits relative to the recursive call decides whether it runs on the way down or the way back.

Check your understanding

Inside a correct printArray, the print line and the recursive call are swapped, so the method recurses first and prints after. Running it on {7, 2, 9} - what happens?

• A. It prints 7 2 9, same as before.
• B. It prints 9 2 7 - the array backwards. (correct)
• C. It crashes with StackOverflowError.
• D. It prints nothing at all.

Answer: B

Why: With the recursive call first, every call dives all the way to the base case before any printing happens; each call then prints its element as the stack unwinds, deepest call first. The verified run outputs exactly 9 2 7. Where a line sits relative to the recursive call decides whether it runs on the way down or the way back.

Why A tempts people

Order relative to the recursive call is everything: printing BEFORE the call gives forward order on the way down; printing AFTER gives reverse order on the unwind.

Why C tempts people

The base case and the index + 1 are untouched, so the recursion still terminates after exactly 4 calls - only the timing of the print moved.

Why D tempts people

The print line still executes once per element - just after each call's recursive work finishes instead of before. Every element is printed exactly once.

Predict first

Same skeleton, different work: instead of printing each element, add it. This is the from-scratch exercise to try solo after the session:

Commit before you compute: what does Transfer: a recursive sum come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Verify: real run on {7, 2, 9} returned 18

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. Read the table bottom-up to watch the answers assemble during the unwind - the same return trip that printed backwards a moment ago.

Annotate

Walk the callouts on Transfer: a recursive sum. Each one is a place this is easy to get subtly wrong.

• A void method just stops; a summing method must answer. The sum of nothing is 0 - the identity that makes the additions work.
• Read the table bottom-up to watch the answers assemble during the unwind - the same return trip that printed backwards a moment ago.

Comparison matrix

From Loop vs recursion: an honest comparison: every row here is a choice with a cost. Fill the recursion column, then say which row you would actually pick and what you give up for it.

Match the pairs

From Questions students always ask — match each one to what it actually does. The descriptions have been shuffled.

• c1. Why not just use a loop?
• c2. Is the for loop in main cheating?
• c3. Are two methods named printArray legal?

• b1. For this task a loop is fine - the assignment is teaching the mechanism. Backwards printing already showed the payoff, and folder trees will make it undeniable.
• b2. No - the assignment explicitly says to FILL the array with a for loop. Only printArray has to be recursive, and yours is.
• b3. Yes - that is overloading: same name, different parameter lists. Java picks by the arguments at the call site. It is how we honored the pseudo-code's one-argument call.

Why: Why not just use a loop?, Is the for loop in main cheating?, Are two methods named printArray legal? are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.

Comparison matrix

From Final pre-submission checklist: refill the done column from what you know. The rest of the table is as it appeared.

Match the pairs

Match each term to the definition this lesson gave it — not the one you would guess from the word.

• t1. Base case
• t2. Recursive step
• t3. Recursive method
• t4. Call stack
• t5. Overloading

• d1. The condition under which the method does NOT call itself - it just stops (returns). For printArray: the index has walked past the last element.
• d2. The line where the method calls itself on a smaller version of the problem. For printArray: print one element, then call yourself with index + 1.
• d3. A method that calls itself, directly or indirectly, handling one piece of the problem per call.
• d4. Java's tower of paused calls - it grows one frame per call on the way down and unwinds as returns cascade back.
• d5. Two methods sharing a name with different parameter lists - how printArray(array) and printArray(array, index) coexist.

Why: These are the working definitions of Base case, Recursive step, Recursive method, Call stack, Overloading as Recursion - Building the printArray() Assignment uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.

Draw it

One page, no notation unless you need it: draw how these connect — Part 1 · What Is Recursion? · Part 2 · Trace It by Hand · Part 3 · Build the Assignment · Part 4 · When It Breaks · Part 5 · Screenshots & Submission · Part 6 · Prove You Own It. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.