0.999 ... is 1 for the same reason 0.333... is 1/3, it's just a different expression for the same number.
This is a discussion on Concept of Quantity within the General Discussions forums, part of the Community Boards category; 0.999 ... is 1 for the same reason 0.333... is 1/3, it's just a different expression for the same number....
0.999 ... is 1 for the same reason 0.333... is 1/3, it's just a different expression for the same number.
Last edited by whiteflags; 03-01-2011 at 12:05 PM.
I can't proof it, but I can proof the reverse, that 0.9999..... = 1. I haven't read the entire thread, but I couldn't find the actual proof in it glancing over it.
10*0.99999.... = 9.99999....
Subtract 0.99999.... from 9.99999... As there are an infinite number of 9's in both, each 9 in 0.999... has a matching 9 in 9.9999... it "removes". Hence:
9.9999... - 0.9999... = 9
So let's say a = 0.99999...
I just showed that 10*a - a = 9.
9*a = 9
a = 1
Not my own proof, but I've always particularly liked this proof...
The problem here is there is in quantifying infinity. I think what you're trying to say is that as the number of nines approaches infinity, the value approaches 1. (?)
Been a while since I've done any real math, but I'm much more comfortable with that than saying 0.999... = 1.
edit: btw, I like the identity proof.
Last edited by Perspective; 03-01-2011 at 01:41 PM.
You're right saying that: as the number of nines approaches infinity, the value approaches one. However, if there is an INFINITE amount of 9's, as indicated by 0.999..., then the proof I presented holds.
There's the difference between the number of 9's approaching infinity, or there actually being an infinite number. They're not the same thing.
That is true for any finite number of nines. You can prove it with nested interval theorem. EDIT: Actually, I'm not sure I can . However, you can infinitely nest intervals with 1 and .999... always in them. Nested interval theorem states there is exactly one number in every infinitely nested interval.
Of course I can. It's 0.999...
Real numbers are uncountable. The "you cannot find a number" is simply an exploitation of our inability to represent these numbers to their infinite precision. It does not mean however such a number can't exist. Many theorems have proven the infinite set of rational numbers. The same way we use oo to represent infinity, for the purposes of this debate we can simply stipulate that 0.(9) is not a number, but the representation of a number that has an infinite number of 9s.
As such, 0.(9) stands between 0.(9) and 1. Or, if you want a more complete answer, oo stands between 0.(9) and 1.
Last edited by Mario F.; 03-01-2011 at 05:16 PM.
From now on a large part of your life will be spent finding and correcting your own mistakes.
And if you are lucky and land yourself a good job, a whole lot more time will be spent finding and correcting other people's mistakes.
That has to be good, no?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Where is this "infinity" thing coming from? The fact that the number of digits is infinite is irrelevant.
How do you express the value 1/10 in decimal? It's 0.1. How do you express it in binary? It requires an unending number of digits. Thus, the infinitude of the representation is an artifact of the chosen base, not anything to do with the number itself.
It's a tough concept and there are many ways of looking at it, but 0.999... is indisputably equal to 1. Period.And certainly 0.999... is not equal to 1. Just because you can't find a number in between them doesn't make them the same. The inequality 0.999... < 1 still holds for any number of nines.
The real numbers are dense. This means that between any two unequal real numbers there are an infinite number of real numbers. Thus if 0.999... and 1 are not equal, there are an infinite number (uncountably infinite, actually) of values between the two. Name just one of them.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
From now on a large part of your life will be spent finding and correcting your own mistakes.
And if you are lucky and land yourself a good job, a whole lot more time will be spent finding and correcting other people's mistakes.
That has to be good, no?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
You're saying 0.(9) is a number which is unequal to itself?
EDIT: Okay, let's start the long process of going through each of the thousands of explanation of why 0.999... == 1.
Let x = 0.999...
Thus 10 * x = 9.999...
Thus 10 * x - x = 9.999... - 0.999...
All the nines on the right of the decimal subtract away:
10 * x - x = 9
9 * x = 9
x = 1
The only way the proof fails is if 0.999... != 0.999...
Last edited by brewbuck; 03-01-2011 at 09:38 PM.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
It follows on the same concept that oo does not equal oo, brewbuck. It's another of infinity paradoxes; also somewhat explored by Hippasus when he proved that the square root of 2 is both odd and even.
Conceptually you know very well that for every precision, no mater how large, that you can think for 0.(9), you need always to add another decimal place. You'll do this indefinitely. However, for 0.(9) to become 1 you need to add 0.(0)1. You are required an infinitesimal to reach 1. You are thus required another infinity.
But I also believe your axiom to be wrong:
And here you will make your first mistake:Let x = 0.999...
Thus 10 * x = 9.999...
Thus 10 * x - x = 9.999... - 0.999...
They don't really. Not for the "last" decimal place, represented by an infinitesimal. If we replace the above for a finite quantity it's easy to see why:All the nines on the right of the decimal subtract away:
10 * x - x = 9
Let X = 0.999
Thus 10 * x = 9.99.
Thus 10 * x - x = 9.99 - 0.999
Oops!
Next you make your second mistake, I believe:
But oo-oo != 0. It's undefined. It's both 0 and 1, or 12 and 13. Or any other number you can imagine. One of the properties of infinity is that it does not equal itself. Mathematically your expression becomes undefined at this point. The thought is that we know there is a number for your expression, but we can never reach it. As such it's undefined.10 * x - x = 9
So, to finalize your axiom:
10 * x - x = undefined
I suppose I can be corrected somewhere since my math skills are tremendously limited. But more than my gross attempt at correcting you, I think it stands that 0.(9) is the representation of a number that never reaches 1. On the right side of an interval, this number would be represented as "1[" and this is a crucial hint to the nature of this number and the fact it does not equal 1.
From now on a large part of your life will be spent finding and correcting your own mistakes.
And if you are lucky and land yourself a good job, a whole lot more time will be spent finding and correcting other people's mistakes.
That has to be good, no?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I'm probably being pants on head retarded about this but like I said before, 0.333... is 1/3.
Therefore
1/3 + 1/3 + 1/3 = 1
Iff 1/3 = 0.333... then 0.333... + 0.333... + 0.333... = 0.999...
QED.
There are real numbers that result in a repeated sequence in any base. 0.2 doesn't stop being 0.2 when you express it in binary. But I think 1 is special because it's a unit. I think that in many bases (above binary perhaps, unless you entertain fractional bits) 1 has alternate expressions.
But again... pants on head retarded here.
Last edited by whiteflags; 03-01-2011 at 10:58 PM.
Ah, I see your point now. Trouble is it has been long established that irrational numbers cannot be represented as fractions. So, 0.333... cannot be really represented as 1/3. Why? Well, exactly because of the example you gave. Many other examples exist where the irrationality of irrational numbers is evident every time you try to represent them as fractional numbers, like the aforementioned Hippasus proof.
We may do so on a daily-basis for convenience sake because the margins of error we impose become acceptable. But when it comes down to discussing the nature of 0.333..., or 0.999... for that matter, bringing in fractional numbers will not do because it will introduce an error margin that simply isn't acceptable.
From now on a large part of your life will be spent finding and correcting your own mistakes.
And if you are lucky and land yourself a good job, a whole lot more time will be spent finding and correcting other people's mistakes.
That has to be good, no?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
1/3 is not irrational on the basis that I just expressed it in rational form. (e.g. sqrt 2 is irrational. ) But I see you're point: 0.333... is an approximation of 1/3, just as 0.999... would be of 1. As an approximation, it couldn't be exactly equal, but the difference is infinitesimally small, so by all means of proof it would be equal.
EDIT: By that I mean 0.999... or 0.333... carried out to some finite place would be an approximation but the difference between the actual numbers and 1 and 1/3 respectively are so small.
Last edited by whiteflags; 03-01-2011 at 11:52 PM.