Session3

Software Development Life Cycle (SDLC)
Summary: As in any other engineering discipline, software
engineering also has some structured models for software
development. This document will provide you with a
generic overview about different software development
methodologies adopted by contemporary software firms.
Read on to know more about the Software Development
Life Cycle (SDLC) in detail.
Curtain Raiser
Like any other set of engineering products, software products are also
oriented towards the customer. It is either market driven or it drives the
market. Customer Satisfaction was the buzzword of the 80's. Customer
Delight is today's buzzword and Customer Ecstasy is the buzzword of the
new millennium. Products that are not customer or user friendly have no
place in the market although they are engineered using the best
technology. The interface of the product is as crucial as the internal
technology of the product.
Market Research
A market study is made to identify a potential customer's need. This process
is also known as market research. Here, the already existing need and the
possible and potential needs that are available in a segment of the society
are studied carefully. The market study is done based on a lot of
assumptions. Assumptions are the crucial factors in the development or
inception of a product's development. Unrealistic assumptions can cause a
nosedive in the entire venture. Though assumptions are abstract, there
should be a move to develop tangible assumptions to come up with a
successful product.
Research and Development
Once the Market Research is carried out, the customer's need is given to
the Research & Development division (R&D) to conceptualize a cost-
effective system that could potentially solve the customer's needs in a
manner that is better than the one adopted by the competitors at present.
Once the conceptual system is developed and tested in a hypothetical
environment, the development team takes control of it. The development
team adopts one of the software development methodologies that is
given below, develops the proposed system, and gives it to the customer.
The Sales & Marketing division starts selling the software to the available
customers and simultaneously works to develop a niche segment that
could potentially buy the software. In addition, the division also passes the
feedback from the customers to the developers and the R&D division to

make possible value additions to the product.
While developing a software, the company outsources the non-core
activities to other companies who specialize in those activities. This
accelerates the software development process largely. Some companies
work on tie-ups to bring out a highly matured product in a short period.
Popular Software Development Models
The following are some basic popular models that are adopted by many
software development firms
A. System Development Life Cycle (SDLC) Model
B. Prototyping Model
C. Rapid Application Development Model
D. Component Assembly Model
A. System Development Life Cycle (SDLC) Model
This is also known as Classic Life Cycle Model (or) Linear Sequential Model
(or) Waterfall Method. This model has the following activities.
1. System/Information Engineering and Modeling
As software is always of a large system (or business), work begins by
establishing the requirements for all system elements and then allocating
some subset of these requirements to software. This system view is
essential when the software must interface with other elements such as
hardware, people and other resources. System is the basic and very critical
requirement for the existence of software in any entity. So if the system is
not in place, the system should be engineered and put in place. In some
cases, to extract the maximum output, the system should be re-engineered
and spruced up. Once the ideal system is engineered or tuned, the
development team studies the software requirement for the system.
2. Software Requirement Analysis
This process is also known as feasibility study. In this phase, the
development team visits the customer and studies their system. They
investigate the need for possible software automation in the given system.
By the end of the feasibility study, the team furnishes a document that holds
the different specific recommendations for the candidate system. It also
includes the personnel assignments, costs, project schedule, target dates
etc.... The requirement gathering process is intensified and focussed
specially on software. To understand the nature of the program(s) to be built,
the system engineer or "Analyst" must understand the information domain
for the software, as well as required function, behavior, performance and
interfacing. The essential purpose of this phase is to find the need and to
define the problem that needs to be solved .

3. System Analysis and Design
In this phase, the software development process, the software's overall
structure and its nuances are defined. In terms of the client/server
technology, the number of tiers needed for the package architecture, the
database design, the data structure design etc... are all defined in this
phase. A software development model is thus created. Analysis and
Design are very crucial in the whole development cycle. Any glitch in the
design phase could be very expensive to solve in the later stage of the
software development. Much care is taken during this phase. The logical
system of the product is developed in this phase.
4. Code Generation
The design must be translated into a machine-readable form. The code
generation step performs this task. If the design is performed in a detailed
manner, code generation can be accomplished without much complication.
Programming tools like compilers, interpreters, debuggers etc... are used
to generate the code. Different high level programming languages like C, C+
+, Pascal, Java are used for coding. With respect to the type of application,
the right programming language is chosen.
5. Testing
Once the code is generated, the software program testing begins. Different
testing methodologies are available to unravel the bugs that were committed
during the previous phases. Different testing tools and methodologies are
already available. Some companies build their own testing tools that are
tailor made for their own development operations.
6. Maintenance
The software will definitely undergo change once it is delivered to the
customer. There can be many reasons for this change to occur. Change
could happen because of some unexpected input values into the system. In
addition, the changes in the system could directly affect the software
operations. The software should be developed to accommodate changes
that could happen during the post implementation period.
Back to top
B. Prototyping Model
This is a cyclic version of the linear model. In this model, once the
requirement analysis is done and the design for a prototype is made, the
development process gets started. Once the prototype is created, it is given
to the customer for evaluation. The customer tests the package and gives
his/her feed back to the developer who refines the product according to the
customer's exact expectation. After a finite number of iterations, the final
software package is given to the customer. In this methodology, the software
is evolved as a result of periodic shuttling of information between the
customer and developer. This is the most popular development model in

the contemporary IT industry. Most of the successful software products have
been developed using this model - as it is very difficult (even for a whiz kid!)
to comprehend all the requirements of a customer in one shot. There are
many variations of this model skewed with respect to the project
management styles of the companies. New versions of a software product
evolve as a result of prototyping.
Back to top
C. Rapid Application Development (RAD) Model
The RAD modelis a linear sequential software development process that
emphasizes an extremely short development cycle. The RAD model is a
"high speed" adaptation of the linear sequential model in which rapid
development is achieved by using a component-based construction
approach. Used primarily for information systems applications, the RAD
approach encompasses the following phases:
1. Business modeling
The information flow among business functions is modeled in a way that
answers the following questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?
2. Data modeling
The information flow defined as part of the business modeling phase is
refined into a set of data objects that are needed to support the business.
The characteristic (called attributes) of each object is identified and the
relationships between these objects are defined.
3. Process modeling
The data objects defined in the data-modeling phase are transformed to
achieve the information flow necessary to implement a business function.
Processing the descriptions are created for adding, modifying, deleting, or
retrieving a data object.
4. Application generation
The RAD model assumes the use of the RAD tools like VB, VC++, Delphi
etc... rather than creating software using conventional third generation
programming languages. The RAD model works to reuse existing program
components (when possible) or create reusable components (when
necessary). In all cases, automated tools are used to facilitate construction
of the software.

5. Testing and turnover
Since the RAD process emphasizes reuse, many of the program
components have already been tested. This minimizes the testing and
development time.
Back to top
D. Component Assembly Model
Object technologies provide the technical framework for a component-based
process model for software engineering. The object oriented paradigm
emphasizes the creation of classes that encapsulate both data and the
algorithm that are used to manipulate the data. If properly designed and
implemented, object oriented classes are reusable across different
applicationsand computer based system architectures. Component
Assembly Model leads to software reusability. The integration/assembly of
the already existing software components accelerate the development
process. Nowadays many component libraries are available on the Internet.
If the right components are chosen, the integration aspect is made much
simpler.
Back to top
Conclusion
All these different software development models have their own advantages
and disadvantages. Nevertheless, in the contemporary commercial software
evelopment world, the fusion of all these methodologies is incorporated.
Timing is very crucial in software development. If a delay happens in the
development phase, the market could be taken over by the competitor. Also
if a 'bug' filled product is launched in a short period of time (quicker than the
competitors), it may affect the reputation of the company. So, there should
be a tradeoff between the development time and the quality of the product.
Customers don't expect a bug free product but they expect a user-friendly
product. That results in Customer Ecstasy!
Systems Development Life Cycle
From Wikipedia, the free encyclopedia
Jump to: navigation, search
This list may require cleanup to meet Wikipedia's quality standards.
Please help improve this list. It may be poorly defined, unverified or indiscriminate.
This article or section is in need of attention from an expert on the subject.

Please help recruit one or improve this article yourself. See the talk page for details.
Please consider using {{Expert-subject}} to associate this request with a WikiProject
Systems Development Life Cycle (SDLC) or sometimes just (SLC) is defined by the
U.S. Department of Justice (DoJ) as a software development process, although it is also a
distinct process independent of software or other information technology considerations.
It is used by a systems analyst to develop an information system, including requirements,
validation, training, and user ownership through investigation, analysis, design,
implementation, and maintenance. SDLC is also known as information systems
development or application development. An SDLC should result in a high quality
system that meets or exceeds customer expectations, within time and cost estimates,
works effectively and efficiently in the current and planned information technology
infrastructure, and is cheap to maintain and cost-effective to enhance. SDLC is a
systematic approach to problem solving and is composed of several phases, each
comprised of multiple steps:
• The Software concept - identifies and defines a need for the new system
• A requirements analysis - analyzes the information needs of the end users
• The architectural design - creates a blueprint for the design with the necessary
specifications for the hardware, software, people and data resources
• Coding and debugging - creates and programs the final system
• System testing - evaluates the system's actual functionality in relation to expected
or intended functionality.
1. Implemen
tation
2. Testi
ng
3. Evaluati
on
or
1. Feasibilit
y Study
2. Anal
ysis
3. Design
4. Developm
ent
5. Implement
ation
6. Maintenan
ce
or
1. Feasibilit
y Study
2. Anal
ysis
3. Design
4. Implement
ation
5. Maintenan
ce
or
1. Feasibilit
y Study
2. Anal
ysis
3. Design
4. Developm
ent
5. Testing
6. Implement
ation
7. Mainten
ance
or
1. Analysis
(including
Feasibility
Study)
2. Desig
n
3. Develop
ment
4. Implement
ation
5. Evaluation or

