This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints are perimeter 2L + 2W ≤ 40 (at most 40 inches), area LW ≥ 84 (at least 84 sq in), and L > 0, W > 0 (positive dimensions). Choice A correctly represents all constraints with the full perimeter formula and ≥ for area. A distractor like Choice C uses L + W ≤ 40, which is only half the perimeter—remember perimeter is 2(L + W), so include the 2! Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost $ \le 500$, 'need at least 10 units' becomes quantity $ \ge 10$. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! The constraints are cost $24x + 18y \le 180$ (no more than $180), serving $8x + 6y \ge 60$ (at least 60 people), and $x \ge 0$, $y \ge 0$ with integers (nonnegative whole trays). Choice A correctly represents all constraints with $ \le $ for cost and $ \ge $ for serving, including nonnegativity and integers. A distractor like Choice B flips cost to $ \ge 180$, which means spending at least $180, but the limit is at most—remember to match 'no more than' to $ \le $! Constraint identification from context: (1) list every limitation mentioned ('budget $X,$ 'time $ \le $ Y hours,' 'need $ \ge $ Z units'), (2) translate using key phrases: 'at most' $ \to \le $, 'at least' $ \to \ge $, 'exactly' $ \to =$, 'more than' $ \to >$, 'less than' $ \to <$, (3) don't forget implicit constraints like $x \ge 0$, $y \ge 0$ (can't be negative) or $x, y$ integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. Checking viability is systematic: (1) write out each constraint, (2) substitute the proposed solution into each one, (3) verify each is satisfied (inequality holds, equation balances), (4) check context reasonableness (non-negative? integers if needed?). If everything passes, it's viable. If anything fails, it's nonviable—and you should identify WHICH constraint was violated. Complete checking means checking ALL constraints, not just some! Checking each: $(2,4)$ $2(2)+4=8 \le 12$ (✓), $2+2(4)=10 \le 14$ (✓); $(4,2)$ $2(4)+2=10 \le 12$ (✓), $4+2(2)=8 \le 14$ (✓); $(5,4)$ $2(5)+4=14>12$ (✗); $(0,7)$ $0+7=7 \le 12$ (✓), $0+2(7)=14 \le 14$ (✓)—only $(5,4)$ fails. Choice C correctly identifies the nonviable point with complete checking showing it violates $2x + y \le 12$. Choice A gently, but $(2,4)$ satisfies both inequalities, so it's viable—check substitutions carefully. Constraint identification from context: (1) list every limitation mentioned ('budget $X,$ 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like $x \ge 0$, $y \ge 0$ (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions! The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. A constraint is a limitation or requirement: 'budget at most $500' becomes cost ≤ 500, 'need at least 10 units' becomes quantity ≥ 10. The system of ALL constraints defines the feasible region—the set of all solutions that work. A solution is viable if it lies in this feasible region (satisfies every single inequality/equation) AND makes real-world sense (no negative quantities, whole units when needed, etc.). Even one violation makes it nonviable! Let's translate each constraint: (1) Budget constraint: 8x + 20y ≤ 400 (at most $400), (2) Total items: x + y ≥ 30 (at least 30), (3) Minimum hoodies: y ≥ 10 (at least 10), (4) Non-negativity: x ≥ 0, y ≥ 0. Choice A correctly represents all constraints with the proper inequality directions matching the problem's language. Choice B incorrectly uses 8x + 20y ≥ 400, which would mean spending at least $400 rather than at most $400. Constraint identification from context: (1) list every limitation mentioned ('budget $X,' 'time ≤ Y hours,' 'need ≥ Z units'), (2) translate using key phrases: 'at most' → ≤, 'at least' → ≥, 'exactly' → =, 'more than' → >, 'less than' → <, (3) don't forget implicit constraints like x ≥ 0, y ≥ 0 (can't be negative) or x, y integers (if discrete), (4) write the complete system. Missing even one constraint can make you accept infeasible solutions!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. Checking viability is systematic: (1) write out each constraint, (2) substitute the proposed solution into each one, (3) verify each is satisfied (inequality holds, equation balances), (4) check context reasonableness (non-negative? integers if needed?). If everything passes, it's viable. If anything fails, it's nonviable—and you should identify WHICH constraint was violated. Complete checking means checking ALL constraints, not just some! Let's check each option: For A (26,12): x + 2y = 26 + 2(12) = 26 + 24 = 50 ≤ 50 ✓, x + y = 26 + 12 = 38 ≥ 30 ✓, y = 12 ≥ 12 ✓. For B (10,20): x + 2y = 10 + 2(20) = 10 + 40 = 50 ≤ 50 ✓, x + y = 10 + 20 = 30 ≥ 30 ✓, y = 20 ≥ 12 ✓. For C (6,12): x + 2y = 6 + 2(12) = 6 + 24 = 30 ≤ 50 ✓, x + y = 6 + 12 = 18 < 30 ✗ (violates minimum total). For D (24,13): x + 2y = 24 + 2(13) = 24 + 26 = 50 ≤ 50 ✓, x + y = 24 + 13 = 37 ≥ 30 ✓, y = 13 ≥ 12 ✓. Choice C correctly identifies (6,12) as nonviable because it violates the constraint x + y ≥ 30, with only 18 total items instead of the required 30. The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. Thorough constraint checking is what separates good modeling from sloppy work!

This question tests your ability to translate real-world limitations into mathematical constraints (equations and inequalities) and determine whether potential solutions are viable—meaning they satisfy all constraints and make sense in context. Checking viability is systematic: (1) write out each constraint, (2) substitute the proposed solution into each one, (3) verify each is satisfied (inequality holds, equation balances), (4) check context reasonableness (non-negative? integers if needed?). If everything passes, it's viable. If anything fails, it's nonviable—and you should identify WHICH constraint was violated. Complete checking means checking ALL constraints, not just some! Let's check (x,y) = (6,7) against each constraint: (1) Fruit cups: x + 2y = 6 + 2(7) = 6 + 14 = 20. We need 20 ≤ 18, but 20 > 18 ✗ (violates fruit constraint). (2) Protein scoops: y = 7 ≤ 7 ✓. (3) Total smoothies: x + y = 6 + 7 = 13 ≥ 10 ✓. (4) Non-negativity: 6 ≥ 0 ✓ and 7 ≥ 0 ✓. Choice B correctly identifies that the point violates x + 2y ≤ 18, as 20 > 18. Even though all other constraints are satisfied, this single violation makes the solution nonviable. The viability checklist: Make a table with one row per constraint. For each constraint, substitute your point and mark whether it's satisfied (✓) or violated (✗). If all checks pass AND context is reasonable, mark VIABLE. If even one ✗ appears OR context is violated (like negative values or fractional items), mark NONVIABLE and note which constraint failed. This organized approach prevents missing checks and makes your reasoning clear. Thorough constraint checking is what separates good modeling from sloppy work!

The correct answer is A. The total number of people must equal $$n$$, so $$a + b = n$$. The cost constraint allows spending up to $1200, so $$18a + 25b \leq 1200$$. Package A provides 2 appetizers per person and Package B provides 3, so total appetizers = $$2a + 3b \geq 150$$. Choice B incorrectly allows fewer than $$n$$ people total. Choice C uses strict inequalities when the constraints allow equality. Choice D incorrectly swaps the appetizer coefficients (should be 2 for A, 3 for B).

When translating percentage requirements into mathematical constraints, you need to identify what quantity represents the "whole" and what represents the "part." Here, the city requires at least 60% of all parking spaces to be regular spaces.

The correct constraint is $$r \geq 0.6(r + c)$$ because regular spaces ($$r$$) must be at least 60% of the total spaces ($$r + c$$). This directly translates the requirement: "regular spaces ≥ 60% of total spaces."

Let's examine why each wrong answer fails. Choice A states $$r + c \geq 0.6r$$, which says total spaces must exceed 60% of regular spaces. This reverses the relationship entirely—it's comparing total spaces to a fraction of regular spaces rather than requiring regular spaces to be a fraction of the total. Choice C gives $$r \geq 0.6c$$, meaning regular spaces must exceed 60% of compact spaces. This compares regular to compact spaces only, ignoring the total count that the regulation actually references. Choice D presents $$0.6r + c \leq r + c$$, which is always true (since $$0.6r < r$$) and relates to the width constraint rather than the percentage requirement.

When working with percentage constraints in optimization problems, always identify the base quantity (what the percentage is "of") and the quantity being constrained. Write it as: [constrained quantity] ≥ [percentage] × [base quantity]. This systematic approach prevents confusion between comparing parts to wholes versus parts to other parts.

When you encounter linear programming problems involving constraints, focus on translating the word problem into mathematical inequalities by identifying the key relationships between variables.

The market demand constraint states that the company must produce "at least twice as many smartphones as tablets." This means smartphone production ($$s$$) must be greater than or equal to two times tablet production ($$t$$). Mathematically, this translates directly to $$s \geq 2t$$.

Let's examine why the other options miss the mark:

Option A ($$s + t \geq 2t$$) simplifies to $$s \geq t$$, which only requires smartphones to equal or exceed tablets, not be twice as many. This misinterprets the constraint by including total production rather than comparing the individual quantities.

Option B ($$2s \geq t$$) reverses the relationship entirely. This would mean twice the smartphones must exceed tablets, but the problem states smartphones must be at least twice the tablets, not that double the smartphones exceeds tablets.

Option D ($$t \leq \frac{s}{2}$$) is mathematically equivalent to the correct answer when rearranged, but it's written from the tablet perspective rather than directly expressing the smartphone constraint as stated in the problem.

Study tip: When translating "at least twice as many of A as B," write it as $$A \geq 2B$$. Practice converting word constraints into inequalities by identifying which variable should be isolated and whether the relationship requires "at least" (≥), "at most" (≤), or exact equality (=).

The correct answer is A. The fire safety regulation limits attendance to no more than 480 people, so $$t \leq 480$$. The cost constraint requires total costs to be under $15000 (not equal to), so $$8000 + 15t < 15000$$. Choice B incorrectly uses the theater capacity (500) instead of the fire safety limit (480). Choice C incorrectly allows costs to equal $15000. Choice D incorrectly uses strict inequality for the attendance constraint when exactly 480 people should be allowed.