Mathematical ambiguity when accepting 0.99...=1
Post Voting Period
The voting period for this debate has ended.
after 0 votes the winner is...
It's a Tie!
Voting Style:  Open  Point System:  7 Point  
Started:  8/31/2015  Category:  Education  
Updated:  1 year ago  Status:  Post Voting Period  
Viewed:  593 times  Debate No:  79210 
Debate Rounds (5)
Comments (5)
Votes (0)
This is my very first debate here, and in it I will attempt to show that, while for practicality 1 = 0.99..., theoretically this does not always quite yield true. I shall present an argument in favor of this, and will be open to criticism.
The Argument: 1 = 0.99... Where f(1) is well defined: f(1)=f(0.99...) must hold. Let f(x) be the digital root of x. f(0)=0 f(0.9)=f(0+9)=f(9)=9 f(123.64)=f(1+2+3+4+6)=f(16)=f(7)=7 f(99)=f(9+9)=f(18)=f(1+8)=f(9)=9 (This is how a digital root is found, and yes, f(x) is algebraically well defined for rational digitfinite real numbers. It is quite a large equation, but I can write it down on request) Now 0.99... has a countably infinite set of 9s trailing. But all the 9s are countable and distinguishable from each other, such that when counting the 9s, you always end up with a whole number of 9s counted. ( 0.99 has 2 9s. 0.999 has 3 9s.) No matter for how long you count the trailing 9s you will never end up with a decimal number of 9s, as you cannot have a fraction of a digit. That is, counting digits will always result in a whole number. Consider: f(1) = f(0.99...) 1 = f(0+9+9+9+9+9+9+9+9+9....) 1 = f(9*n) Where n holds the property of being a whole number, an addition of 1s together, forever. Hence 1=9. Which is, a contradiction. A contradiction which arises from saying 1 = 0.99.. I entertain the thought that there is something fundamentally wrong when proving 0.99...=1, but admittedly I have no idea what. I greatly appreciate any criticism of my argument, and should an opponent accept the debate, I would be delighted. Welcome! I accept your challenge! Though I guess I shouldn't be the one welcoming you, since this is my first debate here too. Anyway, onto the counterargument: First, for brevity, I will refer to digital sums as dsums. I looked up the proof about digital roots of multiples of nine[1], and it's a bit more complicated. I'll show that one here and give some reasoning for why it doesn't work for 0.999... The proof first uses the fact that any number may be represented as a sum of multiples of increasing powers of ten, and then subtracts one out of each of those powers of ten. 9N is there because we are only considering multiples of 9: 9N = a + 10b + 100c + ... 9N = a + (b + 9b) + (c + 99c) + ... 9N = (a + b + c + ...) + (9b + 99c + ...) 9N = (a + b + c + ...) + 9*(b + 11c + ...) 9N = (a + b + c + ...) + 9*(something) 9N = dsum(9N) + 9*(something) Reordering this equation, we get: dsum(9N) = 9N  9*(something) dsum(9N) = 9*(something else) Since (a + b + c + ...) < (a + 10b + 100c + ...), the dsum will be smaller than 9n. Since dsums give single digits, and the only single digit multiple of 9 is nine, this means the dsum(9N)=9. However, this only works for finite numbers. It does not work for infinitely long numbers such as 0.999... For example, take (a + b + c + ...) + 9*(b + 11c + ...). If your number was infinitely long and you used increasing powers instead of decreasing ones (because if you used decreasing ones you'd get a summation if the form x/(y^n) which in this case converges to one), then you'd be multiplying by infinity. Since infinity is infinitely long, no dividing or separating into separate chunks to add together later will lead to anything less than infinity, so dsum(infinity) is undefined. This means that this method doesn't tell you what dsum(0.999...) is. However, that doesn't mean there aren't other methods that will work. After all, dsum(1/7) is defined. [2] This is the problem with your dsum(0 + 9 + 9 + 9 + ...)=dsum(9 * n) . It puts infinity into a place that only finite numbers make sense in. However, since 1/3=0.333..., then 3 * 1/3 = 0.999... and that should give you dsum(3/3)=dsum(1)=1. Even if you were to consider combining another set of fractions to get 0.999... I still don't think you'd get anything other than undefined or 1, depending on how you went about it. This is because you'd need to include multiples of 3 to get those 9s, and dsum(1/3), dsum(1/6), and dsum(1/9) are all undefined. [3] However, I believe dsum(0.999...)=dsum(1) because it works in the proof for dsum(9N)=9 and it works by allowing 3/3 =1. Also, if you're going to argue against 0.999...=1, shouldn't you give a reason why the normal algebra doesn't apply? If x=0.999... and 10x=9.999..., then doesn't that mean 9x=9 => x=1, thus 0.999...=1? [1]:http://mathforum.org... [2]:http://www.sjsu.edu... [3]:http://www.sjsu.edu... 

I thank you for accepting my challenge!
First, we need to clarify what I mean by digital root. My counterargument: You are right in a way, that is what the well known definition of dsum does, but not mine. I also looked up the digital root proof a few weeks back and to be honest I was not quite satisfied of its limitation, supposedly this limitation we are talking about right now, which is why I extended it a bit. In other words, the dsum(x) I used is a bit dfferent. Mine is an explicit input output function. Thus I shall post my algebraic definition of dsum(x), without going into lengthy derivation. First off we need to be clear on how we treat infinity here. You should agree that n, representing a countably infinite whole number of digits, is composed of whole numbers added together. Which means that, apart from the fact that dsum(infinity) is not dsum(9n), exactly: 1."Infinity" is not a real number and cannot be treated as such. 2. You were partially correct when saying that dsum(1/3) and dsum(1/6) and dsum(1/9)are all quite undefined but not the case when it is 0.99..., as for the digital root function, even if the number of 9s are countably infinite, as they already are, i.e. you can count them and tend to infinite digits in only that way, dsum(9n) is still 9, no matter how large n is. Infact if you insist anyway that 9n should be treated as simply "infinity", which is not so, my digital root function also returns 9 if one were to brazenly consider it a real number and use it algebraically, oddly enough. This is my definition of digital root of x, where x is real and digitfinite, or x is real and has a homogenous digital root no matter how many digits you consider from x, and from where: drF(x) represents the final digital root of x, x being any real number which is digit finite or homogenous in its digital root, x=a/(3b1) dr(a) represents the digital root of a where a is a real whole number dr(3b1) represents the digital root of 3b1 where b is a real whole number drF(x) = dr[dr(dr(a)/dr(3b1))] {Shorthand definition} Formal algebraic definition of dr(a) [which you can use to then formally define drF(x), as simply writing drF(x) as such is simply way too long and I will likely copy it wrong somewhere] dr(a) = 5.4+(9/pi)arctan(tan(pi({abs(a)0.5arctan(tan((pi*0.5)(2abs(a)1))/pi5.4}/9) , where abs(a) can be considered as sqrt(a^2). If you were to brazenly suggest to replace x by infinity and see what happens, you can do so by saying that x=infinity/(3(1)1)=infinity, I will not oblige. Taking (infinity) as tan(pi/2), tan(infinity)=tan tan(pi/2), and as tan(pi/2) is undefined it is suitable to take tan(infinity)=tan(pi/2) That would actually result in 9 as an output, and I fully urge you to take my word with skepticism, write down drF(x) and do as I did. In other words, no matter how you view 9n to be, dr(9n) is still 9. You might ask, what makes tan(pi/2) special when there are other inputs of tan(c) which tend to infinity? Try them as well, they all give back drF(infinity)=9 Which I admit is mysterious, but also gives me freedom in saying, you were also wrong in another part of your argument: You asked me to give a reason why using normal algebra does not apply when "proving" that 0.99...=1. ...Well, this IS normal algebra, all of it. And by using normal algebra I have also shown how 0.99...=/=1. But, I will go along with what you have shown: x=0.99... 10x=0.99...*10=9.99... 10xx=0.99...*9 x=0.99... Frankly what I am saying is that the algebraic proof is flawed in the sense that it shows not proves. Here is what I mean, and after you read it, you will appreciate the difference between showing and proving: In mathematics there are, literally countless examples of when some variable has only one value or two that make sense from all the possible outcomes. The others are contradictory or non sensical. Such an example, which is very commonly found, is one that claims to show that all numbers are equal, with actually no algebraic fallacy. Let me demonstrate. [1] Proof That All Numbers Are Equal? Date: 12/06/2005 at 17:00:34 From: RV Subject: All numbers are equal Theorem: All numbers are equal. Proof: Choose arbitrary a and b, and let t = a + b. Then a + b = t (a + b)(a  b) = t(a  b) a^2  b^2 = ta  tb a^2  ta = b^2  tb a^2  ta + (t^2)/4 = b^2  tb + (t^2)/4 (a  t/2)^2 = (b  t/2)^2 a  t/2 = b  t/2 a = b So all numbers are the same, and math is pointless. What is the error in this proof? I think that if a = b then a  b = 0 and we cannot multiply both sides of the equation by (a  b) because when a number is multiplied by zero the answer is always zero. [/1] In this demonstration, there is no logical fallacy unless a=b, but a=b is just one case. The rest are still valid. So I ask you, what makes the "proof" I have linked forward more or less valid than the "proof" you proposed that 1=0.99... If to safeguard all mathematical reason, the above "proof" that all numbers are equal needs to have one of the possible solutions disregarded, that a=b, then why does this not apply to your argument? (N.B. There is a response to the question put forward in the link I provided) [1] http://mathforum.org... [/1] You're welcome. Okay, I'm going to try and make things neater this time. First, I'll address the proof that all numbers are equal. Proof That All Numbers Are Equal? The problem comes when taking the root of both sides. Since (x)^2 = (x)^2, you need to take into account the possibility that one of the sides is negative. Technically, it should go like this: (a  t/2)^2 = (b  t/2)^2 ±(a  t/2) = ±(b  t/2) Which gives us two equations: a  t/2 = (b  t/2) & a  t/2 = b  t/2 a  t/2 = b + t/2 & a = b a + b = t One gives you the original equation, and the other gives you something impossible. That's why it's important to consider that some roots may have either positive or negative answers. Not considering that actually is a fallacy. In fact, that very flaw was discussed in your link. (Which you apparently read, so I'm not sure why you included that particular link for an example.) Thus, the thing that makes my algebraic proof better is that it does not have that specific flaw. It does not have multiple possible answers, so that flaw isn't applicable here. If you want to give an example of why the algebraic proof of 0.999...=1 doesn't work, you'd have to give another example of a proof that used the same method to prove something impossible, not a proof with a completely unrelated flaw. If you could disprove something by showing that an unrelated proof didn't work, showing a single flawed proof could disprove absolutely every proof in mathematics. New definition of dsum For your definition, I'm pretty sure 'countably infinite whole number' isn't possible, as a whole number implies a number under infinity. I'll assume you just meant countably infinite, since that's already related to the set of natural numbers. Also, dsum(9n) is not 9 when n=∞. The reason for this as I said earlier: while you can eventually reach an indefinitely large whole number 9n by adding 9s together, you can never reach infinity. So saying 'no matter how large n is' isn't applicable here because 'no matter how large n is', it cannot equal infinity. Countable infinity should not be treated the same way as whole numbers because it does not have the same properties. I'm also not sure what you mean when you say 'homogeneous digital root'. 'Homogeneous' only applies to functions, differential equations, or numbers. I don't think you're talking about numbers with identical prime factors or functions that scale by c^k when you multiply the input by a constant c because that doesn't work in digital roots for anything other than 9 and k=0, especially once you calculate a root larger than 9 (e.g. dsum(2)=2 dsum(2*11)=4, dsum(2*111)=6, dsum(2*1111)=dsum(10)=1), so I guess you're talking about homogeneity in the chemical or physical sense. I suppose you're considering repeating decimals like 0.333... or 0.999... as homogeneous? And where did that algebraic definition of dr(a) come from? I though the digital root was based on modular arithmetic. (dsum(x)=x%9 unless x%9=0, or x=0, then dsum(x)=9 and dsum(x)=0 respectively.) Do you have a link for the algebraic definition? (By the way, I plugged your equation into a calculator. It didn't work.[1]) Furthermore, why are you sure that tan(pi/2) is the same as countable infinity? (It isn't, by the way. tan(pi/2) is actually complex infinity, not normal infinity. I learned that one from wolfram alpha. Besides, I'm not sure normal infinity would be the same as countable infinity, because one describes the size of a set and the other describes a number greater than any whole or real number. And we're talking about setting x to infinity when x can at least be set to any real number, a set which is uncountable.) Even ignoring all that, in your algebra, the way that you got tan(x)=a and tan(y)=b gives you tan(b)=tan(y) doesn't work because tangent function don't work like simple parentheses. It should be easy to see that those are two separate equations that cannot be combined algebraically. Your equation should be tan(∞)=tan(tan(pi/2)) since tan(pi/2)≈∞, not tan(∞)=tan(pi/2). Now, while you say I should take your word with skepticism and write down drF(x), I have no way of doing so. I'm pretty sure the equation you listed isn't correct since the parentheses are mismatched and testing it after fixem them doesn't equal the actual digital root. There's also no link to the correct equation you want me to check. I don't know if just plugging in infinity will work either because both tan(∞) and tan(pi/2) lead to things that aren't whole numbers and will never be without some sort of limit function. The limit function might work here, but I have no idea what it equals without a working equation. I doubt the limit of the algebraic definition of the digital root equals 9, but I can't really tell without that working equation. However, even if your equation worked, I think I've shown that the reasoning behind it is flawed enough that it doesn't apply to this particular situation. Sources: [1] http://www.wolframalpha.com...*0.5%29%282abs%28a%291%29%29%2Fpi5.4%7D%2F9%29+ 

First of all, I was saddened, seriously, with the fact that I failed to close parentheses, making my equation illegible.
Very well, secondly I will address your response to the proof that all numbers are equal. You specifically said that "one gives you the original equation, and the other gives you something impossible". I do realise the "flaw" (there is no flaw, the asker simply ommitted the fact that there are and  values for square roots, but the conclusion that a=b is still a possible solution) is discussed, so I ask you: How do you know, that one answer is impossible? What I am trying to show here is simply that as there are ways to show that 1=0.99..., there are was to show that they are not the same as well. Homogenous digital roots : Homogenous in a physical sense. Where did the definiton of dr(a) come from? I made my own definition of dr(a) , I kind of said that. No I have no link of the derivation or the equation itself found on the web, but I will link it, because nobody uses that form, most probably, unless someone also happened to have derived dr(a) as I did, which is highly unlikely but possible. I derived it using Graham et al's definition of fract(x). This time I will link the equation directly [1], and may I say it works for real whole numbers if you use dr(a) and for real numbers if you use drF(x) where x=a/(3b1), a and b being what I mentioned before. However for clarity's sake I will link WolframAlpha's neat presentation below with the correct equation. (Note that WolframAlpha does not even plot drF(x), at least on my smartphone, and sometimes it does not even give the right output, ...at least on my smartphone, so I highly suggest using a calculator, my computation times out :/) Now, when you ask why I plugged in tan(pi/2) as countable infinity, I certainly did not mean it to stand for countable infinity. From what I understood from what you said, "Since infinity is infinitely long, no dividing or separating into separate chunks to add together later will lead to anything less than infinity, so dsum(infinity) is undefined.", you were talking about "normal" infinity. Since drF(x) is only intended to work where x has a real domain, tan(pi/2) can be said to tend to "normal" infinity."Complex" infinity, per se, is only applicable if x is a complex variable. I simply did that to go along with what you were saying. And the reason I did that was this : I wanted to show you that even if you let 9n tend to normal infinity, the digital root would still be 9. I did not have to do this at all. You asked in the comments for me to elaborate what I specifically did when I let x tend to infinity, so I will explain it all here with the rest of what I was saying. Please refer to the equation I linked for this. I will also use limits this time. As previously stated: drF(x)=dr(dr(dr(a)/dr(3b1)))) Now you can agree, instead of writing all of it and risk making a syntax error somewhere, we can simply work it out bit by bit. If one lets b=1 and a tend to infinity; drF("infinity")=dr(dr(dr("infinity)/dr1)=dr(dr(dr("infinity")/dr(2))) As a approaches infinity, we can see that dr(a) will tend to nothing but 5.4. [2] (Link below. Of course we cannot plug in a=infinity, but we can check where it is going as a gets closer, as we do in limits) You were actually very right when you pointed out my mistake with the tangent function, hopefully it is cleared now and for that I apologize. Below you will find a link of drF(x) in its full form, (which again gives me a computational time out) and a link to an online limit calculator with the equation dr(a) already plugged in: (The limit was taken for only dr(a) as only it has a in it, by using the formal method of getting closer to a target, maybe you will have more luck with setting the limit directly to infinity, but when I tried it the computation timed out) [1] http://m.wolframalpha.com...(9%2Fpi)(arctan(tan(pi(((5.4%2B(9%2Fpi)arctan(tan(pi((%5B5.4%2B(9%2Fpi)arctan(tan(pi((x0.9)%2F90.5)))%5D%2F%5B5.4%2B(9%2Fpi)arctan(tan(pi((3b10.9)%2F90.5)))%5D0.9)%2F90.5))))0.9)%2F90.5))))&incCompTime=true[/1] [2] http://m.wolframalpha.com... [/2] P.S. As I have a feeling the first link might not work: drF(x) =5.4+(9/pi)(arctan(tan(pi(((5.4+(9/pi)arctan(tan(pi(([5.4+(9/pi)arctan(tan(pi((x0.9)/90.5)))]/[5.4+(9/pi)arctan(tan(pi((3b10.9)/90.5)))]0.9)/90.5))))0.9)/90.5)))) SimLeek forfeited this round. 

My opponent forfeited the previous round. I will assume he did not give up, but had no time to respond.
I am solely interested in what is wrong with the proof, putting my copypaste errors of my equation aside. If anyone can shed any light, it will be vastly appreciated as I have quite the existential crisis right now. ;) SimLeek forfeited this round. 

No response.
SimLeek forfeited this round. 
No votes have been placed for this debate.
You said that digital roots are based on modular arithmetic but then you proceed to identify the limitations.
That means, to no surprise, that digital roots are not well defined in modular arithmetic.
As tan(pi/2)>infinity
tan(infinity)=tantan(pi/2)=pi/2
This is just a side note to help clear things up should you write drF(x) and see what happens in the case x tends to infinity.
[I would accept it but i don't have time :( ]