1. Feasibilit
y Study
2. Anal
ysis
3. Design
4. Implement
ation
5. Testing 6. Evaluation
7. Mainten
ance
The last row represents the most commonly used Life Cycle steps (used also in AQA
module exams).
Contents
[hide]
• 1 The 'Systems Life Cycle' (UK Version)
• 2 Systems Development Life Cycle: Building the System
o 2.1 Insourcing
o 2.2 Selfsourcing
o 2.3 Prototyping
o 2.4 Outsourcing
• 3 References
• 4 See also
• 5 External links
[edit] The 'Systems Life Cycle' (UK Version)
The SDLC is referred to as the Systems Life Cycle (SLC) in the United Kingdom,
whereby the following names are used for each stage:
1. Terms Of Reference — the management will decide what capabilities and
objectives they wish the new system to incorporate;
2. Feasibility Study — asks whether the managements' concept of their desired new
system is actually an achievable, realistic goal, in-terms of money, time and end
result difference to the original system. Often, it may be decided to simply update
an existing system, rather than to completely replace one;
3. Fact Finding and Recording — how is the current system used? Often
questionnaires are used here, but also just monitoring (watching) the staff to see
how they work is better, as people will often be reluctant to be entirely honest
through embarrassment about the parts of the existing system they have trouble
with and find difficult if merely asked;
4. Analysis — free from any cost or unrealistic constraints, this stage lets minds run
wild as 'wonder systems' can be thought-up, though all must incorporate
everything asked for by the management in the Terms Of Reference section;
5. Design — designers will produce one or more 'models' of what they see a system
eventually looking like, with ideas from the analysis section either used or
discarded. A document will be produced with a description of the system, but

nothing is specific — they might say 'touchscreen' or 'GUI operating system', but
not mention any specific brands;
6. System Specification — having generically decided on which software packages
to use and hardware to incorporate, you now have to be very specific, choosing
exact models, brands and suppliers for each software application and hardware
device;
7. Implementation and Review — set-up and install the new system (including
writing any custom (bespoke) code required), train staff to use it and then monitor
how it operates for initial problems, and then regularly maintain thereafter.
During this stage, any old system that was in-use will usually be discarded once
the new one has proved it is reliable and as usable.
8. Use - obviously the system needs to actually be used by somebody, otherwise the
above process would be completely useless.
9. Close - the last step in a system's life cycle is its end, which is most often
forgotten when you design the system. The system can be closed, it can be
migrated to another (more modern platform) or it's data can be migrated into a
replacing system.
[edit] Systems Development Life Cycle: Building the
System
All methods undertake the seven steps listed under insourcing to different degrees:
[edit] Insourcing
Insourcing is defined as having IT specialists within an organization to build the
organization’s system by
• Planning – establishing the plans for creating an information system by
o Defining the system to be developed – based on the systems prioritized
according to the organization’s critical success factor (CSF), a system
must be identified and chosen
o the project scope – a high level of system requirements must be defined
and put into a project scope document
o Developing the project plan - – all details from tasks to be completed, who
completed them and when they were completed must be formalized
o Managing and monitoring the project plan – this allows the organization to
stay on track, creating project milestones and feature creeps which allow
you to add to the initial plan
• Analysis – the users and IT specialists collaborate to collect, comprehend, and
logistically formalize business requirements by
o Gathering the business requirements' – IT specialists and knowledge
workers collaborate in a joint application design (JAD) and discuss
which tasks to undertake to make the system most successful

o Analyzing the requirements – business requirements are prioritized and
put in a requirements definition document where the knowledge worker
will approve and place their signatures
• Design – this is where the technical blueprint of the system is created by
o Designing the technical architecture – choosing amongst the architectural
designs of telecommunications, hardware and software that will best suit
the organization’s system and future needs
o Designing the systems model – graphically creating a model from
graphical user interface (GUI), GUI screen design, and databases, to
placement of objects on screen
o Write the test conditions - Work with the end users to develop the test
scripts according to the system requirements
• Development – executing the design into a physical system by
o Building the technical architecture – purchasing the material needed to
build the system
o Building the database and programs – the IT specialists write programs
which will be used on the system
• Testing – testing the developed system
o Test the system using the established test scripts – test conditions are
conducted by comparing expected outcomes to actual outcomes. If these
differ, a bug is generated and a backtrack to the development stage must
occur.
• Deployment – the systems are placed and used in the actual workforce and
o The user guide is created
o Training is provided to the users of the system - usually through
workshops or online
• Maintenance – keeping the system up to date with the changes in the
organization and ensuring it meets the goals of the organization by
o Building a help desk to support the system users – having a team available
to aid technical difficulties and answer questions
o Implementing changes to the system when necessary.
[edit] Selfsourcing
Selfsourcing is defined as having knowledge workers within an organization build the
organization’s system
• Align selfsourcing applications to the goals of the organization – All intentions
must be related to the organization’s goals and time management is key.
• Establish what external assistance will be necessary – this may be where an IT
specialist in the organization may assist
• Document and formalize the completed system created for future users –
• Provide ongoing support - being able to maintain and make adjustments to the
system as the environment changes..
[edit] Prototyping

Prototyping is defined as creating a model, which displays the necessary characteristics
of a proposed system
• Gathering requirements – these requirements will be stated by the knowledge
workers as well as become apparent in comparison with the old or existing system
• Create prototype of system – Confirm a technically proficient system by using
prototypes and create basic screen and reports
• Review by knowledge workers - create a model of the system that will be
analyzed, inspected and evaluated by knowledge workers who will propose
recommendations to have the system reach its maximum potential
• Revise the prototype – if necessary
• Market the idea of the new system – use the prototype to sell the new system and
convince the organization of the advantages of switching up to the new system
[edit] Outsourcing
Outsourcing is defined as having a third party (outside the organization) to build the
organization’s system so expert minds can create the highest quality system by.
• Outsourcing for development software -
o Purchasing existing software and paying the publisher to make certain
modifications and paying the publisher for the right to make modifications
yourself
o Outsourcing the development of an entirely new unique system for which
no software exists
• Selecting a target system – make sure there is no confidential information critical
to the organization that others should not see. If the organization is small enough,
consider selfsourcing
• Establish logical requirements - IT specialists and knowledge workers collaborate
in a joint application design (JAD) and discuss which tasks to undertake to make
the system most successful to gather business requirements
• Develop a request for a proposal – a request for proposal (RFP) is created and
formalized. It includes everything the home organization is looking for in the
system and can be used as the legal binding contract
• Evaluate request for proposed returns and choose a vendor amongst the many who
have replied with different prototypes
• Test and Accept a Solution – the chosen system must be tested by the home
organization and a sign-off must be conducted
• Monitor and Reevaluate – keep the system up to date with the changing
environment and evaluate the chosen vendor’s ability and accommodate to
maintain the system
Algorithm

In mathematics, computing, linguistics, and related disciplines, an algorithm is a definite
list of well-defined instructions for completing a task; that given an initial state, will
proceed through a well-defined series of successive states, eventually terminating in an
end-state. The transition from one state to the next is not necessarily deterministic; some
algorithms, known as probabilistic algorithms, incorporate randomness.
The concept of an algorithm originated as a means of recording procedures for solving
mathematical problems such as finding the common divisor of two numbers or
multiplying two numbers. A partial formalization of the concept began with attempts to
solve the Entscheidungsproblem (the "decision problem") that David Hilbert posed in
1928. Subsequent formalizations were framed as attempts to define "effective
calculability" (cf Kleene 1943:274) or "effective method" (cf Rosser 1939:225); 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 I" of
1936, and Alan Turing's Turing machines of 1936-7 and 1939.
Contents
[hide]
• 1 Etymology
• 2 Why algorithms are necessary: an informal definition
• 3 Formalization of algorithms
o 3.1 Termination
o 3.2 Expressing algorithms
o 3.3 Implementation
• 4 Example
o 4.1 Algorithm analysis
• 5 Classes
o 5.1 Classification by implementation
o 5.2 Classification by design paradigm
o 5.3 Classification by field of study
o 5.4 Classification by complexity
• 6 Legal issues
• 7 History: Development of the notion of "algorithm"
o 7.1 Origin of the word
o 7.2 Discrete and distinguishable symbols
o 7.3 Manipulation of symbols as "place holders" for numbers: algebra
o 7.4 Mechanical contrivances with discrete states
o 7.5 Mathematics during the 1800s up to the mid-1900s
o 7.6 Emil Post (1936) and Alan Turing (1936-7, 1939)
o 7.7 J. B. Rosser (1939) and S. C. Kleene (1943)
o 7.8 History after 1950
• 8 See also
• 9 Notes
• 10 References

