How is a feasible region different from a boundary line of a constraint?

A boundary line represents points where one inequality is exactly equal, while the feasible region represents points satisfying all inequalities together. The line is a single geometric object, but the region is an intersection of many half-planes. This distinction matters because optimization later uses only points that satisfy the entire system.

What is the difference between $\le$ and $<$ when sketching constraints?

With $\le$, boundary points are included, so the line is drawn solid; with $<$, boundary points are excluded, so the line is dashed. The inequality symbol encodes set membership, not just notation style. Getting this wrong changes which points are considered valid.

How does shading the rejected side compare with shading the accepted side?

Shading the rejected side usually keeps the final feasible overlap visually clean as an unshaded region. Shading accepted sides can create heavy overlaps that are harder to interpret and easier to misread. Both are theoretically possible, but rejected-side shading is strategically clearer in multi-constraint graphs.

What error occurs if you forget to include $x \ge 0$ and $y \ge 0$?

You may include points in negative coordinate regions that violate the model assumptions. This can produce a larger but invalid feasible set and lead to incorrect conclusions. Non-negativity constraints are structural and must be graphed like any other inequality.

Why is delaying all shading until the end a common mistake?

When many lines are present, postponing shading makes it easy to forget which side each inequality kept. The result is often side reversals and inconsistent overlap. Incremental shading preserves local correctness and reduces memory load.

What can go wrong if you decide the correct half-plane from slope intuition alone?

Slope only tells line direction, not which side satisfies a specific inequality value condition. Without a test point, you can keep the wrong half-plane even if the line itself is accurate. Substitution of a simple point gives a definitive logical check.

What is the formal definition of the feasible region in two-variable linear programming?

It is the set of all ordered pairs $(x,y)$ that satisfy every constraint simultaneously. Geometrically, this is the intersection of all relevant half-planes, including axis restrictions. The region can be bounded or unbounded depending on the constraint system.

Why do we graph $ax + by = c$ before handling $ax + by \le c$ or $ax + by \ge c$?

The equation gives the exact boundary that separates satisfying and non-satisfying points. Once that line is drawn, the inequality only requires choosing one side. This separation of tasks improves accuracy and makes errors easier to diagnose.

How can rewriting to $y \le mx + c$ help when sketching constraints?

Slope-intercept form immediately reveals gradient and y-intercept, which speeds plotting and checking. It also makes visual comparisons between multiple boundaries easier. The algebraic rewrite is a convenience tool, not a new constraint.

Why does the intersection approach guarantee that points in the final region are valid?

Each constraint acts as a filter, so every additional inequality can only remove invalid points, not add new violations. A point that survives all filters satisfies the full system by definition. This is the geometric meaning of logical conjunction in linear inequalities.

Library Podcasts

Courses

Referral & Rewards

Revision Notes

International A-Level

Sketching the Feasible Region

Summary

Sketching the feasible region is the graphical process of converting linear inequalities into boundary lines and identifying the overlap that satisfies all constraints simultaneously. The core idea is logical intersection: each inequality keeps one half-plane, and the feasible region is where all retained half-planes overlap with non-negativity conditions. This matters because it transforms an abstract constraint system into a visible decision space that can be checked, interpreted, and used in later optimization steps.

1. Definition & Core Concepts

What the feasible region means

Feasible region is the set of all coordinate pairs that satisfy every constraint at the same time. Each linear inequality defines a half-plane, so the region is the intersection of multiple half-planes rather than a single line. In linear programming with two variables, this intersection is visualized directly on a Cartesian graph.

Constraint language and boundaries

A constraint like $ax + by \le c$ includes the boundary line $ax + by = c$ and one side of it, while $ax + by < c$ excludes the boundary itself. This is why boundary style carries meaning: solid lines for inclusive inequalities and dashed lines for strict inequalities. The non-negativity conditions $x \ge 0$ and $y \ge 0$ are also constraints and usually restrict the region to the first quadrant.

2. Underlying Principles

3. Methods & Techniques

4. Key Distinctions

5. Exam Strategy & Tips

6. Common Pitfalls & Misconceptions

7. Connections & Extensions

Sketching the Feasible Region

Q: What is the difference between $\le$ and $<$ when sketching constraints?

With $\le$, boundary points are included, so the line is drawn solid; with $<$, boundary points are excluded, so the line is dashed. The inequality symbol encodes set membership, not just notation style. Getting this wrong changes which points are considered valid.

Q: How does shading the rejected side compare with shading the accepted side?

Shading the rejected side usually keeps the final feasible overlap visually clean as an unshaded region. Shading accepted sides can create heavy overlaps that are harder to interpret and easier to misread. Both are theoretically possible, but rejected-side shading is strategically clearer in multi-constraint graphs.

