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

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)?

• People read from top bottom, left -to-right in English. So, first SOLVE_PROBLEM, then CHECK, then FUNCTION_1 then FUNCTION_2 Jun 20, 2015 at 14:50
• This seems to be a question about computer science, rather than about academia per se. Jun 20, 2015 at 18:32
• Whatever best communicates the algorithm to a human reader.( Jun 21, 2015 at 3:44

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.

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.