Chapter 1 Raptor
Chapter 1 Raptor
Chapter 1 Raptor
Input
Computer
Output
CONTROL
UNIT
INPUT
OUTPUT
ALU
MEMORY
Figure 1.2: Basic structure of a computer
Page no: 1
1. Input Devices:
Allows getting data into the computer. A simple example of input device is keyboard.
2. Output devices:
Shows the result after processing data or information.
3. Central Processing Unit (CPU)
It is electronic circuit that manipulates data into the required information. That is,
CPU executes the computer instruction. It consists of two parts, Arithmetic Logic
Unit (ALU) and Control Unit (CU).
-
Control Unit
Directs and coordinates the execution of stored program instruction.
4. Memory
There are two kinds of computer memory: primary and secondary. Primary memory
is accessible directly by the processing unit. Random Access Memory (RAM) is an
example of primary memory. As soon as the computer is switched off the contents of
the primary memory is lost. You can store and retrieve data much faster with primary
memory compared to secondary memory. Secondary memory is used to store data
permanently. An example of this type of memory includes floppy disks, magnetic
disk. Primary memory is more expensive than secondary memory. Because of this the
size of primary memory is less than that of secondary memory.
Computer memory is used to store two things: (i) instructions to execute a program
and (ii) data. When the computer is doing any job, the data that have to be processed
are stored in the RAM. This data may come from an input device like keyboard or
from a secondary storage device like a floppy disk.
In computer all information are stored in the form of bits. A bit is a binary digit,
which is either 0 or 1. A unit of 8 bits is known as Byte.
Computer memory is expressed in terms of the number of bytes it can hold. The
number of bytes is expressed as kilobytes, 2 to the 10th power (210), or 1024 bytes.
kilobyte is abbreviated KB, or simply K. Thus, the memory of a 640K computer can
store 640 x 1024, or 655,360 bytes of data. Memory capacity is most often expressed
in terms of a megabyte (1024 x 1024), abbreviated MB. One megabyte is roughly
one million bytes. Some large computers express memory in terms of gigabytes
(abbreviated GB)-billions of bytes.
Page no: 2
Page no: 3
Page no: 4
Once the program code is written, it is very unlikely that it will be perfect on the first run.
Programming errors are common in the early versions of the program. Most programmers
use the phase: desk-checking, translating and debugging.
Desk-checking: Tracing down the program code to discover any error that might be
there. Similar to proof reading and may uncover several errors.
Translating: A translator is a program that converts the code into a language, which the
computer can understand. A compiler is a translator and has in-built capabilities of
detecting errors and produce a listing of them. These are mostly errors due to the
wrong syntax in the use of the language.
Debugging: Detecting errors (bugs) by running the program. Most of the errors in this
phase are due to the logic of the program
v.
Documenting the Program
Documenting the program is a detailed description of the programming cycle and specific
facts about the program. Documenting is an on-going process needed to supplement
human memory and help organize program planning. Documentation is also critical to
communication with other who might have an interest in your program. Typical
documentation materials include origin and nature of the problem, brief description of the
program, logic tools such as flowcharts and pseudocode, and testing results. Comments
on the program code are also an important part of documentation.
Page no: 5
ALGORITHMS
The term algorithm originally referred to any computation performed via a set of rules
applied to numbers written in decimal form. The word is derived from the phonetic
pronunciation of the last name of Abu Ja'far Mohammed ibn Musa al-Khowarizmi, who
was an Arabic mathematician who invented a set of rules for performing the four basic
arithmetic operations (addition, subtraction, multiplication and division) on decimal
numbers.
An algorithm is a representation of a solution to a problem. If a problem can be defined
as a difference between a desired situation and the current situation in which one is, then
a problem solution is a procedure, or method, for transforming the current situation to the
desired one. We solve many such trivial problems every day without even thinking about
it, for example making breakfast, travelling to the workplace etc. But the solution to such
problems requires little intellectual effort and is relatively unimportant. However, the
solution of a more interesting problem of more importance usually involves stating the
problem in an understandable form and communicating the solution to others. In the case
where a computer is part of the means of solving the problem, a procedure, explicitly
stating the steps leading to the solution, must be transmitted to the computer. This
concept of problem solution and communication makes the study of algorithms important
to computer science.
Throughout history, man has thought of ever more elegant ways of reducing the amount
of labour needed to do things. A computer has immense potential for saving time/energy,
as most (computational) tasks that are repetitive or can be generalised can be done by a
computer. For a computer to perform a desired task, a method for carrying out some
sequence of events, resulting in accomplishing the task, must somehow be described to
the computer. The algorithm can be described on many levels because the algorithm is
just the procedure of steps to take and get the result. The language used to describe an
algorithm to other people will be quite different from that which is used by the computer,
however the actual algorithm will in essence be the same. An example of an algorithm
people use would be a recipe to make a cake.
"4 extra large eggs, beaten
1&1/2 C. stock
1/2 teaspoon salt
1 scallion, minced
1 C. small shrimp or lobster flakes
1 t. soy sauce
1 Tablespoon oil
1. Mix all the ingredients, except the oil, in a deep bowl.
Page no: 6
2.
3.
4.
5.
Put 1" water in wide pot, then place deep bowl of batter inside.
Cover pot tightly and steam 15 min.
Heat oil very hot and pour over custard.
Steam 5 more min.
Serves 4 people"
This breaks down 'Making Chinese egg custard' into smaller steps. To make the product
one still needs to know how to execute each of the steps in the procedure and understand
all of the terms.
Definition:
A procedure is a finite sequence of well-defined instructions, each of which can be
mechanically carried out in a finite amount of time.
The procedure must break up the problem solution into parts that the recipient party can
understand and execute. In the case of a computer, the problem solution is usually in the
form of a program that encompasses the algorithm and explains to the computer a clearly
defined procedure for achieving the solution. The procedure must consist of smaller steps
each of which the computers understand. There may be no ambiguities in the translation
of the procedure into the necessary action to be taken. A program is then just a specific
realisation of an algorithm, which may be executed on a physical device.
A computer is essentially a physical device designed to carry out a collection of primitive
actions. A procedure is a sequence of instructions written in terms of which evoke a
proper operation. To make effective use of an algorithm on a computer one must not only
find and understand a solution to the problem but also convey the algorithm to the
computer, giving the correct sequence of understood commands that represent the same
algorithm.
Definition:
An algorithm is procedure consisting of a finite set of unambiguous rules (instructions)
which specify a finite sequence of operations that provides the solution to a problem, or
to a specific class of problems for any allowable set of input quantities (if there are
inputs). In other word, an algorithm is a step-by-step procedure to solve a given
problem
Alternatively, we can define an algorithm as a set or list of instructions for carrying out
some process step by step. A recipe in a cookbook is an excellent example of an
algorithm. The recipe includes the requirements for the cooking or ingredients and the
method of cooking them until you end up with a nice cooked dish.
In the same way, algorithms executed by a computer can combine millions of elementary
steps, such as additions and subtractions, into a complicated mathematical calculation.
Also by means of algorithms, a computer can control a manufacturing process or co-
Page no: 7
ordinate the reservations of an airline as they are received from the ticket offices all over
the country. Algorithms for such large-scale processes are, of course, very complex, but
they are built up from pieces.
One of the obstacles to overcome in using a computer to solve your problems is that of
translating the idea of the algorithm to computer code (program). People cannot normally
understand the actual machine code that the computer needs to run a program, so
programs are written in a programming language such as C or Pascal, which is then
converted into machine code for the computer to run.
In the problem-solving phase of computer programming, you will be designing
algorithms. This means that you will have to be conscious of the strategies you use to
solve problems in order to apply them to programming problems. These algorithms can
be designed though the use of flowcharts or pseudocode.
2.2 FLOWCHARTS
Flowcharting is a tool developed in the computer industry, for showing the steps
involved in a process. A flowchart is a diagram made up of boxes, diamonds and other
shapes, connected by arrows - each shape represents a step in the process, and the arrows
show the order in which they occur. Flowcharting combines symbols and flowlines, to
show figuratively the operation of an algorithm.
In computing, there are dozens of different symbols used in flowcharting (there are even
national and international flowcharting symbol standards). In business process analysis, a
couple of symbols are sufficient. A box with text inside indicates a step in the process,
while a diamond with text represents a decision point. See the figure for an example.
If the flowchart is too messy to draw, try starting again, but leaving out all of the decision
points and concentrating on the simplest possible course. Then the session can go back
and add the decision points later. It may also be useful to start by drawing a high-level
flowchart for the whole organisation, with each box being a complete process that has to
be filled out later.
From this common understanding can come a number of things - process improvement
ideas will often arise spontaneously during a flowcharting session. And after the session,
the facilitator can also draw up a written procedure - a flowcharting session is a good way
of documenting a process.
Process improvement starts with an understanding of the process, and flowcharting is the
first step towards process understanding.
Page no: 8
Flowcharting Symbols
There are 6 basic symbols commonly used in flowcharting of assembly language
programs: Terminal, Process, input/output, Decision, Connector and Predefined Process.
This is not a complete list of all the possible flowcharting symbols, it is the ones used
most often in the structure of Assembly language programming.
Symbol
Name
Function
Process
input/output
Decision
Connector
Predefined Process
Terminal
Flow Lines
Page no: 9
4. Generally a flowchart will flow from top to bottom. However, an upward flow
can be shown as long as it does not exceed 3 symbols.
5. Connectors are used to connect breaks in the flowchart. Examples are:
From one page to another page.
From the bottom of the page to the top of the same page.
An upward flow of more then 3 symbols
6. Subroutines and Interrupt programs have their own and independent flowcharts.
7. All flow charts start with a Terminal or Predefined Process (for interrupt
programs or subroutines) symbol.
8. All flowcharts end with a terminal or a contentious loop.
Flowcharting uses symbols that have been in use for a number of years to represent the
type of operations and/or processes being performed. The standardised format provides a
common method for people to visualise problems together in the same manner. The use
of standardised symbols makes the flow charts easier to interpret, however, standardising
symbols is not as important as the sequence of activities that make up the process.
Flowcharting Tips
Chart the process the way it is really occurring. Do not document the way a written
process or a manager thinks the process happens.
People typically modify existing processes to enable a more efficient process. If the
desired or theoretical process is charted, problems with the existing process will not
be recognised and no improvements can be made.
Note all circumstances actually dealt with.
Test the flow chart by trying to follow the chart to perform the process charted. If
there is a problem performing the operation as charted, note any differences and
modify the chart to correct. A better approach would be to have someone unfamiliar
with the process try to follow the flow chart and note questions or problems found.
Include mental steps in the process such as decisions. These steps are sometimes left
out because of familiarity with the process, however, represent sources of problems
due to a possible lack of information used to make the decision can be inadequate or
incorrect if performed by a different person.
Page no: 10
a) Algorithm
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Start
Sum = 0
Get the first testscore
Add first testscore to sum
Get the second testscore
Add to sum
Get the third testscore
Add to sum
Get the Forth testscore
Add to sum
Get the fifth testscore
Add to sum
Get the sixth testscore
Add to sum
Output the sum
Stop
Sum = 0
Page no: 11
Output Sum
STOP
The algorithm and the flowchart above illustrate the steps for solving the problem of
adding six testscores. Where one testscore is added to sum at a time. Both the algorithm
and flowchart should always have a Start step at the beginning of the algorithm or
flowchart and at least one stop step at the end, or anywhere in the algorithm or flowchart.
Since we want the sum of six testscore, then we should have a container for the resulting
sum. In this example, the container is called sum and we make sure that sum should start
with a zero value by step 2.
Page no: 12
Example 2: The problem with this algorithm is that, some of the steps appear more than
once, i.e. step 5 get second number, step 7, get third number, etc. One could shorten the
algorithm or flowchart as follows:
1.
2.
3.
4.
5.
6.
7.
Start
Sum = 0
Get a value
sum = sum + value
Go to step 3 to get next Value
Output the sum
Stop
Start
Sum =
Get a value
Output
STOP
This algorithm and its corresponding flowchart are a bit shorter than the first one. In this
algorithm, step 3 to 5 will be repeated, where a number is obtained and added to sum.
Similarly the flowchart indicates a flowline being drawn back to the previous step
indicating that the portion of the flowchart is being repeated. One problem indicates that
these steps will be repeated endlessly, resulting in an endless algorithm or flowchart. The
algorithm needs to be improved to eliminate this problem. In order to solve this problem,
we need to add a last value to the list of numbers given. This value should be unique so
that, each time we get a value, we test the value to see if we have reached the last value.
In this way our algorithm will be a finite algorithm which ends in a finite number of steps
as shown below. There are many ways of making the algorithm finite.
The new list of numbers will be 26, 49, 498, 9387, 48962, 1, -1. The value 1 is a unique
number since all other numbers are positive.
1. Start
2. Sum = 0
3. Get a value
Page no: 13
4.
5.
6.
7.
8.
Corresponding flowchart
START
Sum = 0
Get a value
Value
= -1
Yes
No
Sum = Sum + Value
Output Sum
STOP
3. DATA TYPES
Although some contemporary languages allow programmers to invent his own data
types, and define their related operations, there are a number of traditional data types
found in most languages:
Integer
Integers are numeric data items, which are either positive or negative including zero, i.e.
1, 488, -22, 0, 456. Some programming languages put restrictions on the magnitude of
integers which may be used in program instructions. These restrictions are usually
dependent on the size of the memory location of the computer in which the language
may run.
Page no: 14
Real Numbers
There are two types of real numbers, Fixed-Point and Floating Point.
Fixed Point
Fixed point data items are numbers which have embedded decimal point i.e. 1.5,
458.4589, -0.569.
Floating Point
Floating point data items are numbers, which are, held as binary fractions by a computer.
The numbers are expressed in a form where you have a mantissa and an exponent, for
example
Number
12.3
= 0.123 * 102
123000 = 0.123 * 106
0.000123 =0.123 * 10-3
Mantissa
0.123
0.123
0.123
Exponent
2
6
-3
Floating point representation of data is used to overcome the restrictions placed on the
magnitude of numbers by the size of computers memory locations.
Character
Character data, sometimes referred to as string data, may consist of any digits, letters of
the alphabet or symbols which, the internal coding system of the computer is capable of
representing. Many programming languages require character data to be enclosed by
quotation marks when used in program instructions, for example PRINT HAPPY NEW
YEAR.
Boolean
Boolean data items are used as status indicators and may contain only one of two possible
values: True or False.
DATA ITEM
There are two basic methods of using data items in a program:
a)
Constants
Data items are sometimes required to keep their values throughout the program, hence the
term constant. A constant is a specific value or character string used explicitly in an
operation. Consider the constant values 47.5, 1, and 13 in the example below.
Multiply by 47.5
Add 1 to
If = 13
Print PLEASE INPUT TODAYS DATE
Page no: 15
b)
Assignment
The assignment operation has the form:
variable := expression. (Pascal)
variable = expression. (C/C++/Java)
The assignment operation is used to assign a name to a value. Thus it is used whenever
you need to keep track of a value that is needed later. Some typical uses include:
The assignment operator is not commute i.e. x = e is not the same as e = x. The variable
must be declared. Variables used in the expression must be defined (have values). The
type of the expression must be compatible with the type of the variable.
The order in which assignments are performed is important for example, if the first and
second assignments in the swap sequence were interchanged, x and y would end up
assigned to the same value. The input operation and the output operation share some of
the same constraints.
2.5 PSEUDOCODE
Pseudocode is one of the tools that can be used to write a preliminary plan that can be
developed into a computer program. Pseudocode is a generic way of describing an
algorithm without use of any specific programming language syntax. It is, as the name
suggests, pseudo code it cannot be executed on a real computer, but it models and
resembles real programming code, and is written at roughly the same level of detail.
Pseudocode, by nature, exists in various forms, although most borrow syntax from
popular programming languages (like C, Lisp, or FORTRAN). Natural language is used
whenever details are unimportant or distracting.
MT 512: Programming Design
Page no: 16
Computer science textbooks often use pseudocode in their examples so that all
programmers can understand them, even if they do not all know the same programming
languages. Since pseudocode style varies from author to author, there is usually an
accompanying introduction explaining the syntax used.
In the algorithm design, the steps of the algorithm are written in free English text and,
although brevity is desired, they may be as long as needed to describe the particular
operation. The steps of an algorithm are said to be written in pseudocode.
Many languages, such as Pascal, have a syntax that is almost identical to pseudocode and
hence make the transition from design to coding extremely easy.
The following section deal with the control structures (control constructs) Sequence,
Selection and Iteration or Repetition.
Page no: 17
Start
Average = sum/6
Output sum
Stop
Example 3: This is the pseudo-code required to input three numbers from the keyboard
and output the result.
Use variables: sum, number1, number2, number3 of type integer
Accept number1, number2, number3
Sum = number1 + number2 + number3
Print sum
End program
Example 4: The following pseudo-code describes an algorithm which will accept two
numbers from the keyboard and calculate the sum and product displaying the answer on
the monitor screen.
Use variables sum, product, number1, number2 of type real
display Input two numbers
accept number1, number2
sum = number1 + number2
print The sum is , sum
product = number1 * number2
print The Product is , product
end program
Decision Structure or Selection Structure
The decision structure or mostly commonly known as a selection structure, is case where
in the algorithm, one has to make a choice of two alternatives by making decision
depending on a given condition.
Page no: 18
Selection structures are also called case selection structures when there are two or more
alternatives to choose from.
This structure can be illustrated in a flowchart as follows:
True
Condition
False
Task-A
Task-B
False
Condition
True
Task-A
Page no: 19
Making Choices
There are many occasions where a program is required to take alternative actions. For
example, there are occasions where we need to take action according to the user choice.
All computer languages provide a means of selection. Usually it is in the form of If
statement and our pseudo-code is no exception to this.
We will use the if statement together with logical operators to test for true or false as
shown below.
If a = b
print a = b
The action is only taken when the test is true.
The logical operators used in our pseudo-code are
=
is equal to
>
is greater than
<
is less than
>=
is greater than or equal
<=
is less than or equal
<>
is not eaqual to
Example 5: The following shows how the selection control structure is used in a program
where a user chooses the options for multiplying the numbers or adding them or
subtracting.
Use variables: choice, of the type character
ans, number1, number2, of type integer
display choose one of the following
display m for multiply
display a for add
display s for subtract
accept choice
display input two numbers you want to use
accept number1, number2
Page no: 20
80 Distinction
60 Merit
40 Pass
40 fail
The pseudo-code is
Use variables: mark of type integer
If mark >= 80 display distinction
If mark >= 60 and mark < 80 display merit
If mark >= 40 and mark < 60 display pass
If mark < 40 display fail
An if statement on its own is often not the best way of solving problems. A more elegant
set of conditions can be created by adding an else statement to the if statement. The else
statement is used to deal with situations as shown in the following examples.
Example 7: A person is paid at top for category 1 work otherwise pay is at normal rate.
If the work is category 1
pay-rate is top
Else
pay-rate is normal
Page no: 21
The else statement provides a neat way of dealing with alternative condition. In pseudocode we write
If work = cat1 then p-rate: = top
Else p-rate = normal
Or
If work = cat1 then
p-rate: = top
Else
p-rate = normal
The following example illustrate the use of if else statements in implementing double
alternative conditions.
If salary < 50000 then
Tax = 0
Else
If salary > 50000 AND salary < 100000 then
Tax = 50000 * 0.05
Else
Tax = 100000 * 0.30
The case statement
Repeating the if else statements a number of times can be somewhat confusing. An
alternative method provided in a number of languages is to use a selector determined by
the alternative conditions that are needed. In our pseudo-code, this will called a case
statement.
Example 8: The following program segment outputs a message to the monitor screen
describing the insurance available according to a category input by the user.
Use variables: category of type character
Display input category
Accept category
If category = U
Display insurance is not available
Else
If category = A then
Display insurance is double
Else
If category = B then
Display insurance is normal
Else
If category = M then
Display insurance is medically dependent
Else
Display entry invalid
Page no: 22
Condition
False
True
Task
Any program instruction that repeats some statement or sequence of statements a number
of times is called an iteration or a loop. The commands used to create iterations or loops
Page no: 23
are all based on logical tests. There three constructs for iterations or loops in our pseudocode.
The Repeat Until loop.
The syntax is
REPEAT
A statement or block of statements
UNTIL a true condition
Example 9: A program segment repeatedly asks for entry of a number in the range 1 to
100 until a valid number is entered.
REPEAT
DISPLAY Enter a number between 1 and 100
ACCEPT number
UNTIL number < 1 OR number > 100
Example 10. A survey has been carried out to discover the most popular sport. The
results will be typed into the computer for analysis. Write a program to accomplish this.
REPEAT
DISPLAY Type in the letter chosen or Q to finish
DISPLAY A: Athletics
DISPLAY S: Swimming
DISPLAY F: Football
DISPLAY B: Badminton
DISPLAY Enter data
ACCEPT letter
If letter = A then
Athletics = athletics + 1
If letter = S then
Swimming = Swimming + 1
If letter = F then
Football = Football + 1
If letter = B then
Badminton = Badminton + 1
UNTIL letter = Q
DISLAY Athletics scored, athletics, votes
DISLAY Swimming scored, swimming, votes
DISLAY Football scored, football, votes
DISLAY Badminton scored, Badminton, votes
The WHILE loop
The second type of iteration we will look at is the while iteration. This type of conditional
loop tests for terminating condition at the beginning of the loop. In this case no action is
performed at all if the first test causes the terminating condition to evaluate as false.
Page no: 24
The syntax is
WHILE (a condition is true)
A statement or block of statements
ENDWHILE
Example 11: A program segment to print out each character typed at a keyboard until the
character q is entered.
WHILE letter <> q
ACCEPT letter
DISPLAY The character you typed is, letter
ENDWHILE
Example 12: Write a program that will output the square root of any number input until
the number input is zero.
In some cases, a variable has to be initialised before execution of the loop as shown in
the following example.
Use variable: number of type real
DISPLAY Type in a number or zero to stop
ACCEPT number
WHILE number <> 0
Square = number * number
DISPLAY The square of the number is, square
DISPLAY Type in a number or zero to stop
ACCEPT number
ENDWHILE
The FOR Loop
The third type of iteration, which we shall use when the number of iterations is known in
advance, is a for loop. This, in its simplest form, uses an initialisation of the variable as a
starting point, a stop condition depending on the value of the variable. The variable is
incremented on each iteration until it reaches the required value.
The pseudo-code syntax will be:
FOR (starting state, stopping condition, increment)
Statements
ENDFOR
Example 13.
FOR (n = 1, n <= 4, n + 1)
DISPLAY loop, n
ENDFOR
The fragment of code will produce the output
Loop 1
Loop 2
Loop 3
Loop 4
Page no: 25
In the example, n is usually referred as the loop variable, or counting variable, or index of
the loop. The loop variable can be used in any statement of the loop. The variable should
not be assigned a new value within the loop, which may change the behaviour of the
loop.
Example 14: Write a program to calculate the sum and average of a series of numbers.
The pseudo-code solution is:
Use variables: n, count of the type integer
Sum, number, average of the type real
DISPLAY How many numbers do you want to input
ACCEPT count
SUM = 0
FOR (n = 1, n <= count, n + 1)
DISPLAY Input the number from your list
ACCEPT number
SUM = sum + number
ENDFOR
Average = sum / count
DISPLAY The sum of the numbers is , sum
DISPLAY Average of the numbers is , average
Flowcharts have been used in this section to illustrate the nature of the three control
structures. These three are the basic control structures out of which all programs are built.
Beyond this, flowcharts serve the programmer in two distinct ways: as problem solving
tools and as tools for documenting a program.
Example
Design an algorithm and the corresponding flowchart for finding the sum of n numbers.
Pseudocode Program
Start
Sum = 0
Display Input value n
Input n
For(I = 1, n, 5)
Input a value
Sum = sum + value
ENDFOR
Output sum
Stop
In this example, we have used I to allow us to count the numbers, which we get for the
addition. We compare I with n to check whether we have exhausted the numbers or not in
order to stop the computation of the sum (or to stop the iteration structure). In such a
case, I is referred to as a counter.
Page no: 26
Input a number
True
I>n
False
Output Sum
Exercise
1. Design an algorithm and the corresponding flowchart for finding the sum of
the numbers 2, 4, 6, 8, , n
2. Using flowcharts, write an algorithm to read 100 numbers and then display the
sum.
3. Write an algorithm to read two numbers then display the largest.
4. Write an algorithm to read two numbers then display the smallest
5. Write an algorithm to read three numbers then display the largest.
6. Write an algorithm to read 100 numbers then display the largest.
Page no: 27
CHAPTER
3
ALGORITHMIC PROBLEM SOLVING
In this chapter you will learn about
What an algorithm is.
The relationship between data and algorithm.
The characteristics of an algorithm.
Using pseudo-codes and flowcharts to represent algorithms.
32
Chapter 3
3.1 Algorithms
In Chapter 2, we expounded the working of problem solving from a general
perspective. In computing, we focus on the type of problems categorically
known as algorithmic problems, where their solutions are expressible in the
form of algorithms.
An algorithm 1 is a well-defined computational procedure consisting of a
set of instructions, that takes some value or set of values, as input, and
produces some value or set of values, as output. In other word, an algorithm
is a procedure that accepts data, manipulate them following the prescribed
steps, so as to eventually fill the required unknown with the desired value(s).
Input
Algorithm
Output
The term algorithm was derived from the name of Mohammed al-Khowarizmi, a Persian mathematician in the ninth
century. Al-Khowarizmi Algorismus (in Latin) Algorithm.
3.1
Algorithms
33
ingredients
recipe
(software)
Cooking utensils
(hardware)
Ah-gong
bah-kut-teh
The first documented algorithm is the famous Euclidean algorithm written
by the Greek mathematician Euclid in 300 B.C. in his Book VII of the
Elements. It is rumoured that King Ptolemy, having looked through the
Elements, hopefully asked Euclid if there were not a shorter way to geometry,
to which Euclid severely answered: In geometry there is no royal road!
The modern Euclidean algorithm to compute gcd (greatest common
divisor) of two integers, is often presented as followed.
1. Let A and B be integers with A > B 0.
2. If B = 0, then the gcd is A and the algorithm ends.
3. Otherwise, find q and r such that
A = qB + r where 0 r < B
Note that we have 0 r < B < A and gcd(A,B) = gcd(B,r).
Replace A by B, and B by r. Go to step 2.
Walk through this algorithm with some sets of values.
34
Chapter 3
3.3
Characteristics Of An Algorithm 35
36
Chapter 3
Algorithm version 2:
sum count 0
min ?
max ?
for each num entered,
increment count
sum sum + num
if num < min then min num
if num > max then max num
ave sum/count
Note the use of indentation and symbols in the second version. What
should min and max be initialised with?
Algorithms may also be represented by diagrams. One popular
diagrammatic method is the flowchart, which consists of terminator boxes,
process boxes, and decision boxes, with flows of logic indicated by arrows.
The flowchart below depicts the same logic as the algorithms above.
start
Terminator box
Process box
sum count 0
min ?
max ?
Yes
Decision box
end of
input?
No
increment count
sum sum + num
num<min?
ave sum/count
min num
No
num>max?
end
Yes
Yes
max num
No
3.5
Control Structures 37
3.6
Summary
38
Chapter 3
Exercises
In the exercises below, you are asked to find the answers by hand, and jot
down the steps involved for the generalized versions. You need not write
programs for them yet you will be doing that later you need only to
discover the steps and put them down into an algorithm.
1.
2.
How would you sort 10 numbers in increasing order? Do you know any
of the basic sorting techniques?
3.
4.
Two words are anagrams of each other if they differ only by the order
of their characters. For example, HATE and HEAT, NOW and
WON, reset and steer are anagrams, but sell and less are not.
Write an algorithm to determine if two given words are anagrams.
5.
How do you test for primality? That is, given a positive integer, how
do you determine that it is a prime number?
6.
4. PROGRAMMING APPROACHES
Organizations and individuals are continually searching for more efficient ways to
perform the software development process.
One-way of reducing the time and cost of development is to standardize software
programs and the programming process. The benefits of standardized programs are that
they are easier to code, maintain, debug, and modify.
In recent years, a variety of techniques have appeared attempting to minimize differences
in the way programmers' design and develop software. A few of the most commonly used
techniques for standardization are described in this lesson.
Programming Approaches: Nonstructured Vs. Structured Approaches
Structured programming is a standardization technique used for software development.
This approach works by having all programmers use the same structured design
techniques. Structured programming was invented to address the shortcomings of nonstructured programming, which frequently employed GO TO branch points to transfer
from one part of the program to another part. Using GO TO codes, one could transfer
backward, forward, or anywhere else within the program. The problem is that the
connections between parts of the program by using GO TO commands can become quite
haphazard.
The haphazard and sometimes convoluted pattern of linkages between parts of the
program has been called spaghetti code. This type of programming is difficult to
understand and debug. Non-structured programming of this nature is now viewed as an
ineffective programming strategy.
To develop good software, developers have to carefully think out and design the
programs. In the earliest days of computing, programmers wrote software according to
their own whims, with the result that programs were often confusing and difficult to work
with. Software today is expected to follow recognised design principles. The prevailing
design standards are structured programming and structured design.
4.1 STRUCTURED PROGRAMMING
Structured programming makes use of the control structures (sequence, selection and
repetition). Structured programming does not use GO TO commands. The sequence
principle implies that program instructions should be executed in the order in which they
appear. The selection principle implies that instructions may be executed selectively
using IF-THEN and/or IF-THEN-ELSE statements. These statements work in the
following way. IF a condition is met or is true, THEN a specific set of instructions will be
executed. If the condition is false, then another set of instructions will be executed.
MT 512: Programming Design
Page no: 38
For example, IF an employee works 40+ hours a week, THEN calculate gross pay based
on an overtime rate of time and a half. If the employee does not work 40+ hours a week,
THEN calculate gross pay based on the normal hourly pay rate. IF-THEN-ELSE works in
a similar way, but in this case the word ELSE is substituted for a false case, a condition
that is not met. IF the employee works 40+ hours a week, then calculate gross pay base
on a time and a half pay rate, ELSE calculate gross pay based on the normal rate.
Alternatively when there are many options, one can employ the CASE statement.
The iteration principle indicates that one part of the program can be repeated or iterated a
limited number of times. In most computer languages, the iteration may be activated by
using REPEAT ---UNTIL or using the WHILE loop and the FOR loop.
4.2
STRUCTURED DESIGN
According to structured design principles, a program should be designed from the topdown or bottom-up as a hierarchical series of modules. A module is a logical way of
partitioning or subdividing a program so that each module performs one or a small
number of related tasks.
4.2.1
Modular Programming
One programming approach that has proven to be most productive is called top-down
decomposition. Top-down decomposition is the process of breaking the overall procedure
or task into component parts (modules) and then subdivide each component module until
the lowest level of detail has been reached. It is called top-down design or top-down
decomposition since we start "at the top" with a general problem and design specific
solutions to its sub problems. In order to obtain an effective solution for the main
Page no: 39
Master file
Earnings
Deductions
Taxing
Net earning
Print reports
The tasks given above can be depicted in a hierarchical chart (Hierarchical Program
Organisation) as shown below.
Page no: 40
PAYROLL PROBLEM
Master File
Create
Master
File
Update
Master
File
Earnings
Create
Earning
File
Update
Earning
File
Deductions
Create
Deduction
File
Taxing
Update
Deduction
File
Create or
update Tax
File
Identifying and diagramming the relationship between modules in this fashion allows
programmers to focus on the overall organisation and logic of the program without
getting bogged down in the details. Once the overall structure of the program is finalised,
detail coding of individual modules can proceed.
It is the set of principles that enable a problem to be solved by breaking it down into
manageable parts, step-by-step from the overall problem specification, in stages through
to the actual code.
4.2.3 Bottom-up Design
Already existing facilities/designs are used/taken into consideration as a model for a new
(better) design. Using Bottom-up design strategy, we take an already existing computer
program as a model for our new program. We try to utilise the existing facilities or design
in a way, which gives out program a better performance.
4.2.3 Stepwise Refinement
Stepwise refinement is a top-down design strategy. The program is developed by
successively refining levels of procedural detail. In each step of the refinement, one or
several instructions of the given program are decomposed into more detailed instructions.
This successive decomposition or refinement of specifications terminates when all
instructions are expressed in terms of any underlying computer or programming
language.
Every refinement step implies some design decisions. It is important that the programmer
is aware of the underlying criteria.
Page no: 41
4.3
SUB-PROGRAMS
In top down design, the problem is broken down into sub-problems. The main problem is
solved by the corresponding main program. Solutions to the sub-problems are provided
by subprograms, known as procedures, functions, or subroutine depending on the
programming language. A subprogram performs or executes the computer instructions
required to solve a given subproblem.
Main Problem
Subproblem
A
Subproblem
B
Main Program
Subproblem
C
Subprogram A
Subprogram B
SubProgram C
Page no: 42
Page no: 43
Page no: 44
void main()
{
float val1, val2;
float total, difference;
val1=2;
val2=4;
sum_and_difference(val1,val, total, difference);
cout<<The sum is <<total;
cout<<The difference is <<difference;
}
The symbol & in the procedure parameter list instructs the computer to copy back any
changes to the values of a and b once the procedure has completed.
In summary, if you want to write a sub-program that has a number of inputs and a single
output, write a function. If you want many outputs from the sub-programs, use a number
of var parameters in a procedure
4.3.3 Built in functions
While most programming languages enable you to write your own functions (as above),
most also provide a library of common functions ready for you to use (e.g. sine, cosine).
Exercise
1. Devise the pseudcode for a program that will accept names and marks of each student in
the class of 100 students, and then calculate the average of all marks. The program
should make sure the entered marks entered are valid (in the range of 0 and 100). Use
the idea of modular programming.
2. Write pseudcode for a program that will read two matrices and then display their sum.
3. The scalar product (also called the inner product or the dot product) of the two
vectors (one-dimensional arrays) A and B with n elements is defined as
n
Page no: 45
Variable names:
One has two choices, and you should choose one and follow it consistently. Variable
names only one word long can begin either with a lower case or an upper case and
thereafter are lower case including other acceptable characters.
Guidelines for choosing meaningful names:
In general, choose English words, which describe the thing being named.
Use simple names for variables used briefly and locally. For example, a loop
counter might be a single letter.
Otherwise, avoid using lots of one- and two- character names like x or b2.
Use common prefixes/suffixes to associate names of the same general type or
category.
Avoid deliberate misspellings and meaningless suffixes to create variables with
similar names, e.g. if the name index is used, do not define another variable with a
name like indx, ndex, or index2.
Avoid names that are similar to each other and thus possibly confusable.
Never use acronyms as abbreviations, instead, if your names are getting long you
may eliminate vowels (e.g., frstElmnt), or use an unambiguous prefix (e.g.,
firstElem), but NOT fe.
Page no: 46
5.1.2
Indentation
Use a modest size indentation. Four spaces is probably optimal. If you anticipate
problems with rightward drift, you could even try two or three, although this is
not as easy to read.
5.1.3 Comments
Comments should help the reader of your code to understand it. Like any other form of
expression, it should not be flowery or repetitive. In particular observe the following
guidelines
For each variable, give a one-line comment stating the use of the variable. These
may follow the variable declaration, as
in:
int i;
/* loop variable */
for (i = 0; i < sizeOfArray; 1)
someArray[i] = 0;
}
Page no: 47
Or you may use a comment block to identify the use of several variables together. Before
each major section of the program, give the purpose of that section.
At the end of statement blocks unless the block is only a couple lines long, there should
be a comment indicating which block is being ended. See the examples above.
Comment Blocks like the one used above should have a running line of /s or asterisks
which clearly identifies the block as a comment, even if the beginning or end of the
comment is not visible on the page or screen.
5.1.4
On many machines and in many software packages, this is a standard line length. It
makes it easier for others to read and/or print your programs.
5.1.5
Sometimes the simple insertion of a blank line here and there to help group a few lines of
code which work together to achieve a sub-goal can make the program much easier to
read. But don't put in too much white space or the reader will not be able to see enough of
the code at a time.
Page no: 48
6. PROGRAM
TESTING
Page no: 49
Page no: 50
This is the type of tests that are performed from a user perspective when we are doing
supported by tools that execute the software for us.
White Box Testing
White box testing might be more appropriately named clear box testing. In this type of
test, the tester knows how the software module or component is implemented. In this
scenario, the tester is trying to ensure that the software does not fail. Automation of white
box testing is more difficult than black box testing. This type of test is usually done from
the developer perspective during unit testing where one of the test resources is the source
code. We need to know how the software has been written so that we can test its possible
failure points.
Software testing is becoming increasingly important. It is important to do it well,
especially when we are involved in component-based development where we don't know
exactly what other components our software may interact with. Adherance to the
development specification and a properly working interface are essential. Some
companies, like Microsoft, have a tester for every developer because the test process is so
important.
Typical Input
Most testing should be done using typical input values that the program design is
supposed to cater for. The problem description will often contain ranges or even absolute
values that the program should expect to handle. Of course, even these can be too many
or too complex for exhaustive testing, so the tester can choose appropriate values.
Some programs do not place restrictions on their input values, but even if they do not,
programs need to be tested on typical values. In some cases, these will be sets of typical
inputs, not just one. The problem with testing on a single value is that the program may
work perfectly on your chosen typical representative value, but fail on another because it
handles the typical value specially without your knowledge. Choosing more than one
typical value can minimize this problem. These typical inputs also become part of the test
suite.
Special Input
Often programs will fail when presented with data that is zero or absent, or too small. It
can also be that the data is too big, or too long. A good strategy in these cases is to
present the program with the simplest possible case (typically zero or absent data) and
then to present it with a complex case involving large values, long strings, or large
numbers of items. If the program passes these tests, it may still fail on typical input
data, and several tests should be run on data that represents the typical case.
Page no: 51
It is useless to rely on one representative input, and even when several tests have
succeeded, suspicion is still appropriate, and more probing is often necessary before
feeling happy about the program. For instance a program that expects to read a name
might get an empty string; a program that expects a number of inputs of the same kind
may get none; a program that stores a maximum of 100 names might get exactly 100. A
list of values might be terminated by a special sentinel value, or perhaps a negative value
where the norm is positive. The program should be able to cater for these, without failing,
so they become part of the test suite
Invalid Input
Many inputs have range restrictions, so the extreme end of the range, and beyond, should
be tested. Names of one character; ages less than zero, or greater than 150; car speeds
over 500 m.p.h., and so on.
These ranges should be tested at their extremes, and beyond to be safe. Even more
common is the program that tests for valid input but does not test for invalid input. If a
number between 1 and 5 is supposed to be input, and the user puts in 6 (or 10000!) what
happens? If a response should be y or n, what happens with a z? Programs that
behave gracefully under this kind of fire are called robust. Programs that crash when
presented with invalid input are just useless!.
Having assembled the test suite (and this could be as small as a handful of values for
small programs) the program should be executed using the inputs and its behaviour
observed and recorded. This is rather like experimentation. If the program succeeds on all
inputs, i.e. its observed behaviour matches the expected behaviour, as extracted from the
specification, then you are done! Mostly, however, and especially for programs of any
size, disasters of various sorts will occur. How to fix these disasters is a job for
debugging. However, they would not have occurred if comprehensive testing had not
been carried out.
Program Verification
Verification means that the characteristics of modules or programs are thoroughly
checked according to their specifications. A program is defined to be correct, whenever it
complies fully to the specifications, which means that for all given inputs it reacts with
correct outputs. We distinguish partial and total correctness of a program, where the
former means that it terminates for a given input and delivers the correct results. A
program is totally correct, if it terminates and it is partially correct for all inputs.
Page no: 52
Program Validation
In contrast to verification, the process of validation is applied to check, if the system or
one particular module corresponds to the given requirements with correct results
according. To achieve this, the program is either executed or simulated. Two basic
approaches can be distinguished: the validation of the complete system (according to the
user's requirements) and the validation of the functional requirements. Testing may also
be described as the iterative application of validation.
Problems of Testing
A principle problem of testing is that in the general case and for a program of arbitrary
size and complexity, it can always only demonstrate the existence of errors, but it can
never prove the absence of errors. Furthermore, exhaustive testing is usually impossible
due to the amount of possible inputs a program states in most software systems. Yet,
since every test suite feeds a program under consideration only with selected inputs out of
the often-enormous space of all possibilities, certain bugs in the code may never be
evidenced. This means, that the total elimination of bugs is an unrealistic goal.
Usually, programs are not correct at the first place. In contrast, it is even highly probable,
that any developed program contains some errors. The reason for this is partially the
complexity of the program development process itself, partially the difficulty to define
solutions and realization as software, but also the high precision that is required from
software engineering in general.
Another main problem of testing is, that it is surprisingly often not considered until the
code has been run the first time and is found not to work. Statistics show that many errors
have already been made before coding begins, and the later the errors are detected, the
higher are the associated costs to rework the system in order to function correctly. Boehm
states that the most. In addition, the testing phase is still a highly tedious task, that is
mostly carried out manually, which is therefore error-prone in itself. A related question is
the amount of required testing, which is more often defined by the amount of available
budget or the given schedule.
And finally, it is very difficult to determine the sufficient amount of testing. It is clear,
that exhaustive testing is impossible in both principle and testing. In principle, there are
two possibilities to decide about test completion: statistical, when error statistics attest a
sufficient degree of reliability, and systematic, which tries to determine methods for
identifying the functional properties and classes of possible errors in programs. A very
common approach is to fix every detected bug and perform testing until the project
management orders a product release. Bach tries to articulate and perhaps quantify the
amount of testing [Bach 98], that is sufficient for different projects depending on the
circumstances and may be useful for everyday projects as well as mission- or life-critical
projects.
Page no: 53
7. PROGRAM DOCUMENTATION
Documentation, or the preparation of documents, that explains the program of the is an
essential but sometimes neglected part of the programming process. Because the
provision of the necessary documentation to support a program is not seen as a challenge
or intellectual exercise (and because it is almost invariably left until after the program has
been developed and is then seen as delaying the new program), it is seldom done or done
properly. It should be one of the fundamental principles of programmer management that
no program is allowed to be used without having been provided with sufficient
documentation.
Documentation should be an ongoing part of developing a program and should be
finalised, after the program has successfully tested and ready for implementation.
Documentation developed during the programming process should include a narrative
description of the program, program design documents, such as flowcharts or
pseudocode, program listings, and test results including input and output format. The
documentation of the program can be contained in documents referred as program
manuals. Comments in the program itself are also an important part of program
documentation.
Data entry and computer operations procedures should also be documented prior to
implementation. The programmer who developed a program may leave the company for
various reasons, and another programmer may be required to make a change to the
program. When new programmer would rely on the Documentation of the program in
order to make changes. Otherwise, the new program has to study and understand the
program before making any changes. This may take a long time to understand a program
written by another programmer.
This indicates that, Documentation is valuable because it helps the next programmer who
is later is asked to update the program. Program Documentation can substantially reduce
the amount of time the new programmer will have to spend learning about the program to
know how best to make a change.
Documentation of the program is also necessary for the users who will be using the
program. The user must understand, what input he is required to provide for the program,
the nature of the processing carried out by the program and the output, which he will
receive.
Documentation for Programmers
The documentation is required to enable the programmer to maintain a program over its
life span may be divided in Internal and External Documentation.
Page no: 54
Internal Documentation
This covers the aspects of programs which are embodied in the syntax of the
programming language, which includes
Meaningful names used to describe data items and procedures
Comments relating to the function of the program as a whole and of the modules
comprising the program.
Clarity of the style and format: i.e indentation of related block of instructions,
blank lines separating modules.
Use of symbolic Names (Variable Names) instead of constants.
External Documentation
This category covers the supporting documentation, which should be maintained in a
manual or folder accompanying any program. It is essential that as changes are made to a
program, its external documentation is updated at the same time. Out-of-date
documentation can be misleading to a maintenance programmer and result in time
wastage. External documentation should include:
Page no: 55
PROGRAM MAINTENANCE
Program maintenance includes all the changes to a program once it is implemented and
processing real transactions. Sometimes, maintenance is required to correct errors that
were not found during the testing stage. Other times, maintenance is required to make
changes that are the result of users new information requirements.
Page no: 56
6.
PROGRAM ERRORS
Error
Failure
Fault
Bug
etc
We will provide corresponding definitions in the following paragraphs, which have been
derived from existing literature.
We will stick to the common usage of the term "error", which covers all different kinds of
errors, bugs, failures, or faults. This view is sufficiently accurate and precise for our
needs.
A very informal definition of the most basic term "error" corresponding to computer
science is as follows:
An error is defined as the computation (calculation and outputting) of one or more
incorrect results by a computer.
This definition of an error is the most commonly used, and the term "error" has also been
used in the definition for debugging. The noted lack of precision is established by two
issues: On the one hand, there needs to be a distinction between the observed erroneous
behavior and the original error itself. On the other hand, the term "results" identifies not
only the output of a program, but also incorrect states during execution.
These problems are discussed in more detail by focusing on the states of
application programs, which consist of simple and compounded instructions.
In terms of errors, two kinds can generally be distinguished: hardware errors and software
errors. The former result from erroneous functions of electronic elements, which have
been initiated e.g. by dust, heat, variations in electrical currents, and others, or have been
introduced through corrupted connections and cables or by other faulty components. The
appearance of hardware errors leads to interruptions of service, which often result in
complete breakdowns or system shutdowns.
In the scope of this work, we will not consider hardware errors, but instead concentrate
on the second kind of errors, that manifest themselves in software.
Software errors (often called logical errors) are based on an incorrect sequence of
statements, which can further be attributed to errors in the implementation or in the basic
MT 512: Programming Design
Page no: 56
algorithm. These kinds of errors are related to program behavior, that is, unexpected,
unintended, or otherwise wrong due to some incorrect activity of a human.
A fault is rarely the work of a single operation. More often than not is it a logical
sequence that runs to dozens of lines of code and crosses modules. In this context, we
distinguishes between the following kinds of errors:
Errors of origin
Subsequent errors
An error of origin is one that is observed at the program state where it occurs initially.
Therefore, such an error manifests the first occurrence of an incorrect operation. This is
also the place, where the correction should be applied. However, since errors are seldom
detected immediately, users are usually confronted with subsequent errors first. Such
subsequent errors exist always only as a consequence of an error of origin. They reveal an
incorrect program state, which results from both, their operation and incorrect input
variables. This relation between several states of a program is also expressed in the term
fault, which can be defined as follows:
Definition
A fault is a logical sequence of statements (or rather state changes) or an
accidental condition that produces a result other than that which the programmer
intended or causes a program to fail to perform its required function. Therefore,
a fault gives rise to errors and inversely, an error is the result of a fault during
the creation of the program.
Probably the most common faults are typos in the source code text that have not been
detected by the compiler, or some other incorrect statements which do not comply with
the intended semantics of a program.
The worst kind of fault is a failure, which can be defined as follows:
Definition
A failure is the inability of a system (or one of its components) to perform a
given function within given limits.
Additionally, a failure is often defined as a loss of some service to the user. Therefore, it
represents one special kind of manifestation of erroneous program behavior [Choi 91],
because a program fails to produce expected results and may even terminate abnormally.
The missing term in this context is "bug", which is often used as an equivalent
replacement for error. However, in practice most people identify some additional
characteristics for a bug as specified in the following definition:
Page no: 57
Definition
A bug is the commonly used term for an error with originally unknown location
and reason. A bug can also be attributed to a poorly prepared and executed test,
as well as a bad program description that may lead users to mistake correct
behavior for bugs.
The notions and terms described above can also be described with a conceptual
overview. A special group is the false errors, which occur at state changes that are
incorrectly assumed to be wrong.
During debugging, we want to pinpoint the very origin of an error, i.e. the first
incorrect operation, which is often a difficult task. For that reason, we may identify
several more characteristics of bugs.
Additionally, there are those errors related to failures of the hardware on which the
program is executed, and to the corruption of the media on which the program is stored.
Software components differ fundamentally from hardware components, because they
don't suffer from aging or transient failures. Instead, when software components fail, the
reasons are:
Inaccuracies of the problem specification, which results in programs that behave
differently than intended by the specifier.
Errors introduced during software development, which results in programs that
behave differently than intended by the programmer.
Errors introduced during compilation, which results in programs that behave
differently than intended by the compiler.
Some more characteristics to establish a classification of errors with the following
three classes:
These different characteristics are very useful during debugging. Only if users are aware
about all the different possibilities, they are able to react to incorrect program behavior
and perform corresponding error detection activities. To underline the importance of
these tasks, the following section describes actual cases of erroneous behavior observed
in computer systems.
Page no: 58
Crash
A serious computer failure. A computer crash means that the computer itself stops
working or that a program aborts unexpectedly. A crash signifies either a hardware
malfunction or a very serious software bug.
If your computer crashes, it is not your fault. If the program is good and your hardware is
functioning properly, there is nothing you can do to make your system crash.
Hang
To crash in such a way that the computer does not respond to input from the keyboard or
mouse. If your computer is hung, you usually need to reboot it, although sometimes
hitting the correct sequence of control characters will free it up.
Computers systems may crash. Files may be accidentally deleted. Disks may
accidentally be reformatted. Computer viruses may corrupt files. Files may be
accidentally overwritten. Disgruntled employees may try to destroy your files. All of
these can lead to the loss of your critical data. You may think it's lost forever, but we
employ the latest tools and techniques to recover your data.
In many instances, the data cannot be found using the limited software tools available to
most users. The advanced tools that we utilize allow us to find your files and restore them
for your use. In those instances where the files have been irreparably damaged, our
computer forensics expertise allows us to recover even the smallest remaining fragments.
Overflow error
An error that occurs when the computer attempts to handle a number that is too large for
it. Every computer has a well-defined range of values that it can represent. If during
execution of a program it arrives at a number outside this range, it will experience an
overflow error. Overflow errors are sometimes referred to as overflow conditions.
Runtime
Occurring while a program is executing. For example, a runtime error is an error that
occurs during program execution and a runtime library is a library of routines that are
bound to the program during execution. In contrast, compile-time refers to events that
occur while a program is being compiled.
Bomb
To fail. The term bomb usually refers to a program hanging or ending prematurely. Note
that bombing is usually less serious than crashing, because bombing refers to a single
program, whereas crashing refers to the entire system. The two terms, however, are not
always used consistently.
Page no: 59
The Apple Macintosh computer actually has a bomb message that sometimes appears
just before the system crashes.
Abort
To stop a program or function before it has finished naturally. The term abort refers to
both requested and unexpected terminations. For example, many applications let you
abort a search or a print job. On the other hand, programs can abort unexpectedly for any
of the following reasons:
When a program aborts, you are usually returned to the operating system shell level.
Contrast abort with crash, which makes the entire system, including the operating system,
unusable.
Underflow
Refers to the condition that occurs when a computer attempts to represent a number that
is too small for it (that is, a number too close to zero). Programs respond to underflow
conditions in different ways. Some report an error, while others approximate as best they
can and continue processing. For example, if your computer support 8 decimal places of
precision and a calculation produces the number 0.000000005, an underflow condition
occurs.
Fatal error
An error that causes a program to abort. Sometimes a fatal error returns you to the
operating system. When a fatal error occurs, you may lose whatever data the program
was currently processing.
Page no: 60