Math problem

Status
Not open for further replies.
That's just it, though - the working proof doesn't do this. Well, okay, it does, but only as a side effect. It takes the more general proof and applies it to a specific value of a.

Working proof: x = a <=> 10x = radixpointshift(a)
Your "broken" proof: x = a <=> 10x = 9 + a

The two methods are incompatible. The second is only valid for a = 1 (which is what you're saying), otherwise algebraic law is broken. The first is applicable to any value of a, and algebraic law is never broken.
Problem with that method is that you remove x from the proof entirely in the third step, so you end up with an identity statement which doesn't prove anything.

Sent from my SPH-D710 using Tapatalk 2
That's basically my point.
 
Like this:

x = a
9 + x = 9 + a
9 + x - x = 9 + a - a
9 = 9
Therefore, x still equals a... which was never in doubt in the first place.
 
You haven't said anything I don't already know, nor argues against my point. I was using those proofs illustratively to demonstrate the very things you've pointed out more explicitly. As said earlier in the thread, it basically boils down to: is 9 + 0.99999... == 10*0.99999...

My contention revolves around the number of decimal places in each one. In the first, there is infinite decimal places. In the second, there is infinite-1 decimal places...which we treat as infinite decimal places.

I contend that 9+0.99999... is a less ambiguous interpretation of the "working" proof than 10*0.99999... because it doesn't in any way adjust the number of decimal places. That's where I think some implicit rounding occurs.
 
I see. It's an issue of real number construction and the presence or absence of non-zero infinitesimals.

But we've gone quite far afield now from the original topic, and I feel bad enough having inflicted Halforums to this discussion without adding number theory on top of it.

Sent from my SPH-D710 using Tapatalk 2
 
I contend that 9+0.99999... is a less ambiguous interpretation of the "working" proof than 10*0.99999... because it doesn't in any way adjust the number of decimal places. That's where I think some implicit rounding occurs.
If you want to approach it quasi-arithmatically, then remember that multiplication is just a shorthand form of addition, so "10x" is exactly equivalent to writing "x+x+x+x+x+x+x+x+x+x," and therefore:
Code:
10 * 0.999...
is in fact exactly the same as stating:
Code:
  0.999...
  0.999...
  0.999...
  0.999...
  0.999...
  0.999...
  0.999...
  0.999...
  0.999...
+ 0.999...
--------
  9.999...
which is in fact completely different from stating:
Code:
  0.999...
+ 9.000...
--------
  9.999...
...which can be verified simply by inspection. If anything, you accidentally show that 9.999... is the same as 9.999... (both methods produce the same result), which would actually prove that 9x0.999...=9 and therefore that 0.999...=1.

Now each of the ten terms in that tall addition problem above all have infinite significant digits. Thus it follows that there is no "lost" digit on the end, because every digit always has another 9 to the right of it to keep it from "rolling over" to zero. Your argument that you can make an equivalent by saying, "We are not multiplying by 10, we are adding a 9 in front of it" makes no sense for the same reason I can't arbitrarily say that "we are not multiplying by ten, we are adding a zero on the end." If that were true, then 10 x 0.999... would instead be 0.999...0 which is impossible (that rule has a hidden restriction, which is that the number you are multiplying by 10 can't have any significant digits after the decimal point). Even if you try and rationalize it by moving the decimal point and then sticking a zero into the spot which "opened up" (10x0.999... = 9.999...0) this "rule" still fails because there is no end, no terminus where you could stick that zero. The hard part to visualize is that the series of nines is not dynamically growing and pushing out into infinity faster and faster as you race to put your zero on the "end." Instead it is static. Its foreverness does not change since it was already forever when you started. You could count off a dozen googolplexes of 9's as you try to reach the end, but once you had done so, you would literally be no closer to the "end" than when you started. Not "figuratively" no closer, but literally. Even half of forever is still forever. This is what "Infinite" means.

You can convert it to other bases if you really want, but the result ends up being the same.
0.999... (base 10) is exactly equal to 0.222... (base 3) or 0.FFF... (base 16). It is easiest to see in (base 2) because 0.111... perfectly illustrates the concept of "there is no room for any number to exist between 0.111... and 1.000..."

If you want to look at this algorithmically instead of algebraically, the concept being stated is that a zero followed by an infinite series of digits-which-are-all-one-unit-less-than-the-base will always be the same as (or simplify to) one unit.

Infinity is a hard concept to grasp, and transcends such concepts as, "how many." In Mathematics, you say something is "Infinite" not because it would be impractical to determine (like how many atoms exist in the Universe), but because it would be impossible to quantify (like how many real numbers exist between 0 and 1).

--Patrick
 
My best friend is a mathematics professor with a PhD in mathematics. I asked him about this, and he told me that 0.999... is 1 and you guys are dumb.

That's about all I have to contribute to this.


*I didn't actually ask him specifically about this, but we've had the exact same conversation before. I added the you guys are dumb part.
 
You haven't said anything I don't already know, nor argues against my point. I was using those proofs illustratively to demonstrate the very things you've pointed out more explicitly. As said earlier in the thread, it basically boils down to: is 9 + 0.99999... == 10*0.99999...

My contention revolves around the number of decimal places in each one. In the first, there is infinite decimal places. In the second, there is infinite-1 decimal places...which we treat as infinite decimal places.
It's really a matter of defining infinity. What we're all saying, I think, is that infinity-1=infinity, due to how infinity works. In your explanation of 1/3 where you keep adding decimal 3's, you say that we approximate the division by 'an infinity of 3's' because we're not able to get to the last decimal place, but there's really an infinity of 3's because you know every division begets the same result and you'll keep getting 3's. There's no last decimal to the division unless you decide to stop it... if you do the 'exact' division, you actually get the infinity of 3's!
Anyway, I don't think we're going to agree here.

I contend that 9+0.99999... is a less ambiguous interpretation of the "working" proof than 10*0.99999... because it doesn't in any way adjust the number of decimal places. That's where I think some implicit rounding occurs.
Even if you interpret it that way, your step would yield
9.9999...=9+x instead of
9.9999...=10x, right? So your breaking it doesn't really work.
(Please, if you answer prioritize this second part. I think it may be more productive.)
 
9.9999...=9+x instead of
9.9999...=10x, right?
No, thats not true.[DOUBLEPOST=1355413692][/DOUBLEPOST]
Infinity is a hard concept to grasp, and transcends such concepts as, "how many." In Mathematics, you say something is "Infinite" not because it would be impractical to determine (like how many atoms exist in the Universe), but because it would be impossible to quantify (like how many real numbers exist between 0 and 1).

--Patrick
I think therein lies the problem.[DOUBLEPOST=1355414056][/DOUBLEPOST]
you guys are dumb.
I may very well be. I like playing devil's advocate with my math friends, which might be what makes me dumb.
 

fade

Staff member
Do you remember the scene in Police Academy where Tackleberry shows up after the gunfight and realizes he missed it? That's me right now.
 
Do you remember the scene in Police Academy where Tackleberry shows up after the gunfight and realizes he missed it? That's me right now.
Feel free to correct/comment any misconceptions or inconsistencies you see. That way we'll all learn. Just remember to show your work. :)

--Patrick
 
Status
Not open for further replies.
Top