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.
Limits don’t disprove this at all. In order to prove 0.999…=1 you need to first define what 0.999… even means. You typically define this as an infinite geometric series with terms 9/10, 9/100, 9/1000 and so on (so as the infinite sum 9/10+9/100+9/1000+…). By definition this is a limit of a sequence of partial sums, each partial sum is a finite geometric sum which you would typically rewrite in a convenient formula using properties of geometric sums and take the limit (see the link).
The thing is that it follows from our definitions that 0.999… IS 1 (try and take the limit I mentioned), they are the same numbers. Not just really close, they are the same number.
What you’re saying here isn’t actually true because -0.999… and -1 are the same number. -0.9, -0.99, -0.999 and so on are not holes, but -0.999… is a hole, because it is the number -1.
You see the distinction here? Notations -0.9, -0.99, -0.999 and so on are all defined in terms of finite sums. For example -0.999 is defined in terms of the decimal expansion -(9/10+9/100+9/1000). But -0.999… is defined in terms of an infinite series.
The same sort of reasoning applies to your other decimal examples.
You take limits of functions. The first limit is the limit of a function f that, according to the diagram of the problem, approaches 1 as x goes to 1. But the second limit is the limit of a constant function that always maps elements of its domain to the value 2 (which is f(1)). You can show using the epsilon delta definition of the limit that such a limit will be equal to 2.
The notation here might be a little misleading, but the intuition for it is not so bad. Imagine the graph of your constant function 2, it’s a horizontal line at y=2.
But I think that it’s a matter of the origin of the 0.9999…
This is correct. It follows directly from the definition of the notation 0.999… that 0.999…=1.
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.
Then you are wrong. 3/3 is 1, 0.999… is 1, these are all the same numbers. Just because the notation can be confusing doesn’t make it untrue. Once you learn the actual definitions for these notations and some basic facts about sums/series and limits you can prove for yourself that what I’m saying is the case.
I do accept that we can just presume 0.999… can just be assumed 1 due to how common 3*(1/3) is.
It’s not an assumption or presumption. It is typically proved in calculus or real analysis.
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.
It definitely doesn’t throw a wrench into things in other parts of math (at least not in the sense of there being weird murky contradictions hiding in math due to something like this). Ieee floats just aren’t comparable. With ieee floats you always have some finite collection of bits representing some number. The arrangement is similar to how we do scientific notation, but with a few weird quirks (like offsets in the exponent for example) that make it kinda different. But there’s only finitely many different numbers that these kinds of standards can represent due to there only being finitely many bit patterns for your finite number of bits. The base 10 representation of a number does not have the same restriction on the number of digits you can use to represent numbers. When you write 0.999…, there aren’t just a lot (but finitely many) 9’s after the decimal point, there are infinitely many 9’s after the decimal point.
In a programming context, once you start using floating point math you should avoid using direct equality at all and instead work within some particular error bound specified by what kind of accuracy your problem needs. You might be able to get away with equating 4.000001 and 4 in some contexts, but in other contexts the extra accuracy of 0.0000001 might be significant. Ignoring these kinds of distinctioms have historically been the cause of many weird and subtle bugs.
I have no reason to believe that this isn’t the case for our base10 numbering systems either.
The issue here is that you don’t understand functions, limits, base expansions of numbers or what the definition of notation like 0.999… actually is.
The thing is that it follows from our definitions that 0.999… IS 1 (try and take the limit I mentioned), they are the same numbers. Not just really close, they are the same number.
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.
The issue here is that you don’t understand functions, limits, base expansions of numbers or what the definition of notation like 0.999… actually is.
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.
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. But you’re cherry picking trying to make me look dumb when instead you’ve just added nothing to the conversation.
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:
In my original comment I actually told you how the proof for 0.999…=1 works.
I just outlined the proof for you again.
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.
I’m cherry picking, yet you cherry picked the sentence “I don’t really think I’m cherry picking” over the entirety of my previous comment to you?
Virtually my whole last paragraph was ignored in my original comment.
Did you not read the entire last paragraph of my first comment where I directly quoted and responded to the last paragraph of your original comment? Here, let me quote it for you. I see reading is not your strong suit.
Quote I took from your last paragraph:
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.
My response:
It definitely doesn’t throw a wrench into things in other parts of math (at least not in the sense of there being weird murky contradictions hiding in math due to something like this). Ieee floats just aren’t comparable. With ieee floats you always have some finite collection of bits representing some number. The arrangement is similar to how we do scientific notation, but with a few weird quirks (like offsets in the exponent for example) that make it kinda different. But there’s only finitely many different numbers that these kinds of standards can represent due to there only being finitely many bit patterns for your finite number of bits. The base 10 representation of a number does not have the same restriction on the number of digits you can use to represent numbers. When you write 0.999…, there aren’t just a lot (but finitely many) 9’s after the decimal point, there are infinitely many 9’s after the decimal point.
In a programming context, once you start using floating point math you should avoid using direct equality at all and instead work within some particular error bound specified by what kind of accuracy your problem needs. You might be able to get away with equating 4.000001 and 4 in some contexts, but in other contexts the extra accuracy of 0.0000001 might be significant. Ignoring these kinds of distinctioms have historically been the cause of many weird and subtle bugs.
Quote I took from your last paragraph:
I have no reason to believe that this isn’t the case for our base10 numbering systems either.
My response:
The issue here is that you don’t understand functions, limits, base expansions of numbers or what the definition of notation like 0.999… actually is.
But you keep doing you.
Lmao, be sure to work on that reading comprehension problem of yours.
What are you even expecting? How am I supposed to read your mind and respond to all the super important and deep points you think you’ve made by misunderstanding basic arithmetic and calculus? Maybe the responsibility is on you to raise those points if you want further response from me on them and not on me to somehow just magically know what you want?
I’m cherry picking, yet you cherry picked the sentence “I don’t really think I’m cherry picking” over the entirety of my previous comment to you?
Nope. Because I’m establishing that you’re picking and choosing my original argument to respond to. That makes ALL of your responses kind of pointless.
The issue here is that you don’t understand functions, limits, base expansions of numbers or what the definition of notation like 0.999… actually is.
Which is taken in bad faith. Not only do you resort to ad hominem (you have no idea what I know about functions and limits, yet you go out of your way to claim that I know nothing), but you fundamentally DO NOT UNDERSTAND what I’ve said. Instead you choose to be a prick about it and act like you have some understanding of Math that nobody else in the room does. You’re no Einstien guy. You can’t even understand the premise that put forth and address it. You stuck your fingers in your ears and scream “LALALALALALA” and DON’T ADDRESS WHAT I SAID.
try and take the limit I mentioned
No… I’ve presented the problematic limit… You IGNORED this and just assert your own thing. This is tantamount to “The sky is blue” when I show you a picture of sky that happens to be purple or red. Your limit (sky) isn’t the one I’m concerned about… that’s not the discussion.
So let’s break it down barney for you.
You claim 0.999… IS 1. Fine. My claim is that it “really” isn’t (In the most mildest/literal sense), but is likely sufficient enough that it doesn’t matter. I believe that it’s a fundamental “glitch” in the base10 numbering system. This problem DOESN’T exist in base12 or other systems that are divisible by whatever number we’re talking about. Then I proceed to back up this “idea” with a similar but easier to parse example of floating point numbers. Where you can commonly get 4.0…1 or 3.9…9 (And keep in mind that this is only finite because of the space limitation of the memory of the computer… This would otherwise be 3.999…) numbers and both can and usually do mean 4. The idea behind that being that The numbering system in simply unable to represent the intended value. Now… To address this point… Can you prove that this premise doesn’t exist for your claim? Because my response is simply that Base12 doesn’t have the issue with (1/3)*3 when parsed in non fractional notation. Now you TRIED to address this by saying that since we can assign places in decimal notation and can feasibly go as far out to the right as we want… that we CAN represent it accurately. My counter argument would be that we do not have sufficient mechanism to represent it as evidenced that changing out notation to another base doesn’t have this “flaw”. Now remember… I even from the get-go said "I do accept that we can just presume 0.999… can just be assumed 1 " as there is no REASONABLE case where 1.9999999999999999999… isn’t just 2. The real question becomes that if we assign 1.999… = 2 definitionally. Is there ANY mathematical case where this causes an issue? Since we can’t prove a negative… it’s a moot question. It works for everything… except becomes weirdly questionable in cases of limits where there is a hole in the function.
Further… Any definition of limits you use to evaluate for 0.999… = 1 I can also apply to the previous examples of functions where there are holes. That was the point of the “I know the proof… The only thing I’ve never had anyone clean up appropriately is that limits disprove that this is the case.” and funny enough… even you haven’t done it. You’ve not sufficiently explained it.
Instead of being a dick… Learn to actually talk to people. I have no interest in continuing discourse with you. You’ve shown to argue in bad faith from the get-go.
It’s funny, even in the wiki article you linked people admit that it’s not foolproof.
and Timothy Gowers argues in Mathematics: A Very Short Introduction that the resulting identity 0.999… = 1 is a convention as well:
However, it is by no means an arbitrary convention, because not adopting it forces one either to invent strange new objects or to abandon some of the familiar rules of arithmetic.[49]
So reason for acceptance is that some rules go silly? I can agree with that… But that doesn’t mean that it makes fully logical sense. The funny part is… this wiki page even covers why I believe what I do…
Revisiting subtraction (http://math.fau.edu/richman/docs/999.pdf is an actual source/copy of the original article… Yes I actually do understand math and yes I’ve read this a long time ago regardless of your attempts to denigrate me.) in the above link is where I sit logically on the matter. Note that term used here in the paper is skeptic, not because I don’t believe that it works… but that I don’t believe that it is a law of math that necessarily is provable in the universe as we know it. Any calculatable 0.999… value you place into the limits that I’ve exampled in my original post does NOT calculate to 1 unless you make the jump to using some other form of math to “prove” that 0.999… = 1. So you can tell me that 1/3 can be properly evaluated in decimal… I’m not the only one who thinks otherwise. But yeah… I’m just some fucking moron on the internet in your mind. So I’m sure you’ll tell me how I’m all wrong even though there is legitimate discourse on the matter still in the mathematics community and I’m not the newest person on the block to think the way I do.
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.
Limits don’t disprove this at all. In order to prove 0.999…=1 you need to first define what 0.999… even means. You typically define this as an infinite geometric series with terms 9/10, 9/100, 9/1000 and so on (so as the infinite sum 9/10+9/100+9/1000+…). By definition this is a limit of a sequence of partial sums, each partial sum is a finite geometric sum which you would typically rewrite in a convenient formula using properties of geometric sums and take the limit (see the link).
The thing is that it follows from our definitions that 0.999… IS 1 (try and take the limit I mentioned), they are the same numbers. Not just really close, they are the same number.
What you’re saying here isn’t actually true because -0.999… and -1 are the same number. -0.9, -0.99, -0.999 and so on are not holes, but -0.999… is a hole, because it is the number -1.
You see the distinction here? Notations -0.9, -0.99, -0.999 and so on are all defined in terms of finite sums. For example -0.999 is defined in terms of the decimal expansion -(9/10+9/100+9/1000). But -0.999… is defined in terms of an infinite series.
The same sort of reasoning applies to your other decimal examples.
You take limits of functions. The first limit is the limit of a function f that, according to the diagram of the problem, approaches 1 as x goes to 1. But the second limit is the limit of a constant function that always maps elements of its domain to the value 2 (which is f(1)). You can show using the epsilon delta definition of the limit that such a limit will be equal to 2.
The notation here might be a little misleading, but the intuition for it is not so bad. Imagine the graph of your constant function 2, it’s a horizontal line at y=2.
This is correct. It follows directly from the definition of the notation 0.999… that 0.999…=1.
Then you are wrong. 3/3 is 1, 0.999… is 1, these are all the same numbers. Just because the notation can be confusing doesn’t make it untrue. Once you learn the actual definitions for these notations and some basic facts about sums/series and limits you can prove for yourself that what I’m saying is the case.
It’s not an assumption or presumption. It is typically proved in calculus or real analysis.
It definitely doesn’t throw a wrench into things in other parts of math (at least not in the sense of there being weird murky contradictions hiding in math due to something like this). Ieee floats just aren’t comparable. With ieee floats you always have some finite collection of bits representing some number. The arrangement is similar to how we do scientific notation, but with a few weird quirks (like offsets in the exponent for example) that make it kinda different. But there’s only finitely many different numbers that these kinds of standards can represent due to there only being finitely many bit patterns for your finite number of bits. The base 10 representation of a number does not have the same restriction on the number of digits you can use to represent numbers. When you write 0.999…, there aren’t just a lot (but finitely many) 9’s after the decimal point, there are infinitely many 9’s after the decimal point.
In a programming context, once you start using floating point math you should avoid using direct equality at all and instead work within some particular error bound specified by what kind of accuracy your problem needs. You might be able to get away with equating 4.000001 and 4 in some contexts, but in other contexts the extra accuracy of 0.0000001 might be significant. Ignoring these kinds of distinctioms have historically been the cause of many weird and subtle bugs.
The issue here is that you don’t understand functions, limits, base expansions of numbers or what the definition of notation like 0.999… actually is.
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.
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.
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. But you’re cherry picking trying to make me look dumb when instead you’ve just added nothing to the conversation.
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.
Your whole statement here is not an issue because:
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).
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.
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.
You really are.
Virtually my whole last paragraph was ignored in my original comment. But you keep doing you.
I’m cherry picking, yet you cherry picked the sentence “I don’t really think I’m cherry picking” over the entirety of my previous comment to you?
Did you not read the entire last paragraph of my first comment where I directly quoted and responded to the last paragraph of your original comment? Here, let me quote it for you. I see reading is not your strong suit.
Quote I took from your last paragraph:
My response:
Quote I took from your last paragraph:
My response:
Lmao, be sure to work on that reading comprehension problem of yours.
What are you even expecting? How am I supposed to read your mind and respond to all the super important and deep points you think you’ve made by misunderstanding basic arithmetic and calculus? Maybe the responsibility is on you to raise those points if you want further response from me on them and not on me to somehow just magically know what you want?
Nope. Because I’m establishing that you’re picking and choosing my original argument to respond to. That makes ALL of your responses kind of pointless.
Which is taken in bad faith. Not only do you resort to ad hominem (you have no idea what I know about functions and limits, yet you go out of your way to claim that I know nothing), but you fundamentally DO NOT UNDERSTAND what I’ve said. Instead you choose to be a prick about it and act like you have some understanding of Math that nobody else in the room does. You’re no Einstien guy. You can’t even understand the premise that put forth and address it. You stuck your fingers in your ears and scream “LALALALALALA” and DON’T ADDRESS WHAT I SAID.
No… I’ve presented the problematic limit… You IGNORED this and just assert your own thing. This is tantamount to “The sky is blue” when I show you a picture of sky that happens to be purple or red. Your limit (sky) isn’t the one I’m concerned about… that’s not the discussion.
So let’s break it down barney for you.
You claim 0.999… IS 1. Fine. My claim is that it “really” isn’t (In the most mildest/literal sense), but is likely sufficient enough that it doesn’t matter. I believe that it’s a fundamental “glitch” in the base10 numbering system. This problem DOESN’T exist in base12 or other systems that are divisible by whatever number we’re talking about. Then I proceed to back up this “idea” with a similar but easier to parse example of floating point numbers. Where you can commonly get 4.0…1 or 3.9…9 (And keep in mind that this is only finite because of the space limitation of the memory of the computer… This would otherwise be 3.999…) numbers and both can and usually do mean 4. The idea behind that being that The numbering system in simply unable to represent the intended value. Now… To address this point… Can you prove that this premise doesn’t exist for your claim? Because my response is simply that Base12 doesn’t have the issue with (1/3)*3 when parsed in non fractional notation. Now you TRIED to address this by saying that since we can assign places in decimal notation and can feasibly go as far out to the right as we want… that we CAN represent it accurately. My counter argument would be that we do not have sufficient mechanism to represent it as evidenced that changing out notation to another base doesn’t have this “flaw”. Now remember… I even from the get-go said "I do accept that we can just presume 0.999… can just be assumed 1 " as there is no REASONABLE case where 1.9999999999999999999… isn’t just 2. The real question becomes that if we assign 1.999… = 2 definitionally. Is there ANY mathematical case where this causes an issue? Since we can’t prove a negative… it’s a moot question. It works for everything… except becomes weirdly questionable in cases of limits where there is a hole in the function.
Further… Any definition of limits you use to evaluate for 0.999… = 1 I can also apply to the previous examples of functions where there are holes. That was the point of the “I know the proof… The only thing I’ve never had anyone clean up appropriately is that limits disprove that this is the case.” and funny enough… even you haven’t done it. You’ve not sufficiently explained it.
Instead of being a dick… Learn to actually talk to people. I have no interest in continuing discourse with you. You’ve shown to argue in bad faith from the get-go.
It’s funny, even in the wiki article you linked people admit that it’s not foolproof.
So reason for acceptance is that some rules go silly? I can agree with that… But that doesn’t mean that it makes fully logical sense. The funny part is… this wiki page even covers why I believe what I do…
https://en.wikipedia.org/wiki/0.999…#In_alternative_number_systems
Revisiting subtraction (http://math.fau.edu/richman/docs/999.pdf is an actual source/copy of the original article… Yes I actually do understand math and yes I’ve read this a long time ago regardless of your attempts to denigrate me.) in the above link is where I sit logically on the matter. Note that term used here in the paper is skeptic, not because I don’t believe that it works… but that I don’t believe that it is a law of math that necessarily is provable in the universe as we know it. Any calculatable 0.999… value you place into the limits that I’ve exampled in my original post does NOT calculate to 1 unless you make the jump to using some other form of math to “prove” that 0.999… = 1. So you can tell me that 1/3 can be properly evaluated in decimal… I’m not the only one who thinks otherwise. But yeah… I’m just some fucking moron on the internet in your mind. So I’m sure you’ll tell me how I’m all wrong even though there is legitimate discourse on the matter still in the mathematics community and I’m not the newest person on the block to think the way I do.
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)?