Algorithm

In mathematics, computer science, and related subjects, an algorithm (derived from the name of mathematician al-Khwārizmī and transformed to match the greek "arithmos"-number) is an effective method for solving a problem expressed as a finite sequence of steps. Algorithms are used for calculation, data processing, and many other fields. (In more advanced or abstract settings, the instructions do not necessarily constitute a finite sequence, and even not necessarily a sequence; see, e.g., "nondeterministic algorithm".)
Each algorithm is a list of well-defined instructions for completing a task. Starting from an initial state, the instructions describe a computation that proceeds through a well-defined series of successive states, eventually terminating in a final ending state. The transition from one state to the next is not necessarily deterministic; some algorithms, known as randomized algorithms, incorporate randomness.
A partial formalization of the concept began with attempts to solve the Entscheidungsproblem (the "decision problem") posed by David Hilbert in 1928. Subsequent formalizations were framed as attempts to define "effective calculability" or "effective method"; those formalizations included the Gödel–Herbrand–Kleene recursive functions of 1930, 1934 and 1935, Alonzo Church's lambda calculus of 1936, Emil Post's "Formulation 1" of 1936, and Alan Turing's Turing machines of 1936–7 and 1939.
The adjective "continuous" when applied to the word "algorithm" can mean:
An algorithm operating on data that represents continuous quantities, even though this data is represented by discrete approximations – such algorithms are studied in numerical analysis; or
An algorithm in the form of a differential equation that operates continuously on the data, running on an analog computer.

Why algorithms are necessary: an informal definition
For a detailed presentation of the various points of view around the definition of "algorithm" see Algorithm characterizations. For examples of simple addition algorithms specified in the detailed manner described in Algorithm characterizations, see Algorithm examples.
While there is no generally accepted formal definition of "algorithm," an informal definition could be "a process that performs some sequence of operations." For some people, a program is only an algorithm if it stops eventually. For others, a program is only an algorithm if it stops before a given number of calculation steps.
A prototypical example of an algorithm is Euclid's algorithm to determine the maximum common divisor of two integers.
We can derive clues to the issues involved and an informal meaning of the word from the following quotation from Boolos & Jeffrey (1974, 1999) (boldface added):
No human being can write fast enough, or long enough, or small enough† ( †"smaller and smaller without limit ...you'd be trying to write on molecules, on atoms, on electrons") to list all members of an enumerably infinite set by writing out their names, one after another, in some notation. But humans can do something equally useful, in the case of certain enumerably infinite sets: They can give explicit instructions for determining the nth member of the set, for arbitrary finite n. Such instructions are to be given quite explicitly, in a form in which they could be followed by a computing machine, or by a human who is capable of carrying out only very elementary operations on symbols
The term "enumerably infinite" means "countable using integers perhaps extending to infinity." Thus Boolos and Jeffrey are saying that an algorithm implies instructions for a process that "creates" output integers from an arbitrary "input" integer or integers that, in theory, can be chosen from 0 to infinity. Thus we might expect an algorithm to be an algebraic equation such as y = m + n — two arbitrary "input variables" m and n that produce an output y. As we see in Algorithm characterizations — the word algorithm implies much more than this, something on the order of (for our addition example):
Precise instructions (in language understood by "the computer") for a "fast, efficient, good" process that specifies the "moves" of "the computer" (machine or human, equipped with the necessary internally contained information and capabilities) to find, decode, and then munch arbitrary input integers/symbols m and n, symbols + and = ... and (reliably, correctly, "effectively") produce, in a "reasonable" time, output-integer y at a specified place and in a specified format.
The concept of algorithm is also used to define the notion of decidability. That notion is central for explaining how formal systems come into being starting from a small set of axioms and rules. In logic, the time that an algorithm requires to complete cannot be measured, as it is not apparently related with our customary physical dimension. From such uncertainties, that characterize ongoing work, stems the unavailability of a definition of algorithm that suits both concrete (in some sense) and abstract usage of the term.

