Re: countability of reals

From: |-|erc (h_at_r.c)
Date: 01/22/05 

Date: Sat, 22 Jan 2005 15:19:03 +1000

"Barb Knox" <see@sig.below> wrote in
> In article <35du73F4kcg3bU1@individual.net>, "|-|erc" <h@r.c> wrote:
>
> >"Barb Knox" <see@sig.below> wrote in > >>
> >> >> >> >Just stop thinking of omega as this
> >> >> >> >
> >> >> >> >0.00010101010101001001010110111010100
> >> >> >> >
> >> >> >> >and our 'knowledge' of omega is this
> >> >> >> >
> >> >> >> >0.000101X1X1X1XXXX100XXX011XXX101XX00
> >> >> >>
> >> >> >> That much I can agree with.
> >> >> >>
> >> >> >> >Just because we can inspect some programs and unveil the X
> >> >> >> >for a nice shiny 0 or 1, doesn't mean all those X's are 0's or 1's.
> >> >> >> >
> >> >> >> >This is Omega
> >> >> >> >0.0 0101 1 1 1 100 011 01 00
> >> >> >>
> >> >> >> What?? So you are claiming that those blank positions are NEITHER 0
> >> >> >> nor
> >> >> >> 1??
> >> >> >> That's bizarre even for you. A given TM+input either halts or it
> >> >> >> doesn't
> >> >> >> --
> >> >> >> what ELSE do you think it might do instead??
> >> >>
> >> >> [snip]
> >> >> >> (1) A given TM+input either eventually halts or it doesn't. There
> >> >> >> are
> >> >> >> no
> >> >> >
> >> >> >No. that is misleading. it doesn't eventually do anything. one of the
> >> >> >options is to eventually halt. the other is to neverventually continue.
> >> >>
> >> >> "neverventually continue"? I infer that you mean this as a synonym for
> >> >> "hang" (below).
> >> >>
> >> >> >> mystic "variables". The fact that we might not be able to *determine*
> >> >> >> whether a particular long-running TM+input will eventually halt is
> >> >> >> irrelevant. This yes-or-no-ness is essential to the very statement of
> >> >> >> the
> >> >> >> halting problem, which requires that the halts-or-not question be WELL
> >> >> >> DEFINED for all TM+input combinations.
> >> >> >>
> >> >> >> (**) If you disagree with this, then pray do tell us what a TM+input
> >> >> >> might
> >> >> >> do other than (A) halt (i.e. stop after some finite number of steps),
> >> >> >> or
> >> >> >> (B)
> >> >> >> not halt (i.e. not i.e. stop after any finite number of steps).
> >> >> >> Enquring
> >> >> >> minds need to know. What possible (C) alternative do you have in
> >> >> >> mind??
> >> >> >
> >> >> >hang
> >> >>
> >> >> For a TM, how does your "hang" differ from "not halt". In normal usage,
> >> >> a
> >> >> "hung" computation is in a non-halting loop.
> >> >
> >> >that's well hung, if its just hung its not all the way
> >>
> >> How about giving an actual answer. You're big on asking questions, but
> >> pretty small on giving answers it seems. So once again, for a TM, how does
> >> your "hang" differ from "not halt". I claim that it doesn't differ, and
> >> therfore your argument above is INVALID.
> >>
> >
> >You don't get the well hung part?
> >
> >After infinite time, a process halts or it doesn't
> >After finite time, a process halts or it hangs.
> >After a process hangs, it halts or it doesn't.
>
> So your "hangs" (which really should be called "is running") is only a
> temporary state of affairs: it either eventually halts (which BTW will be
> after some FINITE number of steps), or it doesn't. So it is still the case
> that a given TM+input will either eventually halt or it will not, right? So
> "1" and "0" DO cover all the possibilities.
>
close enough, but they are not observable possibilities.

Herc

Relevant Pages