Chapter 3 — Algorithms and Flowcharts

Definition and meaning: An algorithm is a precise, step-by-step method to solve a problem or perform a task. It describes each needed action, the order to do them in, and the expected output for given inputs. An algorithm can be written as a list of steps, expressed as pseudocode, or represented visually as a flowchart.

Why clarity matters: Each step in an algorithm must be clear and unambiguous. If a step can be interpreted in more than one way, different people or machines may produce different results. For example, the instruction "arrange the books" should be replaced by "arrange books in alphabetical order by title" to be definite.

Key properties: A good algorithm must be finite — it must finish after a limited number of steps. It must be effective — each step should be simple enough to be carried out exactly. It should specify inputs and outputs clearly. Correctness is essential: for every valid input the algorithm should produce the intended output. Finally, while not the main focus in Class 8, efficiency is desirable; it means using fewer steps or less time to reach the answer.

Examples to understand properties: A recipe to make toast is an algorithm: inputs (bread, toaster), steps (insert bread, press lever, wait), and output (toasted bread). A vague instruction like "keep stirring until ready" is not good unless "ready" is defined by time or a visible sign. Always check whether an algorithm finishes for all allowed inputs — if it depends on a condition that never becomes false, the algorithm will not be finite.

Testing and improvement: After writing an algorithm, test it by doing a dry run using sample inputs, including typical and boundary cases (such as zero or equal numbers). If the result is incorrect, trace where steps failed and revise. Practising this builds logical reasoning and prepares students for coding in later classes.

Understand the problem: Before you write any steps, read the problem carefully. Ask: what inputs are given? What result is expected? Write the problem in your own words to ensure you understand it correctly. Identify special cases that might need attention, such as equal values or zero.

Select inputs and outputs: Decide exactly which values the algorithm must read and which values it should produce. For example, to find the average of marks, inputs are the list of marks and number of students; the output is the calculated average.

Break the task into main steps: Think of how you would do the task yourself. Write the big steps in order. For instance: read values, process them (such as add or compare), and then display the result. Keep each step small and focused so it is easy to test.

Refine steps into detailed actions: Replace vague actions with specific instructions. Instead of "process the list", write "for each element in the list add element to total". If repetition is needed, indicate how many times it will repeat or state the condition that ends the repetition. If decisions are needed, state the condition clearly, e.g., "if score >= 35 then pass else fail".

Choose a representation: Write the algorithm as numbered steps, use pseudocode, or draw a flowchart. Choose the representation that makes the logic clearest for the problem and for your own style. Pseudocode is good for outlining logic; flowcharts help visualise the flow of control.

Dry run and test: Use sample inputs, including edge cases, and follow the steps by hand recording variable values. If the result differs from expectations, find the step where the logic broke and rewrite it. Repeat testing until the algorithm works for all tested inputs. Keep refining to improve clarity and, when appropriate, efficiency.

What is a flowchart: A flowchart is a visual diagram showing the steps and decisions of an algorithm. It uses standard shapes for specific kinds of actions and arrows to show the order of execution. Flowcharts make the flow of control and choices easy to follow at a glance.

Why use flowcharts: They help to plan and communicate solutions clearly. For learners, drawing a flowchart before coding makes it easier to find missing steps, spot logic errors, and discuss the approach with classmates or teachers. A flowchart also serves as a simple documentation of how a program or process works.

How to begin drawing: Start with the oval Start symbol, then draw shapes for inputs, processes and decisions in the order they occur. Connect shapes with arrows. Place a Stop symbol where the algorithm ends. Keep the diagram flowing from top to bottom or left to right so it is intuitive for a reader.

Use in planning and debugging: A well-made flowchart can be translated into code or pseudocode. While tracing by hand, the flowchart shows the path of execution clearly and helps to test different paths. For example, if a decision splits into two outcomes, follow each path with suitable test inputs to ensure both lead to correct results and eventually to Stop.

Limitations and good practice: Flowcharts are excellent for small to medium problems but can become large for complex systems. Use modular design by splitting a large problem into small sub-flowcharts. Keep labels short, use standard symbols, and redraw messy charts for clarity. With practice, converting algorithms into flowcharts and back becomes fast and reliable, preparing students for programming tasks later on.

