Welcome back to Modeling and Solving Everyday Systems! You have reached the fourth lesson of five, and with break-even problems now behind us, we turn to a different flavor of everyday system.
Picture two receipts sitting on a table. Each lists the same two items in different amounts, and each shows a total at the bottom. Neither receipt alone can tell us what a single item costs, yet together they can — and that small piece of detective work is what today's models are built for. As in Lesson 2, we stop once the model is written; solving comes next time.
Two Purchases, One Pair of Unknowns
Comparison situations gave us two competing rules and asked when they agree. Combined-purchase situations are different: there is no competition at all. Both purchases follow the exact same price list, and what we do not know is the price list itself.
That is the key idea. If a bakery charges one fixed price per muffin and one fixed price per coffee, then every receipt from that bakery is built from those same two numbers. One receipt gives us one fact about them, which is never enough to pin down two unknowns.
A second receipt helps only if it describes a genuinely different mix. A receipt for 3 muffins and 2 coffees at $16.50 and another for 6 muffins and 4 coffees at $33.00 look like two facts, but the second is just the first one doubled — it rules out nothing new. Change the proportions, and the second purchase finally tells us something the first did not.
Reading One Purchase as an Equation
Let us slow down on a single receipt before handling two. Suppose someone buys 3 muffins and 2 coffees and pays $16.50. If m is the price of one muffin in dollars, then 3 muffins cost 3m dollars; if c is the price of one coffee in dollars, then 2 coffees cost 2c dollars. The total is the sum of the two:
3m+2c=16.50
This shape has a name we have met before: standard form, Ax+By=C. Receipts land in it almost effortlessly, because every piece of the sentence has its own slot to fall into.
Part of the situation
Where it goes
In our example
How many of each item
the coefficients A and B
3 and 2
The price of each item
the variables x and y
m and c
The amount paid
the constant C
16.50
Join the 1M+ learners on CodeSignal
Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal
Defining the Variables Explicitly
Building the System from Two Receipts
When the Unknowns Are Quantities Instead of Prices
Checking the Model Before Solving
Common Pitfalls
These are the slips that produce a system which looks perfectly fine but describes the wrong situation.
Swapping coefficients between items. The most common error of all. Reread the source sentence once after writing each equation.
Letting a variable mean a count in one equation and a price in the other. One variable, one meaning, for the whole problem.
Writing a per-item total instead of a per-purchase total. The constant on the right is what the whole receipt came to, not what a single item cost.
Forgetting an item that appears in only one purchase. If the second order adds a bagel the first did not include, that is a third unknown, and two equations will not be enough.
Starting to solve. Tempting, but today's goal is a faithful model. A correct answer to the wrong system is still wrong.
Conclusion and Next Steps
In this lesson we learned to hear two receipts as two equations. Each purchase becomes a single standard-form equation whose coefficients are the counts, whose variables are the shared unknown prices, and whose constant is the amount paid. We also met the mirror-image version, where the prices are known and the counts are unknown, and we built a short checklist — matching coefficients, consistent variable order, consistent units — for confirming a model before any algebra begins.
As you may recall from Lesson 2, a model is only trustworthy if the variables are defined with units before any equation is written. That habit matters even more here, because the words "muffin" and "coffee" can each refer to a count or to a price, and mixing those two meanings quietly ruins the model.
So we write the definitions as full sentences, naming both the quantity and its unit:
Let m = the price of one muffin, in dollars.
Let c = the price of one cup of coffee, in dollars.
A quick units check then confirms the equation makes sense. The coefficient 3 counts muffins and m is dollars per muffin, so 3m comes out in dollars; the same holds for 2c, and the right side is dollars too. When a term's units do not match the total, something has been paired incorrectly — and that is worth catching now rather than after ten lines of algebra.
Now the second receipt. Suppose a second visit to the same bakery buys 5 muffins and 4 coffees for $29.50. The prices have not changed, so we reuse the very same m and c and write one equation per purchase:
{3m+2c=16.505m+4c=29.50​
That is the entire model. The two equations differ only in their coefficients and totals, because the unknowns they describe are shared — the price list is common to both lines.
Notice also that neither variable is isolated, and both equations sit in standard form with the variables in matching order. By the three-step scan from Lesson 1, that structure points firmly toward elimination rather than substitution. We will not act on that today, but it explains why this lesson pairs so naturally with the one ahead of it.
Combined-purchase situations come in a second variety that catches people off guard: sometimes the prices are printed and the counts are unknown. A movie theater charges $12 per adult ticket and $8 per child ticket. One group buys 20 tickets in total and pays $196. How many of each kind did they buy?
Here the unknowns are counts, so the definitions flip: let a = the number of adult tickets bought, and let k = the number of child tickets bought. The two given facts describe two different things, which gives the system a slightly different look:
{a+k=2012a+8k=196​
The first equation counts tickets, so both coefficients are 1 and the total is a ticket count. The second counts dollars, so the coefficients are prices and the total is money. Both equations are still in standard form, and the units test still applies to each one separately: never add a ticket count to a dollar amount inside the same equation.
Since we stop before the algebra, our quality control has to happen on the model itself. Three quick passes catch nearly every translation error.
Match each coefficient to its variable. Read the sentence and the equation side by side. If the receipt says 5 muffins, then 5 must multiply m, not c.
Keep the variable order the same in both equations. Writing 3m+2c=16.50 and then 4c+5m=29.50 is not wrong, but lining the variables up in columns makes next lesson's work far easier.
Confirm the units of every equation. All terms within one equation must measure the same kind of thing, whether that is dollars, tickets, or pounds.
One last sanity check costs nothing: does the model actually use both purchases, and are the two mixes different? As we saw earlier, two receipts describing the same proportions carry one fact twice, and no amount of algebra can pull two prices out of one fact.