o 10.1 Secondary references
[edit] Etymology
Al-Khwārizmī, Persian astronomer and mathematician, wrote a treatise in Arabic in 825
AD, On Calculation with Hindu Numerals. (See algorism). It was translated into Latin in
the 12th century as Algoritmi de numero Indorum,[1]
which title was likely intended to
mean "[Book by] Algoritmus on the numbers of the Indians", where "Algoritmi" was the
translator's rendition of the author's name in the genitive case; but people
misunderstanding the title treated Algoritmi as a Latin plural and this led to the word
"algorithm" (Latin algorismus) coming to mean "calculation method". The intrusive "th"
is most likely due to a false cognate with the Greek αριθμος (arithmos) meaning
"number".
Flowcharts are often used to graphically represent algorithms.
[edit] Why algorithms are necessary: an informal
definition
No generally accepted formal definition of "algorithm" exists yet. We can, however,
derive clues to the issues involved and an informal meaning of the word from the
following quotation from Boolos and Jeffrey (1974, 1999):
"No human being can write fast enough, or long enough, or small enough 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" (boldface added, p. 19).
The words "enumerably infinite" mean "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 (logic). 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.
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.
[edit] Formalization of algorithms
Algorithms are essential to the way computers process information, because a computer
program is essentially an algorithm that tells the computer what specific steps to perform
(in what specific order) in 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 performed by a Turing-complete
system. Authors who assert this thesis include Savage (1987) and Gurevich (2000):
"...Turing's informal argument in favor of his thesis justifies a stronger thesis:
every algorithm can be simulated by a Turing machine" (Gurevich 2000:1)
...according to Savage [1987], "an algorithm is a computational process defined
by a Turing machine."(Gurevich 2000:3)
Typically, when an algorithm is associated with processing information, data are read
from an input source or device, written to an output sink or device, and/or stored for
further processing. Stored data are regarded as part of the internal state of the entity
performing the algorithm. In practice, the state is stored in a data structure, but an
algorithm requires the internal data only for specific operation sets called abstract data
types.
For any 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
almost 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 .
[edit] 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" (Kleene 1952:136). Others, including Kleene, include procedures that
could run forever without stopping; such a procedure has been called a "computational
method" (Knuth 1997:5) or "calculation procedure or algorithm" (Kleene 1952:137);
however, Kleene notes that such a method must eventually exhibit "some object" (Kleene
1952:137).
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 is not 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" (Minsky 1967:105)
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 of arbitrary algorithms whether or not they
terminate from given starting states. The analysis of algorithms for their likelihood of
termination is called termination analysis.
In the case of non-halting computation method (calculation procedure) success can no
longer be defined in terms of halting with a meaningful output. Instead, terms of success
that allow for unbounded output sequences must be defined. For example, an algorithm
that verifies if there are more zeros than ones in an infinite random binary sequence must
run forever to be effective. If it is implemented correctly, however, the algorithm's output
will be useful: for as long as it examines the sequence, the algorithm will give a positive
response while the number of examined zeros outnumber the ones, and a negative
response otherwise. Success for this algorithm could then be defined as eventually
outputting only positive responses if there are actually more zeros than ones in the

sequence, and in any other case outputting any mixture of positive and negative
responses.
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 (Kleene 1952:322). Davis does this to his subtraction algorithm —
he fixes his algorithm in a second example so that it is proper subtraction (Davis
1958:12-15). Along with the logical outcomes "true" and "false" Kleene also proposes the
use of a third logical symbol "u" — undecided (Kleene 1952:326) — 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" (Minsky
1967:186)
[edit] Expressing algorithms
Algorithms can be expressed in many kinds of notation, including natural languages,
pseudocode, flowcharts, and programming languages. Natural language expressions of
algorithms tend to be verbose and ambiguous, and are rarely used for complex or
technical algorithms. Pseudocode and flowcharts 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 (Sipser 2006:157):

• 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.
[edit] 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.
[edit] Example
One of the simplest algorithms is to find the largest number in an (unsorted) list of
numbers. The solution necessarily requires looking at every number in the list, but only
once at each. From this follows a simple algorithm, which can be stated in a high-level
description English prose, as:
High-level description:
1. Assume the first item is largest.
2. Look at each of the remaining items in the list and if it is larger than the largest
item so far, make a note of it.
3. The last noted item is the largest in the list when the process is complete.
(Quasi-)formal description: Written in prose but much closer to the high-level language
of a computer program, the following is the more formal coding of the algorithm in
pseudocode or pidgin code:
Algorithm LargestNumber
Input: A non-empty list of numbers L.
Output: The largest number in the list L.
largest ← L0
for each item in the list L≥1, do
if the item > largest, then

largest ← the item
return largest
• "←" is a loose shorthand for "changes to". For instance, "largest ← item" means that the value of
largest changes to the value of item.
• "return" terminates the algorithm and outputs the value that follows.
For a more complex example of an algorithm, see Euclid's algorithm for the greatest
common divisor, one of the earliest algorithms known.
[edit] Algorithm analysis
As it happens, it is important to know how much of a particular resource (such as time or
storage) is required for a given algorithm. Methods have been developed for the analysis
of algorithms to obtain such quantitative answers; for example, the algorithm above has a
time requirement of O(n), using the big O notation with n as the length of the list. At all
times the algorithm only needs to remember two values: the largest number found so far,
and its current position in the input list. Therefore it is said to have a space requirement of
O(1).[2]
(Note that the size of the inputs is not counted as space used by the algorithm.)
Different algorithms may complete the same task with a different set of instructions in
less or more time, space, or effort than others. For example, given two different recipes
for making potato salad, one may have peel the potato before boil the potato while the
other presents the steps in the reverse order, yet they both call for these steps to be
repeated for all potatoes and end when the potato salad is ready to be eaten.
The analysis and study of algorithms is a discipline of computer science, and is often
practiced abstractly without the use of a specific programming language or
implementation. In this sense, algorithm analysis resembles other mathematical
disciplines in that it focuses on the underlying properties of the algorithm and not on the
specifics of any particular implementation. Usually pseudocode is used for analysis as it
is the simplest and most general representation.
[edit] Classes
There are various ways to classify algorithms, each with its own merits.
[edit] Classification by implementation
One way to classify algorithms is by implementation means.
• Recursion or iteration: A recursive algorithm is one that invokes (makes
reference to) itself repeatedly until a certain condition matches, which is a method
common to functional programming. Iterative algorithms use repetitive constructs
like loops and sometimes additional data structures like stacks to solve the given
problems. Some problems are naturally suited for one implementation or the
other. For example, towers of hanoi is well understood in recursive

implementation. Every recursive version has an equivalent (but possibly more or
less complex) iterative version, and vice versa.
• Logical: An algorithm may be viewed as controlled logical deduction. This notion
may be expressed as:
Algorithm = logic + control.[3]
The logic component expresses the axioms that may be used in the computation
and the control component determines the way in which deduction is applied to
the axioms. This is the basis for the logic programming paradigm. In pure logic
programming languages the control component is fixed and algorithms are
specified by supplying only the logic component. The appeal of this approach is
the elegant semantics: a change in the axioms has a well defined change in the
algorithm.
• Serial or parallel or distributed: Algorithms are usually discussed with the
assumption that computers execute one instruction of an algorithm at a time.
Those computers are sometimes called serial computers. An algorithm designed
for such an environment is called a serial algorithm, as opposed to parallel
algorithms or distributed algorithms. Parallel algorithms take advantage of
computer architectures where several processors can work on a problem at the
same time, whereas distributed algorithms utilise multiple machines connected
with a network. Parallel or distributed algorithms divide the problem into more
symmetrical or asymmetrical subproblems and collect the results back together.
The resource consumption in such algorithms is not only processor cycles on each
processor but also the communication overhead between the processors. Sorting
algorithms can be parallelized efficiently, but their communication overhead is
expensive. Iterative algorithms are generally parallelizable. Some problems have
no parallel algorithms, and are called inherently serial problems.
• Deterministic or non-deterministic: Deterministic algorithms solve the problem
with exact decision at every step of the algorithm whereas non-deterministic
algorithm solve problems via guessing although typical guesses are made more
accurate through the use of heuristics.
• Exact or approximate: While many algorithms reach an exact solution,
approximation algorithms seek an approximation that is close to the true solution.
Approximation may use either a deterministic or a random strategy. Such
algorithms have practical value for many hard problems.
[edit] Classification by design paradigm
Another way of classifying algorithms is by their design methodology or paradigm. There
is a certain number of paradigms, each different from the other. Furthermore, each of

