Top-down vs Bottom-up approaches in describing an algorithm in a research paper

Question

When writing a (computer science) research paper, I have to describe my method in term in pseudocode. Because of readability and reusability, I want to break my method into smaller pieces. However, I don't know how to present them in my paper. As far as I know, there are two approaches:

• Top-down: first, present a main pseudocode which calls/invokes other smaller ones which will be explained later.
• Bottom-up: present and explain all the smaller pieces first, then combine them together into a bigger one.

For example, in my paper, I'm presenting a method to solve to a problem, this method is describe by a funtion, named SOLVE_PROBLEM, as follow:

SOLVE_PROBLEM(input) {
    if CHECK(input) then:
        FUNCTION_1(input)
    else:
        FUNCTION_2(input)
}

As you can see, SOLVE_PROBLEM uses other functions (CHECK, FUNCTION_1 and FUNCTION_2) to find a solution. My question is to how to presents those functions in my paper. Should I present i) SOLVE_PROBLEM first (as it is the solution to the problem, which is the main point of the paper), or ii) other methods fisrt (as they are the building blocks to a solution)?

Answer 1

The answer depends on personal preferences, as well as on the algorithm itself. Consider the following two descriptions of SOLVE_PROBLEM:

Top-down: We want to solve problem A on input. Function SOLVE_PROBLEM solves the problem. There are two cases, depending on condition B, which we can check with function CHECK. If the condition holds, we solve the problem with FUNCTION_1. Otherwise we use FUNCTION_2.

Bottom-up: We want to solve problem A on input. In the general case, the problem can be solved with FUNCTION_1. The general solution assumes condition B, which we can check with function CHECK. If the condition does not hold, we can solve the special case with FUNCTION_2. This completes function SOLVE_PROBLEM.

I personally prefer the top-down approach, if the algorithm has multiple equally important parts. Bottom-up approach becomes preferable, if one part of the algorithm attacks the core of the problem, while the rest just deals with special cases and administrative stuff.

Answer 2

In general, you should avoid telling a reader something without justifying why you say it (in terms the reader already gets), to avoid frustrating his motivation. At the same time, the paper should be readable at least linearly, so you can't say too much about stuff you haven't presented yet.

To follow this guideline, it is often (but not always) better to proceed top-down. When you start, you've explained why readers should care about your problem, hence why you need SOLVE_PROBLEM. Then you present SOLVE_PROBLEM and explain what the different steps achieve (not the how). Hopefully names give a hint, but often it's not enough. SOLVE_PROBLEM in turn motivates the other procedures, so you can explain them in the same way.

With a bottom-up presentation, you risk presenting code without having justified why it's needed. Maybe your FuzzBahzz solver needs a BarBuzz solver which needs a BipBop solver, but readers who care about FuzzBahzz might not guess why BipBop is related.