Q: What error occurs if you forget to include $x \ge 0$ and $y \ge 0$?

You may include points in negative coordinate regions that violate the model assumptions. This can produce a larger but invalid feasible set and lead to incorrect conclusions. Non-negativity constraints are structural and must be graphed like any other inequality.

Q: Why is delaying all shading until the end a common mistake?

When many lines are present, postponing shading makes it easy to forget which side each inequality kept. The result is often side reversals and inconsistent overlap. Incremental shading preserves local correctness and reduces memory load.

Q: What can go wrong if you decide the correct half-plane from slope intuition alone?

Slope only tells line direction, not which side satisfies a specific inequality value condition. Without a test point, you can keep the wrong half-plane even if the line itself is accurate. Substitution of a simple point gives a definitive logical check.

Q: What is the formal definition of the feasible region in two-variable linear programming?

It is the set of all ordered pairs $(x,y)$ that satisfy every constraint simultaneously. Geometrically, this is the intersection of all relevant half-planes, including axis restrictions. The region can be bounded or unbounded depending on the constraint system.

Q: Why do we graph $ax + by = c$ before handling $ax + by \le c$ or $ax + by \ge c$?

The equation gives the exact boundary that separates satisfying and non-satisfying points. Once that line is drawn, the inequality only requires choosing one side. This separation of tasks improves accuracy and makes errors easier to diagnose.

Q: How can rewriting to $y \le mx + c$ help when sketching constraints?

Slope-intercept form immediately reveals gradient and y-intercept, which speeds plotting and checking. It also makes visual comparisons between multiple boundaries easier. The algebraic rewrite is a convenience tool, not a new constraint.

Q: Why does the intersection approach guarantee that points in the final region are valid?

Each constraint acts as a filter, so every additional inequality can only remove invalid points, not add new violations. A point that survives all filters satisfies the full system by definition. This is the geometric meaning of logical conjunction in linear inequalities.

Summary

1. Definition & Core Concepts

What the feasible region means

Feasible region is the set of all coordinate pairs that satisfy every constraint at the same time. Each linear inequality defines a half-plane, so the region is the intersection of multiple half-planes rather than a single line. In linear programming with two variables, this intersection is visualized directly on a Cartesian graph.

Constraint language and boundaries

A constraint like $ax + by \le c$ includes the boundary line $ax + by = c$ and one side of it, while $ax + by < c$ excludes the boundary itself. This is why boundary style carries meaning: solid lines for inclusive inequalities and dashed lines for strict inequalities. The non-negativity conditions $x \ge 0$ and $y \ge 0$ are also constraints and usually restrict the region to the first quadrant.

2. Underlying Principles

Why graphing inequalities works

A linear inequality partitions the plane into two regions because its corresponding equation forms a straight boundary. Any point on one side makes the left-hand side larger or smaller in a consistent way, so one side satisfies the inequality and the other does not. This geometric consistency is what makes point-testing reliable for selecting the correct half-plane.

Intersection principle

The feasible set is built by logical AND: a point is valid only if it passes every constraint check. Geometrically, that means repeatedly narrowing the allowed area until only the common overlap remains. If no overlap exists, the problem is infeasible, which is an important diagnostic conclusion.

3. Methods & Techniques

Step-by-step sketching workflow

Rewrite each inequality in a graph-friendly form such as $y \le mx + c$ when possible, then plot the boundary line using two reliable points (for example intercepts). After drawing each line, test a reference point like $(0,0)$ if it is not on the boundary, and keep the side that satisfies the inequality. Shading the rejected side often makes the final unshaded overlap easier to identify.

Accuracy checks and notation

Label each boundary with its equation so later interpretation is unambiguous, especially when several lines are close together. Verify intercepts and gradient signs before shading, because a sign error can flip the allowed side and invalidate the entire region. Mark the final overlap clearly (often with a label such as $R$ ) and ensure axis constraints are visibly enforced.

Visual map of constraints and overlap

The diagram below shows a generic coordinate setup with multiple linear boundaries and the shared feasible polygon. The key skill is not artistic drawing but correct side-selection for each inequality. Once side-selection is correct, the overlap appears naturally as the decision region.

