1/3 = .333…

1/3 + 1/3 + 1/3 = 3/3 = 1

.333… + 333… + 333… = .999…

.999… = 1

Discuss

  • Saik0@lemmy.saik0.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.