Top Banner
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
170
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Session 3

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

Page 2: Session 3

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 .

Page 3: Session 3

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

Page 4: Session 3

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.

Page 5: Session 3

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 CycleFrom Wikipedia, the free encyclopedia

Jump to: navigation, searchThis 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.

Page 6: Session 3

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. Implementation

2. Testing

3. Evaluation

or

1. Feasibility Study

2. Analysis

3. Design4. Development

5. Implementation

6. Maintenance

or

1. Feasibility Study

2. Analysis

3. Design4. Implementation

5. Maintenance

or

1. Feasibility Study

2. Analysis

3. Design4. Development

5. Testing6. Implementation

7. Maintenance

or

1. Analysis (includingFeasibility Study)

2. Design

3. Development

4. Implementation

5. Evaluation

or

Page 7: Session 3

1. Feasibility Study

2. Analysis

3. Design4. Implementation

5. Testing6. Evaluation

7. Maintenance

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

Page 8: Session 3

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 byo 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

Page 9: Session 3

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

Page 10: Session 3

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

Page 11: Session 3

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

Page 12: Session 3

o 10.1 Secondary references

11 External links

[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):

Page 13: Session 3

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).

Page 14: Session 3

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

Page 15: Session 3

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):

Page 16: Session 3

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

Page 17: Session 3

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

Page 18: Session 3

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

Page 19: Session 3

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

Page 20: Session 3

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.

Page 21: Session 3

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

Page 22: Session 3

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

Page 23: Session 3

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

Page 24: Session 3

