You cannot use the outcome of a proof you’re validating as the evidence of the validating proof.

You should read what I said more closely. If you read what I actually said (literally the very first paragraph), you’ll notice I told you what the proof of 0.999…=1 is.

Let me fill in some of the details I left out for you. By definition, 0.999… IS the sum as n goes from 1 to infinity of 9/10^n. By definition this is the limit as N goes to infinity of the sum from n=1 to N of 9/10^n. The sum from n=1 to N can be evaluated (by the link in my original post) to be (9/10)(1-(1/10)^(N-1))/(1-1/10). So, from calculus we take the limit of this formula as N goes to infinity, it is (9/10)/(1-1/10), arithmetic tells us this value is 1. So, the limit of the sequence of partial sums we mentioned earlier is just 1, by definition this tells us 0.999…=1

What I’ve just outlined to you is the “infinite series and sequences argument” shown here, it is equivalent to the “rigorous proof” argument they also give.

You cannot use the outcome of a proof you’re validating as the evidence of the validating proof. Prove that the limits work without a presumption that 0.999… = 1. Evaluate a limit where there’s a hole in the function for 1… then prove that 0.999… also meets that hole without the initial claim that 0.999… = 1 since that’s the claim we’re testing.

Your whole statement here is not an issue because:

1. In my original comment I actually told you how the proof for 0.999…=1 works.
2. I just outlined the proof for you again.
3. I also sent you a link just now containing more explanations and proofs of this fact.

So you you tell me I don’t understand things… when you’ve not provided proof of anything other than just espousing that 0.999… = 1.

Again, the issue is you failing to see that I already told you the proof of this fact in my original post (and in the current post).

And I know how to work with floats in a programming context. It’s the programming context that tells me that there could be a case where the BASE10 notation we use simply does “fit” the proper evaluation of what 1/3 is. Since you know… Base12 does. These are things I’ve actually already discussed… and have covered.

I’m not sure if you meant to say the base 10 expansion of 1/3 does or doesn’t “fit” the “proper evaluation” of 1/3, but it does. Hint: try to apply my previous proof method to the series 3/10+3/100+3/1000+… to show this series evaluates to 1/3.

The issue that you’re getting so mystified by here is really to do with divisibility. Ieee floats are irrelevant and arguably don’t even really describe the entire set of real numbers very well to begin with.

It turns out that any rational number (i.e. a ratio of two integers) has a repeating decimal expansion no matter what base you pick (in some cases this expansion is not unique though fwiw). See here for an explanation of this. You might want to also read about Euclid’s division lemma as well.

It’s just that the way the denominator of your rational number divides the base you choose determines the sort of pattern you see when computing the base expansion (specifically whether or not the denominator divides the base tells you when the base expansion can terminate or not).

For example say we want to know the base 10 expansion of 1/2. To compute the first digit you can notice that since the base 10 expansion of 1/2 is given by 1/2=b_1/10+b_2/100+b_3/1000+… for each b_i being some integer between 0 and 9 (inclusive), that the integer part of 10(1/2), gives our first digit b_1, notice 10(1/2) is 5, so our first digit is 5. To compute our next digit consider 1/2-b_1/10=b_2/100+b_3/1000+…, this tells us the second digit of our base 10 expansion is the integer part of 100(1/2-b_1/10), but this value is just zero. If we keep repeating this process we keep getting zeroes. Notice we have a sequence of statements of the form 10(1/2), 100(1/2-b_1/10), 1000(1/2-b_1/10-b_2/100), … that we’re using to successively calculate out the actual values b_1, b_2, … and so on. Since 2 divided 10 we got b_1 to be equal to 5, which caused 100(1/2-b_1/10) to be equal to 0, so b_2 was zero, so 1000(1/2-b_1/10-b_2/100) ended up being equal to 1000(1/2-b_1/10), which is zero, so b_3 is zero and so on. The fact that 2 divides 10 causes a cascading sequence of zeroes after b_1=5 when we start actually trying to compute the digits of 1/2 in base 10.

We can try the same trick for 1/2 in base 3 now. We know our base 3 expansion of 1/2 has the form 1/2=a_1/3+a_2/9+a_3/27+… (these denominators are increasing powers of 3) where our a_i’s are integers between 0 and 2 (inclusive). So, the integer part of 3(1/2) gives us our first digit a_1, but 2 doesn’t divide 3 cleanly, so we have to use Euclid’s lemma (i.e. division) to find the integer part of a_1, notice 3=2(1)+1, so 3/2=1+1/3, so our first digit is 1. Cool, so now we need to find our next digit, similar to before we see it is the integer part of 9(1/2-a_1/3)=9(1/2-1/3)=9/6=3/2, but this is just the same problem as before, so a_2=1 as well (which is what we expect). Continuing this process leads us to a sequence of 1’s for each digit in the base 3 expansion of 1/2.

The fact that the decimal expansion for 1/2 terminates but the base 3 expansion doesn’t is due to 2 cleanly dividing 10 but not 3 in the above process. Notice also, that the general method I’ve outlined above (though not the most efficient) can be applied to any rational number and with any base that is a positive integer.

But you’re cherry picking trying to make me look dumb when instead you’ve just added nothing to the conversation.

I don’t really think I’m “cherry picking” or “adding nothing to the conversation”. You’re speaking from ignorance and I’m pointing out the points where you’re reasoning is going astray and how to resolve those issues. Rather than feeling dumb because you don’t know what you’re talking about, you should read what I said to try and see why it resolves the issues you’re struggling with.