Obections to Cantor's Theory (Wikipedia article)
in [Logic]
|
Prev: Derivations
Next: Simple yet Profound Metatheorem
From: Tony Orlow on 26 Jul 2005 13:32 malbrain(a)yahoo.com said: > stephen(a)nomail.com wrote: > > In sci.math malbrain(a)yahoo.com wrote: > > > stephen(a)nomail.com wrote: > > >> In sci.math malbrain(a)yahoo.com wrote: > > >> > Barb Knox wrote: > > >> >> In article <1122338688.718048.162860(a)g47g2000cwa.googlegroups.com>, > > >> >> malbrain(a)yahoo.com wrote: > > >> >> > > >> >> >Barb Knox wrote: > > >> >> >> In article <MPG.1d4ecd45545679a8989f6b(a)newsstand.cit.cornell.edu>, > > >> >> >> Tony Orlow (aeo6) <aeo6(a)cornell.edu> wrote: > > >> >> >> [snip] > > >> >> >> > > >> >> >> >keep in mind that > > >> >> >> >inductive proof IS an infinite loop, so that incrementing in the loop > > >> >> >> >creates > > >> >> >> >infinite values, and the quality of finiteness is not maintained over those > > >> >> >> >infinite iterations of the loop. > > >> >> >> > > >> >> >> Using your computational view, consider the following infinite loop > > >> >> >> (using some unbounded-precision arithmetic system similar to > > >> >> >> java.math.BigInteger): > > >> >> >> > > >> >> >> for (i = 0; ; i++) { > > >> >> >> println(i); > > >> >> >> } > > >> >> >> > > >> >> >> Now, although this is an INFINITE loop, every value printed will be > > >> >> >> FINITE. Right? > > >> >> > > > >> >> >Not so fast. The behaviour of incrementing i after it reaches INT_MAX > > >> >> >is undefined. > > >> >> > > >> >> Not so fast yourself. You missed the part about "unbounded-precision > > >> >> arithmetic system", which has no max. > > >> > > >> > Sorry, but the C standard admits no such system. INT_MAX must be > > >> > declared by the implementation. There is no room for exceptions. karl > > >> > m > > >> > > >> Why are you talking about C? > > > > > Because C is "better" defined than java, and the example is written in > > > C. karl m > > > > The example is not written in C. It is perfectly legal > > Java code, and C++ code, and C# code, and Javascript. > > Given that 'println' is not a standard C function, but > > it is a standard Java function, and the author identified > > the example as Java, it is pretty clear the example was written > > in Java. > > I really don't want to get into a discussion of why the C standard > doesn't allow EXCEPTIONS when considering the infinite. Perhaps later > this afternoon the sky will open up a little. karl m > > In any case, sure, the program will spit out finite numbers, snce it is a finite machine running in finite time. If the machine had infinite capacity and infinite funtime, it could conceivably produce infinite results. -- Smiles, Tony
From: malbrain on 26 Jul 2005 13:32 Randy Poe wrote: > Tony Orlow (aeo6) wrote: > > Well, if this is how mathematicians feel about their study, and claim it has no > > connection to reality, then Cantorian set theorists really have no reason to > > claim that anything they say is more correct than any competing claims. > > As usual, you are confused. Your arguments deal with conclusions > which you draw FROM THE SAME AXIOMS as the competing, mainstream > theorems you denigrate. Ok. Perhaps you might give us the pre-set-theory version of the axiom of induction. I presume it didn't just spring-up from nothing. > Mathematicians have every right to say that theorems deduced > from a given set of axioms by rigorous logic are more > correct UNDER THOSE AXIOMS than a competing, contradicting > set of conclusions someone claims arise UNDER THE SAME > AXIOMS. >From Webster's 1913 on-line dictionary: Cor*rect" (k?r-r?kt"), a. [L. correctus, p. p. of corrigere to make straight, to correct; cor- + regere to lead straight: cf. F. correct. See Regular, Right, and cf. Escort.] Set right, or made straight; hence, conformable to truth, rectitude, or propriety, or to a just standard; not faulty or imperfect; free from error; as, correct behavior; correct views It would seem that correct stems from Euclid's axioms. karl m
From: Randy Poe on 26 Jul 2005 13:43 malbrain(a)yahoo.com wrote: > David Kastrup wrote: > > Of course not. But the basis for choosing an axiom is irrelevant to > > the application of the axiom. And this axiom was chosen exactly in a > > manner that does not require recursive application. > > When working a proof one chooses one's axioms based on the desired > result. How can you say that the choice is irrelevant to the > application? Eh? Can you give an example that you think illustrates this "choosing one's axioms based on the desired result"? Do you think different number theories decide which of the Peano axioms to accept and which not, or add additional axioms of their own, based on a "desired result"? If you want to make a contribution to the same theory that everybody else is working on, you start from the same axioms. If you choose different axioms, you aren't working on the same system. - Randy
From: malbrain on 26 Jul 2005 13:47 Randy Poe wrote: > malbrain(a)yahoo.com wrote: > > David Kastrup wrote: > > > Of course not. But the basis for choosing an axiom is irrelevant to > > > the application of the axiom. And this axiom was chosen exactly in a > > > manner that does not require recursive application. > > > > When working a proof one chooses one's axioms based on the desired > > result. How can you say that the choice is irrelevant to the > > application? > > Eh? > > Can you give an example that you think illustrates this > "choosing one's axioms based on the desired result"? Do > you think different number theories decide which of the > Peano axioms to accept and which not, or add additional > axioms of their own, based on a "desired result"? Perhaps terminology is misleading us. I'm talking about applying axioms in a proof, and you seem to be talking about including them into the system in the first place. That's why we're asking for the history of the axiom of infinity v. axiom of induction. > If you want to make a contribution to the same theory > that everybody else is working on, you start from the > same axioms. If you choose different axioms, you aren't > working on the same system. We're discussing the system of natural numbers. karl m
From: malbrain on 26 Jul 2005 13:51
Tony Orlow (aeo6) wrote: > malbrain(a)yahoo.com said: > > stephen(a)nomail.com wrote: > > > In sci.math malbrain(a)yahoo.com wrote: > > > > stephen(a)nomail.com wrote: > > > >> In sci.math malbrain(a)yahoo.com wrote: > > > >> > Barb Knox wrote: > > > >> >> In article <1122338688.718048.162860(a)g47g2000cwa.googlegroups.com>, > > > >> >> malbrain(a)yahoo.com wrote: > > > >> >> > > > >> >> >Barb Knox wrote: > > > >> >> >> In article <MPG.1d4ecd45545679a8989f6b(a)newsstand.cit.cornell.edu>, > > > >> >> >> Tony Orlow (aeo6) <aeo6(a)cornell.edu> wrote: > > > >> >> >> [snip] > > > >> >> >> > > > >> >> >> >keep in mind that > > > >> >> >> >inductive proof IS an infinite loop, so that incrementing in the loop > > > >> >> >> >creates > > > >> >> >> >infinite values, and the quality of finiteness is not maintained over those > > > >> >> >> >infinite iterations of the loop. > > > >> >> >> > > > >> >> >> Using your computational view, consider the following infinite loop > > > >> >> >> (using some unbounded-precision arithmetic system similar to > > > >> >> >> java.math.BigInteger): > > > >> >> >> > > > >> >> >> for (i = 0; ; i++) { > > > >> >> >> println(i); > > > >> >> >> } > > > >> >> >> > > > >> >> >> Now, although this is an INFINITE loop, every value printed will be > > > >> >> >> FINITE. Right? > > > >> >> > > > > >> >> >Not so fast. The behaviour of incrementing i after it reaches INT_MAX > > > >> >> >is undefined. > > > >> >> > > > >> >> Not so fast yourself. You missed the part about "unbounded-precision > > > >> >> arithmetic system", which has no max. > > > >> > > > >> > Sorry, but the C standard admits no such system. INT_MAX must be > > > >> > declared by the implementation. There is no room for exceptions. karl > > > >> > m > > > >> > > > >> Why are you talking about C? > > > > > > > Because C is "better" defined than java, and the example is written in > > > > C. karl m > > > > > > The example is not written in C. It is perfectly legal > > > Java code, and C++ code, and C# code, and Javascript. > > > Given that 'println' is not a standard C function, but > > > it is a standard Java function, and the author identified > > > the example as Java, it is pretty clear the example was written > > > in Java. > > > > I really don't want to get into a discussion of why the C standard > > doesn't allow EXCEPTIONS when considering the infinite. Perhaps later > > this afternoon the sky will open up a little. karl m > > > > > In any case, sure, the program will spit out finite numbers, snce it is a > finite machine running in finite time. If the machine had infinite capacity and > infinite funtime, it could conceivably produce infinite results. I think you mean that the machine has finite runtime. That's what the OPERATING SYSTEM enforces. My java-virtual-machines strike the program dead with a BOLT OF LIGHTNING when it runs amok. karl m |