Panhellenic Economics & Informatics common mistakes
Panhellenic Economics & Informatics · Understand the traps and how to avoid them.
Computing a price elasticity of demand as a simple ratio of percentage changes without checking whether the question asks for point elasticity at a given point versus arc elasticity between two points, then reporting a number with the wrong sign convention or the wrong base for the percentage change.
Candidates memorize the formula (ΔQ/Q)/(ΔP/P) but not the choice of base. The midpoint (arc) formula and the point formula give different values, and the negative sign is often dropped or kept inconsistently. Under time pressure the candidate grabs whichever base was used in the last worked example and does not re-read whether the question specifies a price range or a single point.
What to do instead
Before computing, underline in the prompt whether two price-quantity pairs are given (use arc/midpoint: divide by the average of the two prices and quantities) or a demand function is given (use point elasticity: (dQ/dP)·(P/Q), differentiating the function). State the sign convention explicitly in the answer and, when the exam treats elasticity as an absolute value, say so. Practice by computing both versions for the same data and confirming they converge as the price interval shrinks.
Determining the profit-maximizing output by setting price equal to marginal cost under monopoly or monopolistic competition, or by setting marginal revenue equal to average total cost, instead of MR = MC followed by reading price off the demand curve.
The perfectly competitive rule P = MC is drilled first and becomes the default. Candidates also conflate the two-step monopoly procedure (find Q where MR = MC, then find P on demand at that Q) into a single equation. The result is an output level and price that are internally inconsistent with the demand curve, which the candidate does not notice because they never plug the quantity back into demand.
What to do instead
Always execute the three-step routine explicitly: (1) derive MR from the inverse demand function (same intercept, twice the slope for linear demand); (2) solve MR = MC for Q; (3) substitute Q into the demand function, not into MR, to get P. Then verify that P exceeds MC and that the markup is positive. If a table is given, build columns for TR, MR, TC, and MC and locate the crossing rather than eyeballing profits.
Treating a shift of the supply or demand curve and a movement along the curve as interchangeable, so that a price ceiling, a tax, or an input-cost change is analyzed by moving to a different point on the same curve rather than shifting the relevant curve.
The graphical distinction is taught early and feels trivial, but exam items embed it in multi-step scenarios (for example, a per-unit tax on sellers plus a binding price floor). Candidates draw the first curve they think of and then slide along it, producing the wrong new equilibrium and the wrong incidence or deadweight-loss conclusion.
What to do instead
Classify the shock before drawing: does it change the quantity demanded/supplied at every price (shift) or only the price faced (movement)? A per-unit tax on sellers shifts supply up by the tax; a subsidy shifts it down; a price ceiling creates a shortage measured along the existing curves. Redraw from scratch for each scenario, label the original and new equilibrium, and compute consumer/seller incidence as the difference between the new consumer price, the new seller price, and the original equilibrium price.
Computing real versus nominal GDP (or a GDP deflator, CPI inflation, or a growth rate) using the wrong base year, mixing a Laspeyres and Paasche weighting, or applying a simple percentage change where a chain or geometric average is required over multiple periods.
The arithmetic looks routine, so candidates rush it. The deflator uses current-year quantities while the CPI uses a fixed basket, and candidates swap them. For multi-period growth, they add annual rates instead of compounding, and for average growth they divide by the number of years instead of taking the geometric mean.
What to do instead
Write the definition next to the calculation: deflator = (nominal/real) × 100 with current-year quantities; CPI = cost of fixed basket at current prices / cost at base prices × 100. For growth over n periods use (end/start)^(1/n) − 1, and for total growth use the product of (1 + g) factors. Sanity-check by confirming the deflator equals 100 in the base year and that a computed real growth rate is plausible relative to nominal growth minus inflation.
Reading a regression output and interpreting a coefficient as a causal effect or as a correlation of the dependent variable with itself, misreading the standard error as a measure of fit, or failing to distinguish R-squared from adjusted R-squared when comparing models with different numbers of regressors.
Output tables present many numbers with similar names, and candidates under exam pressure map them onto the wrong concept. The classic errors are treating a large t-statistic as proof of causality, reading the p-value as the probability the null is true, and preferring the model with higher R-squared even after adding irrelevant variables.
What to do instead
Annotate each column before answering: coefficient = predicted change in Y per one-unit change in X holding others fixed; standard error = precision of that estimate; t = coefficient/SE; p-value = probability of a result at least this extreme if the null were true. Use adjusted R-squared or an information criterion when comparing models with different regressor counts, and state explicitly that observational coefficients are associations unless the design (instrument, experiment, difference-in-differences) supports a causal claim.
Stating a hypothesis-test conclusion as 'we accept the null hypothesis' or 'the result proves the null', and choosing a one-tailed versus two-tailed test based on the sign of the sample estimate rather than on the wording of the research question.
Everyday language treats 'not rejected' as 'true', and candidates mirror that. The tail choice is often made after seeing the data, which is a subtle specification error the candidate does not recognize as an error at all. This produces conclusions that overstate what the test establishes.
What to do instead
Use the fixed phrasing: reject H0 or fail to reject H0, never accept. Decide the tail before looking at the estimate: 'different from', 'changed', or 'is there an effect' implies two-tailed; 'greater than' or 'less than' in the research hypothesis implies one-tailed. Report the test statistic, the critical value or p-value, and the decision in that order, and add one sentence on what the decision does not establish.
Evaluating asymptotic complexity by counting loops rather than by counting how the work grows with input size, so that a nested loop over a constant-size alphabet is called O(n²), a halving loop is called O(n), or a recursive function's complexity is guessed without writing the recurrence.
Candidates pattern-match loop nesting to exponents. They also forget that sequential loops add rather than multiply, and they do not set up recurrences for divide-and-conquer code. Amortized structures (dynamic arrays, hash tables) and best/average/worst distinctions add to the confusion.
What to do instead
For every loop, ask what the bound variable depends on: a loop from 0 to 255 is O(1) regardless of n. Add complexities for sequential blocks and multiply for nested blocks whose bounds are independent. For recursion, write T(n) explicitly and solve it (master theorem or expansion), for example T(n) = 2T(n/2) + O(n) giving O(n log n). State which case (worst, average, amortized) you are reporting and justify it in one line.
Tracing a sorting or search algorithm on a small array and reporting the state after the wrong number of passes, or confusing stable and in-place properties, so that the final array is right but the intermediate trace, comparison count, or stability claim is wrong.
Candidates verify only the final sorted output and assume the intermediate steps follow. Insertion sort, selection sort, and bubble sort all reach the same final array but differ in swaps and intermediate states, and stability depends on the comparison and swap policy rather than the algorithm name alone.
What to do instead
Trace with a table: one row per pass, columns for the array state, the index being processed, and the comparison/swap count. Memorize the invariants: after pass k of selection sort the first k positions are final; after pass k of bubble sort the last k are final; insertion sort keeps a sorted prefix. For stability, check whether equal keys are ever swapped past each other, and for in-place, check whether auxiliary arrays proportional to n are allocated.
Writing SQL that silently changes the result set through NULL semantics, inner joins that drop unmatched rows, or aggregate queries with ungrouped columns, and then reporting a count or average that looks plausible but is wrong.
Candidates test queries mentally on small clean data where no NULLs or unmatched foreign keys exist. They use COUNT(column) where COUNT(*) was intended, put a filter on the right side of a LEFT JOIN in the WHERE clause (turning it into an inner join), and select non-aggregated columns not in GROUP BY.
What to do instead
Before running, list the NULL-bearing columns and decide the intended treatment (COUNT(*) versus COUNT(col), COALESCE, IS NULL versus = NULL). For outer joins, keep filters on the preserved table in WHERE and filters on the optional table in the ON clause, and verify by counting rows before and after the join. For aggregates, confirm every non-aggregated select column appears in GROUP BY, and validate results against a hand-computed count on a small subset.
Normalizing a relational schema to third normal form by mechanically splitting tables without checking that the decomposition is lossless and dependency-preserving, or answering a normalization question by naming the normal form without showing which functional dependency violates it.
Candidates memorize the definitions of 1NF, 2NF, and 3NF but not the decomposition tests. They split on every dependency they see, which can lose information on join, and they assert 'this is in 3NF' without identifying the offending dependency or candidate key, which is what the question actually asks for.
What to do instead
Always compute the candidate keys first from the given functional dependencies (closure of each attribute set). Then test each dependency: a violation of 2NF is a non-prime attribute depending on part of a key; a violation of 3NF is a transitive dependency from a non-prime attribute. When decomposing, verify losslessness by checking that the common attributes of the resulting relations form a superkey of at least one of them, and check dependency preservation by confirming each original dependency is implied by the dependencies of the new relations.