Re: Another stab at Cantor

In article <1158606529.450493.233240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<msadkins04@xxxxxxxxx> wrote:
Arturo Magidin wrote:
In article <1158602827.356674.135820@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<msadkins04@xxxxxxxxx> wrote:
Arturo Magidin wrote:
In article <1158598213.849000.127730@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<msadkins04@xxxxxxxxx> wrote:
Let R be the set of all infinite binary strings which eventually settle
into a repeating digit or pattern of digits. Let L1 be a well-defined
ordering of R. Let D1 be the diagonal number obtained from L1 by the
application of Cantor's diagonal process. D1 is not a member of R.

Let L2 be the list obtained by putting D1 at the head of L1 (that is,
by adding one to the index number of each member of L1, and placing D1
in the first position of the newly indexed list). Let D2 be the
diagonal number obtained from L2 by the application of Cantor's
diagonal process. D2 is not a member of R, and is not D1. Let L3 be
the list obtained by putting D2 at the head of L2.

Let L_Omega be the list defined by the totality of all possible steps
of this procedure.

There is no such thing. If you think of L_{n+1} as being obtained by
"adding a previous element" to L_n, then L_Omega is not a list: it
does not have a first element.

It does if you read it backwards. That is to say, it has a last
member, that being the first member of the list L1.

No, it does not have a last memeber either. The way you constructed
L_Omega was to start with L1, which has no last member, a pre-append
new numbers to this list. You end up with a mapping from the integers
to the set of all sequences of 0's and 1's. Such a mapping has no
first and no last element, just as there is no first and no last
integer.

Here is a modification meeting your objections:

The real objection is below; we have already told you how to fix this
particular technical issue.

Start with L1. Derive D1, and create L2 by putting it at the head of
L1 (first index position) in the manner previously described. L2 has a
first member (D1) followed by a second member (the first member of L1).
L2 has no last member. Now re-index L2 so that it has a last member,
but no first member -- that is, the omega_th member is D1, the
omega-1_th member is the first member of L1, and so forth. Call this
re-indexed version *L2. Now, from L2, generate D2. Add D2 to *L2 as
the new last member, bumping the others _down_ a notch, to derive *L3.

Sigh. You aren't doing anything new except confusing yourself.

You start with L1. The elements of L1 are indexed, say, by the
positive integers. Your L2 is indexed by the non-negative integers,
adding D1 as the 0th member of th elist. Your *L2 is indexed by the
non-positive integers, by considering the (-n)th element (n a positive
integer) of *L2 to be simply the nth element of L2. If you "add D2 to
*L2 as the new last member"), then your new list *L3 is simply indexed
by all integer less than or equal to 1; the elements indexed by
negative integers correspond to the elements of L1; the element
indexed by 0 corresponds to D1; and the element corresponding to the
index 1 is D2.

This is exactly the same as what you did before, except you are
taking the negative of the "old" indices.

The omega_th member of *L3 is D2; the omega-1_th member of *L3 is D1;

No. First, it is false that the "omega-th member of *L3 is D2". Your
*L3 is indexed by the integers ... -2, -1, 0, 1; it has no first
element and therefore it makes no sense to talk about "omega-th"
element. And if you think of the ordering as going "the other way"
(your old L3), then there is also no "omega-th" element because there
is no element of the list that does not correspond to an integer.


Second, there is no such thing as "omega-1-th member." You are
speaking nonsense.


the omega-2_th member of *L3 is the first member of L1; and so forth.

No. This is still nonsense.

Again, *L3 has a last member, but no first member.

Yes; which is why talking about "the omegath member" is a priori
nonsense, and nonsense in context too.


Now, complete the process to obtain *L_Omega. This has a last
member,

No, it does not have a last member. YOU AREN'T DOING ANYTHING
DIFFERENT FROM BEFORE. Before, each of your lists Ln had a first but
no last member, yet the "limit" L_Omega had no first element (even
though each intermediate term did).

This time your *L_n lists each have a last but no first element, and
yet the "limit" *L_Omega HAS NO LAST ELEMENT, any more than the old
L_omega had a first element. Your *L_Omega is indexed by the integers
(both positive, negative, and zero), and the k-th term of *L_Omega is
just the (-k)-th term of L_Omega. No first, and no last element, for
either one.

the omega_th member, which is the first member of L1 (as stated
above).

And it is just as much nonsense as it was above.

All of its other members, and their ordering, are well defined (as
stated above).

All the members and the ordering are indeed well defined. However, the
ORDERING IS NOT A WELL ORDERING. There is no first element.

Rest is nonsense.

False. Just because a process does not, a priori, exclude any
particular number does not mean that the process will necessarily
INCLUDE all numbers. Once again you are assuming that the process will
somehow produce "all" numbers to begin with, and this is what you are
supposed to PROVE, not to assume.

Well, the only way that the process can stop producing non-repeating
infinite binary strings (as diagonals) is either: (A) To "run out of"
such strings, which is to say to produce them all; or, (B) To run into
a limitation preventing some such strings from being produced.

Your process has a built-in stopping point: Omega. The
limitation that pervents all possible strings from being produced is
the fact that you are only producing countably many strings.

Since
no such limitation is inherent in the production, there is none.

This is an argument from ignorance. The fact that you cannot
understand what the inherent limitation is does not mean that no such
limitation occurs. You are quite simply wrong, as you have been from
the very beginning.


--
======================================================================
"It's not denial. I'm just very selective about
what I accept as reality."
--- Calvin ("Calvin and Hobbes" by Bill Watterson)
======================================================================

Arturo Magidin
magidin-at-member-ams-org

.

Relevant Pages

  • brad does the neener neener gambit
    ... a faculty member of the College System in Minnesota. ... He made up some lies that he had some reason ... And it was ALWAYS with the strong support of hundreds of other list members. ... ever got any support from other members of lists. ...
    (sci.psychology.psychotherapy)
  • Re: Distribution List Resolution with new Contact List
    ... ..AddMember method, and you double-click that member, it doesn't open their ... Outlook version number. ... Distribution Lists if you use existing Outlook functionality. ...
    (microsoft.public.outlook.program_vba)
  • Re: help on EZScriptomatic mod
    ... > If strmanagedBy "" Then ... > For Each Item in strmember ... but it pulls the group members and reports>> the member DN to the file.) ... >>>I was trying to just get a list of users for some the groups, since there>>>are bunch of groups with hundreds of users I was using EZADScriptomatic>>>but for the members properties page it lists all of the info the member>>>users, I just wanted to get the name of the users and that's it. ...
    (microsoft.public.windows.server.active_directory)
  • Re: SS Maurice & Lazarus
    ... I'm not a member, so it doesn't ... Guy Coutant de Saissaval matriculated Arms with Supporters, ... As far as lists of members of the Ven Order of St John concerned it is ...
    (rec.heraldry)
  • Re: Forward references and recursion
    ... It needs not only the name, but it need to know the declaration, to calculate ... A workaround, is to change the member as the pointer to the list, ... Probably you needs just a outside lists of plain data classes, ...
    (microsoft.public.vc.stl)