Algorithms Introduction

Introduction

An algorithm is a means of describing the logic or processing involved in completing a task. They can be used to express the processing for a whole variety of different situations from business operations through to solving puzzles like a Rubik's Cube or something simple such as tying a shoe lace. They are also highly effective as an intermediate step between planning out the overall structure of a software program and the writing of code.

In this tutorial we will investigate two methods of algorithm description commonly used in software engineering :

• Pseudocode - a text based method
• Flowcharts - a graphical method

The two methods are comparable and have the same features. Anything you can represent in one, you can represent similarly in the other.

The rest of this page will cover general algorithm concepts the first basic structure, Sequence. Future pages will cover the following :

• The second basic structure - Decision
• The third basic structure - Iteration (loops)
• Functions
• Arrays and Records
• Examples and Standard Algorithms
• Pseudocode cheat sheet

Sequence

Sequence is the first of three basic structures that make up algorithms (the other two being decisions and iteration). A sequence is a series of steps which should be executed, in order, one after the other. Let's look at an example in pseudocode :

In the above example there are a few things to note :

• BEGIN and END are keywords and as such are written in all UPPERCASE.
• Get, Set and Display are not keywords but are actions, start them with uppercase letters to indicate as such.
• Indentation is used to help illustrate the structure of the program. Generally you indent following any keyword.
• number1, number2 and answer are variables (for storing values) and are written in all lowercase.

These general rules should be followed strictly. Doing so increases readability and means the reader can spend more of their focus on understanding the logic as opposed to reading the algorithm.

Whilst you should be strict with the layout of the algorithm, there are certain elements that offer flexibility. For actions, we can generally use a variety of words, as long as the words we use are obvious and unambiguous and that we are consistent in the words that we choose to use. Here are some common alternatives for the actions above :

• Get - Read, Ask, Input
• Set - Make (or just leave out altogether)
• Display - Show, Print

For instance, the following is just as valid for the above algorithm :

When it comes to flowcharts, sequence is represented in a similar manner to pseudocode however we incorporate shapes around the steps to visually present the logic. The following shapes are used :

The colours are not necessary. I've done it for ease of reading and you are welcome to use colours as well but it is prefectly fine to have them as just black and white.

Here is the same algorithm as presented above but in flowchart :

When using flowcharts there is also some flexibility in how we present them. Every step may be presented in it's own shape, or we may decide to group several related steps together into a single shape. This can help when we have larger algorithms to make it more compact and easier to visualise the overall structure of the logic. If you group steps together you should only group a maximum of 3 otherwise it can easily become messy and harder to read.

Here are a few other things you should do when using flowcharts to maximise readability :

• Line up shapes and joining lines so that they flow down in a consistent line.
• Make the different shapes for elements similar in size and proportion as much as practical.
• Flow lines should always enter a shape from the top and leave from the bottom.

The diagram to the side has broken each of these rules. For a small flowchart like this you can still read it ok but as soon as it starts growing in complexity, breaking these rules will quickly make for a diagram which is unwieldly.

Level of detail

One of the things that students always struggle with is the level of detail that is required in an algorithm. This can vary depending on the situation. You need enough detail to be unambiguous in what needs to be done but not so much detail that you effectively just implemented the solution.

An algorithm should be written in generic (yet still specific) wording and not use the syntax of a particular programming language. An algorithm should be language agnostic, that is, you should be able to read it and implement it in any programming language.

For example if I wanted only the integer part of the result of a calculation (say 9 divided by 2, which should result in 4) this could be achieved by :

• Algorithm : Set answer to integer part of num1 / num2
• Python : answer = int(num1 / num2)
• Javascript : var answer = Math.floor (num1 / num2)

The programmer can read the algorithm and know what needs to be done then convert that into the syntax of the relevant programming language.

An algorithm should focus on the logic needed to solve the problem and ignore all of the ancilliary detail. For example, if I was going to print the score for a player at the end of a game, in code it could be quite a few lines of instructions to select a font, set colours, set up images and other elements to be rendered to the screen and print the actual text for the score. In an algorithm I would simply say "Display score".

Some examples

Find the average of three numbers :

We could have combined lines 5 and 6 into one calculation but it often improves readability if we break it up into steps depending on the level of existing knowledge of the intended audience.

Convert degrees farenheit into degrees celsius :

Summary