Chambers 20th Century Dictionary describes an algorithm as: "a rule for solving a mathematical problem in a finite number of steps". And in the Computing Dictionary

My view? Well, I think of an algorithm as a machine, comparable to an engine, or some device, for solving a problem. An example: the problem might be powering a motor car. There would be a host of different engine types: diesel, petrol, gas turbine, steam, electric. To me, they look like algorithms for the problem of propelling a car. I sometimes think of a bridge as an algorithm for crossing a gulf or river. There are many different kinds of bridges: suspension, girder, etc and each has its role and cost. Same with the car engine: different role and costs."Technically an algorithm must reach a result after a finite number of steps, thus ruling out brute force search methods for certain problems, though some might claim that brute force search was also a valid (generic) algorithm. The term is also used loosely for any sequence of actions (which may or may not terminate)."

In some sense I visualise algorithms in terms of cogs, wheels and cranks: a mechanical thing.

You have been using algorithms all the time, and probably weren't aware of it. You would be given an algorithm for long division, multiplication, addition and subtraction when in primary school. You were the computer, and you executed those algorithms. You benefit from algorithms every time you play some arcade game, with high performance graphics. There will be a host of algorithms for working out when two objects collide (in the shootemup games, or car chases), when you are past a given point, etc. Calculators use algorithms, to find logarithms, square roots, factorial, etc. There is an algorithm in my video camera, to reduce camera shake.

Algorithms aint programs, just as a recipe for steamed fish aint a meal (it just tells you how to steam the fish). I could describe an algorithm in English or in some "pseudo code" (something that looks like a very high level language, but we don't have a compiler for it). So, an algorithm aint necessarily a piece of code. An algorithm might be "on the shelf", in a book, and when you have a specific computational problem, you might be able to identify that problem as being an instance of (lets say) X, and we know that there is an algorithm for X. So we go and find it, and code it up.

And there are good and not so good algorithms. If you are implementing a solution to a given problem you might have a choice of algorithms. If you choose the wrong one you might get bad performance and the system will be unusable. You could get it right, and end up with a market leader!

There are loads of algorithms. There are algorithms for putting things in place, for locating something, for finding some configuration that is optimal (in some sense). There are conferences and journals devoted to algorithms, books, and web sites. There is a huge body of research in algorithms: trying to find better algorithms, and trying to better understand the behaviour of the algorithms that we already have. And I must confess, I do a bit myself.

The gentleman on the stamp is Abu Jafar Mohammed ibm Musa Al Khwarizmi, who first suggested a mechanical method for adding two numbers represented in the Hindiu numeral system (circa A.D. 800). And that is how we get the word algorithm (miss-pronounce Alquarizmi?) . I stole this picture from Donald Knuth's home page.

But there are algorithms much older than Abu Jafar Mohammed ibm Musa Al Khwarizmi. The mathematician Euclid (greek mathematician of 3d century BC Alexandria) is credited with amongst other things (i.e. The Elements) the description of a technique for finding the highest common factor (HCF) of two integers by:

dividing the larger by the smaller, then the smaller by the remainder of that first division, then the remainder of the first division by the remainder of the second, and so on until the process terminates with a remainder of zero.

It's important that you know about them, know that algorithms exist for certain problems so that you don't have to reinvent the wheel. It's important that you know something about algorithms, such as the cost of using them, so that you can make sound engineering decisions when you solve a problem. It is true that even though we get gains in performance from our systems as hardware performance increases, this improvement can frequently be insignificant compared to improvements brought about by algorithms. It's not unusual to see a problem solved millions of times quicker by one algorithm than another.

Well, it's about trees, and stacks, and lists, queues, deques, doubly linked lists, and heaps, graphs, digraphs, arrays, vectors; all those things. But those are just words (heaps, deque?) aren't they? Here's what the Computing Dictionary had to say about abstract data types:

**abstract data type**

(ADT) A type whose internal form is hidden behind a set
of access
functions. Objects of the type are created and inspected only by calls
to the access functions. This allows the implementation of the type to
be changed without requiring any changes outside the module
in which it is defined. Abstract data types are central to object-oriented
programming where every class
is an ADT. A classic example of an ADT is a stack
data type for which functions might be provided to create an empty stack,
to push
values onto a stack and to pop
values from a stack. (22 Feb 1995)

So, an abstract data type (adt) implements some property, but hides from the user (programmer) just how it is implemented. As an example, we might have an ADT for a set. We would then require methods to create a set, test for membership, union, intersection, set-difference, addition, and deletion. We give those to the user, and we implement it. We can implement the set ADT anyway we choose, so long as we provide the required functionality.

How we implement that functionality brings us to data structures. For
the set example above we might use an array or vector. This will have advantages
and disadvantages. We might use instead a linked
list, or a hash table. Each one of these representations, ways of *structuring
the data* will have advantages and disadvantages, such as speed and
space consumption. Again, if we make a bad choice of data structure we
might deliver an unusable system that is too slow or takes up so much space
that we can only work on small data sets. Get it right, and again we could
have a market leader!

For pretty much the same reason that algorithms are important. Data structures have costs and benefits. You want to know about these, so that when you make a design decision, it is an informed one, not just a guess or a hunch. Furthermore, when you make your choice you have an understanding of the consequences of that choice.

A computer scientist needs to know about, and understand, algorithms and data structures so that they can make sound engineering decisions, so that they are more than just a hacker producing systems with unpredictable behaviour.