Formalization
Algorithms are essential to the way computers process information. Many computer programs contain algorithms that specify the specific instructions a computer should perform (in a specific order) to carry out a specified task, such as calculating employees' paychecks or printing students' report cards. Thus, an algorithm can be considered to be any sequence of operations that can be simulated by a Turing-complete system. Authors who assert this thesis include Minsky (1967), Savage (1987) and Gurevich (2000):
Minsky: "But we will also maintain, with Turing . . . that any procedure which could "naturally" be called effective, can in fact be realized by a (simple) machine. Although this may seem extreme, the arguments . . . in its favor are hard to refute".
Gurevich: "...Turing's informal argument in favor of his thesis justifies a stronger thesis: every algorithm can be simulated by a Turing machine ... according to Savage (1987), an algorithm is a computational process defined by a Turing machine".
Typically, when an algorithm is associated with processing information, data is read from an input source, written to an output device, and/or stored for further processing. Stored data is regarded as part of the internal state of the entity performing the algorithm. In practice, the state is stored in one or more data structures.
For some such computational process, the algorithm must be rigorously defined: specified in the way it applies in all possible circumstances that could arise. That is, any conditional steps must be systematically dealt with, case-by-case; the criteria for each case must be clear (and computable).
Because an algorithm is a precise list of precise steps, the order of computation will always be critical to the functioning of the algorithm. Instructions are usually assumed to be listed explicitly, and are described as starting "from the top" and going "down to the bottom", an idea that is described more formally by flow of control.
So far, this discussion of the formalization of an algorithm has assumed the premises of imperative programming. This is the most common conception, and it attempts to describe a task in discrete, "mechanical" means. Unique to this conception of formalized algorithms is the assignment operation, setting the value of a variable. It derives from the intuition of "memory" as a scratchpad. There is an example below of such an assignment.
For some alternate conceptions of what constitutes an algorithm see functional programming and logic programming .

Termination
Some writers restrict the definition of algorithm to procedures that eventually finish. In such a category Kleene places the "decision procedure or decision method or algorithm for the question". Others, including Kleene, include procedures that could run forever without stopping; such a procedure has been called a "computational method" or "calculation procedure or algorithm (and hence a calculation problem) in relation to a general question which requires for an answer, not yes or no, but the exhibiting of some object".
Minsky makes the pertinent observation, in regards to determining whether an algorithm will eventually terminate (from a particular starting state):
But if the length of the process isn't known in advance, then "trying" it may not be decisive, because if the process does go on forever—then at no time will we ever be sure of the answer.
As it happens, no other method can do any better, as was shown by Alan Turing with his celebrated result on the undecidability of the so-called halting problem. There is no algorithmic procedure for determining whether or not arbitrary algorithms terminate from given starting states. The analysis of algorithms for their likelihood of termination is called termination analysis.
See the examples of (im-)"proper" subtraction at partial function for more about what can happen when an algorithm fails for certain of its input numbers—e.g., (i) non-termination, (ii) production of "junk" (output in the wrong format to be considered a number) or no number(s) at all (halt ends the computation with no output), (iii) wrong number(s), or (iv) a combination of these. Kleene proposed that the production of "junk" or failure to produce a number is solved by having the algorithm detect these instances and produce e.g., an error message (he suggested "0"), or preferably, force the algorithm into an endless loop. Davis (1958) does this to his subtraction algorithm—he fixes his algorithm in a second example so that it is proper subtraction and it terminates. Along with the logical outcomes "true" and "false" Kleene (1952) also proposes the use of a third logical symbol "u" — undecided — thus an algorithm will always produce something when confronted with a "proposition". The problem of wrong answers must be solved with an independent "proof" of the algorithm e.g., using induction:
We normally require auxiliary evidence for this [that the algorithm correctly defines a mu recursive function], e.g, in the form of an inductive proof that, for each argument value, the computation terminates with a unique value.

Expressing algorithms
Algorithms can be expressed in many kinds of notation, including natural languages, pseudocode, flowcharts, programming languages or control tables (processed by interpreters). Natural language expressions of algorithms tend to be verbose and ambiguous, and are rarely used for complex or technical algorithms. Pseudocode, flowcharts and control tables are structured ways to express algorithms that avoid many of the ambiguities common in natural language statements, while remaining independent of a particular implementation language. Programming languages are primarily intended for expressing algorithms in a form that can be executed by a computer, but are often used as a way to define or document algorithms.
There is a wide variety of representations possible and one can express a given Turing machine program as a sequence of machine tables (see more at finite state machine and state transition table), as flowcharts (see more at state diagram), or as a form of rudimentary machine code or assembly code called "sets of quadruples" (see more at Turing machine).
Sometimes it is helpful in the description of an algorithm to supplement small "flow charts" (state diagrams) with natural-language and/or arithmetic expressions written inside "block diagrams" to summarize what the "flow charts" are accomplishing.
Representations of algorithms are generally classed into three accepted levels of Turing machine description:
1 High-level description:
"...prose to describe an algorithm, ignoring the implementation details. At this level we do not need to mention how the machine manages its tape or head."
2 Implementation description:
"...prose used to define the way the Turing machine uses its head and the way that it stores data on its tape. At this level we do not give details of states or transition function."
3 Formal description:
Most detailed, "lowest level", gives the Turing machine's "state table".
For an example of the simple algorithm "Add m+n" described in all three levels see Algorithm examples.

