It actually happens with all odd numbers that don’t happen to divide 10 (which is where the base10 things comes up). But I think that it’s a matter of the origin of the 0.9999… I don’t think that 3/3 is ever actually 0.9999… but rather is just a “graphical glitch” of base 10 math. It doesn’t happen in base12 with 1/3, but 1/7 still does.
I do accept that we can just presume 0.999… can just be assumed 1 due to how common 3*(1/3) is. But I do think it throws a wrench in other parts of math if we assume it’s universally true. Just like in programming languages… primarily float math that these types of issues crop up a lot, we don’t just assume that the 3.999999… is accurate, but rather that it intended 4 from the get-go, primarily because of the limits of the space we put the number in. I have no reason to believe that this isn’t the case for our base10 numbering systems either.
Genuinely curious about this one, what function are you assuming when using the limit approach to evaluate? I presume it is f(x) = x, but then it would not have a discontinuity at 1. Or is the point that whether 0.999… = 1 or not depends on the implicit function in the context (in which case, limits wouldn’t disprove the argument but rather add nuance to it)?
I know the proof… The only thing I’ve never had anyone clean up appropriately is that limits disprove that this is the case.
https://math15fun.com/2017/02/25/finding-limits-graphically/
If a limit exists… (such as the case in this link), -1 is a hole… but not -0.999999…
It’s even more apparent in “weird” functions like the one outlined here… https://math.stackexchange.com/questions/3136135/limits-of-functions-with-holes-variables-vs-constants
for x=1 the output is 2… but for x=0.99999… it’s 1.
For what it’s worth, this same issue crops up with 1/7 as well.
0.142857…+0.142857…+0.142857…+0.142857…+0.142857…+0.142857…+0.142857… = 0.999999…
It actually happens with all odd numbers that don’t happen to divide 10 (which is where the base10 things comes up). But I think that it’s a matter of the origin of the 0.9999… I don’t think that 3/3 is ever actually 0.9999… but rather is just a “graphical glitch” of base 10 math. It doesn’t happen in base12 with 1/3, but 1/7 still does.
I do accept that we can just presume 0.999… can just be assumed 1 due to how common 3*(1/3) is. But I do think it throws a wrench in other parts of math if we assume it’s universally true. Just like in programming languages… primarily float math that these types of issues crop up a lot, we don’t just assume that the 3.999999… is accurate, but rather that it intended 4 from the get-go, primarily because of the limits of the space we put the number in. I have no reason to believe that this isn’t the case for our base10 numbering systems either.
Genuinely curious about this one, what function are you assuming when using the limit approach to evaluate? I presume it is f(x) = x, but then it would not have a discontinuity at 1. Or is the point that whether 0.999… = 1 or not depends on the implicit function in the context (in which case, limits wouldn’t disprove the argument but rather add nuance to it)?