these categories will include many different types of algorithms. Some commonly found
paradigms include:
• Divide and conquer. A divide and conquer algorithm repeatedly reduces an
instance of a problem to one or more smaller instances of the same problem
(usually recursively), until the instances are small enough to solve easily. One
such example of divide and conquer is merge sorting. Sorting can be done on each
segment of data after dividing data into segments and sorting of entire data can be
obtained in conquer phase by merging them. A simpler variant of divide and
conquer is called decrease and conquer algorithm, that solves an identical
subproblem and uses the solution of this subproblem to solve the bigger problem.
Divide and conquer divides the problem into multiple subproblems and so
conquer stage will be more complex than decrease and conquer algorithms. An
example of decrease and conquer algorithm is binary search algorithm.
• Dynamic programming. When a problem shows optimal substructure, meaning
the optimal solution to a problem can be constructed from optimal solutions to
subproblems, and overlapping subproblems, meaning the same subproblems are
used to solve many different problem instances, a quicker approach called
dynamic programming avoids recomputing solutions that have already been
computed. For example, the shortest path to a goal from a vertex in a weighted
graph can be found by using the shortest path to the goal from all adjacent
vertices. Dynamic programming and memoization go together. The main
difference between dynamic programming and divide and conquer is that
subproblems are more or less independent in divide and conquer, whereas
subproblems overlap in dynamic programming. The difference between dynamic
programming and straightforward recursion is in caching or memoization of
recursive calls. When subproblems are independent and there is no repetition,
memoization does not help; hence dynamic programming is not a solution for all
complex problems. By using memoization or maintaining a table of subproblems
already solved, dynamic programming reduces the exponential nature of many
problems to polynomial complexity.
• The greedy method. A greedy algorithm is similar to a dynamic programming
algorithm, but the difference is that solutions to the subproblems do not have to be
known at each stage; instead a "greedy" choice can be made of what looks best for
the moment. The greedy method extends the solution with the best possible
decision (not all feasible decisions) at an algorithmic stage based on the current
local optimum and the best decision (not all possible decisions) made in previous
stage. It is not exhaustive, and does not give accurate answer to many problems.
But when it works, it will be the fastest method. The most popular greedy
algorithm is finding the minimal spanning tree as given by Kruskal.
• Linear programming. When solving a problem using linear programming,
specific inequalities involving the inputs are found and then an attempt is made to
maximize (or minimize) some linear function of the inputs. Many problems (such
as the maximum flow for directed graphs) can be stated in a linear programming
way, and then be solved by a 'generic' algorithm such as the simplex algorithm. A

more complex variant of linear programming is called integer programming,
where the solution space is restricted to the integers.
• Reduction. This technique involves solving a difficult problem by transforming it
into a better known problem for which we have (hopefully) asymptotically
optimal algorithms. The goal is to find a reducing algorithm whose complexity is
not dominated by the resulting reduced algorithm's. For example, one selection
algorithm for finding the median in an unsorted list involves first sorting the list
(the expensive portion) and then pulling out the middle element in the sorted list
(the cheap portion). This technique is also known as transform and conquer.
• Search and enumeration. Many problems (such as playing chess) can be
modeled as problems on graphs. A graph exploration algorithm specifies rules for
moving around a graph and is useful for such problems. This category also
includes search algorithms, branch and bound enumeration and backtracking.
• The probabilistic and heuristic paradigm. Algorithms belonging to this class fit
the definition of an algorithm more loosely.
1. Probabilistic algorithms are those that make some choices randomly (or pseudo-
randomly); for some problems, it can in fact be proven that the fastest solutions
must involve some randomness.
2. Genetic algorithms attempt to find solutions to problems by mimicking biological
evolutionary processes, with a cycle of random mutations yielding successive
generations of "solutions". Thus, they emulate reproduction and "survival of the
fittest". In genetic programming, this approach is extended to algorithms, by
regarding the algorithm itself as a "solution" to a problem.
3. Heuristic algorithms, whose general purpose is not to find an optimal solution, but
an approximate solution where the time or resources are limited. They are not
practical to find perfect solutions. An example of this would be local search, tabu
search, or simulated annealing algorithms, a class of heuristic probabilistic
algorithms that vary the solution of a problem by a random amount. The name
"simulated annealing" alludes to the metallurgic term meaning the heating and
cooling of metal to achieve freedom from defects. The purpose of the random
variance is to find close to globally optimal solutions rather than simply locally
optimal ones, the idea being that the random element will be decreased as the
algorithm settles down to a solution.
[edit] Classification by field of study
See also: List of algorithms
Every field of science has its own problems and needs efficient algorithms. Related
problems in one field are often studied together. Some example classes are search
algorithms, sorting algorithms, merge algorithms, numerical algorithms, graph
algorithms, string algorithms, computational geometric algorithms, combinatorial
algorithms, machine learning, cryptography, data compression algorithms and parsing
techniques.

Fields tend to overlap with each other, and algorithm advances in one field may improve
those of other, sometimes completely unrelated, fields. For example, dynamic
programming was originally invented for optimization of resource consumption in
industry, but is now used in solving a broad range of problems in many fields.
[edit] Classification by complexity
See also: Complexity class
Algorithms can be classified by the amount of time they need to complete compared to
their input size. There is a wide variety: some algorithms complete in linear time relative
to input size, some do so in an exponential amount of time or even worse, and some
never halt. Additionally, some problems may have multiple algorithms of differing
complexity, while other problems might have no algorithms or no known efficient
algorithms. There are also mappings from some problems to other problems. Owing to
this, it was found to be more suitable to classify the problems themselves instead of the
algorithms into equivalence classes based on the complexity of the best possible
algorithms for them.
[edit] Legal issues
See also: Software patents for a general overview of the patentability of software,
including computer-implemented algorithms.
Algorithms, by themselves, are not usually patentable. In the United States, a claim
consisting solely of simple manipulations of abstract concepts, numbers, or signals do not
constitute "processes" (USPTO 2006) and hence algorithms are not patentable (as in
Gottschalk v. Benson). However, practical applications of algorithms are sometimes
patentable. For example, in Diamond v. Diehr, the application of a simple feedback
algorithm to aid in the curing of synthetic rubber was deemed patentable. The patenting
of software is highly controversial, and there are highly criticized patents involving
algorithms, especially data compression algorithms, such as Unisys' LZW patent.
Additionally, some cryptographic algorithms have export restrictions (see export of
cryptography).
This short section requires expansion.
[edit] History: Development of the notion of
"algorithm"
[edit] Origin of the word
See also: Timeline of algorithms