{"alt":"Coordinate grid with several linear constraint lines, rejected-side indication, and the unshaded overlapping feasible region labeled R.","svg":"<svg viewBox="0 0 600 400" xmlns="http://www.w3.org/2000/svg\"><marker id="axis-arrow-marker-fr1" markerWidth="8" markerHeight="8" refX="6" refY="4" orient="auto"><path d="M0,0 L8,4 L0,8 Z" fill="#374151"/><linearGradient id="feasible-fill-gradient-fr1" x1="0" y1="0" x2="1" y2="1"><stop offset="0%" stop-color="#dbeafe"/><stop offset="100%" stop-color="#93c5fd"/><rect x="0" y="0" width="600" height="400" fill="#ffffff"/><g stroke="#e5e7eb" stroke-width="1" opacity="0.4"><line x1="50" y1="50" x2="50" y2="350"/><line x1="100" y1="50" x2="100" y2="350"/><line x1="150" y1="50" x2="150" y2="350"/><line x1="200" y1="50" x2="200" y2="350"/><line x1="250" y1="50" x2="250" y2="350"/><line x1="300" y1="50" x2="300" y2="350"/><line x1="350" y1="50" x2="350" y2="350"/><line x1="400" y1="50" x2="400" y2="350"/><line x1="450" y1="50" x2="450" y2="350"/><line x1="500" y1="50" x2="500" y2="350"/><line x1="550" y1="50" x2="550" y2="350"/><line x1="50" y1="50" x2="550" y2="50"/><line x1="50" y1="100" x2="550" y2="100"/><line x1="50" y1="150" x2="550" y2="150"/><line x1="50" y1="200" x2="550" y2="200"/><line x1="50" y1="250" x2="550" y2="250"/><line x1="50" y1="300" x2="550" y2="300"/><line x1="50" y1="350" x2="550" y2="350"/><line x1="50" y1="350" x2="555" y2="350" stroke="#374151" stroke-width="2" marker-end="url(#axis-arrow-marker-fr1)"/><line x1="50" y1="350" x2="50" y2="45" stroke="#374151" stroke-width="2" marker-end="url(#axis-arrow-marker-fr1)"/><path d="M50 300 L520 120" stroke="#ef4444" stroke-width="2.5" fill="none"/><path d="M80 350 L420 70" stroke="#ef4444" stroke-width="2.5" fill="none"/><path d="M50 180 L550 180" stroke="#ef4444" stroke-width="2.5" fill="none"/><polygon points="120,260 240,215 290,180 170,180" fill="url(#feasible-fill-gradient-fr1)" opacity="0.45" stroke="#3b82f6" stroke-width="2"/><path d="M110 275 Q95 285 80 280" stroke="#f59e0b" stroke-width="2" fill="none" marker-end="url(#axis-arrow-marker-fr1)"/><text x="72" y="372" fill="#374151" font-size="14">x<text x="34" y="62" fill="#374151" font-size="14">y<text x="410" y="110" fill="#374151" font-size="13">Constraint lines<text x="176" y="205" fill="#1d4ed8" font-size="13">Feasible region R<text x="62" y="292" fill="#f59e0b" font-size="12">Shade rejected side"}

4. Key Distinctions

Boundary and side-selection differences

Distinguishing boundary inclusion from side-selection prevents two common logic errors: drawing the wrong line type and keeping the wrong half-plane. Inclusion is decided by the symbol ( $\le, \ge$ versus $<, >$ ), while side-selection is decided by testing a point. Treat these as separate decisions so your graph remains mathematically consistent.

Comparison table for exam decisions

The table summarizes distinctions you should apply immediately while sketching. Each row corresponds to a decision point that affects correctness before any optimization begins.

Feature	Case A	Case B
Boundary style	$\le$ or $\ge$ : solid line	$<$ or $>$ : dashed line
Region identification	Shade rejected side	Keep unshaded overlap
Axis constraints	Include $x \ge 0, y \ge 0$ by default	Ignoring them can add invalid points
Testing method	Substitute a test point	Do not infer side from slope alone

5. Exam Strategy & Tips

High-yield workflow under time pressure

Plot one constraint and shade immediately before moving to the next, because delayed shading increases confusion when many lines overlap. Label each line as soon as it is drawn so you can audit your work quickly if a later step looks inconsistent. This incremental method reduces cognitive load and catches sign mistakes early.

Verification checklist

Confirm intercepts, confirm boundary style, confirm tested side, then confirm non-negativity; this sequence catches most mark-losing errors. A fast sanity test is to pick one visible point in your final region and verify it satisfies all inequalities algebraically. If even one constraint fails, your region marking is not yet correct.

6. Common Pitfalls & Misconceptions

Frequent mistakes

Students often think every boundary should be solid, but strict inequalities require dashed lines because boundary points are excluded. Another common error is shading the satisfying side instead of the rejected side, which can hide the actual overlap after multiple constraints. Consistency in your shading convention prevents this reversal.

Conceptual misconceptions

Some learners assume the largest-looking area is automatically feasible, but feasibility is logical validity, not visual size. Others forget that axis restrictions are constraints too, which can accidentally include negative values that are not allowed. Always interpret feasibility as a full system condition, not a partial one.