Symbols you must know: Flowcharts depend on a small set of standard symbols that communicate different kinds of steps. The Start/Stop symbol is an oval and marks where the process begins or ends. The Input/Output symbol is a parallelogram and is used for reading input values or displaying results. The Process symbol is a rectangle and stands for operations such as calculations or assignments. The Decision symbol is a diamond and represents a test that yields two or more branches, commonly yes/no or true/false. The Connector is a small circle used to join parts of a chart or continue the flow on another page.

How to use the symbols: Place the right symbol for each action; do not use a rectangle for a decision or a diamond for input. Inside each shape use short, precise text: in a rectangle write statements like "sum = sum + i"; in a parallelogram write "Read n" or "Write result"; in a diamond write a condition such as "i <= n?". Label the arrows leaving a decision with outcomes such as "Yes" and "No" if the path is not obvious from context.

Combining symbols for structure: A loop is drawn by using a decision diamond to check the loop condition and an arrow that returns to an earlier process. For count-controlled loops, show initialization, decision check, process inside the loop, update step, and the arrow back to the check. Use connectors when the diagram becomes large to avoid crossing lines and to keep the flow tidy.

Practice drawing neatly: Teachers expect correct shapes, readable text, and clear arrows. Practice by drawing each symbol and writing examples inside them. Understanding and using these symbols correctly will make your flowcharts unambiguous and easier to convert into pseudocode or code later.

Follow standard rules: A flowchart must be clear, logical and complete. Use standard symbols and place Start at the top (or left) and Stop at the end. Each shape should contain a short phrase describing the action. Avoid long sentences; use concise statements such as "i = i + 1" or "Display total".

Flow direction and arrows: Make the flow easy to read: top-to-bottom or left-to-right. Arrows show the direction of control. Do not have multiple arrow heads or ambiguous connections. If arrows cross, rearrange shapes to avoid crossing or use connectors that make the connections clear.

Decisions and branches: Every decision diamond should have two exits for a simple yes/no question. Label the exits when necessary. Ensure both exits ultimately lead to a defined next step or to Stop; do not leave a branch without a clear outcome. For multiway decisions, chain diamonds or use clear labels for each path.

Loops and updates: For loops, show initialization before the loop, a decision to test whether to continue, the body of the loop, and an update step that modifies the loop counter or condition. If the update is missing, the loop may never end. For count-controlled loops, show the counter initialization, the check, the body, and the counter increment clearly.

Completeness and testing: Include Start and Stop and make sure every possible path reaches Stop. After drawing a flowchart, perform a dry run with sample inputs to check correctness. Finally, redraw messy charts for clarity. Neatness and correctness are graded more than artistic drawing; clarity of logic is the key goal.

Three essential constructs: Any algorithm is built from three basic control structures: sequence, selection and iteration. Sequence is simply doing steps one after another. Selection is choosing different paths depending on a condition. Iteration repeats a group of steps until a condition is satisfied or for a set number of times.

Sequence explained: Most simple tasks are a sequence. For example, to add two numbers you read the first number, read the second number, add them, and display the result. Each step follows the previous one with no branching or repetition.

Selection (decision) explained: Selection is used when a choice must be made. It uses a condition to decide which path to follow. A typical example is determining pass or fail from marks: if marks >= 35 then pass else fail. In a flowchart this appears as a diamond with two arrows. Selection can be nested so that one decision leads to another decision inside a branch.

Iteration (loop) explained: Iteration repeats actions. There are two common kinds: count-controlled loops (repeat a fixed number of times) and condition-controlled loops (repeat until a condition is met). A count-controlled example is: FOR i = 1 TO 5 DO print i. A condition-controlled example is: WHILE input <> 0 DO add input to total; read next input. Each loop must include an update step that moves the loop toward termination.

Combining constructs: Real problems mix these constructs. Example: compute the sum of even numbers in a list — sequence to read the list, iteration to inspect each number, and selection inside the loop to check if a number is even. Practise breaking problems into these constructs and drawing the corresponding flowchart or writing pseudocode; this skill is central to writing correct programs later.

What is pseudocode: Pseudocode is a simple, informal way to express an algorithm using human-readable statements. It looks like programming code but uses English words and avoids strict syntax rules. Pseudocode helps to plan logic before converting it to a flowchart or program.