Computer algorithms
In computer systems, an algorithm is basically an instance of logic written in software by software developers to be effective for the intended "target" computer(s), in order for the software on the target machines to do something. For instance, if a person is writing software that is supposed to print out a PDF document located at the operating system folder "/My Documents" at computer drive "D:" every Friday at 10 pm, they will write an algorithm that specifies the following actions: "If today's date (computer time) is 'Friday,' open the document at 'D:/My Documents' and call the 'print' function". While this simple algorithm does not look into whether the printer has enough paper or whether the document has been moved into a different location, one can make this algorithm more robust and anticipate these problems by rewriting it as a formal CASE statement[15] or as a (carefully crafted) sequence of IF-THEN-ELSE statements. For example the CASE statement might appear as follows (there are other possibilities):
CASE 1: IF today's date is NOT Friday THEN exit this CASE instruction ELSE
CASE 2: IF today's date is Friday AND the document is located at 'D:/My Documents' AND there is paper in the printer THEN print the document (and exit this CASE instruction) ELSE
CASE 3: IF today's date is Friday AND the document is NOT located at 'D:/My Documents' THEN display 'document not found' error message (and exit this CASE instruction) ELSE
CASE 4: IF today's date is Friday AND the document is located at 'D:/My Documents' AND there is NO paper in the printer THEN (i) display 'out of paper' error message and (ii) exit.
Note that CASE 3 includes two possibilities: (i) the document is NOT located at 'D:/My Documents' AND there's paper in the printer OR (ii) the document is NOT located at 'D:/My Documents' AND there's NO paper in the printer.
The sequence of IF-THEN-ELSE tests might look like this:
TEST 1: IF today's date is NOT Friday THEN done ELSE TEST 2:
TEST 2: IF the document is NOT located at 'D:/My Documents' THEN display 'document not found' error message ELSE TEST 3:
TEST 3: IF there is NO paper in the printer THEN display 'out of paper' error message ELSE print the document.
These examples' logic grants precedence to the instance of "NO document at 'D:/My Documents' ". Also observe that in a well-crafted CASE statement or sequence of IF-THEN-ELSE statements the number of distinct actions—4 in these examples: do nothing, print the document, display 'document not found', display 'out of paper' – equals the number of cases.
Given unlimited memory, a computational machine with the ability to execute either a set of CASE statements or a sequence of IF-THEN-ELSE statements is Turing complete. Therefore, anything that is computable can be computed by this machine. This form of algorithm is fundamental to computer programming in all its forms (see more at McCarthy formalism).

Implementation
Most algorithms are intended to be implemented as computer programs. However, algorithms are also implemented by other means, such as in a biological neural network (for example, the human brain implementing arithmetic or an insect looking for food), in an electrical circuit, or in a mechanical device.

Super Contra (Game)

Super Contra (スーパー魂斗羅?) is the 1988 arcade sequel to Konami's Contra, released during the previous year. Unlike the original Contra, the arcade version of Super Contra was distributed in Europe with its original title and cooperative 2-player feature intact. A home version of Super Contra was released for the Nintendo Entertainment System in 1990, which was localized as Super C in North America and Probotector II: Return of the Evil Forces in the PAL region.
In Super Contra, the alien forces from the original game have taken over a base in an undisclosed region of South America and the players once again assume the roles of protagonists Bill Rizer and Lance Bean to counter the invasion.

Plot
Set a year after the events of the original Contra, Bill and Lance, the heroes from the previous game, are sent on a second mission. This time, the alien forces from the previous game have taken over an allied military base, possessing most of its troops. Bill and Lance must not only fight against their former comrade-in-arms, but also a new mutated form of the same alien creatures they fought during their previous mission.

