Obections to Cantor's Theory (Wikipedia article)
in [Logic]
|
Prev: Derivations
Next: Simple yet Profound Metatheorem
From: stephen on 25 Jul 2005 23:37 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 <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. >> >> There is no INT_MAX for an unbounded-precision arithmetic system. > The C language is defined by the C standard, as defined by ISO. There > are no "unbounded" standard types in the C language. karl m Why are you talking about C? Do you bother to read the posts you resond to? To quote: >> >> Using your computational view, consider the following infinite loop >> >> (using some unbounded-precision arithmetic system similar to >> >> java.math.BigInteger): No mention of C. There is a specific mention of an unbounded-precision arithmetic system, an in such systems MAX_INT is not defined. Stephen
From: stephen on 25 Jul 2005 23:38 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? Stephen
From: imaginatorium on 26 Jul 2005 00:00 Virgil wrote: > In article <MPG.1d4f082a49cdb89d989f7b(a)newsstand.cit.cornell.edu>, > Tony Orlow (aeo6) <aeo6(a)cornell.edu> wrote: > > > Virgil said: > > > > But there is no 1-1 correspondence between naturals and INFINITE > > > bit strings (only with finite bit strings). This is just another > > > instance of that same delusion that TO has that there exist > > > naturals with more than finitely many naturals as predecessors. > > > > > If they have all 1's in finite positions, then there is indeed a > > bijection between infinite bit strings and finite naturals. > > Not in any standard representation, in which the leading digit of an > n-ary representation of a natural must be non-zero. Hmm, Tony's statement is pretty woolly, but perhaps he means: "If they have 1's only in finite positions, then there is indeed a bijection between infinite bit strings and finite naturals." which seems to be true. Roughly speaking then, the Tonats turn out to be the 2-adics, and our disagreement is that we define the pofnats as a (countable) subset of the (uncountable) Tonats; Tony simply cannot stomach our definition, for reasons to do with his fallacious demonstrations from "information theory", so claims that somehow the pofnats are indeterminate. If we could only agree to change "indeterminate" to "beyond Tony's understanding", we might be there - total agreement. Brian Chandler http://imaginatorium.org
From: malbrain on 26 Jul 2005 00:09 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
From: Email me at CS not Boole on 26 Jul 2005 01:16
In article <1122269959.094056.105880(a)o13g2000cwo.googlegroups.com>, Jiri Lebl <jirka(a)5z.com> wrote: >Vaughan Pratt wrote: >> Daryl McCullough wrote: >> > Give an example of a calculation in physics in which using modern >> > ("Cantorian") mathematics gives you the wrong answer, and using >> > some other kind of mathematics gives you the right answer. >> >> That's pretty easy, isn't it? The Dirac delta function pervades >> physics, but if you used "Cantorian mathematics", which defines a >> function as a set of ordered pairs, you'd get either the wrong answer, >> an overflow error of some kind, or a type check error. > > [snip] >Not even Dirac would call the "delta function" a set theoretic >BTW from the formulation of your answer I assume you're a programmer >and not a mathematician. I'm a dog, welcome to the Internet. I think you're overlooking the context: DMcC had asked for "an example of a calculation in physics"..., which my answer took literally. If you were to take an algorithm for some discrete situation where the Kronecker delta worked just fine and mindlessly generalize it to the continuous case including replacing Kronecker by Dirac, you may well find yourself dividing by zero in the course of determining the one nonzero value of the Dirac delta function, which should result in some sort of error either at compile time or run time. In fact one could say that the basic problem with generalizing Kronecker to Dirac is that the (ordered) field of reals is an Archimedean field. In any non-Archimedean ordered field such as Robinson's (via ultrafilters), Conway's (surreal numbers), Bell's (an ordered ring extending the reals with nilpotent infinitesimals), etc. you could take the spike in the Dirac delta function to be infinitesimally wide and of height the reciprocal of its width (scaled as necessary). That way Dirac delta would be a function on the (nonstandard) reals and the above "mindless generalization" might actually work. (This leaves open the question of how to make the calculation effective, which may require some ingenuity but may well be feasible nonetheless.) Anyone care to comment on the relative efficacy of the distribution approach vs. basing the Dirac delta function on non-Archimedean fields? Vaughan Pratt -- Don't contact me at pratt(a)boole.stanford.edu, substitute cs for boole instead. |