Useful keywords and structure: Common words used in pseudocode include READ, WRITE, IF, THEN, ELSE, ENDIF, FOR, WHILE, REPEAT, UNTIL, SET, and RETURN. Use indentation to show which statements belong to a decision or loop. For example, under an IF write the statements that run when the condition is true indented to make the structure clear.

Writing good pseudocode: Be consistent with variable names and keep statements short and precise. Write assignments as "sum = sum + i" and input as "READ n". When using loops, clearly show initialization, condition and update steps, for example: FOR i = 1 TO n sum = sum + i ENDFOR. For decisions use clear conditions like "IF marks >= 35 THEN" and include an ELSE branch if needed.

Advantages in planning: Pseudocode is quick to write and easy to modify. It helps spot logic errors before drawing a flowchart or writing code. When converting to code later, you map pseudocode statements to actual language constructs. Pseudocode serves as a bridge between plain English explanations and formal programming syntax.

Practice tips: Write pseudocode for daily activities such as making tea or for small math problems. Compare your pseudocode with a flowchart for the same problem to ensure both represent the same logic. This practice improves clarity and prepares you for programming in higher classes.

Mapping ideas between forms: Each flowchart symbol has a corresponding pseudocode construct. Input/Output parallelogram maps to READ and WRITE statements. Process rectangles map to assignment or calculation lines like "sum = sum + i". Decision diamonds map to IF...THEN...ELSE, WHILE or REPEAT conditions depending on the logic. Connectors map to labels or continuation statements in longer pseudocode.

Converting a flowchart to pseudocode: Read the flowchart from Start to Stop. For each shape write the equivalent pseudocode statement. When you reach a decision diamond, write an IF or WHILE block and indent the statements for each branch. If the decision leads back to a previous step, you will usually use a WHILE or REPEAT loop in pseudocode. Ensure you include initialization steps shown before a loop and the update step inside the loop.

Converting pseudocode to a flowchart: Read each pseudocode statement in order and draw the matching shape. For READ/WRITE use parallelograms, for assignments use rectangles, and for IF or WHILE use diamonds. For FOR loops, show initialization, condition check, loop body, update, and back arrow to the condition. Label decision arrows with Yes/No or True/False if needed to make the flow explicit.

Checking the translation: After conversion, dry run the new representation with sample inputs to confirm the logic is preserved. Look for missing initialization, incorrect loop updates, or missing branches. Practice with examples of increasing complexity — single decision, nested decisions, loops with inner decisions — until conversions feel straightforward.

Why this skill matters: Translating between flowcharts and pseudocode trains clear thinking and prepares students to convert plans into real code. It helps spot mismatches early and document solutions clearly for others to understand and implement.

Problem statement and approach: We need an algorithm to find the largest among three numbers a, b and c. The efficient way uses only two comparisons. First compare a and b to find the larger of those two. Store that in a variable max. Then compare max with c. The larger of these two will be the largest of the three.

Why this works: By first reducing the problem from three numbers to two (by selecting the larger of a and b), we make the second comparison sufficient to find the overall maximum. This avoids unnecessary comparisons and is simple to test.

Pseudocode: READ a, b, c IF a >= b THEN max = a ELSE max = b ENDIF IF c >= max THEN max = c ENDIF WRITE max This pseudocode uses >= so equal values are handled correctly. The algorithm is finite and definite; it finishes after the two comparisons and one output.

Flowchart structure: Start -> Input a,b,c (parallelogram) -> Decision a >= b? (diamond) with Yes branch setting max = a (rectangle) and No branch setting max = b -> Next decision c >= max? with Yes branch setting max = c and No branch skipping -> Output max -> Stop. Label arrows clearly and ensure both decision exits eventually lead to the next step.

Testing with examples: Use several test values: (5,9,3) gives max = 9; (7,7,6) gives max = 7; (-2, -5, -1) gives max = -1. Trace each step by writing variable values at each stage to make sure the chart and pseudocode match. This example reinforces selection and shows how to write clear, testable algorithms.

Problem and two viewpoints: The task is to compute the sum of the first n natural numbers. There are two common ways to think about this: an iterative method that uses a loop and a direct mathematical formula. For Class 8 we focus on understanding iteration and show the formula for checking answers.

