Page 1 of 46 12311 ... LastLast
Results 1 to 10 of 456

Thread:
Sketch of a Disproof of Rice's Theorem

  1. #1
    Peter Olcott Guest

    Default Sketch of a Disproof of Rice's Theorem

    Continuation of "Pathological Self-Reference and the Halting Problem"

    Paraphrase from page 237 of Dexter Kozen's 1997 Automata and
    Computability His example proves that a TM that accepts the empty string
    is undecidable. Basically I only translated his English prose into the
    AnyString() pseudo-code provided below:

    My adaptation shows that deciding the decidability of a TM that accepts
    the empty string is decidable.

    // if t(m) halts
    // Accept <sigma>*
    // if t(m) does not halt
    // Accept NULL (Empty Set)
    Boolean AnyString()
    {
    TM m; // Turing Machine hard-wired into finite-control
    String x; // Input data hard-wired into finite-control
    m(x);
    return true;
    }

    // This function works correctly for all input that is decidable:
    // 1) returns true where tm halts on input. (halts in accept state)
    // 2) returns false where tm does not halt on input. (halts in reject state)
    // 3) loops on undecidable input.
    // function prototype
    Boolean Halts(String tm, String input);

    // function prototype
    Boolean DecidabilityDecider(String tm, String input);

    // function invocation
    DecidabilityDecider(AnyString, "");

    // pseudo-code of above function invocation

    if (Decidable(Halts, m, x))
    if (Halts(m,x))
    return true;
    else
    return false;
    else
    return false;

    Hypothesis:
    1) For the set of possible input strings to the universal set of Turing
    Machines there exists no way to show that decidability is undecidable.

    2) Reduction of DecidabilityDecider(String tm, String input) to the
    Halting Problem is not possible.


  2. #2
    Ben Bacarisse Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    Peter Olcott < - > writes:

    > Continuation of "Pathological Self-Reference and the Halting Problem"


    Much could be said of this but here is, to my mind, the key issue:

    <snip>
    > // This function works correctly for all input that is decidable:
    > // 1) returns true where tm halts on input. (halts in accept state)
    > // 2) returns false where tm does not halt on input. (halts in reject state)
    > // 3) loops on undecidable input.
    > // function prototype
    > Boolean Halts(String tm, String input);


    You have not said what "decidable" means here. I can't simply use the
    standard meaning because decidability is a property of sets and not of
    individual cases.

    If you mean "This function works correctly for all input cases that have
    a correct true/false answer" then no such machine or function exists.

    But in recent postings you been using another meaning. Your magical
    DecidabilityDecider had the task of spotting the cases where the Halts
    machine got the answer wrong. Using that meaning, Halts can be any
    machine at all and the "undecidable inputs" are just the ones it gets
    wrong. You've rejected this interpretation of what you mean.

    So we are back to the first two of Patricia's questions: what is this
    "bug-free" Halts function, and can you prove that such a thing exists?

    <snip>
    --
    Ben.

  3. #3
    Peter Olcott Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
    > Peter Olcott< - > writes:
    >
    >> Continuation of "Pathological Self-Reference and the Halting Problem"

    > Much could be said of this but here is, to my mind, the key issue:
    >
    > <snip>
    >> // This function works correctly for all input that is decidable:
    >> // 1) returns true where tm halts on input. (halts in accept state)
    >> // 2) returns false where tm does not halt on input. (halts in reject state)
    >> // 3) loops on undecidable input.
    >> // function prototype
    >> Boolean Halts(String tm, String input);

    > You have not said what "decidable" means here. I can't simply use the
    > standard meaning because decidability is a property of sets and not of
    > individual cases.


    The set of elements of <sigma>* that Halts() halts in its accept state T
    The set of elements of <sigma>* that Halts() halts in its reject state F
    (T <union> F) derives the set named Decidable

    > If you mean "This function works correctly for all input cases that have
    > a correct true/false answer" then no such machine or function exists.

    It you payed better attention you would have seen that I already
    specified the third alternative of undecidable inputs.
    >
    > But in recent postings you been using another meaning. Your magical
    > DecidabilityDecider had the task of spotting the cases where the Halts
    > machine got the answer wrong. Using that meaning, Halts can be any


    I am uncomfortable with calling a failure to respond a wrong answer.
    Within the conventional meaning of the term {wrong answer} and the
    conventional meaning of the term {failure to respond} calling a {failure
    to respond} a {wrong answer} is a lie. How about we just call these
    undecidable cases instead.

    > machine at all and the "undecidable inputs" are just the ones it gets
    > wrong. You've rejected this interpretation of what you mean.
    >
    > So we are back to the first two of Patricia's questions: what is this
    > "bug-free" Halts function, and can you prove that such a thing exists?
    >
    > <snip>


    Once the undecidable inputs are screened out there is nothing in
    computing theory that says that the remaining inputs can not always be
    correctly decided.

  4. #4
    Peter Olcott Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
    > Peter Olcott< - > writes:
    >
    >> > Continuation of "Pathological Self-Reference and the Halting Problem"

    > Much could be said of this but here is, to my mind, the key issue:
    >
    > <snip>
    >> > // This function works correctly for all input that is decidable:
    >> > // 1) returns true where tm halts on input. (halts in accept state)
    >> > // 2) returns false where tm does not halt on input. (halts in reject state)
    >> > // 3) loops on undecidable input.
    >> > // function prototype
    >> > Boolean Halts(String tm, String input);

    > You have not said what "decidable" means here. I can't simply use the
    > standard meaning because decidability is a property of sets and not of
    > individual cases.
    >
    > If you mean "This function works correctly for all input cases that have
    > a correct true/false answer" then no such machine or function exists.
    >
    > But in recent postings you been using another meaning. Your magical
    > DecidabilityDecider had the task of spotting the cases where the Halts
    > machine got the answer wrong. Using that meaning, Halts can be any
    > machine at all and the "undecidable inputs" are just the ones it gets
    > wrong. You've rejected this interpretation of what you mean.
    >
    > So we are back to the first two of Patricia's questions: what is this
    > "bug-free" Halts function, and can you prove that such a thing exists?
    >
    > <snip>
    > -- Ben.

    None of the theory of computation can show that a TM that has the
    purpose of detecting halting can not always have exactly three actions:
    (a) Correctly Halt in its accept state indicating that the input TM will
    halt on its input
    (b) Correctly Halt in its reject state indicating that the input TM will
    not halt on its input
    (c) Loop on undecidable cases.

    None of computing theory can show that a
    Boolean DecidabilityDecider(String tm, String input) can not always
    1) Correctly halt in its accept state indicating that its input TM is a
    decider for its input.
    2) Correctly halt in its reject state indicating that its input TM is a
    not decider for its input.

    //
    // A true halt decider for all valid input
    //
    if (DecidabilityDecider(Halts, tm, input))
    if (Halts, (tm, input) )
    return true;
    else
    return false;
    else
    Print("Input to Halts() is Semantically Mal-Formed!")

  5. #5
    Joshua Cranmer Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    On 3/27/2012 9:41 PM, Peter Olcott wrote:
    > None of the theory of computation can show that a TM that has the
    > purpose of detecting halting can not always have exactly three actions:
    > (a) Correctly Halt in its accept state indicating that the input TM will
    > halt on its input
    > (b) Correctly Halt in its reject state indicating that the input TM will
    > not halt on its input
    > (c) Loop on undecidable cases.


    You seem to be attempting what is conventionally the "halts, doesn't
    halt, I can't tell" model of the halting problem.

    > None of computing theory can show that a
    > Boolean DecidabilityDecider(String tm, String input) can not always
    > 1) Correctly halt in its accept state indicating that its input TM is a
    > decider for its input.
    > 2) Correctly halt in its reject state indicating that its input TM is a
    > not decider for its input.


    I'm not sure what you mean by this.
    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth

  6. #6
    Patricia Shanahan Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    On 3/27/2012 8:54 PM, Joshua Cranmer wrote:
    > On 3/27/2012 9:41 PM, Peter Olcott wrote:
    >> None of the theory of computation can show that a TM that has the
    >> purpose of detecting halting can not always have exactly three actions:
    >> (a) Correctly Halt in its accept state indicating that the input TM will
    >> halt on its input
    >> (b) Correctly Halt in its reject state indicating that the input TM will
    >> not halt on its input
    >> (c) Loop on undecidable cases.

    >
    > You seem to be attempting what is conventionally the "halts, doesn't
    > halt, I can't tell" model of the halting problem.


    I've tried suggesting that. I believe there are three differences:

    1. The three result model is useful.

    2. The three result model can be implemented.

    3. (and this may be the issue) The three result model does not in any
    way contradict halting undecidability, Rice's Theorem, or any other
    established result.

    Patricia

  7. #7
    Peter Olcott Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    On 3/27/2012 10:54 PM, Joshua Cranmer wrote:
    > On 3/27/2012 9:41 PM, Peter Olcott wrote:
    >> None of the theory of computation can show that a TM that has the
    >> purpose of detecting halting can not always have exactly three actions:
    >> (a) Correctly Halt in its accept state indicating that the input TM will
    >> halt on its input
    >> (b) Correctly Halt in its reject state indicating that the input TM will
    >> not halt on its input
    >> (c) Loop on undecidable cases.

    >
    > You seem to be attempting what is conventionally the "halts, doesn't
    > halt, I can't tell" model of the halting problem.
    >
    >> None of computing theory can show that a
    >> Boolean DecidabilityDecider(String tm, String input) can not always
    >> 1) Correctly halt in its accept state indicating that its input TM is a
    >> decider for its input.
    >> 2) Correctly halt in its reject state indicating that its input TM is a
    >> not decider for its input.

    >
    > I'm not sure what you mean by this.

    You have removed too much of the context for me to explain.

  8. #8
    Peter Olcott Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    On 3/27/2012 11:53 PM, Patricia Shanahan wrote:
    > On 3/27/2012 8:54 PM, Joshua Cranmer wrote:
    >> On 3/27/2012 9:41 PM, Peter Olcott wrote:
    >>> None of the theory of computation can show that a TM that has the
    >>> purpose of detecting halting can not always have exactly three actions:
    >>> (a) Correctly Halt in its accept state indicating that the input TM
    >>> will
    >>> halt on its input
    >>> (b) Correctly Halt in its reject state indicating that the input TM
    >>> will
    >>> not halt on its input
    >>> (c) Loop on undecidable cases.

    >>
    >> You seem to be attempting what is conventionally the "halts, doesn't
    >> halt, I can't tell" model of the halting problem.

    >
    > I've tried suggesting that. I believe there are three differences:
    >
    > 1. The three result model is useful.
    >
    > 2. The three result model can be implemented.
    >
    > 3. (and this may be the issue) The three result model does not in any
    > way contradict halting undecidability, Rice's Theorem, or any other
    > established result.
    >
    > Patricia

    It is the part that you removed that is significant.
    The non trivial property of decidability can always be decided for a
    recursively enumerable set.
    Because this property can always be decided a halt decider that decides
    all of its input can be made.

  9. #9
    Ben Bacarisse Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    Peter Olcott < - > writes:

    > On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
    >> Peter Olcott< - > writes:
    >>
    >>> Continuation of "Pathological Self-Reference and the Halting Problem"

    >> Much could be said of this but here is, to my mind, the key issue:
    >>
    >> <snip>
    >>> // This function works correctly for all input that is decidable:
    >>> // 1) returns true where tm halts on input. (halts in accept state)
    >>> // 2) returns false where tm does not halt on input. (halts in reject state)
    >>> // 3) loops on undecidable input.
    >>> // function prototype
    >>> Boolean Halts(String tm, String input);

    >> You have not said what "decidable" means here. I can't simply use the
    >> standard meaning because decidability is a property of sets and not of
    >> individual cases.

    >
    > The set of elements of <sigma>* that Halts() halts in its accept state T
    > The set of elements of <sigma>* that Halts() halts in its reject state F
    > (T <union> F) derives the set named Decidable


    An interesting change. Your last definition had the stipulation that
    the result had to be correct. Now, T union F is just the set of inputs
    on which Halts halts. The "decidability decider" must just decide the
    complement of that set. It is, in effect, a halt decider. Is this just
    a mistake, or have you changed your mind?

    >> If you mean "This function works correctly for all input cases that have
    >> a correct true/false answer" then no such machine or function exists.

    > It you payed better attention you would have seen that I already
    > specified the third alternative of undecidable inputs.


    Yes, but I am asking you to tell me the specification of Halts. You've
    rejected lots of examples because they are not "bug-free". I am very
    happy that you permit a set of inputs on which a putative halt decider
    may not halt, but you have to say what these cases are. With no
    restrictions, people will show reductions to halting by picking any
    Halts implementation they like.

    If you don't define "bug-free" there are simple machines for which
    neither T union F not its complement are decidable (and it's even easier
    with you new definition).

    >> But in recent postings you been using another meaning. Your magical
    >> DecidabilityDecider had the task of spotting the cases where the Halts
    >> machine got the answer wrong. Using that meaning, Halts can be any

    >
    > I am uncomfortable with calling a failure to respond a wrong
    > answer. Within the conventional meaning of the term {wrong answer} and
    > the conventional meaning of the term {failure to respond} calling a
    > {failure to respond} a {wrong answer} is a lie. How about we just call
    > these undecidable cases instead.


    Because they are decidable. All halting cases are decidable. I see
    no problem with "wrong". A putative decider for some set that does not
    halt on some input is wrong.

    >> machine at all and the "undecidable inputs" are just the ones it gets
    >> wrong. You've rejected this interpretation of what you mean.
    >>
    >> So we are back to the first two of Patricia's questions: what is this
    >> "bug-free" Halts function, and can you prove that such a thing exists?
    >>
    >> <snip>

    >
    > Once the undecidable inputs are screened out there is nothing in
    > computing theory that says that the remaining inputs can not always be
    > correctly decided.


    Yes, once the wrong numbers are screened out from this function

    Bool is_this_one_of_next_weeks_lottery_numbers(int n)

    there is nothing stopping me from being very rich. Stating a condition
    is not the same as showing that anything can meet it.

    --
    Ben.

  10. #10
    Peter Olcott Guest

    Default Re: Sketch of a Disproof of Rice's Theorem

    On 3/27/2012 10:54 PM, Joshua Cranmer wrote:
    > On 3/27/2012 9:41 PM, Peter Olcott wrote:
    >> None of the theory of computation can show that a TM that has the
    >> purpose of detecting halting can not always have exactly three actions:
    >> (a) Correctly Halt in its accept state indicating that the input TM will
    >> halt on its input
    >> (b) Correctly Halt in its reject state indicating that the input TM will
    >> not halt on its input
    >> (c) Loop on undecidable cases.

    >
    > You seem to be attempting what is conventionally the "halts, doesn't
    > halt, I can't tell" model of the halting problem.
    >
    >> None of computing theory can show that a
    >> Boolean DecidabilityDecider(String tm, String input) can not always
    >> 1) Correctly halt in its accept state indicating that its input TM is a
    >> decider for its input.
    >> 2) Correctly halt in its reject state indicating that its input TM is a
    >> not decider for its input.

    >
    > I'm not sure what you mean by this.

    You are still at the premise, please move on to the reasoning and its
    tentative conclusion.

Page 1 of 46 12311 ... LastLast

Similar Threads

  1. Replies: 1
    Last Post: 02-09-08, 03:15 PM
  2. Replies: 1
    Last Post: 02-09-08, 03:15 PM
  3. 3d sketch
    By sinan egilmez in forum comp.soft-sys.matlab
    Replies: 1
    Last Post: 27-08-08, 09:57 PM
  4. Orange Cheese Shop sketch
    By Steve Terry in forum uk.telecom.mobile
    Replies: 12
    Last Post: 26-08-08, 11:53 AM
  5. Rice warnt Russland
    By =?ISO-8859-15?Q?Bodo_L=FCders?= in forum de.soc.politik.misc
    Replies: 7
    Last Post: 14-08-08, 08:06 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •