Use pseudocode tracing to check a loop's stopping point

Four display cards are numbered 1, 2, 3 and 4. The fictional instruction is to visit each card exactly once, in ascending order. A loop that says it handles four cards might still stop before card 4. To find out, write down the position at every condition check, the card visited when the condition is true, and the position after the update. The failed check belongs in the record too: it identifies where execution stops. For pseudocode tracing, verify each step.

In this example, a visit means the instruction processes the card at the current numbered position. It does not change the card collection or imply anything about a particular app. The goal is to compare an actual sequence of visits with the stated requirement. Keep the collection and starting position fixed while comparing stopping conditions; changing several parts at once would make it harder to tell why the result changed.

Before You Check Decision Table Logic, Trace The Stated Rule

First pin down the notation. The cards exist only at positions 1 through 4. Let pseudocode tracing follow a variable called position, initially assigned the value 1. An assignment such as “position becomes position plus 1” changes its stored value after the current card has been visited. “Less than 4” compares the current value with 4; equality does not pass. These meanings are part of this fictional exercise, so the trace has no hidden indexing convention to guess.

The instruction order is equally important. Test the condition before each visit. If it is true, visit the card at position, increase position by 1, and return to the test. If it is false, stop without visiting or increasing anything. Here is the complete first version, written as directions rather than code for a particular language:

1. Set position to 1.
2. While position is less than 4, visit the card numbered position.
3. After that visit, set position to position plus 1, then test the condition again.
4. When the condition is false, stop.

Notice that “four cards exist” is background information, while “position is less than 4” is the actual stopping rule. The number of cards cannot substitute for a condition check. Nor does “visit the card numbered position” increase position on its own. Making the update explicit prevents the trace from quietly moving to another card before the written instruction tells it to move.

Where To Check Decision Table Logic Versus Loop Execution

Write a row for each test, including the one that fails. Start with position 1: 1 is less than 4, so visit card 1 and update position to 2. At position 2, the condition is true; visit card 2 and update to 3. At position 3, it is true again; visit card 3 and update to 4. At position 4, “less than 4” is false. No visit or update follows that result.

A compact record can keep the order visible without hiding the last check. Read each line as “position at test; condition result; card visited; position after update”: 1; true; card 1; 2. Then 2; true; card 2; 3. Then 3; true; card 3; 4. Finally 4; false; none; still 4. That final “still 4” describes the unchanged state after stopping, rather than an extra iteration.

The required visits were 1, 2, 3 and 4. The recorded visits were 1, 2 and 3. Card 4 exists but was never processed. If a reader only counts the successful checks, they can see there were three visits, yet miss the reason. Recording the final failed comparison shows that the loop reached position 4 and stopped before the visit instruction could run. This is a boundary error in the stated example, not evidence that the card is missing from the collection.

Now change just the stopping comparison. Leave the four cards, the initial position of 1, the visit instruction and the plus-one update untouched. Say instead: “While position is less than or equal to 4, visit the card numbered position; then increase position by 1.” Equality matters at the boundary: position 4 now passes the test. Whether that change meets the requirement can be checked by another trace, rather than accepted because the new wording sounds inclusive.

For this second version, the successful checks at positions 1, 2 and 3 have the same visits and updates as before. Position 4 passes, visits card 4, then updates to 5. The next comparison, “5 is less than or equal to 4,” is false, leaving position at 5 when the loop stops. The visits are now 1, 2, 3 and 4 in order, with no repeat in this particular trace.

Position 5 in the stopped state is not an attempted visit to card 5. The condition is evaluated before the visit, and it fails at 5. If the exercise leaves out the order of the test and visit, however, you cannot safely infer that outcome. An instruction that visits first and tests afterward might try to use a nonexistent card. Write down the order actually specified before making a claim about what happens at the edge.

There is another way to expose the dependence on the initial state. Keep cards numbered 1 through 4 and keep the inclusive “less than or equal to 4” condition, but suppose the instruction explicitly starts position at 0. Zero passes the comparison, and the next instruction attempts to visit card 0. This collection has no card 0. Mark the attempted reference as invalid; do not add a card to rescue the example or skip directly to card 1 without a written rule allowing it.

A collection numbered 0 through 3 could be a different, coherent exercise, but that would change the collection and its upper boundary. Likewise, starting at 0 with a separate instruction to increase position before visiting would change the instruction order. Neither alternative describes the four-card example as stated. The trace is useful precisely because it exposes those choices rather than quietly repairing them.

If a real set of instructions does not specify the starting position, you cannot fill in the first row honestly. If it omits the update, you cannot infer the next position. If it says “repeat until done” without defining done, you cannot determine the failed check. Ask for the missing rule before claiming which cards are visited. A trace records the consequences of defined instructions; it cannot supply instructions that were never given.

Sometimes the condition itself refers to several facts, and the written rule does not say what to do for a particular combination. That is a separate question from following this single, defined comparison. When the choices of conditions or outcomes are incomplete, the related guide can help you check decision table logic. Once the rule is settled, return to the execution trace to see what repeated tests and updates actually do.

Tiburn HQ Board Walkthrough: Keep The Trace Visible

For an individual preparation setup, the listed Dell Inspiron laptop is one possible place to write the fictional directions and rows for pseudocode tracing. Ordinary written notes are enough for this exercise; no programming environment is required or implied by the product listing. Keep the original wording beside the rows so that a correction to the condition remains visibly separate from a correction to the initial position or update.

For a shared walkthrough, a Tiburn HQ Board is an optional display context for discussing the same written trace. The listing describes an interactive board, but this exercise does not depend on any particular file format, connection to the laptop or collaboration application. Verify an actual display arrangement separately if you plan to use one. The reasoning works just as well when people read the rows from paper.

During a discussion, point to the position at the start of each row before naming the card. Have someone state whether the comparison passes; only then add a card visit or write “none.” After a successful visit, record the new position in the same row. The next row begins with that new value. At the failed comparison, leave the visit and update absent. This order makes it possible to spot a row that accidentally records a visit after stopping.

Place the strict and inclusive traces side by side in the notes. Their rows for positions 1 through 3 agree, so the first meaningful disagreement is the test at position 4. In the strict version it fails and card 4 remains unvisited. In the inclusive version it passes, card 4 is visited, and the subsequent test fails at position 5. The comparison isolates the effect of the boundary wording without crediting the changed rule for differences it did not cause.

One reader can challenge the trace with a narrow question: “Which written instruction authorizes this row?” A visit at position 4 under the strict condition has no authorization because its test was false. A second visit at position 3 has no authorization because the update moved position to 4 after the first visit. A visit to card 5 under the inclusive condition has no authorization because the test at position 5 fails. These checks refer to specific rows rather than a general impression that the loop looks right.

Keep the conclusion bounded by the example. With cards numbered 1 through 4, initial position 1 and a plus-one update after each visit, “less than 4” visits cards 1 through 3 and stops at 4. “Less than or equal to 4” visits all four and stops at 5. A starting position of 0 against cards numbered 1 through 4 attempts an undefined visit unless another written instruction changes the order. For another collection or an incompletely stated rule, make a fresh trace rather than treating these rows as a universal proof.