Now without sarcasm, I think that 0.3333… = 1/3 but if we want to be really accurate then it’s better to not use 0.3333… in any equation and instead keep the 1/3. Even to write the result of an equation as for example something like (1/3)sqrt(2).
In that sense, pi would be a shorthand for writing 4SUMn,0->infinite
But here’s the thing: 1/3 is not only a Rational number, it’s also part of the Reals, so 0.33333… is just a different kind of notation, a notation which at best is recognised as a different notation for the accurate 1/3 notation, at worst is used like an approximation.
As for 0.999999… being 1. I think it is the equal number for someone who recognises it as a different notation for 1, a notation which kind of implies 1.0.
At worst it’s taken as an approximation which is never accurate. That is, if one takes the decimal places as literally the number and then finds that there is always one missing.
Pi is a specific ratio that cannot be written in decimal form. There are a great many known relationships that cannot be represented in decimal form. And any and every decimal number that requires a ellipsis is not the actual limit for the same reason the decimal representations of Pi (even out to the 12 trillion places) is not the actual number. Infinite means that the string keeps going AND NEVER GETS TO THE NUMBER.
These two sentences are mutual incompatible. We know its length to be infinite. That is a known length.
I showed two examples, specifically addressing your claims that 1+infinity > infinity, and that two line segments of different lengths have different numbers of points. If you think my reasoning is flawed, show your work.
You seem to be using a notion of infinity as somehow uncertain. But infinite quantities are certain, they are static, they’re just infinite. They aren’t growing or changing, we aren’t waiting for them to get somewhere, they are just infinite. An infinite string isn’t a process. An infinite string of 3s isn’t growing, we aren’t actually doing long division when refer to it. 1 divided by 3 produces an infinite, repeating decimal expansion .333… That infinite expansion is how 1 divided by 3 is written.
We can show that .333… equals 1/3, using a point you made earlier:
Infinite is NOT a length. It is a quality. You already agreed that not all infinites are equal.
A little off topic, so just briefly:
You can specify a particular infinite list, say the integers. And you can specify that you are going to take every other number, which you call “even” to make another list. In so doing, you have already stated that you only took half of the first list to make the second list. QED.
Alternatively you can specify the first list as the integers. And then specify a second list as 2 times each of the first list. In such a case, you have two equal cardinality lists. The problem is that you cannot multiply 2 times the maximum/last element of the first list, because there isn’t such a maximum/last (NOT, NOT, NOT because you didn’t have time to get to it). Thus you can’t actually fulfill your second list specification. QED.
In either case, you cannot actually accomplish what you imagined doing.
Not at all. “Infinity” is certainly not existent.
Except that there are different infinites. And even if you did know the number of items in the infinite list, you still would not know their sum, only their limit. Different size infinite sets can have the same summation limit. The limit DOES NOT specify the final summation.
That is an issue with you, not me. As I have said many times, I am not referring to the process unless I state that I am. There are different cardinalities and/or sizes of infinite. Which one do you have? You don’t know. What is the sum of all of its elements? You don’t know that either. All you know is the digits involved and the limit which is being eternally approached without ever, ever, ever being reached. It is certain that the limit is NOT reached, which is why it is an infinite, never ending string, with an always present remaining difference to 1.0 not summed.
You keep thinking that by stating that it is infinite, you have specified the end point of the string, “infinity”, and thus of the summation. There is no end point to specify. And the summation never tallies as anything because it never ends. Even if you have added an infinite quantity of elements, you still have an infinite quantity to go. And you always do. It is “statically” unknown as to how many elements there are. You only know that it is an endless list.
Fault. 9 times 0.333… is NOT 3.0.
What is 9 times 3? 27.
Carried infinitely gives you: 2.999…
You merely presumed the consequent.
And when you “subtract” the two series, you get: 2.7 + 0.27 + 0.027 + …
You know that every element in the infinite list:
0.1
0.01
0.001
.
.
.
has a 1 at the end. And you know that such is the entire list of the differences between 1 and ALL partial sums of the 0.999… series. Yet you keep insisting that “the final sum” has zero difference. Where did the 1 disappear to in that “final sum”? It is required to be in the specified list.
A) there is NO FINAL SUMMATION.
B) Even if there was a final summation, there would still be required a difference between it and 1.0
A poor analogy would be to say that my dog is the same as a picture of my dog (even though we say “that’s my dog” when we look at a picture of my dog).
It looks as though, rather than finding a fault in my reasoning, you’ve just found a conclusion that you don’t like. That equation, 9(.333…) = 3, is the result of subtracting this equation:
.333… = 3/10 + 3/100 +3/100 …
from this equation:
10 (.333…) = 3 + 3/10 + 3/100 + 3/1000 …
So it can’t be that the equation is faulty on its own. Either one of the previous equations must be incorrect, or the operation I performed on them was performed incorrectly. Which was it?
He didn’t multiply by nine. The only multiplication that took place was the first multiplication by 10 and he only completed the operation on the right hand side. At the end, he divided both sides by 9 to get 0.333… =3/9
That is deceptive, but not false. The standard means for representation is lacking, thus leading to a deception.
That is exactly the issue.
What you have is:
[10.000… :0R] * [0.333… :3R] = [3.333… :30R]
Those are all of the same cardinality/size. But realize that you have stated that you multiplied EVERY element of the first series by 10. And that means EVERY element, no matter how infinite the list is. To maintain the same cardinality, you cannot have any added elements. And that means that the list of partial multiples will display that EVERY element is 10 times larger. And that means at the end of EVERY member of the infinite partial multiples list, you must have a place saver “0” that came from the multiple of 10 (just like you do with ALL arithmetics).
0.3 → 3.0
0.03 → 0.30
0.003 → 0.030
.
.
.
[0.000… :3R] → [0.000… :30R] EVERY element must have a zero place holder at the right end, else you did not multiply every element by 10.
That should be pretty obvious.
And that was the FAULT in your reasoning and the shortcoming of the standard method of representing any infinite series of digits.
This is using hyperreals, which it seems you must to make your case. So, fair enough, if we use non-standard mathematical systems, we get a different result.
You had an infinite set and then multiplied it times 10. What did you expect?
And it doesn’t have to be hyperreals.
You had an infinite set of numbers then increased each by a factor of 10. So you still have an the infinite set of numbers. They are merely a little larger. But being larger, you must list them that way and thus maintain that “30” as the last number in the series. And of course, if you do that, when you add them all back together, you will still have that 30 at the extreme of the infinite set.
If EVERY member of an infinite set has a “right end”, then the most extreme member also has a “right end”.
You had an infinite set. EVERY member of that set had to have a “0” as its right digit because you multiplied every member by 10.
You don’t throw away place holders when you add them all back together.
And if you count only the right side of the decimal, you still have the same quantity of digits as you started with … as long as you count that last “30” as two digits, else you have a lesser infinity than you started with (which would constitute another Fault).
There’s no difference between 1.0 and 1.00. As I argued earlier, there’s an implied infinite string of zeros at the end of every real number that terminates.
If that were true then that would confirm that 1.0 = .999… since the difference between them is 0.000… with ‘no end to be obtained’. In order for the two numbers to be different, you’d have to propose that there is a ‘1’ somewhere out there at the end of all those zeros, and you just said that in fact there is not.
