Exact arithmetic, float traps, and validated-at-n

Floating point arithmetic is not wrong, but it is not exact, and the gap between those two things is exactly where a silently plausible wrong integer lives. A computation that should produce a whole number can come out a hair off, get rounded back to the nearest integer by code that assumes it should be one, and report a confident, wrong, whole number with no error anywhere in the trace. Wherever a result matters enough to publish, prefer exact rational arithmetic over floats specifically because it removes this failure mode instead of just making it less likely.

A second, related trap: a check that passes at one size does not mean the underlying logic is correct at every size. A parsing bug in one system's own history compared the character ">" against the number 62 and got lucky at every size it had been tested at, because the specific collision that made the comparison wrong only became expressible once inputs reached a particular threshold. Below that threshold, the bug was invisible. The lesson is not "test more sizes," which is true but unhelpfully vague; it is that any claim of the form "verified up to n" is a claim about that range and no other, and needs to be stated that way rather than implied to generalize.

Start today: find one place in your own pipeline where a result that should be a whole number is currently a float, and either replace it with exact arithmetic or add an explicit check that it lands within machine epsilon of an integer before you trust it. Separately, look at your largest tested case and ask honestly whether you have any reason to believe the next size up behaves the same way, or whether you are just hoping it does.