A BLATENT FLAW in Cantor's diag proof
in [Math]
|
Prev: I'm gonna try this one more time CANTOR DISPROOF
Next: Reliability: Treating the Building & the Fault Line As One & the Same
From: William Hughes on 8 Jun 2010 13:14 On Jun 8, 2:02 pm, George Greene <gree...(a)email.unc.edu> wrote: > What the diagonalization argument is intended to show is simply that > the computable reals Are Not ALL the reals that there Are. I would prefer to say that the diagonalization argument shows that there is no list of real numbers. In this form it is true if you only allow computable numbers (thus only computable lists) or if you allow arbitrary numbers. - William Hughes
From: George Greene on 8 Jun 2010 13:16 On Jun 7, 11:17 pm, Tim Little <t...(a)little-possums.net> wrote: > On 2010-06-08, |-|ercules <radgray...(a)yahoo.com> wrote: > Delete "(infinite)", and your statement is correct. There is no such > thing as an infinite finite length though, so inserting the word > "infinite" there makes no sense. It makes a LITTLE bit of sense. What he MEANT was that there are infiniteLY MANY of these different finite lengths and that there is NO finite upper bound on them. The fact that this is not the same as what he said, is, well, typical. The two commonest things in the universe are hydrogen and stupidity. Maybe next we need to google "pons asinorum".
From: William Hughes on 8 Jun 2010 14:18 On Jun 8, 2:08 pm, George Greene <gree...(a)email.unc.edu> wrote: > Of course you can find a new sequence using diagonalization Yes, if you have a list of all real numbers then you can find a new sequence using diagonalization. If you have a list of all real numbers then you can't find a new sequence using diagonalization. If you have a list of all real numbers then there is an even prime greater than 2. - William Hughes > (well, not you personally, since it's infinite and you're not). > William Hughes doesn't know every damn thing. > Your actual problem is that they're NOT "all computed up to infinite > length". > They're all computed up to ALL FINITE lengths. > Hint: > Suppose you were trying to decimally approximate 1/3. > Suppose you had an infinite list OF FINITE sequences approximating it: > .3 > .33 > .333 > .3333 > .33333 > etc., i.e., the nth element on this list is a decimal point followed > by n 3's. > The list has denumerably (i.e. countably many) elements and EVERY > finite > approximation (or element or finite sequence) on the list occurs at a > KNOWN FINITE > position on the list; there is an element for every (positive) natural > n, and every natural > n has an element (namely, the string of a decimal point followed by n > 3's). > > Despite the fact that the decimal approximation for 1/3 is computed > UP TO EVERY FINITE length, on this list, THE INFINITE approximation > that is EXACTLY 1/3 IS *NOT* ON this list! > This list does NOT HAVE a LAST element! > This list does not have any infinite elements! > Or if you like, its elements are ALL infinite, but they just have all > 0's > after the initial finite segment of 3's. > > My point is, IF YOU HAVE A BRAIN, > it is EASY to see how something could be computed to all > finite lengths, yet NOT computed to ANY INfinite length. > > Clue: 1/3 IS NOT ON this list. > Never
From: Marshall on 8 Jun 2010 14:42 On Jun 8, 9:48 am, jbriggs444 <jbriggs...(a)gmail.com> wrote: > On Jun 8, 10:03 am, Marshall <marshall.spi...(a)gmail.com> wrote: > > On Jun 7, 8:40 pm, "|-|ercules" <radgray...(a)yahoo.com> wrote: > > > "Marshall" <marshall.spi...(a)gmail.com> wrote: > > > > On Jun 7, 7:51 pm, "|-|ercules" <radgray...(a)yahoo.com> wrote: > > > > >> I can compute the list of all computable reals. There's just some numbers that show > > > >> up blank. > > > > >> It's trivial to compute a list that covers every digit sequence to all (infinite) finite lengths. > > > > > How are you going to do that? > > > > > Write a program that first prints out an infinite sequence of zeroes, > > > > and then... > > > > > Oops! Already a problem! There is no "then" that comes after > > > > writing the zeroes, because the process of writing the > > > > zeroes will never finish. > > > > > Please show us this trivial program that computes every infinite digit > > > > sequence. > > > > Here you go: > > > > 1 000000 > > > 2 31415 > > > 3 2818 > > > 4 141 > > > 5 22 > > > 6 7 > > > > It's not finished yet! Next digit is the 7th 0 on the first number.. > > > At no point will this process ever produce even a single > > infinite string of digits. > > > Also I see no reason to think it's going to be anything vaguely > > comprehensive in the vertical direction either. > > With a serpentine traversal, for every position on the grid > there will be (for an algorithm that doesn't end up looping > quietly or halting) a time by which the algorithm will have > provided a digit for that position. > > In this sense, the algorithm specifies every digit on every > line. Sure. However, at no point will this process ever produce even a single infinite line of digits. When we talk about enumerating the natural numbers, for example: f(x) = { emit x; f(x+1); } f(0); then at no point will we be finished with all of them. However, for every natural number n, there is a point at which n will be emitted. At no point, ever, in the serpentine traversal, will we have even a single infinitely long line of digits. We never ever produce even one infinite digit sequence this way; we certainly cannot say that we are producing all of them. Marshall
From: jbriggs444 on 8 Jun 2010 15:33
On Jun 8, 2:42 pm, Marshall <marshall.spi...(a)gmail.com> wrote: > On Jun 8, 9:48 am, jbriggs444 <jbriggs...(a)gmail.com> wrote: > > > > > > > On Jun 8, 10:03 am, Marshall <marshall.spi...(a)gmail.com> wrote: > > > On Jun 7, 8:40 pm, "|-|ercules" <radgray...(a)yahoo.com> wrote: > > > > "Marshall" <marshall.spi...(a)gmail.com> wrote: > > > > > On Jun 7, 7:51 pm, "|-|ercules" <radgray...(a)yahoo.com> wrote: > > > > > >> I can compute the list of all computable reals. There's just some numbers that show > > > > >> up blank. > > > > > >> It's trivial to compute a list that covers every digit sequence to all (infinite) finite lengths. > > > > > > How are you going to do that? > > > > > > Write a program that first prints out an infinite sequence of zeroes, > > > > > and then... > > > > > > Oops! Already a problem! There is no "then" that comes after > > > > > writing the zeroes, because the process of writing the > > > > > zeroes will never finish. > > > > > > Please show us this trivial program that computes every infinite digit > > > > > sequence. > > > > > Here you go: > > > > > 1 000000 > > > > 2 31415 > > > > 3 2818 > > > > 4 141 > > > > 5 22 > > > > 6 7 > > > > > It's not finished yet! Next digit is the 7th 0 on the first number. > > > > At no point will this process ever produce even a single > > > infinite string of digits. > > > > Also I see no reason to think it's going to be anything vaguely > > > comprehensive in the vertical direction either. > > > With a serpentine traversal, for every position on the grid > > there will be (for an algorithm that doesn't end up looping > > quietly or halting) a time by which the algorithm will have > > provided a digit for that position. > > > In this sense, the algorithm specifies every digit on every > > line. > > Sure. However, at no point will this process ever produce > even a single infinite line of digits. I certainly agree that if we set this thing running and let it print on a hypothetical infinite roll of infinitely wide paper then we can never ever point to a line on the paper and say "there, look at it, the completed decimal expansion of line number 1". You are absolutely correct. In that sense, the algorithm never "produces" a single number. > > When we talk about enumerating the natural numbers, > for example: > > f(x) = { emit x; f(x+1); } > f(0); > > then at no point will we be finished with all of them. > However, for every natural number n, there is > a point at which n will be emitted. Agreed. > At no point, ever, in the serpentine traversal, will > we have even a single infinitely long line of digits. > We never ever produce even one infinite digit > sequence this way; we certainly cannot say that > we are producing all of them. I think you are stretching your point when you use the phraseology "are producing". At best the relevant point would be that we cannot say that we "have produced" all of them. However... One can evaluate a limit without computing the values of all of its terms. And one can characterize a completely populated infinite square grid of numbers in terms of a generating algorithm without actually having to run that algorithm and without requiring that the algorithm ever arrive at a halt state. But perhaps we are in vigorous agreement. |