The word algorithm comes from the name of the 9th century Persian mathematician Abu
Abdullah Muhammad ibn Musa al-Khwarizmi whose works introduced Indian numerals
and algebraic concepts. He worked in Baghdad at the time when it was the centre of
scientific studies and trade. The word algorism originally referred only to the rules of
performing arithmetic using Arabic numerals but evolved via European Latin translation
of al-Khwarizmi's name into algorithm by the 18th century. The word evolved to include
all definite procedures for solving problems or performing tasks.
[edit] Discrete and distinguishable symbols
Tally-marks: To keep track of their flocks, their sacks of grain and their money the
ancients used tallying: accumulating stones or marks scratched on sticks, or making
discrete symbols in clay. Through the Babylonian and Egyptian use of marks and
symbols, eventually Roman numerals and the abacus evolved. (Dilson, p.16–41) Tally
marks appear prominently in unary numeral system arithmetic used in Turing machine
and Post-Turing machine computations.
[edit] Manipulation of symbols as "place holders" for numbers: algebra
The work of the ancient Greek geometers, Persian mathematician Al-Khwarizmi (often
considered as the "father of algebra"), and Western European mathematicians culminated
in Leibniz's notion of the calculus ratiocinator (ca 1680):
"A good century and a half ahead of his time, Leibniz proposed an algebra of
logic, an algebra that would specify the rules for manipulating logical concepts in
the manner that ordinary algebra specifies the rules for manipulating numbers"
(Davis 2000:18).
[edit] Mechanical contrivances with discrete states
The clock: Bolter credits the invention of the weight-driven clock as “The key invention
[of Europe in the Middle Ages]", in particular the verge escapement (Bolter 1984:24) that
provides us with the tick and tock of a mechanical clock. “The accurate automatic
machine” (Bolter 1984:26) led immediately to "mechanical automata" beginning in the
thirteenth century and finally to “computational machines" – the difference engine and
analytical engines of Charles Babbage and Countess Ada Lovelace (Bolter p.33–34,
p.204–206).
Jacquard loom, Hollerith punch cards, telegraphy and telephony — the
electromechanical relay: Bell and Newell (1971) indicate that the Jacquard loom (1801),
precursor to Hollerith cards (punch cards, 1887), and “telephone switching technologies”
were the roots of a tree leading to the development of the first computers (Bell and
Newell diagram p. 39, cf Davis (2000)). By the mid-1800s the telegraph, the precursor of
the telephone, was in use throughout the world, its discrete and distinguishable encoding
of letters as “dots and dashes” a common sound. By the late 1800s the ticker tape (ca

1870s) was in use, as was the use of Hollerith cards in the 1890 U.S. census. Then came
the Teletype (ca 1910) with its punched-paper use of Baudot code on tape.
Telephone-switching networks of electromechanical relays (invented 1835) was behind
the work of George Stibitz (1937), the inventor of the digital adding device. As he
worked in Bell Laboratories, he observed the “burdensome’ use of mechanical calculators
with gears. "He went home one evening in 1937 intending to test his idea.... When the
tinkering was over, Stibitz had constructed a binary adding device" (Valley News, p. 13).
Davis (2000) observes the particular importance of the electromechanical relay (with its
two "binary states" open and closed):
It was only with the development, beginning in the 1930s, of electromechanical
calculators using electrical relays, that machines were built having the scope
Babbage had envisioned." (Davis, p. 148)
[edit] Mathematics during the 1800s up to the mid-1900s
Symbols and rules: In rapid succession the mathematics of George Boole (1847, 1854),
Gottlob Frege (1879), and Giuseppe Peano (1888–1889) reduced arithmetic to a sequence
of symbols manipulated by rules. Peano's The principles of arithmetic, presented by a
new method (1888) was "the first attempt at an axiomatization of mathematics in a
symbolic language" (van Heijenoort:81ff).
But Heijenoort gives Frege (1879) this kudos: Frege’s is "perhaps the most important
single work ever written in logic. ... in which we see a " 'formula language', that is a
lingua characterica, a language written with special symbols, "for pure thought", that is,
free from rhetorical embellishments ... constructed from specific symbols that are
manipulated according to definite rules"(van Heijenoort:1). The work of Frege was
further simplified and amplified by Alfred North Whitehead and Bertrand Russell in their
Principia Mathematica (1910–1913).
The paradoxes: At the same time a number of disturbing paradoxes appeared in the
literature, in particular the Burali-Forti paradox (1897), the Russell paradox (1902–03),
and the Richard Paradox (1905, Dixon 1906), (cf Kleene 1952:36–40). The resultant
considerations led to Kurt Gödel’s paper (1931) — he specifically cites the paradox of
the liar — that completely reduces rules of recursion to numbers.
Effective calculability: In an effort to solve the Entscheidungsproblem defined precisely
by Hilbert in 1928, mathematicians first set about to define what was meant by an
"effective method" or "effective calculation" or "effective calculability" (i.e., a
calculation that would succeed). In rapid succession the following appeared: Alonzo
Church, Stephen Kleene and J.B. Rosser's λ-calculus (cf footnote in Alonzo Church
1936a:90, 1936b:110), a finely-honed definition of "general recursion" from the work of
Gödel acting on suggestions of Jacques Herbrand (cf Gödel's Princeton lectures of 1934)
and subsequent simplifications by Kleene (1935-6:237ff, 1943:255ff), Church's proof

(Church 1936:88ff) that the Entscheidungsproblem was unsolvable, Emil Post's definition
of effective calculability as a worker mindlessly following a list of instructions to move
left or right through a sequence of rooms and while there either mark or erase a paper or
observe the paper and make a yes-no decision about the next instruction (cf his
"Formulation I" 1936:289-290), Alan Turing's proof of that the Entscheidungsproblem
was unsolvable by use of his "a- [automatic-] machine" (Turing 1936-7:116ff) -- in effect
almost identical to Post's "formulation", J. Barkley Rosser's definition of "effective
method" in terms of "a machine" (Rosser 1939:226), S. C. Kleene's proposal of a
precursor to "Church thesis" that he called "Thesis I" (Kleene 1943:273–274)), and a few
years later Kleene's renaming his Thesis "Church's Thesis" (Kleene 1952:300, 317) and
proposing "Turing's Thesis" (Kleene 1952:376).
[edit] Emil Post (1936) and Alan Turing (1936-7, 1939)
Here is a remarkable coincidence of two men not knowing each other but describing a
process of men-as-computers working on computations — and they yield virtually
identical definitions.
Emil Post (1936) described the actions of a "computer" (human being) as follows:
"...two concepts are involved: that of a symbol space in which the work leading
from problem to answer is to be carried out, and a fixed unalterable set of
directions.
His symbol space would be
"a two way infinite sequence of spaces or boxes... The problem solver or worker
is to move and work in this symbol space, being capable of being in, and
operating in but one box at a time.... a box is to admit of but two possible
conditions, i.e., being empty or unmarked, and having a single mark in it, say a
vertical stroke.
"One box is to be singled out and called the starting point. ...a specific problem is
to be given in symbolic form by a finite number of boxes [i.e., INPUT] being
marked with a stroke. Likewise the answer [i.e., OUTPUT] is to be given in
symbolic form by such a configuration of marked boxes....
"A set of directions applicable to a general problem sets up a deterministic
process when applied to each specific problem. This process will terminate only
when it comes to the direction of type (C ) [i.e., STOP]." (U p. 289–290) See
more at Post-Turing machine
Alan Turing’s work (1936–1937, 1939:160) preceded that of Stibitz (1937); it is
unknown if Stibitz knew of the work of Turing. Turing’s biographer believed that
Turing’s use of a typewriter-like model derived from a youthful interest: “Alan had
dreamt of inventing typewriters as a boy; Mrs. Turing had a typewriter; and he could well
have begun by asking himself what was meant by calling a typewriter 'mechanical'"

(Hodges, p. 96) Given the prevalence of Morse code and telegraphy, ticker tape
machines, and Teletypes we might conjecture that all were influences.
Turing — his model of computation is now called a Turing machine — begins, as did
Post, with an analysis of a human computer that he whittles down to a simple set of basic
motions and "states of mind". But he continues a step further and creates a machine as a
model of computation of numbers (Turing 1936-7:116):
"Computing is normally done by writing certain symbols on paper. We may
suppose this paper is divided into squares like a child's arithmetic book....I assume
then that the computation is carried out on one-dimensional paper, i.e., on a tape
divided into squares. I shall also suppose that the number of symbols which may
be printed is finite....
"The behavior of the computer at any moment is determined by the symbols
which he is observing, and his "state of mind" at that moment. We may suppose
that there is a bound B to the number of symbols or squares which the computer
can observe at one moment. If he wishes to observe more, he must use successive
observations. We will also suppose that the number of states of mind which need
be taken into account is finite...
"Let us imagine that the operations performed by the computer to be split up into
'simple operations' which are so elementary that it is not easy to imagine them
further divided" (Turing 1936-7:136).
Turing's reduction yields the following:
"The simple operations must therefore include:
"(a) Changes of the symbol on one of the observed squares
"(b) Changes of one of the squares observed to another square within L squares of
one of the previously observed squares.
"It may be that some of these change necessarily invoke a change of state of mind. The
most general single operation must therefore be taken to be one of the following:
"(A) A possible change (a) of symbol together with a possible change of state of
mind.
"(B) A possible change (b) of observed squares, together with a possible change
of state of mind"
"We may now construct a machine to do the work of this computer."((Turing
1936-7:136).
A few years later, Turing expanded his analysis (thesis, definition) with this forceful
expression of it:
"A function is said to be "effectivey calculable" if its values can be found by some
purely mechanical process. Although it is fairly easy to get an intuitive grasp of
this idea, it is neverthessless desirable to have some more definite, mathematical

expressible definition . . . [he discusses the history of the definition pretty much as
presented above with respect to Gödel, Herbrand, Kleene, Church, Turing and
Post] . . . We may take this statement literally, understanding by a purely
mechanical process one which could be carried out by a machine. It is possible to
give a mathematical description, in a certain normal form, of the structures of
these machines. The development of these ideas leads to the author's definition of
a computable function, and to an identification of computability † with effective
calculability . . . .
"† We shall use the expression "computable function" to mean a function
calculable by a machine, and we let "effectively calculabile" refer to the intuitive
idea without particular identification with any one of these definitions." (Turing
1939:160).
[edit] J. B. Rosser (1939) and S. C. Kleene (1943)
J. Barkley Rosser boldly defined an ‘effective [mathematical] method’ in the following
manner (boldface added):
"'Effective method' is used here in the rather special sense of a method each step
of which is precisely determined and which is certain to produce the answer in a
finite number of steps. With this special meaning, three different precise
definitions have been given to date. [his footnote #5; see discussion immediately
below]. The simplest of these to state (due to Post and Turing) says essentially
that an effective method of solving certain sets of problems exists if one can
build a machine which will then solve any problem of the set with no human
intervention beyond inserting the question and (later) reading the answer.
All three definitions are equivalent, so it doesn't matter which one is used.
Moreover, the fact that all three are equivalent is a very strong argument for the
correctness of any one." (Rosser 1939:225–6)
Rosser's footnote #5 references the work of (1) Church and Kleene and their definition of
λ-definability, in particular Church's use of it in his An Unsolvable Problem of
Elementary Number Theory (1936); (2) Herbrand and Gödel and their use of recursion in
particular Gödel's use in his famous paper On Formally Undecidable Propositions of
Principia Mathematica and Related Systems I (1931); and (3) Post (1936) and Turing
(1936-7) in their mechanism-models of computation.
Stephen C. Kleene defined as his now-famous "Thesis I" known as "the Church-Turing
Thesis". But he did this in the following context (boldface in original):
"12. Algorithmic theories... In setting up a complete algorithmic theory, what we
do is to describe a procedure, performable for each set of values of the
independent variables, which procedure necessarily terminates and in such
manner that from the outcome we can read a definite answer, "yes" or "no," to the
question, "is the predicate value true?”" (Kleene 1943:273)

[edit] History after 1950
A number of efforts have been directed toward further refinement of the definition of
"algorithm", and activity is on-going because of issues surrounding, in particular,
foundations of mathematics (especially the Church-Turing Thesis) and philosophy of
mind (especially arguments around artificial intelligence). For more, see Algorithm
characterizations.
Pseudocode (derived from pseudo and code) is a compact and informal high-level
description of a computer programming algorithm that uses the structural conventions of
programming languages, but omits detailed subroutines, variable declarations, and
language-specific syntax. The programming language is augmented with natural language
descriptions of the details, where convenient, or with compact mathematical notation.
The purpose of using pseudocode as opposed the language syntax is that it is easier for
humans to read. This is often achieved by making the sample application-independent so
more specific items (i/o variables, etc.) can be added later.
Pseudocode resembles, but should not be confused with, skeleton programs including
dummy code, which can be compiled without errors. Flowcharts can be thought of as a
graphical form of pseudocode.
Contents
[hide]
• 1 Syntax
• 2 Application
• 3 Examples of pseudocode
• 4 Mathematical style pseudocode
• 5 Machine compilation or interpretation
o 5.1 Natural language grammar in programming languages
o 5.2 Mathematical programming languages
• 6 See also
[edit] Syntax
As the name suggests, pseudocode generally does not actually obey the syntax rules of
any particular language; there is no systematic standard form, although any particular
writer will generally borrow the appearance of a particular language. Popular sources
include PASCAL, C, Java, BASIC, Lisp, and ALGOL. Details not relevant to the
algorithm (such as memory management code) are usually omitted. Blocks of code, for

