This technique can't be applied to equality, since equality "collapses" the entire decimal expansion down to a single bit: we can't make closer and closer appro

This technique can't be applied to equality, since equality "collapses" the entire decimal expansion down to a single bit: we can't make closer and closer approximations, since that first bit requires an infinite amount of work. In fact, talking about "Nth decimals" also requires an infinite amount of work. For example, what's the first digit of '0.99999... + 0.00000...'? Note that this is not the same as 'rounded to one significant digit'. Let's call the numbers x and y; there are a few possibilities: - If y = 0, then the sum is equal to x: - If x eventually has a non-9 digit, then the first digit is 0; e.g. if the third digit is a 3, then the result is 0.993... - If x repeats 9 forever, the first digit can be either 1 or 0, depending on taste - If y > 0, then the result depends on the relative magnitudes of y and (1 - x). The first digit could be 0 (if y < 1 - x), or 1 (if y > 1 - x). If these differences only occur after billions of decimal places, we must go that far through the calculation to determine whether the first digit is 0 or 1! Most computable real representations will actually calculate to within some epsilon, e.g. a power of 10 if we're rounding the final decimal when displaying the result. That ensures all of these problems disappear, but of course it introduces uncertainty. We can likewise ask whether two numbers are equal to some precision; but not necessarily in general. (There might be tricks/identities for the particular functions being used in this calculator; but the above applies to "computable reals" in the strictest sense; i.e. where each function is a Universal Turing Machine)