Algorithms and Lazarus

Structural Elements: SEQUENCE

Sequence is the most obvious of skills in programming but can be the most difficult to master. Many times the large 'programming' task is insolvable because of the inability to see all of the little pieces that go together to make a solution.

It seems obvious to suggest that you have to get the steps in the right order (and we are all familiar with the consequences of mucking around with the order of a recipe). In programming this is most important. Programs are comprised of small tasks (or statements) and the order they are executed is important - you can't calculate the circumference before you have asked for the radius or defined the value for pi for example.

Sequence gets a little muddled when we enter the realm of event-drive programming as it is not obvious WHAT a user of your program is going to want to do. Well written event-driven programs allow the user to do what they want to do, when they are read to do it - this necessitates very careful planning and well-understood sequence. Some of the most obscure (and therefore difficult to de-bug) errors in commercial software are when unplanned combinations of events occur.

In simple terms, a sequence to change a flat tyre could be expressed as the following set of steps:

1. get gear out of boot;
2. loosen wheel nuts a little;
3. place jack under lifting point;
4. jack tyre off ground;
5. remove wheel nuts;
6. remove tyre;
7. put spare tyre on;
8. replace wheel nuts;
9. lower jack;
10. final tighten of wheel nuts;
11. put gear away;

This sequence is not fully developed and much is taken for granted. Some of the tasks are compound tasks (that is they actually contain a number of sub-tasks). The get gear out of boot step could actually be thought of more completely as:

begin

open boot;
get spare tyre;
get jack;
get tyre brace (the spannery thing);

end;

In the above example there are some added algorithmic elements if we want to get technical - the removal of wheel nuts is actually an iteration of the removal of a single nut (repeated as many times as there are nuts to remove). Using the jack could be seen as an iteration as you crank the handle and stop when the wheel is sufficiently high from the ground (are we there yet?).

Sequence in programs is facilitated by legal statements being executed in the correct order: do this then this then this then this. The order of the statements does matter.

Sequences can get complicated - a complex task can sometimes be further sub-divided (developed) into a nested sequence:

In Lazarus, sequences of statements are separated by semi-colons:

answer.caption := inttostr(2*pi*r);
r := 45;
pi := 22/7;

The sequence above is logically flawed as the answer is calculated before the values for the variables are defined. Although this code would compile correctly (no syntax errors) it would result in an incorrect answer. A logically better sequence would be:

r := 45;
pi := 22/7;
answer.caption := inttostr(2*pi*r);

Indeed, Lazarus has many built-ins and pi is one of them (the inbuilt value for pi is much more accurate than the calculated value of 22/7 which will be evaluated as a truncated real).

In an event-driven system, you sometimes have to cater for the user wanting to do things in a different order to that which you imagined. You might, for example have a screen similar to the following:

Logic would dictate that the user should enter a mark and then a total before they press the calculate button. Logic would also suggest that the user will not enter a 0 (zero) into the total box (as we all know dividing by zero is a fatal error).

Given this is an event-driven program, however, we cannot leave it to chance (if the user can muck something up they will). The event handler behind the calculate button must do a number of things:

check the mark is a valid number;
check the total is a valid number;
check the mark is <= the total;
calculate the percentage and display it;

This algorithm is complicated by the fact that there are a number of decisions that are necessary pre-conditions for the calculation to succeed - these are selections and are covered in the next section.

A much better solution would be to have the calculate button disabled (that is it is unable to be pressed) until the things inputted into the mark and total boxes are legal- this would also be a useful visual clue to the user that they have done the right thing (as opposed to your program unceremoniously crashing in their hands - never a good look).

Recognising sequence in an algorithm is as much common sense as it is experience. Once you begin to think algorithmically, large/complex programming tasks become sequences of smaller, easier to manage sub-tasks.