Exercise 3: Why the Heading Bug Is Conceptual, Not a Floating-Point Bug — Possible Solution
====================================================================

WHAT A FLOATING-POINT PRECISION BUG WOULD LOOK LIKE
------------------------------
Numerical Methods & Floating-Point Computation covered bugs where the
arithmetic itself introduces a small, unwanted error - values that
should be exactly equal but aren't, due to rounding (like 0.1+0.2 !=
0.3), or a computation whose relative error blows up because of
catastrophic cancellation or an ill-conditioned problem. In all of
those cases, the underlying MATH being performed was the right math
for the problem - the issue was that the computer's finite-precision
representation of real numbers introduced error while carrying that
correct math out.

WHY THIS CHAPTER'S BUG IS DIFFERENT
------------------------------
In this chapter's heading example, 10 - 350 was computed as exactly
-340, with zero rounding error anywhere in the calculation - a
calculator, an exact-fraction library, or infinite-precision
arithmetic would all produce precisely the same -340 result. The
problem isn't that the subtraction was computed imprecisely; it's
that plain subtraction is simply the WRONG operation to answer "how
far apart are these two compass headings," because compass headings
live on a circle that wraps around every 360 degrees, and ordinary
subtraction has no built-in awareness of that wraparound. This is a
mismatch between the mathematical model being used (linear
subtraction) and the actual structure of the problem (circular/
periodic), not an artifact of finite-precision computer arithmetic.

WHAT USING MORE PRECISION WOULD AND WOULDN'T FIX
------------------------------
Using a more precise numeric type (say, a higher-precision decimal
type, or arbitrary-precision arithmetic) would not change the result
of 10 - 350 at all - it would still compute exactly -340, since that
subtraction has no rounding error to begin with regardless of the
numeric type used. More precision only helps when the bug's cause is
representation/rounding error, which is not what's happening here.
What actually fixes this bug is using the mathematically correct
operation for circular quantities - the wrapped-difference formula or
the atan2-based trigonometric identity this chapter verified - which
has nothing to do with numeric precision and everything to do with
choosing an operation that respects the problem's own periodic
structure.

WHY THIS WORKS AS AN ANSWER
------------------------------
The explanation correctly separates "the arithmetic was performed
imprecisely" (a floating-point bug, per the prerequisite course) from
"the wrong operation was used for a periodic quantity" (this chapter's
own conceptual bug), and explicitly confirms that increasing numeric
precision would leave the -340 result completely unchanged, since
there was never any rounding error involved in producing it.