Question

There are some crucial differences between “programs” and “algorithms.” What are they? Is every program an algorithm? Is every algorithm a program? How can you tell if you have a program? Can you just look at it and tell? How can you tell if you have an algorithm? Can you look at it and tell?

Answer 1

Answer:-

I'm going to give the same answer as I gave the previous time this question came up.

First, understand that there is no good formal definition of "algorithm" at the time of writing. The key word here is "formal".

However, there are smart people working on it.

What we know is that whatever an "algorithm" is, it sits somewhere between "mathematical function" and "computer program".

A mathematical function is formal notion of a mapping from inputs to outputs. So, for example, "sort" is a mapping between a sequence of orderable items and a sequence of orderable items of the same type, which maps each sequence to its ordered sequence. This function could be implemented using different algorithms (e.g. merge sort, heap sort). Each algorithm, in turn, could be implemented using different programs (even given the same programming language).

So the best handle that we have on what an "algorithm" is, is that it's some kind of equivalence class on programs, where two programs are equivalent if they do "essentially the same thing". Any two programs which implement the same algorithm must compute the same function, but the converse is not true.

Similarly, there is an equivalence class between algorithms, where two algorithms are equivalent if they compute the same mathematical function.

The hard part in all this is trying to capture what we mean by "essentially the same thing".

There are some obvious things that we should include. For example, two programs are essentially the same if they differ only by variable renamings. Most models of programming languages have native notions of "equivalence" (e.g. beta reduction and eta conversion in lambda calculus), so we should throw those in too.

Whatever equivalence relation we pick, this gives us some structure. Algorithms form a category by virtue of the fact that they are the quotient category of programs. Some interesting equivalence relations are known to give rise to interesting categorical structures; for example, the category of primitive recursive algorithms is a universal object in the category of categories. Whenever you see interesting structure like that, you know that this line of enquiry will probably be useful.

Ultimately, the difference is one of perspective. A program is a program: a sequence of statements in some language, perhaps a programming language or machine-level instructions. Algorithms are usually described at a higher level than machine instructions or programming language statements but just how high a level is rather flexible. For example, in some circumstances, "Sort the array, then look at the kkth element" is a perfectly good description of an algorithm for finding the kkth largest object in an array; in other circumstances, you might want to specify much more detail about how the sorting takes place.

As you say, an algorithm is something like "a process or set of rules to be followed in calculations or other problem-solving operations, especially by a computer." So, literally speaking, every program is an algorithm. Usually, though, we speak of programs implementing algorithms. Usually, when describing an algorithm, we avoid the low-level detail of exactly how things are implemented, assuming that a competent programmer would be able to implement it in the langauge of their choosing.

• An algorithm is a systematic approach to solving a specific problem.

• A program is a set of instructions for a computer to follow.

A program therefore does not even need to solve a problem. I'm sure we can all think of several programs that have caused more problems than they've solved. A program can be an implementation of many algorithms, or an algorithm can be implemented by patching together many programs. A program can even contain no algorithms. For example, the empty program which simply exits, or perhaps even a Hello World, could be considered a program with no algorithm.

Since an algorithm solves a specific problem, it is focused on a specific whole concept. An algorithm therefore provides abstract steps for processing one set of related information into a different set of derived information. A program does not require its constituents to be at all conceptually related. For example, a program can have an easter egg, but a thing properly called an algorithm should not. You can have a virus or trojan lurking in a program, but not in an algorithm. The closest an algorithm can get to this would be something like a backdoor in an encryption algorithm, where the planned flaw is part of the information relationship established by the algorithm.

And lastly, a program, as it is short for a computer program, tautologically requires a computer. An algorithm does not. If I systematically separate the shirts, pants, and socks from my laundry before putting them away, this is an algorithm. It deals with related inputs and outputs, can be described in a flow chart, and has calculable consequences in terms of efficiency (for example, the number of clothing pieces which must be compared to find matching socks).