People like to say that they want a paycheck with "lots of zeroes in it." Seems to me that they really should prefer a paycheck with "lots of nines in it." Replacing any zero with a nine would be an often substantial improvement, unless it's one of those unfortunate negative paychecks. What's more, asking for nines avoids the embarrassment of leading zeroes ("we'll pay you $000,005").
There's still the problem of digits after the decimal point; an employer can easily and cheaply pay you a paycheck with an infinite number of nines (or, to save toner, pay you a paycheck that is worth the same as a number with an infinite number of nines). So next time you're looking for a job, tell the employer "I'd like a paycheck with lots of nines in it -- before the decimal point."
To be safe, you need to specify the currency, number set (integers here), sign, and base...
For example, 1/3 equals .3333 (ad infinitum) and 2/3 equals .6666 (ad infinitum), and you can get the calculator or spreadsheet to display those numbers (although you have to specify rounding down to get .6666 instead of .6667), but you can never get the calculator or spreadsheet to display 3/3 as .9999.
No?
restating it this way might clarify:
lim (1-10**-n) = 1
n -> oo
1 - 0.999... = 0.000...
well, to beat a dead horse ... I think we're mixing labels and concepts. "0.999 ..." isn't anything numerical, it's a shorthand label for a limiting operation as noted above (or prof V's version, if you prefer). so altho the statements "the infinite sum is equal 1" and my "lim blah = 1" are meaningful, the statement ".999 ... is equal 1" strictly speaking is just shorthand for one of the other two statements (or another equivalent one) and is therefore meaningful only if both parties have agreed beforehand to so interpret it. in this forum, my guess is that it would be a mistake to assume this a priori agreement, as evidenced by the comments. I rest my case.
Anyway, the arithmetic logic units of calculators only work with finite approximations, not real numbers. So, simply because punching 1 / 3 + 2 / 3 into your (algebraic hierarchy) calculator yields 1, it doesn't mean 1 is equal to .999... .
It would seem that, were one to wish (for whatever stupid reason) to be clever when negotiating for remuneration, the thing to do is insist on using scientific notation, which is unambiguous in matters such as this.
Kevin L. Connors, Editor
The Daily Brief
But with this proviso, if "..." is understood to mean infinite repetition, then "0.999... = 1", no ifs, ands, or buts.
I find two lines of logic persuasive. Unfortunately, they lead to opposite conclusions.
1) 1/3 = .3333......
(1/3)*3 = 1 and .3333.....*3=.9999...
therefore .9999....=1
2) 1-.9=.1; 1-.99=.01; 1-.999=.001; etc.
therefore, the difference between 1 and .9999... must always be positive and non-zero (even if it is vanishingly small) and it follows that 1 does not equal .9999...
Both statements cannot be true, but I cannot see where one of them is false. I would be delighted if someone would explain.
Here's where the falseness comes in. Your statement is correct for any finite truncation, but not for the infinite. The problem (conceptually) is that the positive numbers are not a "topologically closed" set -- the limit of an infinite sequence of positive numbers can be 0, which is not, itself, a positive number.
Another way to convince yourself that 0.999999999.... = 1 is to recall how to convert any repeating decimal into a fraction:
0.44444444..... = X
4.44444444..... = 10X
10X = 4.44444444444....
- X = 0.44444444444.....
9X = 4, so X = 4/9
Try the same thing with 0.9999999999999....
(This isn't a "proof," just another way of trying to convince yourself.)
Incidentally, this ambiguity can cause occasional problems when trying to mathematically prove things using decimal representations, since rational numbers whose denominators have only 2s and 5s as factors don't have unique decimal representations;
3/5 = 0.600000000000000.... = 0.5999999999999999....
this may be clear to those who have the requisite background, but it isn't to everyone. in fact, your example of "2+2=4" is widely used as an example of an obvious universal truth when, IMO (and apparently yours), it is anything but. the need for agreement on what notation/labels - mathematical, political, philosophical, legal, whatever - is "understood to mean" was my only point. and to repeat, the comments suggest that in this forum the notation in question does not have a commonly understood meaning; otherwise, there would not be the "debate" over what it is.
I think that referring to a big paycheck as one with a lot of zeros in it is related to the concept of zero as a placeholder, rather than an actual integer. This is the great advantage that arabic numerals have over, say, roman numerals. So, with a nod to the placeholder function of zero, asking for a paycheck with a lot of zeros is essentially like asking for a paycheck with a lot of "figures" (as in six figure, seven figure, etc.). I suppose the idea being that with enough figures, it doesn't matter precisely what the figures are.
Ask for ten significant digits, no more than two in the mantissa.
And you are quite right to say that the problem is a conceptual one. The series .1,.01,.001,... must at some point have 0 as a term and not merely approach 0 for my second line of logic to be false. This, to me, is not obvious or intuitive. The problem is that I (intuitively) think that each term in the series should have the same properties as each conceivable term in the series (which are all positive).
My struggles with the infinite...
I guess this is what bothers me about ".999... = =1". the following is (I think) true whether one is dealing with the open or closed unit interval:
0.999... = lim (1-10**-n) = 1
. . . . . . . . . n->oo
however, the conclusion "therefore, 0.999...= =1 isn't meaningful for the open interval. or have the intervening 40+ years clouded my memory on this arcania?
To look at it another way, if I were to ask a prospective employer for a salary of $999,999, the employer might wonder if I were serious about the job. So, I might as well ask for $1,000,000 and be done with it.
let s=0.x1... xn x1...xn (repeat indefinitely)
10**n s = 10**n (0.x1... xn x1...xn ...)
= (x1...xn).(x1...xn)... = x1...xn+s
s=x1...xn/(10**n-1)
examples:
s=0.111... : n=1, x1=1, s=1/(10-1) = 1/9
s=0.2525...: n=2, x1x2=25, s=25/99
If not, then the proceeding 1) 1/3 = 0.333... -> 2) 3 * (1/3) = 3 * (0.333...) -> 3) 1 = 0.999... has a problem.
There may be such a proof but I barely know set theory, so I ain't got it. And it strikes me that you might no tbe able to make a usable exposition with pennies, a physical number line, or pieces of string.
I applaud your care in not accepting it as "obvious". this isn't a "proof", but it may address your concern about the meaning of the "*" operator when applied to the symbol "0.333...":
define 0.mmm... = m*(sum 10**-n, n=1,...,oo)
k*(0.mmm...) = k*[m*(sum 10**-n, n=1...,oo)]
=(k*m)*(sum 10**-n, n=1...,oo) = 0.(km)(km)(km)...
if k*m<10
this is just a trivial formalization of the usual rules for multiplying in the special case where the product of the integer in a repeating decimal (m) and another integer (k) is less than 10 (to avoid addressing carry).
"Does anyone have a good "proof" that 3 * 0.333... = 0.999... where * is the same operation that * represents in 3*3 = 9?
If not, then the proceeding 1) 1/3 = 0.333... -> 2) 3 * (1/3) = 3 * (0.333...) -> 3) 1 = 0.999... has a problem."
Wow. What a beautifully subtle understanding of the issue (it must be, since I was thinking of the same question after I posted my bit, above ;-) )
Here's how I break it down:
If you believe that 1/3 = 0.3333...(forever), and if you believe that a = b implies that a+a+a = b+b+b, then it is clear that
1/3 + 1/3 + 1/3 = 0.333..... + 0.333333.... + 0.333333....
and since the left side = 1, so must the right.
But now we're down to your excellent observation: What in the world do we mean by the right side of this "=" Why should that be 0.9999....? (In this particular example, we can somehow cheat, and add left to right, since no carrying is involved, but, again, that's cheating. Everyone knows that you have to start at the smallest place when adding decimal numbers, and these things have no "smallest" place. The same criticism applies to my subtraction algorithm, above, which is why I said it wasn't a real "proof.")
The truth is, we can't add these expressions "place by place forever." Addition is a "binary" (two term) operation, and so can be extended finitely, but not, in general, infinitely. So that proof, while appealing, is not rigorous. It can, perhaps, be patched, but not easily.
It's best to start over.
Technically, 0.999... is actually (as was pointed out above) an infinite geometric series:
0.9 + 0.09 + 0.009 + .... = 0.9(1/10) + 0.9(1/100) + ....
and since we can't (algorithmically) add forever, we instead define the infinite sum as the limit (if it exists) of the finite partial sums:
lim (n -> infinity) 0.999999...9 ("n" nines.)
Now, this limit = 1. Why? Because it's impossible to make an interval so small, around 1, that it doesn't contain all but finitely many of these partial sums, and that's the definition of a limit. For example, if I make an interval of radius 0.00005 around 1, it will contain all of the terms from 0.99999 on to infinity, only missing the first 4 (a finite number of) terms.
So, truth be told, the problem was re-defined into a topological (limit-based), rather than an algebraic (algorithm-based) problem.
In some very real sense, this becomes a "because I said so" argument -- that is, we've defined an infinite decimal expansion so that 0.99999.... forever has no choice but to equal 1. And, you're absolutely right, 3*0.333 (forever) does not = 0.999 (forever) in the SAME SENSE that 3*3 = 9. In fact, it equals it in an extended (topological) definition that happens to remain consistent with the finite (algebraic) definition.
(My explanation may well be faulty, but I'm convinced that your subtle distinction is absolutely valid.)
That is a good start, but that * is different from the * that applies to numbers like 1/3 and the * that applies to numbers like 1, no? A couple of quick changes may fix it, but, again, this may be beyond my math ken.
Maybe the solution is in your last paragraph . . .
limit (n -> infinity) 3* Sn (the partial sum sequence) =
3* limit(n -> infinity) Sn
(we can "pull the constant through limits")
using the topological (limit) definition. And "coincidentally" it nicely matches with our usual 3*3 definition (proof that God is, at least sometimes, very good.)
I love proofs by definition. They're so much nicer than actual, honest-to-goodness common sense arguments. My favorite lecture day in beginning algebra is when I can honestly say that the reason that 3^0 = 1 is BECAUSE I SAID SO (damn, the superscript tags work in the preview, but I can't post with them.). That is, it's defined to be so, in order that the rules for exponents continue to work as they do for positive integer exponents.
Just like "why isn't 1 prime?" "Because if it were, all of the theorems about primes would have to contain the caveat 'primes > 1' "
Or "Why is 0! = 1?" 5! = 5*4*3*2*1, for example, so you'd think that 0! should = 0. But it doesn't, for the simple reason that otherwise, many many formulae would have to strip out 0 and treat it as a special case.
If only I could raise my kids that way.
See the <a rel="nofollow" href="http://www.jir.com/"><i>Journal of Irreproducible Results</i></a> (volume 41, number 2). "A Note on the Pending Demise of All Mathematics" by Sanford H. Lefkowitz:
<blockquote>
...details about the study of addition at the National Number Accelerator (NNA) have been revealed.
...the numerical scientists bombarded a "0" (a zero) with a stream of "1"s (ones).
...But when the scientists examined the detritus of the "1", they were in for a shock (partly because the equipment was not properly grounded, but also because the results were very surprising).
...The imperfections were very, very small and were observable only with the highest powered numerical microscope in the world. But the imperfections were unmistakably there. As a result, it is not the case that 1 + 1 = 2. 1 + 2 is extremely close to 2, but is actually slightly less than 2.
...As amazing as it may seem to traditional mathematicians, there is a largest number. The largest number in the number system is 1.26 * 10^25 + 14....
</blockquote>
See the Journal of Irreproducible Results (volume 41, number 2). "A Note on the Pending Demise of All Mathematics" by Sanford H. Lefkowitz:
And it changes playground name-calling forever.
"You're a big poopy-head 1.26 * 10^25 + 14 times."
"Well, you're a big poopy-head 1.26 * 10^25 + 15 times."
"Nu-unh, that's not a number!"
"Mommeeeeeee!"
"1 + 2 is extremely close to 2" should obviously be
"1 + 1 is extremely close to 2" (as it is in the original source material).
Sorry about that.
To confuse the issue, I'm not sure the proposition holds that 0.9999...=1.000 if you start playing with the set of Surreal numbers, but those have fewer, ah... real-world applications than imaginary numbers. I believe they're also reliant on the axiom of choice, making them less generally useful than the reals.
The tricky bit comes from thinking of 0.999... as being an actual number, which it isn't — you can never write it, no matter how hard you try. As other posters have said, it is exactly the same as the expression lim (n to infinity) 1 - 10^(-n) = 1, and all the 9s we can write only approximate it — badly.
Intuitively it's strange, but it's really just an artifact of the way we try to express limits like that in terms of numbers and decimals. (To turn your argument on its head, we could easily argue that the number 999... — that is, a 9 followed by an infinite number of 9s — is not infinite, since it is finite no matter how many 9s you write. Of course, a 9 followed by an infinite number of 9s would necessarily be an infinite quantity.)
Math is fun.
How would that definition work in the whole number world, where you can find no non-zero number closer to 2 than 1?
Alternatively, if 0.999... = 1, I presume 1.000... = 1 as well, so 0.999... = 1.000... . Is 1 not closer to 0.999... than 1.000... ? (I can see definitional problems here, but I think they stem from the ease with which you are intermingling different types of "numbers," and not from my query.)
If, however, as you suggest, a.bbb... is not a number but a representative of a limit series, then the operations that work on a.bbb... are not necessarily the same operations that work on numbers. In that case, "0.999... = 1" really means that the limit of the infinite series 0.9 + 0.99 + 0.999 . . . is 1, not that they are equal in the same way that 1 and 1 are, or 2 and 2 are.
Devin, you write, "The tricky bit comes from thinking of 0.999... as being an actual number, which it isn't -- you can never write it, no matter how hard you try." How can that possibly be right? You can't write the full decimal expansion of 1/3, of the square root of 2, of pi, and so on. What does being able to write the full decimal expansion of something have to do with whether it is "an actual number"?
Tennesseean, you write, "Is 1 not closer to 0.999... than 1.000...?" The answer, it seems to me, is "no" (even if you mean "Is 1 not closer to 1.000... than 0.999...," which is what I think you mean).
The bottom line is that there's no puzzle here, and no different definitions of equals or different categories of numbers. "0.999..." is just a convenient way of writing "the sum of an infinite series 9/10^n, as n goes from 1 to infinity," just as "0.333..." is a convenient way of writing "the sum of an infinite series 3/10^n, as n goes from 1 to infinity." 0.333... is equal to 1/3 because that's what the sum of that infinite series equals (which is just a convenient way of saying "that's what the finite sums in that series converge to"). 0.999... is equal to 1 for precisely the same reason. None of them is "not a number."
Regarding my dilemma, I should have made clear that 1.000... is supposed to be 1 + an infinitely small amount (or, the sum of the infinite series which approaches 1 from "the other side" of 0.999...). Maybe that wasn't clear. Then the question is which is closer to 0.999..., 1 or 1.000... .
But, really, that isn't that much of a puzzle, because if one infinitesmally small difference doesn't much count, why should two?
But your last paragraph, which does resolve everything, also obviates, it seems to me, a handful of interesting questions. If by 0.999... we mean the limit of the infinite series 0.9 + 0.09 + ..., then it is uncontroversial that 0.999... = 1. But, whenever people tread out this stuff, they mean to suggest that the infinite series itself is equal to 1 -- which is a different matter altogether.
Remember that lots of incredibly smart people have thought that the square root of 2 and pi are not numbers, or at least that they are significantly different beasts than 6 or 9 or even 3.1415926.
What is most amazing to me is that I doubt but one or two of my mathematics teachers (I probably had about 20 official mathematics instructors) had any idea why those numbers were controversial to those people or, perhaps more importantly, why other people have to come to believe that those numbers are legitimately considered numbers.
What on earth are you doing posting on infinite series at 4:09am?? That can't be healthy.
I further realize that I was too hasty in my first proposition in equating 1/3 with .333... in that this is no more or less reasonable than saying .999...=1.
Cf. what Bertrand Russell once said in this context:
[Copied from this site]
I was in high school, working part-time in a yogurt shop, and had only worked for about 4 months.
well, I got tired and didn't distinguish, so here's the early AM version as opposed to the late PM one:
define "0.mmm..." (=d) "m x (sum 10**-n, n=1,...,oo)" where "(=d)" means "equal by definition" and "x" is the usual integer multiply operator
(note: IMO, this (or equivalent)is the only sense in which the symbology "0.mmm..." has any meaning. since for any m the series converges to m/9, in that sense of "is" (shades of clinton), "0.mmm..." is a real number, namely m/9.
define a "multiplication operator" * on elements "0.mmm..." and integers k to be
k*(0.mmm...) (=d) k x [m x (sum 10**-n, n=1...,oo)]
= (k x m) x [sum 10**-n, n=1...,oo)]
(=d) 0.(k x m)(k x m)...
if k x m<10
and this restriction wasn't "cheating", it was laziness to avoid addressing the carry, which actually is straightforward: make each term in the repeating decimal symbology (k x m + c) mod 10 where c is the carry (ie, the multiple of ten - I can't remember the nomenclature).
eg, for m=8 and k=3, the answer should be 24/9=2.666...
0.(24)(24)(24)... = 2.(4+2)(4+2)... = 2.666...