Gameplay
The arcade version of Super Contra plays essentially the same as its predecessor. The main difference was in its versatility. While the original Contra had two different perspectives (a side-view and a 3D view), Super Contra replaces the 3D stages with top-view stages similar to other overhead shooters at the time such as Commando and Ikari Warriors. Additionally, the side-view stages of Super Contra featured inclined surfaces, which were not in the original Contra. In the arcade version, the player can now control the height of their jump; by holding the joystick up and pressing the jump button will allow for a higher jump; likewise the player can perform low jumps as well by holding down-right or down-left while pressing the jump button. The arcade version is composed of five stages which spans a military base, a jungle and an alien lair. Stage 1, 3, 4 are side-view stages, while Stage 2 and 5 are top-view stages.
Like in the original Contra, the player can upgrade their default gun into one of the following four special weapons: the Machine Gun, the Spread Gun, a Laser Gun, and a Bomb Gun. Unlike the other games in the series, the power-up icons are now represented by the actual weapons wielded by the character instead of the traditional letter-based falcon icons. The player can upgrade their weapon by picking it up twice in a row. In the top-view stages, the player can also pick up and carry a "Mega Shell", which can be launched by pressing the jump button, killing all on-screen enemies.

Nintendo Entertainment System
A home version of Super Contra was released for the Nintendo Entertainment System on February 2, 1990 in Japan and on April 1990 in North America, where it was retitled Super C. A PAL version of the NES game, titled Probotector II: Return of the Evil Forces, was released in 1992.
The gameplay and graphics of Super C are similar to the first NES game, but replaces the pseudo-3D stages with overhead stages much like its arcade counterpart. There are three stages unique to the NES version: a high-tech base, a mountain and an alien nest, all vertical-scrolling stages. The order of the latter stages and bosses are also slightly different, with new bosses featured in this version (including a new final boss). The NES version uses the same power-ups as the original NES game, but changes the function of the "fire gun" power-up from a gun that fires small fireballs that travels corkscrew pattern to a large projectile that spreads fire after hitting its target. The player can charge this gun by holding down the B button and then releasing it, shooting an even larger projectile that passes through most fodder enemies and causes an even bigger explosion when it hits a large target. The Rapid Bullets, Barrier and Special power-ups from the first NES game are also included in this game.
The Konami Code from the original Contra was not included in this game. A different code was added which gives out thirty lives in the Famicom version and ten lives in the NES versions. Like in the Famicom version of Contra, the Japanese Super Contra has a stage select code that was removed from its NES counterparts. All three versions contain a sound test mode. Like the first NES game, Probotector II (the PAL version), replaced the main characters and some of the enemies with robots.

Alan Turing (Figure)

Alan Mathison Turing, OBE, FRS (pronounced /ˈtjʊərɪŋ/ TEWR-ing; 23 June 1912 – 7 June 1954), was an English mathematician, logician, cryptanalyst and computer scientist. He was highly influential in the development of computer science, providing a formalization of the concept of the algorithm and computation with the Turing machine, which played a significant role in the creation of the modern computer.

During the Second World War, Turing worked for the Government Code and Cypher School at Bletchley Park, Britain's codebreaking centre. For a time he was head of Hut 8, the section responsible for German naval cryptanalysis. He devised a number of techniques for breaking German ciphers, including the method of the bombe, an electromechanical machine that could find settings for the Enigma machine. After the war he worked at the National Physical Laboratory, where he created one of the first designs for a stored-program computer, the ACE.
Towards the end of his life Turing became interested in mathematical biology. He wrote a paper on the chemical basis of morphogenesis, and he predicted oscillating chemical reactions such as the Belousov–Zhabotinsky reaction, which were first observed in the 1960s.
Turing's homosexuality resulted in a criminal prosecution in 1952 — homosexual acts were illegal in the United Kingdom at that time — and he accepted treatment with female hormones (chemical castration) as an alternative to prison. He died in 1954, several weeks before his 42nd birthday, from cyanide poisoning. An inquest determined it was suicide; his mother and some others believed his death was accidental. On 10 September 2009, following an Internet campaign, then-British Prime Minister Gordon Brown made an official public apology on behalf of the British government for the way in which Turing was treated after the war.

Battle City (Game)

Battle City (known as Tank in some regions) is a multi-directional shooter video game for the Nintendo Family Computer produced and published in 1985 by Namco. The game was later released for the Game Boy and was included in the Japanese version of Star Fox: Assault. It is a port of the arcade game Tank Battalion with additional features (including two player simultaneous play, and an edit feature, both explained later). There was also a rendition for Nintendo's Vs. System arcade cabinets.
The player, controlling a tank, must destroy enemy tanks in each level, which enter the playfield from the top of the screen. The enemy tanks attempt to destroy the player's base (represented on the map as a bird, eagle or Phoenix), as well as the human tank itself. A level is completed when the player destroys all 20 enemy tanks, but the game ends if the player's base is destroyed or the player loses all available lives.

