Working Through the Penny Ante Equilibrium Lab
I spent more time than I care to admit debugging my first run of the Penny Ante Equilibrium model. The core idea is straightforward: you have agents with different utility functions and endowments, they trade in a simple exchange economy, and you watch the tâtonnement process converge to an equilibrium price vector. The lab manual walks you through it step by step, but there are places where things go sideways if you aren't paying attention. The most important thing to understand is how the demand functions are derived. Each agent maximizes Cobb-Douglas utility subject to their budget constraint. For an agent with utility U = x^alpha * y^(1-alpha) and endowment (omega_x, omega_y), the demand for x at prices (p_x, p_y) is alpha * (p_x * omega_x + p_y * omega_y) / p_x. That second expression -- the numerator -- is the agent's wealth, and it's easy to drop a parenthesis there during implementation. I've seen that error three times across different semesters. Once you have individual demands, you aggregate across agents and compute excess demand for each good. Equilibrium occurs when excess demand equals zero for all goods. By Walras' Law, you only need to clear one market; the other clears automatically. Most lab setups use good y as the numeraire and set p_y = 1, which simplifies the computation considerably.
The tâtonnement algorithm works by adjusting prices based on excess demand. If excess demand for x is positive, you raise p_x; if negative, you lower it. A common update rule is p_x_new = p_x_old * (1 + lambda * z_x), where z_x is the excess demand and lambda is a step size parameter. The tricky part is choosing lambda. Too large and the prices oscillate or diverge. Too small and convergence takes forever. I found that lambda between 0.05 and 0.2 works for most standard parameterizations, but you'll need to tune it for edge cases. Here's a specific scenario that caught me off guard. When agents have very asymmetric endowments -- say one agent holds almost all of good x and another holds almost all of good y -- the equilibrium price ratio becomes extremely high or low. My implementation was using a fixed lambda of 0.1 and it failed to converge, bouncing between values that swung wildly. The workaround was to normalize the initial price vector and scale lambda inversely with the magnitude of the price. So if the initial p_x was around 10, I'd drop lambda to 0.01. This adaptation brought convergence down from never finishing to roughly 50-80 iterations depending on tolerance. Another thing that trips people up: the lab often specifies agents with logarithmic utility, which is technically equivalent to Cobb-Douglas with equal exponents. The demand formulas are the same, but if you're coding this from scratch and you accidentally use a general power function without constraining the exponents to sum to one, your budget constraint won't bind correctly and your excess demands will be wrong. Double-check that alpha + beta = 1 for each agent.
When implementing the convergence check, don't just test whether excess demand is exactly zero. Floating point arithmetic makes that impossible. Use a tolerance like 1e-6 or 1e-8 depending on your precision needs. I initially used 1e-4 and got results that looked correct numerically but violated the budget constraint by a noticeable margin when I checked by hand. The lab answers typically involve running the simulation with a specific number of agents -- usually 2 to 4 -- and verifying that the equilibrium prices match the closed-form solution you can derive analytically. For two agents with Cobb-Douglas utilities, the equilibrium price ratio is p_x / p_y = (alpha_1 * omega_x1 + alpha_2 * omega_x2) / ((1 - alpha_1) * omega_y1 + (1 - alpha_2) * omega_y2). Running your code against this formula is the best sanity check you can do. If your code produces a price ratio that deviates from this analytical result, the issue is almost always in the demand calculation or in how you're updating prices. Trace through one iteration manually with pen and paper. It sounds tedious but it's faster than randomly changing parameters and rerunning.
Get the Full Details
One more subtlety: some versions of this lab ask you to explore how the number of agents affects convergence speed. More agents don't necessarily mean slower convergence. What matters more is the distribution of preferences and endowments. A four-agent economy with similar preferences converges faster than a two-agent economy with diametrically opposed ones. I ran a comparison once with 10 agents who all had identical alpha = 0.5 and symmetric endowments -- it converged in about 20 iterations. Same setup but with alpha ranging from 0.2 to 0.8 stretched it to over 200 iterations. The code itself should be structured so that you can easily swap out agent parameters without rewriting the core loop. I kept my agent data in a simple array of structs with fields for alpha, omega_x, and omega_y, then wrote a single function to compute aggregate excess demand given a price vector. That separation made debugging about three times faster than it would have been otherwise.
Common Mistakes to Avoid
Forgetting that prices must stay positive. If your update rule pushes p_x below zero, the next iteration divides by a negative price and everything collapses. Add a floor or use the multiplicative update rule, which naturally keeps prices positive. I prefer the multiplicative form precisely for this reason. Using absolute price levels instead of price ratios. The equilibrium in a pure exchange economy is determined only by relative prices. If you're checking convergence by looking at absolute price levels changing, you might think the system hasn't converged when it actually has. Track the price ratio p_x / p_y and watch when that stabilizes. Neglecting to verify that markets clear after convergence. Run the final price vector through the excess demand function one more time and confirm that the result is within tolerance. Some implementations report convergence based on price changes between iterations, but the prices could be stable at a non-equilibrium point if lambda was too small.
If you're stuck, the most reliable approach is to start with the simplest possible case -- two agents, two goods, alpha = 0.5 for both, equal endowments -- get that working and matching the analytical solution, then gradually add complexity. Every time you add an agent or change a parameter, re-run the baseline case first to make sure you haven't introduced a regression.