Iterative algorithm (loop): The loop-based method builds the total by adding numbers one by one. Steps: read n, initialize sum = 0 and i = 1. Then while i <= n add i to sum and increase i by 1. After the loop ends display sum. This is a count-controlled loop because it repeats exactly n times when n is a positive integer. The algorithm must initialize both sum and i before entering the loop and must update i inside the loop to ensure termination.

Pseudocode: READ n sum = 0 i = 1 WHILE i <= n DO sum = sum + i i = i + 1 ENDWHILE WRITE sum This pseudocode clearly shows initialization, the loop condition, the body where accumulation happens, and the update of i.

Flowchart structure: Start -> Read n -> sum=0, i=1 (process) -> Decision i <= n? -> If Yes do sum = sum + i (process), i = i + 1 (process), then arrow back to decision. If No, go to Write sum and Stop. When drawing, keep the decision diamond between initialization and the loop body and make sure the update step is inside the loop so that i moves towards termination.

Formula for checking: The well-known formula sum = n*(n+1)/2 gives the same result and is useful to verify loop results for sample n. For example with n = 5 the loop yields 15 and the formula gives 5*6/2 = 15. Use both methods in class to build confidence in correctness and to learn both procedural thinking and numerical shortcuts.

What is tracing (dry run): Tracing a flowchart means following each step manually, updating variable values as you move from start to stop. It is the simplest way to test whether the logic works for given inputs. Write down a table of variables and their values at each important step so you can see how the result was produced.

How to perform a dry run: 1) Choose sample inputs, including normal and boundary cases (zero, negative numbers, equal values). 2) Start at the Start symbol and note initial values. 3) Follow arrows, executing each process and recording changes. 4) When reaching a decision, choose the branch based on the current values and continue until Stop. 5) Compare the final output with the expected result to decide if the flowchart is correct.

Finding and fixing errors: If the result is wrong, look back through the trace table to find where an unexpected value first occurred. Common causes include incorrect initialization, missing updates inside loops, wrong comparison operators, or missing branches in decisions. Once the cause is found, edit the flowchart: change initialization, add an update statement, correct the condition, or add the missing branch, then re-run the trace on the corrected chart.

Examples of common trace findings: Off-by-one errors are often visible during tracing when a loop runs one time too many or too few. A missing increment statement will show a variable stuck at the same value through many steps. An unhandled case in a decision will appear as no defined output for some input values. Tracing helps you see such problems clearly and fix them systematically.

Teacher expectations: In exams, present a clear trace table with steps and variable values, explain which branch was taken at each decision, and justify fixes if you change the flowchart. Good tracing demonstrates understanding of the algorithm's behaviour and is a key skill for programming success.

Common mistakes students make: Many errors recur when beginners write algorithms or draw flowcharts. Vague instructions such as "do process" leave ambiguity. Missing Start or Stop symbols make a diagram incomplete. Forgetting to initialize variables before use leads to incorrect results. In loops, missing the update (for example forgetting i = i + 1) creates an infinite loop. Using wrong comparison operators (like < instead of <=) causes off-by-one mistakes. Decisions with only one branch drawn leave some inputs unhandled.

How to avoid these mistakes: Use specific, short statements inside symbols. Always include Start and Stop. Initialize all variables before using them. For loops, ensure initialization, condition and update are clearly shown. Label decision branches and make sure every path reaches Stop. Perform at least two dry runs with different inputs, including edge cases, to find hidden errors. Ask a classmate to review your flowchart; peer review often spots overlooked issues.

Advantages of flowcharts: Flowcharts make logic visible and easy to follow. They are excellent for planning because they reveal missing steps and branches before coding. Flowcharts are useful for communicating ideas to others who understand diagrams better than text. They also serve as simple documentation and help in debugging because the flow of control is explicit.

Limitations of flowcharts: For very large programs, flowcharts can become unwieldy and hard to maintain. They do not show low-level details such as data types, memory use, or performance aspects explicitly. For complex systems, modular designs or high-level diagrams are preferred and flowcharts are used only for parts of the system. Despite limitations, flowcharts are ideal for learning algorithmic thinking and for designing small to medium problems.

Practical advice: Use flowcharts for classroom problems and small projects. When a task grows large, split it into subproblems and draw a flowchart for each part. Keep diagrams neat and tested; clear, tested flowcharts are a strong foundation for later programming and for performing well in exams.