Exercise 3: The Real Bug From a Strict-Equality Button-Edge Check — Possible Solution ==================================================================== WHY STRICT SIGNS ARE THE WRONG CHOICE HERE ------------------------------ This chapter verified directly that a point sitting exactly on a polygon's boundary produces a cross-product value of exactly 0 for the edge it's touching - but that was in a hand-constructed example using clean integer coordinates. A real mouse click's screen coordinates, once converted through whatever coordinate transforms the UI system uses (potentially involving the same kind of floating-point arithmetic covered throughout Numerical Methods & Floating-Point Computation), are extremely unlikely to land on a value that computes to EXACTLY 0 even when the click is, for all practical purposes, precisely on the button's edge from the user's perspective. A strict test using > 0 or < 0 (rather than >= 0/<= 0, or better, a small tolerance band) would essentially never register a value as sitting exactly on the boundary - it would resolve to "inside" or "outside" based on which side of zero a tiny, invisible- to-the-user rounding error happened to land on. WHAT THE ACTUAL BUG WOULD LOOK LIKE ------------------------------ The user experience symptom would be a button that appears to have a slightly inconsistent, "flickery" or unpredictable edge - clicking what looks like precisely the same pixel position twice (or clicking along the visible border of the button) could sometimes register as a successful click and sometimes not, purely because of which side of zero the cross-product calculation's own floating-point rounding happened to fall on for that particular click's exact computed coordinates. From the user's perspective, this would look like the button is unreliable or "buggy" right at its edges, with no visible reason why - exactly the kind of maddening, hard-to-reproduce interaction bug that's difficult to track down without understanding the underlying floating-point cause. WHY A TOLERANCE BAND FIXES THIS PROPERLY ------------------------------ Using a small tolerance around the boundary (treating any cross-product value within some small epsilon of 0 as "on the edge," and deciding explicitly and consistently how edge clicks should be handled) removes the dependence on an exact zero that real-world floating-point coordinates are unlikely to ever produce reliably - matching Numerical Methods & Floating-Point Computation Chapter 1's own foundational warning against relying on exact equality for values arrived at through floating-point computation. WHY THIS WORKS AS AN ANSWER ------------------------------ The explanation connects the general boundary-tolerance principle this chapter raised to a concrete, realistic scenario (real mouse coordinates passing through floating-point transforms), describes a specific, plausible user-facing symptom (an inconsistent, flickery button edge) rather than a vague "it could go wrong," and explains why a tolerance band is the correct fix rather than merely restating that exact equality is risky.