example code contained within a loop, may be described in a one-line natural language
sentence.
Depending on the writer, pseudocode may therefore vary widely in style, from a near-
exact imitation of a real programming language at one extreme, to a description
approaching formatted prose at the other.
[edit] Application
Textbooks and scientific publications related to computer science and numerical
computation often use pseudocode in description of algorithms, so that all programmers
can understand them, even if they do not all know the same programming languages. In
textbooks, there is usually an accompanying introduction explaining the particular
conventions in use. The level of detail of such languages may in some cases approach
that of formalized general-purpose languages — for example, Knuth's seminal textbook
The Art of Computer Programming describes algorithms in a fully-specified assembly
language for a non-existent microprocessor.
A programmer who needs to implement a specific algorithm, especially an unfamiliar
one, will often start with a pseudocode description, and then simply "translate" that
description into the target programming language and modify it to interact correctly with
the rest of the program. Programmers may also start a project by sketching out the code
in pseudocode on paper before writing it in its actual language, as a top-down structuring
approach.
[edit] Examples of pseudocode
An example of how pseudocode differs from regular code is below.
Regular code (written in PHP):
<?php
if (is_valid($cc_number)) {
execute_transaction($cc_number,
$order);
} else {
show_failure();
}
?>
Pseudocode:
if credit card number is valid
execute transaction based on
number and order
else
show a generic failure
message
end if
The pseudocode of the Hello world program is particularly simple:
output Hello World
[edit] Mathematical style pseudocode

In numerical computation, pseudocode often consists of mathematical notation, typically
from set and matrix theory, mixed with the control structures of a conventional
programming language, and perhaps also natural language descriptions. This is a compact
and often informal notation that can be understood by a wide range of mathematically
trained people, and is frequently used as a way to describe mathematical algorithms.
Normally non-ASCII typesetting is used for the mathematical equations, for example by
means of TeX or MathML markup, or proprietary formula editors.
Mathematical style pseudocode is sometimes referred to as pidgin code, for example
pidgin ALGOL (the origin of the concept), pidgin Fortran, pidgin BASIC, pidgin Pascal,
and pidgin C.
[edit] Machine compilation or interpretation
It is often suggested that future programming languages will be more similar to
pseudocode or natural language than to present-day languages; the idea is that increasing
computer speeds and advances in compiler technology will permit computers to create
programs from descriptions of algorithms, instead of requiring the details to be
implemented by a human.
[edit] Natural language grammar in programming languages
Various attempts to bring elements of natural language grammar into computer
programming have produced programming languages such as HyperTalk, Lingo,
AppleScript, SQL and Inform. In these languages, parentheses and other special
characters are replaced by prepositions, resulting in quite talkative code. This may make
it easier for a person without knowledge about the language to understand the code and
perhaps also to learn the language. However, the similarity to natural language is usually
more cosmetic than genuine. The syntax rules are just as strict and formal as in
conventional programming, and do not necessarily make development of the programs
easier.
[edit] Mathematical programming languages
An alternative to using mathematical pseudocode (involving set theory notation or matrix
operations) for documentation of algorithms is to use a formal mathematical
programming language that is a mix of non-ASCII mathematical notation and program
control structures. Then the code can be parsed and interpreted by a machine.
Several formal specification languages include set theory notation using special
characters. Examples are:
• Z notation
• Vienna Development Method Specification Language (VDM-SL).

Some array programming languages include vectorized expressions and matrix
operations as non-ASCII formulas, mixed with conventional control structures. Examples
are:
• A programming language (APL), and its dialects APLX and A+.
• MathCAD.
The process of converting a problem to computer code is a five-step one and you may
have to repeat some steps in response to difficulties.
Step 1: Define the problem. Before starting, it's important you completely understand the
problem's nature any assumptions.
Step 2: Plan the solution. Break the problem's solution down into its smallest steps and
determine how they are logically linked.
Step 3: Code the program. Translate the logical solution into a programming language
the computer understands.
Step 4: Test the program. Check the program logic by hand and then by machine using
various test cases.

Step 5: Document everything. The most important step in many cases. You won't always
remember what you did or be able to figure it out.
Translators
To get from your programming language down to the binary steps the computer
understands requires some form of translator. Translators come in two general types:
• Compiler: Translates an entire program at one time then executes.
o Compiled programs execute much faster.
o Compilation is usually a multi-step process.
o Compilers do not require space in memory when programs run.
• Interpreter: Translates a program line at a time while executing.
o Interpreted programs are slower because translation takes times.
o Interpretation translates in one step.
o Interpreters must be in memory while a program is running.
Programming Language Hierarchy
There are a variety of programming languages, falling into several classes. These classes
range from actual machine code through languages with very English-like structure.
There are other trade-offs as shown here.
Language English-like Ease of Use Efficiency
Machine Not Very Hard Very
Assembly
High-level
Nonprocedural Very Easy Not Very
The basic trade-off you have to make is between ease of use and efficiency. Because
higher level languages tend to require lots of extra code, they don't use the machine as
efficiently as possible. This partially accounts for the need for more powerful hardware to
run newer software.
Comp 150 - Algorithms & Pseudo-Code
(revised 01/11/2008)

