Re: Olcott is cured of CrackPottery! (Halting Problem)

stephen_at_nomail.com
Date: 09/24/04 

Date: 24 Sep 2004 14:15:08 GMT

In comp.theory Charlie-Boo <chvol@aol.com> wrote:
: mtx014@linux.services.coventry.ac.uk (Robert Low) wrote
:> Charlie-Boo <chvol@aol.com> wrote:
:> >3. Incomplete or inconsistent specs.
:> >Come to think of it, the halting problem (and Godel's Incompleteness
:> >Theorem et. al.) is just a case of # 3. Ho hum.
:>
:> Except, of course, that it isn't. The specification "f is a
:> function which takes a TM description and an input tape, and
:> returns 1 if the TM halts on the input and 0 if it does
:> not" is neither incomplete nor inconsistent. It just happens
:> to be a function that cannot be computed by a TM. Proving
:> that is not so "ho hum" (though it's easy once you know the
:> answer, of course).

: A horse is a horse, of course, of course.
: http://www.bussongs.com/songs/a_horse_is_a_horse_mr_ed_tv_show.php
: That is, of course, unless . . . you're wrong. You miss subtleties of
: programming that only an experienced programmer (such as myself) would
: appreciate. Consider, for example, the following innocent looking
: rules proposed as "specs":

He is not missing any subtleties. There is no inconsistency in
the specification of the Halting function. A program X either halts
on an input Y or it does not. There is one and only one output
for each input.

: A. There is a routine for entering in the type of transaction.
: B. If the type of transaction is greater than 1, then the system
: writes "yes" and then halts.
: C. If the type of transaction is less than 3, then the system writes
: "no" and then halts.

This is nothing at all like the Halting problem. The specification
defines one and only one answer for each possible input.

Stephen

Relevant Pages