Gameplay
Battle City contains 35 different stages that are 13 units wide by 13 units high. Each map contains different types of terrain and obstacles. Examples include brick walls that can be destroyed by having either the player's tank or an enemy tank shoot at them, steel walls that can be destroyed by the player if he has collected three or more power-up stars, bushes that hide tanks under them, ice fields that make it difficult to control tank and pools of water which cannot be crossed by tanks. There are four progressively harder types of enemy tanks. The game becomes more challenging in later levels, as enemy tanks may act as decoys to lure players away from their base so that another tank can destroy it. In addition, flashing tanks could be destroyed for power-ups. There are several types of power-ups: tank symbol gives an extra life, star improves player's tank (having one star make shots faster, having two stars allow two simultaneous shots, having three stars allow the player to destroy steel), bomb destroys all visible enemy tanks, clock freezes all enemy tanks for a period of time, shovel adds steel walls around the base for a period of time and shield makes player's tank invulnerable to attack for a period of time.

Battle City was also one of the first games to allow two players to play simultaneously. Both players have to defend the base together, and if one player shoots the other, the friendly fire victim would freeze for a while (but can still shoot).
Battle City was one of the first NES games to allow players access to an edit mode where they could create custom levels. However, custom levels cannot be saved.
The Game Boy version is more challenging, as the screen is too small to display the whole map and only enough to display one part of it. Players often would have to scroll to different parts of the map to view them and everything in them. As a result, defending the base is even more difficult, while the player is occupied with enemies on one part of the map, other enemies could sneak past the player and right to the base, destroying it without fear of retaliation and by complete surprise. A radar is in the Game Boy version, but not in the NES version.

Plot
As with many games released during the first wave of NES titles, Battle City did not have a proper storyline or ending. After the player completed stage 35, the game would go back to stage 1 and continue, although enemy tank pattern is changed now and remains the same for the rest of the game.
In the Game Boy version, however, you would have to go up to level 50, and then start again.

Digger (Game)

Digger is a Canadian computer game released by Windmill Software in 1983, popular in the era of the IBM PC with a CGA graphics card and monitor. It generally requires a genuine CGA card and runs too fast on computers faster than the original IBM PC 4.77 MHz. In an exception to the CGA requirement, it is possible to use a CGA emulator to run Digger on a Hercules graphics card.

Gameplay
Many features of Digger are similar to those in the arcade games Mr. Do and Dig Dug. As in those games, the player is placed in an underground maze, and can dig horizontal and vertical tunnels through it. At least one tunnel already exists at the start of play. At various points on the board are emeralds (usually in clusters) and bags of gold. Monsters (initially in the 'nobbin' form) appear at the top right-hand corner. If earth is excavated from under a gold bag, then the bag will wobble for a few seconds and then drop; if it falls more than one row, it will break open after falling, releasing gold which can be collected. Bags can also be pushed left or right into vertical paths, with similar results. Falling bags will squash monsters that they fall on, but they will also squash the digger. The digger also has a weapon, which will fire in a straight line, but takes several seconds to recharge (taking longer as the levels go higher).
Monsters will sometimes change from the 'nobbin' form to the 'hobbin' form, more frequently on higher levels. Hobbins also have the power to excavate, and can destroy emeralds and gold bags while so doing.
When a monster is killed, another will appear at the top right-hand corner of the screen, up to a maximum number which depends on the level. Once all the monsters for the level have been created, a cherry appears in their place. If the digger collects this, bonus mode is entered, and for about fifteen seconds (which decreases as the game level gets higher) the digger is able to eat the monsters. Accordingly, the monsters now run away from the digger rather than towards it.
A level ends when all the emeralds are gone or all the monsters have been killed.

Scoring
The player scores 25 points for collecting an emerald, with a bonus of 250 if eight are collected in immediate succession. Killing a monster by shooting it or dropping a gold bag on it scores 250 points; in bonus mode, the player scores 200 points for the first monster eaten, 400 for the second, and so on, doubling each time. Collecting gold earns 500 points, and entering bonus mode 1,000. A new life is awarded at each multiple of 20,000 points.

Development
Digger was developed by Rob Sleath, the primary developer of Windmill games in 1983. In 1984, Digger was converted to run on IBM PCjr and IBM JX, the Japanese version. The last original version was released for a Canadian computer Hyperion running at 6 MHz.

Music
During normal game play the Popcorn theme is used as background music. In bonus mode the Overture to Wilhelm Tell by Gioachino Rossini plays. If the player dies, a rendition of Frédéric Chopin's Piano Sonata No. 2 in B flat Minor (also known as The Funeral March) is played, accompanied with a picture of a RIP gravestone.