ENGGEN 131 Chap.2 Conditionals, Problem Solving and Debugging
Conditionals, Problem Solving and Debugging
This chapter translates engineering requirements into Boolean expressions and mutually exclusive branches. It emphasises inclusive and exclusive endpoints, scalar versus array logic, branch ordering and the first-mismatch method of debugging. Boundary tables and adversarial tests reveal errors that ordinary interior values miss, while error classes guide the first useful diagnostic action.
What this chapter covers
- 01
Relational operators and Boolean results
- 02
AND, OR and explicit grouping
- 03
If, elseif and else branch order
- 04
Boundary tables for included endpoints
- 05
Syntax, run-time and logic error evidence
Worked example · free
Trace a three-band shipping rule
- 149 is below 50, so the charge is 8.
- 250 and 99 lie in the middle interval, so each charge is 4.
- 1100 enters the final branch and costs 0.
Key terms
- Boolean expression
- An expression that evaluates to true or false.
- Boundary case
- An input at or immediately beside a decision threshold.
- First mismatch
- The earliest program state that differs from a hand-worked prediction.
Conditionals, Problem Solving and Debugging FAQ
Why can separate if statements be wrong?
Each independent condition is evaluated, so more than one body can execute. Use an exclusive chain when exactly one category should apply. Rehearse this distinction with a fresh interval and branch trace before relying on program output.
Where should I place a breakpoint?
Place it just before the earliest suspect decision, inspect the operands, predict the condition result and then step once. Test the claim on a boundary case where the interval and branch assumptions become visible.
What makes a strong debugging test?
A strong test attacks a likely assumption, such as an included endpoint, zero iterations, one iteration or the shortest valid input. Write the expected interval and branch state first, then compare it carefully with execution.
Exam move
Start with the requirement in ordinary language and rewrite it as non-overlapping intervals. Circle every included endpoint and mark every excluded endpoint. For each interval, choose one representative interior value and values exactly on its boundaries. Only then translate the rules into comparisons. This prevents MATLAB syntax from silently changing the specification.
When the input is an array, state whether the desired result is one Boolean for the whole array, an elementwise logical mask, or a decision based on any or all entries. Build a branch table with columns for input, each condition result, branch selected and expected output. Evaluate an if/elseif/else chain from top to bottom and stop at the first true condition.
Evaluate independent if statements independently because more than one body may execute. Use this table to identify overlap, gaps and shadowed branches. A good minimal suite places tests just below, exactly at and just above each threshold. Several ordinary values from one region give less information than one carefully selected endpoint. Debug from the earliest observable mismatch.
Reproduce the failure with the smallest input that still triggers it, set a breakpoint immediately before the suspect decision and predict the operands and Boolean result. Step once and compare prediction with observation. If they differ, inspect precedence, operators, data type and shape at that expression. If they agree, continue to the next state change.
Change one cause at a time, rerun the failing case and then rerun the complete boundary table to detect a regression in an adjacent branch. Classify failures before choosing a response. A syntax failure means MATLAB cannot parse the statement, so inspect brackets, quotes and statement structure near the reported location. A run-time failure occurs on particular data, so examine current indices, dimensions and values.
A logic failure completes but violates the expected result, so compare with an independently worked oracle. Do not treat successful execution or plausible output as proof of correctness. State the failure class, first incorrect state and evidence supporting the proposed repair. Practise compound conditions by expanding them into truth tables.
For AND, identify a case where each operand is false separately and a case where both are true. For OR, include the all-false case and cases where either operand alone is true. Note short-circuit behaviour for scalar logical decisions and elementwise behaviour for masks. Parenthesise comparisons when grouping could be misread.
Avoid mathematical chained inequalities; write the two comparisons explicitly and connect them with the operator required by the input shape. End each session by designing, not coding, a small decision problem. Specify the inputs, outputs, partitions, invalid-input policy and test oracle. Exchange the branch order mentally to see whether a broad condition would capture a more specific case.
Then implement and verify against the prewritten table. Keep an error log that records the assumption behind every defect, such as strict instead of inclusive comparison or independent if instead of mutually exclusive branching. Revision is complete when you can justify that every permitted input reaches exactly one intended outcome and every boundary has direct test evidence.
For a final mixed exercise, define a three-region rule with two inclusive thresholds and one invalid-input policy. Draw its intervals, write a branch table and choose tests at both exact thresholds and immediately on either side. Add one array input and state whether the required outcome is a mask, any-match decision or all-match decision.
After implementation, introduce a deliberate reversed inequality and use a breakpoint to find the earliest mismatch. Classify the resulting defect, repair only that cause and rerun the whole table. The completed record should show specification, predicted Boolean values, observed branch, correction and regression result.
This synthesis prevents debugging from becoming trial and error and demonstrates that boundaries, branch order, scalar versus elementwise logic and evidence-based repair can all be justified from one compact case.