Exercise 1: Hand-Tracing the Flowchart on [5, 5, 5] — Possible Solution
====================================================================

HAND-TRACE
------------------------------
list = [5, 5, 5], n = 3

Start -> Input list -> max_val <- list[0] = 5 -> i <- 1

Diamond "i <= n-1?" (i.e. i <= 2):
  i=1: 1<=2, Yes -> go to second diamond

Diamond "list[i] > max_val?":
  list[1]=5, max_val=5. Is 5 > 5? No.
  -> i <- i+1 = 2, loop back to first diamond

Diamond "i <= n-1?":
  i=2: 2<=2, Yes -> go to second diamond

Diamond "list[i] > max_val?":
  list[2]=5, max_val=5. Is 5 > 5? No.
  -> i <- i+1 = 3, loop back to first diamond

Diamond "i <= n-1?":
  i=3: 3<=2, No -> Output max_val

FINAL OUTPUT: 5

WHY THE OUTPUT IS CORRECT DESPITE max_val NEVER BEING "UPDATED"
------------------------------
The decision diamond specifically asks "list[i] > max_val?" using
STRICT greater-than, not "greater than or equal to." Every element in
this list is exactly equal to max_val's starting value (5), so the
condition list[i] > max_val is false at every single check - max_val
is never reassigned after its initial value from list[0].

This is still correct because max_val started out already holding the
correct answer: list[0] itself is 5, and since every other element is
also 5, the true maximum of the whole list genuinely is 5 - the same
value max_val already had before the loop even ran. The strict
greater-than comparison doesn't need to "find" the maximum among tied
values; it only needs to update max_val when it finds something
STRICTLY larger than what's already recorded, and correctly leaves
max_val alone whenever nothing larger exists - which includes the case
where everything is tied for the maximum.

WHY THIS WORKS AS AN ANSWER
------------------------------
The trace follows every diamond and arrow explicitly through both loop
iterations rather than skipping to the final answer, and the
explanation correctly identifies why strict-greater-than still produces
the right result on an all-tied list - not because ties are handled
specially, but because the initial value already happened to be
correct and nothing forced it to change incorrectly.