BasketMC

Sequence Peak Detector Part 2, Episode 8: TIS-100

  • Published on

Episode 8 goes back to Sequence Peak Detector, the puzzle the last episode left unsolved. Basket throws out the plan the nodes open with, turns the two bottom nodes into storage cells, and spends most of the video stepping through runs that write the wrong numbers. By the end the puzzle passes.

Storage cells

The puzzle text reads: "Sequences are zero-terminated. Read a sequence from IN. Write the min value to OUT.I. Write the max value to OUT.A." The video opens with a program already in the nodes. The commentary talks it through and gives up on it: "So that was a lot of planning for not working."

Basket rewrites the two nodes above OUT.I and OUT.A as storage. As the commentary lays it out, a zero means send the stored value out and reset, a negative number means send the value back up, and anything else gets kept. On screen that is "SWP", "SAV", "MOV UP ACC", "JEZ OUTPUT", "JLZ RET", with an OUTPUT label that ends "MOV ACC DOWN" and "MOV 0 ACC".

Comparing

The node under IN now copies each number down and to the right, and "MOV LEFT DOWN" passes the copy along. The two middle nodes do the comparing: each takes a number, sends "MOV -1 DOWN" to ask its storage cell for the value it holds, runs "SUB DOWN", and jumps back to START if the new number loses. Otherwise "SWP" and "MOV ACC DOWN" hand the new number down to be kept. A zero from IN becomes "MOV 0 DOWN".

The first run stops almost at once. Both outputs get a red 0 where 14 and 73 were expected. "Zeros, huh?"

The Sequence Peak Detector screen during "Running test 1...": six nodes hold code, with two storage nodes above OUT.I and OUT.A, and the first value written to both OUT.I and OUT.A is a red 0 where 14 and 73 are expected

Stepping through

Basket steps through and watches 14 come in from IN. The commentary decides a cell needs to accept a number outright when the value it had before was 0, then sees that the min side "never kept the 14."

The Sequence Peak Detector program paused mid-step: the node under IN shows 14 in its ACC register with "MOV ACC DOWN" highlighted, the compare and storage nodes below wait on their first lines, and the output columns are still empty

Swapping "SAV" and "SWP" at the top of the storage code changes the failure: the next run writes -1 to both outputs.

The Sequence Peak Detector screen during a test run with a red -1 as the first value in both OUT.I and OUT.A; the two storage nodes now begin "START:", "SAV", "SWP"

A stray -1

More breakpoints follow. A jump condition is flipped and flipped back, and a "SWP" in the RET branch becomes "SAV". On the next run OUT.A starts with the right 73 while OUT.I still shows -1. "A is figured out."

Starting at 999

The zero is still the trouble on the min side. Basket tries a check for a zero coming back from below, squeezes the OUTPUT label onto one line to make room, still runs short of lines, and removes the check again. Then a different idea: "These numbers can only go up to 999." The OUT.I cell gets "MOV 999 ACC" before START and resets to 999 instead of 0, so the first real number is never higher. "If 999 happens to come through here, that's okay."

The run is slow, then fast-forwarded, and every output matches.

The Sequence Peak Detector test running with OUT.I and OUT.A filling with values that match the expected columns; the node above OUT.I begins and ends with "MOV 999 ACC"

Where it ends

The result screen reads 481 cycles, 6 nodes and 49 instructions. A friend's score beside it has fewer cycles with the same nodes and instructions; the commentary expected more lines. "I'm done with that puzzle." The segment map shows Sequence Peak Detector as nominal, and the video cuts to the end card.