4.4 Algorithm Formats: Natural Language, Flowcharts, Pseudocode, and Tracing

What this competency asks

ETS asks you to understand how to develop and analyze algorithms expressed in multiple formats (natural language, flowcharts, and pseudocode):

1. Interpret diagrams that describe algorithms, given an explanation of the symbols used.
2. Compare algorithms written in multiple formats.
3. Trace and analyze algorithms written in different formats.
4. Identify the correct sequencing of steps in an algorithm, and errors in sequencing.

Three ways to express one algorithm

An algorithm is a finite sequence of unambiguous steps that solves a problem. Here is one algorithm, finding the largest value in a list, in three formats.

Natural language

1. Take the first value as the largest so far.
2. Look at each remaining value in turn.
3. If a value is greater than the largest so far, it becomes the new largest.
4. When no values remain, report the largest so far.

Pseudocode (ETS notation)

int findMax ( int[ ] nums, int n )
    int largest ← nums[0]
    for ( int i ← 1; i < n; i ← i + 1 )
        if ( nums[i] > largest )
            largest ← nums[i]
        end if
    end for
    return largest
end findMax

Flowchart: see the diagram in this section.

When a question asks you to compare formats, check that each version has the same initialization, the same condition (for example, > versus ≥), the same loop range, and the same result. A natural-language version that says "start with 0 as the largest" is not equivalent to one that starts with the first element, because it fails when every value is negative.

Reading flowcharts

ETS's content description says you will interpret diagrams given an explanation of the symbols used, so read the legend on the test. The conventional symbols (from the ISO 5807 flowchart standard) are:

A loop in a flowchart is an arrow that returns to an earlier decision. When you trace one, keep going around the loop until the decision sends you out.

Tracing: the most important skill

Tracing (also called desk checking) means executing an algorithm by hand. Build a trace table:

1. One column per variable, plus columns for any condition and for output.
2. Write the initial values.
3. Go line by line. When a variable changes, add a row with its new value.
4. Record true or false for each condition so you follow the correct branch.
5. Stop when the loop condition fails, and note the final values.

Worked trace

int total ← 0
int k ← 1
while ( k ≤ 4 )
    if ( k % 2 == 0 )
        total ← total + k * 3
    else
        total ← total + k
    end if
    k ← k + 1
end while
print "Result: " + total

Output: Result: 22. Notice that the loop test runs five times but the body runs four times. Questions about "how many times is the condition evaluated" versus "how many times does the body execute" test exactly this difference.

Sequencing: order matters

Many questions show an algorithm with steps missing or out of order. Common sequencing errors:

Example of the first error:

int sum ← 0
for ( int i ← 0; i < n; i ← i + 1 )
    sum ← 0
    sum ← sum + list[i]
end for

Deleting the sum ← 0 inside the loop fixes the algorithm, because the initialization above the loop already runs once. To find a sequencing error, trace a small input, such as a list of two or three values, and compare with the intended result.

Loops that test at the top vs. the bottom

A pre-test loop (while) checks its condition before each pass, so it may run zero times. A post-test loop (do … while, repeat … until) checks after each pass, so it runs at least once. This matters with sentinel values, special values such as −1 that mark the end of input:

// Version A: pre-test
int record ← readNext ( )
while ( record ≠ -1 )
    process ( record )
    record ← readNext ( )
end while

// Version B: post-test
int record ← 0
repeat
    record ← readNext ( )
    process ( record )
until ( record == -1 )

Version A reads first and tests before processing, so the sentinel is never processed, and an input that starts with −1 processes nothing. Version B processes whatever it just read before testing, so it always calls process ( -1 ) once at the end, including when the input is empty.

Other defects that tracing reveals

• Off-by-one errors: i ≤ n instead of i < n in a 0-based array of length n reaches the invalid index n.
• Infinite loops: the condition can never become false. For example, while ( count ≠ 10 ) with count starting at 1 and increasing by 2 skips 10 forever.
• Unreachable code: statements after an unconditional return, or inside an if whose condition can never be true, such as ( x > 10 ) and ( x < 5 ).