(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'"

Page 25: Session 3

(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

Page 26: Session 3

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)

Page 27: Session 3

[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

7 External links

[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

Page 28: Session 3

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): <?phpif (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 orderelse show a generic failure messageend if

The pseudocode of the Hello world program is particularly simple:

output Hello World

[edit] Mathematical style pseudocode

Page 29: Session 3

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).

Page 30: Session 3

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.

Page 31: Session 3

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)

Page 32: Session 3

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?

Page 33: Session 3

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 item2. get sales tax rate3. sales tax = price of time times sales tax rate4 final prince = price of item plus sales tax5. display final price6. 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

Page 34: Session 3

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 worked2. get pay rate3. if hours worked ≤ 40 then

3.1 gross pay = pay rate times hours worked4. else

4.1 gross pay = pay rate times 40 plus 1.5 times pay rate times (hours worked minus 40)5. display gross pay6. 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 quizzes2. sum = 03. count = 04. while count < number of quizzes

4.1 get quiz grade4.2 sum = sum + quiz grade4.3 count = count + 1

5. average = sum / number of quizzes6. display average7. 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.

Page 35: Session 3

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.1    (subordinate) statement 2                     7.2    etc ...

Iterative (dot notation used for numbering subordinate statements)

        9.    while "condition"                      9.1    (subordinate) statement 1                     9.2    etc ...

Return to Comp 150 Home Page

Page 36: Session 3

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

Page 37: Session 3

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

Page 38: Session 3

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.

Page 39: Session 3

              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

          a = (year - 1901) modulo 28           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

Page 40: Session 3

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

        a = (year - 1901) modulo 28         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 ExamplesModified 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.

Page 41: Session 3

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 zeroSet grade counter to oneWhile grade counter is less than or equal to ten Input the next grade Add the grade into the totalendwhile Set the class average to the total divided by tenPrint the class average.

3.

Initialize total to zeroInitialize counter to zeroInput the first gradewhile the user has not as yet entered the sentinel

Page 42: Session 3

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 zeroinitialize failures to zeroinitialize student to onewhile 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

Page 43: Session 3

Print out appropriate heading and make it prettyWhile 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 set consec cntr to 1 endif set hold char = new char continue endif if new char < hold char if consec cntr < 3 set consec cntr to 1 endif set hold char = new char 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 endifend WhilePrint 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,

Page 44: Session 3

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:

Page 45: Session 3

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

Page 46: Session 3

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.

Page 47: Session 3

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 widthCommon 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, BUMPIF-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

Page 48: Session 3

sequence 1ELSE sequence 2ENDIFThe 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 messageELSE Display regular time messageENDIF

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 sequenceENDWHILEThe 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 - DeathsENDWHILE

Example

WHILE employee.type NOT EQUAL manager AND personCount < numEmployees INCREMENT personCountCALL employeeList.getPerson with personCount RETURNING employeeENDWHILE

CASE

A CASE construct indicates a multiway branch based on conditions that are mutually exclusive. Four keywords, CASE, OF, OTHERS, and ENDCASE, and conditions are used to indicate the various alternatives. The general form is:

CASE expression OF condition 1 : sequence 1 condition 2 : sequence 2

Page 49: Session 3

... condition n : sequence n OTHERS: default sequenceENDCASE

The OTHERS clause with its default sequence is optional. Conditions are normally numbers or characters

indicating the value of "expression", but they can be English statements or some other notation that specifies the condition under which the given sequence is to be performed. A certain sequence may be associated with more than one condition.

Example

        CASE  Title  OF                Mr      : Print "Mister"                Mrs     : Print "Missus"                Miss    : Print "Miss"                Ms      : Print "Mizz"                Dr      : Print "Doctor"        ENDCASE

Example

        CASE  grade  OF                A       : points = 4                B       : points = 3                C       : points = 2                D       : points = 1                F       : points = 0        ENDCASE

REPEAT-UNTIL

This loop is similar to the WHILE loop except that the test is performed at the bottom of the loop instead of at the top. Two keywords, REPEAT and UNTIL are used. The general form is:

REPEAT sequenceUNTIL conditionThe "sequence" in this type of loop is always performed at least once, because the test is peformed after the sequence is executed. At the conclusion of each iteration, the condition is evaluated, and the loop repeats if the condition is false. The loop terminates when the condition becomes true.  

Page 50: Session 3

FOR

This loop is a specialized construct for iterating a specific number of times, often called a "counting" loop.  Two keywords, FOR and ENDFOR are used. The general form is:

FOR iteration bounds sequenceENDFORIn cases where the loop constraints can be obviously inferred it is best to describe the loop using problem domain vocabulary.

Example

FOR each month of the year (good) FOR month = 1 to 12 (ok)

FOR each employee in the list (good) FOR empno = 1 to listsize (ok)

NESTED CONSTRUCTS

The constructs can be embedded within each other, and this is made clear by use of indenting. Nested constructs should be clearly indented from their surrounding constructs.

Example

SET total to zero REPEAT READ Temperature IF Temperature > Freezing THEN     INCREMENT total END IFUNTIL Temperature < zero Print total

In the above example, the IF construct is nested within the REPEAT construct, and therefore is indented.    

INVOKING SUBPROCEDURES

Use the CALL keyword. For example:

CALL AvgAge with StudentAges CALL Swap with CurrentItem and TargetItem

Page 51: Session 3

CALL Account.debit with CheckAmount CALL getBalance RETURNING aBalance CALL SquareRoot with orbitHeight RETURNING nominalOrbit

EXCEPTION HANDLING

    BEGIN         statements     EXCEPTION         WHEN exception type             statements to handle exception        WHEN another exception type             statements to handle exception    END

Sample Pseudocode

"Adequate"

FOR X = 1 to 10     FOR Y = 1 to 10         IF gameBoard[X][Y] = 0             Do nothing         ELSE             CALL theCall(X, Y) (recursive method)             increment counter                          END IF    END FOREND FOR

"Better"

Set moveCount to 1FOR each row on the board     FOR each column on the board         IF gameBoard position (row, column) is occupied THEN

            CALL findAdjacentTiles with row, column            INCREMENT moveCount         END IF     END FOREND FOR

(Note: the logic is restructured to omit the "do nothing" clause)

Page 52: Session 3

"Not So Good"

FOR all the number at the back of the array     SET Temp equal the addition of each number     IF > 9 THEN         get the remainder of the number divided by 10 to that index         and carry the "1"     Decrement one Do it again for numbers before the decimal  

"Good Enough (not perfect)"

SET Carry to 0 FOR each DigitPosition in Number from least significant to most

significant

    COMPUTE Total as sum of FirstNum[DigitPosition] and

SecondNum[DigitPosition] and Carry  

    IF Total > 10 THEN         SET Carry to 1         SUBTRACT 10 from Total     ELSE         SET Carry to 0     END IF

    STORE Total in Result[DigitPosition]

END LOOP  

IF Carry = 1 THEN     RAISE Overflow exception END IF  

"Pretty Good"  This example shows how pseudocode is written as comments in the source file. Note that the double slashes are indented.

public boolean moveRobot (Robot aRobot) {     //IF robot has no obstacle in front THEN

Page 53: Session 3

        // Call Move robot         // Add the move command to the command history         // RETURN true     //ELSE         // RETURN false without moving the robot     //END IF }

Example Java Implementation

source code statements are interleaved with pseudocode. comments that correspond exactly to source code are removed during coding.

public boolean moveRobot (Robot aRobot) {     //IF robot has no obstacle in front THEN     if (aRobot.isFrontClear())     {         // Call Move robot         aRobot.move();         // Add the move command to the command history         cmdHistory.add(RobotAction.MOVE);         return true;     }     else // don't move the robot     {         return false;     }//END IF }  

  Examples of vague pseudocode

 

Document History

Date Author Change

12/2/03 JD Added Exception Handling and more examples

2/21/03 JDAdded "problem domain vocabulary" paragraph. Modified FOR loop explanation.

 

Page 54: Session 3

Algorithms for calculating varianceFrom Wikipedia, the free encyclopedia

Jump to: navigation, search

Algorithms for calculating variance play a minor role in statistical computing. A key problem in the design of good algorithms for this problem is that formulas for the variance may involve sums of squares, which can lead to numerical instability as well as to arithmetic overflow when dealing with large values.

Contents

[hide] 1 Algorithm I 2 Algorithm II 3 Algorithm II (compensated) 4 Algorithm III 5 Algorithm IV 6 Example 7 See also 8 References

9 External links

[edit] Algorithm I

The formula for calculating the variance of an entire population of size n is:

The formula for calculating an unbiased estimate of the population variance from a finite sample of n observations is:

Therefore a naive algorithm to calculate the estimated variance is given by the following pseudocode:

n = 0sum = 0sum_sqr = 0

foreach x in data: n = n + 1 sum = sum + x sum_sqr = sum_sqr + x*xend for

mean = sum/n

Page 55: Session 3

variance = (sum_sqr - sum*mean)/(n - 1)

This algorithm can easily be adapted to compute the variance of a finite population: simply divide by n instead of n − 1 on the last line.

Because sum_sqr and sum * mean can be very similar numbers, the precision of the result can be much less than the inherent precision of the floating-point arithmetic used to perform the computation. This is particularly bad if the variance is small relative to the sum of the numbers.

[edit] Algorithm II

An alternate approach, using a different formula for the variance, is given by the following pseudocode:

n = 0sum1 = 0foreach x in data: n = n + 1 sum1 = sum1 + xend formean = sum1/n

sum2 = 0foreach x in data: sum2 = sum2 + (x - mean)^2end forvariance = sum2/(n - 1)

This algorithm is often more numerically reliable than Algorithm I for large sets of data, although it can be worse if much of the data is very close to but not precisely equal to the mean and some are quite far away from it.

The results of both of these simple algorithms (I and II) can depend inordinately on the ordering of the data and can give poor results for very large data sets due to repeated roundoff error in the accumulation of the sums. Techniques such as compensated summation can be used to combat this error to a degree.

[edit] Algorithm II (compensated)

The compensated-summation version of the algorithm above reads:

n = 0sum1 = 0foreach x in data: n = n + 1 sum1 = sum1 + xend formean = sum1/n

Page 56: Session 3

sum2 = 0sumc = 0foreach x in data: sum2 = sum2 + (x - mean)^2 sumc = sumc + (x - mean)end forvariance = (sum2 - sumc^2/n)/(n - 1)

[edit] Algorithm III

The following formulas can be used to update the mean and (estimated) variance of the sequence, for an additional element xnew. Here, m denotes the estimate of the population mean, s2

n-1 the estimate of the population variance, s2n the estimate of the sample variance,

and n the number of elements in the sequence before the addition.

A numerically stable algorithm is given below. It also computes the mean. This algorithm is due to Knuth,[1] who cites Welford.[2]

n = 0mean = 0S = 0

foreach x in data: n = n + 1 delta = x - mean mean = mean + delta/n S = S + delta*(x - mean) // This expression uses the new value of meanend for

variance = S/(n - 1)

This algorithm is much less prone to loss of precision due to massive cancellation, but might not be as efficient because of the division operation inside the loop. For a particularly robust two-pass algorithm for computing the variance, first compute and subtract an estimate of the mean, and then use this algorithm on the residuals.

[edit] Algorithm IV

When the observations are weighted, West (1979) [3] suggests this incremental algorithm:

n = 0foreach x in the data: if n=0 then n = 1 mean = x S = 0 sumweight = weight else n = n + 1

Page 57: Session 3

temp = weight + sumweight S = S + sumweight*weight*(x-mean)^2 / temp mean = mean + (x-mean)*weight / temp sumweight = temp end ifend forVariance = S * sumweight * n / (n-1) // if sample is the population, omit n/(n-1)

[edit] Example

Assume that all floating point operations use the standard IEEE 754 double-precision arithmetic. Consider the sample (4, 7, 13, 16) from an infinite population. Based on this sample, the estimated population mean is 10, and the unbiased estimate of population variance is 30. Both Algorithm I and Algorithm II compute these values correctly. Next consider the sample (108 + 4, 108 + 7, 108 + 13, 108 + 16), which gives rise to the same estimated variance as the first sample. Algorithm II computes this variance estimate correctly, but Algorithm I returns 29.333333333333332 instead of 30. While this loss of precision may be tolerable and viewed as a minor flaw of Algorithm I, it is easy to find data that reveal a major flaw in the naive algorithm: Take the sample to be (109 + 4, 109 + 7, 109 + 13, 109 + 16). Again the estimated population variance of 30 is computed correctly by Algorithm II, but the naive algorithm now computes it as -170.66666666666666. This is a serious problem with Algorithm I because by definition the variance can never be negative.

Not to be confused with Euclidean geometry.

In number theory, the Euclidean algorithm (also called Euclid's algorithm) is an algorithm to determine the greatest common divisor (GCD) of two elements of any Euclidean domain (for example, the integers). Its major significance is that it does not require factoring the two integers, and it is also significant in that it is one of the oldest algorithms known, dating back to the ancient Greeks.

Contents

[hide] 1 History of the Euclidean algorithm 2 Description of the algorithm

o 2.1 Using recursion o 2.2 Using iteration o 2.3 The extended Euclidean algorithm o 2.4 Original algorithm

3 An example 4 Proof

Page 58: Session 3

5 Running time 6 Relation with continued fractions 7 Generalization to Euclidean domains 8 See also 9 References

10 External links

[edit] History of the Euclidean algorithm

The Euclidean algorithm is one of the oldest algorithms known, since it appeared in Euclid's Elements around 300 BC. Euclid originally formulated the problem geometrically, as the problem of finding a common "measure" for two line lengths, and his algorithm proceeded by repeated subtraction of the shorter from the longer segment. However, the algorithm was probably not discovered by Euclid and it may have been known up to 200 years earlier. It was almost certainly known by Eudoxus of Cnidus (about 375 BC), and Aristotle (about 330 BC) hinted at it in his Topics, 158b, 29-35.

[edit] Description of the algorithm

Given two natural numbers a and b, not both equal to zero: check if b is zero; if yes, a is the gcd. If not, repeat the process using, respectively, b, and the remainder after dividing a by b. The remainder after dividing a by b is usually written as a mod b.

These algorithms can be used in any context where division with remainder is possible. This includes rings of polynomials over a field as well as the ring of Gaussian integers, and in general all Euclidean domains. Applying the algorithm to the more general case other than natural number will be discussed in more detail later in the article.

[edit] Using recursion

Using recursion, the algorithm can be expressed:

function gcd(a, b) if b = 0 return a else return gcd(b, a mod b)

[edit] Using iteration

An efficient, iterative method, for compilers that don't optimize tail recursion:

function gcd(a, b) while b ≠ 0 t := b b := a mod b a := t return a

Page 59: Session 3

[edit] The extended Euclidean algorithm

Main article: extended Euclidean algorithm

By keeping track of the quotients occurring during the algorithm, one can also determine integers p and q with ap + bq = gcd(a, b). This is known as the extended Euclidean algorithm.

[edit] Original algorithm

The original algorithm as described by Euclid treated the problem geometrically, using repeated subtraction rather than mod (remainder).

function gcd(a, b) while b ≠ 0 if a > b a := a - b else b := b - a return a

Notice that while b can be zero, a cannot be zero; otherwise, this becomes an infinite loop. This algorithm does not require an extra variable t.

[edit] An example

As an example, consider computing the gcd of 1071 and 1029, which is 21. Recall that “mod” means “the remainder after dividing.”

With the recursive algorithm:

a b Explanations

gcd( 1071, 1029) The initial arguments

= gcd( 1029, 42) The second argument is 1071 mod 1029

= gcd( 42, 21) The second argument is 1029 mod 42

= gcd( 21, 0) The second argument is 42 mod 21

Page 60: Session 3

= 21 Since b=0, we return a

With the iterative algorithm:

a b Explanation

1071 1029 Step 1: The initial inputs

1029 42Step 2: The remainder of 1071 divided by 1029 is 42, which is put on the right, and the divisor 1029 is put on the left.

42 21 Step 3: We repeat the loop, dividing 1029 by 42, and get 21 as remainder.

21 0Step 4: Repeat the loop again, since 42 is divisible by 21, we get 0 as remainder, and the algorithm terminates. The number on the left, that is 21, is the gcd as required.

Observe that a ≥ b in each call. If initially, b > a, there is no problem; the first iteration effectively swaps the two values.

[edit] Proof

Suppose a and b are the natural numbers whose gcd has to be determined. Now, suppose b > 0, and the remainder of the division of a by b is r. Therefore a = qb + r where q is the quotient of the division.

Any common divisor of a and b is also a divisor of r. To see why this is true, consider that r can be written as r = a − qb. Now, if there is a common divisor d of a and b such that a = sd and b = td, then r = (s−qt)d. Since all these numbers, including s−qt, are whole numbers, it can be seen that r is divisible by d.

The above analysis is true for any divisor d; thus, the greatest common divisor of a and b is also the greatest common divisor of b and r. Therefore it is enough if we continue searching for the greatest common divisor with the numbers b and r. Since r is smaller in absolute value than b, we will reach r = 0 after finitely many steps.

Page 61: Session 3

[edit] Running time

Plot of the running time for gcd(x,y). Red indicates a fast computation, while successively bluer points indicate slower computations

When analyzing the running time of Euclid's algorithm, it turns out that the inputs requiring the most divisions are two successive Fibonacci numbers (because their ratios are the convergents in the slowest continued fraction expansion to converge, that of the golden ratio) as proved by Gabriel Lamé, and the worst case requires O ( n ) divisions, where n is the number of digits in the input. However, the divisions themselves are not constant time operations; the actual time complexity of the algorithm is O(n2). The reason is that division of two n-bit numbers takes time O(n(m + 1)), where m is the length of the quotient. Consider the computation of gcd(a,b) where a and b have at most n bits, let be the sequence of numbers produced by the algorithm, and let be their lengths. Then k = O(n), and the running time is bounded by

This is considerably better than Euclid's original algorithm, in which the modulus operation is effectively performed using repeated subtraction in O(2n) steps. Consequently, that version of the algorithm requires O(2nn) time for n-digit numbers, or time for the number m.

Euclid's algorithm is widely used in practice, especially for small numbers, due to its simplicity. An alternative algorithm, the binary GCD algorithm, exploits the binary representation used by computers to avoid divisions and thereby increase efficiency, although it too is O(n²); it merely shrinks the constant hidden by the big-O notation on many real machines.

There are more complex algorithms that can reduce the running time to O(n(logn)2(loglogn)). See Computational complexity of mathematical operations for more details.

[edit] Relation with continued fractions

The quotients that appear when the Euclidean algorithm is applied to the inputs a and b are precisely the numbers occurring in the continued fraction representation of a/b. Take for instance the example of a = 1071 and b = 1029 used above. Here is the calculation with highlighted quotients:

1071 = 1029 × 1 + 42 1029 = 42 × 24 + 21 42 = 21 × 2 + 0

Consequently,

Page 62: Session 3

.

This method applies to arbitrary real inputs a and nonzero b; if a/b is irrational, then the Euclidean algorithm does not terminate, but the computed sequence of quotients still represents the (now infinite) continued fraction representation of a/b.

The quotients 1,24,2 count certain squares nested within a rectangle R having length 1071 and width 1029, in the following manner:

(1) there is 1 1029×1029 square in R whose removal leaves a 42×1029 rectangle, R1;

(2) there are 24 42×42 squares in R1 whose removal leaves a 21×42 rectangle, R2;

(3) there are 2 21×21 squares in R2 whose removal leaves nothing.

The "visual Euclidean algorithm" of nested squares applies to an arbitrary rectangle R. If the (length)/(width) of R is an irrational number, then the visual Euclidean algorithm extends to a visual continued fraction.

[edit] Generalization to Euclidean domains

The Euclidean algorithm can be applied to some rings, not just the integers. The most general context in which the algorithm terminates with the greatest common divisor is in a Euclidean domain. For instance, the Gaussian integers and polynomial rings over a field are both Euclidean domains.

As an example, consider the ring of polynomials with rational coefficients. In this ring, division with remainder is carried out using long division, also known as synthetic division. The resulting polynomials are then made monic by factoring out the leading coefficient.

We calculate the greatest common divisor of

x4 − 4x3 + 4x2 − 3x + 14 = (x2 − 5x + 7)(x2 + x + 2)

and

x4 + 8x3 + 12x2 + 17x + 6 = (x2 + 7x + 3)(x2 + x + 2).

Following the algorithm gives these values:

a b

Page 63: Session 3

x4 + 8x3 + 12x2 + 17x + 6 x4 − 4x3 + 4x2 − 3x + 14

x4 − 4x3 + 4x2 − 3x + 14

x2 + x + 2

x2 + x + 2 0

This agrees with the explicit factorization. For general Euclidean domains, the proof of correctness is by induction on some size function. For the integers, this size function is just the identity. For rings of polynomials over a field, it is the degree of the polynomial (note that each step in the above table reduces the degree by one).

[edit] See also

Least common multiple Extended Euclidean algorithm Binary GCD algorithm Lehmer's GCD algorithm

[edit] References

Donald Knuth . The Art of Computer Programming, Volume 2: Seminumerical Algorithms, Third Edition. Addison-Wesley, 1997. ISBN 0-201-89684-2. Sections 4.5.2–4.5.3, pp.333–379.

Thomas H. Cormen , Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms, Second Edition. MIT Press and McGraw-Hill, 2001. ISBN 0-262-03293-7. Section 31.2: Greatest common divisor, pp.856–862.

Clark Kimberling . "A Visual Euclidean Algorithm," Mathematics Teacher 76 (1983) 108-109.

[edit] External links

Euclid's Algorithm at cut-the-knot Binary Euclid's Algorithm (Java) at cut-the-knot Euclid's Game (Java) at cut-the-knot Eric W. Weisstein , Euclidean Algorithm at MathWorld. Eric W. Weisstein , Lamé's Theorem at MathWorld. Euclid's algorithm at PlanetMath.

Page 64: Session 3

Music and Euclid's algorithm Implementation in Javascript .NET Implementation of Euclidean algorithm

A flowchart (also spelled flow-chart and flow chart) is a schematic representation of an algorithm or a process.

A flowchart is one of the seven basic tools of quality control, which also includes the histogram, Pareto chart, check sheet, control chart, cause-and-effect diagram, and scatter diagram (see Quality Management Glossary). They are commonly used in business/economic presentations to help the audience visualize the content better, or to find flaws in the process. Alternatively, one can use Nassi-Shneiderman diagrams.

A flowchart is described as "cross-functional" when the page is divided into different "lanes" describing the control of different organizational units. A symbol appearing in a particular "lane" is within the control of that organizational unit. This technique allows the analyst to locate the responsibility for performing an action or making a decision correctly, allowing the relationship between different organizational units with responsibility over a single process.

Contents [hide]1 History2 Software 2.1 Manual2.2 Automatic3 Examples4 Symbols5 References6 See also7 External links

[edit]History

The first structured method for documenting process flow, the flow process chart, was introduced by Frank Gilbreth to members of ASME in 1921 as the presentation “Process Charts—First Steps in Finding the One Best Way”. Gilbreth's tools quickly found their way into industrial engineering curricula. In the early 1930s, an industrial engineer, Allan H. Mogensen began training business people in the use of some of the tools of industrial engineering at his Work Simplification Conferences in Lake Placid, New York.

Page 65: Session 3

A 1944 graduate of Mogensen's class, Art Spinanger, took the tools back to Procter and Gamble where he developed their Deliberate Methods Change Program. Another 1944 graduate, Ben S. Graham, Director of Formcraft Engineering at Standard Register Corporation, adapted the flow process chart to information processing with his development of the multi-flow process chart to displays multiple documents and their relationships. In 1947, ASME adopted a symbol set derived from Gilbreth's original work as the ASME Standard for Process Charts.

According to Herman Goldstine, he developed flowcharts with John von Neumann at Princeton University in late 1946 and early 1947.[1]

[edit]Software

[edit]Manual

Any vector-based drawing program can be used to create flowcharts. Some tools offer special support for flowcharts, e.g., ConceptDraw and SmartDraw.

[edit]Automatic

Many software packages exist that can create flowcharts automatically, either directly from source code, or from a flowchart description language:

For example, Graph::Easy, a Perl package, takes a textual description of the graph, and uses the description to generate various output formats including HTML, ASCII or SVG. The example graph listed below was generated from the text shown below. The automatically generated SVG output is shown on the right: A simple flowchart, created automatically.graph { flow: south; }node.start { shape: rounded; fill: #ffbfc9; }node.question { shape: diamond; fill: #ffff8a; }node.action { shape: rounded; fill: #8bef91; }

[ Lamp doesn't work ] { class: start } --> [ Lamp\n plugged in? ] { class: question; } -- No --> [ Plug in lamp ] { class: action; }

[ Lamp\n plugged in? ] --> [ Bulb\n burned out? ] { class: question; } -- Yes --> [ Replace bulb ] { class: action; }

[ Bulb\n burned out? ]

Page 66: Session 3

-- No --> [ Buy new lamp ] { class: action; }

There exist also various MediaWiki Extensions to incorporate flowchart descriptions directly into wiki articles.

[edit]Examples A simple flowchart for computing factorial N (N!)

A flowchart for computing factorial N (N!) Where N! = 1 * 2 * 3 *...* N. This flowchart would be difficult to program directly into a computer programming language since the flowchart represents "a loop and a half" — a situation discussed in introductory programming textbooks that requires either a duplication of a component (to be both inside and outside the loop) or the component to be put inside a branch in the loop.

Since computer programming languages do not contain all of the constructs that can be created by the drawing of flowcharts, they do not often help new programmers learn the concepts of logical flow and program structure. To try writing flowcharts for computer programs, an on-line applet for iconic programming is available that limits the flowchart components and connections to those that can be directly converted into any programming language. (Note: click on the yellow square to begin.)!

[edit]Symbols

A typical flowchart from older Computer Science textbooks may have the following kinds of symbols:Start and end symbols, represented as lozenges, ovals or rounded rectangles, usually containing the word "Start" or "End", or another phrase signaling the start or end of a process, such as "submit enquiry" or "receive product".Arrows, showing what's called "flow of control" in computer science. An arrow coming from one symbol and ending at another symbol represents that control passes to the symbol the arrow points to.Processing steps, represented as rectangles. Examples: "Add 1 to X"; "replace identified part"; "save changes" or similar.Input/Output, represented as a parallelogram. Examples: Get X from the user; display X.Conditional (or decision), represented as a diamond (rhombus). These typically contain a Yes/No question or True/False test. This symbol is unique in that it has two arrows coming out of it, usually from the bottom point and right point, one corresponding to Yes or True, and one corresponding to No or False. The arrows should always be labeled. More than two arrows can be used, but this is normally a

Page 67: Session 3

clear indicator that a complex decision is being taken, in which case it may need to be broken-down further, or replaced with the "pre-defined process" symbol.A number of other symbols that have less universal currency, such as: A Document represented as a rectangle with a wavy base;A Manual input represented by rectangle, with the top irregularly sloping up from left to right. An example would be to signify data-entry from a form;A Manual operation represented by a trapezoid with the longest parallel side at the top, to represent an operation or adjustment to process that can only be made manually.A Data File represented by a cylinderNote: All process symbols within a flowchart should be numbered. Normally a number is inserted inside the top of the shape to indicate which step the process is within the flowchart.

Flowcharts may contain other symbols, such as connectors, usually represented as circles, to represent converging paths in the flow chart. Circles will have more than one arrow coming into them but only one going out. Some flow charts may just have an arrow point to another arrow instead. These are useful to represent an iterative process (what in Computer Science is called a loop). A loop may, for example, consist of a connector where control first enters, processing steps, a conditional with one arrow exiting the loop, and one going back to the connector. Off-page connectors are often used to signify a connection to a (part of another) process held on another sheet or screen. It is important to remember to keep these connections logical in order. All processes should flow from top to bottom and left to right.

C Data types.

Variable declarationC has a concept of 'data types' which are used to declare a variable before its use.

The declaration of a variable will assign storage for the variable and define the type of data that will be held in the location.

So what data types are available? int float double char void enum

Please note that there is not a boolian data type. C does not have the traditional view about logical comparison, but thats another story.

int - data typeint is used to define integer numbers.

{ int Count;

Page 68: Session 3

Count = 5;}

float - data typefloat is used to define floating point numbers. { float Miles; Miles = 5.6; }double - data typedouble is used to define BIG floating point numbers. It reserves twice the storage for the number. On PCs this is likely to be 8 bytes. { double Atoms; Atoms = 2500000; }char - data typechar defines characters. { char Letter; Letter = 'x'; }ModifiersThe three data types above have the following modifiers.

short long signed unsigned The modifiers define the amount of storage allocated to the variable. The amount of storage allocated is not cast in stone. ANSI has the following rules:

short int <= LONG What this means is that a 'short int' should assign less than or the same amount of storage as an 'int' and the 'int' should be less bytes than a 'long int'. What this means in the real world is:

short int - 2 bytes (16 bits) int int - 2 bytes (16 bits) long int - 4 bytes (32 bits) signed char - 1 byte (Range -128 ... +127)unsigned char - 1 byte (Range 0 ... 255) float - 4 bytes double - 8 bytes long double - 8 bytes

These figures only apply to todays generation of PCs. Mainframes and midrange machines could use different figures, but would still comply with the rule above.

Page 69: Session 3

You can find out how much storage is allocated to a data type by using the sizeof operator. Qualifiers

const Volatile The const qualifier is used to tell C that the variable value can not change after initialisation.

const float pi=3.14159;

pi cannot be changed at a later time within the program.

Another way to define constants is with the #define preprocessor which has the advantage that it does not use any storage (but who counts bytes these days?).

See also:Data type conversion

Storage classes.

cast

typedef keyword.

I have had several sugestions on how to describe volatile, If you have any input please mail me. The volatile keyword acts as a data type qualifier. The qualifier alters the default why in which the compiler handles the variable and does not attempt to optimize the storage referenced by it. Martin Leslie

volatile means the storage is likely to change at anytime and be changed but something outside the control of the user program. This means that if you reference the variable, the program should always check the physical address (ie a mapped input fifo), and not use it in a cashed way. Stephen Hunt

Here is an example for the usage of the volatile keyword: /* Base address of the data input latch */

volatile unsigned char *baseAddr;

/* read parts of output latch */

lsb = *handle->baseAddr;

Page 70: Session 3

middle = *handle->baseAddr;msb = *handle->baseAddr;

Between reads the bytes are changed in the latch.

Without the volatile, the compiler optimises this to a single assignment: lsb = middle = msb = *handle->baseAddr;

Tim Potter

A volatile variable is for dynamic use. E.G. for data that is to be passed to an I/O port Here is an example.

#define TTYPORT 0x17755U

volatile char *port17 = (char)*TTYPORT;*port17 = 'o';*port17 = 'N';

Without the volatile modifier, the compiler would think that the statement *port17 = 'o'; is redundant and would remove it from the object code. The volatile statement prevents the compiler optimisation.

Data type conversionAn operator must have operands of the same type before it can carry out the operation. Because of this, C will perform some automatic conversion of data types.

These are the general rules for binary operators (* + / % etc):

If either operand is long double the other is converted to long double.

Otherwise, if either operand is double the other is converted to double

Otherwise, if either operand is float the other is converted to float

Otherwise, convert char and short to int

Then, if an operand is long convert the other to long.

C Storage Classes.

C has a concept of 'Storage classes' which are used to define the scope (visability) and life time of variables and/or functions.

So what Storage Classes are available? auto register static extern typedef

Page 71: Session 3

auto - storage classauto is the default storage class for local variables.

{ int Count; auto int Month;}

The example above defines two variables with the same storage class. auto can only be used within functions, i.e. local variables.

register - Storage Classregister is used to define local variables that should be stored in a register instead of RAM. This means that the variable has a maximum size equal to the register size (usually one word) and cant have the unary '&' operator applied to it (as it does not have a memory location).

{ register int Miles;}

Register should only be used for variables that require quick access - such as counters. It should also be noted that defining 'register' goes not mean that the variable will be stored in a register. It means that it MIGHT be stored in a register - depending on hardware and implimentation restrictions.

static - Storage Classstatic is the default storage class for global variables. The two variables below (count and road) both have a static storage class.

static int Count; int Road;

{ printf("%d\n", Road); }static variables can be 'seen' within all functions in this source file. At link time, the static variables defined here will not be seen by the object modules that are brought in.

'static' can also be defined within a function! If this is done the variable is initalised at run time but is not reinitalized when the function is called. This is serious stuff - tread with care.

{ static Count=1;

}Here is an example

There is one very important use for 'static'. Consider this bit of code. char * func(void);

Page 72: Session 3

main() { char *Text1; Text1 = func(); }

char * func(void) { char Text2[10]="martin"; return(Text2); }Now, 'func' returns a pointer to the memory location where 'text2' starts BUT text2 has a storage class of 'auto' and will disappear when we exit the function and could be overwritten but something else. The answer is to specify

static char Text[10]="martin";The storage assigned to 'text2' will remain reserved for the duration if the program.

extern - storage Classextern defines a global variable that is visable to ALL object modules. When you use 'extern' the variable cannot be initalized as all it does is point the variable name at a storage location that has been previously defined.

Source 1 Source 2 -------- --------

extern int count; int count=5;

write() main() { { printf("count is %d\n", count); write(); } }Count in 'source 1' will have a value of 5. If source 1 changes the value of count - source 2 will see the new value. Here are some example source files.

Source 1Source 2

The compile command will look something like.

gcc source1.c source2.c -o program

8.4. Const and volatile

Page 73: Session 3

These are new in Standard C, although the idea of const has been borrowed from C++. Let us get one thing straight: the concepts of const and volatile are completely independent. A common misconception is to imagine that somehow const is the opposite of volatile and vice versa. They are unrelated and you should remember the fact.

Since const declarations are the simpler, we'll look at them first, but only after we have seen where both of these type qualifiers may be used. The complete list of relevant keywords ischar long float volatileshort signed double voidint unsigned const

In that list, const and volatile are type qualifiers, the rest are type specifiers. Various combinations of type specifiers are permitted:char, signed char, unsigned charint, signed int, unsigned intshort int, signed short int, unsigned short intlong int, signed long int, unsigned long intfloatdoublelong double

A few points should be noted. All declarations to do with an int will be signed anyway, so signed is redundant in that context. If any other type specifier or qualifier is present, then the int part may be dropped, as that is the default.

The keywords const and volatile can be applied to any declaration, including those of structures, unions, enumerated types or typedef names. Applying them to a declaration is called qualifying the declaration—that's why const and volatile are called type qualifiers, rather than type specifiers. Here are a few representative examples:volatile i;volatile int j;const long q;const volatile unsigned long int rt_clk;struct{ const long int li; signed char sc;}volatile vs;

Don't be put off; some of them are deliberately complicated: what they mean will be explained later. Remember that they could also be further complicated by introducing storage class specifications as well! In fact, the truly spectacularextern const volatile unsigned long int rt_clk;

is a strong possibility in some real-time operating system kernels.

Page 74: Session 3

8.4.1. Const

Let's look at what is meant when const is used. It's really quite simple: const means that something is not modifiable, so a data object that is declared with const as a part of its type specification must not be assigned to in any way during the run of a program. It is very likely that the definition of the object will contain an initializer (otherwise, since you can't assign to it, how would it ever get a value?), but this is not always the case. For example, if you were accessing a hardware port at a fixed memory address and promised only to read from it, then it would be declared to be const but not initialized.

Taking the address of a data object of a type which isn't const and putting it into a pointer to the const-qualified version of the same type is both safe and explicitly permitted; you will be able to use the pointer to inspect the object, but not modify it. Putting the address of a const type into a pointer to the unqualified type is much more dangerous and consequently prohibited (although you can get around this by using a cast). Here is an example:#include <stdio.h>#include <stdlib.h>

main(){ int i; const int ci = 123;

/* declare a pointer to a const.. */ const int *cpi;

/* ordinary pointer to a non-const */ int *ncpi;

cpi = &ci; ncpi = &i;

/* * this is allowed */ cpi = ncpi;

/* * this needs a cast * because it is usually a big mistake, * see what it permits below. */ ncpi = (int *)cpi;

/* * now to get undefined behaviour... * modify a const through a pointer

Page 75: Session 3

*/ *ncpi = 0;

exit(EXIT_SUCCESS);}Example 8.3

As the example shows, it is possible to take the address of a constant object, generate a pointer to a non-constant, then use the new pointer. This is an error in your program and results in undefined behaviour.

The main intention of introducing const objects was to allow them to be put into read-only store, and to permit compilers to do extra consistency checking in a program. Unless you defeat the intent by doing naughty things with pointers, a compiler is able to check that const objects are not modified explicitly by the user.

An interesting extra feature pops up now. What does this mean?char c;char *const cp = &c;

It's simple really; cp is a pointer to a char, which is exactly what it would be if the const weren't there. The const means that cp is not to be modified, although whatever it points to can be—the pointer is constant, not the thing that it points to. The other way round isconst char *cp;

which means that now cp is an ordinary, modifiable pointer, but the thing that it points to must not be modified. So, depending on what you choose to do, both the pointer and the thing it points to may be modifiable or not; just choose the appropriate declaration.8.4.2. Volatile

After const, we treat volatile. The reason for having this type qualifier is mainly to do with the problems that are encountered in real-time or embedded systems programming using C. Imagine that you are writing code that controls a hardware device by placing appropriate values in hardware registers at known absolute addresses.

Let's imagine that the device has two registers, each 16 bits long, at ascending memory addresses; the first one is the control and status register (csr) and the second is a data port. The traditional way of accessing such a device is like this:/* Standard C example but without const or volatile *//** Declare the device registers* Whether to use int or short* is implementation dependent*/

Page 76: Session 3

struct devregs{ unsigned short csr; /* control & status */ unsigned short data; /* data port */};

/* bit patterns in the csr */#define ERROR 0x1#define READY 0x2#define RESET 0x4

/* absolute address of the device */#define DEVADDR ((struct devregs *)0xffff0004)

/* number of such devices in system */#define NDEVS 4

/** Busy-wait function to read a byte from device n.* check range of device number.* Wait until READY or ERROR* if no error, read byte, return it* otherwise reset error, return 0xffff*/unsigned int read_dev(unsigned devno){

struct devregs *dvp = DEVADDR + devno;

if(devno >= NDEVS) return(0xffff);

while((dvp->csr & (READY | ERROR)) == 0) ; /* NULL - wait till done */

if(dvp->csr & ERROR){ dvp->csr = RESET; return(0xffff); }

return((dvp->data) & 0xff);}Example 8.4

The technique of using a structure declaration to describe the device register layout and names is very common practice. Notice that there aren't actually any objects of that type defined, so the declaration simply indicates the structure without using up any store.

Page 77: Session 3

To access the device registers, an appropriately cast constant is used as if it were pointing to such a structure, but of course it points to memory addresses instead.

However, a major problem with previous C compilers would be in the while loop which tests the status register and waits for the ERROR or READY bit to come on. Any self-respecting optimizing compiler would notice that the loop tests the same memory address over and over again. It would almost certainly arrange to reference memory once only, and copy the value into a hardware register, thus speeding up the loop. This is, of course, exactly what we don't want; this is one of the few places where we must look at the place where the pointer points, every time around the loop.

Because of this problem, most C compilers have been unable to make that sort of optimization in the past. To remove the problem (and other similar ones to do with when to write to where a pointer points), the keyword volatile was introduced. It tells the compiler that the object is subject to sudden change for reasons which cannot be predicted from a study of the program itself, and forces every reference to such an object to be a genuine reference.

Here is how you would rewrite the example, making use of const and volatile to get what you want./** Declare the device registers* Whether to use int or short* is implementation dependent*/

struct devregs{ unsigned short volatile csr; unsigned short const volatile data;};

/* bit patterns in the csr */#define ERROR 0x1#define READY 0x2#define RESET 0x4

/* absolute address of the device */#define DEVADDR ((struct devregs *)0xffff0004)

/* number of such devices in system */#define NDEVS 4

/** Busy-wait function to read a byte from device n.* check range of device number.* Wait until READY or ERROR

Page 78: Session 3

* if no error, read byte, return it* otherwise reset error, return 0xffff*/unsigned int read_dev(unsigned devno){

struct devregs * const dvp = DEVADDR + devno;

if(devno >= NDEVS) return(0xffff);

while((dvp->csr & (READY | ERROR)) == 0) ; /* NULL - wait till done */

if(dvp->csr & ERROR){ dvp->csr = RESET; return(0xffff); }

return((dvp->data) & 0xff);}Example 8.5

The rules about mixing volatile and regular types resemble those for const. A pointer to a volatile object can be assigned the address of a regular object with safety, but it is dangerous (and needs a cast) to take the address of a volatile object and put it into a pointer to a regular object. Using such a derived pointer results in undefined behaviour.

If an array, union or structure is declared with const or volatile attributes, then all of the members take on that attribute too. This makes sense when you think about it—how could a member of a const structure be modifiable?

That means that an alternative rewrite of the last example would be possible. Instead of declaring the device registers to be volatile in the structure, the pointer could have been declared to point to a volatile structure instead, like this:struct devregs{ unsigned short csr; /* control & status */ unsigned short data; /* data port */};volatile struct devregs *const dvp=DEVADDR+devno;

Since dvp points to a volatile object, it not permitted to optimize references through the pointer. Our feeling is that, although this would work, it is bad style. The volatile declaration belongs in the structure: it is the device registers which are volatile and that is where the information should be kept; it reinforces the fact for a human reader.

Page 79: Session 3

So, for any object likely to be subject to modification either by hardware or asynchronous interrupt service routines, the volatile type qualifier is important.

Now, just when you thought that you understood all that, here comes the final twist. A declaration like this:volatile struct devregs{ /* stuff */}v_decl;

declares the type struct devregs and also a volatile-qualified object of that type, called v_decl. A later declaration like thisstruct devregs nv_decl;

declares nv_decl which is not qualified with volatile! The qualification is not part of the type of struct devregs but applies only to the declaration of v_decl. Look at it this way round, which perhaps makes the situation more clear (the two declarations are the same in their effect):struct devregs{ /* stuff */}volatile v_decl;

If you do want to get a shorthand way of attaching a qualifier to another type, you can use typedef to do it:struct x{ int a;};typedef const struct x csx;

csx const_sx;struct x non_const_sx = {1};

const_sx = non_const_sx; /* error - attempt to modify a const */8.4.2.1. Indivisible Operations

Those of you who are familiar with techniques that involve hardware interrupts and other ‘real time’ aspects of programming will recognise the need for volatile types. Related to this area is the need to ensure that accesses to data objects are ‘atomic’, or uninterruptable. To discuss this is any depth would take us beyond the scope of this book, but we can at least outline some of the issues.

Be careful not to assume that any operations written in C are uninterruptable. For example,extern const volatile unsigned long realtimeclock;

could be a counter which is updated by a clock interrupt routine. It is essential to make it volatile because of the asynchronous updates to it, and it is marked const because it

Page 80: Session 3

should not be changed by anything other than the interrupt routine. If the program accesses it like this:unsigned long int time_of_day;

time_of_day = real_time_clock;

there may be a problem. What if, to copy one long into another, it takes several machine instructions to copy the two words making up real_time_clock and time_of_day? It is possible that an interrupt will occur in the middle of the assignment and that in the worst case, when the low-order word of real_time_clock is 0xffff and the high-order word is 0x0000, then the low-order word of time_of_day will receive 0xffff. The interrupt arrives and increments the low-order word of real_time_clock to 0x0 and then the high-order word to 0x1, then returns. The rest of the assignment then completes, with time_of_day ending up containing 0x0001ffff and real_time_clock containing the correct value, 0x00010000.

This whole class of problem is what is known as a critical region, and is well understood by those who regularly work in asynchronous environments. It should be understood that Standard C takes no special precautions to avoid these problems, and that the usual techniques should be employed.

The header ‘signal.h’ declares a type called sig_atomic_t which is guaranteed to be modifiable safely in the presence of asynchronous events. This means only that it can be modified by assigning a value to it; incrementing or decrementing it, or anything else which produces a new value depending on its previous value, is not safe.

8.2. Declarations, Definitions and Accessibility

Chapter 4 introduced the concepts of scope and linkage, showing how they can be combined to control the accessibility of things throughout a program. We deliberately gave a vague description of exactly what constitutes a definition on the grounds that it would give you more pain than gain at that stage. Eventually it has to be spelled out in detail, which we do in this chapter. Just to make things interesting, we need to throw in storage class too.

You'll probably find the interactions between these various elements to be both complex and confusing: that's because they are! We try to eliminate some of the confusion and give some useful rules of thumb in Section 8.2.6 below—but to understand them, you still need to read the stuff in between at least once.

For a full understanding, you need a good grasp of three distinct but related concepts. The Standard calls them:durationscopelinkage

Page 81: Session 3

and describes what they mean in a fairly readable way (for a standard). Scope and linkage have already been described in Chapter 4, although we do present a review of them below.8.2.1. Storage class specifiers

There are five keywords under the category of storage class specifiers, although one of them, typedef, is there more out of convenience than utility; it has its own section later since it doesn't really belong here. The ones remaining are auto, extern, register, and static.

Storage class specifiers help you to specify the type of storage used for data objects. Only one storage class specifier is permitted in a declaration—this makes sense, as there is only one way of storing things—and if you omit the storage class specifier in a declaration, a default is chosen. The default depends on whether the declaration is made outside a function (external declarations) or inside a function (internal declarations). For external declarations the default storage class specifier will be extern and for internal declarations it will be auto. The only exception to this rule is the declaration of functions, whose default storage class specifier is always extern.

The positioning of a declaration, the storage class specifiers used (or their defaults) and, in some cases, preceding declarations of the same name, can all affect the linkage of a name, although fortunately not its scope or duration. We will investigate the easier items first.8.2.1.1. Duration

The duration of an object describes whether its storage is allocated once only, at program start-up, or is more transient in its nature, being allocated and freed as necessary.

There are only two types of duration of objects: static duration and automatic duration. Static duration means that the object has its storage allocated permanently, automatic means that the storage is allocated and freed as necessary. It's easy to tell which is which: you only get automatic duration ifthe declaration is inside a functionand the declaration does not contain the static or extern keywordsand the declaration is not the declaration of a function

(if you work through the rules, you'll find that the formal parameters of a function always meet all three requirements—they are always ‘automatic’).

Although the presence of static in a declaration unambiguously ensures that it has static duration, it's interesting to see that it is by no means the only way. This is a notorious source of confusion, but we just have to accept it.

Data objects declared inside functions are given the default storage class specifier of auto unless some other storage class specifier is used. In the vast majority of cases, you don't

Page 82: Session 3

want these objects to be accessible from outside the function, so you want them to have no linkage. Either the default, auto, or the explicit register storage class specifier results in an object with no linkage and automatic duration. Neither auto nor register can be applied to a declaration that occurs outside a function.

The register storage class is quite interesting, although it is tending to fall into disuse nowadays. It suggests to the compiler that it would be a good idea to store the object in one or more hardware registers in the interests of speed. The compiler does not have to take any notice of this, but to make things easy for it, register variables do not have an address (the & address-of operator is forbidden) because some computers don't support the idea of addressable registers. Declaring too many register objects may slow the program down, rather than speed it up, because the compiler may either have to save more registers on entrance to a function, often a slow process, or there won't be enough registers remaining to be used for intermediate calculations. Determining when to use registers will be a machine-specific choice and should only be taken when detailed measurements show that a particular function needs to be speeded up. Then you will have to experiment. In our opinion, you should never declare register variables during program development. Get the program working first, then measure it, then, maybe, judicious use of registers will give a useful increase in performance. But that work will have to be repeated for every type of processor you move the program to; even within one family of processors the characteristics are often different.

A final note on register variables: this is the only storage class specifier that may be used in a function prototype or function definition. In a function prototype, the storage class specifier is simply ignored, in a function definition it is a hint that the actual parameter should be stored in a register if possible. This example shows how it might be used:#include <stdio.h>#include <stdlib.h>

void func(register int arg1, double arg2);

main(){ func(5, 2); exit(EXIT_SUCCESS);}

/** Function illustrating that formal parameters* may be declared to have register storage class.*/void func(register int arg1, double arg2){

/* * Illustrative only - nobody would do this * in this context. * Cannot take address of arg1, even if you want to

Page 83: Session 3

*/ double *fp = &arg2;

while(arg1){ printf("res = %f\n", arg1 * (*fp)); arg1--; }}Example 8.1

So, the duration of an object depends on the storage class specifier used, whether it's a data object or function, and the position (block or file scope) of the declaration concerned. The linkage is also dependent on the storage class specifier, what kind of object it is and the scope of the declaration. Table 8.1 and Table 8.2 show the resulting storage duration and apparent linkage for the various combinations of storage class specifiers and location of the declaration. The actual linkage of objects with static duration is a bit more complicated, so use these tables only as a guide to the simple cases and take a look at what we say later about definitions.Storage Class Specifier Function or Data Object Linkage Durationstatic either internal staticextern either probably external staticnone function probably external staticnone data object external static

Table 8.1. External declarations (outside a function)

The table above omits the register and auto storage class specifiers because they are not permitted in file-scope (external) declarations.Storage Class Specifier Function or Data Object Linkage Durationregister data object only none automaticauto data object only none automaticstatic data object only none staticextern either probably external staticnone data object none automaticnone function probably external static

Table 8.2. Internal declarations

Internal static variables retain their values between calls of the function that contains them, which is useful in certain circumstances (see Chapter 4).8.2.2. Scope

Now we must look again at the scope of the names of objects, which defines when and where a given name has a particular meaning. The different types of scope are the following:

Page 84: Session 3

function scopefile scopeblock scopefunction prototype scope

The easiest is function scope. This only applies to labels, whose names are visible throughout the function where they are declared, irrespective of the block structure. No two labels in the same function may have the same name, but because the name only has function scope, the same name can be used for labels in every function. Labels are not objects—they have no storage associated with them and the concepts of linkage and duration have no meaning for them.

Any name declared outside a function has file scope, which means that the name is usable at any point from the declaration on to the end of the source code file containing the declaration. Of course it is possible for these names to be temporarily hidden by declarations within compound statements. As we know, function definitions must be outside other functions, so the name introduced by any function definition will always have file scope.

A name declared inside a compound statement, or as a formal parameter to a function, has block scope and is usable up to the end of the associated } which closes the compound statement. Any declaration of a name within a compound statement hides any outer declaration of the same name until the end of the compound statement.

A special and rather trivial example of scope is function prototype scope where a declaration of a name extends only to the end of the function prototype. That means simply that this is wrong (same name used twice):void func(int i, int i);

and this is all right:void func(int i, int j);

The names declared inside the parentheses disappear outside them.

The scope of a name is completely independent of any storage class specifier that may be used in its declaration.8.2.3. Linkage

We will briefly review the subject of linkage here, too. Linkage is used to determine what makes the same name declared in different scopes refer to the same thing. An object only ever has one name, but in many cases we would like to be able to refer to the same object from different scopes. A typical example is the wish to be able to call printf from several different places in a program, even if those places are not all in the same source file.

The Standard warns that declarations which refer to the same thing must all have compatible type, or the behaviour of the program will be undefined. A full description of

Page 85: Session 3

compatible type is given later; for the moment you can take it to mean that, except for the use of the storage class specifier, the declarations must be identical. It's the responsibility of the programmer to get this right, though there will probably be tools available to help you check this out.

The three different types of linkage are:external linkageinternal linkageno linkage

In an entire program, built up perhaps from a number of source files and libraries, if a name has external linkage, then every instance of a that name refers to the same object throughout the program.

For something which has internal linkage, it is only within a given source code file that instances of the same name will refer to the same thing.

Finally, names with no linkage refer to separate things.8.2.4. Linkage and definitions

Every data object or function that is actually used in a program (except as the operand of a sizeof operator) must have one and only one corresponding definition. This is actually very important, although we haven't really come across it yet because most of our examples have used only data objects with automatic duration, whose declarations are axiomatically definitions, or functions which we have defined by providing their bodies.

This ‘exactly one’ rule means that for objects with external linkage there must be exactly one definition in the whole program; for things with internal linkage (confined to one source code file) there must be exactly one definition in the file where it is declared; for things with no linkage, whose declaration is always a definition, there is exactly one definition as well.

Now we try to draw everything together. The real questions areHow do I get the sort of linkage that I want?What actually constitutes a definition?

We need to look into linkage first, then definitions.

How do you get the appropriate linkage for a particular name? The rules are a little complicated.A declaration outside a function (file scope) which contains the static storage class specifier results in internal linkage for that name. (The Standard requires that function declarations which contain static must be at file scope, outside any block)If a declaration contains the extern storage class specifier, or is the declaration of a function with no storage class specifier (or both), then:

Page 86: Session 3

If there is already a visible declaration of that identifier with file scope, the resulting linkage is the same as that of the visible declaration;otherwise the result is external linkage.If a file scope declaration is neither the declaration of a function nor contains an explicit storage class specifier, then the result is external linkage.Any other form of declaration results in no linkage.In any one source code file, if a given identifer has both internal and external linkage then the result is undefined.

These rules were used to derive the ‘linkage’ columns of Table 8.1 and Table 8.2, without the full application of rule 2—hence the use of the ‘probably external’ term. Rule 2 allows you to determine the precise linkage in those cases.

What makes a declaration into a definition?Declarations that result in no linkage are also definitions.Declarations that include an initializer are always definitions; this includes the ‘initialization’ of functions by providing their body. Declarations with block scope may only have initializers if they also have no linkage.Otherwise, the declaration of a name with file scope and with either no storage class specifier or with the static storage class specifier is a tentative definition. If a source code file contains one or more tentative definitions for an object, then if that file contains no actual definitions, a default definition is provided for that object as if it had an initializer of 0. (Structures and arrays have all their elements initialized to 0). Functions do not have tentative definitions.

A consequence of the foregoing is that unless you also provide an initializer, declarations that explicitly include the extern storage class specifier do not result in a definition.8.2.5. Realistic use of linkage and definitions

The rules that determine the linkage and definition associated with declarations look quite complicated. The combinations used in practice are nothing like as bad; so let's investigate the usual cases.

The three types of accessibility that you will want of data objects or functions are:throughout the entire program,restricted to one source file,restricted to one function (or perhaps a single compound statement).

For the three cases above, you will want external linkage, internal linkage, and no linkage respectively. The recommended practice for the first two cases is to declare all of the names in each of the relevant source files before you define any functions. The recommended layout of a source file would be as shown in Figure 8.1.

Figure 8.1. Layout of a source file

Page 87: Session 3

The external linkage declarations would be prefixed with extern, the internal linkage declarations with static. Here's an example./* example of a single source file layout */#include <stdio.h>

/* Things with external linkage:* accessible throughout program.* These are declarations, not definitions, so* we assume their definition is somewhere else.*/

extern int important_variable;extern int library_func(double, int);

/** Definitions with external linkage.*/extern int ext_int_def = 0; /* explicit definition */int tent_ext_int_def; /* tentative definition */

/** Things with internal linkage:* only accessible inside this file.* The use of static means that they are also* tentative definitions.*/

static int less_important_variable;static struct{ int member_1; int member_2;}local_struct;

/** Also with internal linkage, but not a tentative* definition because this is a function.*/static void lf(void);

/** Definition with internal linkage.*/static float int_link_f_def = 5.3;

/** Finally definitions of functions within this file*/

Page 88: Session 3

/** This function has external linkage and can be called* from anywhere in the program.*/void f1(int a){}

/** These two functions can only be invoked by name from* within this file.*/static int local_function(int a1, int a2){ return(a1 * a2);}

static void lf(void){ /* * A static variable with no linkage, * so usable only within this function. * Also a definition (because of no linkage) */ static int count; /* * Automatic variable with no linkage but * an initializer */ int i = 1;

printf("lf called for time no %d\n", ++count);}/** Actual definitions are implicitly provided for* all remaining tentative definitions at the end of* the file*/Example 8.2

We suggest that your re-read the preceding sections to see how the rules have been applied in Example 8.2.

Use of volatile

Page 89: Session 3

The compilation system tries to reduce code size and execution time on all machines, by optimizing code. It is programmer responsibility to inform compilation system that certain code (or variable) should not be optimized. Many programmers do not understand when to use volatile to inform compilation system that certain code should not be optimized or what it does. Although (no doubt) their program work, they do not exploit the full power of the language.

A variable should be declared volatile whenever its value can be changed by something beyond the control of the program in which it appears, such as a concurrently executing thread. Volatile, can appear only once in a declaration with any type specifier; however, they cannot appear after the first comma in a multiple item declaration. For example, the following declarations are legal

/* Let T denotes some data type */typedef volatile T i; volatile T i;T volatile i ; And the following declaration is illegal T i, volatile vi ;Volatile qualifiers can be used to change the behavior of a type. For example, volatile int p = 3;declares and initializes an object with type volatile int whose value will be always read from memory. SyntaxKeyword volatile can be placed before or after the data type in the variable definition. For example following declaration are identical: Volatile T a =3;T volatile a=3; The declaration declares and initializes an objet with type volatile T whose value will be always read from memory Pointer declarationVolatile T * ptr; T volatile * ptr; Ptr is a a pointer to a volatile T: volatile pointer to a volatile variable int volatile * volatile ptr; volatile can be applied to derived types such as an array type ,in that case, the element is qualified, not the array type. When applied to struct types entire contents of the struct become volatile. You can apply the volatile qualifier to the individual members of the struct. Type qualifiers are relevant only when accessing identifiers as l-values in expressions. volatile does not affects the range of values or arithmetic properties of the object.. To declare the item pointed to by the pointer as volatile, use a declaration of the form: volatile T *vptr;

Page 90: Session 3

To declare the value of the pointer - that is, the actual address stored in the pointer - as volatile, use a declaration of the form: T* volatile ptrv;

Use of volatile- An object that is a memory-mapped I/O port - An object variable that is shared between multiple concurrent processes - An object that is modified by an interrupt service routine - An automatic object declared in a function that calls setjmp and whose value is-changed between the call to setjmp and a corresponding call to longjmp

# An object that is a memory-mapped I/O port

an 8 bit , memory -mapped I/O port at physical address 0X15 can be declared as char const ptr=(char*)0X15 ;*ptr access the port consider following code fragment to set the third bit of the output port at periodic intervals *ptr = 0;while(*ptr){ *ptr = 4 ; *ptr = 0 ;}the above code may be optimize as *ptr = 0while(0) {}*ptr is assigned 0 before value 4 is used ( and value of *ptr never changes ( same constant is always assigned to it) volatile keyword is used to suppress these optimization the compiler assumes that the value can change any time , even if no explicit code modify it to suppress all optimization declare ptr as volatile char * const ptr = (volatile char*)0x16this declaration say the object at which ptr points can change without notice , but that ptr itself is a constant whose value never change

# An object that is shared between multiple concurrent processes

if two threads/tasks concurrently assign distinct values to the same shared non-volatile variable, a subsequent use of that variable may obtain a value that is not equal to either of the assigned values, but some implementation-dependent mixture of the two values. so a global variable references by multiple thread programmers must declare shared variable as volatile. #include#includevolatile int num ;void* foo()

Page 91: Session 3

{while(1) { ++num ; sleep(1000); }}

main(){ int p ; void *targ =NULL ; thread_t id ; num = 0; p = thr_create((void*)NULL , 0,foo,targ,0,&id); if(!p) printf(" can not create thread ");

while(1) { printf("%d" , num ) ; }}the compiler may use a register to store the num variable in the main thread , so the change to the value by the second thread are ignored . The volatile modifier is a away of telling the compiler that no optimization applied to the variable its value be not placed in register and value may change outside influence during evaluation

# An automatic object declared in a function that calls setjmp and whose value is-changed between the call to setjmp and a corresponding call to longjmp

Variables local to functions that call setjmp is most often used. When an automatic object is declared in a function that calls setjmp, the compilation system knows that it has to produce code that exactly matches what the programmer wrote. Therefore, the most recent value for such an automatic object will always be in memory (not just in a register) and as such will be guaranteed to be up-to-date when longjmp is called. Without volatile variable is undefined by the standard whether the result one see differs with or without optimization simply reflects that fact Consider following code #includestatic jmp_buf buf ;main( ){ volatile int b; b =3 ; if(setjmp(buf)!=0) { printf("%d ", b) ; exit(0); }

Page 92: Session 3

b=5; longjmp(buf , 1) ; }volatile variable isn't affected by the optimization. So value of b is after the longjump is the last value variable assigned. Without volatile b may or may not be restored to its last value when the longjmp occurs. For clear understanding assembly listing of above program by cc compiler has been given below. /*Listing1: Assembly code fragment of above program Produced by cc compiler when volatile is used*/

.file "vol.c"main:

pushl %ebpmovl %esp, %ebpsubl $20, %espmovl $3, -4(%ebp)pushl $bufcall _setjmpaddl $16, %esptestl %eax, %eaxje .L18subl $8, %espmovl -4(%ebp), %eaxpushl %eaxpushl $.LC0call printfmovl $0, (%esp)call exit.p2align 2

.L18:movl $5, -4(%ebp)subl $8, %esppushl $1pushl $bufcall longjmp

/*Listing 2:Assemply code fragment of above program produced by cc compile witout volatile keword */

.file "wvol.c"main:

pushl %ebpmovl %esp, %ebpsubl $20, %esp

Page 93: Session 3

pushl $bufcall _setjmpaddl $16, %esptestl %eax, %eaxje .L18subl $8, %esppushl $3pushl $.LC0call printfmovl $0, (%esp)call exit.p2align 2

.L18:subl $8, %esppushl $1pushl $bufcall longjmp

/listing 3: difference between listing 1 and listing 3 ***/

< .file "vol.c"---> .file "wvol.c"< movl $3, -4(%ebp) < movl -4(%ebp), %eax< pushl %eax> pushl $3< movl $5, -4(%ebp) / * store in stack */

From above listing 3 it is clear that when you use setjmp and longjmp, the only automatic variables guaranteed to remain valid are those declared volatile.

# An object modified by an interrupt service routineInterrupt service routines often set variables that are tested in main line code. One problem that arises as soon as you use interrupt is that interrupt routines need to communicate with rest of the code .A interrupt may update a variable num that is used in main line of code .An incorrect implementation of this might be: static lon int num ;void interrupt update(void){++num ;}main(){long val ;val = num ;

Page 94: Session 3

while(val !=num)val = num ;rturn val ;}When compilation system execute while statement, the optimizer in compiler may notice that it read the value num once already and that value is still in the register. Instead of re reading the value from memory, compiler may produce code to use the (possibly messed up) value in the register defeating purpose of original C program. Some compiler may optimize entire while loop assuming that since the value of num was just assigned to val , the two must be equal and condition in while statement will therefore always be false .To avoid this ,you have to declare num to be volatile that warns compilers that certain variables may change because of interrupt routines. static volatile long int num ;With volatile keyword in the declaration the compiler knows that the value of num must b read from memory every time it is referenced. ConclusionWhen using exact semantics is necessary, volatile should be used. If you are given a piece of touchy code given as above. It is a good idea in any case to look the compiler outputting listing at the assembly language to be sure that compiler produce code that makes sense.

About the authorAshok K. Pathak a member ( Research Staff ) at Bharat Electronics Limited (CRL) , Ghaziabad .He has been developing embedded application for the past five years. Ashok holds a M.E in computer science and engineering . Ashok recently completed a book about' "Advanced Test in C and Embedded System Programming" , Published by BPB , ND .He can be reached at [email protected].

6.38. Variables in Specified Registers

GNU C allows you to put a few global variables into specified hardware registers. You can also specify the register in which an ordinary register variable should be allocated.

Global register variables reserve registers throughout the program. This may be useful in programs such as programming language interpreters which have a couple of global variables that are accessed very often.

Local register variables in specific registers do not reserve the registers. The compiler's data flow analysis is capable of determining where the specified registers contain live values, and where they are available for other uses. Stores into local register variables may be deleted when they appear to be dead according to dataflow analysis. References to local register variables may be deleted or moved or simplified.

Page 95: Session 3

These local variables are sometimes convenient for use with the extended asm feature (Section 6.35 Assembler Instructions with C Expression Operands), if you want to write one output of the assembler instruction directly into a particular register. (This will work provided the register you specify fits the constraints specified for that operand in the asm.) 6.38.1. Defining Global Register Variables

You can define a global register variable in GNU C like this: register int *foo asm ("a5");

Here a5 is the name of the register which should be used. Choose a register which is normally saved and restored by function calls on your machine, so that library routines will not clobber it.

Naturally the register name is cpu-dependent, so you would need to conditionalize your program according to cpu type. The register a5 would be a good choice on a 68000 for a variable of pointer type. On machines with register windows, be sure to choose a "global" register that is not affected magically by the function call mechanism.

In addition, operating systems on one type of cpu may differ in how they name the registers; then you would need additional conditionals. For example, some 68000 operating systems call this register %a5.

Eventually there may be a way of asking the compiler to choose a register automatically, but first we need to figure out how it should choose and how to enable you to guide the choice. No solution is evident.

Defining a global register variable in a certain register reserves that register entirely for this use, at least within the current compilation. The register will not be allocated for any other purpose in the functions in the current compilation. The register will not be saved and restored by these functions. Stores into this register are never deleted even if they would appear to be dead, but references may be deleted or moved or simplified.

It is not safe to access the global register variables from signal handlers, or from more than one thread of control, because the system library routines may temporarily use the register for other things (unless you recompile them specially for the task at hand).

It is not safe for one function that uses a global register variable to call another such function foo by way of a third function lose that was compiled without knowledge of this variable (i.e. in a different source file in which the variable wasn't declared). This is because lose might save the register and put some other value there. For example, you can't expect a global register variable to be available in the comparison-function that you pass to qsort, since qsort might have put something else in that register. (If you are prepared to recompile qsort with the same global register variable, you can solve this problem.)

Page 96: Session 3

If you want to recompile qsort or other source files which do not actually use your global register variable, so that they will not use that register for any other purpose, then it suffices to specify the compiler option -ffixed-reg. You need not actually add a global register declaration to their source code.

A function which can alter the value of a global register variable cannot safely be called from a function compiled without this variable, because it could clobber the value the caller expects to find there on return. Therefore, the function which is the entry point into the part of the program that uses the global register variable must explicitly save and restore the value which belongs to its caller.

On most machines, longjmp will restore to each global register variable the value it had at the time of the setjmp. On some machines, however, longjmp will not change the value of global register variables. To be portable, the function that called setjmp should make other arrangements to save the values of the global register variables, and to restore them in a longjmp. This way, the same thing will happen regardless of what longjmp does.

All global register variable declarations must precede all function definitions. If such a declaration could appear after function definitions, the declaration would be too late to prevent the register from being used for other purposes in the preceding functions.

Global register variables may not have initial values, because an executable file has no means to supply initial contents for a register.

On the SPARC, there are reports that g3 … g7 are suitable registers, but certain library functions, such as getwd, as well as the subroutines for division and remainder, modify g3 and g4. g1 and g2 are local temporaries.

The register storage class specifier

The register storage class specifier indicates to the compiler that the object should be stored in a machine register. The register storage class specifier is typically specified for heavily used variables, such as a loop control variable, in the hopes of enhancing performance by minimizing access time. However, the compiler is not required to honor this request. Because of the limited size and number of registers available on most systems, few variables can actually be put in registers. If the compiler does not allocate a machine register for a register object, the object is treated as having the storage class specifier auto.

An object having the register storage class specifier must be defined within a block or declared as a parameter to a function.

The following restrictions apply to the register storage class specifier: You cannot use pointers to reference objects that have the register storage class specifier.

Page 97: Session 3

You cannot use the register storage class specifier when declaring objects in global scope. A register does not have an address. Therefore, you cannot apply the address operator (&) to a register variable. You cannot use the register storage class specifier when declaring objects in namespace scope.C++ only

Unlike C, C++ lets you take the address of an object with the register storage class. For example: register int i; int* b = &i; // valid in C++, but not in CEnd of C++ onlyStorage duration of register variables

Objects with the register storage class specifier have automatic storage duration. Each time a block is entered, storage for register objects defined in that block is made available. When the block is exited, the objects are no longer available for use.

If a register object is defined within a function that is recursively invoked, memory is allocated for the variable at each invocation of the block.Linkage of register variables

Since a register object is treated as the equivalent to an object of the auto storage class, it has no linkage.

Related information Initialization and storage classesBlock/local scopeReferences (C++ only)IBM extensionGlobal variables in specified registers (C only)

You can specify that a particular hardware register is dedicated to a global variable by using an assembly global register variable declaration. Stores into the reserved register are never deleted. This language extension is provided for compatibility with GNU C.

Global register variable declaration syntax >>-register--variable_declaration-------------------------------> >--+-asm-----+-("register_specifier")-------------------------->< +-__asm__-+ '-__asm---'

Page 98: Session 3

The register_specifier is a string representing a hardware register. The register name is CPU-specific. XL C supports the following register names on the PowerPC:r0 to r31 -- general purpose registersf0 to f31 -- floating point registersv0 to v31 -- vector registersNote:You cannot use registers r30 or r14 for register variable declarations, as these are reserved for use by the XL C++ runtime environment.

The following are the rules of use for register variables:General purpose registers can only be reserved for variables of integer or pointer type.Floating point registers can only be reserved for variables of float, double, or 64-bit long double type.Vector registers can only be reserved for variables of vector type.Variables of long long type cannot reserve registers.A global register variable cannot be initialized.The register dedicated for a global register variable should not be a volatile register, or the value stored into the global variable might not be preserved across a function call.A global register variable can only reserve a register that is not already reserved by another global register variable.The same global register variable cannot reserve more than one register.A register variable should not be used in an OpenMP clause or OpenMP parallel or work-sharing region.The register specified in the global register declaration is reserved for the declared variable only in the compilation unit in which the register declaration is specified. The register is not reserved in other compilation units unless you place the global register declaration in a common header file, or use the -qreserved_reg compiler option.

Lesson 3: The use and declaration of constants.

This lesson will show you how to:Use constants in CDeclare constants in Cthe #define directivethe keyword const

Q: What's the difference between a lawyer and a bucket of shit?A: The bucket.

A constant is similar to a variable in the sense that it represents a memory location (or simply, a value). It is different from a normal variable, as I sure you can guess, in that it cannot change it's value in the proram - it must stay for ever stay constant. In general, constants are a useful because they can prevent program bugs and logical errors(errors are explained later). Unintended modifications are prevented from occurring. The compiler will catch attempts to reassign new values to constants.

Page 99: Session 3

Using #defineThere are three techniques used to define constants in C. First, constants may be defined using the preprocessor directive (the preprocessor-directives are explained in summary guide 1 in the advanced user category - don't be scared - they are very easy to understand) #define. The preprocessor is a program that modifies your source file prior to compilation. Common preprocessor directives are #include, which is used to include additional code into your source file, #define, which is used to define a constant. The standard is that constants are always in uppercase whereas normal variables are in lowercase - you don't have to follow this convention - it just makes things easier. Remember that this statement must not contain a semi-colon, and must not contain the assignment operator (in english it is equals, =). The #define directive is used as follows:

#define ID_NO 12345

Wherever the constant appears in your source file, the preprocessor replaces it by its value. So, for instance, every "pi" in your source code will be replace by 3.1415. The compiler will only see the value 3.1415 in your code, not "pi". Every "pi" is just replaced by its value. Here is a simple program illustrating the preprocessor directive #define.

#include <stdio.h>

#define MONDAY 1#define TUESDAY 2#define WEDNESDAY 3#define THURSDAY 4#define FRIDAY 5#define SATURDAY 6#define SUNDAY 7

int main(void){

int today = MONDAY;

if ((today == SATURDAY) || (today == SUNDAY)) { printf("Weekend\n"); } else { printf("Go to work or school\n"); }

return 0;

Page 100: Session 3

}

Don't worry if you don't understand this program, just look at it's basic structure that's all. All will be revealed. Good things come to those who wait!

How do you know if a woman is about to say something smart? When she starts her sentence with something like "A man once told me..."

Using const variablesThe second technique is to use the keyword const when defining a variable. When used the compiler will catch attempts to modify variables that have been declared const.

const float pi = 3.1415;const int id_no = 12345;

There are two main advantages over the first technique. First, the type of the constant is defined. "pi" is float. "id_no" is int. This allows some type checking by the compiler. Second, these constants are variables with a definite scope. The scope of a variable relates to parts of your program in which it is defined. Some variables may exist only in certain functions or in certain blocks of code. You may want to use "id_no" in one function and a completely unrelated "id_no" in your main program. Sorry if this is confusing, the scope of variables will be covered in a latter lesson.

Teach Yourself C in 21 Days

- 21 -Advanced Compiler UseProgramming with Multiple Source Files Advantages of Modular Programming Modular Programming Techniques Module Components External Variables and Modular Programming Using .OBJ Files Using the make Utility The C Preprocessor The #define Preprocessor Directive The #include Directive Using #if, #elif, #else, and #endif Using #if...#endif to Help Debug Avoiding Multiple Inclusions of Header Files The #undef Directive Predefined Macros Using Command-Line Arguments

Page 101: Session 3

Summary Q&A Workshop Quiz Exercises

This chapter, the last of your 21 days, covers some additional features of the C compiler. Today you will learn aboutProgramming with multiple source-code files

Using the C preprocessor

Using command-line arguments Programming with Multiple Source Files

Until now, all your C programs have consisted of a single source-code file, exclusive of header files. A single source-code file is often all you need, particularly for small programs, but you can also divide the source code for a single program among two or more files, a practice called modular programming. Why would you want to do this? The following sections explain.

Advantages of Modular Programming

The primary reason to use modular programming is closely related to structured programming and its reliance on functions. As you become a more experienced programmer, you develop more general-purpose functions that you can use, not only in the program for which they were originally written, but in other programs as well. For example, you might write a collection of general-purpose functions for displaying information on-screen. By keeping these functions in a separate file, you can use them again in different programs that also display information on-screen. When you write a program that consists of multiple source-code files, each source file is called a module.

Modular Programming Techniques

A C program can have only one main() function. The module that contains the main() function is called the main module, and other modules are called secondary modules. A separate header file is usually associated with each secondary module (you'll learn why later in this chapter). For now, look at a few simple examples that illustrate the basics of multiple module programming. Listings 21.1, 21.2, and 21.3 show the main module, the secondary module, and the header file, respectively, for a program that inputs a number from the user and displays its square.

Listing 21.1. LIST21_1.C: the main module.1: /* Inputs a number and displays its square. */2:

Page 102: Session 3

3: #include <stdio.h>4: #include "calc.h"5:6: main()7: {8: int x;9:10: printf("Enter an integer value: ");11: scanf("%d", &x);12: printf("\nThe square of %d is %ld.\n", x, sqr(x));13: return(0);14: }Listing 21.2. CALC.C: the secondary module.1: /* Module containing calculation functions. */2:3: #include "calc.h"4:5: long sqr(int x)6: {7: return ((long)x * x);8: }Listing 21.3. CALC.H: the header file for CALC.C.1: /* CALC.H: header file for CALC.C. */2:3: long sqr(int x);4:5: /* end of CALC.H */Enter an integer value: 100The square of 100 is 10000.

ANALYSIS: Let's look at the components of these three files in greater detail. The header file, CALC.H, contains the prototype for the sqr() function in CALC.C. Because any module that uses sqr() needs to know sqr()'s prototype, the module must include CALC.H.

The secondary module file, CALC.C, contains the definition of the sqr() function. The #include directive is used to include the header file, CALC.H. Note that the header filename is enclosed in quotation marks rather than angle brackets. (You'll learn the reason for this later in this chapter.)

The main module, LIST21_1.C, contains the main() function. This module also includes the header file, CALC.H.

After you use your editor to create these three files, how do you compile and link the final executable program? Your compiler controls this for you. At the command line, enter

Page 103: Session 3

xxx list21_1.c calc.c

where xxx is your compiler's command. This directs the compiler's components to perform the following tasks:1. Compile LIST21_1.C, creating LIST21_1.OBJ (or LIST21_1.O on a UNIX system). If it encounters any errors, the compiler displays descriptive error messages.

2. Compile CALC.C, creating CALC.OBJ (or CALC.O on a UNIX system). Again, error messages appear if necessary.

3. Link LIST21_1.OBJ, CALC.OBJ, and any needed functions from the standard library to create the final executable program LIST21_1.EXE.

Module Components

As you can see, the mechanics of compiling and linking a multiple-module program are quite simple. The only real question is what to put in each file. This section gives you some general guidelines.

The secondary module should contain general utility functions--that is, functions that you might want to use in other programs. A common practice is to create one secondary module for each type of function--for example, KEYBOARD.C for your keyboard functions, SCREEN.C for your screen display functions, and so on. To compile and link more than two modules, list all source files on the command line:

tcc mainmod.c screen.c keyboard.c

The main module should contain main(), of course, and any other functions that are program-specific (meaning that they have no general utility).

There is usually one header file for each secondary module. Each file has the same name as the associated module, with an .H extension. In the header file, putPrototypes for functions in the secondary module

#define directives for any symbolic constants and macros used in the module

Definitions of any structures or external variables used in the module

Because this header file might be included in more than one source file, you want to prevent portions of it from compiling more than once. You can do this by using the preprocessor directives for conditional compilation (discussed later in this chapter).

External Variables and Modular Programming

Page 104: Session 3

In many cases, the only data communication between the main module and the secondary module is through arguments passed to and returned from the functions. In this case, you don't need to take special steps regarding data visibility, but what about an external variable that needs to be visible in both modules?

Recall from Day 12, "Understanding Variable Scope," that an external variable is one declared outside of any function. An external variable is visible throughout the entire source code file in which it is declared. However, it is not automatically visible in other modules. To make it visible, you must declare the variable in each module, using the extern keyword. For example, if you have an external variable declared in the main module as

float interest_rate;

you make interest_rate visible in a secondary module by including the following declaration in that module (outside of any function):

extern float interest_rate;

The extern keyword tells the compiler that the original declaration of interest_rate (the one that set aside storage space for it) is located elsewhere, but that the variable should be made visible in this module. All extern variables have static duration and are visible to all functions in the module. Figure 21.1 illustrates the use of the extern keyword in a multiple-module program.

Figure 21.1.

Using the extern keyword to make an external variable visible across modules.

In Figure 21.1, the variable x is visible throughout all three modules. In contrast, y is visible only in the main module and secondary module 1.

Using .OBJ Files

After you've written and thoroughly debugged a secondary module, you don't need to recompile it every time you use it in a program. Once you have the object file for the module code, all you need to do is link it with each program that uses the functions in the module.

When you compile a program, the compiler creates an object file that has the same name as the C source code file and an .OBJ extension (or an .O extension on UNIX systems). For example, suppose you're developing a module called KEYBOARD.C and compiling it, along with the main module DATABASE.C, using the following command:

tcc database.c keyboard.c

Page 105: Session 3

The KEYBOARD.OBJ file is also on your disk. Once you know that the functions in KEYBOARD.C work properly, you can stop compiling it every time you recompile DATABASE.C (or any other program that uses it), linking the existing object file instead. To do this, use the command

tcc database.c keyboard.obj

The compiler then compiles DATABASE.C and links the resulting object file DATABASE.OBJ with KEYBOARD.OBJ to create the final executable file DATABASE.EXE. This saves time, because the compiler doesn't have to recompile the code in KEYBOARD.C. However, if you modify the code in KEYBOARD.C, you must recompile it. In addition, if you modify a header file, you must recompile all the modules that use it.

DON'T try to compile multiple source files together if more than one module contains a main() function. You can have only one main().

DO create generic functions in their own source files. This way, they can be linked into any other programs that need them.

DON'T always use the C source files when compiling multiple files together. If you compile a source file into an object file, recompile only when the file changes. This saves a great deal of time. Using the make Utility

Almost all C compilers come with a make utility that can simplify and speed the task of working with multiple source-code files. This utility, which is usually called NMAKE.EXE, lets you write a so-called make file that defines the dependencies between your various program components. What does dependency mean?

Imagine a project that has a main module named PROGRAM.C and a secondary module named SECOND.C. There are also two header files, PROGRAM.H and SECOND.H. PROGRAM.C includes both of the header files, whereas SECOND.C includes only SECOND.H. Code in PROGRAM.C calls functions in SECOND.C.

PROGRAM.C is dependent on the two header files because it includes them both. If you make a change to either header file, you must recompile PROGRAM.C so that it will include those changes. In contrast, SECOND.C is dependent on SECOND.H but not on PROGRAM.H. If you change PROGRAM.H, there is no need to recompile SECOND.C--you can just link the existing object file SECOND.OBJ that was created when SECOND.C was last compiled.

A make file describes the dependencies such as those just discussed that exist in your project. Each time you edit one or more of your source code files, you use the NMAKE utility to "run" the make file. This utility examines the time and date stamps on the source code and object files and, based on the dependencies you have defined, instructs the

Page 106: Session 3

compiler to recompile only those files that are dependent on the modified file(s). The result is that no unnecessary compilation is done, and you can work at the maximum efficiency.

For projects that involve one or two source code files, it usually isn't worth the trouble of defining a make file. For larger projects, however, it's a real benefit. Refer to your compiler documentation for information on how to use its NMAKE utility.

The C Preprocessor

The preprocessor is a part of all C compiler packages. When you compile a C program, the preprocessor is the first compiler component that processes your program. In most C compilers, the preprocessor is part of the compiler program. When you run the compiler, it automatically runs the preprocessor.

The preprocessor changes your source code based on instructions, or preprocessor directives, in the source code. The output of the preprocessor is a modified source code file that is then used as the input for the next compilation step. Normally you never see this file, because the compiler deletes it after it's used. However, later in this chapter you'll learn how to look at this intermediate file. First, you need to learn about the preprocessor directives, all of which begin with the # symbol.

The #define Preprocessor Directive

The #define preprocessor directive has two uses: creating symbolic constants and creating macros.

Simple Substitution Macros Using #define

You learned about substitution macros on Day 3, "Storing Data: Variables and Constants," although the term used to describe them in that chapter was symbolic constants. You create a substitution macro by using #define to replace text with other text. For example, to replace text1 with text2, you write

#define text1 text2

This directive causes the preprocessor to go through the entire source code file, replacing every occurrence of text1 with text2. The only exception occurs if text1 is found within double quotation marks, in which case no change is made.

The most frequent use for substitution macros is to create symbolic constants, as explained on Day 3. For example, if your program contains the following lines:

#define MAX 1000x = y * MAX;z = MAX - 12;

Page 107: Session 3

during preprocessing, the source code is changed to read as follows:

x = y * 1000;z = 1000 - 12;

The effect is the same as using your editor's search-and-replace feature in order to change every occurrence of MAX to 1000. Your original source code file isn't changed, of course. Instead, a temporary copy is created with the changes. Note that #define isn't limited to creating symbolic numeric constants. For example, you could write

#define ZINGBOFFLE printfZINGBOFFLE("Hello, world.");

although there is little reason to do so. You should also be aware that some authors refer to symbolic constants defined with #define as being macros themselves. (Symbolic constants are also called manifest constants.) However, in this book, the word macro is reserved for the type of construction described next.

Creating Function Macros with #define

You can use the #define directive also to create function macros. A function macro is a type of shorthand, using something simple to represent something more complicated. The reason for the "function" name is that this type of macro can accept arguments, just like a real C function does. One advantage of function macros is that their arguments aren't type-sensitive. Therefore, you can pass any numeric variable type to a function macro that expects a numeric argument.

Let's look at an example. The preprocessor directive

#define HALFOF(value) ((value)/2)

defines a macro named HALFOF that takes a parameter named value. Whenever the preprocessor encounters the text HALFOF(value) in the source code, it replaces it with the definition text and inserts the argument as needed. Thus, the source code line

result = HALFOF(10);

is replaced by this line:

result = ((10)/2);

Likewise, the program line

printf("%f", HALFOF(x[1] + y[2]));

Page 108: Session 3

is replaced by this line:

printf("%f", ((x[1] + y[2])/2));

A macro can have more than one parameter, and each parameter can be used more than once in the replacement text. For example, the following macro, which calculates the average of five values, has five parameters:

#define AVG5(v, w, x, y, z) (((v)+(w)+(x)+(y)+(z))/5)

The following macro, in which the conditional operator determines the larger of two values, also uses each of its parameters twice. (You learned about the conditional operator on Day 4, "Statements, Expressions, and Operators.")

#define LARGER(x, y) ((x) > (y) ? (x) : (y))

A macro can have as many parameters as needed, but all of the parameters in the list must be used in the substitution string. For example, the macro definition

#define ADD(x, y, z) ((x) + (y))

is invalid, because the parameter z is not used in the substitution string. Also, when you invoke the macro, you must pass it the correct number of arguments.

When you write a macro definition, the opening parenthesis must immediately follow the macro name; there can be no white space. The opening parenthesis tells the preprocessor that a function macro is being defined and that this isn't a simple symbolic constant type substitution. Look at the following definition:

#define SUM (x, y, z) ((x)+(y)+(z))

Because of the space between SUM and (, the preprocessor treats this like a simple substitution macro. Every occurrence of SUM in the source code is replaced with (x, y, z) ((x)+(y)+(z)), clearly not what you wanted.

Also note that in the substitution string, each parameter is enclosed in parentheses. This is necessary to avoid unwanted side effects when passing expressions as arguments to the macro. Look at the following example of a macro defined without parentheses:

#define SQUARE(x) x*x

If you invoke this macro with a simple variable as an argument, there's no problem. But what if you pass an expression as an argument?

result = SQUARE(x + y);

Page 109: Session 3

The resulting macro expansion is as follows, which doesn't give the proper result:

result = x + y * x + y;

If you use parentheses, you can avoid the problem, as shown in this example:

#define SQUARE(x) (x)*(x)

This definition expands to the following line, which does give the proper result:

result = (x + y) * (x + y);

You can obtain additional flexibility in macro definitions by using the stringizing operator (#) (sometimes called the string-literal operator). When a macro parameter is preceded by # in the substitution string, the argument is converted into a quoted string when the macro is expanded. Thus, if you define a macro as

#define OUT(x) printf(#x)

and you invoke it with the statement

OUT(Hello Mom);

it expands to this statement:

printf("Hello Mom");

The conversion performed by the stringizing operator takes special characters into account. Thus, if a character in the argument normally requires an escape character, the # operator inserts a backslash before the character. Continuing with the example, the invocation

OUT("Hello Mom");

expands to

printf("\"Hello Mom\"");

The # operator is demonstrated in Listing 21.4. First, you need to look at one other operator used in macros, the concatenation operator (##). This operator concatenates, or joins, two strings in the macro expansion. It doesn't include quotation marks or special treatment of escape characters. Its main use is to create sequences of C source code. For example, if you define and invoke a macro as

#define CHOP(x) func ## xsalad = CHOP(3)(q, w);

Page 110: Session 3

the macro invoked in the second line is expanded to

salad = func3 (q, w);

You can see that by using the ## operator, you determine which function is called. You have actually modified the C source code.

Listing 21.4 shows an example of one way to use the # operator.

Listing 21.4. Using the # operator in macro expansion.1: /* Demonstrates the # operator in macro expansion. */2:3: #include <stdio.h>4:5: #define OUT(x) printf(#x " is equal to %d.\n", x)6:7: main()8: {9: int value = 123;10: OUT(value);11: return(0);12: }value is equal to 123.

ANALYSIS: By using the # operator on line 5, the call to the macro expands with the variable name value as a quoted string passed to the printf() function. After expansion on line 9, the macro OUT looks like this:

printf("value" " is equal to %d.", value );Macros Versus Functions

You have seen that function macros can be used in place of real functions, at least in situations where the resulting code is relatively short. Function macros can extend beyond one line but usually become impractical beyond a few lines. When you can use either a function or a macro, which should you use? It's a trade-off between program speed and program size.

A macro's definition is expanded into the code each time the macro is encountered in the source code. If your program invokes a macro 100 times, 100 copies of the expanded macro code are in the final program. In contrast, a function's code exists only as a single copy. Therefore, in terms of program size, the better choice is a true function.

When a program calls a function, a certain amount of processing overhead is required in order to pass execution to the function code and then return execution to the calling

Page 111: Session 3

program. There is no processing overhead in "calling" a macro, because the code is right there in the program. In terms of speed, a function macro has the advantage.

These size/speed considerations aren't usually of much concern to the beginning programmer. Only with large, time-critical applications do they become important.

Viewing Macro Expansion

At times, you might want to see what your expanded macros look like, particularly when they aren't working properly. To see the expanded macros, you instruct the compiler to create a file that includes macro expansion after the compiler's first pass through the code. You might not be able to do this if your C compiler uses an Integrated Development Environment (IDE); you might have to work from the command prompt. Most compilers have a flag that should be set during compilation. This flag is passed to the compiler as a command-line parameter.

For example, to precompile a program named PROGRAM.C with the Microsoft compiler, you would enter

cl /E program.c

On a UNIX compiler, you would enter

cc -E program.c

The preprocessor makes the first pass through your source code. All header files are included, #define macros are expanded, and other preprocessor directives are carried out. Depending on your compiler, the output goes either to stdout (that is, the screen) or to a disk file with the program name and a special extension. The Microsoft compiler sends the preprocessed output to stdout. Unfortunately, it's not at all useful to have the processed code whip by on your screen! You can use the redirection command to send this output to a file, as in this example:

cl /E program.c > program.pre

You can then load the file into your editor for printing or viewing.

DO use #defines, especially for symbolic constants. Symbolic constants make your code much easier to read. Examples of things to put into defined constants are colors, true/false, yes/no, the keyboard keys, and maximum values. Symbolic constants are used throughout this book.

DON'T overuse macro functions. Use them where needed, but be sure they are a better choice than a normal function. The #include Directive

Page 112: Session 3

You have already learned how to use the #include preprocessor directive to include header files in your program. When it encounters an #include directive, the preprocessor reads the specified file and inserts it at the location of the directive. You can't use the * or ? wildcards to read in a group of files with one #include directive. You can, however, nest #include directives. In other words, an included file can contain #include directives, which can contain #include directives, and so on. Most compilers limit the number of levels deep that you can nest, but you usually can nest up to 10 levels.

There are two ways to specify the filename for an #include directive. If the filename is enclosed in angle brackets, such as #include <stdio.h> (as you have seen throughout this book), the preprocessor first looks for the file in the standard directory. If the file isn't found, or no standard directory is specified, the preprocessor looks for the file in the current directory.

"What is the standard directory?" you might be asking. In DOS, it's the directory or directories specified by the DOS INCLUDE environment variable. Your DOS documentation contains complete information on the DOS environment. To summarize, however, you set an environment variable with a SET command (usually, but not necessarily, in your AUTOEXEC.BAT file). Most compilers automatically set the INCLUDE variable in the AUTOEXEC.BAT file when the compiler is installed.

The second method of specifying the file to be included is enclosing the filename in double quotation marks: #include "myfile.h". In this case, the preprocessor doesn't search the standard directories; instead, it looks in the directory containing the source code file being compiled. Generally speaking, header files that you write should be kept in the same directory as the C source code files, and they are included by using double quotation marks. The standard directory is reserved for header files supplied with your compiler.

Using #if, #elif, #else, and #endif

These four preprocessor directives control conditional compilation. The term conditional compilation means that blocks of C source code are compiled only if certain conditions are met. In many ways, the #if family of preprocessor directives operates like the C language's if statement. The difference is that if controls whether certain statements are executed, whereas #if controls whether they are compiled.

The structure of an #if block is as follows:

#if condition_1statement_block_1#elif condition_2statement_block_2...#elif condition_nstatement_block_n

Page 113: Session 3

#elsedefault_statement_block#endif

The test expression that #if uses can be almost any expression that evaluates to a constant. You can't use the sizeof() operator, typecasts, or the float type. Most often you use #if to test symbolic constants created with the #define directive.

Each statement_block consists of one or more C statements of any type, including preprocessor directives. They don't need to be enclosed in braces, although they can be.

The #if and #endif directives are required, but #elif and #else are optional. You can have as many #elif directives as you want, but only one #else. When the compiler reaches an #if directive, it tests the associated condition. If it evaluates to TRUE (nonzero), the statements following the #if are compiled. If it evaluates to FALSE (zero), the compiler tests, in order, the conditions associated with each #elif directive. The statements associated with the first TRUE #elif are compiled. If none of the conditions evaluates as TRUE, the statements following the #else directive are compiled.

Note that, at most, a single block of statements within the #if...#endif construction is compiled. If the compiler finds no #else directive, it might not compile any statements.

The possible uses of these conditional compilation directives are limited only by your imagination. Here's one example. Suppose you're writing a program that uses a great deal of country-specific information. This information is contained in a header file for each country. When you compile the program for use in different countries, you can use an #if...#endif construction as follows:

#if ENGLAND == 1#include "england.h"#elif FRANCE == 1#include "france.h"#elif ITALY == 1#include "italy.h"#else#include "usa.h"#endif

Then, by using #define to define the appropriate symbolic constant, you can control which header file is included during compilation.

Using #if...#endif to Help Debug

Another common use of #if...#endif is to include conditional debugging code in the program. You could define a DEBUG symbolic constant set to either 1 or 0. Throughout the program, you can insert debugging code as follows:

Page 114: Session 3

#if DEBUG == 1debugging code here#endif

During program development, if you define DEBUG as 1, the debugging code is included to help track down any bugs. After the program is working properly, you can redefine DEBUG as 0 and recompile the program without the debugging code.

The defined() operator is useful when you write conditional compilation directives. This operator tests to see whether a particular name is defined. Thus, the expression

defined( NAME )

evaluates to TRUE or FALSE, depending on whether NAME is defined. By using defined(), you can control compilation, based on previous definitions, without regard to the specific value of a name. Referring to the previous debugging code example, you could rewrite the #if...#endif section as follows:

#if defined( DEBUG )debugging code here#endif

You can also use defined() to assign a definition to a name only if it hasn't been previously defined. Use the NOT operator (!) as follows:

#if !defined( TRUE ) /* if TRUE is not defined. */#define TRUE 1#endif

Notice that the defined() operator doesn't require that a name be defined as anything in particular. For example, after the following program line, the name RED is defined, but not as anything in particular:

#define RED

Even so, the expression defined( RED ) still evaluates as TRUE. Of course, occurrences of RED in the source code are removed and not replaced with anything, so you must use caution.

Avoiding Multiple Inclusions of Header Files

As programs grow, or as you use header files more often, you run the risk of accidentally including a header file more than once. This can cause the compiler to balk in confusion. Using the directives you've learned, you can easily avoid this problem. Look at the example shown in Listing 21.5.

Page 115: Session 3

Listing 21.5. Using preprocessor directives with header files.1: /* PROG.H - A header file with a check to prevent multiple includes! */2:3. #if defined( PROG_H )4: /* the file has been included already */5: #else6: #define PROG_H7:8: /* Header file information goes here... */9:10:11:12: #endif

ANALYSIS: Examine what this header file does. On line 3, it checks whether PROG_H is defined. Notice that PROG_H is similar to the name of the header file. If PROG_H is defined, a comment is included on line 4, and the program looks for the #endif at the end of the header file. This means that nothing more is done.

How does PROG_H get defined? It is defined on line 6. The first time this header is included, the preprocessor checks whether PROG_H is defined. It won't be, so control goes to the #else statement. The first thing done after the #else is to define PROG_H so that any other inclusions of this file skip the body of the file. Lines 7 through 11 can contain any number of commands or declarations.

The #undef Directive

The #undef directive is the opposite of #define--it removes the definition from a name. Here's an example:

#define DEBUG 1/* In this section of the program, occurrences of DEBUG *//* are replaced with 1, and the expression defined( DEBUG ) *//* evaluates to TRUE. *.#undef DEBUG/* In this section of the program, occurrences of DEBUG *//* are not replaced, and the expression defined( DEBUG ) *//* evaluates to FALSE. */

You can use #undef and #define to create a name that is defined only in parts of your source code. You can use this in combination with the #if directive, as explained earlier, for more control over conditional compilations.

Predefined Macros

Page 116: Session 3

Most compilers have a number of predefined macros. The most useful of these are __DATE__, __TIME__, __LINE__, and __FILE__. Notice that each of these are preceded and followed by double underscores. This is done to prevent you from redefining them, on the theory that programmers are unlikely to create their own definitions with leading and trailing underscores.

These macros work just like the macros described earlier in this chapter. When the precompiler encounters one of these macros, it replaces the macro with the macro's code. __DATE__ and __TIME__ are replaced with the current date and time. This is the date and time the source file is precompiled. This can be useful information as you're working with different versions of a program. By having a program display its compilation date and time, you can tell whether you're running the latest version of the program or an earlier one.

The other two macros are even more valuable. __LINE__ is replaced by the current source-file line number. __FILE__ is replaced with the current source-code filename. These two macros are best used when you're trying to debug a program or deal with errors. Consider the following printf() statement:

31:32: printf( "Program %s: (%d) Error opening file ", __FILE__, __LINE__ );33:

If these lines were part of a program called MYPROG.C, they would print

Program MYPROG.C: (32) Error opening file

This might not seem important at this point, but as your programs grow and spread across multiple source files, finding errors becomes more difficult. Using __LINE__ and __FILE__ makes debugging much easier.

DO use the __LINE__ and __FILE__ macros to make your error messages more helpful.

DON'T forget the #endif when using the #if statement.

DO put parentheses around the value to be passed to a macro. This prevents errors. For example, use this:#define CUBE(x) (x)*(x)*(x)

instead of this:#define CUBE(x) x*x*x

Using Command-Line Arguments

Page 117: Session 3

Your C program can access arguments passed to the program on the command line. This refers to information entered after the program name when you start the program. If you start a program named PROGNAME from the C:\> prompt, for example, you could enter

C:\>progname smith jones

The two command-line arguments smith and jones can be retrieved by the program during execution. You can think of this information as arguments passed to the program's main() function. Such command-line arguments permit information to be passed to the program at startup rather than during execution, which can be convenient at times. You can pass as many command-line arguments as you like. Note that command-line arguments can be retrieved only within main(). To do so, declare main() as follows:

main(int argc, char *argv[]){/* Statements go here */}

The first parameter, argc, is an integer giving the number of command-line arguments available. This value is always at least 1, because the program name is counted as the first argument. The parameter argv[] is an array of pointers to strings. The valid subscripts for this array are 0 through argc - 1. The pointer argv[0] points to the program name (including path information), argv[1] points to the first argument that follows the program name, and so on. Note that the names argc and argv[] aren't required--you can use any valid C variable names you like to receive the command-line arguments. However, these two names are traditionally used for this purpose, so you should probably stick with them.

The command line is divided into discrete arguments by any white space. If you need to pass an argument that includes a space, enclose the entire argument in double quotation marks. For example, if you enter

C:>progname smith "and jones"

smith is the first argument (pointed to by argv[1]), and and jones is the second (pointed to by argv[2]). Listing 21.6 demonstrates how to access command-line arguments.

Listing 21.6. Passing command-line arguments to main().1: /* Accessing command-line arguments. */2:3: #include <stdio.h>4:5: main(int argc, char *argv[])6: {7: int count;8:

Page 118: Session 3

9: printf("Program name: %s\n", argv[0]);10:11: if (argc > 1)12: {13: for (count = 1; count < argc; count++)14: printf("Argument %d: %s\n", count, argv[count]);15: }16: else17: puts("No command line arguments entered.");18: return(0);19: }list21_6Program name: C:\LIST21_6.EXENo command line arguments entered.list21_6 first second "3 4"Program name: C:\LIST21_6.EXEArgument 1: firstArgument 2: secondArgument 3: 3 4

ANALYSIS: This program does no more than print the command-line parameters entered by the user. Notice that line 5 uses the argc and argv parameters shown previously. Line 9 prints the one command-line parameter that you always have, the program name. Notice this is argv[0]. Line 11 checks to see whether there is more than one command-line parameter. Why more than one and not more than zero? Because there is always at least one--the program name. If there are additional arguments, a for loop prints each to the screen (lines 13 and 14). Otherwise, an appropriate message is printed (line 17).

Command-line arguments generally fall into two categories: those that are required because the program can't operate without them, and those that are optional, such as flags that instruct the program to act in a certain way. For example, imagine a program that sorts the data in a file. If you write the program to receive the input filename from the command line, the name is required information. If the user forgets to enter the input filename on the command line, the program must somehow deal with the situation. The program could also look for the argument /r, which signals a reverse-order sort. This argument isn't required; the program looks for it and behaves one way if it's found and another way if it isn't.

DO use argc and argv as the variable names for the command-line arguments for main(). Most C programmers are familiar with these names.

DON'T assume that users will enter the correct number of command-line parameters. Check to be sure they did, and if not, display a message explaining the arguments they should enter. Summary

Page 119: Session 3

This chapter covered some of the more advanced programming tools available with C compilers. You learned how to write a program that has source code divided among multiple files or modules. This practice, called modular programming, makes it easy to reuse general-purpose functions in more than one program. You saw how you can use preprocessor directives to create function macros, for conditional compilation, and other tasks. Finally, you saw that the compiler provides some function macros for you.

Q&AQ When compiling multiple files, how does the compiler know which filename to use for the executable file?

A You might think the compiler uses the name of the file containing the main() function; however, this isn't usually the case. When compiling from the command line, the first file listed is used to determine the name. For example, if you compiled the following with Borland's Turbo C, the executable would be called FILE1.EXE:

tcc file1.c main.c prog.cQ Do header files need to have an .H extension?

A No. You can give a header file any name you want. It is standard practice to use the .H extension.

Q When including header files, can I use an explicit path?

A Yes. If you want to state the path where a file to be included is, you can. In such a case, you put the name of the include file between quotation marks.

Q Are all the predefined macros and preprocessor directives presented in this chapter?

A No. The predefined macros and directives presented in this chapter are ones common to most compilers. However, most compilers also have additional macros and constants.

Q Is the following header also acceptable when using main() with command-line parameters?

main( int argc, char **argv);A You can probably answer this one on your own. This declaration uses a pointer to a character pointer instead of a pointer to a character array. Because an array is a pointer, this definition is virtually the same as the one presented in this chapter. This declaration is also commonly used. (See Day 8, "Using Numeric Arrays," and Day 10, "Characters and Strings," for more details.)

Workshop

Page 120: Session 3

The Workshop provides quiz questions to help you solidify your understanding of the material covered and exercises to provide you with experience in using what you've learned.

Quiz1. What does the term modular programming mean?

2. In modular programming, what is the main module?

3. When you define a macro, why should each argument be enclosed in parentheses?

4. What are the pros and cons of using a macro in place of a regular function?

5. What does the defined() operator do?

6. What must always be used if #if is used?

7. What extension do compiled C files have? (Assume that they have not been linked.)

8. What does #include do?

9. What is the difference between this line of code:

#include <myfile.h>and this line of code:

#include "myfile.h"10. What is __DATE__ used for?

11. What does argv[0] point to?

Exercises

Because many solutions are possible for the following exercises, answers are not provided.1. Use your compiler to compile multiple source files into a single executable file. (You can use Listings 21.1, 21.2, and 21.3 or your own listings.)

2. Write an error routine that receives an error number, line number, and module name. The routine should print a formatted error message and then exit the program. Use the predefined macros for the line number and module name (pass the line number and module name from the location where the error occurs). Here's a possible example of a formatted error:

module.c (Line ##): Error number ##

Page 121: Session 3

3. Modify exercise 2 to make the error message more descriptive. Create a text file with your editor that contains an error number and message. Call this file ERRORS.TXT. It could contain information such as the following:

1 Error number 12 Error number 290 Error opening file100 Error reading fileHave your error routine search this file and display the appropriate error message based on a number passed to it.

4. Some header files might be included more than once when you're writing a mod-ular program. Use preprocessor directives to write the skeleton of a header file that compiles only the first time it is encountered during compilation.

5. Write a program that takes two filenames as command-line parameters. The program should copy the first file into the second file. (See Day 16, "Using Disk Files," if you need help working with files.)

6. This is the last exercise of the book, and its content is up to you. Select a programming task of interest to you that also meets a real need you have. For example, you could write programs to catalog your compact disc collection, keep track of your checkbook, or calculate financial figures related to a planned house purchase. There's no substitute for tackling a real-world programming problem in order to sharpen your programming skills and help you remember all the things you learned in this book.

© Copyright, Macmillan Computer Publishing. All rights reserved.