Quadratic Upgrade 3 / Analysis & Critique

What Changed from Upgrade 2

Upgrade 3 inverts the constructor workflow. Previous upgrades all started with a, b, and c. Upgrade 3 introduces a constructor that starts with roots, then reconstructs the quadratic that must have produced them. That is a major conceptual shift: we are no longer just analyzing a parabola; we are designing one from its intercept data.

The headliner is the roots constructor, which required adding complex arithmetic to ComplexOrderedPair. Once you allow complex conjugate roots, the project can no longer treat complex numbers as display-only objects. They become computational objects.

Roots Constructor, Real Case (Vieta’s Formulas)

For a monic quadratic — that is, one with a = 1 — the real-roots case is wonderfully clean. If the roots are r1 and r2, then:

(x - r1)(x - r2) = x² - (r1 + r2)x + r1*r2

So:
b = -(r1 + r2)
c = r1 * r2

This is Vieta’s Formulas in action. The constructor is not “guessing” coefficients. It is using an exact algebraic identity. The implementation reflects that directly:

if(areRealZeros){
    a = 1;
    b = -1*(x1 + x2);
    c = x1 * x2;
}

Why monic? Because the simplest version of the inverse problem starts with a = 1. A non-monic version would be possible if the constructor also accepted a scale factor, but Upgrade 3 deliberately focuses on the cleanest teaching case first.

The defensive check is also mathematically correct: if the arguments are being treated as real roots, both y-values must be zero. A real root is an x-intercept. If a point claims to be a root but has y != 0, it is not a root at all.

Roots Constructor, Complex Case

Complex roots of a real quadratic must come in conjugate pairs. If one root is a + bi, the other must be a - bi. This is not a coding preference; it is a structural property of real-coefficient polynomials.

(a+bi) + (a-bi) = 2a          // purely real
(a+bi)(a-bi) = a² + b²   // purely real

So:
b = -2a
c = a² + b²

The code mirrors that structure by computing the sum and product through ComplexOrderedPair helpers:

ComplexOrderedPair z1 = (ComplexOrderedPair) r1;
ComplexOrderedPair z2 = (ComplexOrderedPair) r2;
ComplexOrderedPair sum = z1.add(z2);
b = -1*(sum.getX());
ComplexOrderedPair product = z1.multiply(z2);
c = product.getX();

Notice the defensive gate: the real parts must match, and the imaginary parts must be opposites. That is precisely the definition of conjugates.

Defensive Programming Gate

The new constructor follows a clean gate pattern:

1. Classify the inputs as either real-root candidates or complex-number candidates
2. Validate that those inputs satisfy the mathematical rules of that category
3. Either compute coefficients or print an error and terminate
4. Never attempt the math on invalid input

This is exactly the right shape for student-facing defensive programming. The constructor does not pretend there is a sensible default when the inputs are mathematically illegal. It stops the program because the object literally cannot be defined correctly.

The use of System.exit(0) instead of silently returning is important. It tells students that some errors are fatal. If the roots are invalid, there is no legitimate quadratic to create, so continuing would be dishonest.

The same philosophy already existed in setA(): if a is effectively zero, the object stops being quadratic. Upgrade 3 is consistent. Both places rely on the same EPSILON-based notion of “close enough to zero.”

ComplexOrderedPair Gets Arithmetic

The two new methods are mathematically standard and cleanly implemented:

(a+bi) + (c+di) = (a+c) + (b+d)i
(a+bi)(c+di) = ac + adi + bci + bdi²
              = (ac-bd) + (ad+bc)i

add() is component-wise. multiply() uses FOIL and substitutes i² = -1. That is exactly the right level of transparency for an APCS audience: enough detail to connect the code to the algebra, but not so much that the method disappears under commentary.

More importantly, these methods belong on ComplexOrderedPair, not on Quadratic. They are operations on complex numbers, not operations that merely happen to be used by quadratics. That is a Single Responsibility Principle win.

printOrderedPairsIn() T-Table Generator

The method signature is:

printOrderedPairsIn(double xmin,
                    double xmax,
                    double xinc,
                    boolean shouldFormatAsOrderedPair)

The boolean parameter controls format only, not the mathematics. That is a reasonable design choice for a teaching project because the two modes are tightly related: one is human-readable (P(x, y)), the other is spreadsheet-friendly (x,y).

for(double x = xmin; x <= xmax; x += xinc){
    OrderedPair op = new OrderedPair(x, f(x));
    if(shouldFormatAsOrderedPair) System.out.println(op);
    else System.out.println(op.getX() + "," + op.getY());
}

Verdict: An excellent practical addition. The boolean flag is a reasonable design choice for a teaching context. The floating-point loop counter is worth noting as a future improvement, not a deal-breaker.

isEffectivelyZero() Made Public

Upgrade 1 introduced EPSILON. Upgrade 2 used it inline. Upgrade 3 turns the pattern into a named utility method:

public boolean isEffectivelyZero(double value){
    return (Math.abs(value) < QuadraticDriver.EPSILON);
}

Why public rather than private? Because the roots constructor receives input from outside the class and must validate it. That makes the method part of the class’s externally useful logic, not just an internal implementation detail. It also leaves the door open for future subclasses or drivers to reuse the same comparison rule.

Verdict: The refactoring from inline Math.abs(x - 0.0) < EPSILON to isEffectivelyZero(x) is an improvement in readability. The method name expresses the intent; the inline expression expresses the mechanism. In a teaching context, the named method wins.

DWR: The Cast Operator Precedence Trap

This is the headliner DWR moment because it names one of the most common Java mistakes students make when subclass-only methods enter the picture.

// This does NOT compile:
ComplexOrderedPair product = (ComplexOrderedPair)r1.multiply((ComplexOrderedPair)r2);

Why? Because Java parses the expression as “call multiply() on r1, then cast the return value.” But r1 is declared as an OrderedPair, and OrderedPair has no multiply() method. The cast applies to the return value, not the receiver.

The fix is beautifully simple:

ComplexOrderedPair z1 = (ComplexOrderedPair) r1;
ComplexOrderedPair z2 = (ComplexOrderedPair) r2;
ComplexOrderedPair product = z1.multiply(z2);

Lesson: Whenever you need to call a subclass method on a variable declared as the parent type, store the downcast in a new variable first. Don’t try to cast-and-call in a single expression.

This is also the flip side of polymorphism. Overridden methods can be called through the parent type. But a method that exists only in the subclass is invisible through the parent reference until you downcast.

Upgrade 3 as a Teaching Milestone

Where Upgrade 4 Could Go

• Add final back to the three constants in QuadraticDriver
• Wrap the debug complex-roots println inside the breadcrumb check
• Support non-monic quadratics by accepting a scale factor a in the roots constructor
• Replace System.exit(0) with a custom InvalidRootsException
• Fix the floating-point loop counter in printOrderedPairsIn()
• Improve toString() so zero-coefficient terms are suppressed
• Add a compareTo() method so two quadratics can be ordered by vertex height