Definition of Algorithm (after Al Kho-war-iz-mi a 9th century Persian mathematician) -
an ordered sequence of unambiguous and well-defined instructions that performs some
task and halts in finite time
Let's examine the four parts of this definition more closely
1. an ordered sequence means that you can number the steps (it's socks then shoes!)
2. unambiguous and well-defined instructions means that each instruction is clear,
do-able, and can be done without difficulty
3. performs some task
4. halts in finite time (algorithms terminate!)
Algorithms can be executed by a computing agent which is not necessarily a computer.
Three Catagories of Algorithmic Operations
Algorithmic operations are ordered in that there is a first instruction, a second instruction
etc. However, this is not enough. An algorithm must have the ability to alter the order of
its instructions. An instruction that alters the order of an algorithm is called a control
structure
Three Categories of Algorithmic Operations:
1. sequential operations - instructions are executed in order
2. conditional ("question asking") operations - a control structure that asks a
true/false question and then selects the next instruction based on the answer
3. iterative operations (loops) - a control structure that repeats the execution of a
block of instructions
Unfortunately not every problem or task has a "good" algorithmic solution. There are
1. unsolvable problems - no algorithm can exist to solve the problem (Halting
Problem)
2. "hard" (intractable) problems - algorithm takes too long to solve the problem
(Traveling Salesman Problem)
3. problems with no known algorithmic solution
How to represent algorithms?
1. Use natural languages
o too verbose
o too "context-sensitive"- relies on experience of reader
2. Use formal programming languages
o too low level

o requires us to deal with complicated syntax of programming language
3. Pseudo-Code - natural language constructs modeled to look like statements
available in many programming languages
Pseudo-Code is simply a numbered list of instructions to perform some task. In this
course we will enforce three standards for good pseudo code
1. Number each instruction. This is to enforce the notion of an ordered sequence
of ... operations. Furthermore we introduce a dot notation (e.g. 3.1 come after 3
but before 4) to number subordinate operations for conditional and iterative
operations
2. Each instruction should be unambiguous (that is the computing agent, in this case
the reader, is capable of carrying out the instruction) and effectively computable
(do-able).
3. Completeness. Nothing is left out.
Pseudo-code is best understood by looking at examples. Each example below
demonstrates one of the control structures used in algorithms : sequential operations,
conditional operations, and iterative operations. We also list all variables used at the end
of the pseudo-code.
Example #1 - Computing Sales Tax : Pseudo-code the task of computing the final price
of an item after figuring in sales tax. Note the three types of instructions: input (get),
process/calculate (=) and output (display)
1. get price of item
2. get sales tax rate
3. sales tax = price of time times sales tax rate
4 final prince = price of item plus sales tax
5. display final price
6. halt
Variables: price of item, sales tax rate, sales tax, final price
Note that the operations are numbered and each operation is unambiguous and effectively
computable. We also extract and list all variables used in our pseudo-code. This will be
useful when translating pseudo-code into a programming language
Example #2 - Computing Weekly Wages: Gross pay depends on the pay rate and the
number of hours worked per week. However, if you work more than 40 hours, you get
paid time-and-a-half for all hours worked over 40. Pseudo-code the task of computing
gross pay given pay rate and hours worked.
1. get hours worked

2. get pay rate
3. if hours worked ≤ 40 then
3.1 gross pay = pay rate times hours worked
4. else
4.1 gross pay = pay rate times 40 plus 1.5 times pay rate times
(hours worked minus 40)
5. display gross pay
6. halt
variables: hours worked, ray rate, gross pay
This example introduces the conditional control structure. On the basis of the true/false
question asked in line 3, we execute line 3.1 if the answer is True; otherwise if the answer
is False we execute the lines subordinate to line 4 (i.e. line 4.1). In both cases we resume
the pseudo-code at line 5.
Example #3 - Computing a Quiz Average: Pseudo-code a routine to calculate your quiz
average.
1. get number of quizzes
2. sum = 0
3. count = 0
4. while count < number of quizzes
4.1 get quiz grade
4.2 sum = sum + quiz grade
4.3 count = count + 1
5. average = sum / number of quizzes
6. display average
7. halt
variables: number of quizzes, sum ,count, quiz grade, average
This example introduces an iterative control statement. As long as the condition in line 4
is True, we execute the subordinate operations 4.1 - 4.3. When the condition becomes
False, we resume the pseudo-code at line 5.
This is an example of a top-test or while do iterative control structure. There is also a
bottom-test or repeat until iterative control structure which executes a block of statements
until the condition tested at the end of the block is False.
Pseudo-code is one important step in the process of writing a program.
Pseudo-code Language Constructions : A Summary

Computation/Assignment
set the value of "variable" to :"arithmetic expression" or
"variable" equals "expression" or
"variable" = "expression"
Input/Output
get "variable", "variable", ...
display "variable", "variable", ...
Conditional (dot notation used for numbering subordinate statements)
6. if "condition"
6.1 (subordinate) statement 1
6.2 etc ...
7. else
7.2 etc ...
Iterative (dot notation used for numbering subordinate statements)
9. while "condition"
9.2 etc ...
Return to Comp 150 Home Page
Determining the Day of the Week from the Date
(see Asgt 06 - Calculating Day of the Week)
03/17/2004
The day of the week for any date can be obtained from the following two data items :
A. The ordinal position of the day within the year (e.g. March 25, 1999 was day 84).
We'll call this the year_ordinal.
B. The ordinal position of the day within the week for January 1 of that year (where
Sunday is 1, Monday is 2 etc.). The ordinal position of the day within the week we'll call
the week_ordinal and week_ordinal for January 1 we'll refer call week_ordinal(1/1). This
value depends on the year.

Given these two numbers, year_ordinal (the ordinal position of day within the year) and
week_ordinal(1/1) (the ordinal position of January 1 within the week), the week_ordinal
for any date is easily found by the formula
((year_ordinal - 1) + (week_ordinal(1/1) - 1) ) modulo 7 + 1
Essentially you start at the ordinal position of January 1 with in the week and increment it
by the ordinal position of the day within the year minus 1 (modulo 7) then add 1 to obtain
ordinal position of the day within the week.
For example, if the January 1 of the year was a Wednesday (day of week 4) and you
wanted to find the day of the week January 12 fell on (day number 12) then starting at 3
you count forward 11 units (modulo 7)
3, 4, 5, 6, 0, 1, 2, 3, 4, 5, 6, 0
You end up at 0. Adding 1 to 0 yields 1 so January 12 is a Sunday. You can check that
this works using the calender below by starting at Wednesday the 1st and counting
forward 11 days to arrive at Sunday!
Su M Tu W Th F Sa
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Calculating Year Ordinal: the ordinal postion of the day within the year
Calculating the year_ordinal is easily done if we make use of the following table which
lists the number of days before the 1st of each month
Month Number of Days
before 1st
Jan 0
Feb 31
Mar 59*
Apr 90*
May 120*
Jun 151*
Jul 181*
Aug 212*
Sept 243*
Oct 273*
Nov 304*
Dec 334* Note : * indicates add 1 for leap
years
This table is obtained by summing the days of all prior months.

The year ordinal for any date is obtained by adding the proper value for that month from
the table to the day.
Example
June 15, 2003 is day 166 (151 + 15).
Calculating Week_Ordinal (1/1): the ordinal position of January 1
Since 365 is not divisible by 7 but 365 equals 52 times 7 plus 1, the ordinal position of
the day within the week for January 1 advances by 1 day from one year to the next except
when the previous year was a leap year in which case it advances by 2 days.
Example
Since January 1, 1998 fell on a Thursday, January 1, 1999 fell on a Friday since there
are 365 days between them.
Since January 1, 2000 fell on a Saturday, January 1, 2001 will fall on a Monday since
there are 366 days between them.
Given that the January 1 advances one day except when going from a leap year in which
case it advances two days, it's not difficult to show that there is a 28 year cycle for
determining the day for January 1. Consider the years 1901 through 1928. The cycle
starts with Tuesday, January 1 1901. Years in red indicate where the ordinal position
advances by 2
1901 - Tu 1902 - W 1903 - Th 1904 - F
1905 - Su 1906 - M 1907 - Tu 1908 - W
1909 - F 1910 - Sa 1911 - Su 1912 - M
1913 - W 1914 - Th 1915 - F 1916 - Sa
1917 - M 1918 - Tu 1919 - W 1920 - Th
1921 - Sa 1922 - Su 1923 - M 1924 - Tu
1925 - Th 1926 - F 1927 - Sa 1928 - Su
1929 - Tu 1930 - W 1931 - Th 1932 - F
As is shown, the pattern repeats with 1929. The cycle is 28 years long.
Since the cycle repeats every 28 years, if we calculate the difference between the current
year and 1901 modulo 28, we will know where we are within the 28 year cycle. Using the
formula we obtain
a = (year - 1901) modulo 28
where a is in integer between 0 and 27.

Example : For the year 2000,
(2000 - 1901) modulo 28 equals 15.
and if you count 15 forward from 1901 - Tu (1902 - W is 1, 1903 - Th is 2 etc) you end
up at 1916 - Sa. So January 1, 2000 was a Saturday.
There is a trick we can used to calculate the day instead counting forward on the 1901 -
1928 table. Given any year, the value of a that we calculate is the offset into the 28 year
cycle. And if we did not have to take into account the effect of leap years, if we added a
to the to the first day value for 1901 modulo 7, we would have the first day for the year;
that is calculate (3 + a) mod 7.
However this does not take into account the effect of leap years which pushed January 1
ahead two days instead of 1. So if we add the number of leap years in the cycle, b where
b = floor (a / 4)
the sum of a plus b modulo 7 tells us how many days we have to advance January 1 from
Tuesday. Since modulo 7 returns a value between 0 and 6 and we normally number the
days of the week 1 (Sunday) through 7 (Saturday), we have to add 1.
week_ordinal(1/1) = (2 + a + b) modulo 7 + 1
Thus the week_ordinal(1/1) can be found by the three formulas
1. a = (year - 1901) mod 28
2. b = floor(a/4)
3. week_ordinal(1/1) = (2 + a + b) modulo 7 + 1
Summary
To find the ordinal position of the day within the week for any date between Jan 1, 1901
and Dec 31 2099
1. Find the year_ordinal using the table of days before the first of the month
2. Calculate week_ordinal(1/1) as follows
b = floor (a/4)
week_ordinal(1/1) = (2 + a + b) modulo 7 + 1
3. Day of the Week = ((year_ordinal - 1) + (week_ordinal(1/1) - 1)) modulo 7 + 1

Addendum
1. This algorithm only works for the dates between 1901 and 2100. The fact that 2100
is not a leap year prohibits the 28 year cycle for obtaining the first day from carrying
over into the 22nd century.
2. The algorithm presented makes use of modular arithmetic with its use of modulo 28
and modulo 7 calculations. In modular arithmetic it's easier to starting counting at 0
instead of 1. Consequently the algorithm could be simplified if we made the following
changes
a. Number the days from 0 to 6 with Sunday being day 0 and Saturday being day 6
b. Number the days of the year from 0 to 364 (or 365 for leap year) with January 1
being day 0 etc.
Alternate Algorithm
Number the days of the week 0 - 6 and the days of the year 0 - 364 (or 365 for leap year)
1. Find the year_ordinal using the table of days before the first of the month except
subtract 1 from this value. This would number the day of the year from 0 to 364 (or 365
for leap years)
2. Calculate week_ordinal(1/1) as follows
b = floor (a/4)
week_ordinal(1/1) = (2 + a + b) modulo 7
We note that Tuesday January 1, 1901 is now day 2 under the new numbering (Sunday is
day 0)
3. Day of the Week = (year_ordinal + week_ordinal(1/1)) modulo 7
Example : Find the Day of the Year for March 21, 2004
1. March 21, 2000 is day 60 + 21 - 1 = 80
2. a = (2004 - 1901) modulo 28 = 19
b = floor (19/4) = 4
week_ordinal(1/1) = (2 + 19 + 4) modulo 7 = 4 (Thursday)
3. week_ordinal(3/21/2004) = (80+4) modulo 7 = 0 (Sunday)

Pseudocode Examples
Modified 15 December 1999
An algorithm is a procedure for solving a problem in terms of the actions
to be executed and the order in which those actions are to be
executed. An algorithm is merely the sequence of steps taken to solve
a problem. The steps are normally "sequence," "selection, "
"iteration," and a case-type statement.
In C, "sequence statements" are imperatives. The "selection" is the "if
then else" statement, and the iteration is satisfied by a number of
statements, such as the "while," " do," and the "for," while the case-type
statement is satisfied by the "switch" statement.
Pseudocode is an artificial and informal language that helps programmers
develop algorithms. Pseudocode is a "text-based" detail (algorithmic)
design tool.
The rules of Pseudocode are reasonably straightforward. All statements
showing "dependency" are to be indented. These include while, do, for, if,
switch. Examples below will illustrate this notion.
GUIDE TO PSEUDOCODE LEVEL OF DETAIL: Given record/file
descriptions, pseudocode should be created in sufficient detail so as to
directly support the programming effort. It is the purpose of pseudocode
to elaborate on the algorithmic detail and not just cite an abstraction.
Examples:
1.
If student's grade is greater than or equal to 60
Print "passed"
else
Print "failed"
endif
2.

Set total to zero
Set grade counter to one
While grade counter is less than or equal to ten
Input the next grade
Add the grade into the total
endwhile
Set the class average to the total divided by ten
Print the class average.
3.
Initialize total to zero
Initialize counter to zero
Input the first grade
while the user has not as yet entered the sentinel
add this grade into the running total
add one to the grade counter
input the next grade (possibly the sentinel)
endwhile
if the counter is not equal to zero
set the average to the total divided by the counter
print the average
else
print 'no grades were entered'
endif
4.
initialize passes to zero
initialize failures to zero
initialize student to one
while student counter is less than or equal to ten
input the next exam result
if the student passed
add one to passes
else
add one to failures
add one to student counter
endif
endwhile
print the number of passes

print the number of failures
if eight or more students passed
print "raise tuition"
endif
5.
Larger example:
NOTE: NEVER ANY DATA DECLARATIONS IN PSEUDOCODE
Print out appropriate heading and make it pretty
While not EOF do:
Scan over blanks and white space until a char is found
(get first character on the line)
set can't-be-ascending-flag to 0
set consec cntr to 1
set ascending cntr to 1
putchar first char of string to screen
set read character to hold character
While next character read != blanks and white space
putchar out on screen
if new char = hold char + 1
add 1 to consec cntr
set hold char = new char
continue
endif
if new char >= hold char
if consec cntr < 3
endif
continue
endif
if new char < hold char
if consec cntr < 3
endif
set can't be ascending flag to 1
continue
endif
end while
if consec cntr >= 3
printf (Appropriate message 1 and skip a line)
add 1 to consec total
endif
if can't be ascending flag = 0
printf (Appropriate message 2 and skip a line)
add 1 to ascending total
else
printf (Sorry message and skip a line)
add 1 to sorry total

endif
end While
Print out totals: Number of consecs, ascendings, and sorries.
Stop
Some Keywords that should be Used and Additional Points
For looping and selection, The keywords that are to be used include Do
While...EndDo; Do Until...Enddo; While .... Endwhile is acceptable.
Also, Loop .... endloop is also VERY good and is language
independent. Case...EndCase; If...Endif; Call ... with (parameters);
Call; Return ....; Return; When;
Always use scope terminators for loops and iteration.
As verbs, use the words Generate, Compute, Process, etc. Words such as
set, reset, increment, compute, calculate, add, sum, multiply, ... print,
display, input, output, edit, test , etc. with careful indentation tend to foster
desirable pseudocode. Also, using words such as Set and Initialize, when
assigning values to variables is also desirable.
More on Formatting and Conventions in Pseudocoding
 INDENTATION in pseudocode should be identical to its
implementation in a programming language. Try to indent at least
four spaces.
 As noted above, the pseudocode entries are to be cryptic, AND
SHOULD NOT BE PROSE. NO SENTENCES.
 No flower boxes (discussed ahead) in your pseudocode.
 Do not include data declarations in your pseudocode.
 But do cite variables that are initialized as part of their declarations.
E.g. "initialize count to zero" is a good entry.
Function Calls, Function Documentation, and Pseudocode
 Calls to Functions should appear as:
Call FunctionName (arguments: field1, field2, etc.)
 Returns in functions should appear as:

Return (field1)
 Function headers should appear as:
FunctionName (parameters: field1, field2, etc. )
 Note that in C, arguments and parameters such as "fieldn" could be
written: "pointer to fieldn ...."
 Functions called with addresses should be written as:
Call FunctionName (arguments: pointer to fieldn, pointer to field1,
etc.)
 Function headers containing pointers should be indicated as:
FunctionName (parameters: pointer to field1, pointer to field2, ...)
 Returns in functions where a pointer is returned:
Return (pointer to fieldn)
 It would not hurt the appearance of your pseudocode to draw a line or
make your function header line "bold" in your pseudocode. Try to
set off your functions.
 Try to use scope terminators in your pseudocode and source code too. It
really hels the readability of the text.
Source Code
 EVERY function should have a flowerbox PRECEDING IT. This
flower box is to include the functions name, the main purpose of the
function, parameters it is expecting (number and type), and the type
of the data it returns. All of these listed items are to be on separate
lines with spaces in between each explanatory item.
 FORMAT of flowerbox should be
********************************************************
Function: ( cryptic text describing single function
....... (indented like this)
.......
Calls: Start listing functions "this" function calls
Show these functions: one per line, indented
Called by: List of functions that calls "this" function
Show these functions: one per line, indented.
Input Parameters: list, if appropriate; else None
Returns: List, if appropriate.
****************************************************************
 INDENTATION is critically important in Source Code. Follow
standard examples given in class. If in doubt, ASK. Always indent
statements within IFs, FOR loops, WILLE loops, SWITCH

statements, etc. a consistent number of spaces, such as four.
Alternatively, use the tab key. One or two spaces is insufficient.
 Use scope terminators at the end of if statements, for statements, while
statements, and at the end of functions. It will make your program
much more readable.
SPELLING ERRORS ARE NOT ACCEPTABLE
PSEUDOCODE STANDARD
Pseudocode is a kind of structured english for describing algorithms. It allows the
designer to focus on the logic of the algorithm without being distracted by details of
language syntax. At the same time, the pseudocode needs to be complete. It describe the
entire logic of the algorithm so that implementation becomes a rote mechanical task of
translating line by line into source code.
In general the vocabulary used in the pseudocode should be the vocabulary of the
problem domain, not of the implementation domain. The pseudocode is a narrative for
someone who knows the requirements (problem domain) and is trying to learn how the
solution is organized. E.g.,
Extract the next word from the line (good)
set word to get next token (poor)
Append the file extension to the name (good)
name = name + extension (poor)
FOR all the characters in the name (good)
FOR character = first to last (ok)
Note that the logic must be decomposed to the level of a single loop or decision. Thus
"Search the list and find the customer with highest balance" is too vague because it takes
a loop AND a nested decision to implement it. It's okay to use "Find" or "Lookup" if
there's a predefined function for it such as String.indexOf().
Each textbook and each individual designer may have their own personal style of
pseudocode. Pseudocode is not a rigorous notation, since it is read by other people, not by
the computer. There is no universal "standard" for the industry, but for instructional
purposes it is helpful if we all follow a similar style. The format below is recommended
for expressing your solutions in our class.

The "structured" part of pseudocode is a notation for representing six specific structured
programming constructs: SEQUENCE, WHILE, IF-THEN-ELSE, REPEAT-UNTIL,
FOR, and CASE. Each of these constructs can be embedded inside any other construct.
These constructs represent the logic, or flow of control in an algorithm.
It has been proven that three basic constructs for flow of control are sufficient to
implement any "proper" algorithm.
SEQUENCE is a linear progression where one task is performed sequentially after
another.
WHILE is a loop (repetition) with a simple conditional test at its beginning.
IF-THEN-ELSE is a decision (selection) in which a choice is made between two
alternative courses of action.
Although these constructs are sufficient, it is often useful to include three more
constructs:
REPEAT-UNTIL is a loop with a simple conditional test at the bottom.
CASE is a multiway branch (decision) based on the value of an expression. CASE is a
generalization of IF-THEN-ELSE.
FOR is a "counting" loop.
SEQUENCE
Sequential control is indicated by writing one action after another, each action on a line
by itself, and all actions aligned with the same indent. The actions are performed in the
sequence (top to bottom) that they are written.
Example (non-computer)
Brush teeth
Wash face
Comb hair
Smile in mirror
Example
READ height of rectangle
READ width of rectangle
COMPUTE area as height times width
Common Action Keywords
Several keywords are often used to indicate common input, output, and processing
operations.
Input: READ, OBTAIN, GET
Output: PRINT, DISPLAY, SHOW
Compute: COMPUTE, CALCULATE, DETERMINE

Initialize: SET, INIT
Add one: INCREMENT, BUMP
IF-THEN-ELSE
Binary choice on a given Boolean condition is indicated by the use of four keywords: IF,
THEN, ELSE, and ENDIF. The general form is:
IF condition THEN
sequence 1
ELSE
sequence 2
ENDIF
The ELSE keyword and "sequence 2" are optional. If the condition is true, sequence 1 is
performed, otherwise sequence 2 is performed.
Example
IF HoursWorked > NormalMax THEN
Display overtime message
ELSE
Display regular time message
ENDIF
WHILE
The WHILE construct is used to specify a loop with a test at the top. The beginning and
ending of the loop are indicated by two keywords WHILE and ENDWHILE. The general
form is:
WHILE condition
sequence
ENDWHILE
The loop is entered only if the condition is true. The "sequence" is performed for each
iteration. At the conclusion of each iteration, the condition is evaluated and the loop
continues as long as the condition is true.
Example
WHILE Population < Limit
Compute Population as Population + Births - Deaths
ENDWHILE
Example
WHILE employee.type NOT EQUAL manager AND personCount < numEmployees
INCREMENT personCount
CALL employeeList.getPerson with personCount RETURNING employee
ENDWHILE
CASE

Session3

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Session3

Semelhante a Session3 (20)

Último

Último (20)

Session3