f



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.

0
NoSpam271 (937)
3/28/2012 12:03:48 AM
comp.theory 5139 articles. 1 followers. marty.musatov (1143) is leader. Post Follow

454 Replies
1380 Views

Similar Articles

[PageSpeed] 33

Peter Olcott <NoSpam@OCR4Screen.com> 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.
0
ben.usenet (6790)
3/28/2012 1:56:31 AM
On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  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.
0
NoSpam271 (937)
3/28/2012 2:17:06 AM
On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  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!")
0
NoSpam271 (937)
3/28/2012 2:41:01 AM
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
0
Pidgeot18 (1520)
3/28/2012 3:54:19 AM
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
0
pats (3556)
3/28/2012 4:53:15 AM
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.
0
NoSpam271 (937)
3/28/2012 9:27:44 AM
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.
0
NoSpam271 (937)
3/28/2012 9:38:41 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  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.
0
ben.usenet (6790)
3/28/2012 10:29:23 AM
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.
0
NoSpam271 (937)
3/28/2012 10:53:26 PM
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
Right you are still looking at the premises, and have not yet examined 
the reasoning or its tentative conclusion.

Here is a preview of the reasoning:

Boolean HaltDecider(String tm, String input)
{
    if (Decidable(Halts, tm, input))
      if (Halts(tm, input))
        return true;
     else
        return false;
   else
     Print("The input is semantically incorrect!");
}
0
NoSpam271 (937)
3/28/2012 10:57:44 PM
On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
>>> >>  Peter Olcott<NoSpam@OCR4Screen.com>   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 did not yet get to the reasoning, you are still on the premises.
Premises are defined as true, and they are also self consistent.

0
NoSpam271 (937)
3/28/2012 11:00:58 PM
On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>> 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.
So when a halt decider halts in its accept state for all input tms that 
halt on their input and halts in its reject state for all tms that do 
not halt on their input, this is *incorrect* ?
0
NoSpam271 (937)
3/28/2012 11:03:00 PM
On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
> 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?
T <union> F is the inputs which Halts correctly decides.
The Decidability Decider matches these inputs so that it can screen out 
semantically invalid inputs.

if (Decidable(Halts, tm, input))
   if (Halts(tm, input))
     return true;
   else
      return false;
else
   Print("Semantically Invalid Input");
0
NoSpam271 (937)
3/28/2012 11:07:10 PM
On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
> 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).
Bug free means that:
1) Whenever Halts() halts in its accept state its input tm would halt on 
its input.
2) Whenever Halts() halts in its reject state its input tm would not 
halt on its input.
3) The only cases that Halts() does not halt are those cases that are 
undecidable for it.

Wasn't this entirely self-evidently logically entailed by the term 
"bug-free" ?
Is there anything at all that "bug-free" could possibly correctly mean 
besides the above specification?
0
NoSpam271 (937)
3/28/2012 11:12:31 PM
On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
> 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.
OK fine, then what time is it (yes or no) ?
a) It must be in hours and minutes because it is time.
b) It can't be in hours and minutes because a (yes or no) answer is 
specified.
c) If you don't answer this counts as a wrong answer.

This is the exact same situation as a Turing Machine that is provided 
input defined with Pathological Self-Reference.

0
NoSpam271 (937)
3/28/2012 11:16:35 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> >  On 3/27/2012 8:56 PM, Ben Bacarisse wrote:
>>>> >>  Peter Olcott<NoSpam@OCR4Screen.com>   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?

Any comment?  Are you changing the definition?
>>
>>>> >>  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 did not yet get to the reasoning, you are still on the premises.
> Premises are defined as true, and they are also self consistent.

That's not true.  You need to add some reading in logic to your list.

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 1:02:18 AM
On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>> 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.
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.
0
NoSpam271 (937)
3/29/2012 1:16:53 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>> 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.
> OK fine, then what time is it (yes or no) ?
> a) It must be in hours and minutes because it is time.
> b) It can't be in hours and minutes because a (yes or no) answer is
> specified.
> c) If you don't answer this counts as a wrong answer.
>
> This is the exact same situation as a Turing Machine that is provided
> input defined with Pathological Self-Reference.

No, it is not the same at all.  The question, "does TM t halt on input
i" has a correct true/false answer and entails no logical nonsense.
Nothing new here, of course, but since you keep making the same silly
analogy, the same reply is needed.

I am glad, though, that you agree with my term "wrong".  Let's go ahead
and rename

  Decidable(Halts, t, i)

as

  GetsItWrong(Halts, t, i)

(with a corresponding flip of the condition, of course) when Halts(t,i)
either does not terminate or is otherwise incorrect.  This is much less
confusing to people who know that all the cases are decidable, but that
certain machines (called Halts here) get some cases wrong.

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 1:17:25 AM
On 3/28/2012 5:53 PM, Peter Olcott wrote:
> 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.

If there's confusion in what your premise is, what hope have you that 
your reasoning or conclusion are clear and concise? To quote a book I 
have, "an error in the premise leads to an error in the conclusion."

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/29/2012 2:13:28 AM
On 3/28/2012 3:57 PM, Peter Olcott wrote:
> 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
> Right you are still looking at the premises, and have not yet examined
> the reasoning or its tentative conclusion.

Grant me an incorrect or sufficiently confused premise, and I could
prove anything. If I don't understand and agree with the premise, I
don't care what conclusions can be drawn from it.

Patricia
0
pats (3556)
3/29/2012 2:28:22 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>> 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).
> Bug free means that:
> 1) Whenever Halts() halts in its accept state its input tm would halt
> on its input.
> 2) Whenever Halts() halts in its reject state its input tm would not
> halt on its input.
> 3) The only cases that Halts() does not halt are those cases that are
> undecidable for it.
>
> Wasn't this entirely self-evidently logically entailed by the term
> "bug-free" ?

No, because the definition is based on another undefined term.  When
pressed to define Invalid_Input, you came up with a definition that, you
insist, only applies to "bug-free" Halts machines.  Now, when asked to
define these bug-free Halts machines, you make the definition depend on
an undefined concept of invalid input (now called undecidable cases).  I
say that this concept of undecidable cases is undefined because you've
claimed that your old definition of it (Invalid_Input) applied only the
class of machine you are currently defining!  You wouldn't push a
circular definition on us would you?

> Is there anything at all that "bug-free" could possibly correctly mean
> besides the above specification?

Yes, of course.  The natural meaning is of a correct halting decider.
Yours is of a partially correct one with an unspecified number of cases
that it is permitted to get wrong.  That's not the obvious meaning of
"bug-free".

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 2:34:59 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>> 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?
> T <union> F is the inputs which Halts correctly decides.

Right.  So it was just a mistake on your behalf.  I note that you
snipped your incorrect definition:

| 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

It would help if you sometimes just said "yes, that was a slip".

<snip>
-- 
Ben.
0
ben.usenet (6790)
3/29/2012 2:41:34 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>> 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.
> So when a halt decider halts in its accept state for all input tms
> that halt on their input and halts in its reject state for all tms
> that do not halt on their input, this is *incorrect* ?

No, it's just not what you said.

This is different to the old definition where the answer had to be
correct.  It just looked wrong, and you've agreed elsewhere that it was
just a slip.  I have to comment on what you write, not what I think you
meant to write.

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 2:46:52 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:
<snip>
> Boolean HaltDecider(String tm, String input)
> {
>    if (Decidable(Halts, tm, input))
>      if (Halts(tm, input))
>        return true;
>     else
>        return false;
>   else
>     Print("The input is semantically incorrect!");
> }

Stepping back a bit...

If I understand your other posts, this construct only applies to
"bug-free" Halts machines, and these have the property that they are
correct except that they don't halt on exactly those inputs that
Decidable(Halts, tm, input) rejects.  Assuming that all this can be
pinned down, and that the resulting objects exist, what will you have
achieved?  HaltDecider is just as bad at deciding halting as Halts is.

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 3:14:32 AM
On 3/28/2012 4:12 PM, Peter Olcott wrote:
....
> 3) The only cases that Halts() does not halt are those cases that are
> undecidable for it.

So what exactly does "undecidable for it" mean in this context? Remember
there is exactly one possible outcome for a given TM with a given input.

Suppose I have a three result {true, false, "don't know"} TM, M1, that
returns true and false for a subset of inputs for which it can provably
correctly evaluate whether they represent a TM computation that halts,
and returns "don't know" for all other inputs. That is something that
can be proved to exist.

I now construct a new TM, M2, that does the following:

Pass its input to M1.

If M1 returns true, return true.

If M1 returns false, return false.

If M1 returns "don't know" go into an infinite loop.

Is M2 bug-free? If not, why not?

Patricia
0
pats (3556)
3/29/2012 9:24:27 AM
On 3/28/2012 8:02 PM, Ben Bacarisse wrote:
>>>>>>> >>>>  >>    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 did not yet get to the reasoning, you are still on the premises.
>> >  Premises are defined as true, and they are also self consistent.
> That's not true.  You need to add some reading in logic to your list.
If all boats are cats, then boats say meaow.
0
NoSpam271 (937)
3/29/2012 10:07:59 AM
On 3/28/2012 8:02 PM, Ben Bacarisse wrote:
>>>>>>> >>>>  >>    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 did not yet get to the reasoning, you are still on the premises.
>> >  Premises are defined as true, and they are also self consistent.
> That's not true.  You need to add some reading in logic to your list.
Within the scope of determining the validity of deductive logical 
inference premises are defined as true, like a given in geometry.
0
NoSpam271 (937)
3/29/2012 10:09:57 AM
On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>> >>  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.
>> >  OK fine, then what time is it (yes or no) ?
>> >  a) It must be in hours and minutes because it is time.
>> >  b) It can't be in hours and minutes because a (yes or no) answer is
>> >  specified.
>> >  c) If you don't answer this counts as a wrong answer.
>> >
>> >  This is the exact same situation as a Turing Machine that is provided
>> >  input defined with Pathological Self-Reference.
> No, it is not the same at all.  The question, "does TM t halt on input
> i" has a correct true/false answer and entails no logical nonsense.
So still do not comprehend Pathological Self-Reference?
0
NoSpam271 (937)
3/29/2012 10:10:48 AM
On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
> I am glad, though, that you agree with my term "wrong".  Let's go ahead
> and rename
>
>    Decidable(Halts, t, i)
>
> as
>
>    GetsItWrong(Halts, t, i)
That would be backwards, that would be Undecidable().
GetsItCorrectly() would be more apt, yet I am going to stick with 
Decidable() and DecidabilityDecider().
0
NoSpam271 (937)
3/29/2012 10:12:36 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 8:02 PM, Ben Bacarisse wrote:
>>>>>>>> >>>>  >>    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 did not yet get to the reasoning, you are still on the premises.
>>> >  Premises are defined as true, and they are also self consistent.
>> That's not true.  You need to add some reading in logic to your list.
> Within the scope of determining the validity of deductive logical
> inference premises are defined as true, like a given in geometry.

I was talking about your claim that "premises [...] are also self
consistent".

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 11:50:36 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> >  On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>> >>  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.
>>> >  OK fine, then what time is it (yes or no) ?
>>> >  a) It must be in hours and minutes because it is time.
>>> >  b) It can't be in hours and minutes because a (yes or no) answer is
>>> >  specified.
>>> >  c) If you don't answer this counts as a wrong answer.
>>> >
>>> >  This is the exact same situation as a Turing Machine that is provided
>>> >  input defined with Pathological Self-Reference.
>> No, it is not the same at all.  The question, "does TM t halt on input
>> i" has a correct true/false answer and entails no logical nonsense.
> So still do not comprehend Pathological Self-Reference?

No, of course I don't.  You've never defined it.  You, on the other
hand, don't seem to understand what a decision problem is.  This is more
serious, because you've claimed to be taking talking about one from the
start.

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 12:02:59 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
>> I am glad, though, that you agree with my term "wrong".  Let's go ahead
>> and rename
>>
>>    Decidable(Halts, t, i)
>>
>> as
>>
>>    GetsItWrong(Halts, t, i)
> That would be backwards, that would be Undecidable().

Why did you clip the part where I said I was inverting the condition?
Was that because you like to look as if you are scoring points rather
than having a debate?

> GetsItCorrectly() would be more apt, yet I am going to stick with
> Decidable() and DecidabilityDecider().

Of course.  Despite being less than ideal, those terms carry the right
degree of obfuscation.  They hint at what you want to be true.

-- 
Ben.
0
ben.usenet (6790)
3/29/2012 12:09:30 PM
In comp.theory Peter Olcott <NoSpam@ocr4screen.com> wrote:
>
> Within the scope of determining the validity of deductive logical 
> inference premises are defined as true, like a given in geometry.

No, _axioms_ are defined to be true. _Premises_ can be true or
false. 

The logical argument "Socrates is a man and all men are immortal, thus
Socrates is immortal" consists of a conclusion, "Socrates is
immortal", one true premise "Socrates is a man" and one false premise
"All men are immortal."

The conclusion above is valid, in that it follows logically from the
premises. It's not _true_ though, because it is based on a flawed
premise.

-- 
Leif Roar Moldskred

0
leifm1143 (162)
3/29/2012 12:32:37 PM
Peter Olcott wrote:
> On 3/28/2012 8:02 PM, Ben Bacarisse wrote:
>>>>>>>> >>>>  >>    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 did not yet get to the reasoning, you are still on the premises.
>>> >  Premises are defined as true, and they are also self consistent.
>> That's not true.  You need to add some reading in logic to your list.
> Within the scope of determining the validity of deductive logical 
> inference premises are defined as true, like a given in geometry.

Whether I am interested in the results derived from a given set of
axioms depends on details such as whether the axioms appear reasonable
to me, and, in particular, whether they are likely to form a consistent
system.

Your earlier comments about a contradiction between your conclusions and
Rice's Theorem strongly suggests that adding your axioms to normal
set-theory axioms results in an inconsistent system.

I am glad to have the fact that your theories depend on adding your own
axioms made explicit.

Patricia
0
pats (3556)
3/29/2012 2:00:44 PM
In comp.theory Patricia Shanahan <pats@acm.org> wrote:
> 
> Whether I am interested in the results derived from a given set of
> axioms depends on details such as whether the axioms appear reasonable
> to me, and, in particular, whether they are likely to form a consistent
> system.

More to the point, you can't choose your own axioms when discussing
the Halting problem. You have to use the same system of mathematics as
everybody else.

-- 
Leif Roar Moldskred
0
leifm1143 (162)
3/29/2012 2:53:13 PM
On 3/28/2012 9:28 PM, Patricia Shanahan wrote:
> On 3/28/2012 3:57 PM, Peter Olcott wrote:
>> 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
>> Right you are still looking at the premises, and have not yet examined
>> the reasoning or its tentative conclusion.
>
> Grant me an incorrect or sufficiently confused premise, and I could
> prove anything. If I don't understand and agree with the premise, I
> don't care what conclusions can be drawn from it.
>
> Patricia
So we agree on this premise could you move past this now?
0
NoSpam271 (937)
3/29/2012 10:12:48 PM
On 3/28/2012 9:34 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>> 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).
>> Bug free means that:
>> 1) Whenever Halts() halts in its accept state its input tm would halt
>> on its input.
>> 2) Whenever Halts() halts in its reject state its input tm would not
>> halt on its input.
>> 3) The only cases that Halts() does not halt are those cases that are
>> undecidable for it.
>>
>> Wasn't this entirely self-evidently logically entailed by the term
>> "bug-free" ?
> No, because the definition is based on another undefined term.  When
> pressed to define Invalid_Input, you came up with a definition that, you
> insist, only applies to "bug-free" Halts machines.  Now, when asked to
> define these bug-free Halts machines, you make the definition depend on
> an undefined concept of invalid input (now called undecidable cases).  I
> say that this concept of undecidable cases is undefined because you've
> claimed that your old definition of it (Invalid_Input) applied only the
> class of machine you are currently defining!  You wouldn't push a
> circular definition on us would you?
>
>> Is there anything at all that "bug-free" could possibly correctly mean
>> besides the above specification?
> Yes, of course.  The natural meaning is of a correct halting decider.
> Yours is of a partially correct one with an unspecified number of cases
> that it is permitted to get wrong.  That's not the obvious meaning of
> "bug-free".
>
It does not get any cases wrong, all of these cases are screened out by 
the DecidabilityDecider() before they reach the HaltDecider().
0
NoSpam271 (937)
3/29/2012 10:14:44 PM
On 3/28/2012 9:41 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>> 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?
>> T<union>  F is the inputs which Halts correctly decides.
> Right.  So it was just a mistake on your behalf.  I note that you
> snipped your incorrect definition:
>
> | 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
>
> It would help if you sometimes just said "yes, that was a slip".
>
> <snip>

Feel free anytime. I made no mistake here.

1) The set of possible inputs to Halts() is defined as X;
2) The subset of X such that Halts(), halts in its accept state that 
mathematically maps to the input tm halting on its input T.
3) The subset of X such that Halts(), halts in its reject state that 
mathematically maps to the input tm not halting on its input F.
4) (T <union> F) The Decidable inputs to Halts() D.
5) X <minus> D the undecidable inputs to Halts() (no label needed 
because this is not referred to).


0
NoSpam271 (937)
3/29/2012 10:22:42 PM
On 3/28/2012 9:46 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>> 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.
>> So when a halt decider halts in its accept state for all input tms
>> that halt on their input and halts in its reject state for all tms
>> that do not halt on their input, this is *incorrect* ?
> No, it's just not what you said.
>
> This is different to the old definition where the answer had to be
> correct.  It just looked wrong, and you've agreed elsewhere that it was
> just a slip.  I have to comment on what you write, not what I think you
> meant to write.
>
I never made a mistake on this. I did not admit to a slip.
0
NoSpam271 (937)
3/29/2012 10:23:55 PM
On 3/28/2012 10:14 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
> <snip>
>> Boolean HaltDecider(String tm, String input)
>> {
>>     if (Decidable(Halts, tm, input))
>>       if (Halts(tm, input))
>>         return true;
>>      else
>>         return false;
>>    else
>>      Print("The input is semantically incorrect!");
>> }
> Stepping back a bit...
>
> If I understand your other posts, this construct only applies to
> "bug-free" Halts machines, and these have the property that they are
> correct except that they don't halt on exactly those inputs that
> Decidable(Halts, tm, input) rejects.  Assuming that all this can be
> pinned down, and that the resulting objects exist, what will you have
> achieved?  HaltDecider is just as bad at deciding halting as Halts is.
>
It only fails to decide those cases that were artificially contrived to 
make it fail, (or are otherwise erroneous) and since those cases derive 
incorrect input, they can be dismissed as incorrect input in the same 
way that a HaltDecider would dismiss an English Poem as neither halting 
nor failing to halt.
0
NoSpam271 (937)
3/29/2012 10:26:48 PM
On 3/29/2012 4:24 AM, Patricia Shanahan wrote:
> On 3/28/2012 4:12 PM, Peter Olcott wrote:
> ...
>> 3) The only cases that Halts() does not halt are those cases that are
>> undecidable for it.
>
> So what exactly does "undecidable for it" mean in this context? Remember
> there is exactly one possible outcome for a given TM with a given input.
>
> Suppose I have a three result {true, false, "don't know"} TM, M1, that

That is not 100% precisely literally correctly true. There is no actual 
logical entailment for a "don't know" case. You are getting sloppy with 
meanings here. Pathological Self-Reference does not derive any "don't 
know" cases, it derives "can't say" cases, big difference.

> returns true and false for a subset of inputs for which it can provably
> correctly evaluate whether they represent a TM computation that halts,
> and returns "don't know" for all other inputs. That is something that
> can be proved to exist.
>
> I now construct a new TM, M2, that does the following:
>
> Pass its input to M1.
>
> If M1 returns true, return true.
>
> If M1 returns false, return false.
>
> If M1 returns "don't know" go into an infinite loop.

That would always be rejected by the DecidabilityDecider() as incorrect 
input.  The DecidabilityDecider() can not be transformed into an 
instance of the Halting Problem, it simply correctly rejects this input.

>
> Is M2 bug-free? If not, why not?
>
> Patricia

0
NoSpam271 (937)
3/29/2012 10:32:09 PM
On 3/29/2012 7:02 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>
>>>>>   On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>>>>>   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.
>>>>>   OK fine, then what time is it (yes or no) ?
>>>>>   a) It must be in hours and minutes because it is time.
>>>>>   b) It can't be in hours and minutes because a (yes or no) answer is
>>>>>   specified.
>>>>>   c) If you don't answer this counts as a wrong answer.
>>>>>
>>>>>   This is the exact same situation as a Turing Machine that is provided
>>>>>   input defined with Pathological Self-Reference.
>>> No, it is not the same at all.  The question, "does TM t halt on input
>>> i" has a correct true/false answer and entails no logical nonsense.
>> So still do not comprehend Pathological Self-Reference?
> No, of course I don't.  You've never defined it.  You, on the other
> hand, don't seem to understand what a decision problem is.  This is more
> serious, because you've claimed to be taking talking about one from the
> start.
>

So how would you characterize the reason why the Halting Problem can not 
be solved?
It is a perfectly valid problem and computer science is just too plain 
stupid to solve it?
0
NoSpam271 (937)
3/29/2012 10:35:27 PM
On 3/29/2012 7:09 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
>>> >>  I am glad, though, that you agree with my term "wrong".  Let's go ahead
>>> >>  and rename
>>> >>
>>> >>      Decidable(Halts, t, i)
>>> >>
>>> >>  as
>>> >>
>>> >>      GetsItWrong(Halts, t, i)
>> >  That would be backwards, that would be Undecidable().
> Why did you clip the part where I said I was inverting the condition?
> Was that because you like to look as if you are scoring points rather
> than having a debate?
I have very little time in the morning and simply missed this part.

>> >  GetsItCorrectly() would be more apt, yet I am going to stick with
>> >  Decidable() and DecidabilityDecider().
> Of course.  Despite being less than ideal, those terms carry the right
> degree of obfuscation.  They hint at what you want to be true.
I have defined these sets with complete precision many times, you are 
just trying to be difficult.
0
NoSpam271 (937)
3/29/2012 10:37:26 PM
On 3/29/2012 7:32 AM, Leif Roar Moldskred wrote:
> In comp.theory Peter Olcott<NoSpam@ocr4screen.com>  wrote:
>> >
>> >  Within the scope of determining the validity of deductive logical
>> >  inference premises are defined as true, like a given in geometry.
> No,_axioms_  are defined to be true._Premises_  can be true or
> false.
Only when one examines the soundness of reasoning are the truth of the 
premises considered, when evaluating validity premises are always taken 
to be true.
0
NoSpam271 (937)
3/29/2012 10:39:38 PM
On 3/29/2012 9:00 AM, Patricia Shanahan wrote:
> Peter Olcott wrote:
>> On 3/28/2012 8:02 PM, Ben Bacarisse wrote:
>>>>>>>>> >>>> >>    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 did not yet get to the reasoning, you are still on the 
>>>> premises.
>>>> >  Premises are defined as true, and they are also self consistent.
>>> That's not true.  You need to add some reading in logic to your list.
>> Within the scope of determining the validity of deductive logical 
>> inference premises are defined as true, like a given in geometry.
>
> Whether I am interested in the results derived from a given set of
> axioms depends on details such as whether the axioms appear reasonable
> to me, and, in particular, whether they are likely to form a consistent
> system. 
We already agreed on the main premise, the three value halt decider.
It always correctly determines halting or failing to halt except in 
those cases where this is not possible.

The DecidabilityDecider() screens out these cases as incorrect input.

enum Boolean(true, false, neither);

Boolean HaltDecider(String tm, String input)
{
   if (Decidable(Halts, tm, input))
      if Halts(tm, input))
        return true;
     else
       return false;
    else
      return neither;  // meaning that the input is incorrect
}

0
NoSpam271 (937)
3/29/2012 10:46:41 PM
On 3/29/2012 9:53 AM, Leif Roar Moldskred wrote:
> In comp.theory Patricia Shanahan<pats@acm.org>  wrote:
>> Whether I am interested in the results derived from a given set of
>> axioms depends on details such as whether the axioms appear reasonable
>> to me, and, in particular, whether they are likely to form a consistent
>> system.
> More to the point, you can't choose your own axioms when discussing
> the Halting problem. You have to use the same system of mathematics as
> everybody else.
>

Ultimately the entire set of all of the truth of mathematics has been 
fully self-contained within tautologies that existed long before the 
beginning of time.
0
NoSpam271 (937)
3/29/2012 10:55:57 PM
On 3/29/2012 3:12 PM, Peter Olcott wrote:
> On 3/28/2012 9:28 PM, Patricia Shanahan wrote:
....
>> Grant me an incorrect or sufficiently confused premise, and I could
>> prove anything. If I don't understand and agree with the premise, I
>> don't care what conclusions can be drawn from it.
>>
>> Patricia
> So we agree on this premise could you move past this now?

In a sense. One of the few things keeping me in this thread was
curiosity as two whether the stated contradiction between your ideas and
Rice's Theorem was due to muddled thinking or extra axioms leading to an
inconsistent system.

Now I know that you are introducing your own axioms, I am reasonably
sure that inconsistent axioms are a factor.

Given inconsistent axioms, the quality of reasoning is irrelevant.

Bye,

Patricia
0
pats (3556)
3/29/2012 11:10:36 PM
On 3/29/2012 6:10 PM, Patricia Shanahan wrote:
> On 3/29/2012 3:12 PM, Peter Olcott wrote:
>> On 3/28/2012 9:28 PM, Patricia Shanahan wrote:
> ...
>>> Grant me an incorrect or sufficiently confused premise, and I could
>>> prove anything. If I don't understand and agree with the premise, I
>>> don't care what conclusions can be drawn from it.
>>>
>>> Patricia
>> So we agree on this premise could you move past this now?
>
> In a sense. One of the few things keeping me in this thread was
> curiosity as two whether the stated contradiction between your ideas and
> Rice's Theorem was due to muddled thinking or extra axioms leading to an
> inconsistent system. 

I am still working on better ways to express these ideas. To do this I 
am more deeply grounding myself within the conventional terminology and 
concepts of the theory of computation.

I think that I may have found a non-trivial property of a 
recursively-enumerable set that is decidable.

Since Rice's Theorem states that:
Every nontrivial property of a recursively-enumerable set is 
undecidable, my finding (if correct) would disprove Rice's Theorem.
0
NoSpam271 (937)
3/29/2012 11:16:13 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 9:34 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
<snip>
>>> Bug free means that:
>>> 1) Whenever Halts() halts in its accept state its input tm would halt
>>> on its input.
>>> 2) Whenever Halts() halts in its reject state its input tm would not
>>> halt on its input.
>>> 3) The only cases that Halts() does not halt are those cases that are
>>> undecidable for it.
<snip>
>>> Is there anything at all that "bug-free" could possibly correctly mean
>>> besides the above specification?
>> Yes, of course.  The natural meaning is of a correct halting decider.
>> Yours is of a partially correct one with an unspecified number of cases
>> that it is permitted to get wrong.  That's not the obvious meaning of
>> "bug-free".
>>
> It does not get any cases wrong, all of these cases are screened out
> by the DecidabilityDecider() before they reach the HaltDecider().

This is becoming absurd.  You can't even keep track of your own
definitions.  Your "bug-free" requirement was made of the machine whose
inputs are to be "screened out".

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 12:43:48 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 9:41 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>> 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?
>>> T<union>  F is the inputs which Halts correctly decides.
>> Right.  So it was just a mistake on your behalf.  I note that you
>> snipped your incorrect definition:
>>
>> | 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
>>
>> It would help if you sometimes just said "yes, that was a slip".
>>
>> <snip>
>
> Feel free anytime. I made no mistake here.
>
> 1) The set of possible inputs to Halts() is defined as X;
> 2) The subset of X such that Halts(), halts in its accept state that
> mathematically maps to the input tm halting on its input T.
> 3) The subset of X such that Halts(), halts in its reject state that
> mathematically maps to the input tm not halting on its input F.
> 4) (T <union> F) The Decidable inputs to Halts() D.
> 5) X <minus> D the undecidable inputs to Halts() (no label needed
> because this is not referred to).

You don't see that difference?  Of course you do.  You must do, because
you've added the crucial parts back using new words.

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 12:50:33 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/28/2012 10:14 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>> <snip>
>>> Boolean HaltDecider(String tm, String input)
>>> {
>>>     if (Decidable(Halts, tm, input))
>>>       if (Halts(tm, input))
>>>         return true;
>>>      else
>>>         return false;
>>>    else
>>>      Print("The input is semantically incorrect!");
>>> }
>> Stepping back a bit...
>>
>> If I understand your other posts, this construct only applies to
>> "bug-free" Halts machines, and these have the property that they are
>> correct except that they don't halt on exactly those inputs that
>> Decidable(Halts, tm, input) rejects.  Assuming that all this can be
>> pinned down, and that the resulting objects exist, what will you have
>> achieved?  HaltDecider is just as bad at deciding halting as Halts is.
>>
> It only fails to decide those cases that were artificially contrived
> to make it fail, (or are otherwise erroneous) and since those cases
> derive incorrect input, they can be dismissed as incorrect input in
> the same way that a HaltDecider would dismiss an English Poem as
> neither halting nor failing to halt.

<sigh> It's not the same at all.  Those "contrived" inputs represent
machine and input pairs that have correct true/false answers to the
question that a halting decider must answer.

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 1:10:40 AM
On 3/29/2012 5:22 PM, Peter Olcott wrote:
> On 3/28/2012 9:41 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com> writes:
>>
>>> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>> 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?
>>> T<union> F is the inputs which Halts correctly decides.
>> Right. So it was just a mistake on your behalf. I note that you
>> snipped your incorrect definition:
>>
>> | 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
>>
>> It would help if you sometimes just said "yes, that was a slip".
>>
>> <snip>
>
> Feel free anytime. I made no mistake here.

You seem to treat the two definitions in this post as exactly 
equivalent, but they are not. One definition is the set which of inputs 
for which a given Turing machine returns the same answer as the halting 
function, while the other is the set of inputs for which a given Turing 
machine halts on.

If you still don't believe that these two definitions are different, 
here's an easy test case. Suppose we implement Halts like so:
Halts(M, w) -> unconditionally accept.

Which of the following sets would you call "Decidable"?
A. All input pairs {M, w}
B. All input pairs {M, w} such that M halts when input with w fed as input.

Set A would correspond to the definition of T union F, while set B 
corresponds to the definition of the inputs that Halts correctly 
decides. These two sets are clearly not equivalent, so you are clearly 
giving two contradictory definitions here. Assuming that you did not 
intend a contradiction in your premise [1], you made a mistake.

[1] It's always possible that this is what you intended, but since a 
contradiction proves anything, it's completely tautological nonsense.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 1:24:09 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/29/2012 4:24 AM, Patricia Shanahan wrote:
>> On 3/28/2012 4:12 PM, Peter Olcott wrote:
>> ...
>>> 3) The only cases that Halts() does not halt are those cases that are
>>> undecidable for it.
>>
>> So what exactly does "undecidable for it" mean in this context? Remember
>> there is exactly one possible outcome for a given TM with a given input.
>>
>> Suppose I have a three result {true, false, "don't know"} TM, M1, that
>
> That is not 100% precisely literally correctly true. There is no
> actual logical entailment for a "don't know" case. You are getting
> sloppy with meanings here. Pathological Self-Reference does not derive
> any "don't know" cases, it derives "can't say" cases, big difference.

You must allow other people to state *their* premises.  In this case it
is perfectly fine to suppose such a machines exist -- they clearly do.
If you don't like the term "don't know", just assume that M1 returns
result from the set {true, false, banana}.

>> returns true and false for a subset of inputs for which it can provably
>> correctly evaluate whether they represent a TM computation that halts,
>> and returns "don't know" for all other inputs. That is something that
>> can be proved to exist.

"...and returns 'banana' for all other inputs."

>> I now construct a new TM, M2, that does the following:
>>
>> Pass its input to M1.
>>
>> If M1 returns true, return true.
>>
>> If M1 returns false, return false.
>>
>> If M1 returns "don't know" go into an infinite loop.

"If M1 returns 'banana' go into an infinite loop."

> That would always be rejected by the DecidabilityDecider() as
> incorrect input.  The DecidabilityDecider() can not be transformed
> into an instance of the Halting Problem, it simply correctly rejects
> this input.

Total nonsense.  There is no attempt here to reduce anything to halting,
and there is no "DecidabilityDecider" in sight here.  The question is
about whether a machine is or is not "bug-free".  It is just an attempt
to clarify this term that you've introduced.

>> Is M2 bug-free? If not, why not?

As with so many of Patricia's questions, it's a good one and I urge you
not to ignore it.

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 1:27:25 AM
On 3/29/2012 5:35 PM, Peter Olcott wrote:
> So how would you characterize the reason why the Halting Problem can not
> be solved?
> It is a perfectly valid problem and computer science is just too plain
> stupid to solve it?

Mathematics is simply not complete. That's one way. Another way is (this 
is very informal) to note that any sufficiently complex structure is 
ultimately finite, while general techniques are infinite in complexity, 
so it is impossible to build a structure which is totally 
impregnable--the fact that you can build a machine implies that you must 
be able to defeat it somehow. A better explanation of this can be found 
in the chapter on the record player in the book Godel, Escher, Bach.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 1:29:56 AM
On 3/29/2012 5:26 PM, Peter Olcott wrote:
> It only fails to decide those cases that were artificially contrived to
> make it fail, (or are otherwise erroneous) and since those cases derive
> incorrect input, they can be dismissed as incorrect input in the same
> way that a HaltDecider would dismiss an English Poem as neither halting
> nor failing to halt.

What defines an "artificially contrived" case? I'm guessing you intend 
to mean "unrealistic input", but, in many cases, artificially-crafted 
inputs are just as important to worry about as typical input. Note that 
nearly every security problem in modern computers arises from failures 
in artificially crafted cases: SQL injections, buffer overflows, etc. In 
a more practical sense, the fact that it is possible to craft instances 
that force quicksort to regress to O(n^2) time make it an unacceptable 
algorithm in many places.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 1:49:05 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/29/2012 7:02 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
>>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>>
>>>>>>   On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>>>>>>   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.
>>>>>>   OK fine, then what time is it (yes or no) ?
>>>>>>   a) It must be in hours and minutes because it is time.
>>>>>>   b) It can't be in hours and minutes because a (yes or no) answer is
>>>>>>   specified.
>>>>>>   c) If you don't answer this counts as a wrong answer.
>>>>>>
>>>>>>   This is the exact same situation as a Turing Machine that is provided
>>>>>>   input defined with Pathological Self-Reference.
>>>> No, it is not the same at all.  The question, "does TM t halt on input
>>>> i" has a correct true/false answer and entails no logical nonsense.
>>> So still do not comprehend Pathological Self-Reference?
>> No, of course I don't.  You've never defined it.  You, on the other
>> hand, don't seem to understand what a decision problem is.  This is more
>> serious, because you've claimed to be taking talking about one from the
>> start.
>>
>
> So how would you characterize the reason why the Halting Problem can
> not be solved?

There are several way to look at it.  It is natural that there must be
many functions that can't be computed by any Turing machine simply
because there are only countably many Turing machines, but there are
uncountably many functions from input strings to {true, false} (to pick
just an interesting subset of functions).

Why is halting, specifically, one of these?  The argument that proves
that halting is not decidable is also a diagonalisation argument,
exactly like Cantor's argument about the power set of N.  Because you've
stripped out the details of the encoding from all your arguments (and
because you've decided the result before you start) you haven't absorbed
the nature of the proof.  There aren't enough natural numbers to encode
a single machine that can decide halting.

> It is a perfectly valid problem and computer science is just too plain
> stupid to solve it?

Computer science has solved it, in that it is now a settled question.
It's only unsolved for people who want a different answer.


-- 
Ben.
0
ben.usenet (6790)
3/30/2012 1:51:37 AM
On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/28/2012 9:34 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
> <snip>
>>>> Bug free means that:
>>>> 1) Whenever Halts() halts in its accept state its input tm would halt
>>>> on its input.
>>>> 2) Whenever Halts() halts in its reject state its input tm would not
>>>> halt on its input.
>>>> 3) The only cases that Halts() does not halt are those cases that are
>>>> undecidable for it.
> <snip>
>>>> Is there anything at all that "bug-free" could possibly correctly mean
>>>> besides the above specification?
>>> Yes, of course.  The natural meaning is of a correct halting decider.
>>> Yours is of a partially correct one with an unspecified number of cases
>>> that it is permitted to get wrong.  That's not the obvious meaning of
>>> "bug-free".
>>>
>> It does not get any cases wrong, all of these cases are screened out
>> by the DecidabilityDecider() before they reach the HaltDecider().
> This is becoming absurd.  You can't even keep track of your own
> definitions.  Your "bug-free" requirement was made of the machine whose
> inputs are to be "screened out".
>
You are back to striving to be disagreeable again, I see.
0
NoSpam271 (937)
3/30/2012 3:16:13 AM
On 3/29/2012 7:50 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/28/2012 9:41 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>
>>>> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>>> 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?
>>>> T<union>   F is the inputs which Halts correctly decides.
>>> Right.  So it was just a mistake on your behalf.  I note that you
>>> snipped your incorrect definition:
>>>
>>> | 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
>>>
>>> It would help if you sometimes just said "yes, that was a slip".
>>>
>>> <snip>
>> Feel free anytime. I made no mistake here.
>>
>> 1) The set of possible inputs to Halts() is defined as X;
>> 2) The subset of X such that Halts(), halts in its accept state that
>> mathematically maps to the input tm halting on its input T.
>> 3) The subset of X such that Halts(), halts in its reject state that
>> mathematically maps to the input tm not halting on its input F.
>> 4) (T<union>  F) The Decidable inputs to Halts() D.
>> 5) X<minus>  D the undecidable inputs to Halts() (no label needed
>> because this is not referred to).
> You don't see that difference?  Of course you do.  You must do, because
> you've added the crucial parts back using new words.
>
There is no significant difference, what was not stated before was 
logically entailed, thus equivalent to being stated.
0
NoSpam271 (937)
3/30/2012 3:17:38 AM
On 3/29/2012 8:10 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/28/2012 10:14 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>> <snip>
>>>> Boolean HaltDecider(String tm, String input)
>>>> {
>>>>      if (Decidable(Halts, tm, input))
>>>>        if (Halts(tm, input))
>>>>          return true;
>>>>       else
>>>>          return false;
>>>>     else
>>>>       Print("The input is semantically incorrect!");
>>>> }
>>> Stepping back a bit...
>>>
>>> If I understand your other posts, this construct only applies to
>>> "bug-free" Halts machines, and these have the property that they are
>>> correct except that they don't halt on exactly those inputs that
>>> Decidable(Halts, tm, input) rejects.  Assuming that all this can be
>>> pinned down, and that the resulting objects exist, what will you have
>>> achieved?  HaltDecider is just as bad at deciding halting as Halts is.
>>>
>> It only fails to decide those cases that were artificially contrived
>> to make it fail, (or are otherwise erroneous) and since those cases
>> derive incorrect input, they can be dismissed as incorrect input in
>> the same way that a HaltDecider would dismiss an English Poem as
>> neither halting nor failing to halt.
> <sigh>  It's not the same at all.  Those "contrived" inputs represent
> machine and input pairs that have correct true/false answers to the
> question that a halting decider must answer.
>
You still did not answer my similar question:
What time is it (yes or no) ???
0
NoSpam271 (937)
3/30/2012 3:18:53 AM
On 3/29/2012 8:24 PM, Joshua Cranmer wrote:
> On 3/29/2012 5:22 PM, Peter Olcott wrote:
>> On 3/28/2012 9:41 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com> writes:
>>>
>>>> On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>>> 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?
>>>> T<union> F is the inputs which Halts correctly decides.
>>> Right. So it was just a mistake on your behalf. I note that you
>>> snipped your incorrect definition:
>>>
>>> | 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
>>>
>>> It would help if you sometimes just said "yes, that was a slip".
>>>
>>> <snip>
>>
>> Feel free anytime. I made no mistake here.
>
> You seem to treat the two definitions in this post as exactly 
> equivalent, but they are not. One definition is the set which of 
> inputs for which a given Turing machine returns the same answer as the 
> halting function, while the other is the set of inputs for which a 
> given Turing machine halts on. 

These are the three possible cases, they are all inclusive.
1) The halt decider halts in its accept state only when the input tm 
would halt on its input.
2) The halt decider halts in its reject state only when the input tm 
would not halt on its input.
3) The halt decider loops on its input in the all of the cases where it 
can not correctly halt in either its accept state or its reject state. 
It does not loop in any other cases.


0
NoSpam271 (937)
3/30/2012 3:25:25 AM
On 3/29/2012 8:29 PM, Joshua Cranmer wrote:
> On 3/29/2012 5:35 PM, Peter Olcott wrote:
>> So how would you characterize the reason why the Halting Problem can not
>> be solved?
>> It is a perfectly valid problem and computer science is just too plain
>> stupid to solve it?
>
> Mathematics is simply not complete.
Yeah that is what Godel incorrectly proposed.
0
NoSpam271 (937)
3/30/2012 3:31:41 AM
> > Mathematics is simply not complete.

On Mar 29, 11:31 pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> Yeah that is what Godel incorrectly proposed.

??

Are we being trolled?
0
greeneg9613 (188)
3/30/2012 3:42:01 AM
On 3/29/2012 10:25 PM, Peter Olcott wrote:
> On 3/29/2012 8:24 PM, Joshua Cranmer wrote:
>> You seem to treat the two definitions in this post as exactly
>> equivalent, but they are not. One definition is the set which of
>> inputs for which a given Turing machine returns the same answer as the
>> halting function, while the other is the set of inputs for which a
>> given Turing machine halts on.
>
> These are the three possible cases, they are all inclusive.

Could you answer my question? You're still being stubbornly unclear in 
your responses. Here it is again:

> Suppose we implement Halts like so:
> Halts(M, w) -> unconditionally accept.
>
> Which of the following sets would you call "Decidable"?
> A. All input pairs {M, w}
> B. All input pairs {M, w} such that M halts when input with w fed as input.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 4:48:32 AM
On 3/29/2012 10:16 PM, Peter Olcott wrote:
> On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
>> This is becoming absurd. You can't even keep track of your own
>> definitions. Your "bug-free" requirement was made of the machine whose
>> inputs are to be "screened out".
>>
> You are back to striving to be disagreeable again, I see.

Says the person who is giving multiple inconsistent definitions, has 
explicitly stated that he ignores long posts, and instructs his 
opponents to take his word on everything.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 4:52:37 AM
On 3/29/2012 10:31 PM, Peter Olcott wrote:
> On 3/29/2012 8:29 PM, Joshua Cranmer wrote:
>> On 3/29/2012 5:35 PM, Peter Olcott wrote:
>>> So how would you characterize the reason why the Halting Problem can not
>>> be solved?
>>> It is a perfectly valid problem and computer science is just too plain
>>> stupid to solve it?
>>
>> Mathematics is simply not complete.
> Yeah that is what Godel incorrectly proposed.

You don't even have to go so far as Godel: there must exist uncomputable 
functions since there are 2^Aleph_0 functions but only Aleph_1 programs, 
so it is not possible to construct a bijection between functions and 
programs which compute them.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 4:55:09 AM
On 3/29/2012 11:48 PM, Joshua Cranmer wrote:
> On 3/29/2012 10:25 PM, Peter Olcott wrote:
>> On 3/29/2012 8:24 PM, Joshua Cranmer wrote:
>>> You seem to treat the two definitions in this post as exactly
>>> equivalent, but they are not. One definition is the set which of
>>> inputs for which a given Turing machine returns the same answer as the
>>> halting function, while the other is the set of inputs for which a
>>> given Turing machine halts on.
>>
>> These are the three possible cases, they are all inclusive.
>
> Could you answer my question? You're still being stubbornly unclear in 
> your responses. Here it is again:
>
>> Suppose we implement Halts like so:
>> Halts(M, w) -> unconditionally accept.
>>
>> Which of the following sets would you call "Decidable"?
>> A. All input pairs {M, w}
>> B. All input pairs {M, w} such that M halts when input with w fed as 
>> input.
>
1) In the case where Halts() halts in its accept state, where M would 
halt on its input w, this would be decidable.
2) In the case where Halts() halts in its reject state, where M would 
not halt on its input w, this would be decidable.
3) In the case where Halts() can not correctly halt in either its accept 
state or its reject state this would be undecidable.

I think that 1) corresponds to B.

0
NoSpam271 (937)
3/30/2012 11:54:29 AM
On 3/29/2012 11:52 PM, Joshua Cranmer wrote:
> On 3/29/2012 10:16 PM, Peter Olcott wrote:
>> On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
>>> This is becoming absurd. You can't even keep track of your own
>>> definitions. Your "bug-free" requirement was made of the machine whose
>>> inputs are to be "screened out".
>>>
>> You are back to striving to be disagreeable again, I see.
>
> Says the person who is giving multiple inconsistent definitions, has 
> explicitly stated that he ignores long posts, and instructs his 
> opponents to take his word on everything. 
See you just proved it by using the term opponent.  None of my 
definitions have been inconsistent at all, and I can't see why the first 
versions of these definitions are not obviously clear.
0
NoSpam271 (937)
3/30/2012 11:57:18 AM
On 3/29/2012 11:55 PM, Joshua Cranmer wrote:
> On 3/29/2012 10:31 PM, Peter Olcott wrote:
>> On 3/29/2012 8:29 PM, Joshua Cranmer wrote:
>>> On 3/29/2012 5:35 PM, Peter Olcott wrote:
>>>> So how would you characterize the reason why the Halting Problem 
>>>> can not
>>>> be solved?
>>>> It is a perfectly valid problem and computer science is just too plain
>>>> stupid to solve it?
>>>
>>> Mathematics is simply not complete.
>> Yeah that is what Godel incorrectly proposed.
>
> You don't even have to go so far as Godel: there must exist 
> uncomputable functions since there are 2^Aleph_0 functions but only 
> Aleph_1 programs, so it is not possible to construct a bijection 
> between functions and programs which compute them. 
I have to learn more math to understand that.
0
NoSpam271 (937)
3/30/2012 11:59:05 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/29/2012 8:29 PM, Joshua Cranmer wrote:
<snip>
>> Mathematics is simply not complete.
> Yeah that is what Godel incorrectly proposed.

Ah.  It's getting clearer...  Rice, Turing, Gödel...  I'll bet Cantor
either is, or will soon be, on your list of mathematicians who've made
big mistakes.

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 1:15:05 PM
On 3/30/2012 8:15 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/29/2012 8:29 PM, Joshua Cranmer wrote:
> <snip>
>>> Mathematics is simply not complete.
>> Yeah that is what Godel incorrectly proposed.
> Ah.  It's getting clearer...  Rice, Turing, Gödel...  I'll bet Cantor
> either is, or will soon be, on your list of mathematicians who've made
> big mistakes.
>

No only the cases that depend upon Pathological Self-Reference.
0
NoSpam271 (937)
3/30/2012 1:38:48 PM
On 3/29/2012 8:29 PM, Joshua Cranmer wrote:
> On 3/29/2012 5:35 PM, Peter Olcott wrote:
>> So how would you characterize the reason why the Halting Problem can not
>> be solved?
>> It is a perfectly valid problem and computer science is just too plain
>> stupid to solve it?
>
> Mathematics is simply not complete. 

That answer is far too vague. Exactly what is not complete about 
mathematics it within the specific instance of the halting problem?
0
NoSpam271 (937)
3/30/2012 1:44:40 PM
On 3/29/2012 8:51 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/29/2012 7:02 AM, Ben Bacarisse wrote:
>>> >>  Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>> >>
>>>> >>>  On 3/28/2012 8:17 PM, Ben Bacarisse wrote:
>>>>> >>>>  Peter Olcott<NoSpam@OCR4Screen.com>    writes:
>>>>> >>>>
>>>>>>> >>>>>>     On 3/28/2012 5:29 AM, Ben Bacarisse wrote:
>>>>>>>>> >>>>>>>>     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.
>>>>>>> >>>>>>     OK fine, then what time is it (yes or no) ?
>>>>>>> >>>>>>     a) It must be in hours and minutes because it is time.
>>>>>>> >>>>>>     b) It can't be in hours and minutes because a (yes or no) answer is
>>>>>>> >>>>>>     specified.
>>>>>>> >>>>>>     c) If you don't answer this counts as a wrong answer.
>>>>>>> >>>>>>
>>>>>>> >>>>>>     This is the exact same situation as a Turing Machine that is provided
>>>>>>> >>>>>>     input defined with Pathological Self-Reference.
>>>>> >>>>  No, it is not the same at all.  The question, "does TM t halt on input
>>>>> >>>>  i" has a correct true/false answer and entails no logical nonsense.
>>>> >>>  So still do not comprehend Pathological Self-Reference?
>>> >>  No, of course I don't.  You've never defined it.  You, on the other
>>> >>  hand, don't seem to understand what a decision problem is.  This is more
>>> >>  serious, because you've claimed to be taking talking about one from the
>>> >>  start.
>>> >>
>> >
>> >  So how would you characterize the reason why the Halting Problem can
>> >  not be solved?
> There are several way to look at it.  It is natural that there must be
> many functions that can't be computed by any Turing machine simply
> because there are only countably many Turing machines, but there are
> uncountably many functions from input strings to {true, false} (to pick
> just an interesting subset of functions).
>
> Why is halting, specifically, one of these?  The argument that proves
> that halting is not decidable is also a diagonalisation argument,
> exactly like Cantor's argument about the power set of N.

So I will have to explain Pathological Self-Reference in terms of the 
diagonalization.
I will get back to you on this.
0
NoSpam271 (937)
3/30/2012 1:49:11 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/29/2012 8:10 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 3/28/2012 10:14 PM, Ben Bacarisse wrote:
>>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>> <snip>
>>>>> Boolean HaltDecider(String tm, String input)
>>>>> {
>>>>>      if (Decidable(Halts, tm, input))
>>>>>        if (Halts(tm, input))
>>>>>          return true;
>>>>>       else
>>>>>          return false;
>>>>>     else
>>>>>       Print("The input is semantically incorrect!");
>>>>> }
>>>> Stepping back a bit...
>>>>
>>>> If I understand your other posts, this construct only applies to
>>>> "bug-free" Halts machines, and these have the property that they are
>>>> correct except that they don't halt on exactly those inputs that
>>>> Decidable(Halts, tm, input) rejects.  Assuming that all this can be
>>>> pinned down, and that the resulting objects exist, what will you have
>>>> achieved?  HaltDecider is just as bad at deciding halting as Halts is.
>>>>
>>> It only fails to decide those cases that were artificially contrived
>>> to make it fail, (or are otherwise erroneous) and since those cases
>>> derive incorrect input, they can be dismissed as incorrect input in
>>> the same way that a HaltDecider would dismiss an English Poem as
>>> neither halting nor failing to halt.
>> <sigh>  It's not the same at all.  Those "contrived" inputs represent
>> machine and input pairs that have correct true/false answers to the
>> question that a halting decider must answer.
>>
> You still did not answer my similar question:
> What time is it (yes or no) ???

We are at an impasse and I am not sure there is any way to move forward.
When pressed, you refused to say whether you agree that all questions of
the form "does machine t halt on input i" have correct yes/no answers.
That's telling.  I suspect that you are, by now, too committed to the
idea that there are "invalid halting questions" to accept this plain
fact.  Questions like "what time is it, yes or no?" don't have correct
yes/no answers, so to call it a "similar" question seems disingenuous,
at best.

I am curious to know what you think about other non-computable
functions.  For example, the Busy Beaver function[1] has been shown not
to be computable without using a reduction to halting, and I can't see
any way you could imagine that some inputs to it are invalid.  Is it
*only* halting that bothers you so much?

[1] BB(n) is a function from the natural numbers to the natural numbers.
It's the maximum number of 1s that an n-state TM can leave on it's tape
when (and if) it halts.  Some values are know: BB(1) = 1, BB(2) = 4,
BB(3) = 6 and BB(4) = 13, but that's it so far.

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 2:08:59 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 3/28/2012 9:34 PM, Ben Bacarisse wrote:
>>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>> <snip>
>>>>> Bug free means that:
>>>>> 1) Whenever Halts() halts in its accept state its input tm would halt
>>>>> on its input.
>>>>> 2) Whenever Halts() halts in its reject state its input tm would not
>>>>> halt on its input.
>>>>> 3) The only cases that Halts() does not halt are those cases that are
>>>>> undecidable for it.
>> <snip>
>>>>> Is there anything at all that "bug-free" could possibly correctly mean
>>>>> besides the above specification?
>>>> Yes, of course.  The natural meaning is of a correct halting decider.
>>>> Yours is of a partially correct one with an unspecified number of cases
>>>> that it is permitted to get wrong.  That's not the obvious meaning of
>>>> "bug-free".
>>>>
>>> It does not get any cases wrong, all of these cases are screened out
>>> by the DecidabilityDecider() before they reach the HaltDecider().
>> This is becoming absurd.  You can't even keep track of your own
>> definitions.  Your "bug-free" requirement was made of the machine whose
>> inputs are to be "screened out".
>>
> You are back to striving to be disagreeable again, I see.

You've made being "bug-free" a crucial criterion for the existence of
what you call a "DecidabilityDecider".  The only definition you've given
so far relies on the definition of cases that are "undecidable".  By
choosing to be offended you've avoided clearing up this ambiguity.  By
all means, continue to be offended, but you won't make any headway
unless you answer these points.

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 2:20:32 PM
On 3/30/2012 8:44 AM, Peter Olcott wrote:
> On 3/29/2012 8:29 PM, Joshua Cranmer wrote:
>> On 3/29/2012 5:35 PM, Peter Olcott wrote:
>>> So how would you characterize the reason why the Halting Problem can not
>>> be solved?
>>> It is a perfectly valid problem and computer science is just too plain
>>> stupid to solve it?
>>
>> Mathematics is simply not complete.
>
> That answer is far too vague. Exactly what is not complete about
> mathematics it within the specific instance of the halting problem?

Did you not read the following sentences I wrote?

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 2:25:09 PM
On 3/30/2012 6:54 AM, Peter Olcott wrote:
> On 3/29/2012 11:48 PM, Joshua Cranmer wrote:
>> On 3/29/2012 10:25 PM, Peter Olcott wrote:
>>> On 3/29/2012 8:24 PM, Joshua Cranmer wrote:
>>>> You seem to treat the two definitions in this post as exactly
>>>> equivalent, but they are not. One definition is the set which of
>>>> inputs for which a given Turing machine returns the same answer as the
>>>> halting function, while the other is the set of inputs for which a
>>>> given Turing machine halts on.
>>>
>>> These are the three possible cases, they are all inclusive.
>>
>> Could you answer my question? You're still being stubbornly unclear in
>> your responses. Here it is again:
>>
>>> Suppose we implement Halts like so:
>>> Halts(M, w) -> unconditionally accept.
>>>
>>> Which of the following sets would you call "Decidable"?
>>> A. All input pairs {M, w}
>>> B. All input pairs {M, w} such that M halts when input with w fed as
>>> input.
>>
> 1) In the case where Halts() halts in its accept state, where M would
> halt on its input w, this would be decidable.
> 2) In the case where Halts() halts in its reject state, where M would
> not halt on its input w, this would be decidable.
> 3) In the case where Halts() can not correctly halt in either its accept
> state or its reject state this would be undecidable.
>
> I think that 1) corresponds to B.

Is that your final answer?

The reason I ask is because, if you decide B is the set "Decidable", you 
can trivially reduce the general halting problem to deciding the 
"Decidable" set for a given Turing machine. In other words, deciding 
this set is exactly as hard as deciding the halting problem at large.


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 2:28:59 PM
On 3/30/2012 6:57 AM, Peter Olcott wrote:
> On 3/29/2012 11:52 PM, Joshua Cranmer wrote:
>> On 3/29/2012 10:16 PM, Peter Olcott wrote:
>>> On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
>>>> This is becoming absurd. You can't even keep track of your own
>>>> definitions. Your "bug-free" requirement was made of the machine whose
>>>> inputs are to be "screened out".
>>>>
>>> You are back to striving to be disagreeable again, I see.
>>
>> Says the person who is giving multiple inconsistent definitions, has
>> explicitly stated that he ignores long posts, and instructs his
>> opponents to take his word on everything.
> See you just proved it by using the term opponent. None of my
> definitions have been inconsistent at all, and I can't see why the first
> versions of these definitions are not obviously clear.

Some of your definitions for "Decidable" are, by common interpretation, 
the set of values for which a given Turing machine halts, while others 
the set of values for which a given Turing machine agrees with the 
generic halting function. These two sets are not equivalent, so, by 
conclusion, you have been giving inconsistent definitions, although you 
probably did not intend to.

And you're the person who claims that natural language makes these 
things easier to understand. Even when your several wordings in natural 
language cause multiple inconsistent definitions to arise.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 2:31:56 PM
Joshua Cranmer <Pidgeot18@verizon.invalid> writes:

> On 3/30/2012 6:54 AM, Peter Olcott wrote:
>> On 3/29/2012 11:48 PM, Joshua Cranmer wrote:
>>> On 3/29/2012 10:25 PM, Peter Olcott wrote:
>>>> On 3/29/2012 8:24 PM, Joshua Cranmer wrote:
>>>>> You seem to treat the two definitions in this post as exactly
>>>>> equivalent, but they are not. One definition is the set which of
>>>>> inputs for which a given Turing machine returns the same answer as the
>>>>> halting function, while the other is the set of inputs for which a
>>>>> given Turing machine halts on.
>>>>
>>>> These are the three possible cases, they are all inclusive.
>>>
>>> Could you answer my question? You're still being stubbornly unclear in
>>> your responses. Here it is again:
>>>
>>>> Suppose we implement Halts like so:
>>>> Halts(M, w) -> unconditionally accept.
>>>>
>>>> Which of the following sets would you call "Decidable"?
>>>> A. All input pairs {M, w}
>>>> B. All input pairs {M, w} such that M halts when input with w fed as
>>>> input.
>>>
>> 1) In the case where Halts() halts in its accept state, where M would
>> halt on its input w, this would be decidable.
>> 2) In the case where Halts() halts in its reject state, where M would
>> not halt on its input w, this would be decidable.
>> 3) In the case where Halts() can not correctly halt in either its accept
>> state or its reject state this would be undecidable.
>>
>> I think that 1) corresponds to B.
>
> Is that your final answer?
>
> The reason I ask is because, if you decide B is the set "Decidable",
> you can trivially reduce the general halting problem to deciding the
> "Decidable" set for a given Turing machine. In other words, deciding
> this set is exactly as hard as deciding the halting problem at large.

This is an interesting step back wards.  When I suggested the same
machine (and the same reduction to halting[1]) Peter replied that the
magic "Decidable" set only exists for "bug-free" Halts machines.

Of course this then led to the "bug-free" means correct except for
"undecidable" cases sub-thread.

I am not surprised that Peter do not give the same answer this time.  I
think he is getting lost in his own ill-defined terms.

[1] Actually I suggested Halts(M, w) -> unconditionally reject, but
Patricia pointed out that unconditionally accept is marginally simpler.
-- 
Ben.
0
ben.usenet (6790)
3/30/2012 2:42:34 PM
On 3/30/2012 9:42 AM, Ben Bacarisse wrote:
> I am not surprised that Peter do not give the same answer this time.  I
> think he is getting lost in his own ill-defined terms.

I don't think this is quite the case. Rather, I think he is using the 
terms elastically: if a case would admit a failure in his proof, the 
terms narrow to exclude it. This may explain why he believes natural 
language to be "more clear": words describe his intent whereas 
attempting to produce formal argumentation would make the incorrectness 
of his thesis self-evident.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/30/2012 3:50:00 PM
On Mar 30, 10:08=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> [1] BB(n) is a function from the natural numbers to the natural numbers.
> It's the maximum number of 1s that an n-state TM can leave on it's tape
> when (and if) it halts. =A0Some values are know: BB(1) =3D 1, BB(2) =3D 4=
,
> BB(3) =3D 6 and BB(4) =3D 13, but that's it so far.

Is there a proof of some sub-lemma or corollary to this that it
doesn't
matter what the original input was?  Isn't there some sort of
corresponding function about how long the input had to be IN ORDER TO
PRODUCE this maximal output?

0
greeneg9613 (188)
3/30/2012 4:14:54 PM
On 3/30/2012 8:50 AM, Joshua Cranmer wrote:
> On 3/30/2012 9:42 AM, Ben Bacarisse wrote:
>> I am not surprised that Peter do not give the same answer this time. I
>> think he is getting lost in his own ill-defined terms.
>
> I don't think this is quite the case. Rather, I think he is using the
> terms elastically: if a case would admit a failure in his proof, the
> terms narrow to exclude it. This may explain why he believes natural
> language to be "more clear": words describe his intent whereas
> attempting to produce formal argumentation would make the incorrectness
> of his thesis self-evident.
>

The main effect on me of these threads has been to deepen my respect for
the practicality of the normal written style and social conventions of
mathematical discourse.

Patricia
0
pats (3556)
3/30/2012 4:29:45 PM
On Mar 30, 10:42=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> [1] Actually I suggested Halts(M, w) -> unconditionally reject, but
> Patricia pointed out that unconditionally accept is marginally simpler.

He said that what it "means" for "halts-analyzer" "to BE" "bug-free"
is that
a) whenever it accept-halts (returns true) on (m,i), m halts on i, and
b) whenever it reject -halts (returns false) on(m,i), m does not halt
on i, and
c) whenever it loops, the m,i pair is "undecidable for it".

Relativizing to "for it" trivializes the whole concept; you CAN'T have
an
m,i pair be undecidable for one machine yet decidable for another; if
it's
decidable FOR ANY machine then whatEVER THAT machine decides IS THE
ANSWER and ALL machines are OBLIGATED to decide it THE SAME way if
THEY are going to be "bug-free".
By his definition, the machine that knows NOTHING, that loops on
EVERY (m,i) and NEVER returns any information, qualifies as a halt-
analyzer and says that EVERYthing is undecidable FOR IT.
Because it never answers, it never answers wrongly, and because it
never answers wrongly, it is, by P.O.'s definition, "bug-free".

I tried to rub his nose in this by offering the "analyzer" that accept-
halts
on the machine that always halts, and reject halts on the machine that
always loops, and loops on every other machine.  At least that wasn't
COMPLETELY degenerate; at least it populated all 3 branches of
his decision-tree with at least ONE m.

But he just ignored it.
0
greeneg9613 (188)
3/30/2012 7:51:12 PM
On 3/30/2012 9:08 AM, Ben Bacarisse wrote:
> We are at an impasse and I am not sure there is any way to move forward.
> When pressed, you refused to say whether you agree that all questions of
> the form "does machine t halt on input i" have correct yes/no answers.
When Pathological Self-Reference is involved there is no correct yes/no 
answer.

When the input to the halt decider is a pair of English poems there is 
no correct yes/no answer.

Will the first English poem halt on its input of the second English poem 
(yes or no)?


0
NoSpam271 (937)
3/30/2012 8:51:30 PM
On 3/30/2012 9:08 AM, Ben Bacarisse wrote:
> I am curious to know what you think about other non-computable
> functions.  For example, the Busy Beaver function[1] has been shown not
> to be computable without using a reduction to halting, and I can't see
> any way you could imagine that some inputs to it are invalid.  Is it
> *only*  halting that bothers you so much?
I intensely focus on one problem at a time.
0
NoSpam271 (937)
3/30/2012 8:54:43 PM
In comp.theory Peter Olcott <NoSpam@ocr4screen.com> wrote:

> When Pathological Self-Reference is involved there is no correct yes/no 
> answer.

Then, as there _is_ a correct yes/no answer to the question "Does
program P halt on input I?", there's no "pathological self-reference"
at play here at all and you're just blowing smoke.

-- 
Leif Roar Moldskred
0
leifm1143 (162)
3/30/2012 8:56:27 PM
On 3/30/2012 9:20 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>
>>>> On 3/28/2012 9:34 PM, Ben Bacarisse wrote:
>>>>> Peter Olcott<NoSpam@OCR4Screen.com>    writes:
>>> <snip>
>>>>>> Bug free means that:
>>>>>> 1) Whenever Halts() halts in its accept state its input tm would halt
>>>>>> on its input.
>>>>>> 2) Whenever Halts() halts in its reject state its input tm would not
>>>>>> halt on its input.
>>>>>> 3) The only cases that Halts() does not halt are those cases that are
>>>>>> undecidable for it.
>>> <snip>
>>>>>> Is there anything at all that "bug-free" could possibly correctly mean
>>>>>> besides the above specification?
>>>>> Yes, of course.  The natural meaning is of a correct halting decider.
>>>>> Yours is of a partially correct one with an unspecified number of cases
>>>>> that it is permitted to get wrong.  That's not the obvious meaning of
>>>>> "bug-free".
>>>>>
>>>> It does not get any cases wrong, all of these cases are screened out
>>>> by the DecidabilityDecider() before they reach the HaltDecider().
>>> This is becoming absurd.  You can't even keep track of your own
>>> definitions.  Your "bug-free" requirement was made of the machine whose
>>> inputs are to be "screened out".
>>>
>> You are back to striving to be disagreeable again, I see.
> You've made being "bug-free" a crucial criterion for the existence of
> what you call a "DecidabilityDecider".  The only definition you've given
> so far relies on the definition of cases that are "undecidable".  By
> choosing to be offended you've avoided clearing up this ambiguity.  By
> all means, continue to be offended, but you won't make any headway
> unless you answer these points.
>
I broke it down several times into its categorically exhaustive complete 
enumeration.
I can not believe that you don't fully understand what I am saying.
0
NoSpam271 (937)
3/30/2012 8:59:39 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/30/2012 9:08 AM, Ben Bacarisse wrote:
>> We are at an impasse and I am not sure there is any way to move forward.
>> When pressed, you refused to say whether you agree that all questions of
>> the form "does machine t halt on input i" have correct yes/no answers.
> When Pathological Self-Reference is involved there is no correct
> yes/no answer.

No.  There is no third option for a TM.  It halts or it does not.
Exactly one of yes or no is the correct answer in every case.

> When the input to the halt decider is a pair of English poems there is
> no correct yes/no answer.

Not true.  A halt decider must decide every case, and that includes
English poems (if they can be written in the machine's alphabet, of
course).

This particular error is somewhat understandable because we've all been
very lax about specifying encodings and, even, exactly what a decision
problem is.  That's clearly been a mistake.

It's normal to define a Turing machine decision problem (like halting)
as specifying a set based on some predicate, P:

  { s in Sigma* such that P(s) }

Sigma is the alphabet of the class of TMs we're interested in (we know
the details of it are not very important).  If this set is recursive (an
unfortunate term in my opinion) the decision problem is TM-decidable or
just decidable for short.

For halting, the predicate P(s) is "does s encode a <t, i> pair such
that t halts when run on input i".  Even when s is "A man so various
that he seemed to be not one but all mankind's epitome", P(s) is either
true or false, and that string is either in the set or it is not.

> Will the first English poem halt on its input of the second English
> poem (yes or no)?

That's a slightly different question because we must also consider how
the pair is encoded.  But, such details permitting, a decider must still
answer this question yes or no.

-- 
Ben.
0
ben.usenet (6790)
3/30/2012 10:17:00 PM
On 3/30/2012 9:28 AM, Joshua Cranmer wrote:
> On 3/30/2012 6:54 AM, Peter Olcott wrote:
>> On 3/29/2012 11:48 PM, Joshua Cranmer wrote:
>>> On 3/29/2012 10:25 PM, Peter Olcott wrote:
>>>> On 3/29/2012 8:24 PM, Joshua Cranmer wrote:
>>>>> You seem to treat the two definitions in this post as exactly
>>>>> equivalent, but they are not. One definition is the set which of
>>>>> inputs for which a given Turing machine returns the same answer as 
>>>>> the
>>>>> halting function, while the other is the set of inputs for which a
>>>>> given Turing machine halts on.
>>>>
>>>> These are the three possible cases, they are all inclusive.
>>>
>>> Could you answer my question? You're still being stubbornly unclear in
>>> your responses. Here it is again:
>>>
>>>> Suppose we implement Halts like so:
>>>> Halts(M, w) -> unconditionally accept.
>>>>
>>>> Which of the following sets would you call "Decidable"?
>>>> A. All input pairs {M, w}
>>>> B. All input pairs {M, w} such that M halts when input with w fed as
>>>> input.
>>>
>> 1) In the case where Halts() halts in its accept state, where M would
>> halt on its input w, this would be decidable.
>> 2) In the case where Halts() halts in its reject state, where M would
>> not halt on its input w, this would be decidable.
>> 3) In the case where Halts() can not correctly halt in either its accept
>> state or its reject state this would be undecidable.
>>
>> I think that 1) corresponds to B.
>
> Is that your final answer?
>
> The reason I ask is because, if you decide B is the set "Decidable", 
> you can trivially reduce the general halting problem to deciding the 
> "Decidable" set for a given Turing machine. In other words, deciding 
> this set is exactly as hard as deciding the halting problem at large.
>
>
That is not true, the DecidabilityDecider() rejects any attempt at this.
0
NoSpam271 (937)
3/30/2012 10:40:00 PM
On 3/30/2012 9:31 AM, Joshua Cranmer wrote:
> On 3/30/2012 6:57 AM, Peter Olcott wrote:
>> On 3/29/2012 11:52 PM, Joshua Cranmer wrote:
>>> On 3/29/2012 10:16 PM, Peter Olcott wrote:
>>>> On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
>>>>> This is becoming absurd. You can't even keep track of your own
>>>>> definitions. Your "bug-free" requirement was made of the machine 
>>>>> whose
>>>>> inputs are to be "screened out".
>>>>>
>>>> You are back to striving to be disagreeable again, I see.
>>>
>>> Says the person who is giving multiple inconsistent definitions, has
>>> explicitly stated that he ignores long posts, and instructs his
>>> opponents to take his word on everything.
>> See you just proved it by using the term opponent. None of my
>> definitions have been inconsistent at all, and I can't see why the first
>> versions of these definitions are not obviously clear.
>
> Some of your definitions for "Decidable" are, by common 
> interpretation, the set of values for which a given Turing machine 
> halts, while others the set of values for which a given Turing machine 
> agrees with the generic halting function. These two sets are not 
> equivalent, so, by conclusion, you have been giving inconsistent 
> definitions, although you probably did not intend to.
>
> And you're the person who claims that natural language makes these 
> things easier to understand. Even when your several wordings in 
> natural language cause multiple inconsistent definitions to arise.
>

1) In the case where Halts() halts in its accept state, where M would
halt on its input w, this would be decidable.
2) In the case where Halts() halts in its reject state, where M would
not halt on its input w, this would be decidable.
3) In the case where Halts() can not correctly halt in either its accept
state or its reject state this would be undecidable.

There is no inconsistency here, the above specification of sets is 
entirely consistent when applied so a single TM and the possible input 
strings to this TM.
0
NoSpam271 (937)
3/30/2012 10:45:39 PM
On 3/30/2012 9:42 AM, Ben Bacarisse wrote:
> Joshua Cranmer<Pidgeot18@verizon.invalid>  writes:
>
>> On 3/30/2012 6:54 AM, Peter Olcott wrote:
>>> On 3/29/2012 11:48 PM, Joshua Cranmer wrote:
>>>> On 3/29/2012 10:25 PM, Peter Olcott wrote:
>>>>> On 3/29/2012 8:24 PM, Joshua Cranmer wrote:
>>>>>> You seem to treat the two definitions in this post as exactly
>>>>>> equivalent, but they are not. One definition is the set which of
>>>>>> inputs for which a given Turing machine returns the same answer as the
>>>>>> halting function, while the other is the set of inputs for which a
>>>>>> given Turing machine halts on.
>>>>> These are the three possible cases, they are all inclusive.
>>>> Could you answer my question? You're still being stubbornly unclear in
>>>> your responses. Here it is again:
>>>>
>>>>> Suppose we implement Halts like so:
>>>>> Halts(M, w) ->  unconditionally accept.
>>>>>
>>>>> Which of the following sets would you call "Decidable"?
>>>>> A. All input pairs {M, w}
>>>>> B. All input pairs {M, w} such that M halts when input with w fed as
>>>>> input.
>>> 1) In the case where Halts() halts in its accept state, where M would
>>> halt on its input w, this would be decidable.
>>> 2) In the case where Halts() halts in its reject state, where M would
>>> not halt on its input w, this would be decidable.
>>> 3) In the case where Halts() can not correctly halt in either its accept
>>> state or its reject state this would be undecidable.
>>>
>>> I think that 1) corresponds to B.
>> Is that your final answer?
>>
>> The reason I ask is because, if you decide B is the set "Decidable",
>> you can trivially reduce the general halting problem to deciding the
>> "Decidable" set for a given Turing machine. In other words, deciding
>> this set is exactly as hard as deciding the halting problem at large.
> This is an interesting step back wards.  When I suggested the same
> machine (and the same reduction to halting[1]) Peter replied that the
> magic "Decidable" set only exists for "bug-free" Halts machines.
This is the precise specification of bug-free, do you want to continue 
to pretend that you don't understand this still?

1) Halts() halts in its accept state, where M would halt on its input w, 
this would be decidable.
2) Halts() halts in its reject state, where M would not halt on its 
input w, this would be decidable.
3) In the case where Halts() can not correctly halt in either its accept 
state or its reject state this would be undecidable, Halts() loops.

>
> Of course this then led to the "bug-free" means correct except for
> "undecidable" cases sub-thread.
Undecidable cases are not bugs, they are erroneous input.
What should a halt decider do when its input is a pair of English Poems?

This is undecidable too, do we count it as a wrong answer no matter what 
the halt decider does, or do we allow the halt decider to indicate that 
the input is erroneous?

>
> I am not surprised that Peter do not give the same answer this time.  I
> think he is getting lost in his own ill-defined terms.
>
> [1] Actually I suggested Halts(M, w) ->  unconditionally reject, but
> Patricia pointed out that unconditionally accept is marginally simpler.

0
NoSpam271 (937)
3/30/2012 10:52:38 PM
On 3/30/2012 10:50 AM, Joshua Cranmer wrote:
> On 3/30/2012 9:42 AM, Ben Bacarisse wrote:
>> I am not surprised that Peter do not give the same answer this time.  I
>> think he is getting lost in his own ill-defined terms.
>
> I don't think this is quite the case. Rather, I think he is using the 
> terms elastically: if a case would admit a failure in his proof, the 
> terms narrow to exclude it. This may explain why he believes natural 
> language to be "more clear": words describe his intent whereas 
> attempting to produce formal argumentation would make the 
> incorrectness of his thesis self-evident.
>

A "bug-free" halt decider is logically entailed by its name. I really 
should not have had to define it at all, much less go on and on and on 
stating the completely obvious.

Bug-free means that every decision that it makes is correct, and the 
only cases where it fails to make a decision, is when its input is 
erroneous.

I am not going to define what correct means again so don't ask.
0
NoSpam271 (937)
3/30/2012 10:57:20 PM
On 3/30/2012 3:56 PM, Leif Roar Moldskred wrote:
> In comp.theory Peter Olcott<NoSpam@ocr4screen.com>  wrote:
>
>> >  When Pathological Self-Reference is involved there is no correct yes/no
>> >  answer.
> Then, as there_is_  a correct yes/no answer to the question "Does
> program P halt on input I?", there's no "pathological self-reference"
> at play here at all and you're just blowing smoke.

When this invocation is posed to a TM with Pathological Self-Reference 
it is an entirely different question than when a TM without Pathological 
Self-Reference is invoked.

My reference to Daryl McCullough's "volunteer" analogy has proven this 
in the first posting of my prior thread named: Pathological 
Self-Reference and the Halting Problem.

It is a shame that he did not fully understand his own analogy.
0
NoSpam271 (937)
3/30/2012 11:03:10 PM
In comp.theory Peter Olcott <NoSpam@ocr4screen.com> wrote:
> On 3/30/2012 3:56 PM, Leif Roar Moldskred wrote:

>> Then, as there_is_  a correct yes/no answer to the question "Does
>> program P halt on input I?", there's no "pathological self-reference"
>> at play here at all and you're just blowing smoke.
> 
> When this invocation is posed to a TM with Pathological Self-Reference 
> it is an entirely different question than when a TM without Pathological 
> Self-Reference is invoked.

No, the question is still "Does program P halt on input I." That's
_always_ the question for a halting decider, and that question
_always_ has a correct yes / no answer.

-- 
Leif Roar Moldskred
 
0
leifm1143 (162)
3/30/2012 11:16:15 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/30/2012 9:20 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 3/29/2012 7:43 PM, Ben Bacarisse wrote:
>>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>>
>>>>> On 3/28/2012 9:34 PM, Ben Bacarisse wrote:
>>>>>> Peter Olcott<NoSpam@OCR4Screen.com>    writes:
>>>> <snip>
>>>>>>> Bug free means that:
>>>>>>> 1) Whenever Halts() halts in its accept state its input tm would halt
>>>>>>> on its input.
>>>>>>> 2) Whenever Halts() halts in its reject state its input tm would not
>>>>>>> halt on its input.
>>>>>>> 3) The only cases that Halts() does not halt are those cases that are
>>>>>>> undecidable for it.
>>>> <snip>
>>>>>>> Is there anything at all that "bug-free" could possibly correctly mean
>>>>>>> besides the above specification?
>>>>>> Yes, of course.  The natural meaning is of a correct halting decider.
>>>>>> Yours is of a partially correct one with an unspecified number of cases
>>>>>> that it is permitted to get wrong.  That's not the obvious meaning of
>>>>>> "bug-free".
>>>>>>
>>>>> It does not get any cases wrong, all of these cases are screened out
>>>>> by the DecidabilityDecider() before they reach the HaltDecider().
>>>> This is becoming absurd.  You can't even keep track of your own
>>>> definitions.  Your "bug-free" requirement was made of the machine whose
>>>> inputs are to be "screened out".
>>>>
>>> You are back to striving to be disagreeable again, I see.
>> You've made being "bug-free" a crucial criterion for the existence of
>> what you call a "DecidabilityDecider".  The only definition you've given
>> so far relies on the definition of cases that are "undecidable".  By
>> choosing to be offended you've avoided clearing up this ambiguity.  By
>> all means, continue to be offended, but you won't make any headway
>> unless you answer these points.
>>
> I broke it down several times into its categorically exhaustive
> complete enumeration.
> I can not believe that you don't fully understand what I am saying.

Some notation so I can talk about what you've said.  In many cases I'll
try to use the same symbols that you've used.

T is the set of Turing machines about which we want to determine
halting.  S is the alphabet of these machines, so S* is the set of input
strings.  Given t in T and i in S*, t(i) is the partial function that
represents the result of running t with i as its initial tape.  t(i) is
"yes" if t accepts i, "no" if t rejects i, and undefined in all other
cases (i.e. when t does not halt on input i).

There is a total function called halts: T x S* -> {true, false} such
that halts(t, i) is true if and only if t(i) in {yes, no}.  Elsewhere,
you've said that halts is only a partial function.  No progress is
possible if you are going to stick with that claim.  Try to put it aside
for the moment.

We'll write <t, i> to represent the encoding of a (t, i) pair in some
new alphabet Sigma.  This is the alphabet of the machine that must
determine halting.  The classical halting problem is whether or not a
Turing machine, h, exists such that

  h(<t, i>) = yes if and only if halts(t, i)

Originally, you defined a set Invalid_Input, but you are now concerned
with the complement of that set which you call "Decidable".  This is a
set that is dependent on a particular machine.  Each acceptable halting
machine candidate, h, has a "Decidable" set D(h).  I've used functional
notation to show this dependence.  You defined

  D(h) = T(h) union F(h)

(You originally T and F but T(h) and F(h) remind us that these sets are
determined by the candidate machine in question).

  T(h) = { <t, i> such that halts(t, i) and h(<t, i>) = yes }
  F(h) = { <t, i> such that ~halts(t, i) and h(<t, i>) = no }

You claimed that D(h) was a decidable set, but that runs into problems
for machines like y for which y(s) = yes for all s.  A decider for D(y)
is simply a halting decider.

No, you said.  D(h) only applies to "bug-free" machines.  I.e. there is
a set of TMs, BF, such that D(h) is decidable for all h in BF.  When
pressed for a definition of BF we got this:

h in BF means that:
a) h(<t, i>) = yes implies halts(t, i)
b) h(<t, i>) = no implies ~halts(t, i)
c) h(<t, i>) not in {yes, no} if and only if <t, i> not in D(h)

This is a translation of your (1) to (3), quoted above, into this
notation.  I've used letters so that if you don't agree with this
translation you can talk about (a) not being the same as (1) and so on.

The problem is number 3.  I've had to translate it into a condition
using D(h) because that is the only definition I have so far of
"decidable for a machine h".

Consider the machine l which loops for all inputs.  D(l) is empty, and l
satisfies (a), (b) and (c), but I suspect you don't want this useless
machine to considered bug-free.  I suspect your words:

  "3) The only cases that Halts() does not halt are those cases that are
  undecidable for it."

uses "undecidable" to mean something slightly different to D(h).

The other reason that I think you are not being clear is that my
condition (c) is redundant -- it followed from (a) and (b) and the
definition of D(h) but I don't think you think it's redundant.  I think
your language about "the only cases" is intended to be something
stronger that you are actually saying.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 12:08:22 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:
<snip>
> This is the precise specification of bug-free, do you want to continue
> to pretend that you don't understand this still?

Yes, I still don't understand it.  I've explained why as carefully as I
can in another post.  I think my concerns are legitimate.

> 1) Halts() halts in its accept state, where M would halt on its input
> w, this would be decidable.
> 2) Halts() halts in its reject state, where M would not halt on its
> input w, this would be decidable.
> 3) In the case where Halts() can not correctly halt in either its
> accept state or its reject state this would be undecidable, Halts()
> loops.

I *really* hope you are not going to change the definition to this new
one.  I have spent some considerable time clarifying why I think your
previous definition is not clear (and a little odd) but this new one is
unclear in a whole new set of ways!

>> Of course this then led to the "bug-free" means correct except for
>> "undecidable" cases sub-thread.
> Undecidable cases are not bugs, they are erroneous input.
> What should a halt decider do when its input is a pair of English
> Poems?

I've answered that elsewhere too.

> This is undecidable too, do we count it as a wrong answer no matter
> what the halt decider does, or do we allow the halt decider to
> indicate that the input is erroneous?

No we don't because all questions of the form "does machine t halt on
input i" have correct yes/no answers.  I've said a little more on that
elsewhere as well.  The actual question is "does my input represent a
machine and string pair such that the machine halts when run on the
string".  If the input does not represent what it should the correct
answer is "no".

<snip>
-- 
Ben.
0
ben.usenet (6790)
3/31/2012 12:25:48 AM
On 3/30/2012 6:16 PM, Leif Roar Moldskred wrote:
> In comp.theory Peter Olcott<NoSpam@ocr4screen.com>  wrote:
>> On 3/30/2012 3:56 PM, Leif Roar Moldskred wrote:
>
>>> Then, as there_is_  a correct yes/no answer to the question "Does
>>> program P halt on input I?", there's no "pathological self-reference"
>>> at play here at all and you're just blowing smoke.
>>
>> When this invocation is posed to a TM with Pathological Self-Reference
>> it is an entirely different question than when a TM without Pathological
>> Self-Reference is invoked.
>
> No, the question is still "Does program P halt on input I." That's
> _always_ the question for a halting decider, and that question
> _always_ has a correct yes / no answer.

You're wasting your breath. In a post, he admitted that he believes that 
the correctness of a question is dependent on the machine of which it is 
asked, so "halts(P, I)" has a different value if a machine purporting to 
implement halts is a subprogram of P.


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 1:38:36 AM
On 3/30/2012 5:40 PM, Peter Olcott wrote:
> On 3/30/2012 9:28 AM, Joshua Cranmer wrote:
>> The reason I ask is because, if you decide B is the set "Decidable",
>> you can trivially reduce the general halting problem to deciding the
>> "Decidable" set for a given Turing machine. In other words, deciding
>> this set is exactly as hard as deciding the halting problem at large.
>>
>>
> That is not true, the DecidabilityDecider() rejects any attempt at this.

How can it? "Decidable" is, by your definition, well-defined for any 
Turing machine. So any attempt to implement DecidabilityDecider must 
also work for the Turing machine I enumerated. In the case I gave, the 
"Decidable" set for that Turing machine is precisely the set which 
represents the Halting problem. Therefore, if DecidabilityDecider were 
to work properly, it must solve the Halting problem itself.

If this is not to be the case, either your definition of "Decidable" or 
your definition of DecidabilityDecider needs to be modified.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 1:42:38 AM
On 3/30/2012 6:16 PM, Leif Roar Moldskred wrote:
> In comp.theory Peter Olcott<NoSpam@ocr4screen.com>  wrote:
>> On 3/30/2012 3:56 PM, Leif Roar Moldskred wrote:
>>> Then, as there_is_  a correct yes/no answer to the question "Does
>>> program P halt on input I?", there's no "pathological self-reference"
>>> at play here at all and you're just blowing smoke.
>> When this invocation is posed to a TM with Pathological Self-Reference
>> it is an entirely different question than when a TM without Pathological
>> Self-Reference is invoked.
> No, the question is still "Does program P halt on input I." That's
> _always_ the question for a halting decider, and that question
> _always_ has a correct yes / no answer.
>

Although the words are the same the mathematical mapping from the words 
to the underlying semantic meaning differs depending on whether or not 
Pathological Self-Reference is present.

http://groups.google.com/group/comp.theory/msg/b1f192c4aa8fe5fd?hl=en

The question:
Will the next word from the volunteer's mouth be "no"?
when answered by the volunteer is a different question than when anyone 
else answers it, even if it is word-for-word identical in every other 
way. It is *only* Pathological Self-Reference that makes this difference.
0
NoSpam271 (937)
3/31/2012 2:16:05 AM
On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
> <snip>
>> >  This is the precise specification of bug-free, do you want to continue
>> >  to pretend that you don't understand this still?
> Yes, I still don't understand it.  I've explained why as carefully as I
> can in another post.  I think my concerns are legitimate.
>
>> >  1) Halts() halts in its accept state, where M would halt on its input
>> >  w, this would be decidable.
>> >  2) Halts() halts in its reject state, where M would not halt on its
>> >  input w, this would be decidable.
>> >  3) In the case where Halts() can not correctly halt in either its
>> >  accept state or its reject state this would be undecidable, Halts()
>> >  loops.
> I*really*  hope you are not going to change the definition to this new
> one.  I have spent some considerable time clarifying why I think your
> previous definition is not clear (and a little odd) but this new one is
> unclear in a whole new set of ways!
>
>>> >>  Of course this then led to the "bug-free" means correct except for
>>> >>  "undecidable" cases sub-thread.
>> >  Undecidable cases are not bugs, they are erroneous input.
>> >  What should a halt decider do when its input is a pair of English
>> >  Poems?
> I've answered that elsewhere too.
>
>> >  This is undecidable too, do we count it as a wrong answer no matter
>> >  what the halt decider does, or do we allow the halt decider to
>> >  indicate that the input is erroneous?
> No we don't because all questions of the form "does machine t halt on
> input i" have correct yes/no answers.
Yet an English Poem is not even a Turing Machine so it can not possibly 
either halt or fail to halt. Not allowing rejecting invalid input is a 
fundamental error within computing theory. this makes the current 
definition of computing theory inherently erroneous.

What about the empty string?
Does the empty string halt on the empty string (logically entailing the 
the empty string is running) or does the empty string fail to halt on 
the empty string?

If we utterly avoid any sense of weasel wording, we can say that the 
Turing Machine defined by the empty string neither halts nor fails to 
halt regardless of it input. To require the forced (yes or no) answer to 
this question is inherently erroneous.
0
NoSpam271 (937)
3/31/2012 2:31:00 AM
On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
> No we don't because all questions of the form "does machine t halt on
> input i" have correct yes/no answers.  I've said a little more on that
> elsewhere as well.  The actual question is "does my input represent a
> machine and string pair such that the machine halts when run on the
> string".  If the input does not represent what it should the correct
> answer is "no".
You just broke the halting problem. Now the halt decider can simply 
correctly halt in its reject state because its input is erroneous.

Since you just equated failing to halt with invalid input the halt 
decider can now always correctly halt in its reject state when it 
encounters Pathological Self-Reference. Since you just made the Halting 
Problem decidable, I would estimate that this is not what is meant when 
the term Halting Problem is used.
0
NoSpam271 (937)
3/31/2012 2:42:05 AM
On 3/30/2012 8:42 PM, Joshua Cranmer wrote:
> On 3/30/2012 5:40 PM, Peter Olcott wrote:
>> On 3/30/2012 9:28 AM, Joshua Cranmer wrote:
>>> The reason I ask is because, if you decide B is the set "Decidable",
>>> you can trivially reduce the general halting problem to deciding the
>>> "Decidable" set for a given Turing machine. In other words, deciding
>>> this set is exactly as hard as deciding the halting problem at large.
>>>
>>>
>> That is not true, the DecidabilityDecider() rejects any attempt at this.
>
> How can it? "Decidable" is, by your definition, well-defined for any 
> Turing machine. So any attempt to implement DecidabilityDecider must 
> also work for the Turing machine I enumerated. In the case I gave, the 
> "Decidable" set for that Turing machine is precisely the set which 
> represents the Halting problem. Therefore, if DecidabilityDecider were 
> to work properly, it must solve the Halting problem itself.

Whenever the DecibilityDecider() encounters any instance of the Halting 
Problem, it simply correctly halts in its own reject state, indicating 
undecidability.

A different DecibilityDecider() is provided for each decision criterion.
The DecibilityDecider() that I have been referring to is specific to TM 
halting.

It does not solve the Halting Problem, it simply correctly rejects 
instances of Pathological Self-Reference (or other forms of erroneous 
input).
0
NoSpam271 (937)
3/31/2012 2:49:21 AM
On Mar 30, 7:16=A0pm, Leif Roar Moldskred <le...@dimnakorr.com> wrote:
> No, the question is still "Does program P halt on input I." That's
> _always_ the question for a halting decider,

Careful:  A halting decider DOES NOT EXIST.
0
greeneg9613 (188)
3/31/2012 4:39:40 AM
On Mar 30, 9:38=A0pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> You're wasting your breath. In a post, he admitted that he believes that
> the correctness of a question is dependent on the machine of which it is
> asked, so "halts(P, I)" has a different value if a machine purporting to
> implement halts is a subprogram of P.

We're not wasting anything.  The operative word here is a machine
PURPORTING TO
implement halts.  TURING MACHINES *DON'T* purport.  THEY JUST DO WHAT
THEY DO.
I blame Ben.  He started the trend of accepting P.O.'s incoherent
definitions.
The right response, EVERY time P.O. tried to talk about "a halt
analyzer", was
just to say "THERE IS NO SUCH THING, DUMBASS".
0
greeneg9613 (188)
3/31/2012 4:41:15 AM
On Mar 30, 6:17=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> This particular error is somewhat understandable because we've all been
> very lax about specifying encodings and, even, exactly what a decision
> problem is.

Not ALL of us.  Mostly YOU.
But better late than never.
0
greeneg9613 (188)
3/31/2012 4:43:51 AM
On Mar 30, 6:17=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> For halting, the predicate P(s) is "does s encode a <t, i> pair such
> that t halts when run on input i".

Now you're being kind of ridiculous.  The WHOLE point is that
PREDICATES
are DIFFERENT from TMs, EVEN THOUGH THEIR SPECIFICATION LANGUAGES
LOOK VERY SIMILAR, so similar that P.O. CAN'T TELL THE DIFFERENCE.
This is precisely why he "thinks he can define a TM to do whatever he
wants to",
as you so correctly put it earlier.  He can't tell the difference
between specifying
a predicate (that might or might not be TM-computable) and specifying
pseudo-
code for an actual TM.

More to the point, what you are saying here does NOT match P.O.'s
specification of
what a bug-free halt-analyzer is supposed to do.  If the answer to
your predicate
is "no" because the (single) input string does not properly encode the
pair, then
you will want a TM that reject-halts.  But P.O. wants a TM that reject-
halts only
when given a t and i such t that t doesn't halt on i.  English poems
in the t-
parameter are cases HE considers "undecidable for" his analyzer.
That's an
abuse of language on his part but you are WAY LATE in calling him on
it.
If you had whacked him between the eyes WITH THE ACTUAL MEANING of
"decidable",
LIKE I DID, we would NOT now be IN this mess.

> > Will the first English poem halt on its input of the second English
> > poem (yes or no)?
>
> That's a slightly different question because we must also consider how
> the pair is encoded. =A0But, such details permitting, a decider must stil=
l
> answer this question yes or no.

NO, a halting decider does NOT have to answer that question yes or no,
FOR TWO reasons:
1) a halting decider DOES NOT EXIST.
2) P.O. explicitly said that the way HE wants to handle this case is
by not halting on it.

>
> --
> Ben.

0
greeneg9613 (188)
3/31/2012 4:49:50 AM
On 3/30/2012 9:42 PM, Peter Olcott wrote:
> On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>> No we don't because all questions of the form "does machine t halt on
>> input i" have correct yes/no answers. I've said a little more on that
>> elsewhere as well. The actual question is "does my input represent a
>> machine and string pair such that the machine halts when run on the
>> string". If the input does not represent what it should the correct
>> answer is "no".
> You just broke the halting problem. Now the halt decider can simply
> correctly halt in its reject state because its input is erroneous.

Erroneous in the sense that its input is syntactically invalid. Note 
that you're trying to claim that these "Pathological Self-Reference" 
cases are *semantically* invalid. They are still Turing machines, which 
means, per the specification of the Halting problem, the machine must 
divine the correct answer.

> Since you just equated failing to halt with invalid input the halt
> decider can now always correctly halt in its reject state when it
> encounters Pathological Self-Reference. Since you just made the Halting
> Problem decidable, I would estimate that this is not what is meant when
> the term Halting Problem is used.

No. He did not make it decidable. Remember the formal definition of the 
Halting problem: it is the language {<M, w> | M is a Turing machine that 
halts when w is fed as input}. Note that any input string which does not 
consist of a Turing machine, input string pair is by definition not in 
this language. So it's merely part of the original definition of the 
Halting problem, just one that is usually handwaved (since detecting 
whether or not the input is of the form <M, w> is a trivial task).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 5:47:24 AM
On 3/30/2012 9:49 PM, Peter Olcott wrote:
> On 3/30/2012 8:42 PM, Joshua Cranmer wrote:
>> On 3/30/2012 5:40 PM, Peter Olcott wrote:
>>> On 3/30/2012 9:28 AM, Joshua Cranmer wrote:
>>>> The reason I ask is because, if you decide B is the set "Decidable",
>>>> you can trivially reduce the general halting problem to deciding the
>>>> "Decidable" set for a given Turing machine. In other words, deciding
>>>> this set is exactly as hard as deciding the halting problem at large.
>>>>
>>>>
>>> That is not true, the DecidabilityDecider() rejects any attempt at this.
>>
>> How can it? "Decidable" is, by your definition, well-defined for any
>> Turing machine. So any attempt to implement DecidabilityDecider must
>> also work for the Turing machine I enumerated. In the case I gave, the
>> "Decidable" set for that Turing machine is precisely the set which
>> represents the Halting problem. Therefore, if DecidabilityDecider were
>> to work properly, it must solve the Halting problem itself.
>
> Whenever the DecibilityDecider() encounters any instance of the Halting
> Problem, it simply correctly halts in its own reject state, indicating
> undecidability.

Since the full general Halting problem is undecidable, no machine can 
represent an instance of the Halting problem, so DecidabilityDecider 
would never reject an input because it is an instance of the Halting 
problem.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 5:50:04 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>> <snip>
>>> >  This is the precise specification of bug-free, do you want to continue
>>> >  to pretend that you don't understand this still?
>> Yes, I still don't understand it.  I've explained why as carefully as I
>> can in another post.  I think my concerns are legitimate.
>>
>>> >  1) Halts() halts in its accept state, where M would halt on its input
>>> >  w, this would be decidable.
>>> >  2) Halts() halts in its reject state, where M would not halt on its
>>> >  input w, this would be decidable.
>>> >  3) In the case where Halts() can not correctly halt in either its
>>> >  accept state or its reject state this would be undecidable, Halts()
>>> >  loops.
>> I*really*  hope you are not going to change the definition to this new
>> one.  I have spent some considerable time clarifying why I think your
>> previous definition is not clear (and a little odd) but this new one is
>> unclear in a whole new set of ways!

This crucial question has gone unanswered.

>>>> >>  Of course this then led to the "bug-free" means correct except for
>>>> >>  "undecidable" cases sub-thread.
>>> >  Undecidable cases are not bugs, they are erroneous input.
>>> >  What should a halt decider do when its input is a pair of English
>>> >  Poems?
>> I've answered that elsewhere too.
>>
>>> >  This is undecidable too, do we count it as a wrong answer no matter
>>> >  what the halt decider does, or do we allow the halt decider to
>>> >  indicate that the input is erroneous?
>> No we don't because all questions of the form "does machine t halt on
>> input i" have correct yes/no answers.
> Yet an English Poem is not even a Turing Machine so it can not
> possibly either halt or fail to halt. Not allowing rejecting invalid
> input is a fundamental error within computing theory. this makes the
> current definition of computing theory inherently erroneous.

Rejecting what you are calling invalid input is perfectly acceptable.
It's built in to the definition of the halting problem.

You are proposing something quite different -- a "solution" that refuses
to answer some subset of questions where the input *does* represent a
machine, input pair.

> What about the empty string?
> Does the empty string halt on the empty string (logically entailing
> the the empty string is running) or does the empty string fail to halt
> on the empty string?

The depends on the encoding.  Specify it, and I'll answer your question.
There is nothing stopping someone using a weird encoding where the empty
string represents some specif machine and input pair.

> If we utterly avoid any sense of weasel wording, we can say that the
> Turing Machine defined by the empty string neither halts nor fails to
> halt regardless of it input. To require the forced (yes or no) answer
> to this question is inherently erroneous.

No, you can't say anything about it at all without knowing the encoding
used for the inputs.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 11:12:28 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>> No we don't because all questions of the form "does machine t halt on
>> input i" have correct yes/no answers.  I've said a little more on that
>> elsewhere as well.  The actual question is "does my input represent a
>> machine and string pair such that the machine halts when run on the
>> string".  If the input does not represent what it should the correct
>> answer is "no".
> You just broke the halting problem. Now the halt decider can simply
> correctly halt in its reject state because its input is erroneous.

No.  To use the notation I defied elsewhere, if halts(t, i) then <t, i>
is in the halting set.  Any machine h with h(<t, i>) = no is not
therefore a halting decider.

> Since you just equated failing to halt with invalid input the halt
> decider can now always correctly halt in its reject state when it
> encounters Pathological Self-Reference. Since you just made the
> Halting Problem decidable, I would estimate that this is not what is
> meant when the term Halting Problem is used.

No.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 11:17:15 AM
On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
> On 3/30/2012 9:42 PM, Peter Olcott wrote:
>> On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>>> No we don't because all questions of the form "does machine t halt on
>>> input i" have correct yes/no answers. I've said a little more on that
>>> elsewhere as well. The actual question is "does my input represent a
>>> machine and string pair such that the machine halts when run on the
>>> string". If the input does not represent what it should the correct
>>> answer is "no".
>> You just broke the halting problem. Now the halt decider can simply
>> correctly halt in its reject state because its input is erroneous.
>
> Erroneous in the sense that its input is syntactically invalid. Note 
> that you're trying to claim that these "Pathological Self-Reference" 
> cases are *semantically* invalid. They are still Turing machines, 
> which means, per the specification of the Halting problem, the machine 
> must divine the correct answer.
Erroneous using your own terms:
"does my input represent a machine and string pair such that the machine 
halts when run on the string".
0
NoSpam271 (937)
3/31/2012 12:36:58 PM
On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
>> Since you just equated failing to halt with invalid input the halt
>> decider can now always correctly halt in its reject state when it
>> encounters Pathological Self-Reference. Since you just made the Halting
>> Problem decidable, I would estimate that this is not what is meant when
>> the term Halting Problem is used.
>
> No. He did not make it decidable. Remember the formal definition of 
> the Halting problem: it is the language {<M, w> | M is a Turing 
> machine that halts when w is fed as input}. Note that any input string 
> which does not consist of a Turing machine, input string pair is by 
> definition not in this language. So it's merely part of the original 
> definition of the Halting problem, just one that is usually handwaved 
> (since detecting whether or not the input is of the form <M, w> is a 
> trivial task).
You can't have it both ways:
Either it must answer whether or not an English poem halts on its input 
such that {yes, no, no answer} are all incorrect. Or it can simply 
provide "no" as a correct answer within the scope of your own defintion 
of semantically invalid input:

"does my input represent a machine and string pair such that the machine 
halts when run on the string".

Which makes the conventional halting problem decidable.
0
NoSpam271 (937)
3/31/2012 12:41:35 PM
On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
>>> How can it? "Decidable" is, by your definition, well-defined for any
>>> Turing machine. So any attempt to implement DecidabilityDecider must
>>> also work for the Turing machine I enumerated. In the case I gave, the
>>> "Decidable" set for that Turing machine is precisely the set which
>>> represents the Halting problem. Therefore, if DecidabilityDecider were
>>> to work properly, it must solve the Halting problem itself.
>>
>> Whenever the DecibilityDecider() encounters any instance of the Halting
>> Problem, it simply correctly halts in its own reject state, indicating
>> undecidability.
>
> Since the full general Halting problem is undecidable,
yes
the set of TMs that represent the Halting Problem: HP
> no machine can represent an instance of the Halting problem, 
One element of HP: h
I already did many times so you are wrong here.
> so DecidabilityDecider would never reject an input because it is an 
> instance of the Halting problem. 
false conclusion derived from false premise.
0
NoSpam271 (937)
3/31/2012 12:45:13 PM
On 3/31/2012 6:12 AM, Ben Bacarisse wrote:
> Rejecting what you are calling invalid input is perfectly acceptable.
> It's built in to the definition of the halting problem.
>
> You are proposing something quite different -- a "solution" that refuses
> to answer some subset of questions where the input*does*  represent a
> machine, input pair.
Ah no, this is the subtle error that you make.
Although the input machine and input pair does represent a machine and 
input pair (you are correct so far), it does not represent a machine 
that halts on its input. (neither does it represent a machine that fails 
to halt on its input).

Your own words: (That addressed my tm = English Poem, input)
"does my input represent a machine and string pair such that the machine 
halts when run on the string".

Let's make it a little more formal:

// This is an actual halt decider now
Boolean HaltDecider(String tm, String input)
{
   if ( Halts(tm, input) )
     return true;
   else  // Pathological Self-Reference and English Poems go here
     return false;
}

// The else also includes tm(input) not halting

0
NoSpam271 (937)
3/31/2012 1:03:45 PM
On 3/31/2012 6:17 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>>> >>  No we don't because all questions of the form "does machine t halt on
>>> >>  input i" have correct yes/no answers.  I've said a little more on that
>>> >>  elsewhere as well.  The actual question is "does my input represent a
>>> >>  machine and string pair such that the machine halts when run on the
>>> >>  string".  If the input does not represent what it should the correct
>>> >>  answer is "no".
>> >  You just broke the halting problem. Now the halt decider can simply
>> >  correctly halt in its reject state because its input is erroneous.
> No.  To use the notation I defied elsewhere, if halts(t, i) then<t, i>
> is in the halting set.  Any machine h with h(<t, i>) = no is not
> therefore a halting decider.
>

If (according to your own criterion, provided below) you are going to 
screen out t = {English Poem} then this also logically entails screening 
out instances of halts(t, i) that derive Pathological Self-Reference.

Your own words:
"does my input represent a machine and string pair such that the machine 
halts when run on the string".

translated to pseudo-code:

// This is an actual halt decider now
Boolean HaltDecider(String tm, String input)
{
   if ( Halts(tm, input) )
     return true;
   else  // Pathological Self-Reference and English Poems go here
     return false;
}

The above halt decider decides all cases of halting, and rejects both 
not halting and every possible form of invalid input.

This is much simpler (and therefore easier to understand) than my 
DecidabilityDecider() so your feedback was very helpful.
0
NoSpam271 (937)
3/31/2012 1:17:18 PM
On 3/31/2012 6:12 AM, Ben Bacarisse wrote:
>> What about the empty string?
>> >  Does the empty string halt on the empty string (logically entailing
>> >  the the empty string is running) or does the empty string fail to halt
>> >  on the empty string?
> The depends on the encoding.  Specify it, and I'll answer your question.
> There is nothing stopping someone using a weird encoding where the empty
> string represents some specif machine and input pair.
>
>> >  If we utterly avoid any sense of weasel wording, we can say that the
>> >  Turing Machine defined by the empty string neither halts nor fails to
>> >  halt regardless of it input. To require the forced (yes or no) answer
>> >  to this question is inherently erroneous.
> No, you can't say anything about it at all without knowing the encoding
> used for the inputs.
// Function Prototype
Boolean HaltDecider(String tm, String input);

// Function Invocation
HaltDecider("", "");

Does "" halt on its input "", fail to halt, or neither?
0
NoSpam271 (937)
3/31/2012 1:21:21 PM
On 3/31/2012 4:12 AM, Ben Bacarisse wrote:
....
> The depends on the encoding.  Specify it, and I'll answer your question.
> There is nothing stopping someone using a weird encoding where the empty
> string represents some specif machine and input pair.

I propose encoding the TM in the Turing Machine Markup Language
specified at http://www.unidex.com/turing/tmml.htm. Because it is based
on XML, the end of the turing-machine element can be detected. Treat the
non-blank portion of the tape following that as the input string.

Using that encoding, all strings that lack an initial "<", including the
empty string, are not in the language of TM computations that halt.

The language a halting decider using this encoding, by definition, would
have to accept comprises exactly the strings that meet all the rules for
a TMML description followed by a (possibly empty) string of the
described TM's input symbols, such that the described TM halts if run
with that string as initial tape contents.

Patricia
0
pats (3556)
3/31/2012 2:56:27 PM
On Mar 31, 8:45=A0am, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> yes
> the set of TMs that represent the Halting Problem:

That would be the empty set, dumbass.
What makes you a dumbass is your persistent refusal to learn basic
terminology.
THERE IS NO SUCH THING AS
"the set of TMs that represent the Halting Problem".
*ALL* TMs are possible as INPUTS to the halting problem,
 and *NO* TM *solves* the Halting Problem.
It just plain does NOT MEAN ANYthing for a TM "to represent the
Halting Problem".

Tragically, you still don't know what a PROBLEM is.
That's right, "Problem" IS A TECHNICAL TERM around here.
The fact that Ben didn't whack you between the eyes with THAT
to START with is original sin.
0
greeneg9613 (188)
3/31/2012 3:16:20 PM
On Mar 31, 9:03=A0am, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> Although the input machine and input pair does represent a machine and
> input pair (you are correct so far), it does not represent a machine
> that halts on its input. (neither does it represent a machine that fails
> to halt on its input).

Peter, you are JUST LYING!
If the pair represents a TM and some input then IT NECESSARILY
represents either a machine that halts on that input or a machine
that doesn't halt in that input.  EVERY TM either halts, or doesn't
halt,
ON EVERY input.  BY DEFINITION.  This is NOT something you
OR ANYONE even *GETS* to have an OPINION about!

It is NOT like you are someday going to present both a TM
and a finite input string for it with the property that the TM
neither halts nor fails-to-halt on the string!!
0
greeneg9613 (188)
3/31/2012 3:18:42 PM
On Mar 31, 9:21=A0am, Peter Olcott <NoS...@OCR4Screen.com> wrote:

> // Function Prototype
> Boolean HaltDecider(String tm, String input);
>
> // Function Invocation
> HaltDecider("", "");
>
> Does "" halt on its input "", fail to halt, or neither?

Your prototype IS COMPLETELY EMPTY, so there IS NO telling WHAT it
might or might not do!
It is not necessary for EVERY string to represent SOME TM, but it IS
POSSIBLE.
You can CHOOSE TO ENCODE your TM descriptions such that everything,
INCLUDING the
empty string and INCLUDING all English poems, represents a TM.
0
greeneg9613 (188)
3/31/2012 3:24:55 PM
On Mar 31, 1:47=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> Remember the formal definition of the
> Halting problem: it is the language {<M, w> | M is a Turing machine that
> halts when w is fed as input}.

This is NOT what you want to use.  The universal turing machine
accepts this language just fine.  The universal TM is the TM that
halts on and only on
this language.  What you need is a machine that, in addition to
getting all the yes
answers right as U does, also gets all the no answers right.  Defining
the halting
problem as a language here is a bit ridiculous.
A problem is an infinite collection of questions.
It's decidable iff there is a TM that answers all the questions
correctly.
This is NOT the same thing as "there's a TM that accepts the language
of all the yes answers".
THAT's recursively enumerable or SEMI-decidable.

0
greeneg9613 (188)
3/31/2012 3:57:44 PM
On Mar 31, 4:12=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Peter Olcott <NoS...@OCR4Screen.com> writes:
> > On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
> >> Peter Olcott<NoS...@OCR4Screen.com> =A0writes:
> >> <snip>
> >>> > =A0This is the precise specification of bug-free, do you want to co=
ntinue
> >>> > =A0to pretend that you don't understand this still?
> >> Yes, I still don't understand it. =A0I've explained why as carefully a=
s I
> >> can in another post. =A0I think my concerns are legitimate.
>
> >>> > =A01) Halts() halts in its accept state, where M would halt on its =
input
> >>> > =A0w, this would be decidable.
> >>> > =A02) Halts() halts in its reject state, where M would not halt on =
its
> >>> > =A0input w, this would be decidable.
> >>> > =A03) In the case where Halts() can not correctly halt in either it=
s
> >>> > =A0accept state or its reject state this would be undecidable, Halt=
s()
> >>> > =A0loops.
> >> I*really* =A0hope you are not going to change the definition to this n=
ew
> >> one. =A0I have spent some considerable time clarifying why I think you=
r
> >> previous definition is not clear (and a little odd) but this new one i=
s
> >> unclear in a whole new set of ways!
>
> This crucial question has gone unanswered.
>
>
>
>
>
> >>>> >> =A0Of course this then led to the "bug-free" means correct except=
 for
> >>>> >> =A0"undecidable" cases sub-thread.
> >>> > =A0Undecidable cases are not bugs, they are erroneous input.
> >>> > =A0What should a halt decider do when its input is a pair of Englis=
h
> >>> > =A0Poems?
> >> I've answered that elsewhere too.
>
> >>> > =A0This is undecidable too, do we count it as a wrong answer no mat=
ter
> >>> > =A0what the halt decider does, or do we allow the halt decider to
> >>> > =A0indicate that the input is erroneous?
> >> No we don't because all questions of the form "does machine t halt on
> >> input i" have correct yes/no answers.
> > Yet an English Poem is not even a Turing Machine so it can not
> > possibly either halt or fail to halt. Not allowing rejecting invalid
> > input is a fundamental error within computing theory. this makes the
> > current definition of computing theory inherently erroneous.
>
> Rejecting what you are calling invalid input is perfectly acceptable.
> It's built in to the definition of the halting problem.
>
> You are proposing something quite different -- a "solution" that refuses
> to answer some subset of questions where the input *does* represent a
> machine, input pair.
>
> > What about the empty string?
> > Does the empty string halt on the empty string (logically entailing
> > the the empty string is running) or does the empty string fail to halt
> > on the empty string?
>
> The depends on the encoding. =A0Specify it, and I'll answer your question=
..
> There is nothing stopping someone using a weird encoding where the empty
> string represents some specif machine and input pair.
>
> > If we utterly avoid any sense of weasel wording, we can say that the
> > Turing Machine defined by the empty string neither halts nor fails to
> > halt regardless of it input. To require the forced (yes or no) answer
> > to this question is inherently erroneous.
>
> No, you can't say anything about it at all without knowing the encoding
> used for the inputs.
>
> --
> Ben.


TM is tape and read-head.

The program is finite.

The only problem is that pointers can just go forward and loop, yeah,
so it's n in space to store all previous nodes and n^2 in time (for
that) to see if a loop is reached.  So yeah there's another turing
machine for that, with a write-head.

If the program is infinite in that it never terminates or loops, by
the pigeonhole principle it goes out of bounds of any complete finite
reconstruction of all the programs less than a given information
content.  Yet, there's always room on the second tape to make
progress.

If you let infinite programs in to the language, then, yes, from
starting at the beginning of that program it could take forever to
simply follow it, where at each tape offset with a number there is a
number where it goes, and if it lands on zero it returns void.

Then if you had infinitely many writeble turing machines, or two, you
could book-keep starting from each of the offsets.  Then, still, a
pathological program as simple as pointing to the next number would
see none of those ever complete.  Then it gets into being an infinite
sequence, the program, where given a terse encoding, certain infinite
sequences are written in single letters.  Work those out.

Then, working through all statistical inference there, and coding,
what's left is a program that is a random number.  That is to say, no
program emits this number, to be a program, and, programs aren't
random on the TM (and where they are they would almost invariably halt
in random walks, as they pass the origin).

Then, perhaps, there is no program so random that:  it doesn't have
any structure.

You can exhaust all the finite programs from a corpus of strings (here
themselves TMs, random access sequences).  Then what's left isn't a
program.  That takes as long as it takes.

Right then,

Ross Finlayson
0
3/31/2012 4:18:09 PM
On 3/31/2012 8:17 AM, Peter Olcott wrote:
> The above halt decider decides all cases of halting, and rejects both
> not halting and every possible form of invalid input.

A Turing machine that consists of "Pathological self-reference" is not 
invalid input in the sense of the Halting problem. The "valid inputs" 
are precisely those which consist of a Turing machine and input string 
pair. You are redefining the halting problem to exclude cases that are, 
in your view, semantically incorrect.

I thought we had settled this matter a month ago?

In any case, you have still not given any indication that it is possible 
to detect "Pathological self-reference", not least because you haven't 
given a precise, formal definition that would allow you to define a 
language for it in the first place.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 4:30:42 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
>>> Since you just equated failing to halt with invalid input the halt
>>> decider can now always correctly halt in its reject state when it
>>> encounters Pathological Self-Reference. Since you just made the Halting
>>> Problem decidable, I would estimate that this is not what is meant when
>>> the term Halting Problem is used.
>>
>> No. He did not make it decidable. Remember the formal definition of
>> the Halting problem: it is the language {<M, w> | M is a Turing
>> machine that halts when w is fed as input}. Note that any input
>> string which does not consist of a Turing machine, input string pair
>> is by definition not in this language. So it's merely part of the
>> original definition of the Halting problem, just one that is usually
>> handwaved (since detecting whether or not the input is of the form
>> <M, w> is a trivial task).
> You can't have it both ways:
> Either it must answer whether or not an English poem halts on its
> input such that {yes, no, no answer} are all incorrect.

What does this option mean?  It must answer yes/no for all inputs, poems
and all.  Further the answer must be "correct" (h(s) = yes iff s in
{<t, i>} and halts(t, i)).

> Or it can
> simply provide "no" as a correct answer within the scope of your own
> defintion of semantically invalid input:

No, a poem might be represent a machine, input pair.  Alternatively a
Vogan might think that some <t,i> string makes a pretty good poem.
No matter what you call the input, the correct yes/no answer must be
provided. 

> "does my input represent a machine and string pair such that the
> machine halts when run on the string".
>
> Which makes the conventional halting problem decidable.

Eh?  That's just the specification.  It's only decidable if a machine
can pick out the halting cases.  There's a proof that no such machine
exists.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 4:31:29 PM
On 3/31/2012 7:45 AM, Peter Olcott wrote:
> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
>>>> How can it? "Decidable" is, by your definition, well-defined for any
>>>> Turing machine. So any attempt to implement DecidabilityDecider must
>>>> also work for the Turing machine I enumerated. In the case I gave, the
>>>> "Decidable" set for that Turing machine is precisely the set which
>>>> represents the Halting problem. Therefore, if DecidabilityDecider were
>>>> to work properly, it must solve the Halting problem itself.
>>>
>>> Whenever the DecibilityDecider() encounters any instance of the Halting
>>> Problem, it simply correctly halts in its own reject state, indicating
>>> undecidability.
>>
>> Since the full general Halting problem is undecidable,
> yes
> the set of TMs that represent the Halting Problem: HP

No TM can solve the Halting problem. That is what undecidable means. HP 
is necessarily empty.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 4:31:46 PM
On 3/31/2012 7:41 AM, Peter Olcott wrote:
> On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
>>> Since you just equated failing to halt with invalid input the halt
>>> decider can now always correctly halt in its reject state when it
>>> encounters Pathological Self-Reference. Since you just made the Halting
>>> Problem decidable, I would estimate that this is not what is meant when
>>> the term Halting Problem is used.
>>
>> No. He did not make it decidable. Remember the formal definition of
>> the Halting problem: it is the language {<M, w> | M is a Turing
>> machine that halts when w is fed as input}. Note that any input string
>> which does not consist of a Turing machine, input string pair is by
>> definition not in this language. So it's merely part of the original
>> definition of the Halting problem, just one that is usually handwaved
>> (since detecting whether or not the input is of the form <M, w> is a
>> trivial task).
> You can't have it both ways:
> Either it must answer whether or not an English poem halts on its input
> such that {yes, no, no answer} are all incorrect. Or it can simply
> provide "no" as a correct answer within the scope of your own defintion
> of semantically invalid input:
>
> "does my input represent a machine and string pair such that the machine
> halts when run on the string".
>
> Which makes the conventional halting problem decidable.

No, it does not. Regardless of what you believe, the diagonalization 
argument for the conventional halting problem still proves it 
undecidable. You are arguing that it doesn't only on the basis that the 
machine in question neither halts nor fails to halt, a claim which is 
trivially false.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 4:33:19 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 6:12 AM, Ben Bacarisse wrote:
>> Rejecting what you are calling invalid input is perfectly acceptable.
>> It's built in to the definition of the halting problem.
>>
>> You are proposing something quite different -- a "solution" that refuses
>> to answer some subset of questions where the input*does*  represent a
>> machine, input pair.
> Ah no, this is the subtle error that you make.
> Although the input machine and input pair does represent a machine and
> input pair (you are correct so far), it does not represent a machine
> that halts on its input. (neither does it represent a machine that
> fails to halt on its input).

That's not a subtle error that I am making, it a gross error that you
are making.  A Turing machine either halts or it does not.  You may want
to talk about another kind of machine -- go ahead -- but please stop
wasting our time by calling your problem "the halting problem".

> Your own words: (That addressed my tm = English Poem, input)
> "does my input represent a machine and string pair such that the
> machine halts when run on the string".
>
> Let's make it a little more formal:
>
> // This is an actual halt decider now
> Boolean HaltDecider(String tm, String input)
> {
>   if ( Halts(tm, input) )
>     return true;
>   else  // Pathological Self-Reference and English Poems go here
>     return false;
> }
>
> // The else also includes tm(input) not halting

How is that more formal?  What is Halts?  What is Pathological
Self-Reference?  (You've never defined this term.)  Why are you
returning false for a poem?  The correct answer may be "true".  How do
you propose detecting a poem?

I used a notation that did make these points clear.  Yours is just
hand-waving.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 4:40:15 PM
Patricia Shanahan <pats@acm.org> writes:

> On 3/31/2012 4:12 AM, Ben Bacarisse wrote:
> ...
>> The depends on the encoding.  Specify it, and I'll answer your question.
>> There is nothing stopping someone using a weird encoding where the empty
>> string represents some specif machine and input pair.
>
> I propose encoding the TM in the Turing Machine Markup Language
> specified at http://www.unidex.com/turing/tmml.htm. Because it is based
> on XML, the end of the turing-machine element can be detected. Treat the
> non-blank portion of the tape following that as the input string.
>
> Using that encoding, all strings that lack an initial "<", including the
> empty string, are not in the language of TM computations that halt.
>
> The language a halting decider using this encoding, by definition, would
> have to accept comprises exactly the strings that meet all the rules for
> a TMML description followed by a (possibly empty) string of the
> described TM's input symbols, such that the described TM halts if run
> with that string as initial tape contents.

An excellent suggestion.  I've edited my rely to reflect it.

Peter will no doubt reject such a clear example, and prefer, instead, to
keep using pseudo-code and an unspecified encoding.  But it's worth a try.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 4:58:53 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 6:17 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> >  On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>>>> >>  No we don't because all questions of the form "does machine t halt on
>>>> >>  input i" have correct yes/no answers.  I've said a little more on that
>>>> >>  elsewhere as well.  The actual question is "does my input represent a
>>>> >>  machine and string pair such that the machine halts when run on the
>>>> >>  string".  If the input does not represent what it should the correct
>>>> >>  answer is "no".
>>> >  You just broke the halting problem. Now the halt decider can simply
>>> >  correctly halt in its reject state because its input is erroneous.
>> No.  To use the notation I defied elsewhere, if halts(t, i) then<t, i>
>> is in the halting set.  Any machine h with h(<t, i>) = no is not
>> therefore a halting decider.
>>
>
> If (according to your own criterion, provided below) you are going to
> screen out t = {English Poem} then this also logically entails
> screening out instances of halts(t, i) that derive Pathological
> Self-Reference.

First, I did not say that poems should be "screened out".

> Your own words:
> "does my input represent a machine and string pair such that the
> machine halts when run on the string".

If "Pathological Self-Reference" means that the input does not represent
an encoded <t, i> pair such that halts(t, i) = true then a halting
decider must reject the string.  This is not "screening out" -- it's
getting the answer right.  Of course, I have no idea what PSR is, so I
have no idea what a halting decider should really do with such input,
but if it means the input does not represent a halting <t,i> pair, then
answer is easy.

> translated to pseudo-code:
>
> // This is an actual halt decider now
> Boolean HaltDecider(String tm, String input)
> {
>   if ( Halts(tm, input) )
>     return true;
>   else  // Pathological Self-Reference and English Poems go here
>     return false;
> }
>
> The above halt decider decides all cases of halting, and rejects both
> not halting and every possible form of invalid input.
>
> This is much simpler (and therefore easier to understand) than my
> DecidabilityDecider() so your feedback was very helpful.

(1) It's incorrect to reject English poems out right.  (2) What is
"Halts"?  (3) What is "Pathological Self-Reference".

Taking a stab at guessing what you mean, the above is nonsense, since
your best definition yet for what "Halts" can be is a "bug-free" machine
that can loop on some inputs.

I am glad, though, I am being helpful, but I can't yet see the fruits of
it myself.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 5:00:14 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 6:12 AM, Ben Bacarisse wrote:
>>> What about the empty string?
>>> >  Does the empty string halt on the empty string (logically entailing
>>> >  the the empty string is running) or does the empty string fail to halt
>>> >  on the empty string?
>> The depends on the encoding.  Specify it, and I'll answer your question.
>> There is nothing stopping someone using a weird encoding where the empty
>> string represents some specif machine and input pair.
>>
>>> >  If we utterly avoid any sense of weasel wording, we can say that the
>>> >  Turing Machine defined by the empty string neither halts nor fails to
>>> >  halt regardless of it input. To require the forced (yes or no) answer
>>> >  to this question is inherently erroneous.
>> No, you can't say anything about it at all without knowing the encoding
>> used for the inputs.
> // Function Prototype
> Boolean HaltDecider(String tm, String input);
>
> // Function Invocation
> HaltDecider("", "");
>
> Does "" halt on its input "", fail to halt, or neither?

How should I know?  What's the encoding?  Are we to assume the encoding
is plain text pseudo-code?  If so, you'll have to tell me the meaning of
an empty string.  In some languages it's a valid program, but your
pseudo-code is not that well-defined for me to know the answer.

Patricia has suggest using a specific, well-defined encoding:

  http://www.unidex.com/turing/tmml.htm

I suggest we use that, rather so that there will be fewer hypothetical
questions.  Using that encoding, a halting decider must answer "no" when
the tape does not start with a '<'.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 5:02:36 PM
On Mar 31, 9:18=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
wrote:
> On Mar 31, 4:12=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>
>
>
>
> > Peter Olcott <NoS...@OCR4Screen.com> writes:
> > > On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
> > >> Peter Olcott<NoS...@OCR4Screen.com> =A0writes:
> > >> <snip>
> > >>> > =A0This is the precise specification of bug-free, do you want to =
continue
> > >>> > =A0to pretend that you don't understand this still?
> > >> Yes, I still don't understand it. =A0I've explained why as carefully=
 as I
> > >> can in another post. =A0I think my concerns are legitimate.
>
> > >>> > =A01) Halts() halts in its accept state, where M would halt on it=
s input
> > >>> > =A0w, this would be decidable.
> > >>> > =A02) Halts() halts in its reject state, where M would not halt o=
n its
> > >>> > =A0input w, this would be decidable.
> > >>> > =A03) In the case where Halts() can not correctly halt in either =
its
> > >>> > =A0accept state or its reject state this would be undecidable, Ha=
lts()
> > >>> > =A0loops.
> > >> I*really* =A0hope you are not going to change the definition to this=
 new
> > >> one. =A0I have spent some considerable time clarifying why I think y=
our
> > >> previous definition is not clear (and a little odd) but this new one=
 is
> > >> unclear in a whole new set of ways!
>
> > This crucial question has gone unanswered.
>
> > >>>> >> =A0Of course this then led to the "bug-free" means correct exce=
pt for
> > >>>> >> =A0"undecidable" cases sub-thread.
> > >>> > =A0Undecidable cases are not bugs, they are erroneous input.
> > >>> > =A0What should a halt decider do when its input is a pair of Engl=
ish
> > >>> > =A0Poems?
> > >> I've answered that elsewhere too.
>
> > >>> > =A0This is undecidable too, do we count it as a wrong answer no m=
atter
> > >>> > =A0what the halt decider does, or do we allow the halt decider to
> > >>> > =A0indicate that the input is erroneous?
> > >> No we don't because all questions of the form "does machine t halt o=
n
> > >> input i" have correct yes/no answers.
> > > Yet an English Poem is not even a Turing Machine so it can not
> > > possibly either halt or fail to halt. Not allowing rejecting invalid
> > > input is a fundamental error within computing theory. this makes the
> > > current definition of computing theory inherently erroneous.
>
> > Rejecting what you are calling invalid input is perfectly acceptable.
> > It's built in to the definition of the halting problem.
>
> > You are proposing something quite different -- a "solution" that refuse=
s
> > to answer some subset of questions where the input *does* represent a
> > machine, input pair.
>
> > > What about the empty string?
> > > Does the empty string halt on the empty string (logically entailing
> > > the the empty string is running) or does the empty string fail to hal=
t
> > > on the empty string?
>
> > The depends on the encoding. =A0Specify it, and I'll answer your questi=
on.
> > There is nothing stopping someone using a weird encoding where the empt=
y
> > string represents some specif machine and input pair.
>
> > > If we utterly avoid any sense of weasel wording, we can say that the
> > > Turing Machine defined by the empty string neither halts nor fails to
> > > halt regardless of it input. To require the forced (yes or no) answer
> > > to this question is inherently erroneous.
>
> > No, you can't say anything about it at all without knowing the encoding
> > used for the inputs.
>
> > --
> > Ben.
>
> TM is tape and read-head.
>
> The program is finite.
>
> The only problem is that pointers can just go forward and loop, yeah,
> so it's n in space to store all previous nodes and n^2 in time (for
> that) to see if a loop is reached. =A0So yeah there's another turing
> machine for that, with a write-head.
>
> If the program is infinite in that it never terminates or loops, by
> the pigeonhole principle it goes out of bounds of any complete finite
> reconstruction of all the programs less than a given information
> content. =A0Yet, there's always room on the second tape to make
> progress.
>
> If you let infinite programs in to the language, then, yes, from
> starting at the beginning of that program it could take forever to
> simply follow it, where at each tape offset with a number there is a
> number where it goes, and if it lands on zero it returns void.
>
> Then if you had infinitely many writeble turing machines, or two, you
> could book-keep starting from each of the offsets. =A0Then, still, a
> pathological program as simple as pointing to the next number would
> see none of those ever complete. =A0Then it gets into being an infinite
> sequence, the program, where given a terse encoding, certain infinite
> sequences are written in single letters. =A0Work those out.
>
> Then, working through all statistical inference there, and coding,
> what's left is a program that is a random number. =A0That is to say, no
> program emits this number, to be a program, and, programs aren't
> random on the TM (and where they are they would almost invariably halt
> in random walks, as they pass the origin).
>
> Then, perhaps, there is no program so random that: =A0it doesn't have
> any structure.
>
> You can exhaust all the finite programs from a corpus of strings (here
> themselves TMs, random access sequences). =A0Then what's left isn't a
> program. =A0That takes as long as it takes.
>
> Right then,
>
> Ross Finlayson

So, those are the inputs and for each they complete (or an infinite
program has all content exhausted, if it doesn't halt it has no
content, or rather, it is its content and all the other entry points
as origin to the TM could or would follow through to it, the mode).

Then, Rice says no, that's constructive but not complete.

And, I say it's complete.

Right then,

Ross Finlayson
0
3/31/2012 5:13:11 PM
Ben Bacarisse writes:
> Peter Olcott writes:
....
> > Or it can simply provide "no" as a correct answer within the scope
> > of your own defintion of semantically invalid input:
> 
> No, a poem might be represent a machine, input pair.  Alternatively
> a Vogan might think that some <t,i> string makes a pretty good poem.
> No matter what you call the input, the correct yes/no answer must be
> provided.

No poem describing an actual machine could be found by the present
poster, but they were delighted to find, as a by-product of the
attempted search, a poem describing the undecidability of halting:

      <http://www.lel.ed.ac.uk/~gpullum/loopsnoop.html>
0
jpiitula2 (679)
3/31/2012 5:17:37 PM
On 3/31/2012 9:56 AM, Patricia Shanahan wrote:
> On 3/31/2012 4:12 AM, Ben Bacarisse wrote:
> ...
>> The depends on the encoding.  Specify it, and I'll answer your question.
>> There is nothing stopping someone using a weird encoding where the empty
>> string represents some specif machine and input pair.
>
> I propose encoding the TM in the Turing Machine Markup Language
> specified at http://www.unidex.com/turing/tmml.htm. Because it is based
> on XML, the end of the turing-machine element can be detected. Treat the
> non-blank portion of the tape following that as the input string.
>
> Using that encoding, all strings that lack an initial "<", including the
> empty string, are not in the language of TM computations that halt.
>
> The language a halting decider using this encoding, by definition, would
> have to accept comprises exactly the strings that meet all the rules for
> a TMML description followed by a (possibly empty) string of the
> described TM's input symbols, such that the described TM halts if run
> with that string as initial tape contents.
>
> Patricia

How does it represent the empty string?
0
NoSpam271 (937)
3/31/2012 5:47:03 PM
> On 3/31/2012 9:56 AM, Patricia Shanahan wrote:
> > I propose encoding the TM in the Turing Machine Markup Language
> > specified athttp://www.unidex.com/turing/tmml.htm. Because it is based
> > on XML, the end of the turing-machine element can be detected. Treat the
> > non-blank portion of the tape following that as the input string.

On Mar 31, 1:47 pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> How does it represent the empty string?

"It" here means TMML.
TMML *doesn't care* about "representing the empty string".
The things that TMML represents ARE TURING MACHINES.
In other words, your question IS SEMANTICALLY ILL-FORMED.
Semantically correct questions of the form "How does TMML represent
X ?"
REQUIRE X TO BE A TM!!
The X-hole in that form is OF TYPE *TM*, NOT type STRING!

Your question is in fact exactly BACKWARDS.
What you MEANT was, in TMML, what TM/PROGRAM does THE EMPTY STRING
represent.



0
greeneg9613 (188)
3/31/2012 6:53:12 PM
Peter Olcott wrote:
> On 3/31/2012 9:56 AM, Patricia Shanahan wrote:
>> On 3/31/2012 4:12 AM, Ben Bacarisse wrote:
>> ...
>>> The depends on the encoding.  Specify it, and I'll answer your question.
>>> There is nothing stopping someone using a weird encoding where the empty
>>> string represents some specif machine and input pair.
>>
>> I propose encoding the TM in the Turing Machine Markup Language
>> specified at http://www.unidex.com/turing/tmml.htm. Because it is based
>> on XML, the end of the turing-machine element can be detected. Treat the
>> non-blank portion of the tape following that as the input string.
>>
>> Using that encoding, all strings that lack an initial "<", including the
>> empty string, are not in the language of TM computations that halt.
>>
>> The language a halting decider using this encoding, by definition, would
>> have to accept comprises exactly the strings that meet all the rules for
>> a TMML description followed by a (possibly empty) string of the
>> described TM's input symbols, such that the described TM halts if run
>> with that string as initial tape contents.
>>
>> Patricia
> 
> How does it represent the empty string?

If you mean as an input to the TM, by having blank tape immediately
after the ">" at the end of the turing-machine element.

Of course, a completely empty string, without a TM, is represented, as
usual, by a tape containing only blanks. It should be rejected by a
halting decider using this encoding.

Patricia
0
pats (3556)
3/31/2012 7:23:53 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 9:56 AM, Patricia Shanahan wrote:
>> On 3/31/2012 4:12 AM, Ben Bacarisse wrote:
>> ...
>>> The depends on the encoding.  Specify it, and I'll answer your question.
>>> There is nothing stopping someone using a weird encoding where the empty
>>> string represents some specif machine and input pair.
>>
>> I propose encoding the TM in the Turing Machine Markup Language
>> specified at http://www.unidex.com/turing/tmml.htm. Because it is based
>> on XML, the end of the turing-machine element can be detected. Treat the
>> non-blank portion of the tape following that as the input string.
>>
>> Using that encoding, all strings that lack an initial "<", including the
>> empty string, are not in the language of TM computations that halt.
>>
>> The language a halting decider using this encoding, by definition, would
>> have to accept comprises exactly the strings that meet all the rules for
>> a TMML description followed by a (possibly empty) string of the
>> described TM's input symbols, such that the described TM halts if run
>> with that string as initial tape contents.
>>
>> Patricia
>
> How does it represent the empty string?

What's "it"?  If you mean TMML, it doesn't.  It's purpose is to represent
Turing machines, not strings.

-- 
Ben.
0
ben.usenet (6790)
3/31/2012 7:35:14 PM
On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>> Or it can
>> simply provide "no" as a correct answer within the scope of your own
>> defintion of semantically invalid input:
>
> No, a poem might be represent a machine, input pair.  Alternatively a
> Vogan might think that some<t,i>  string makes a pretty good poem.
> No matter what you call the input, the correct yes/no answer must be
> provided.

For what it's worth, there is a programming language that looks like 
Shakespearean plays: 
<http://en.wikipedia.org/wiki/Shakespeare_%28programming_language%29>. 
If you treat that as an encoding for a TM, then English poems can be TMs.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
3/31/2012 8:18:02 PM
On 3/31/2012 11:30 AM, Joshua Cranmer wrote:
> On 3/31/2012 8:17 AM, Peter Olcott wrote:
>> The above halt decider decides all cases of halting, and rejects both
>> not halting and every possible form of invalid input.
>
> A Turing machine that consists of "Pathological self-reference" is not 
> invalid input in the sense of the Halting problem. The "valid inputs" 
> are precisely those which consist of a Turing machine and input string 
> pair. You are redefining the halting problem to exclude cases that 
> are, in your view, semantically incorrect.
>

Ben's new definition of correct input determines the invalidity of input 
with Pathological Self-Reference:

"does my input represent a machine and string pair such that the machine 
halts when run on the string".

With the case of Pathological Self-Reference, the answer is simply no.

> I thought we had settled this matter a month ago?
>
> In any case, you have still not given any indication that it is 
> possible to detect "Pathological self-reference", not least because 
> you haven't given a precise, formal definition that would allow you to 
> define a language for it in the first place.
>

Any possible input that is not decidable is erroneous in one way or 
another.
0
NoSpam271 (937)
3/31/2012 10:46:59 PM
On 3/31/2012 5:46 PM, Peter Olcott wrote:
> On 3/31/2012 11:30 AM, Joshua Cranmer wrote:
>> I thought we had settled this matter a month ago?
>>
>> In any case, you have still not given any indication that it is
>> possible to detect "Pathological self-reference", not least because
>> you haven't given a precise, formal definition that would allow you to
>> define a language for it in the first place.
>>
>
> Any possible input that is not decidable is erroneous in one way or
> another.

That still isn't a definition, and it can be read to imply that you do 
not believe that detecting "Pathological self-reference" is not 
sufficient to cover all classes where a purported Halting verifier 
necessarily differs from the true Halting function.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/1/2012 12:11:38 AM
On 2012-03-31, Peter Olcott <NoSpam@OCR4Screen.com> wrote:
> On 3/31/2012 6:17 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> >  On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>>>> >>  No we don't because all questions of the form "does machine t halt on
>>>> >>  input i" have correct yes/no answers.  I've said a little more on that
>>>> >>  elsewhere as well.  The actual question is "does my input represent a
>>>> >>  machine and string pair such that the machine halts when run on the
>>>> >>  string".  If the input does not represent what it should the correct
>>>> >>  answer is "no".
>>> >  You just broke the halting problem. Now the halt decider can simply
>>> >  correctly halt in its reject state because its input is erroneous.
>> No.  To use the notation I defied elsewhere, if halts(t, i) then<t, i>
>> is in the halting set.  Any machine h with h(<t, i>) = no is not
>> therefore a halting decider.
>>
>
> If (according to your own criterion, provided below) you are going to 
> screen out t = {English Poem} then this also logically entails screening 
> out instances of halts(t, i) that derive Pathological Self-Reference.
>
> Your own words:
> "does my input represent a machine and string pair such that the machine 
> halts when run on the string".
>
> translated to pseudo-code:
>
> // This is an actual halt decider now
> Boolean HaltDecider(String tm, String input)
> {
>    if ( Halts(tm, input) )
>      return true;
>    else  // Pathological Self-Reference and English Poems go here
>      return false;
> }
>
> The above halt decider decides all cases of halting, and rejects both 
> not halting and every possible form of invalid input.
>
> This is much simpler (and therefore easier to understand) than my 
> DecidabilityDecider() so your feedback was very helpful.

Ha! I've decided to stay quiet in this discussion so far, but this one
is truly hilarious. Olcott has finally managed to state his proposed
algorithm in such a simple way that I can follow it. It proves the
following theorem:

  If there exists a machine that decides halting, then we can devise
  another machine with a different name that ALSO decides halting.

He had just formulated it in such overly complicated and ill-defined
terms that it took hundreds of posts to figure out what it was all
about. (Of course, it's an awfully useless theorem as there still
doesn't exist any machine that decides halting.)

Now, let's call the above Olcott's Theorem and finally get back to doing
something more useful in our precious spare time! :-)
0
J1768 (7)
4/1/2012 10:38:21 AM
On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
>>>> >>>  Since you just equated failing to halt with invalid input the halt
>>>> >>>  decider can now always correctly halt in its reject state when it
>>>> >>>  encounters Pathological Self-Reference. Since you just made the Halting
>>>> >>>  Problem decidable, I would estimate that this is not what is meant when
>>>> >>>  the term Halting Problem is used.
>>> >>
>>> >>  No. He did not make it decidable. Remember the formal definition of
>>> >>  the Halting problem: it is the language {<M, w>  | M is a Turing
>>> >>  machine that halts when w is fed as input}. Note that any input
>>> >>  string which does not consist of a Turing machine, input string pair
>>> >>  is by definition not in this language. So it's merely part of the
>>> >>  original definition of the Halting problem, just one that is usually
>>> >>  handwaved (since detecting whether or not the input is of the form
>>> >>  <M, w>  is a trivial task).
>> >  You can't have it both ways:
>> >  Either it must answer whether or not an English poem halts on its
>> >  input such that {yes, no, no answer} are all incorrect.
> What does this option mean?  It must answer yes/no for all inputs, poems
> and all.  Further the answer must be "correct" (h(s) = yes iff s in
> {<t, i>} and halts(t, i)).
>
It is merely an arbitrary convention that an answer must be provided. 
The specification of a Turing Machine does not require an answer, thus 
when one is categorically exhaustively examining *all* of the 
possibilities leaving out the third option forms an incomplete analysis.
0
NoSpam271 (937)
4/1/2012 11:11:56 AM
On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
>>>> >>>  Since you just equated failing to halt with invalid input the halt
>>>> >>>  decider can now always correctly halt in its reject state when it
>>>> >>>  encounters Pathological Self-Reference. Since you just made the Halting
>>>> >>>  Problem decidable, I would estimate that this is not what is meant when
>>>> >>>  the term Halting Problem is used.
>>> >>
>>> >>  No. He did not make it decidable. Remember the formal definition of
>>> >>  the Halting problem: it is the language {<M, w>  | M is a Turing
>>> >>  machine that halts when w is fed as input}. Note that any input
>>> >>  string which does not consist of a Turing machine, input string pair
>>> >>  is by definition not in this language. So it's merely part of the
>>> >>  original definition of the Halting problem, just one that is usually
>>> >>  handwaved (since detecting whether or not the input is of the form
>>> >>  <M, w>  is a trivial task).
>> >  You can't have it both ways:
>> >  Either it must answer whether or not an English poem halts on its
>> >  input such that {yes, no, no answer} are all incorrect.
> What does this option mean?  It must answer yes/no for all inputs, poems
> and all.  Further the answer must be "correct" (h(s) = yes iff s in
> {<t, i>} and halts(t, i)).
>
>> >  Or it can
>> >  simply provide "no" as a correct answer within the scope of your own
>> >  defintion of semantically invalid input:
> No, a poem might be represent a machine, input pair.  Alternatively a
> Vogan might think that some<t,i>  string makes a pretty good poem.
> No matter what you call the input, the correct yes/no answer must be
> provided.
>
I realized that just after I wrote this example, that is why I added the 
dual inputs of empty string to the HaltDecider.

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

// function invocation
HaltDecider("", "");

In this case the encoding is that the entire TM tape remains filled with 
the space character thus indicating that there is no input at all on the 
tape. Because a TM does not have any numerical representation of a space 
character, this can not possibly be construed as a valid TM.

So does "" halt on its input "" (yes or no)?
(1) Yes logically entails that "" is a valid TM that was running, and 
now halts.
(2) No logically entails that "" is a valid TM that remains running.

The only answer that is not a lie is:
(3) Neither
0
NoSpam271 (937)
4/1/2012 11:24:11 AM
On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
>>>> Since you just equated failing to halt with invalid input the halt
>>>> decider can now always correctly halt in its reject state when it
>>>> encounters Pathological Self-Reference. Since you just made the Halting
>>>> Problem decidable, I would estimate that this is not what is meant when
>>>> the term Halting Problem is used.
>>> No. He did not make it decidable. Remember the formal definition of
>>> the Halting problem: it is the language {<M, w>  | M is a Turing
>>> machine that halts when w is fed as input}. Note that any input
>>> string which does not consist of a Turing machine, input string pair
>>> is by definition not in this language. So it's merely part of the
>>> original definition of the Halting problem, just one that is usually
>>> handwaved (since detecting whether or not the input is of the form
>>> <M, w>  is a trivial task).
>> You can't have it both ways:
>> Either it must answer whether or not an English poem halts on its
>> input such that {yes, no, no answer} are all incorrect.
> What does this option mean?  It must answer yes/no for all inputs, poems
> and all.  Further the answer must be "correct" (h(s) = yes iff s in
> {<t, i>} and halts(t, i)).
>
>> Or it can
>> simply provide "no" as a correct answer within the scope of your own
>> defintion of semantically invalid input:
> No, a poem might be represent a machine, input pair.  Alternatively a
> Vogan might think that some<t,i>  string makes a pretty good poem.
> No matter what you call the input, the correct yes/no answer must be
> provided.
>
>> "does my input represent a machine and string pair such that the
>> machine halts when run on the string".
>>
>> Which makes the conventional halting problem decidable.
> Eh?  That's just the specification.  It's only decidable if a machine
> can pick out the halting cases.  There's a proof that no such machine
> exists.
>
Since your criterion did not presume that the TM was valid, and added 
validity checking within the decision:

"does my input represent a machine and string pair such that the machine 
halts when run on the string".

The HaltDecider() can simply correctly halt in its reject state whenever 
it encounters Pathological Self-Reference.

When one presumes that the TM/input pair is valid, and is presented with 
a TM/input pair that is not valid, and is also required to provide a 
yes/no answer regarding whether or not this invalid TM/input pair halts, 
the question is ill-formed.

Before your criterion HaltDecider("", "") must get the wrong answer if 
it is required to provide a yes/no answer.

With your criterion HaltDecider("", "") can simply correctly report "no".
It can also simply correctly report "no" whenever it encounters 
Pathological Self-Reference, or any other form of erroneous input. Your 
criterion has made semantic validation explicit.
0
NoSpam271 (937)
4/1/2012 11:39:22 AM
In comp.theory Peter Olcott <NoSpam@ocr4screen.com> wrote:
>
> It is merely an arbitrary convention that an answer must be provided. 

The "answer" from a Turing Machine is whatever is written on the tape
once the TM halts, including the tape being blank. _Every_ Turing
Machine that halts will therefore _necessarily_ provide an
answer. This follows inescapeably from the way Turing Machines are
defined.

-- 
Leif Roar Moldskred
0
leifm1143 (162)
4/1/2012 12:03:49 PM
Peter Olcott wrote:
....
> It is merely an arbitrary convention that an answer must be provided. 
....

You have written something important with which I totally agree, and
that leads to a simple way of ending this thread. (Patricia quickly
checks calendar, and sees a possible explanation. :-)

The association between the phrase "decider for language X" and the
concept of a TM that always halts in a state representing true if its
input is in X, and always halts in a state representing false if its
input is not in X, is indeed merely an arbitrary convention.

Back when theory of computation was a young topic, all sorts of
different names could have been chosen for what we actually call a
"decider". There was a significant chance it would get a German name,
because of the importance of German researchers in related areas of
mathematics and logic.

However, by now that convention is so well established that, in the
context of comp.theory or sci.logic, using "decider" for anything else
would be the fallacy of equivocation, a fallacy I know you understand
and consider objectionable - see
http://groups.google.com/group/sci.logic/msg/e1b53c513c694290.

As a practical matter, there are numerous papers and books that use 
"decider" according to the convention. Using "decider" in comp.theory or 
sci.logic for anything else would create unacceptable confusion.

If you think you have a better, more useful, concept, as I pointed out
in an earlier thread, you can, without committing any logical fallacies
at all, define a new term. I suggested something like "POdecider", but
you can pick anything that does not have an established meaning in this
context.

You can, of course, use the new term as much as you like in your own
writings. Whether anyone else can read those writings will depend partly
on how clearly you define the new term.

If you want others to use the new term you will need to do two things:

1. Publish a definition that is sufficiently clear that others can
determine whether it applies to specific cases. The clearer the
definition, the better the chances of success in step 2.

2. Convince a critical mass of researchers and computer scientists that
the new term is useful, interesting, and leads to good research questions.

Patricia

0
pats (3556)
4/1/2012 1:51:52 PM
On 4/1/2012 7:03 AM, Leif Roar Moldskred wrote:
> In comp.theory Peter Olcott<NoSpam@ocr4screen.com>  wrote:
>> It is merely an arbitrary convention that an answer must be provided.
> The "answer" from a Turing Machine is whatever is written on the tape
> once the TM halts, including the tape being blank. _Every_ Turing
> Machine that halts will therefore _necessarily_ provide an
> answer. This follows inescapeably from the way Turing Machines are
> defined.
>
It is my understanding that this is not quite true. The answer is not 
conventionally written on the tape. The answer is one of three cases:
1) halt in the accept state
2) halt in the reject state
3) loop, thus not halt in either state
No need to write anything to the tape.
0
NoSpam271 (937)
4/1/2012 2:16:53 PM
On Apr 1, 3:38=A0am, Jan Andres <J...@nAndr.es> wrote:
> On 2012-03-31, Peter Olcott <NoS...@OCR4Screen.com> wrote:
>
>
>
>
>
> > On 3/31/2012 6:17 AM, Ben Bacarisse wrote:
> >> Peter Olcott<NoS...@OCR4Screen.com> =A0writes:
>
> >>> > =A0On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
> >>>> >> =A0No we don't because all questions of the form "does machine t =
halt on
> >>>> >> =A0input i" have correct yes/no answers. =A0I've said a little mo=
re on that
> >>>> >> =A0elsewhere as well. =A0The actual question is "does my input re=
present a
> >>>> >> =A0machine and string pair such that the machine halts when run o=
n the
> >>>> >> =A0string". =A0If the input does not represent what it should the=
 correct
> >>>> >> =A0answer is "no".
> >>> > =A0You just broke the halting problem. Now the halt decider can sim=
ply
> >>> > =A0correctly halt in its reject state because its input is erroneou=
s.
> >> No. =A0To use the notation I defied elsewhere, if halts(t, i) then<t, =
i>
> >> is in the halting set. =A0Any machine h with h(<t, i>) =3D no is not
> >> therefore a halting decider.
>
> > If (according to your own criterion, provided below) you are going to
> > screen out t =3D {English Poem} then this also logically entails screen=
ing
> > out instances of halts(t, i) that derive Pathological Self-Reference.
>
> > Your own words:
> > "does my input represent a machine and string pair such that the machin=
e
> > halts when run on the string".
>
> > translated to pseudo-code:
>
> > // This is an actual halt decider now
> > Boolean HaltDecider(String tm, String input)
> > {
> > =A0 =A0if ( Halts(tm, input) )
> > =A0 =A0 =A0return true;
> > =A0 =A0else =A0// Pathological Self-Reference and English Poems go here
> > =A0 =A0 =A0return false;
> > }
>
> > The above halt decider decides all cases of halting, and rejects both
> > not halting and every possible form of invalid input.
>
> > This is much simpler (and therefore easier to understand) than my
> > DecidabilityDecider() so your feedback was very helpful.
>
> Ha! I've decided to stay quiet in this discussion so far, but this one
> is truly hilarious. Olcott has finally managed to state his proposed
> algorithm in such a simple way that I can follow it. It proves the
> following theorem:
>
> =A0 If there exists a machine that decides halting, then we can devise
> =A0 another machine with a different name that ALSO decides halting.
>
> He had just formulated it in such overly complicated and ill-defined
> terms that it took hundreds of posts to figure out what it was all
> about. (Of course, it's an awfully useless theorem as there still
> doesn't exist any machine that decides halting.)
>
> Now, let's call the above Olcott's Theorem and finally get back to doing
> something more useful in our precious spare time! :-)


Or, that you can fully encode the run of each program, whether or not
it halts.  This program is constructed somehow, no?  Basically still
any program will never leave its first "infinite loop", no it's
deterministic and can't jump out.  And for some inputs it enters a
loop, others it doesn't:  you can plain write it out for each of
those.

Then writing each of the programs as a Turing tape, you can exhaust if
it returns if you wrote the program (for programs).

Then if you want to get into consequences of the continuum of real
numbers - those are properties of those as numbers, not necessarily
TMs.  So, code them up.  While you're at it well-order them, the real
numbers.

Right then,

Ross Finlayson
0
4/1/2012 2:18:05 PM
On 3/31/2012 2:23 PM, Patricia Shanahan wrote:
> Peter Olcott wrote:
>> On 3/31/2012 9:56 AM, Patricia Shanahan wrote:
>>> On 3/31/2012 4:12 AM, Ben Bacarisse wrote:
>>> ...
>>>> The depends on the encoding.  Specify it, and I'll answer your 
>>>> question.
>>>> There is nothing stopping someone using a weird encoding where the 
>>>> empty
>>>> string represents some specif machine and input pair.
>>>
>>> I propose encoding the TM in the Turing Machine Markup Language
>>> specified at http://www.unidex.com/turing/tmml.htm. Because it is based
>>> on XML, the end of the turing-machine element can be detected. Treat 
>>> the
>>> non-blank portion of the tape following that as the input string.
>>>
>>> Using that encoding, all strings that lack an initial "<", including 
>>> the
>>> empty string, are not in the language of TM computations that halt.
>>>
>>> The language a halting decider using this encoding, by definition, 
>>> would
>>> have to accept comprises exactly the strings that meet all the rules 
>>> for
>>> a TMML description followed by a (possibly empty) string of the
>>> described TM's input symbols, such that the described TM halts if run
>>> with that string as initial tape contents.
>>>
>>> Patricia
>>
>> How does it represent the empty string?
>
> If you mean as an input to the TM, by having blank tape immediately
> after the ">" at the end of the turing-machine element.
>
> Of course, a completely empty string, without a TM, is represented, as
> usual, by a tape containing only blanks. It should be rejected by a
> halting decider using this encoding.
>
> Patricia

I don't think that the conventional Halting Problem allows for the 
rejection of a blank tape. The TM must still report the (Yes or No) 
answer regarding whether or not the TM specified by "" halts on the 
input specified by "".
0
NoSpam271 (937)
4/1/2012 2:20:41 PM
On 3/31/2012 7:11 PM, Joshua Cranmer wrote:
> On 3/31/2012 5:46 PM, Peter Olcott wrote:
>> On 3/31/2012 11:30 AM, Joshua Cranmer wrote:
>>> I thought we had settled this matter a month ago?
>>>
>>> In any case, you have still not given any indication that it is
>>> possible to detect "Pathological self-reference", not least because
>>> you haven't given a precise, formal definition that would allow you to
>>> define a language for it in the first place.
>>>
>>
>> Any possible input that is not decidable is erroneous in one way or
>> another.
>
> That still isn't a definition, and it can be read to imply that you do 
> not believe that detecting "Pathological self-reference" is not 
> sufficient to cover all classes where a purported Halting verifier 
> necessarily differs from the true Halting function.
>
When using categorically exhaustive reasoning making assumptions is 
prohibited. I just provided another example that is not decidable:
When the TM specified by "" is tested to see if it halts on its input 
"", this is also undecidable, because the TM specified by "" is not a 
valid TM.
0
NoSpam271 (937)
4/1/2012 2:24:04 PM
On 4/1/2012 6:11 AM, Peter Olcott wrote:
> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
>> What does this option mean? It must answer yes/no for all inputs, poems
>> and all. Further the answer must be "correct" (h(s) = yes iff s in
>> {<t, i>} and halts(t, i)).
>>
> It is merely an arbitrary convention that an answer must be provided.
> The specification of a Turing Machine does not require an answer, thus
> when one is categorically exhaustively examining *all* of the
> possibilities leaving out the third option forms an incomplete analysis.

The specification of a Turing machine might not require it, but the 
definition of a decidable language does. (Hint: Halting is 
Turing-recognizable, but not Turing-decidable. This is exactly because 
Halting can tell you when the answer is "yes" but not when it is "no".)

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/1/2012 2:27:20 PM
On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
> On 3/31/2012 7:45 AM, Peter Olcott wrote:
>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
>>>>> How can it? "Decidable" is, by your definition, well-defined for any
>>>>> Turing machine. So any attempt to implement DecidabilityDecider must
>>>>> also work for the Turing machine I enumerated. In the case I gave, 
>>>>> the
>>>>> "Decidable" set for that Turing machine is precisely the set which
>>>>> represents the Halting problem. Therefore, if DecidabilityDecider 
>>>>> were
>>>>> to work properly, it must solve the Halting problem itself.
>>>>
>>>> Whenever the DecibilityDecider() encounters any instance of the 
>>>> Halting
>>>> Problem, it simply correctly halts in its own reject state, indicating
>>>> undecidability.
>>>
>>> Since the full general Halting problem is undecidable,
>> yes
>> the set of TMs that represent the Halting Problem: HP
>
> No TM can solve the Halting problem. That is what undecidable means. 
> HP is necessarily empty.
>
I did not say that set of TM's that solve the Halting Problem, I said 
the set of TMs that represent (or demonstrate) the problem. All the 
textbooks represent this set as simply HP.
0
NoSpam271 (937)
4/1/2012 2:32:13 PM
On 4/1/2012 9:24 AM, Peter Olcott wrote:
> On 3/31/2012 7:11 PM, Joshua Cranmer wrote:
>> On 3/31/2012 5:46 PM, Peter Olcott wrote:
>>> On 3/31/2012 11:30 AM, Joshua Cranmer wrote:
>>>> I thought we had settled this matter a month ago?
>>>>
>>>> In any case, you have still not given any indication that it is
>>>> possible to detect "Pathological self-reference", not least because
>>>> you haven't given a precise, formal definition that would allow you to
>>>> define a language for it in the first place.
>>>>
>>>
>>> Any possible input that is not decidable is erroneous in one way or
>>> another.
>>
>> That still isn't a definition, and it can be read to imply that you do
>> not believe that detecting "Pathological self-reference" is not
>> sufficient to cover all classes where a purported Halting verifier
>> necessarily differs from the true Halting function.
>>
> When using categorically exhaustive reasoning making assumptions is
> prohibited. I just provided another example that is not decidable:
> When the TM specified by "" is tested to see if it halts on its input
> "", this is also undecidable, because the TM specified by "" is not a
> valid TM.

Deciding whether or not a specific input stream matches, say, TMML is 
perfectly well decidable (actually, even better, it's doable in 
polynomial time). Since this is possible, we can easily exclude all 
strings that are not written in TMML from the universe that the Halting 
TM need consider. If you want me to prove this: XML is a context-free 
grammar, so matching XML is doable with a PDA. On top of that, we can do 
limited semantic matching to make sure that all of the elements are 
possible--we already have programs that can do this. So there's no 
question of its decidability.

Since TMML is decidable, we can then define, say, Atm = {M concat i | M 
is a Turing machine written in TMML and i is a generic string, and M 
halts when given i as input }, and then define Rtm = {M concat i | M is 
a Turing machine written in TMML, i is a generic string, and M does not 
when given i ans input }. Then we can say that Atm is the complement of 
Rtm ... if we consider the universe to be all strings U = {M concat i | 
M is a Turing machine written i nTMML and i is a generic string}, since 
U is a decidable set and decidable sets are closed under set difference 
(Rtm = U - Atm, and Atm complement = Rtm union U complement).

The problem you have is that you want to further restrict U to the point 
where it is no longer a decidable set, which means we can't play these 
same tricks.
-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/1/2012 2:37:00 PM
On 4/1/2012 9:32 AM, Peter Olcott wrote:
> On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
>> On 3/31/2012 7:45 AM, Peter Olcott wrote:
>>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
>>>>>> How can it? "Decidable" is, by your definition, well-defined for any
>>>>>> Turing machine. So any attempt to implement DecidabilityDecider must
>>>>>> also work for the Turing machine I enumerated. In the case I gave,
>>>>>> the
>>>>>> "Decidable" set for that Turing machine is precisely the set which
>>>>>> represents the Halting problem. Therefore, if DecidabilityDecider
>>>>>> were
>>>>>> to work properly, it must solve the Halting problem itself.
>>>>>
>>>>> Whenever the DecibilityDecider() encounters any instance of the
>>>>> Halting
>>>>> Problem, it simply correctly halts in its own reject state, indicating
>>>>> undecidability.
>>>>
>>>> Since the full general Halting problem is undecidable,
>>> yes
>>> the set of TMs that represent the Halting Problem: HP
>>
>> No TM can solve the Halting problem. That is what undecidable means.
>> HP is necessarily empty.
>>
> I did not say that set of TM's that solve the Halting Problem, I said
> the set of TMs that represent (or demonstrate) the problem. All the
> textbooks represent this set as simply HP.

My textbook says nothing of the sort. Can you be more explicit about 
what you mean by "represent the problem"?

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/1/2012 2:37:57 PM
On Apr 1, 7:37=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> On 4/1/2012 9:32 AM, Peter Olcott wrote:
>
>
>
>
>
> > On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
> >> On 3/31/2012 7:45 AM, Peter Olcott wrote:
> >>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
> >>>>>> How can it? "Decidable" is, by your definition, well-defined for a=
ny
> >>>>>> Turing machine. So any attempt to implement DecidabilityDecider mu=
st
> >>>>>> also work for the Turing machine I enumerated. In the case I gave,
> >>>>>> the
> >>>>>> "Decidable" set for that Turing machine is precisely the set which
> >>>>>> represents the Halting problem. Therefore, if DecidabilityDecider
> >>>>>> were
> >>>>>> to work properly, it must solve the Halting problem itself.
>
> >>>>> Whenever the DecibilityDecider() encounters any instance of the
> >>>>> Halting
> >>>>> Problem, it simply correctly halts in its own reject state, indicat=
ing
> >>>>> undecidability.
>
> >>>> Since the full general Halting problem is undecidable,
> >>> yes
> >>> the set of TMs that represent the Halting Problem: HP
>
> >> No TM can solve the Halting problem. That is what undecidable means.
> >> HP is necessarily empty.
>
> > I did not say that set of TM's that solve the Halting Problem, I said
> > the set of TMs that represent (or demonstrate) the problem. All the
> > textbooks represent this set as simply HP.
>
> My textbook says nothing of the sort. Can you be more explicit about
> what you mean by "represent the problem"?
>
> --
> Beware of bugs in the above code; I have only proved it correct, not
> tried it. -- Donald E. Knuth


How many blank Turing tapes does it take to write it out?  1/2.

Then the paths through the Turing tape are the encodings that, in the
framework that they encode, normally and unambiguously (or
arbitrarily) represent the course of the evaluation of the framework.
This would often include arithmetic and it would be naturally founded.

Basically it has that each machine serializes its state and that's a
machine event (for a general program space of all the machines).

Then basically as long as the algorithms are deterministic it's
constructible and complete and you can't construct reversible non-
deterministic algorithms.

Ideas....

Thanks,

Ross Finlayson
0
4/1/2012 3:06:10 PM
On Apr 1, 8:06=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
wrote:
> On Apr 1, 7:37=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
>
>
>
>
>
> > On 4/1/2012 9:32 AM, Peter Olcott wrote:
>
> > > On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
> > >> On 3/31/2012 7:45 AM, Peter Olcott wrote:
> > >>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
> > >>>>>> How can it? "Decidable" is, by your definition, well-defined for=
 any
> > >>>>>> Turing machine. So any attempt to implement DecidabilityDecider =
must
> > >>>>>> also work for the Turing machine I enumerated. In the case I gav=
e,
> > >>>>>> the
> > >>>>>> "Decidable" set for that Turing machine is precisely the set whi=
ch
> > >>>>>> represents the Halting problem. Therefore, if DecidabilityDecide=
r
> > >>>>>> were
> > >>>>>> to work properly, it must solve the Halting problem itself.
>
> > >>>>> Whenever the DecibilityDecider() encounters any instance of the
> > >>>>> Halting
> > >>>>> Problem, it simply correctly halts in its own reject state, indic=
ating
> > >>>>> undecidability.
>
> > >>>> Since the full general Halting problem is undecidable,
> > >>> yes
> > >>> the set of TMs that represent the Halting Problem: HP
>
> > >> No TM can solve the Halting problem. That is what undecidable means.
> > >> HP is necessarily empty.
>
> > > I did not say that set of TM's that solve the Halting Problem, I said
> > > the set of TMs that represent (or demonstrate) the problem. All the
> > > textbooks represent this set as simply HP.
>
> > My textbook says nothing of the sort. Can you be more explicit about
> > what you mean by "represent the problem"?
>
> > --
> > Beware of bugs in the above code; I have only proved it correct, not
> > tried it. -- Donald E. Knuth
>
> How many blank Turing tapes does it take to write it out? =A01/2.
>
> Then the paths through the Turing tape are the encodings that, in the
> framework that they encode, normally and unambiguously (or
> arbitrarily) represent the course of the evaluation of the framework.
> This would often include arithmetic and it would be naturally founded.
>
> Basically it has that each machine serializes its state and that's a
> machine event (for a general program space of all the machines).
>
> Then basically as long as the algorithms are deterministic it's
> constructible and complete and you can't construct reversible non-
> deterministic algorithms.
>
> Ideas....
>
> Thanks,
>
> Ross Finlayson


Having what is an existence proof doesn't make it simple to write
planar circuits in one Turing tape.  I am using two or more myself
usually with then a theorem that it fits in a half so two is OK,
because each fits as they go together.

That is about something like the arbitrary complexity of a 3-D IC or
integrated circuit.  Now we are all used to the idea of computer chips
that are planar.  The electrons as inputs go in one side (as input
leads) and similarly there is output from the chip-scale.
(Informational, high-speed circuits vis-a-vis power, load circuits,
high speed planar ultra VLSI, very large scale integration.)  These
are driven by the clock frequency crystal pulses for their timebase.
It is called systolic like pumping your heart as the clock drives
power into the input leads.  (Here it is the planar IC not a system-on-
chip or on the bus.)  Then you can diagram the junctions of those in a
finite map and write it out and then the field equations are worked
up, for synthesis, to decide that, when electricity runs through the
real chip, that the known effects are considered about how the flow of
the electricity "really" works (or in extraordinary conditions)
because, for example, at the limits of modern and next generation
physical engineering, otherwise the map would not be complete.

Now for the 3-D VLSI, it is this:  the custom logic is free in not
just two dimensions, planar, it's free in each of the three space
dimensions.  (As well materials are moving toward complementary and
supplemental and alternative heat and light pipes, junctions.)  So for
example with my 3-D roller shifter, this is an electrical circuit,
analog devices for the general buffering of serial data into arrays
remarkably improve performance, as you might imagine, while here
representing a design problem:  under all input conditions, there is
more about them to know than what today, if we put into a TM, we would
have deterministic systems that a program we could write could
completely evaluate.

Thanks,

Ross Finlayson
0
4/1/2012 3:26:25 PM
Peter Olcott writes:
> On 4/1/2012 7:03 AM, Leif Roar Moldskred wrote:
> > In comp.theory Peter Olcott wrote:
> >> It is merely an arbitrary convention that an answer must be provided.
> > The "answer" from a Turing Machine is whatever is written on the tape
> > once the TM halts, including the tape being blank. _Every_ Turing
> > Machine that halts will therefore _necessarily_ provide an
> > answer. This follows inescapeably from the way Turing Machines are
> > defined.
> >
> It is my understanding that this is not quite true. The answer is not
> conventionally written on the tape. The answer is one of three cases:
> 1) halt in the accept state
> 2) halt in the reject state
> 3) loop, thus not halt in either state
> No need to write anything to the tape.

Turing machines are supposed to be able to compute anything that can
be computed. Think.

No, I don't mean that Turing machines can think. I mean you should.

Consider, for example, elementary arithmetic. It's computable, given
sufficient time and space and a suitable representation of a number.
Turing machines can do it, and not just in your favourite way ("What
is two plus two, yes or no?") but in the ordinary sense where the
answer is four! Where did you think that answer goes?  (It goes on the
tape.)
0
jpiitula2 (679)
4/1/2012 4:00:43 PM
On 4/1/2012 7:16 AM, Peter Olcott wrote:
> On 4/1/2012 7:03 AM, Leif Roar Moldskred wrote:
>> In comp.theory Peter Olcott<NoSpam@ocr4screen.com> wrote:
>>> It is merely an arbitrary convention that an answer must be provided.
>> The "answer" from a Turing Machine is whatever is written on the tape
>> once the TM halts, including the tape being blank. _Every_ Turing
>> Machine that halts will therefore _necessarily_ provide an
>> answer. This follows inescapeably from the way Turing Machines are
>> defined.
>>
> It is my understanding that this is not quite true. The answer is not
> conventionally written on the tape. The answer is one of three cases:
> 1) halt in the accept state
> 2) halt in the reject state
> 3) loop, thus not halt in either state
> No need to write anything to the tape.

If the third case happens, the TM, by definition, is not a decider for
any language.

Patricia
0
pats (3556)
4/1/2012 4:08:59 PM
On 4/1/2012 7:32 AM, Peter Olcott wrote:
> On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
>> On 3/31/2012 7:45 AM, Peter Olcott wrote:
>>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
>>>>>> How can it? "Decidable" is, by your definition, well-defined for any
>>>>>> Turing machine. So any attempt to implement DecidabilityDecider must
>>>>>> also work for the Turing machine I enumerated. In the case I gave,
>>>>>> the
>>>>>> "Decidable" set for that Turing machine is precisely the set which
>>>>>> represents the Halting problem. Therefore, if DecidabilityDecider
>>>>>> were
>>>>>> to work properly, it must solve the Halting problem itself.
>>>>>
>>>>> Whenever the DecibilityDecider() encounters any instance of the
>>>>> Halting
>>>>> Problem, it simply correctly halts in its own reject state, indicating
>>>>> undecidability.
>>>>
>>>> Since the full general Halting problem is undecidable,
>>> yes
>>> the set of TMs that represent the Halting Problem: HP
>>
>> No TM can solve the Halting problem. That is what undecidable means.
>> HP is necessarily empty.
>>
> I did not say that set of TM's that solve the Halting Problem, I said
> the set of TMs that represent (or demonstrate) the problem. All the
> textbooks represent this set as simply HP.

Could you give the reference to the place in Sipser's "Introduction to
the Theory of Computation" where HP is defined this way? I looked it up
in the index, and also scanned the section headed "The Halting Problem"
without finding it.

Patricia
0
pats (3556)
4/1/2012 4:15:41 PM
On Apr 1, 8:26=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
wrote:
> On Apr 1, 8:06=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
> wrote:
>
>
>
>
>
> > On Apr 1, 7:37=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
>
> > > On 4/1/2012 9:32 AM, Peter Olcott wrote:
>
> > > > On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
> > > >> On 3/31/2012 7:45 AM, Peter Olcott wrote:
> > > >>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
> > > >>>>>> How can it? "Decidable" is, by your definition, well-defined f=
or any
> > > >>>>>> Turing machine. So any attempt to implement DecidabilityDecide=
r must
> > > >>>>>> also work for the Turing machine I enumerated. In the case I g=
ave,
> > > >>>>>> the
> > > >>>>>> "Decidable" set for that Turing machine is precisely the set w=
hich
> > > >>>>>> represents the Halting problem. Therefore, if DecidabilityDeci=
der
> > > >>>>>> were
> > > >>>>>> to work properly, it must solve the Halting problem itself.
>
> > > >>>>> Whenever the DecibilityDecider() encounters any instance of the
> > > >>>>> Halting
> > > >>>>> Problem, it simply correctly halts in its own reject state, ind=
icating
> > > >>>>> undecidability.
>
> > > >>>> Since the full general Halting problem is undecidable,
> > > >>> yes
> > > >>> the set of TMs that represent the Halting Problem: HP
>
> > > >> No TM can solve the Halting problem. That is what undecidable mean=
s.
> > > >> HP is necessarily empty.
>
> > > > I did not say that set of TM's that solve the Halting Problem, I sa=
id
> > > > the set of TMs that represent (or demonstrate) the problem. All the
> > > > textbooks represent this set as simply HP.
>
> > > My textbook says nothing of the sort. Can you be more explicit about
> > > what you mean by "represent the problem"?
>
> > > --
> > > Beware of bugs in the above code; I have only proved it correct, not
> > > tried it. -- Donald E. Knuth
>
> > How many blank Turing tapes does it take to write it out? =A01/2.
>
> > Then the paths through the Turing tape are the encodings that, in the
> > framework that they encode, normally and unambiguously (or
> > arbitrarily) represent the course of the evaluation of the framework.
> > This would often include arithmetic and it would be naturally founded.
>
> > Basically it has that each machine serializes its state and that's a
> > machine event (for a general program space of all the machines).
>
> > Then basically as long as the algorithms are deterministic it's
> > constructible and complete and you can't construct reversible non-
> > deterministic algorithms.
>
> > Ideas....
>
> > Thanks,
>
> > Ross Finlayson
>
> Having what is an existence proof doesn't make it simple to write
> planar circuits in one Turing tape. =A0I am using two or more myself
> usually with then a theorem that it fits in a half so two is OK,
> because each fits as they go together.
>
> That is about something like the arbitrary complexity of a 3-D IC or
> integrated circuit. =A0Now we are all used to the idea of computer chips
> that are planar. =A0The electrons as inputs go in one side (as input
> leads) and similarly there is output from the chip-scale.
> (Informational, high-speed circuits vis-a-vis power, load circuits,
> high speed planar ultra VLSI, very large scale integration.) =A0These
> are driven by the clock frequency crystal pulses for their timebase.
> It is called systolic like pumping your heart as the clock drives
> power into the input leads. =A0(Here it is the planar IC not a system-on-
> chip or on the bus.) =A0Then you can diagram the junctions of those in a
> finite map and write it out and then the field equations are worked
> up, for synthesis, to decide that, when electricity runs through the
> real chip, that the known effects are considered about how the flow of
> the electricity "really" works (or in extraordinary conditions)
> because, for example, at the limits of modern and next generation
> physical engineering, otherwise the map would not be complete.
>
> Now for the 3-D VLSI, it is this: =A0the custom logic is free in not
> just two dimensions, planar, it's free in each of the three space
> dimensions. =A0(As well materials are moving toward complementary and
> supplemental and alternative heat and light pipes, junctions.) =A0So for
> example with my 3-D roller shifter, this is an electrical circuit,
> analog devices for the general buffering of serial data into arrays
> remarkably improve performance, as you might imagine, while here
> representing a design problem: =A0under all input conditions, there is
> more about them to know than what today, if we put into a TM, we would
> have deterministic systems that a program we could write could
> completely evaluate.
>
> Thanks,
>
> Ross Finlayson


Then surely as far as we know that is all classical and true.  Then
that's the point of the scientific method, as far as any conversation
establishing the validity of the ideal, logic's is a scientific one.
You want to talk morals you're a philosopher.  (That's not logical.)
You can use logic, or we rely on it.

Also these are sequences and strings for an origin but each also has
left and right (or up and down in simple diagrammatic notation), each
path is an origin from anywhere, somewhere to the left or right.

Heh, add up each grain of sand:  beach.  Sure, if it's next to an
ocean, which brings and makes them.

This is where each grain of sand is $500, or more, and the time scales
expected to be handled are single, thousands, millions, billions, per
second, billions of waves per second, any, it's a VLSI chip.  Under
gentler idle, these systems are as well rather complete, as ideal
systems, simply classical.

Add up each grain of sand:  dune.

Melt them into glass, make a chip:  grains of sand.  It'll tell you
when to expect the tide.

Those are of course then complex scenarios - however you see that any
deterministic program written is still complete (completely
deterministic in the evaluation of whether it returns and is a finite
evaluation of a program for its inputs or has an infinite path).

The decider, as programs are run and encoded so that the programs are
exhausted over all their inputs, it just looks at the diagrams and
does them in parallel so that all the finite programs complete in the
exhaustion of the product space over all the inputs.  It builds them
in the order of the ones that complete.  Or, it could work up to
bounds, here of course:  still working up and the reductions and the
range coding for conciseness and tractability, and all complete and
deterministic for working toward any well-defined output.

Then it takes forever if the language has infinitely many terminals.
But, in ZF there are only two constants.

0
4/1/2012 5:15:18 PM
On Apr 1, 10:15=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
wrote:
>
> Then it takes forever if the language has infinitely many terminals.
> But, in ZF there are only two constants.


And in some cases it takes forever and would complete.  As well, with
forever, each of the infinite path searches "returns" (as not finite).

So, you got forever?

0
4/1/2012 5:22:37 PM
On 4/1/2012 7:20 AM, Peter Olcott wrote:
> On 3/31/2012 2:23 PM, Patricia Shanahan wrote:
....
>> Of course, a completely empty string, without a TM, is represented, as
>> usual, by a tape containing only blanks. It should be rejected by a
>> halting decider using this encoding.
>>
>> Patricia
>
> I don't think that the conventional Halting Problem allows for the
> rejection of a blank tape. The TM must still report the (Yes or No)
> answer regarding whether or not the TM specified by "" halts on the
> input specified by "".

Some courses and textbooks use "accept" as short for "halt in a state
indicating the input string is in the language" and "reject" for "halt
in a state indicating the input string is not in the language". That is
the case for the most recent course I took, and textbook I read, on the
subject so I tend to use those terms.

Rewriting the paragraph you quoted in full:

Of course, a completely empty string, without a TM, is represented, as
usual, by a tape containing only blanks. A halting decider using this
encoding should halt in a state indicating the string is not in the
language.

Patricia
0
pats (3556)
4/1/2012 7:57:22 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
<snip>
>> No, a poem might be represent a machine, input pair.  Alternatively a
>> Vogan might think that some<t,i>  string makes a pretty good poem.
>> No matter what you call the input, the correct yes/no answer must be
>> provided.
>>
> I realized that just after I wrote this example, that is why I added
> the dual inputs of empty string to the HaltDecider.
>
> // function prototype
> Boolean HaltDecider(String tm, String input);
>
> // function invocation
> HaltDecider("", "");
>
> In this case the encoding is that the entire TM tape remains filled
> with the space character thus indicating that there is no input at all
> on the tape. Because a TM does not have any numerical representation
> of a space character, this can not possibly be construed as a valid
> TM.

Unless you know (and tell us!) what the encoding rules are, you can't
say that "this can not possibly be construed as a valid TM".  However, I
could take that as a specification of (part of) the encoding you are
assuming.  Under that assumption (that a blank tape does not represent a
TM, input pair) the answer is easy -- a correct halt decider must halt
in a reject state.

> So does "" halt on its input "" (yes or no)?
> (1) Yes logically entails that "" is a valid TM that was running, and
> now halts.
> (2) No logically entails that "" is a valid TM that remains running.

Neither entailment is valid.

> The only answer that is not a lie is:
> (3) Neither

No.

-- 
Ben.
0
ben.usenet (6790)
4/1/2012 8:01:21 PM
Patricia Shanahan <pats@acm.org> writes:

> On 4/1/2012 7:32 AM, Peter Olcott wrote:
<snip>
>> I did not say that set of TM's that solve the Halting Problem, I said
>> the set of TMs that represent (or demonstrate) the problem. All the
>> textbooks represent this set as simply HP.
>
> Could you give the reference to the place in Sipser's "Introduction to
> the Theory of Computation" where HP is defined this way? I looked it up
> in the index, and also scanned the section headed "The Halting Problem"
> without finding it.

I am having the same problem with Martin's "Introduction to Languages
and the Theory of Computation", Floyd and Beigel's "The Language of
Machines: An Introduction to Computability and Formal Languages" and
Rayward-Smith's "First Course in Computability".

-- 
Ben.
0
ben.usenet (6790)
4/1/2012 8:42:31 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
<snip you are quoting me here:>
>>> "does my input represent a machine and string pair such that the
>>> machine halts when run on the string".
>>>
>>> Which makes the conventional halting problem decidable.
>> Eh?  That's just the specification.  It's only decidable if a machine
>> can pick out the halting cases.  There's a proof that no such machine
>> exists.
>>
> Since your criterion did not presume that the TM was valid, and added
> validity checking within the decision:
>
> "does my input represent a machine and string pair such that the
> machine halts when run on the string".
>
> The HaltDecider() can simply correctly halt in its reject state
> whenever it encounters Pathological Self-Reference.

That may well be true.  If it does so (and it is correct to do so), PSR
must imply that the input does not encode a member of the halting set.
I've no idea what PSR is, of course, (any chance of a definition?) but
it might be that PSR => non-halting.

> When one presumes that the TM/input pair is valid, and is presented
> with a TM/input pair that is not valid, and is also required to
> provide a yes/no answer regarding whether or not this invalid TM/input
> pair halts, the question is ill-formed.

Oh don't start that again!  Either define these terms or stop using
them.  I wrote a long post that I hoped would encourage you to use a
more formal notation (I kept it light -- just a bit more formality) but
it does not seem to have helped.  If *I've* been unclear, please ask for
more detail.  I'd be happy to provide it (if I can).

> Before your criterion HaltDecider("", "") must get the wrong answer if
> it is required to provide a yes/no answer.
>
> With your criterion HaltDecider("", "") can simply correctly report "no".
> It can also simply correctly report "no" whenever it encounters
> Pathological Self-Reference, or any other form of erroneous
> input. Your criterion has made semantic validation explicit.

See my other post about this.  You may be right, but I can't comment
because I have no idea what Pathological Self-Reference is.

By the way, it's not "my criterion" -- it's how the problem you've been
lecturing us about is usually defined.  I made the mistake of thinking
you were talking about the "conventional halting problem" but that may
not be the case.

I am loath to bring this up, but it's not *always* defined this way.
Some authors, who are being a little less formal, restrict the problem
to one of partitioning the set of <t, i> strings into halting and
non-halting cases, rather than one of partitioning the set of all
strings (Sigma*), into those that encode halting cases from those that
don't.  These texts should include some words about the permitted
encoding -- for example, Rayward-Smith says the encoding must be
"sensible".  The point is that the set of all encoded (t, i) pairs (<t,
i> in my recent notation) must, itself, be decidable or problems like
halting would be undecidable for trivial and uninteresting reasons.

You want to use words like "valid" and "ill-formed" so that you can
equate your desire to define-away the undecidability of halting with the
simply syntactic test of whether a string s is in {<t, i> such t in TM
and i in S*}.

-- 
Ben.
0
ben.usenet (6790)
4/1/2012 9:16:35 PM
On Apr 1, 3:57=A0pm, Patricia Shanahan <p...@acm.org> wrote:
> Of course, a completely empty string, without a TM, is represented, as
> usual, by a tape containing only blanks. A halting decider using this
> encoding should halt in a state indicating the string is not in the
> language.

This is NOT true.
The association between strings-representing-TMs and TMs IS ARBITRARY.
Any TM wanting to present itself as taking a string-describing-a-TM as
input
has the right and the power to decide FOR ITself, withOUT fear of
contradiction
from ANY OUTside authority, that *IT* is going to interpret the empty
string as
whatEVER dang TM *it* DANGWELL pleases.
IF IT CHOOSES to interpret the empty string as denoting the TM that
accepts
everything, then the empty string WILL be in the language.

0
greeneg9613 (188)
4/2/2012 1:43:03 AM
On Apr 1, 4:01=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Unless you know (and tell us!) what the encoding rules are, you can't
> say that "this can not possibly be construed as a valid TM".

Exactly.
If it's *your* TM  then YOU must say which string "means"/denotes
which TM.
If you are going to insist that there are strings that denote no TM
(which you need
not -- and in this context,  arguably should  not -- but IF you are)
then you had
best make sure that THOSE strings form a language that you can easily
describe
to us (it will be equally easy to code your TM-analyzer to return the
right thing for
those cases; it shouldn't loop since invalid input will be EASY to
identify).
0
greeneg9613 (188)
4/2/2012 1:51:25 AM
On Apr 1, 10:22=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
wrote:
> On Apr 1, 10:15=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
> wrote:
>
>
>
> > Then it takes forever if the language has infinitely many terminals.
> > But, in ZF there are only two constants.
>
> And in some cases it takes forever and would complete. =A0As well, with
> forever, each of the infinite path searches "returns" (as not finite).
>
> So, you got forever?


The thing with the Turing machine if it can have "infinite offsets",
that size_t is infinite - heh, that doesn't seem so necessary there
when the other features of the "linear bounded automaton" are there.
None of the "Turing complete" languages we use has that built-in
expectation of more than a finite offset, to represent for example a
program representation.

That would also mean that the language was infinite.  No, I don't
think that's true in any TM  that is not a UTM (universal Turing
machine), each symbol is finite and the language is bounded by the
progress of following the tape.

So anyways as long as the encoding for any program has that it has an
infinite encoding if it doesn't halt as it's the combined program and
input:  the work is done by the encoder.  Basically that says for each
program with its data, you can write the whole thing to the tape even
if it's infinite, in encoding for the language, as long it's the same
for decoding.

Then, Rice says encoding isn't efficient.  I don't say it's easy, but
it's pretty obvious, however you convert N-d to a linear addressing
scheme.

With that encoding, then all the finite programs are written out in
unbounded time (where there is that as a resource in the model) and
all that's left are the programs, with their data, that don't halt,
and it's known where each of those begins.

You could more or less write these strings in natural language and
it's back to the constructible universe.  If the programs don't halt
you can see the words don't stop, because you got forever and you
never forget, and, you never forget anything you can think of, that
you remember.  You can stop and check each it constructs without much
or any thinking.

Basically I'm more interested in completeness results in computability
theory, than incompleteness results.

Right then,

Ross Finlayson
0
4/2/2012 2:18:26 AM
On 4/1/2012 8:51 AM, Patricia Shanahan wrote:
> Peter Olcott wrote:
> ...
>> It is merely an arbitrary convention that an answer must be provided. 
> ...
>
> You have written something important with which I totally agree, and
> that leads to a simple way of ending this thread. (Patricia quickly
> checks calendar, and sees a possible explanation. :-)
>
> The association between the phrase "decider for language X" and the
> concept of a TM that always halts in a state representing true if its
> input is in X, and always halts in a state representing false if its
> input is not in X, is indeed merely an arbitrary convention. 
This way of stating it does not seem so arbitrary.
0
NoSpam271 (937)
4/2/2012 7:04:25 AM
On 4/1/2012 8:51 AM, Patricia Shanahan wrote:
> Peter Olcott wrote:
> ...
>> It is merely an arbitrary convention that an answer must be provided. 
> ...
>
> You have written something important with which I totally agree, and
> that leads to a simple way of ending this thread. (Patricia quickly
> checks calendar, and sees a possible explanation. :-)
>
> The association between the phrase "decider for language X" and the
> concept of a TM that always halts in a state representing true if its
> input is in X, and always halts in a state representing false if its
> input is not in X, is indeed merely an arbitrary convention. 
This way of stating it does not seem so arbitrary, and also this way of 
stating it does not prohibit the decider from going into a loop.
Halt in accept state if input in in X, else either halt in reject state 
or fail to halt.
0
NoSpam271 (937)
4/2/2012 7:06:48 AM
On 4/1/2012 9:27 AM, Joshua Cranmer wrote:
> On 4/1/2012 6:11 AM, Peter Olcott wrote:
>> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
>>> What does this option mean? It must answer yes/no for all inputs, poems
>>> and all. Further the answer must be "correct" (h(s) = yes iff s in
>>> {<t, i>} and halts(t, i)).
>>>
>> It is merely an arbitrary convention that an answer must be provided.
>> The specification of a Turing Machine does not require an answer, thus
>> when one is categorically exhaustively examining *all* of the
>> possibilities leaving out the third option forms an incomplete analysis.
>
> The specification of a Turing machine might not require it, but the 
> definition of a decidable language does. (Hint: Halting is 
> Turing-recognizable, but not Turing-decidable. This is exactly because 
> Halting can tell you when the answer is "yes" but not when it is "no".)
Unless "no" is simply defined as not(yes), thus including neither (yes 
nor no).
0
NoSpam271 (937)
4/2/2012 7:09:21 AM
On 4/1/2012 11:00 AM, Jussi Piitulainen wrote:
> Peter Olcott writes:
>> On 4/1/2012 7:03 AM, Leif Roar Moldskred wrote:
>>> In comp.theory Peter Olcott wrote:
>>>> It is merely an arbitrary convention that an answer must be provided.
>>> The "answer" from a Turing Machine is whatever is written on the tape
>>> once the TM halts, including the tape being blank. _Every_ Turing
>>> Machine that halts will therefore _necessarily_ provide an
>>> answer. This follows inescapeably from the way Turing Machines are
>>> defined.
>>>
>> It is my understanding that this is not quite true. The answer is not
>> conventionally written on the tape. The answer is one of three cases:
>> 1) halt in the accept state
>> 2) halt in the reject state
>> 3) loop, thus not halt in either state
>> No need to write anything to the tape.
> Turing machines are supposed to be able to compute anything that can
> be computed. Think.
>
> No, I don't mean that Turing machines can think. I mean you should.
>
> Consider, for example, elementary arithmetic. It's computable, given
> sufficient time and space and a suitable representation of a number.
> Turing machines can do it, and not just in your favourite way ("What
> is two plus two, yes or no?") but in the ordinary sense where the
> answer is four! Where did you think that answer goes?  (It goes on the
> tape.)
Yes or no answers do not typically go on the tape.
0
NoSpam271 (937)
4/2/2012 7:11:10 AM
Peter Olcott writes:
> On 4/1/2012 11:00 AM, Jussi Piitulainen wrote:
> > Peter Olcott writes:
> >> On 4/1/2012 7:03 AM, Leif Roar Moldskred wrote:
> >>> In comp.theory Peter Olcott wrote:
> >>>> It is merely an arbitrary convention that an answer must be provided.
> >>> The "answer" from a Turing Machine is whatever is written on the tape
> >>> once the TM halts, including the tape being blank. _Every_ Turing
> >>> Machine that halts will therefore _necessarily_ provide an
> >>> answer. This follows inescapeably from the way Turing Machines are
> >>> defined.
> >>>
> >> It is my understanding that this is not quite true. The answer is not
> >> conventionally written on the tape. The answer is one of three cases:
> >> 1) halt in the accept state
> >> 2) halt in the reject state
> >> 3) loop, thus not halt in either state
> >> No need to write anything to the tape.
> >
> > Turing machines are supposed to be able to compute anything that can
> > be computed. Think.
> >
> > No, I don't mean that Turing machines can think. I mean you should.
> >
> > Consider, for example, elementary arithmetic. It's computable, given
> > sufficient time and space and a suitable representation of a number.
> > Turing machines can do it, and not just in your favourite way ("What
> > is two plus two, yes or no?") but in the ordinary sense where the
> > answer is four! Where did you think that answer goes?  (It goes on the
> > tape.)
>
> Yes or no answers do not typically go on the tape.

I don't know what is typical in general. You are probably correct that
Turing machines used to _decide_ something are typically specified so
that their halt states are partitioned into types that correspond to
the different answers.

They still leave something on the tape, like a Unix program writes
something (or nothing) in stdout and stderr even when you consider its
exit status to be the actual result of interest. This is important
when you compose Turing machines or Unix programs. In the case of a
decider, it is so trivial to clean the tape or direct the standard
output streams to /dev/null that the irrelevant output can be ignored
in contexts where the output of interest is just the one bit (the
specific halt state, or exit status).

You say there is "No need to write anything to the tape" but if the
Turing machine does not write anything to the tape, it is just a
finite state automaton. At least it seems to me to be so.
0
jpiitula2 (679)
4/2/2012 8:20:22 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/1/2012 8:51 AM, Patricia Shanahan wrote:
>> Peter Olcott wrote:
>> ...
>>> It is merely an arbitrary convention that an answer must be
>>> provided. 
>> ...
>>
>> You have written something important with which I totally agree, and
>> that leads to a simple way of ending this thread. (Patricia quickly
>> checks calendar, and sees a possible explanation. :-)
>>
>> The association between the phrase "decider for language X" and the
>> concept of a TM that always halts in a state representing true if its
>> input is in X, and always halts in a state representing false if its
>> input is not in X, is indeed merely an arbitrary convention. 
> This way of stating it does not seem so arbitrary, and also this way
> of stating it does not prohibit the decider from going into a loop.
> Halt in accept state if input in in X, else either halt in reject
> state or fail to halt.

As you suggest, only an arbitrary convention, used by narrow-minded
mathematicians, prevents a decider for looping.  Have you rejected this
archaic way of thinking?  If so, tell us once and for all and we can
leave you in peace to develop the new theory of POdecidability.

-- 
Ben.
0
ben.usenet (6790)
4/2/2012 12:35:03 PM
On 4/2/2012 2:09 AM, Peter Olcott wrote:
> On 4/1/2012 9:27 AM, Joshua Cranmer wrote:
>> On 4/1/2012 6:11 AM, Peter Olcott wrote:
>>> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
>>>> What does this option mean? It must answer yes/no for all inputs, poems
>>>> and all. Further the answer must be "correct" (h(s) = yes iff s in
>>>> {<t, i>} and halts(t, i)).
>>>>
>>> It is merely an arbitrary convention that an answer must be provided.
>>> The specification of a Turing Machine does not require an answer, thus
>>> when one is categorically exhaustively examining *all* of the
>>> possibilities leaving out the third option forms an incomplete analysis.
>>
>> The specification of a Turing machine might not require it, but the
>> definition of a decidable language does. (Hint: Halting is
>> Turing-recognizable, but not Turing-decidable. This is exactly because
>> Halting can tell you when the answer is "yes" but not when it is "no".)
> Unless "no" is simply defined as not(yes), thus including neither (yes
> nor no).

My bad for assuming you knew what Turing-recognizable meant.

The Halting problem is Turing-recognizable: if M halts on w, we can 
write a Turing machine that halts. This is trivially implemented by 
"simulate M on w and return true if it halts." If M doesn't halt, this 
implementation runs forever. According to conventional definition, this 
implementation is not a decider since it does not halt if the answer is 
false, it just runs forever. The term for this kind of TM is actually a 
"recognizer": accepts when s is in the language, else runs forever.

So you can tell when the answer is "yes": the Turing machine will quite 
and tell you so. But to find out that the answer is "no", you have to 
wait forever.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/2/2012 2:01:31 PM
On Apr 2, 7:01=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> On 4/2/2012 2:09 AM, Peter Olcott wrote:
>
>
>
>
>
> > On 4/1/2012 9:27 AM, Joshua Cranmer wrote:
> >> On 4/1/2012 6:11 AM, Peter Olcott wrote:
> >>> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
> >>>> What does this option mean? It must answer yes/no for all inputs, po=
ems
> >>>> and all. Further the answer must be "correct" (h(s) =3D yes iff s in
> >>>> {<t, i>} and halts(t, i)).
>
> >>> It is merely an arbitrary convention that an answer must be provided.
> >>> The specification of a Turing Machine does not require an answer, thu=
s
> >>> when one is categorically exhaustively examining *all* of the
> >>> possibilities leaving out the third option forms an incomplete analys=
is.
>
> >> The specification of a Turing machine might not require it, but the
> >> definition of a decidable language does. (Hint: Halting is
> >> Turing-recognizable, but not Turing-decidable. This is exactly because
> >> Halting can tell you when the answer is "yes" but not when it is "no".=
)
> > Unless "no" is simply defined as not(yes), thus including neither (yes
> > nor no).
>
> My bad for assuming you knew what Turing-recognizable meant.
>
> The Halting problem is Turing-recognizable: if M halts on w, we can
> write a Turing machine that halts. This is trivially implemented by
> "simulate M on w and return true if it halts." If M doesn't halt, this
> implementation runs forever. According to conventional definition, this
> implementation is not a decider since it does not halt if the answer is
> false, it just runs forever. The term for this kind of TM is actually a
> "recognizer": accepts when s is in the language, else runs forever.
>
> So you can tell when the answer is "yes": the Turing machine will quite
> and tell you so. But to find out that the answer is "no", you have to
> wait forever.
>
> --
> Beware of bugs in the above code; I have only proved it correct, not
> tried it. -- Donald E. Knuth


But for each of those, we can statically analyze and reduce them,
unless they are simply infinitely aimless, in which case it meets
expectations that it takes forever to read out the infinite sequence
with no structure.  Constructively there is each one tractable.

That's not just random but anti-structural.  Before forever gets
there, it is reduced to the finite.  Also it's approximative, wait as
long as you want, you're only closer to computing of all the programs
and inputs their deterministic, constructive behavior.

"Forever" is simple "infinite time" as a resource along with the
"infinite space" of the halting problem (THP) - yeah it's OK to take
forever to "solve" the halting problem, as long as there's an
exhaustive algorithm.  There might not be infinitely large numbers,
but there are bounds for everything and everything is unbounded.

Then if the language admits actually infinitely many (independent)
symbols, funny the antidiagonal argument is all in one column and the
only one different from writing them out as ordinals is the one at the
end, and all those are on there.

Regards,

Ross Finlayson
0
4/2/2012 3:38:02 PM
On Apr 2, 8:38=A0am, "Ross A. Finlayson" <ross.finlay...@gmail.com>
wrote:
> On Apr 2, 7:01=A0am, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
>
>
>
>
>
> > On 4/2/2012 2:09 AM, Peter Olcott wrote:
>
> > > On 4/1/2012 9:27 AM, Joshua Cranmer wrote:
> > >> On 4/1/2012 6:11 AM, Peter Olcott wrote:
> > >>> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
> > >>>> What does this option mean? It must answer yes/no for all inputs, =
poems
> > >>>> and all. Further the answer must be "correct" (h(s) =3D yes iff s =
in
> > >>>> {<t, i>} and halts(t, i)).
>
> > >>> It is merely an arbitrary convention that an answer must be provide=
d.
> > >>> The specification of a Turing Machine does not require an answer, t=
hus
> > >>> when one is categorically exhaustively examining *all* of the
> > >>> possibilities leaving out the third option forms an incomplete anal=
ysis.
>
> > >> The specification of a Turing machine might not require it, but the
> > >> definition of a decidable language does. (Hint: Halting is
> > >> Turing-recognizable, but not Turing-decidable. This is exactly becau=
se
> > >> Halting can tell you when the answer is "yes" but not when it is "no=
".)
> > > Unless "no" is simply defined as not(yes), thus including neither (ye=
s
> > > nor no).
>
> > My bad for assuming you knew what Turing-recognizable meant.
>
> > The Halting problem is Turing-recognizable: if M halts on w, we can
> > write a Turing machine that halts. This is trivially implemented by
> > "simulate M on w and return true if it halts." If M doesn't halt, this
> > implementation runs forever. According to conventional definition, this
> > implementation is not a decider since it does not halt if the answer is
> > false, it just runs forever. The term for this kind of TM is actually a
> > "recognizer": accepts when s is in the language, else runs forever.
>
> > So you can tell when the answer is "yes": the Turing machine will quite
> > and tell you so. But to find out that the answer is "no", you have to
> > wait forever.
>
> > --
> > Beware of bugs in the above code; I have only proved it correct, not
> > tried it. -- Donald E. Knuth
>
> But for each of those, we can statically analyze and reduce them,
> unless they are simply infinitely aimless, in which case it meets
> expectations that it takes forever to read out the infinite sequence
> with no structure. =A0Constructively there is each one tractable.
>
> That's not just random but anti-structural. =A0Before forever gets
> there, it is reduced to the finite. =A0Also it's approximative, wait as
> long as you want, you're only closer to computing of all the programs
> and inputs their deterministic, constructive behavior.
>
> "Forever" is simple "infinite time" as a resource along with the
> "infinite space" of the halting problem (THP) - yeah it's OK to take
> forever to "solve" the halting problem, as long as there's an
> exhaustive algorithm. =A0There might not be infinitely large numbers,
> but there are bounds for everything and everything is unbounded.
>
> Then if the language admits actually infinitely many (independent)
> symbols, funny the antidiagonal argument is all in one column and the
> only one different from writing them out as ordinals is the one at the
> end, and all those are on there.
>


Rice says you can't construct an encoding for programs thus that if it
halts the encoding is finite.  But, that excludes all the closures of
the finite languages of the various constants and other features of
grammar in the theorems, which are finite and unbounded, each.

But if you just give each finite program a next number if it halts and
give it some "infinite pattern" that it would take infinitely long to
not return when all the finite ones are done - those don't halt.

Then the work is on the encoder, for each program and input, give it a
name constructively and run it out to tape.  When you write a zero to
return flip all unused ones to zero (it starts all ones, the tape, or,
say, negative ones), write a zero, it halted, and it has zeros in all
the unused spaces.  All the finite programs have only zeros in
infinitely many places and nothing else is infinite.  Then a blank
tape is infinite and a finite program is run out to prove it halts.

Then the decoder has no work to do except see whether it completes in
finite time that it has, and, programs with their input halt or don't.

What, Chaitin's Omega?  Oh, that's %50.  (That constant is in various
frameworks more a moving constant, as it were, compared to variables,
for example sometimes it's closer to one or zero, the proportion of
programs that halt.)

Ideas....

Right then,

Ross Finlayson
0
4/2/2012 7:24:35 PM
On Apr 2, 3:11=A0am, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> Yes or no answers do not typically go on the tape.

It is Really REALLY embarrassing for you to have allowed your argument
to
DEvolve from being about something that actually MATTERS (the halting
problem or self-reference) to being about how to represent a 1-bit
output.
0
greeneg9613 (188)
4/2/2012 7:33:43 PM
George Greene <greeneg@email.unc.edu> writes:

> On Apr 1, 3:57 pm, Patricia Shanahan <p...@acm.org> wrote:
>> Of course, a completely empty string, without a TM, is represented, as
>> usual, by a tape containing only blanks. A halting decider using this
>> encoding should halt in a state indicating the string is not in the
>> language.
>
> This is NOT true.
> The association between strings-representing-TMs and TMs IS ARBITRARY.

Yes, but the representation is specified (at least for the case in
question).  Surely the phrase "a halting decider using this encoding"
means one using the encoding described immediately before.

<snip>
-- 
Ben.
0
ben.usenet (6790)
4/2/2012 9:02:41 PM
Ben Bacarisse wrote:
> George Greene <greeneg@email.unc.edu> writes:
> 
>> On Apr 1, 3:57 pm, Patricia Shanahan <p...@acm.org> wrote:
>>> Of course, a completely empty string, without a TM, is represented, as
>>> usual, by a tape containing only blanks. A halting decider using this
>>> encoding should halt in a state indicating the string is not in the
>>> language.
>> This is NOT true.
>> The association between strings-representing-TMs and TMs IS ARBITRARY.
> 
> Yes, but the representation is specified (at least for the case in
> question).  Surely the phrase "a halting decider using this encoding"
> means one using the encoding described immediately before.

That was my intent. Indeed, I am proposing standardizing, for purposes
of this discussion, on using TMML to encode Turing Machines.

Patricia
0
pats (3556)
4/2/2012 10:38:13 PM
On Apr 2, 6:38=A0pm, Patricia Shanahan <p...@acm.org> wrote:
> That was my intent. Indeed, I am proposing standardizing, for purposes
> of this discussion, on using TMML to encode Turing Machines.

My Google interface defaults to hiding long text blocks and I did
not click on the block containing the prior discussion to expand it;
that is why I did not see (in the particular message to which I was
replying)
that a concrete proposal was under discussion.  P.O. will
OF COURSE REFUSE to state/propose a concrete encoding, and I was
expecting that to remain the relevant context.

I also wanted to stress (MY point was) that in some sense one CANnot
defend using TMML or ANY *particular* encoding, as long as one is
using one of the myriad sufficiently simple&well-behaved encodings.
But of course your use of the word "propose" already reflected that.

0
greeneg9613 (188)
4/2/2012 11:03:33 PM
On 4/2/2012 5:38 PM, Patricia Shanahan wrote:
> Ben Bacarisse wrote:
>> George Greene <greeneg@email.unc.edu> writes:
>>
>>> On Apr 1, 3:57 pm, Patricia Shanahan <p...@acm.org> wrote:
>>>> Of course, a completely empty string, without a TM, is represented, as
>>>> usual, by a tape containing only blanks. A halting decider using this
>>>> encoding should halt in a state indicating the string is not in the
>>>> language.
>>> This is NOT true.
>>> The association between strings-representing-TMs and TMs IS ARBITRARY.
>>
>> Yes, but the representation is specified (at least for the case in
>> question).  Surely the phrase "a halting decider using this encoding"
>> means one using the encoding described immediately before.
>
> That was my intent. Indeed, I am proposing standardizing, for purposes
> of this discussion, on using TMML to encode Turing Machines.
>
> Patricia
It might prove helpful. What is its syntax for specifying the Empty String?
0
NoSpam271 (937)
4/3/2012 2:18:08 AM
On 3/31/2012 11:33 AM, Joshua Cranmer wrote:
> On 3/31/2012 7:41 AM, Peter Olcott wrote:
>> On 3/31/2012 12:47 AM, Joshua Cranmer wrote:
>>>> Since you just equated failing to halt with invalid input the halt
>>>> decider can now always correctly halt in its reject state when it
>>>> encounters Pathological Self-Reference. Since you just made the 
>>>> Halting
>>>> Problem decidable, I would estimate that this is not what is meant 
>>>> when
>>>> the term Halting Problem is used.
>>>
>>> No. He did not make it decidable. Remember the formal definition of
>>> the Halting problem: it is the language {<M, w> | M is a Turing
>>> machine that halts when w is fed as input}. Note that any input string
>>> which does not consist of a Turing machine, input string pair is by
>>> definition not in this language. So it's merely part of the original
>>> definition of the Halting problem, just one that is usually handwaved
>>> (since detecting whether or not the input is of the form <M, w> is a
>>> trivial task).
>> You can't have it both ways:
>> Either it must answer whether or not an English poem halts on its input
>> such that {yes, no, no answer} are all incorrect. Or it can simply
>> provide "no" as a correct answer within the scope of your own defintion
>> of semantically invalid input:
>>
>> "does my input represent a machine and string pair such that the machine
>> halts when run on the string".
>>
>> Which makes the conventional halting problem decidable.
>
> No, it does not. Regardless of what you believe, the diagonalization 
> argument for the conventional halting problem still proves it 
> undecidable. You are arguing that it doesn't only on the basis that 
> the machine in question neither halts nor fails to halt, a claim which 
> is trivially false.
>

I think that there is more to it than this. If the undeciable cases can 
simply correctly take the halt in reject state, (because of the way that 
the question is phrased) then halting would become decidable.
0
NoSpam271 (937)
4/3/2012 2:21:23 AM
On 4/2/2012 9:01 AM, Joshua Cranmer wrote:
> On 4/2/2012 2:09 AM, Peter Olcott wrote:
>> On 4/1/2012 9:27 AM, Joshua Cranmer wrote:
>>> On 4/1/2012 6:11 AM, Peter Olcott wrote:
>>>> On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
>>>>> What does this option mean? It must answer yes/no for all inputs, 
>>>>> poems
>>>>> and all. Further the answer must be "correct" (h(s) = yes iff s in
>>>>> {<t, i>} and halts(t, i)).
>>>>>
>>>> It is merely an arbitrary convention that an answer must be provided.
>>>> The specification of a Turing Machine does not require an answer, thus
>>>> when one is categorically exhaustively examining *all* of the
>>>> possibilities leaving out the third option forms an incomplete 
>>>> analysis.
>>>
>>> The specification of a Turing machine might not require it, but the
>>> definition of a decidable language does. (Hint: Halting is
>>> Turing-recognizable, but not Turing-decidable. This is exactly because
>>> Halting can tell you when the answer is "yes" but not when it is "no".)
>> Unless "no" is simply defined as not(yes), thus including neither (yes
>> nor no).
>
> My bad for assuming you knew what Turing-recognizable meant.
>
> The Halting problem is Turing-recognizable: if M halts on w, we can 
> write a Turing machine that halts. This is trivially implemented by 
> "simulate M on w and return true if it halts." If M doesn't halt, this 
> implementation runs forever. According to conventional definition, 
> this implementation is not a decider since it does not halt if the 
> answer is false, it just runs forever. The term for this kind of TM is 
> actually a "recognizer": accepts when s is in the language, else runs 
> forever.
>
> So you can tell when the answer is "yes": the Turing machine will 
> quite and tell you so. But to find out that the answer is "no", you 
> have to wait forever.
>
It is still a mistake to require a yes or no answer when no correct yes 
or no answer exists within the scope of Pathological Self-Reference.
0
NoSpam271 (937)
4/3/2012 2:23:27 AM
On 4/2/2012 9:23 PM, Peter Olcott wrote:
> It is still a mistake to require a yes or no answer when no correct yes
> or no answer exists within the scope of Pathological Self-Reference.

You may believe that the definition is wrong, but everyone else has 
gotten along swimmingly with it for 70 years. This of course means that 
you're not disproving the Halting problem, but rather a (probably not 
very interesting) non-standard variant of it.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/3/2012 2:40:36 AM
On 4/2/2012 7:18 PM, Peter Olcott wrote:
> On 4/2/2012 5:38 PM, Patricia Shanahan wrote:
....
>> That was my intent. Indeed, I am proposing standardizing, for purposes
>> of this discussion, on using TMML to encode Turing Machines.
>>
>> Patricia
> It might prove helpful. What is its syntax for specifying the Empty String?

TMML is a language for describing Turing machines, not strings.

Patricia
0
pats (3556)
4/3/2012 2:47:26 AM
On 4/2/2012 9:21 PM, Peter Olcott wrote:
> I think that there is more to it than this. If the undeciable cases can
> simply correctly take the halt in reject state, (because of the way that
> the question is phrased) then halting would become decidable.

The way you would interpret the Halting problem is very different from 
the way everyone else interprets it. The Halting problem, as it is 
defined, is undecidable, even if you make the allowances you wish, since 
the allowances don't change the definition in the first place.

There is a formal definition of the Halting problem. That the English 
description can allow for different interpretations does not change this 
formal definition, it just means that some people read the wrong definition.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/3/2012 3:47:47 AM
On Apr 2, 10:23=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> It is still a mistake to require a yes or no answer when no correct yes
> or no answer exists within the scope of Pathological Self-Reference.

For halting, THIS DOESN'T MATTER.
THERE IS NEVER anything wrong with "requiring" a yes or no answer
to a halting question, SINCE IT ALWAYS HAS a yes or no answer.
The questions that cannot be consistently answered yes or no that YOU
are
coming up with are unanswerable BECAUSE THEY DON'T EXIST, because
they are PHRASED in terms of a call to Halts(), AND HALTS() DOESN'T
EXIST.

What would REALLY be unanswerable is the TM analogue of
"Will the next word out of your mouth be "no"?"
This ACTUALLY IS DIRECTLY TRANSLATABLE into TM-speak
and it does NOT INVOLVE halting (which is GOOD since Halts() DOES NOT
EXIST, as a TM).

The first question is, what might we MEAN by "next word out"?  Well,
in terms of output,
a TM ONLY HAS ONE output -- it is whatever is written on the tape when
the TM halts.
So if the TM DOESN'T halt, then it DOES NOT PUT OUT an output.   THIS
IS HOW YOU
AVOID the paradox.
And believe it or not, THE HUMAN SPEAKER who receives this question
can avoid the
paradox in THE SAME WAY: by simply NEVER ANSWERING.


All you have to do to achieve an analogue of DMC's original
paradoxical question is
find a way to ask a TM, "will the next word out of your mouth be
'no'?".
This ought to be (and IS) EASY.
The only available candidate for "next word out" is the output, so you
basically
have to ask the TM whether it is going to be print "false" or "no" or
something else indicative
of a reject-halt on its tape, in response to a question about ITS OWN
behavior.
LOTS of TMs are configured to handle questions about the behavior of
TMs.
IF your TM (call it P) is one of those, if P takes an arbitrary TM as
an input parameter,
THEN OF COURSE P CAN TAKE ITSELF (or the string denoting the TM P)
as an input parameter.
Any old program that analyzes the behavior of TMs can analyze P.
It can ask P, "will your output for input x be 'no'?"
Then all you have to do is find a way to make x be the question above.
0
greeneg9613 (188)
4/3/2012 4:16:06 AM
On Apr 2, 10:23=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> It is still a mistake to require a yes or no answer when no correct yes
> or no answer exists within the scope of Pathological Self-Reference.

But a correct yes or no answer DOES exist, for EVERY question about
whether TM m halts on input i, for EVERY m and i, REGARDLESS of
whether
"pathological self-reference" is or isn't occurring.  The ONLY reason
why YOU
think there may exist cases with no correct answer is that YOU keep
presenting
cases using Halts(), when HALTS() DOES NOT *EXIST*, not as a TM or as
anything that a TM could call.
0
greeneg9613 (188)
4/3/2012 4:18:48 AM
On Apr 2, 9:18=A0pm, George Greene <gree...@email.unc.edu> wrote:
> On Apr 2, 10:23=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
>
> > It is still a mistake to require a yes or no answer when no correct yes
> > or no answer exists within the scope of Pathological Self-Reference.
>
> But a correct yes or no answer DOES exist, for EVERY question about
> whether TM m halts on input i, for EVERY m and i, REGARDLESS of
> whether
> "pathological self-reference" is or isn't occurring. =A0The ONLY reason
> why YOU
> think there may exist cases with no correct answer is that YOU keep
> presenting
> cases using Halts(), when HALTS() DOES NOT *EXIST*, not as a TM or as
> anything that a TM could call.

But, all these other things _do_ exist, like negations of these
conjectures, as "a TM or as anything a TM could call" i.e. any
program?  Why not just model the Halts() function as one of those
contingent(ly) things?  Because you have a theorem that Halts()
doesn't exist, not a theorem that Halts_0() + Halts+1() + ... +
through ordinals in IZF + ... doesn't equal Halts(), and that exists
(here plainly constructively).

This uses the completeness theorems of Goedel instead of the
incompleteness.

There are "infinite" time and space resources in this abstract
programming model - there are deterministic and exhaustive algorithms
to remove loops in the program model - only an "infinite program"
would be incompressible, obviously it doesn't halt, but all the
programs that run forever or not with finite specifications have
finite specifications and their halting is deterministic.

While there are "infinite" time and space resources there's no better
way to generate a pseudo-random, and still no way to generate a
"random" program, a random program is among all programs.  Given an
encoding, various structural concerns can define probabilities in
program space.

Thanks,

Ross Finlayson
0
4/3/2012 3:23:39 PM
On 4/2/2012 7:21 PM, Peter Olcott wrote:
....
> I think that there is more to it than this. If the undeciable cases can
> simply correctly take the halt in reject state, (because of the way that
> the question is phrased) then halting would become decidable.

If some combination of hypothetical TMs would, in combination, decide
halting, at least one of them does not exist.

Patricia
0
pats (3556)
4/3/2012 4:33:15 PM
On 4/1/2012 11:08 AM, Patricia Shanahan wrote:
> On 4/1/2012 7:16 AM, Peter Olcott wrote:
>> On 4/1/2012 7:03 AM, Leif Roar Moldskred wrote:
>>> In comp.theory Peter Olcott<NoSpam@ocr4screen.com> wrote:
>>>> It is merely an arbitrary convention that an answer must be provided.
>>> The "answer" from a Turing Machine is whatever is written on the tape
>>> once the TM halts, including the tape being blank. _Every_ Turing
>>> Machine that halts will therefore _necessarily_ provide an
>>> answer. This follows inescapeably from the way Turing Machines are
>>> defined.
>>>
>> It is my understanding that this is not quite true. The answer is not
>> conventionally written on the tape. The answer is one of three cases:
>> 1) halt in the accept state
>> 2) halt in the reject state
>> 3) loop, thus not halt in either state
>> No need to write anything to the tape.
>
> If the third case happens, the TM, by definition, is not a decider for
> any language.
>
> Patricia

1) Halt in the accept state indicating that the input TM and its input 
will halt.
2) Halt in the reject state indicating that the input TM and its input 
will not halt, or the input is invalid semantically or otherwise.

It would be nice to divide up the last one into:
1) Halt in its reject state indicating that the input TM and its input 
will not halt.
2) The case of invalid input of any kind (semantic or otherwise) is 
screened out before the halt decider "sees" any of its input.

That is the purpose of the Decidability Decider.
0
NoSpam271 (937)
4/4/2012 12:37:41 AM
On 4/2/2012 10:47 PM, Joshua Cranmer wrote:
> On 4/2/2012 9:21 PM, Peter Olcott wrote:
>> I think that there is more to it than this. If the undeciable cases can
>> simply correctly take the halt in reject state, (because of the way that
>> the question is phrased) then halting would become decidable.
>
> The way you would interpret the Halting problem is very different from 
> the way everyone else interprets it. The Halting problem, as it is 
> defined, is undecidable, even if you make the allowances you wish, 
> since the allowances don't change the definition in the first place.
>
> There is a formal definition of the Halting problem. That the English 
> description can allow for different interpretations does not change 
> this formal definition, it just means that some people read the wrong 
> definition.

What about when the empty string is input to the halt decider as the 
input TM? Must the halt decider always say yes or no, even in the case 
where the only correct answer is neither?

Boolean Halts("", "");  // Neither true nor false is correct here
0
NoSpam271 (937)
4/4/2012 1:56:44 AM
On 4/3/2012 11:33 AM, Patricia Shanahan wrote:
> On 4/2/2012 7:21 PM, Peter Olcott wrote:
> ...
>> I think that there is more to it than this. If the undeciable cases can
>> simply correctly take the halt in reject state, (because of the way that
>> the question is phrased) then halting would become decidable.
>
> If some combination of hypothetical TMs would, in combination, decide
> halting, at least one of them does not exist.
>
> Patricia

It can always decide halting whenever halting is decidable, otherwise 
the input is erroneous, of the input TM fails to halt.
0
NoSpam271 (937)
4/4/2012 1:58:10 AM
On 4/1/2012 9:37 AM, Joshua Cranmer wrote:
> On 4/1/2012 9:32 AM, Peter Olcott wrote:
>> On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
>>> On 3/31/2012 7:45 AM, Peter Olcott wrote:
>>>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
>>>>>>> How can it? "Decidable" is, by your definition, well-defined for 
>>>>>>> any
>>>>>>> Turing machine. So any attempt to implement DecidabilityDecider 
>>>>>>> must
>>>>>>> also work for the Turing machine I enumerated. In the case I gave,
>>>>>>> the
>>>>>>> "Decidable" set for that Turing machine is precisely the set which
>>>>>>> represents the Halting problem. Therefore, if DecidabilityDecider
>>>>>>> were
>>>>>>> to work properly, it must solve the Halting problem itself.
>>>>>>
>>>>>> Whenever the DecibilityDecider() encounters any instance of the
>>>>>> Halting
>>>>>> Problem, it simply correctly halts in its own reject state, 
>>>>>> indicating
>>>>>> undecidability.
>>>>>
>>>>> Since the full general Halting problem is undecidable,
>>>> yes
>>>> the set of TMs that represent the Halting Problem: HP
>>>
>>> No TM can solve the Halting problem. That is what undecidable means.
>>> HP is necessarily empty.
>>>
>> I did not say that set of TM's that solve the Halting Problem, I said
>> the set of TMs that represent (or demonstrate) the problem. All the
>> textbooks represent this set as simply HP.
>
> My textbook says nothing of the sort. Can you be more explicit about 
> what you mean by "represent the problem"?
>
I will provide one single example, if you can't get it from this there is no hope for you.
HP is stated in several textbooks as the abbreviation of the pattern that forms the set of examples that are the Halting Problem.

0
NoSpam271 (937)
4/4/2012 2:02:32 AM
On Apr 3, 9:58=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> It can always decide halting whenever halting is decidable,

Halting IS ALWAYS decidable.

> otherwise  the input is erroneous,

The input IS NEVER "erroneous".
You may have chosen a string-encoding-of-TMs where a lot of strings
fail to encode TMs, but that does NOT make ANYthing "undecidable".
You can always decide to have ALL those strings represent THE SAME
TRIVIAL tm
AND KEEP GOING.

0
greeneg9613 (188)
4/4/2012 2:03:24 AM
On 4/2/2012 9:40 PM, Joshua Cranmer wrote:
> On 4/2/2012 9:23 PM, Peter Olcott wrote:
>> It is still a mistake to require a yes or no answer when no correct yes
>> or no answer exists within the scope of Pathological Self-Reference.
>
> You may believe that the definition is wrong, but everyone else has 
> gotten along swimmingly with it for 70 years. This of course means 
> that you're not disproving the Halting problem, but rather a (probably 
> not very interesting) non-standard variant of it.
>

The definition is incorrect in an absolute sense, as it one had the 
opinion that 2 + 7 = 32. When the subtle nuances are mathematically 
mapped to the details of their true meaning it all becomes 
self-evidently clear, that the Halting Problem is entirely based on a 
fundamental error of reasoning.

It is like faulting a CAD package for its inability to correctly 
represent  square circles. The error of Pathological Self-Reference 
makes the Halting Problem unsolvable only because it derives an 
erroneous question.
0
NoSpam271 (937)
4/4/2012 2:09:06 AM
On 4/2/2012 9:47 PM, Patricia Shanahan wrote:
> On 4/2/2012 7:18 PM, Peter Olcott wrote:
>> On 4/2/2012 5:38 PM, Patricia Shanahan wrote:
> ...
>>> That was my intent. Indeed, I am proposing standardizing, for purposes
>>> of this discussion, on using TMML to encode Turing Machines.
>>>
>>> Patricia
>> It might prove helpful. What is its syntax for specifying the Empty 
>> String?
>
> TMML is a language for describing Turing machines, not strings.
>
> Patricia

So how does one specify the empty string as input to this Turing Machine?
The simple answer of an empty tape is clear enough, what is the syntax 
to specify an empty tape?

0
NoSpam271 (937)
4/4/2012 2:11:29 AM
On 4/2/2012 4:02 PM, Ben Bacarisse wrote:
> George Greene<greeneg@email.unc.edu>  writes:
>
>> On Apr 1, 3:57 pm, Patricia Shanahan<p...@acm.org>  wrote:
>>> Of course, a completely empty string, without a TM, is represented, as
>>> usual, by a tape containing only blanks. A halting decider using this
>>> encoding should halt in a state indicating the string is not in the
>>> language.
>> This is NOT true.
>> The association between strings-representing-TMs and TMs IS ARBITRARY.
> Yes, but the representation is specified (at least for the case in
> question).  Surely the phrase "a halting decider using this encoding"
> means one using the encoding described immediately before.
>
> <snip>

The tape with only blanks is a fundamental aspect of the way that TM's 
are defined. The Tape alphabet beyond blanks has some leeway.
0
NoSpam271 (937)
4/4/2012 2:14:31 AM
On Apr 3, 10:09=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> The definition is incorrect in an absolute sense, as it one had the
> opinion that 2 + 7 =3D 32.

*DEFINITIONS* canNOT BE "incorrect in an absolute sense".
People can CALL things whatEVER they may WANT to call them --
that is why you have been able to get away with calling individual
things
"undecidable" -- according to the definition that everybody else uses,
decidability is a property of INfinitary questions -- all finite
questions are TRIVIALLY decidable.

"+"  IS JUST A SYMBOL.
ANYBODY COULD CHOOSE to define an alphabet-for-a-TM where
addition was represented by A DIFFERENT symbol.
What you are saying is analogous to declaring something incorrect
for being spelled in a different language.

The correctness or incorrectness of definitions is determined by the
definer and NObody
else.  That is the only reason you have been able to get away with
this for so long.
If you had to use the same definitions we did, most of your posts
would get
chopped in the first paragraph.
0
greeneg9613 (188)
4/4/2012 2:37:24 AM
On Apr 3, 10:09=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> It is like faulting a CAD package for its inability to correctly
> represent =A0square circles. The error of Pathological Self-Reference
> makes the Halting Problem unsolvable only because it derives an
> erroneous question.

NO, DUMBASS it is NOT like that.  The "Halting problem" DOES NOT
DERIVE
any questions.  The halting problem is ONLY about whether TMs
*that actually exist* halt on finite input strings that actually
exist.
All the examples that you are calling pathological involve calls to
a Halts() TM that DOES NOT exist, and therefore have nothing
to do with the halting problem whatsoever.


0
greeneg9613 (188)
4/4/2012 2:38:57 AM
On Apr 3, 10:11=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> So how does one specify the empty string as input to this Turing Machine?
> The simple answer of an empty tape is clear enough, what is the syntax
> to specify an empty tape?

As Patricia already told you, TMML is a language for describing TMs,
NOT input tapes.

0
greeneg9613 (188)
4/4/2012 2:41:25 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/2/2012 4:02 PM, Ben Bacarisse wrote:
>> George Greene<greeneg@email.unc.edu>  writes:
>>
>>> On Apr 1, 3:57 pm, Patricia Shanahan<p...@acm.org>  wrote:
>>>> Of course, a completely empty string, without a TM, is represented, as
>>>> usual, by a tape containing only blanks. A halting decider using this
>>>> encoding should halt in a state indicating the string is not in the
>>>> language.
>>> This is NOT true.
>>> The association between strings-representing-TMs and TMs IS ARBITRARY.
>> Yes, but the representation is specified (at least for the case in
>> question).  Surely the phrase "a halting decider using this encoding"
>> means one using the encoding described immediately before.
>>
>> <snip>
>
> The tape with only blanks is a fundamental aspect of the way that TM's
> are defined. The Tape alphabet beyond blanks has some leeway.

Yes. So?  From another recent post it seems you did not understand
Patricia's proposed encoding.

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 3:09:05 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/2/2012 9:47 PM, Patricia Shanahan wrote:
>> On 4/2/2012 7:18 PM, Peter Olcott wrote:
>>> On 4/2/2012 5:38 PM, Patricia Shanahan wrote:
>> ...
>>>> That was my intent. Indeed, I am proposing standardizing, for purposes
>>>> of this discussion, on using TMML to encode Turing Machines.
>>>>
>>>> Patricia
>>> It might prove helpful. What is its syntax for specifying the Empty
>>> String?
>>
>> TMML is a language for describing Turing machines, not strings.
>>
>> Patricia
>
> So how does one specify the empty string as input to this Turing Machine?
> The simple answer of an empty tape is clear enough, what is the syntax
> to specify an empty tape?

It was stated in Patricia's original posting about this encoding:

  "I propose encoding the TM in the Turing Machine Markup Language
  specified at http://www.unidex.com/turing/tmml.htm. Because it is
  based on XML, the end of the turing-machine element can be
  detected. Treat the non-blank portion of the tape following that as
  the input string."

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 3:10:45 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/2/2012 10:47 PM, Joshua Cranmer wrote:
>> On 4/2/2012 9:21 PM, Peter Olcott wrote:
>>> I think that there is more to it than this. If the undeciable cases can
>>> simply correctly take the halt in reject state, (because of the way that
>>> the question is phrased) then halting would become decidable.
>>
>> The way you would interpret the Halting problem is very different
>> from the way everyone else interprets it. The Halting problem, as it
>> is defined, is undecidable, even if you make the allowances you
>> wish, since the allowances don't change the definition in the first
>> place.
>>
>> There is a formal definition of the Halting problem. That the
>> English description can allow for different interpretations does not
>> change this formal definition, it just means that some people read
>> the wrong definition.
>
> What about when the empty string is input to the halt decider as the
> input TM? Must the halt decider always say yes or no, even in the case
> where the only correct answer is neither?

No, but since there is a correct answer, the question does not arise.

> Boolean Halts("", "");  // Neither true nor false is correct here

False is the correct answer in this case.

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 3:19:58 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/3/2012 11:33 AM, Patricia Shanahan wrote:
>> On 4/2/2012 7:21 PM, Peter Olcott wrote:
>> ...
>>> I think that there is more to it than this. If the undeciable cases can
>>> simply correctly take the halt in reject state, (because of the way that
>>> the question is phrased) then halting would become decidable.
>>
>> If some combination of hypothetical TMs would, in combination, decide
>> halting, at least one of them does not exist.
>>
>> Patricia
>
> It can always decide halting whenever halting is decidable, otherwise
> the input is erroneous, of the input TM fails to halt.

The set decided by such a combination of machines is still not the
halting set, regardless of what you call the subset of inputs that you
choose to ignore.

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 3:28:13 AM
On 4/3/2012 9:02 PM, Peter Olcott wrote:
> I will provide one single example, if you can't get it from this there
> is no hope for you.
> HP is stated in several textbooks as the abbreviation of the pattern
> that forms the set of examples that are the Halting Problem.

The claim "several textbooks" I think is inaccurate, since you appear to 
only have one and, oddly enough, one that no one else has. Nevertheless, 
that is still not the precise example. Can you give a precise, full 
quotation from the textbook?


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/4/2012 5:30:35 AM
Peter Olcott writes:
> On 4/2/2012 9:47 PM, Patricia Shanahan wrote:
> > On 4/2/2012 7:18 PM, Peter Olcott wrote:
> >> On 4/2/2012 5:38 PM, Patricia Shanahan wrote:
> > ...
> >>> That was my intent. Indeed, I am proposing standardizing, for
> >>> purposes of this discussion, on using TMML to encode Turing
> >>> Machines.
> >>>
> >>> Patricia
> >> It might prove helpful. What is its syntax for specifying the
> >> Empty String?
> >
> > TMML is a language for describing Turing machines, not strings.
> >
> > Patricia
> 
> So how does one specify the empty string as input to this Turing Machine?
> The simple answer of an empty tape is clear enough, what is the syntax
> to specify an empty tape?

The Universal Turing Machine XLS Transform, provided for running the
specific Turing Machines in TMML, appears to require a non-empty
string as the tape representation. The ROT13 TM on the site uses an
end-of-input marker; an empty tape would be specified as "$". The
example on the site use something called saxon that is called so:

   saxon rot13_tm.xml utm.xsl tape="plaintext$"

I used xsltproc to encode (decode?) the empty string so:

   xsltproc --stringparam tape '$' utm.xsl rot13_tm.xml

The palindrome recognizer (decider, really) does not use an end
marker, so the empty string should logically be encoded as the empty
string, which the UTM implementation cannot handle. It could, perhaps,
be argued that the empty string is invalid input as a palindrome
candidate. (Incidentally, success is indicated as an empty tape.)
0
jpiitula2 (679)
4/4/2012 6:55:13 AM
On 4/3/2012 9:09 PM, Peter Olcott wrote:
> On 4/2/2012 9:40 PM, Joshua Cranmer wrote:
>> On 4/2/2012 9:23 PM, Peter Olcott wrote:
>>> It is still a mistake to require a yes or no answer when no correct yes
>>> or no answer exists within the scope of Pathological Self-Reference.
>>
>> You may believe that the definition is wrong, but everyone else has
>> gotten along swimmingly with it for 70 years. This of course means
>> that you're not disproving the Halting problem, but rather a (probably
>> not very interesting) non-standard variant of it.
>>
>
> The definition is incorrect in an absolute sense, as it one had the
> opinion that 2 + 7 = 32. When the subtle nuances are mathematically
> mapped to the details of their true meaning it all becomes
> self-evidently clear, that the Halting Problem is entirely based on a
> fundamental error of reasoning.

No it is not. If the input is a Turing machine, then it must either, by 
definition, halt or fail to halt. It is a principle of all axiomatic 
systems that "A or not A" is always a true statement. The definition of 
the Halting problem requires anyone who wishes to solve it to divine the 
correct answer for all Turing machines as input. Your definition seeks 
to exclude a subset of Turing machines, and, more disingenuously, 
exclude a different subset of Turing machines depending on the claimed 
implementation of the algorithm. In terms of logical fallacies, I would 
classify this as "moving the goalposts" (but in the opposite direction 
of its normal usage).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/4/2012 6:52:50 PM
On 4/4/2012 12:30 AM, Joshua Cranmer wrote:
> On 4/3/2012 9:02 PM, Peter Olcott wrote:
>> I will provide one single example, if you can't get it from this there
>> is no hope for you.
>> HP is stated in several textbooks as the abbreviation of the pattern
>> that forms the set of examples that are the Halting Problem.
>
> The claim "several textbooks" I think is inaccurate, since you appear 
> to only have one and, oddly enough, one that no one else has. 
> Nevertheless, that is still not the precise example. Can you give a 
> precise, full quotation from the textbook?
>
>
I don't continue to play heads games with one who is pretending to not 
understand.
0
NoSpam271 (937)
4/4/2012 9:37:23 PM
On 4/1/2012 2:57 PM, Patricia Shanahan wrote:
> On 4/1/2012 7:20 AM, Peter Olcott wrote:
>> On 3/31/2012 2:23 PM, Patricia Shanahan wrote:
> ...
>>> Of course, a completely empty string, without a TM, is represented, as
>>> usual, by a tape containing only blanks. It should be rejected by a
>>> halting decider using this encoding.
>>>
>>> Patricia
>>
>> I don't think that the conventional Halting Problem allows for the
>> rejection of a blank tape. The TM must still report the (Yes or No)
>> answer regarding whether or not the TM specified by "" halts on the
>> input specified by "".
>
> Some courses and textbooks use "accept" as short for "halt in a state
> indicating the input string is in the language" and "reject" for "halt
> in a state indicating the input string is not in the language". That is
> the case for the most recent course I took, and textbook I read, on the
> subject so I tend to use those terms.
>
> Rewriting the paragraph you quoted in full:
>
> Of course, a completely empty string, without a TM, is represented, as
> usual, by a tape containing only blanks. A halting decider using this
> encoding should halt in a state indicating the string is not in the
> language.
>
> Patricia

So in other words it misrepresents that the TM specified by "" as not 
halting, when in truth it neither halts nor fails to halt.
0
NoSpam271 (937)
4/4/2012 9:40:25 PM
On 4/1/2012 11:15 AM, Patricia Shanahan wrote:
> On 4/1/2012 7:32 AM, Peter Olcott wrote:
>> On 3/31/2012 11:31 AM, Joshua Cranmer wrote:
>>> On 3/31/2012 7:45 AM, Peter Olcott wrote:
>>>> On 3/31/2012 12:50 AM, Joshua Cranmer wrote:
>>>>>>> How can it? "Decidable" is, by your definition, well-defined for 
>>>>>>> any
>>>>>>> Turing machine. So any attempt to implement DecidabilityDecider 
>>>>>>> must
>>>>>>> also work for the Turing machine I enumerated. In the case I gave,
>>>>>>> the
>>>>>>> "Decidable" set for that Turing machine is precisely the set which
>>>>>>> represents the Halting problem. Therefore, if DecidabilityDecider
>>>>>>> were
>>>>>>> to work properly, it must solve the Halting problem itself.
>>>>>>
>>>>>> Whenever the DecibilityDecider() encounters any instance of the
>>>>>> Halting
>>>>>> Problem, it simply correctly halts in its own reject state, 
>>>>>> indicating
>>>>>> undecidability.
>>>>>
>>>>> Since the full general Halting problem is undecidable,
>>>> yes
>>>> the set of TMs that represent the Halting Problem: HP
>>>
>>> No TM can solve the Halting problem. That is what undecidable means.
>>> HP is necessarily empty.
>>>
>> I did not say that set of TM's that solve the Halting Problem, I said
>> the set of TMs that represent (or demonstrate) the problem. All the
>> textbooks represent this set as simply HP.
>
> Could you give the reference to the place in Sipser's "Introduction to
> the Theory of Computation" where HP is defined this way? I looked it up
> in the index, and also scanned the section headed "The Halting Problem"
> without finding it.
>
> Patricia

Page 230 of lecture 31.
0
NoSpam271 (937)
4/4/2012 9:42:05 PM
On 4/3/2012 10:10 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 4/2/2012 9:47 PM, Patricia Shanahan wrote:
>>> On 4/2/2012 7:18 PM, Peter Olcott wrote:
>>>> On 4/2/2012 5:38 PM, Patricia Shanahan wrote:
>>> ...
>>>>> That was my intent. Indeed, I am proposing standardizing, for purposes
>>>>> of this discussion, on using TMML to encode Turing Machines.
>>>>>
>>>>> Patricia
>>>> It might prove helpful. What is its syntax for specifying the Empty
>>>> String?
>>> TMML is a language for describing Turing machines, not strings.
>>>
>>> Patricia
>> So how does one specify the empty string as input to this Turing Machine?
>> The simple answer of an empty tape is clear enough, what is the syntax
>> to specify an empty tape?
> It was stated in Patricia's original posting about this encoding:
>
>    "I propose encoding the TM in the Turing Machine Markup Language
>    specified at http://www.unidex.com/turing/tmml.htm. Because it is
>    based on XML, the end of the turing-machine element can be
>    detected. Treat the non-blank portion of the tape following that as
>    the input string."
>
I was asking for XML syntax, that is not XML.
0
NoSpam271 (937)
4/4/2012 9:43:28 PM
On 4/1/2012 3:01 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
> <snip>
>>> >>  No, a poem might be represent a machine, input pair.  Alternatively a
>>> >>  Vogan might think that some<t,i>   string makes a pretty good poem.
>>> >>  No matter what you call the input, the correct yes/no answer must be
>>> >>  provided.
>>> >>
>> >  I realized that just after I wrote this example, that is why I added
>> >  the dual inputs of empty string to the HaltDecider.
>> >
>> >  // function prototype
>> >  Boolean HaltDecider(String tm, String input);
>> >
>> >  // function invocation
>> >  HaltDecider("", "");
>> >
>> >  In this case the encoding is that the entire TM tape remains filled
>> >  with the space character thus indicating that there is no input at all
>> >  on the tape. Because a TM does not have any numerical representation
>> >  of a space character, this can not possibly be construed as a valid
>> >  TM.
> Unless you know (and tell us!) what the encoding rules are, you can't
> say that "this can not possibly be construed as a valid TM".
I already answered that sufficiently above, a blank is not encoded as 
anything else such as ASCII 32, it is hardwired as its own 
representation, and thus not stored within any bit pattern.
0
NoSpam271 (937)
4/4/2012 9:51:16 PM
On 4/4/2012 1:52 PM, Joshua Cranmer wrote:
> On 4/3/2012 9:09 PM, Peter Olcott wrote:
>> On 4/2/2012 9:40 PM, Joshua Cranmer wrote:
>>> On 4/2/2012 9:23 PM, Peter Olcott wrote:
>>>> It is still a mistake to require a yes or no answer when no correct 
>>>> yes
>>>> or no answer exists within the scope of Pathological Self-Reference.
>>>
>>> You may believe that the definition is wrong, but everyone else has
>>> gotten along swimmingly with it for 70 years. This of course means
>>> that you're not disproving the Halting problem, but rather a (probably
>>> not very interesting) non-standard variant of it.
>>>
>>
>> The definition is incorrect in an absolute sense, as it one had the
>> opinion that 2 + 7 = 32. When the subtle nuances are mathematically
>> mapped to the details of their true meaning it all becomes
>> self-evidently clear, that the Halting Problem is entirely based on a
>> fundamental error of reasoning.
>
> No it is not. If the input is a Turing machine, then it must either, 
> by definition, halt or fail to halt. It is a principle of all 
> axiomatic systems that "A or not A" is always a true statement. The 
> definition of the Halting problem requires anyone who wishes to solve 
> it to divine the correct answer for all Turing machines as input. Your 
> definition seeks to exclude a subset of Turing machines, and, more 
> disingenuously, exclude a different subset of Turing machines 
> depending on the claimed implementation of the algorithm. In terms of 
> logical fallacies, I would classify this as "moving the goalposts" 
> (but in the opposite direction of its normal usage).
>

I see you still fail to comprehend pathological self-reference.
0
NoSpam271 (937)
4/4/2012 9:53:45 PM
On 3/31/2012 12:00 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> >  On 3/31/2012 6:17 AM, Ben Bacarisse wrote:
>>> >>  Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>> >>
>>>>> >>>  >    On 3/30/2012 7:25 PM, Ben Bacarisse wrote:
>>>>>>> >>>>  >>    No we don't because all questions of the form "does machine t halt on
>>>>>>> >>>>  >>    input i" have correct yes/no answers.  I've said a little more on that
>>>>>>> >>>>  >>    elsewhere as well.  The actual question is "does my input represent a
>>>>>>> >>>>  >>    machine and string pair such that the machine halts when run on the
>>>>>>> >>>>  >>    string".  If the input does not represent what it should the correct
>>>>>>> >>>>  >>    answer is "no".
>>>>> >>>  >    You just broke the halting problem. Now the halt decider can simply
>>>>> >>>  >    correctly halt in its reject state because its input is erroneous.
>>> >>  No.  To use the notation I defied elsewhere, if halts(t, i) then<t, i>
>>> >>  is in the halting set.  Any machine h with h(<t, i>) = no is not
>>> >>  therefore a halting decider.
>>> >>
>> >
>> >  If (according to your own criterion, provided below) you are going to
>> >  screen out t = {English Poem} then this also logically entails
>> >  screening out instances of halts(t, i) that derive Pathological
>> >  Self-Reference.
> First, I did not say that poems should be "screened out".
>
>> >  Your own words:
>> >  "does my input represent a machine and string pair such that the
>> >  machine halts when run on the string".
> If "Pathological Self-Reference" means that the input does not represent
> an encoded<t, i>  pair such that halts(t, i) = true then a halting
> decider must reject the string.
Then the Halting Problem has always been decidable, when the halt 
analyzer halts in its reject state, even though its input TM will halt 
on its input, false is still the correct return value, because 
halts(t,i) != true.

(halts(t,i) != true) != (halts(t,i) == false)
0
NoSpam271 (937)
4/4/2012 10:01:55 PM
On 4/4/2012 4:40 PM, Peter Olcott wrote:
> So in other words it misrepresents that the TM specified by "" as not
> halting, when in truth it neither halts nor fails to halt.

Using the encoding we have defined, the phrase "the TM specified by ''" 
is ill-defined, for "" defines no TM.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/4/2012 10:28:58 PM
On 4/4/2012 4:53 PM, Peter Olcott wrote:
> I see you still fail to comprehend pathological self-reference.

How can I comprehend something you have not clearly defined? 
Seriously--I just came from a seminar where the entire time was spent 
trying to figure out what the notation being used in the paper actually 
meant and the conclusion derived was "it's either a wrong notation, or 
the notation is extremely sloppy."

As I said before, a Turing machine either halts or fails to halt by 
definition. Even if a Turing machine consists of "pathological 
self-reference" it is, by definition, a Turing machine. Note that, since 
the halting function is uncomputable, no input to the halting function 
can include as a subprogram the halting function, since that would make 
it not a Turing machine.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/4/2012 10:35:19 PM
On 4/4/2012 5:01 PM, Peter Olcott wrote:
> (halts(t,i) != true) != (halts(t,i) == false)

If t is a Turing machine, it does, by definition. This is why we cannot 
implement halts in a Turing machine.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/4/2012 10:36:48 PM
On 4/4/2012 4:42 PM, Peter Olcott wrote:
> On 4/1/2012 11:15 AM, Patricia Shanahan wrote:
>> Could you give the reference to the place in Sipser's "Introduction to
>> the Theory of Computation" where HP is defined this way? I looked it up
>> in the index, and also scanned the section headed "The Halting Problem"
>> without finding it.
>>
>> Patricia
>
> Page 230 of lecture 31.

I took the liberty of looking up page 230 in Sipser's "Introduction to 
the Theory of Computation" (2nd edition, fwiw). This is in the middle of 
the section on describing decidability of logical theories, and is the 
beginning of the discussion of the Gödel's Incompleteness Theorem. There 
is no reference to "HP" anywhere on that page.

So I will repeat Patricia's question: could you give the reference to 
the place in Sipser's "Introduction to the Theory of Computation" where 
HP is defined this way?

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/4/2012 10:45:17 PM
On 4/4/2012 4:37 PM, Peter Olcott wrote:
> On 4/4/2012 12:30 AM, Joshua Cranmer wrote:
>> On 4/3/2012 9:02 PM, Peter Olcott wrote:
>>> I will provide one single example, if you can't get it from this there
>>> is no hope for you.
>>> HP is stated in several textbooks as the abbreviation of the pattern
>>> that forms the set of examples that are the Halting Problem.
>>
>> The claim "several textbooks" I think is inaccurate, since you appear
>> to only have one and, oddly enough, one that no one else has.
>> Nevertheless, that is still not the precise example. Can you give a
>> precise, full quotation from the textbook?
>>
>>
> I don't continue to play heads games with one who is pretending to not
> understand.

I'll take that as a `no', in that you cannot give a quotation. Maybe 
I'll speculate that said textbook doesn't exist and you're merely 
"pretending" to have an authoritative reference to make us back down.

Also, why would I be "pretending" not to understand? Several people are 
legitimately confused by what you say, and I believe that all of us are 
legitimately failing to understand your points.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/4/2012 10:46:09 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/1/2012 2:57 PM, Patricia Shanahan wrote:
<snip>
>> Of course, a completely empty string, without a TM, is represented, as
>> usual, by a tape containing only blanks. A halting decider using this
>> encoding should halt in a state indicating the string is not in the
>> language.
<snip>
> So in other words it misrepresents that the TM specified by "" as not
> halting, when in truth it neither halts nor fails to halt.

No.  Using the specific encoding that's been proposed, an entirely empty
tape does not "represent a <t, i> pair with the property that halts(t,i)
is true".  Consequently, a halting decider TM must say so explicitly by
halting in a reject state.

Analogy: a decider for prime numbers must halt in a reject state when
given 42, "" or "banana".  The question being "is my input a sequence of
decimal digits, d, such that prime(value_of(d)) is true?".

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 11:13:48 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/3/2012 10:10 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 4/2/2012 9:47 PM, Patricia Shanahan wrote:
>>>> On 4/2/2012 7:18 PM, Peter Olcott wrote:
>>>>> On 4/2/2012 5:38 PM, Patricia Shanahan wrote:
>>>> ...
>>>>>> That was my intent. Indeed, I am proposing standardizing, for purposes
>>>>>> of this discussion, on using TMML to encode Turing Machines.
>>>>>>
>>>>>> Patricia
>>>>> It might prove helpful. What is its syntax for specifying the Empty
>>>>> String?
>>>> TMML is a language for describing Turing machines, not strings.
>>>>
>>>> Patricia
>>> So how does one specify the empty string as input to this Turing Machine?
>>> The simple answer of an empty tape is clear enough, what is the syntax
>>> to specify an empty tape?
>> It was stated in Patricia's original posting about this encoding:
>>
>>    "I propose encoding the TM in the Turing Machine Markup Language
>>    specified at http://www.unidex.com/turing/tmml.htm. Because it is
>>    based on XML, the end of the turing-machine element can be
>>    detected. Treat the non-blank portion of the tape following that as
>>    the input string."
>>
> I was asking for XML syntax, that is not XML.

Then you should not have been asking for that.  If you don't understand
the answer you've been given, ask about that answer.  I find Patricia's
description perfectly clear, which is why I re-quoted it.  Which part is
not clear to you?

If the encoding that's been proposed is too complicated for you, just
describe your own.  You should have considered this aspect of the
problem, at least in passing, since having a reasonable encoding is
central to defining the problem.

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 11:30:54 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/1/2012 3:01 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> >  On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
>> <snip>
>>>> >>  No, a poem might be represent a machine, input pair.  Alternatively a
>>>> >>  Vogan might think that some<t,i>   string makes a pretty good poem.
>>>> >>  No matter what you call the input, the correct yes/no answer must be
>>>> >>  provided.
>>>> >>
>>> >  I realized that just after I wrote this example, that is why I added
>>> >  the dual inputs of empty string to the HaltDecider.
>>> >
>>> >  // function prototype
>>> >  Boolean HaltDecider(String tm, String input);
>>> >
>>> >  // function invocation
>>> >  HaltDecider("", "");
>>> >
>>> >  In this case the encoding is that the entire TM tape remains filled
>>> >  with the space character thus indicating that there is no input at all
>>> >  on the tape. Because a TM does not have any numerical representation
>>> >  of a space character, this can not possibly be construed as a valid
>>> >  TM.
>> Unless you know (and tell us!) what the encoding rules are, you can't
>> say that "this can not possibly be construed as a valid TM".
> I already answered that sufficiently above, a blank is not encoded as
> anything else such as ASCII 32, it is hardwired as its own
> representation, and thus not stored within any bit pattern.

Oh dear.  I think you are losing whatever hold you had on this
discussion.  I would normally ask you what you think bit patterns have
to do with any of this, but I don't think you know yourself.

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 11:33:48 PM
On 4/4/2012 5:28 PM, Joshua Cranmer wrote:
> On 4/4/2012 4:40 PM, Peter Olcott wrote:
>> So in other words it misrepresents that the TM specified by "" as not
>> halting, when in truth it neither halts nor fails to halt.
>
> Using the encoding we have defined, the phrase "the TM specified by 
> ''" is ill-defined, for "" defines no TM.
>

Then the same applies to the Halting Problem, when Pathological 
Self-Reference occurs.
0
NoSpam271 (937)
4/4/2012 11:48:03 PM
On 4/4/2012 5:35 PM, Joshua Cranmer wrote:
> On 4/4/2012 4:53 PM, Peter Olcott wrote:
>> I see you still fail to comprehend pathological self-reference.
>
> How can I comprehend something you have not clearly defined? S
A perfect example was provided by Daryl.
0
NoSpam271 (937)
4/4/2012 11:49:18 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 3/31/2012 12:00 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
<you quoting me>
>>> >  Your own words:
>>> >  "does my input represent a machine and string pair such that the
>>> >  machine halts when run on the string".
>> If "Pathological Self-Reference" means that the input does not represent
>> an encoded<t, i>  pair such that halts(t, i) = true then a halting
>> decider must reject the string.
> Then the Halting Problem has always been decidable, when the halt
> analyzer halts in its reject state, even though its input TM will halt
> on its input, false is still the correct return value, because
> halts(t,i) != true.

That's too muddled to be worth unpicking.  Try to re-word it in terms of
encoded inputs and the mathematical objects they encode.

It's possible you've lost track of what I mean by halts(t, i).  It's the
mathematical halting function.

> (halts(t,i) != true) != (halts(t,i) == false)

That can't be the case.  Go back and look at the definition I gave for
the halts function.  You seem, once again, to be talking about some
problem that is not what everyone else means by the halting problem.

-- 
Ben.
0
ben.usenet (6790)
4/4/2012 11:52:17 PM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/4/2012 5:28 PM, Joshua Cranmer wrote:
>> On 4/4/2012 4:40 PM, Peter Olcott wrote:
>>> So in other words it misrepresents that the TM specified by "" as not
>>> halting, when in truth it neither halts nor fails to halt.
>>
>> Using the encoding we have defined, the phrase "the TM specified by
>> " is ill-defined, for "" defines no TM.
>>
>
> Then the same applies to the Halting Problem, when Pathological
> Self-Reference occurs.

Ha!  I feared you say exactly this when I read Joshua's post because
you've started replying by simply stringing vaguely related words
together.  Joshua was saying that your remark was meaningless because it
assumes something not in evidence at the time.  The required action of
halting decider is perfect well-defined in all cases -- even those where
the input is not to your liking.  (That's the best term I can come up
with for Pathological Self-Reference since it remains undefined.)

-- 
Ben.
0
ben.usenet (6790)
4/5/2012 12:01:56 AM
On 4/4/2012 5:36 PM, Joshua Cranmer wrote:
> On 4/4/2012 5:01 PM, Peter Olcott wrote:
>> (halts(t,i) != true) != (halts(t,i) == false)
>
> If t is a Turing machine, it does, by definition. This is why we 
> cannot implement halts in a Turing machine.
>

When Pathological Self-Reference occurs:
(halts(t,i) != true) != (halts(t,i) == false)

Boolean Halts(String tm, String input);

M( String Input )
{
if ( Halts( Input, Input ) )
   Loop Forever;
else
   Exit;
}

1) Halts(M, M) == true  indicates that {TM M will halt on input M}.

2) Halts(M, M) == false indicates that {TM M will not halt on input M}.

3) Halts(M, M) != true  indicates that either {TM M will not halt on 
input M} *or* {Halts(M, M) is undecidable}.

0
NoSpam271 (937)
4/5/2012 12:03:28 AM
On 4/4/2012 7:03 PM, Peter Olcott wrote:
> On 4/4/2012 5:36 PM, Joshua Cranmer wrote:
>> On 4/4/2012 5:01 PM, Peter Olcott wrote:
>>> (halts(t,i) != true) != (halts(t,i) == false)
>>
>> If t is a Turing machine, it does, by definition. This is why we
>> cannot implement halts in a Turing machine.
>>
>
> When Pathological Self-Reference occurs:
> (halts(t,i) != true) != (halts(t,i) == false)

If this is true, then pathological self-reference results in something 
that it is not a Turing machine. No one claims that halting works when 
presented with something other than a Turing machine is presented as input.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/5/2012 12:35:14 AM
On 4/4/2012 6:48 PM, Peter Olcott wrote:
> On 4/4/2012 5:28 PM, Joshua Cranmer wrote:
>> On 4/4/2012 4:40 PM, Peter Olcott wrote:
>>> So in other words it misrepresents that the TM specified by "" as not
>>> halting, when in truth it neither halts nor fails to halt.
>>
>> Using the encoding we have defined, the phrase "the TM specified by
>> ''" is ill-defined, for "" defines no TM.
>>
>
> Then the same applies to the Halting Problem, when Pathological
> Self-Reference occurs.

The best I can get of this statement is that you believe that 
"Pathological self-reference" is not a TM.

We seem to be getting off on several sidetracks here, but to bring this 
back to a point, I ask the following challenge of you:

Define, precisely, a concrete decision tree that can be performed by a 
Turing machine to decide whether or not Pathological self-reference 
occurs, without referring to the halting problem in the definition (this 
avoids any hint of circularity in your argument).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/5/2012 12:37:35 AM
Joshua Cranmer <Pidgeot18@verizon.invalid> writes:

> On 4/4/2012 7:03 PM, Peter Olcott wrote:
>> On 4/4/2012 5:36 PM, Joshua Cranmer wrote:
>>> On 4/4/2012 5:01 PM, Peter Olcott wrote:
>>>> (halts(t,i) != true) != (halts(t,i) == false)
>>>
>>> If t is a Turing machine, it does, by definition. This is why we
>>> cannot implement halts in a Turing machine.
>>>
>>
>> When Pathological Self-Reference occurs:
>> (halts(t,i) != true) != (halts(t,i) == false)
>
> If this is true, then pathological self-reference results in something
> that it is not a Turing machine.

Peter has now stated this (or something similar) several times.  I think
it is time to be up-front and to say that he's not talking about (and
has presumably never been talking about) TM halting.  The halting
problem is precisely the task of finding a TM that calculates halts (the
mathematical total function from (machine, input) pairs to {true,
false}) and he does not accept that this function exists.  Either that,
or he wants to re-define the problem as one of computing a partial
function from (machine, input) to {true, false}.  He's said both at one
time or another, so it could be either (or both!).

> No one claims that halting works when
> presented with something other than a Turing machine is presented as
> input.

I can see this going wrong!  You are absolutely right, but I can
guarantee that Peter will say that this is exactly what we've been
"forcing" halting deciders to so.  He won't be able to separate the fact
that halting is only defined for (machine, input) pairs, from the fact
that a halting decider must be defined for all input strings (even when
they don't encode a machine).  He's been thrown off course by this new
discussion of encoding.

-- 
Ben.
0
ben.usenet (6790)
4/5/2012 12:56:41 AM
On Thu, 05 Apr 2012 01:56:41 +0100, Ben Bacarisse wrote:

> He's been thrown off course by this new discussion of encoding.

Forgive me entering in here as a completely ill-informed bystander, but 
it seems to me that P.O. was never on course in the first place.  I read 
this thread for its entertainment factor, but unless I am way off base, I 
feel sorry for the amount of time it must be taking to produce such a 
wealth of responses to what, as far as I can tell, is a brick wall.

-- 
Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.
0
arcfide (659)
4/5/2012 2:37:30 AM
On Apr 4, 7:30=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> If the encoding that's been proposed is too complicated for you, just
> describe your own.

The problem IS NOT that it is too complicated for him;
the problem is that (AS *I* said at the beginning), IT HAS HOLES.
You CAN'T (pedagogically vs. him)  have holes because his whole point
is that he is going
to claim equivalence BETWEEN "having a hole" (i.e. supplying an
input that is semantically wrong because it is not of the appopriate
Type)
and committing the "wrong" kind of self-reference.
0
greeneg9613 (188)
4/5/2012 2:58:48 AM
"Aaron W. Hsu" <arcfide@sacrideo.us> writes:

> On Thu, 05 Apr 2012 01:56:41 +0100, Ben Bacarisse wrote:
>
>> He's been thrown off course by this new discussion of encoding.
>
> Forgive me entering in here as a completely ill-informed bystander, but 
> it seems to me that P.O. was never on course in the first place.

No he wasn't, but, for whatever reason, these huge threads have
eventually clarified some key facts.

>  I read 
> this thread for its entertainment factor, but unless I am way off base, I 
> feel sorry for the amount of time it must be taking to produce such a 
> wealth of responses to what, as far as I can tell, is a brick wall.

Please don't worry about that!  It takes very little time, and I've
enjoyed re-working these ideas in a new context, even if it is a rather
sterile one.  When I was teaching, I would, on occasion, actually talk
to a *real* brick wall in order to find the right words to make some key
point or other.

I know that reason won't have any effect.  People who have (in their
view) overturned established wisdom, yet choose to tell people about it
by posting on Usenet rather than by writing a paper, are clearly
motivated by psychological rather than mathematical goals.  I do worry
about clogging up news groups that were once useful with this sort of
nonsense but, frankly, that sip has sailed.  Anyway, the posts are all
contained in easy to kill threads.  I only hope that their presence does
not deter those few people who come here with real matters of theory to
discuss.

-- 
Ben.
0
ben.usenet (6790)
4/5/2012 11:21:31 AM
George Greene <greeneg@email.unc.edu> writes:

> On Apr 4, 7:30 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> If the encoding that's been proposed is too complicated for you, just
>> describe your own.
>
> The problem IS NOT that it is too complicated for him;
> the problem is that (AS *I* said at the beginning), IT HAS HOLES.
> You CAN'T (pedagogically vs. him)  have holes because his whole point
> is that he is going
> to claim equivalence BETWEEN "having a hole" (i.e. supplying an
> input that is semantically wrong because it is not of the appopriate
> Type)
> and committing the "wrong" kind of self-reference.

Yes, it's clear that he hopes to do that.

The "holes" (if I understand you correctly) are only there when using
shorthand terms like "that does not encode a valid machine".  If E is
set of all <t, i> strings, the halting set, H, is

  { s in E such that halts(t, i) }

and the "holes" don't matter any more -- there is just a set of strings
to accept and a set to reject (those in Sigma* - H).  It's true that
Peter wants to widen the informal term "valid input", but we should just
make it clear that that is not what people call the halting problem.
All inputs are valid halting questions.

He also wants to re-define halts(t, i) so that it is not a total
function or, maybe, that it's codomain is bigger than {true, false}.
That, again, means he's not talking about the halting problem.  This is
a somewhat charitable interpretation, because he's actually asserted
that halts(t, i) *as usually defined* is not always true or false.

-- 
Ben.
0
ben.usenet (6790)
4/5/2012 12:20:06 PM
On 4/4/2012 7:37 PM, Aaron W. Hsu wrote:
> On Thu, 05 Apr 2012 01:56:41 +0100, Ben Bacarisse wrote:
>
>> He's been thrown off course by this new discussion of encoding.
>
> Forgive me entering in here as a completely ill-informed bystander, but
> it seems to me that P.O. was never on course in the first place.  I read
> this thread for its entertainment factor, but unless I am way off base, I
> feel sorry for the amount of time it must be taking to produce such a
> wealth of responses to what, as far as I can tell, is a brick wall.
>

The really unfortunate time wasting is on P.O.'s part. If he wants to
understand the subject matter of this thread, he needs to spend some
time studying mathematics. He has no idea of what constitutes a
mathematical definition or proof.

Firing off random responses to articles he has not understood, and
cannot understand because he lacks that foundation, will not help him
achieve anything remotely useful, or even impress comp.theory readers.

Patricia
0
pats (3556)
4/5/2012 2:02:03 PM
On Apr 5, 4:21=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "Aaron W. Hsu" <arcf...@sacrideo.us> writes:
>
> > On Thu, 05 Apr 2012 01:56:41 +0100, Ben Bacarisse wrote:
>
> >> He's been thrown off course by this new discussion of encoding.
>
> > Forgive me entering in here as a completely ill-informed bystander, but
> > it seems to me that P.O. was never on course in the first place.
>
> No he wasn't, but, for whatever reason, these huge threads have
> eventually clarified some key facts.
>
> > =A0I read
> > this thread for its entertainment factor, but unless I am way off base,=
 I
> > feel sorry for the amount of time it must be taking to produce such a
> > wealth of responses to what, as far as I can tell, is a brick wall.
>
> Please don't worry about that! =A0It takes very little time, and I've
> enjoyed re-working these ideas in a new context, even if it is a rather
> sterile one. =A0When I was teaching, I would, on occasion, actually talk
> to a *real* brick wall in order to find the right words to make some key
> point or other.
>
> I know that reason won't have any effect. =A0People who have (in their
> view) overturned established wisdom, yet choose to tell people about it
> by posting on Usenet rather than by writing a paper, are clearly
> motivated by psychological rather than mathematical goals. =A0I do worry
> about clogging up news groups that were once useful with this sort of
> nonsense but, frankly, that sip has sailed. =A0Anyway, the posts are all
> contained in easy to kill threads. =A0I only hope that their presence doe=
s
> not deter those few people who come here with real matters of theory to
> discuss.
>
> --
> Ben.


Well, it seems clear to say that it's not he "has no idea of what
constitutes a mathematical definition or proof", anyone most surely
does.

Yes, to expect him to discover "new" (to us) proofs and theorems that
thousands of years of mathematicians lacked the background,
wherewithal, or care to know, that is he creative enough to find a
constructive direction and lucky and smart enough to assemble a proof
where they weren't, or we aren't: to expect that is placing a lot of
faith in him, which as you note would be misplaced for the general
case that he's a crank or troll.

But, if Pete Olcott is actually sincere, (and if he learns), then is
there actually anything wrong to say about that?  Do it better.  Step
up (... or don't).

Crank, crackpot, troll:  Pete, do you consider yourself any of these
things as why you write to sci.math?  I understand how you might feel
like those things, what I want to know is if you actually identify, or
that you feel they are external labels that don't reflect you.

There are infinite dimensions in mathematics, there's pretty much room
for everybody to find something in mathematics.  In the applied yes
everybody does use it every day and it's good to know more and better.

Now it may be that Pete can plain list to us these structural details
of the development, acknowledge points of contention and resolve
them.  Here, there are right ways to do that.

Ah, of course here particularly, where he is claiming results that
basically "contradict dogma", yes then it's his responsibility to
maintain his definitions and to not pollute the standard definitions,
although he can build with them.

However, if he builds it with standard definitions, yes then he must
show it should be dogma.

Yet, sometimes the advantage of finding a truth, has that Pete wants
both this new truth as it could be and dogma to support his reason.

Then as logicians there aren't unknowns in that.

No, sci.math is not a productive tool for the development of new
mathematics.  You want mathoverflow.net and arxiv.org, into citeseer
and publishing.    Get a job, as it were.

However, there are usually at least a half dozen Ph.D.s, that know all
their dogma and will tell you, that are easily trolled and will reply
to your e-mails.  So when you actually do build something and want
others to attack it so you can see if it fails or how you need to
defend it, where the goal is the closure of that in axiomatics, then
it's useful to have these able participants basically point to next
proofs.

No, though, crackpots, cranks, and trolls are a lot easier to ignore
on, say, sci.math or sci.logic, there are right and wrong answers to
having definitions.

Then, if you're not interested in working up and out the paradoxes of
mathematical logic, you're in the wrong room.

There ain't no more trolls on the Internet.

Are you talking to me?  Read it again.

Thanks,

Ross Finlayson
0
4/5/2012 6:45:46 PM
On 4/4/2012 5:45 PM, Joshua Cranmer wrote:
> On 4/4/2012 4:42 PM, Peter Olcott wrote:
>> On 4/1/2012 11:15 AM, Patricia Shanahan wrote:
>>> Could you give the reference to the place in Sipser's "Introduction to
>>> the Theory of Computation" where HP is defined this way? I looked it up
>>> in the index, and also scanned the section headed "The Halting Problem"
>>> without finding it.
>>>
>>> Patricia
>>
>> Page 230 of lecture 31.
>
> I took the liberty of looking up page 230 in Sipser's "Introduction to 
> the Theory of Computation" (2nd edition, fwiw). This is in the middle 
> of the section on describing decidability of logical theories, and is 
> the beginning of the discussion of the Gödel's Incompleteness Theorem. 
> There is no reference to "HP" anywhere on that page.
>
> So I will repeat Patricia's question: could you give the reference to 
> the place in Sipser's "Introduction to the Theory of Computation" 
> where HP is defined this way?
>
1997 edition.
0
NoSpam271 (937)
4/6/2012 12:39:32 AM
On 4/4/2012 5:46 PM, Joshua Cranmer wrote:
> On 4/4/2012 4:37 PM, Peter Olcott wrote:
>> On 4/4/2012 12:30 AM, Joshua Cranmer wrote:
>>> On 4/3/2012 9:02 PM, Peter Olcott wrote:
>>>> I will provide one single example, if you can't get it from this there
>>>> is no hope for you.
>>>> HP is stated in several textbooks as the abbreviation of the pattern
>>>> that forms the set of examples that are the Halting Problem.
>>>
>>> The claim "several textbooks" I think is inaccurate, since you appear
>>> to only have one and, oddly enough, one that no one else has.
>>> Nevertheless, that is still not the precise example. Can you give a
>>> precise, full quotation from the textbook?
>>>
>>>
>> I don't continue to play heads games with one who is pretending to not
>> understand.
>
> I'll take that as a `no', in that you cannot give a quotation. Maybe 
> I'll speculate that said textbook doesn't exist and you're merely 
> "pretending" to have an authoritative reference to make us back down.
>
> Also, why would I be "pretending" not to understand? Several people 
> are legitimately confused by what you say, and I believe that all of 
> us are legitimately failing to understand your points.
>
I now have four, I also bought Sipser, your mistake for assuming.
0
NoSpam271 (937)
4/6/2012 12:40:43 AM
On 4/4/2012 6:13 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 4/1/2012 2:57 PM, Patricia Shanahan wrote:
> <snip>
>>> Of course, a completely empty string, without a TM, is represented, as
>>> usual, by a tape containing only blanks. A halting decider using this
>>> encoding should halt in a state indicating the string is not in the
>>> language.
> <snip>
>> So in other words it misrepresents that the TM specified by "" as not
>> halting, when in truth it neither halts nor fails to halt.
> No.  Using the specific encoding that's been proposed, an entirely empty
> tape does not "represent a<t, i>  pair with the property that halts(t,i)
> is true".  Consequently, a halting decider TM must say so explicitly by
> halting in a reject state.
>
> Analogy: a decider for prime numbers must halt in a reject state when
> given 42, "" or "banana".  The question being "is my input a sequence of
> decimal digits, d, such that prime(value_of(d)) is true?".
>
Then it must also halt in the reject state for undecibility.
0
NoSpam271 (937)
4/6/2012 12:41:53 AM
On 4/5/2012 9:02 AM, Patricia Shanahan wrote:
> On 4/4/2012 7:37 PM, Aaron W. Hsu wrote:
>> On Thu, 05 Apr 2012 01:56:41 +0100, Ben Bacarisse wrote:
>>
>>> He's been thrown off course by this new discussion of encoding.
>>
>> Forgive me entering in here as a completely ill-informed bystander, but
>> it seems to me that P.O. was never on course in the first place.  I read
>> this thread for its entertainment factor, but unless I am way off 
>> base, I
>> feel sorry for the amount of time it must be taking to produce such a
>> wealth of responses to what, as far as I can tell, is a brick wall.
>>
>
> The really unfortunate time wasting is on P.O.'s part. If he wants to
> understand the subject matter of this thread, he needs to spend some
> time studying mathematics. He has no idea of what constitutes a
> mathematical definition or proof.
>
> Firing off random responses to articles he has not understood, and
> cannot understand because he lacks that foundation, will not help him
> achieve anything remotely useful, or even impress comp.theory readers.
>
> Patricia

It might seem that way from your point of view.
0
NoSpam271 (937)
4/6/2012 12:43:32 AM
On 4/5/2012 5:39 PM, Peter Olcott wrote:
> On 4/4/2012 5:45 PM, Joshua Cranmer wrote:
>> On 4/4/2012 4:42 PM, Peter Olcott wrote:
>>> On 4/1/2012 11:15 AM, Patricia Shanahan wrote:
>>>> Could you give the reference to the place in Sipser's "Introduction to
>>>> the Theory of Computation" where HP is defined this way? I looked it up
>>>> in the index, and also scanned the section headed "The Halting Problem"
>>>> without finding it.
>>>>
>>>> Patricia
>>>
>>> Page 230 of lecture 31.
>>
>> I took the liberty of looking up page 230 in Sipser's "Introduction to
>> the Theory of Computation" (2nd edition, fwiw). This is in the middle
>> of the section on describing decidability of logical theories, and is
>> the beginning of the discussion of the Gödel's Incompleteness Theorem.
>> There is no reference to "HP" anywhere on that page.
>>
>> So I will repeat Patricia's question: could you give the reference to
>> the place in Sipser's "Introduction to the Theory of Computation"
>> where HP is defined this way?
>>
> 1997 edition.

My copy is copyright 1997. Its page 230 is part of the discussion of the
definition of "Time Complexity", Chapter 7, definition 7.7.

Patricia
0
pats (3556)
4/6/2012 12:46:56 AM
On 4/5/2012 7:20 AM, Ben Bacarisse wrote:
> George Greene<greeneg@email.unc.edu>  writes:
>
>> On Apr 4, 7:30 pm, Ben Bacarisse<ben.use...@bsb.me.uk>  wrote:
>>> If the encoding that's been proposed is too complicated for you, just
>>> describe your own.
>> The problem IS NOT that it is too complicated for him;
>> the problem is that (AS *I* said at the beginning), IT HAS HOLES.
>> You CAN'T (pedagogically vs. him)  have holes because his whole point
>> is that he is going
>> to claim equivalence BETWEEN "having a hole" (i.e. supplying an
>> input that is semantically wrong because it is not of the appopriate
>> Type)
>> and committing the "wrong" kind of self-reference.
> Yes, it's clear that he hopes to do that.
>
> The "holes" (if I understand you correctly) are only there when using
> shorthand terms like "that does not encode a valid machine".  If E is
> set of all<t, i>  strings, the halting set, H, is
>
>    { s in E such that halts(t, i) }
>
> and the "holes" don't matter any more -- there is just a set of strings
> to accept and a set to reject (those in Sigma* - H).  It's true that
> Peter wants to widen the informal term "valid input", but we should just
> make it clear that that is not what people call the halting problem.
> All inputs are valid halting questions.
>
> He also wants to re-define halts(t, i) so that it is not a total
> function or, maybe, that it's codomain is bigger than {true, false}.
> That, again, means he's not talking about the halting problem.  This is
> a somewhat charitable interpretation, because he's actually asserted
> that halts(t, i) *as usually defined* is not always true or false.
>
It is real simple:

halts(t, i) == true // The input TM halts on its input

halts(t, i) != true
// Either {The input TM does not halt on its input} or {the invocation is undecidable}.



0
NoSpam271 (937)
4/6/2012 12:49:14 AM
On 4/4/2012 9:37 PM, Aaron W. Hsu wrote:
> On Thu, 05 Apr 2012 01:56:41 +0100, Ben Bacarisse wrote:
>
>> He's been thrown off course by this new discussion of encoding.
> Forgive me entering in here as a completely ill-informed bystander, but
> it seems to me that P.O. was never on course in the first place.  I read
> this thread for its entertainment factor, but unless I am way off base, I
> feel sorry for the amount of time it must be taking to produce such a
> wealth of responses to what, as far as I can tell, is a brick wall.
>

So you don't understand Pathological Self-Reference, either?
I explained it quite clearly in my other thread.
0
NoSpam271 (937)
4/6/2012 12:52:09 AM
On 4/4/2012 7:35 PM, Joshua Cranmer wrote:
> On 4/4/2012 7:03 PM, Peter Olcott wrote:
>> On 4/4/2012 5:36 PM, Joshua Cranmer wrote:
>>> On 4/4/2012 5:01 PM, Peter Olcott wrote:
>>>> (halts(t,i) != true) != (halts(t,i) == false)
>>>
>>> If t is a Turing machine, it does, by definition. This is why we
>>> cannot implement halts in a Turing machine.
>>>
>>
>> When Pathological Self-Reference occurs:
>> (halts(t,i) != true) != (halts(t,i) == false)
>
> If this is true, then pathological self-reference results in something 
> that it is not a Turing machine. No one claims that halting works when 
> presented with something other than a Turing machine is presented as 
> input.
>
halts(t,i) = false // The input TM halts on its input
halts(t,i) != true // Also includes undecidability.
0
NoSpam271 (937)
4/6/2012 12:55:10 AM
On 4/4/2012 7:01 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 4/4/2012 5:28 PM, Joshua Cranmer wrote:
>>> On 4/4/2012 4:40 PM, Peter Olcott wrote:
>>>> So in other words it misrepresents that the TM specified by "" as not
>>>> halting, when in truth it neither halts nor fails to halt.
>>> Using the encoding we have defined, the phrase "the TM specified by
>>> " is ill-defined, for "" defines no TM.
>>>
>> Then the same applies to the Halting Problem, when Pathological
>> Self-Reference occurs.
> Ha!  I feared you say exactly this when I read Joshua's post because
> you've started replying by simply stringing vaguely related words
> together.  Joshua was saying that your remark was meaningless because it
> assumes something not in evidence at the time.  The required action of
> halting decider is perfect well-defined in all cases -- even those where
> the input is not to your liking.  (That's the best term I can come up
> with for Pathological Self-Reference since it remains undefined.)
>
When I say things that can't be misunderstood they are simply ignored 
and trimmed from my post.
0
NoSpam271 (937)
4/6/2012 12:56:26 AM
On 4/4/2012 6:52 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 3/31/2012 12:00 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
> <you quoting me>
>>>>>   Your own words:
>>>>>   "does my input represent a machine and string pair such that the
>>>>>   machine halts when run on the string".
>>> If "Pathological Self-Reference" means that the input does not represent
>>> an encoded<t, i>   pair such that halts(t, i) = true then a halting
>>> decider must reject the string.
>> Then the Halting Problem has always been decidable, when the halt
>> analyzer halts in its reject state, even though its input TM will halt
>> on its input, false is still the correct return value, because
>> halts(t,i) != true.
> That's too muddled to be worth unpicking.  Try to re-word it in terms of
> encoded inputs and the mathematical objects they encode.
>
> It's possible you've lost track of what I mean by halts(t, i).  It's the
> mathematical halting function.
>
>> (halts(t,i) != true) != (halts(t,i) == false)
> That can't be the case.  Go back and look at the definition I gave for
> the halts function.  You seem, once again, to be talking about some
> problem that is not what everyone else means by the halting problem.
>
I am not going to keep repeating myself.
0
NoSpam271 (937)
4/6/2012 12:57:06 AM
On 4/4/2012 6:33 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 4/1/2012 3:01 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>
>>>>>   On 3/31/2012 11:31 AM, Ben Bacarisse wrote:
>>> <snip>
>>>>>>>   No, a poem might be represent a machine, input pair.  Alternatively a
>>>>>>>   Vogan might think that some<t,i>    string makes a pretty good poem.
>>>>>>>   No matter what you call the input, the correct yes/no answer must be
>>>>>>>   provided.
>>>>>>>
>>>>>   I realized that just after I wrote this example, that is why I added
>>>>>   the dual inputs of empty string to the HaltDecider.
>>>>>
>>>>>   // function prototype
>>>>>   Boolean HaltDecider(String tm, String input);
>>>>>
>>>>>   // function invocation
>>>>>   HaltDecider("", "");
>>>>>
>>>>>   In this case the encoding is that the entire TM tape remains filled
>>>>>   with the space character thus indicating that there is no input at all
>>>>>   on the tape. Because a TM does not have any numerical representation
>>>>>   of a space character, this can not possibly be construed as a valid
>>>>>   TM.
>>> Unless you know (and tell us!) what the encoding rules are, you can't
>>> say that "this can not possibly be construed as a valid TM".
>> I already answered that sufficiently above, a blank is not encoded as
>> anything else such as ASCII 32, it is hardwired as its own
>> representation, and thus not stored within any bit pattern.
> Oh dear.  I think you are losing whatever hold you had on this
> discussion.  I would normally ask you what you think bit patterns have
> to do with any of this, but I don't think you know yourself.
>
I have to put in too much over-time at work to focus properly. In any 
case the blank does not have to be encoded at all, the TM does not have 
to be a digital or even an analog machine. I think that I recall that 
Turing originally envisioned a human with a pencil and paper, the paper 
was the tape, the human was the TM.
0
NoSpam271 (937)
4/6/2012 1:01:32 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/5/2012 7:20 AM, Ben Bacarisse wrote:
<snip>
>> He also wants to re-define halts(t, i) so that it is not a total
>> function or, maybe, that it's codomain is bigger than {true, false}.
>> That, again, means he's not talking about the halting problem.  This is
>> a somewhat charitable interpretation, because he's actually asserted
>> that halts(t, i) *as usually defined* is not always true or false.
>>
> It is real simple:
>
> halts(t, i) == true // The input TM halts on its input
>
> halts(t, i) != true
> // Either {The input TM does not halt on its input} or {the invocation
> is undecidable}.

Yes, apart from all the odd uses of terms, that's been clear for some
time now.  You should come up with a name for this problem --
quasi-halting?  Almost halting?  It's not "the halting problem".

If you are interested, the odd usages are "halts" for a function that
does not indicate halting, and "undecidable" for a specific (t, i) pair.

Also, I suspect you've switched to talking about machines here.  I was
talking about functions, not machines.

-- 
Ben.
0
ben.usenet (6790)
4/6/2012 1:31:22 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/4/2012 6:13 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 4/1/2012 2:57 PM, Patricia Shanahan wrote:
>> <snip>
>>>> Of course, a completely empty string, without a TM, is represented, as
>>>> usual, by a tape containing only blanks. A halting decider using this
>>>> encoding should halt in a state indicating the string is not in the
>>>> language.
>> <snip>
>>> So in other words it misrepresents that the TM specified by "" as not
>>> halting, when in truth it neither halts nor fails to halt.
>> No.  Using the specific encoding that's been proposed, an entirely empty
>> tape does not "represent a<t, i>  pair with the property that halts(t,i)
>> is true".  Consequently, a halting decider TM must say so explicitly by
>> halting in a reject state.
>>
>> Analogy: a decider for prime numbers must halt in a reject state when
>> given 42, "" or "banana".  The question being "is my input a sequence of
>> decimal digits, d, such that prime(value_of(d)) is true?".
>>
> Then it must also halt in the reject state for undecibility.

Only you can know.  You are using "undecibility" in a non-standard way
and dozens of messages have not brought forth a clear definition.

I can say this.  If you are right, and all the inputs that meet your
definition of "undecidable" are ones which a decider should reject, then
"undecidable" is a very odd word to have chosen for whatever criterion
it represents.

-- 
Ben.
0
ben.usenet (6790)
4/6/2012 1:42:58 AM
On 4/5/2012 7:46 PM, Patricia Shanahan wrote:
> On 4/5/2012 5:39 PM, Peter Olcott wrote:
>> On 4/4/2012 5:45 PM, Joshua Cranmer wrote:
>>> On 4/4/2012 4:42 PM, Peter Olcott wrote:
>>>> On 4/1/2012 11:15 AM, Patricia Shanahan wrote:
>>>>> Could you give the reference to the place in Sipser's 
>>>>> "Introduction to
>>>>> the Theory of Computation" where HP is defined this way? I looked 
>>>>> it up
>>>>> in the index, and also scanned the section headed "The Halting 
>>>>> Problem"
>>>>> without finding it.
>>>>>
>>>>> Patricia
>>>>
>>>> Page 230 of lecture 31.
>>>
>>> I took the liberty of looking up page 230 in Sipser's "Introduction to
>>> the Theory of Computation" (2nd edition, fwiw). This is in the middle
>>> of the section on describing decidability of logical theories, and is
>>> the beginning of the discussion of the Gödel's Incompleteness Theorem.
>>> There is no reference to "HP" anywhere on that page.
>>>
>>> So I will repeat Patricia's question: could you give the reference to
>>> the place in Sipser's "Introduction to the Theory of Computation"
>>> where HP is defined this way?
>>>
>> 1997 edition.
>
> My copy is copyright 1997. Its page 230 is part of the discussion of the
> definition of "Time Complexity", Chapter 7, definition 7.7.
>
> Patricia
Below the paragraph named Diagonalization:

HP def...
0
NoSpam271 (937)
4/6/2012 2:07:52 AM
On Apr 5, 8:55=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:

> halts(t,i) =3D false // The input TM halts on its input

You surely MEANT > halts(t,i)=3D TRUE.


> halts(t,i) !=3D true // Also includes undecidability.

You mean, // Also includes the case where halts(,) DOES NOT HALT.
That is NOT the same thing as "undecidability".  Your insistence on
calling it that just proves you're stupid.


0
greeneg9613 (188)
4/6/2012 2:10:44 AM
On 4/5/2012 8:42 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 4/4/2012 6:13 PM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>
>>>> On 4/1/2012 2:57 PM, Patricia Shanahan wrote:
>>> <snip>
>>>>> Of course, a completely empty string, without a TM, is represented, as
>>>>> usual, by a tape containing only blanks. A halting decider using this
>>>>> encoding should halt in a state indicating the string is not in the
>>>>> language.
>>> <snip>
>>>> So in other words it misrepresents that the TM specified by "" as not
>>>> halting, when in truth it neither halts nor fails to halt.
>>> No.  Using the specific encoding that's been proposed, an entirely empty
>>> tape does not "represent a<t, i>   pair with the property that halts(t,i)
>>> is true".  Consequently, a halting decider TM must say so explicitly by
>>> halting in a reject state.
>>>
>>> Analogy: a decider for prime numbers must halt in a reject state when
>>> given 42, "" or "banana".  The question being "is my input a sequence of
>>> decimal digits, d, such that prime(value_of(d)) is true?".
>>>
>> Then it must also halt in the reject state for undecibility.
> Only you can know.  You are using "undecibility" in a non-standard way
> and dozens of messages have not brought forth a clear definition.
>
> I can say this.  If you are right, and all the inputs that meet your
> definition of "undecidable" are ones which a decider should reject, then
> "undecidable" is a very odd word to have chosen for whatever criterion
> it represents.
>
I explained if fully and provided an example that was ignored and 
trimmed from my response.
0
NoSpam271 (937)
4/6/2012 2:10:57 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/5/2012 8:42 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 4/4/2012 6:13 PM, Ben Bacarisse wrote:
>>>> Peter Olcott<NoSpam@OCR4Screen.com>   writes:
>>>>
>>>>> On 4/1/2012 2:57 PM, Patricia Shanahan wrote:
>>>> <snip>
>>>>>> Of course, a completely empty string, without a TM, is represented, as
>>>>>> usual, by a tape containing only blanks. A halting decider using this
>>>>>> encoding should halt in a state indicating the string is not in the
>>>>>> language.
>>>> <snip>
>>>>> So in other words it misrepresents that the TM specified by "" as not
>>>>> halting, when in truth it neither halts nor fails to halt.
>>>> No.  Using the specific encoding that's been proposed, an entirely empty
>>>> tape does not "represent a<t, i>   pair with the property that halts(t,i)
>>>> is true".  Consequently, a halting decider TM must say so explicitly by
>>>> halting in a reject state.
>>>>
>>>> Analogy: a decider for prime numbers must halt in a reject state when
>>>> given 42, "" or "banana".  The question being "is my input a sequence of
>>>> decimal digits, d, such that prime(value_of(d)) is true?".
>>>>
>>> Then it must also halt in the reject state for undecibility.
>> Only you can know.  You are using "undecibility" in a non-standard way
>> and dozens of messages have not brought forth a clear definition.
>>
>> I can say this.  If you are right, and all the inputs that meet your
>> definition of "undecidable" are ones which a decider should reject, then
>> "undecidable" is a very odd word to have chosen for whatever criterion
>> it represents.
>>
> I explained if fully and provided an example that was ignored and
> trimmed from my response.

Since you've fully explained it, and don't want to keep repeating
yourself, can we conclude that you'll call it day?  You gave it your
best shot, but no one here seems likely to get it.  Time to write that
paper!

-- 
Ben.
0
ben.usenet (6790)
4/6/2012 2:38:46 AM
On 4/4/2012 7:37 PM, Joshua Cranmer wrote:
> On 4/4/2012 6:48 PM, Peter Olcott wrote:
>> On 4/4/2012 5:28 PM, Joshua Cranmer wrote:
>>> On 4/4/2012 4:40 PM, Peter Olcott wrote:
>>>> So in other words it misrepresents that the TM specified by "" as not
>>>> halting, when in truth it neither halts nor fails to halt.
>>>
>>> Using the encoding we have defined, the phrase "the TM specified by
>>> ''" is ill-defined, for "" defines no TM.
>>>
>>
>> Then the same applies to the Halting Problem, when Pathological
>> Self-Reference occurs.
>
> The best I can get of this statement is that you believe that 
> "Pathological self-reference" is not a TM.
>
> We seem to be getting off on several sidetracks here, but to bring 
> this back to a point, I ask the following challenge of you:
>
> Define, precisely, a concrete decision tree that can be performed by a 
> Turing machine to decide whether or not Pathological self-reference 
> occurs, without referring to the halting problem in the definition 
> (this avoids any hint of circularity in your argument).
>

M( String Input )
{
if ( Halts( Input, Input ) )
   Loop Forever;
else
   Exit;
}

The above pseudo code that mathematically maps to a Turing Machine 
provides one specific concrete example of Pathological Self-Reference.
Pathological Self-Reference is the only reason why Halts(M, M) is 
undecidable.

I think that the data structure required to specify Pathological 
Self-Reference would be a graph with cycles, and thus not a tree.
0
NoSpam271 (937)
4/6/2012 2:44:55 AM
On 4/5/2012 9:44 PM, Peter Olcott wrote:
> I think that the data structure required to specify Pathological
> Self-Reference would be a graph with cycles, and thus not a tree.

Then make it a flowchart if you think the decision needs to be an 
iterative or recursive process. I'm still waiting for a formalized 
definition.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/6/2012 3:10:18 AM
On 4/5/2012 10:10 PM, Joshua Cranmer wrote:
> On 4/5/2012 9:44 PM, Peter Olcott wrote:
>> I think that the data structure required to specify Pathological
>> Self-Reference would be a graph with cycles, and thus not a tree.
>
> Then make it a flowchart if you think the decision needs to be an 
> iterative or recursive process. I'm still waiting for a formalized 
> definition.
>
I don't have the time right now, and this misses the point. From the 
specific concrete example that I provided it is apparent that detecting 
instances of this is not impossible.

 From other examples that I have provided it is also shown that 
detecting instances of this can not be made to be impossible by things 
such as reduction (to or from) the Halting Problem.

If detecting instances such as this are not impossible and can not be 
made to be impossible, then the effect of the Halting Problem is bypassed:

A Halt Decider can now provide three results (from the combination of 
two different conventional total Turing Machine deciders):
1) Halts
2) Does not halt
3) Invalid input (semantically, syntactically, or otherwise)
0
NoSpam271 (937)
4/6/2012 12:30:53 PM
On 4/6/2012 9:40 AM, George Greene wrote:
> On Apr 6, 8:30 am, Peter Olcott<NoS...@OCR4Screen.com>  wrote:
>>   From other examples that I have provided it is also shown that
>> detecting instances of this can not be made to be impossible by things
>> such as reduction (to or from) the Halting Problem.
> Detecting instances of this does not NEED  to be "made to be
> impossible" --
> IT IS ALREADY IMPOSSIBLE TO START WITH.  No TM ever has any way
> of telling who its caller is, inherently.
Sorry George you are totally asleep on this one. The Halt analyzer can 
always see all of the details of its caller (within the conventional 
Halting Problem) because it is always provided with the source code of 
its caller.

M( String Input )
{
if ( Halts( Input, Input ) )
   Loop Forever;
else
   Exit;
}

// Function prototype
Boolean Halts(String tm, String input);

// invocation
Halts(M, M);  // example of Pathological Self-Reference

> It will only know of the
> designers of
> the calling contexts decide in advance to pass information about the
> calling
> context IN THE INPUT STRING.  Even in that case, THE CODE, the TM
> ITSELF,
> STILL DOESN'T KNOW.  More to the point, if the designers decided to
> violate
> their own conventions AND LIE to the called TM about who was calling
> it,
> IT COULDN'T CHECK.
It would not need to check. It does not care about who calls it unless 
this is specified as its input. As long as the Halt analyzer provides 
the correct return value for its input it is correct. It does not matter 
what the caller does with this return value after the fact, unless this 
is also specified in the halt analyzer's input.
0
NoSpam271 (937)
4/8/2012 12:44:43 PM
On 4/6/2012 9:43 AM, George Greene wrote:
> On Apr 6, 8:30 am, Peter Olcott<NoS...@OCR4Screen.com>  wrote:
>> A Halt Decider can now provide three results (from the combination of
>> two different conventional total Turing Machine deciders):
>> 1) Halts
>> 2) Does not halt
>> 3) Invalid input (semantically, syntactically, or otherwise)
> ANY TM that chooses to interpret the beginning of its input string as
> a description of a[nother] TM can do THIS.
> We can, if you like, call all such TMs "analyzers".
> But the point is, NONE of these TMs IS A HALT-analyzer.
> Anything that actually deserved to be called a HALT-analyzer
> WOULD GET ALL THE HALTING-QUESTIONS RIGHT.

What is the correct return value to the invocation:
Halts("", "")

If one is careful to mathematically map *all* of the semantic meanings 
that are logically entailed by this, then the correct answer is neither 
true nor false.

> WHENEVER the first input did IN FACT ENCODE AN ACTUAL
> Turing Machine, the Halt Decider WOULD NEVER say that the
> input was "semantically invalid", because THAT IS NOT EVEN POSSIBLE.
Right just like it is not possible to correctly answer the question:
What time it is (yes or no)?

> EVERY TM either does or doesn't halt, ON EVERY input.
Yes, but, sometimes neither return value of (true or false) is correct.

When I ask the question:
What time is it (yes or no), there is a correct answer, but, the set of 
{yes, no} does not contain this correct answer.

In the case of Pathological Self-Reference there is even a correct 
answer from the set of {true, false}, yet there is not a correct return 
value from the function Halts() from the set of {true, false}.

Because there is a correct answer, yet there is not a correct return 
value, this conclusively proves that the question is not the same as the 
invocation, even if they can both be stated using identical words.

> BY DEFINITION.  THERE IS ALWAYS a RIGHT answer.   THERE IS NEVER
> a "semantically invalid" input.
>
>

OK then correctly answer the question:
What time is it, and restrict your answer to the set of {yes, no}.

What time is it (yes, or no)?

Is the above question:
1) Correct and thus has a correct answer. (please provide)
2) Incorrect syntactically.
3) Incorrect semantically.
4) Incorrect for other reasons.



0
NoSpam271 (937)
4/8/2012 12:50:30 PM
On 4/6/2012 9:33 AM, George Greene wrote:
> On Apr 5, 10:44 pm, Peter Olcott<NoS...@OCR4Screen.com>  wrote:
>> M( String Input )
>> {
>> if ( Halts( Input, Input ) )
>>     Loop Forever;
>> else
>>     Exit;
>>
>> }
>>
>> The above pseudo code that mathematically maps to a Turing Machine
> THE ABOVE PSEUDO-CODE *DOES*NOT* mathematically map
> TO ANY Turing Machine BECAUSE it calls Halts( Input, Input ) and
> Halts( , )  *IS NOT* A Turing Machine!
>
> In order to MAKE this map to a turing machine, YOU WOULD HAVE
> TO HAVE A SECOND (or first) PARAMETER FOR M
> that encoded A TURING MACHINE THAT *ACTUALLY EXISTS*!!!!
It looks like you are saying that Turing Machines that get the wrong 
answer can not possibly exist.


0
NoSpam271 (937)
4/8/2012 12:56:05 PM
Peter Olcott wrote:
> It looks like you are saying that Turing Machines that get the wrong
> answer can not possibly exist.

No that's not what George Greene was saying, and that sort of careless
misreading is one of the things that gets you into these messes,
Peter.

You may have seen TM "Halts" in your textbooks, but note the context:
proof by contradiction. It works thus: We assume an X exists, and from
that assumption derive a contradiction. "An X exists" implies false,
so "an X exists" must be false, so no X exists.

One might reply: Ah - but once I have an X I can construct all these
other cools things and this one doesn't even seem to have the
particular contradiction problem you described. Alas that's not a
proof of anything beyond failure to comprehend.


-Bryan

0
4/8/2012 7:04:22 PM
On Apr 8, 8:50=A0am, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> In the case of Pathological Self-Reference

Once again, in the TM world, THERE IS NO SUCH THING
as "pathological self-reference" because the called TM does not
know who its caller is.

>  there is even a correct  answer from the set of {true, false},

NO, THERE ISN'T.  BOTH of these answers, true and false,
LEAD TO LOGICAL CONTRADICTION.  NEITHER of them (in that context)
is correct.

> yet there is not a correct return value from the function Halts() from th=
e set of {true, false}.
That is because Halts(,) DOES NOT EXIST, as a TM, which means that if
you
are trying to ask this question (about the halting behavior of the
program in general,
without necessarily calling a Halts(,) TM), you have the problem that
your
candidate/input program DOES NOT EXIST, because it was written with a
call
to a program THAT DOES NOT EXIST (namely Halts(,) ).

> Because there is a correct answer,

NO, there is NOT a correct answer.
M is NOT a correct PROGRAM because it calls something that doesn't
exist.
0
greeneg9613 (188)
4/9/2012 1:12:56 AM
On 4/8/2012 2:04 PM, Bryan wrote:
> Peter Olcott wrote:
>> It looks like you are saying that Turing Machines that get the wrong
>> answer can not possibly exist.
> No that's not what George Greene was saying, and that sort of careless
> misreading is one of the things that gets you into these messes,
> Peter.
>
> You may have seen TM "Halts" in your textbooks, but note the context:
> proof by contradiction. It works thus: We assume an X exists, and from
> that assumption derive a contradiction. "An X exists" implies false,
> so "an X exists" must be false, so no X exists.
>
> One might reply: Ah - but once I have an X I can construct all these
> other cools things and this one doesn't even seem to have the
> particular contradiction problem you described. Alas that's not a
> proof of anything beyond failure to comprehend.
>
>
> -Bryan
>
If you remove the relevant context (as you just did) I will not be able 
to prevent myself from concluding that you are simply being dishonest.
0
NoSpam271 (937)
4/9/2012 1:48:01 AM
On 4/8/2012 8:12 PM, George Greene wrote:
> On Apr 8, 8:50 am, Peter Olcott<NoS...@OCR4Screen.com>  wrote:
>> >  In the case of Pathological Self-Reference
> Once again, in the TM world, THERE IS NO SUCH THING
> as "pathological self-reference" because the called TM does not
> know who its caller is.
>
You are seeming to be pretty dense George.

M( String Input )
{
if ( Halts( Input, Input ) )
   Loop Forever;
else
   Exit;
}

If the potential halt decider could not see who was calling it from its own input, then the conventional Halting Problem could not be derived.

Halts(M ,M) can see exactly how M is calling it because Halts has M specified as its input.


0
NoSpam271 (937)
4/9/2012 2:27:00 AM
On Apr 8, 6:48=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> On 4/8/2012 2:04 PM, Bryan wrote:
>
>
>
> > Peter Olcott wrote:
> >> It looks like you are saying that Turing Machines that get the wrong
> >> answer can not possibly exist.
> > No that's not what George Greene was saying, and that sort of careless
> > misreading is one of the things that gets you into these messes,
> > Peter.
>
> > You may have seen TM "Halts" in your textbooks, but note the context:
> > proof by contradiction. It works thus: We assume an X exists, and from
> > that assumption derive a contradiction. "An X exists" implies false,
> > so "an X exists" must be false, so no X exists.
>
> > One might reply: Ah - but once I have an X I can construct all these
> > other cools things and this one doesn't even seem to have the
> > particular contradiction problem you described. Alas that's not a
> > proof of anything beyond failure to comprehend.
>
> > -Bryan
>
> If you remove the relevant context (as you just did) I will not be able
> to prevent myself from concluding that you are simply being dishonest.



You know, by this point, we were pretty good friends.  All we did was
hang out with each other and work.  Then he went home to Grandma and
Lewiston.  I had all my computer business for free and basically had
an alcohol budget so I went all over town basically all year for a
couple years and there were probably less problems but maybe it was
more boring.

Yeah, me and the Mayor and Rusty or somebody are more fun at the bar
in the the mayor's town, compared to say the Canadian Scottish Bagpipe
Band going through every bar in town loud they rolled into Oasis and
must have hit the Brass Rail, it was awesome.  We got them down the
street to the Shot Glass and they were going off for hours.

Bar, yeah I drink with Red.

Well I'd probably drink with you for that matter but it might not be
what you're having.

Yeah, Pete, really you should relax.  Seriously you know Greene is
nice and you read too much of an insult that didn't exist.  Trust me
they are happy in arguments and they don't like wrestling with pigs so
it gets them real angry if you misinterpret their what they see as
correction (because here, often they are right, or I'm saying you can
trust George) .  No I didn't see any kind of negativity or implied
derision or anything, Pete, from what George wrote you.  So write him.

Stemper - like I was telling Mossop - I look at what you wrote about
hypergeometry, last month, and look back at what I myself wrote to
sci.math in 1997, and, by jove they are the same.

Then he congratulated me and we toasted each other that I would be
able to tell you that.

So, go back to that, well no, I didn't, I spent time on foundations,
no I have the books for Clifford Algebra and geometry in the modern
and such.

Well modern textbooks Lounesto, Bayliss, Cartan.

So, Happy Easters, congratulation, cheers, and good will toward men
and such, no I don't mistype and errors you see are introduced, Happy
Easter, Jesus.


Good day,

Ross Finlayson
0
4/9/2012 6:38:17 AM
On 04/08/2012 08:50 AM, Peter Olcott wrote:
> In the case of Pathological Self-Reference there is even a correct
> answer from the set of {true, false}, yet there is not a correct return
> value from the function Halts() from the set of {true, false}.
>
> Because there is a correct answer, yet there is not a correct return
> value, this conclusively proves

that the return value is not the same as the correct answer.

> that the question is not the same as the
> invocation, even if they can both be stated using identical words.

Isn't this a pretty good argument *against* your insistence on only 
using words?

Of course a question is not the same as an invocation of a TM. One is a 
question, and the other isn't. A question can (an in this case does) 
have a correct answer. An invocation has a result (return value or never 
halts). For a given invocation there is only *one* possible result.

Talking about an invocation as if it were a question with a set of 
possible answers, one of which should be correct, is wrong. It leads to 
nonsense.

So does talking about a "bug free" halting decider, when you can't prove 
such a thing exists (or, as in this case, there is a proof that none 
does exist).

Ralph Hartley
0
hartley (156)
4/9/2012 12:38:35 PM
Peter Olcott wrote:
> If you remove the relevant context (as you just did) I will not be able
> to prevent myself from concluding that you are simply being dishonest.

Well check out how much of George Greene's post you snipped in the one
where you called him "pretty dense".

The relevant context remains in the news feed. Here: I'll re-include:
> > Peter Olcott  wrote:
> >> M( String Input )
> >> {
> >> if ( Halts( Input, Input ) )
> >>     Loop Forever;
> >> else
> >>     Exit;
>
> >> }
>
> >> The above pseudo code that mathematically maps to a Turing Machine [...]

George Greene wrote:
> > THE ABOVE PSEUDO-CODE *DOES*NOT* mathematically map
> > TO ANY Turing Machine BECAUSE it calls Halts( Input, Input ) and
> > Halts( , )  *IS NOT* A Turing Machine!
>
> > In order to MAKE this map to a turing machine, YOU WOULD HAVE
> > TO HAVE A SECOND (or first) PARAMETER FOR M
> > that encoded A TURING MACHINE THAT *ACTUALLY EXISTS*!!!!

Peter Olcott wrote:
> It looks like you are saying that Turing Machines that get the wrong
> answer can not possibly exist.

No, Peter, that's not what George is saying. He's saying what he
wrote: Turing machine "Halts" does not exist. George is correct. He is
on-point, as I tried to explain, repeated below:

You may have seen TM "Halts" in your textbooks, but note the context:
proof by contradiction. It works thus: We assume an X exists, and from
that assumption derive a contradiction. "An X exists" implies false,
so "an X exists" must be false, so no X exists.

One might reply: Ah - but once I have an X I can construct all these
other cools things and this one doesn't even seem to have the
particular contradiction problem you described. Alas that's not a
proof of anything beyond failure to comprehend.

--
--Bryan
0
4/9/2012 1:19:33 PM
Bryan <bryanjugglercryptographer@yahoo.com> writes:

> Peter Olcott wrote:
>> If you remove the relevant context (as you just did) I will not be able
>> to prevent myself from concluding that you are simply being dishonest.
>
> Well check out how much of George Greene's post you snipped in the one
> where you called him "pretty dense".
>
> The relevant context remains in the news feed. Here: I'll re-include:
>> > Peter Olcott  wrote:
>> >> M( String Input )
>> >> {
>> >> if ( Halts( Input, Input ) )
>> >>     Loop Forever;
>> >> else
>> >>     Exit;
>>
>> >> }
>>
>> >> The above pseudo code that mathematically maps to a Turing Machine [...]
>
> George Greene wrote:
>> > THE ABOVE PSEUDO-CODE *DOES*NOT* mathematically map
>> > TO ANY Turing Machine BECAUSE it calls Halts( Input, Input ) and
>> > Halts( , )  *IS NOT* A Turing Machine!
>>
>> > In order to MAKE this map to a turing machine, YOU WOULD HAVE
>> > TO HAVE A SECOND (or first) PARAMETER FOR M
>> > that encoded A TURING MACHINE THAT *ACTUALLY EXISTS*!!!!
>
> Peter Olcott wrote:
>> It looks like you are saying that Turing Machines that get the wrong
>> answer can not possibly exist.
>
> No, Peter, that's not what George is saying. He's saying what he
> wrote: Turing machine "Halts" does not exist. George is correct. He is
> on-point, as I tried to explain, repeated below:

He is correct in what he says, but he is not on Peter's point.  In
Peter's usage, Halts is not a halting decider.  It is an "almost halting
decider" -- a machine that gets no cases wrong but does not answer in
all cases (I won't get into the mess of what cases those are).

His plan is to construct, from any "suitable" Halts, a "better" halts
that defeats the pattern used in standard proof of undecidability.  He
thinks, wrongly, that this is the only case in which a machine is
obliged to differ from a correct halting decider.

The plan is, of course, impossible.  Also, the name "Halts" is terrible,
suggesting, as it does, a non-existent machine.  Not only that, the
existence of any "suitable" machines is in doubt (I am not sure of the
details anymore).  Please don't get the idea that I think there is any
merit in these ideas, but I think they are best rebutted by
understanding them.

<snip>
-- 
Ben.
0
ben.usenet (6790)
4/9/2012 7:40:06 PM
On 4/9/2012 7:38 AM, Ralph Hartley wrote:
> On 04/08/2012 08:50 AM, Peter Olcott wrote:
>> In the case of Pathological Self-Reference there is even a correct
>> answer from the set of {true, false}, yet there is not a correct return
>> value from the function Halts() from the set of {true, false}.
>>
>> Because there is a correct answer, yet there is not a correct return
>> value, this conclusively proves
>
> that the return value is not the same as the correct answer.
>
>> that the question is not the same as the
>> invocation, even if they can both be stated using identical words.
>
> Isn't this a pretty good argument *against* your insistence on only 
> using words?
>

Generically an invocation and a question only differ by the interface.
Generically there exists a mathematical mapping between a question and 
its invocation representation.

In this specific case we have essentially two questions with identical 
words, yet different meanings. The difference is that one of these 
questions has Pathological Self-Reference, and the other one does not.

> Of course a question is not the same as an invocation of a TM. One is 
> a question, and the other isn't. A question can (an in this case does) 
> have a correct answer. An invocation has a result (return value or 
> never halts). For a given invocation there is only *one* possible result.
>
> Talking about an invocation as if it were a question with a set of 
> possible answers, one of which should be correct, is wrong. It leads 
> to nonsense.
>
> So does talking about a "bug free" halting decider, when you can't 
> prove such a thing exists (or, as in this case, there is a proof that 
> none does exist).
>
> Ralph Hartley

0
NoSpam271 (937)
4/9/2012 11:32:28 PM
On 4/9/2012 8:19 AM, Bryan wrote:
> George Greene wrote:
>>> >  >  THE ABOVE PSEUDO-CODE*DOES*NOT*  mathematically map
>>> >  >  TO ANY Turing Machine BECAUSE it calls Halts( Input, Input ) and
>>> >  >  Halts( , )*IS NOT*  A Turing Machine!
>> >
>>> >  >  In order to MAKE this map to a turing machine, YOU WOULD HAVE
>>> >  >  TO HAVE A SECOND (or first) PARAMETER FOR M
>>> >  >  that encoded A TURING MACHINE THAT*ACTUALLY EXISTS*!!!!
> Peter Olcott wrote:
>> >  It looks like you are saying that Turing Machines that get the wrong
>> >  answer can not possibly exist.
> No, Peter, that's not what George is saying. He's saying what he
> wrote: Turing machine "Halts" does not exist. George is correct. He is
> on-point, as I tried to explain, repeated below:

I was trying to explain Pathological Self-Reference. Halts() is merely a 
name, it does not logically entail 
ThisIsATrueHaltDeciderThatAlwaysDecidesCorrectly().
0
NoSpam271 (937)
4/10/2012 1:37:04 AM
On 4/9/2012 2:40 PM, Ben Bacarisse wrote:
> Bryan<bryanjugglercryptographer@yahoo.com>  writes:
>
>> Peter Olcott wrote:
>>> If you remove the relevant context (as you just did) I will not be able
>>> to prevent myself from concluding that you are simply being dishonest.
>> Well check out how much of George Greene's post you snipped in the one
>> where you called him "pretty dense".
>>
>> The relevant context remains in the news feed. Here: I'll re-include:
>>>> Peter Olcott  wrote:
>>>>> M( String Input )
>>>>> {
>>>>> if ( Halts( Input, Input ) )
>>>>>      Loop Forever;
>>>>> else
>>>>>      Exit;
>>>>> }
>>>>> The above pseudo code that mathematically maps to a Turing Machine [...]
>> George Greene wrote:
>>>> THE ABOVE PSEUDO-CODE *DOES*NOT* mathematically map
>>>> TO ANY Turing Machine BECAUSE it calls Halts( Input, Input ) and
>>>> Halts( , )  *IS NOT* A Turing Machine!
>>>> In order to MAKE this map to a turing machine, YOU WOULD HAVE
>>>> TO HAVE A SECOND (or first) PARAMETER FOR M
>>>> that encoded A TURING MACHINE THAT *ACTUALLY EXISTS*!!!!
>> Peter Olcott wrote:
>>> It looks like you are saying that Turing Machines that get the wrong
>>> answer can not possibly exist.
>> No, Peter, that's not what George is saying. He's saying what he
>> wrote: Turing machine "Halts" does not exist. George is correct. He is
>> on-point, as I tried to explain, repeated below:
> He is correct in what he says, but he is not on Peter's point.  In
> Peter's usage, Halts is not a halting decider.  It is an "almost halting
> decider" -- a machine that gets no cases wrong but does not answer in
> all cases (I won't get into the mess of what cases those are).
>
> His plan is to construct, from any "suitable" Halts, a "better" halts
> that defeats the pattern used in standard proof of undecidability.  He
> thinks, wrongly, that this is the only case in which a machine is
> obliged to differ from a correct halting decider.

In every case where halting is not decidable, there is an error of 
reasoning within the problem. Halting always decidable for every non 
erroneous case.

> The plan is, of course, impossible.  Also, the name "Halts" is terrible,
> suggesting, as it does, a non-existent machine.  Not only that, the
> existence of any "suitable" machines is in doubt (I am not sure of the
> details anymore).  Please don't get the idea that I think there is any
> merit in these ideas, but I think they are best rebutted by
> understanding them.
>
> <snip>

You won't ever be able to correctly refute any self-evident truth, you 
can feel free to fail to comprehend it though.
0
NoSpam271 (937)
4/10/2012 1:42:26 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/9/2012 2:40 PM, Ben Bacarisse wrote:
<snip>
>> His plan is to construct, from any "suitable" Halts, a "better" halts
>> that defeats the pattern used in standard proof of undecidability.  He
>> thinks, wrongly, that this is the only case in which a machine is
>> obliged to differ from a correct halting decider.
>
> In every case where halting is not decidable, there is an error of
> reasoning within the problem. Halting always decidable for every non
> erroneous case.

That's not where the error of reasoning lies.

Halting is undecidable, period.  The term decidable should not be applied
to individual cases.

>> The plan is, of course, impossible.  Also, the name "Halts" is terrible,
>> suggesting, as it does, a non-existent machine.  Not only that, the
>> existence of any "suitable" machines is in doubt (I am not sure of the
>> details anymore).  Please don't get the idea that I think there is any
>> merit in these ideas, but I think they are best rebutted by
>> understanding them.
>>
>> <snip>
>
> You won't ever be able to correctly refute any self-evident truth, you
> can feel free to fail to comprehend it though.

Self-evident truths are often the easiest to refute.  Proved theorems
are much harder.  When you write your paper (you are writing one, yes?)
you will need to do a lot more than just make claims.

"Self-evident" is only applied to claims that have no proof -- things
so obvious that, surely, no one could dispute them -- but which have,
for some reason, eluded all attempt to actually prove them.

-- 
Ben.
0
ben.usenet (6790)
4/10/2012 3:21:16 AM
Peter Olcott wrote:
> In every case where halting is not decidable, there is an error of
> reasoning within the problem. Halting always decidable for every non
> erroneous case.

A bold proclamation. Alas, math and logic disagree.

We *can* construct a TM that:

  1) Never answers the halting problem incorrectly, and
  2) Always answers correctly when the answer is 'Halts'.

If you check your textbooks, you'll likely find 'Halts' defined as a
language, something like the set of strings encoding pairs (m, s)
where Turing machine m halts on input s. A TM with the two properties
above *accepts* the language 'Halts'. There does not exist a TM that
*decides* Halts.

What's more, given a TM, call it 'PHaults' (pseudo-halts), that never
answers incorrectly, we can construct a TM that correctly answers all
the same cases as PHaults, plus always answers correctly when the
answer is 'Halts'. Proof by construction: We interleave emulation of
both PHalts on input (m, s) and m on input s. When either of them
halts we have the answer: the output of PHaults if it halts first, or
'Halts' if m halts first.

Now assume, Peter, that you are correct. Then there exists a TM
'PHaults', that only fails to decide in erroneous cases, and we can
construct a TM, call it "Patho", that takes as input a TM and a
halting problem instance, and decides whether the instance is an
undecidable case for the given machine.

From PHaults, I can construct PHaultsP, (pseudo-halts-plus) that
decides every case PHaults decides, plus always answers correctly when
the answer is 'Halts'. I showed how above.

Now I can build a TM 'Halts' that takes input (m, s), and interleaves
emulation of Patho on (PHaultsP,  (m, s)) and PHaultsP on (m, s). If
PHaultsP halts, I output its answer. If Patho find the s to be
undecidable by PHaultsP, I output "Does not halt", which has to be
correct because PHaultsP decides every instance where the answer is
'Halts'.

My Turing machine, 'Halts', decides the halting problem. I showed how
to construct it, given certain assumptions. Since no TM decides the
halting problem, at least one of the assumptions must be wrong.
They're all solid -- by UseNet standards and could clearly be made
rigorous -- except for what I introduced with "Now assume...".

Peter, the hour is late. I can understand how a novice, a student in a
theory course, might think, "Hey, even if they've proven I can't
decide every case, maybe I can distinguish which cases are
undecidable". The brighter students in this area figure out that it's
the same problem. Most of the rest move on to apply themselves where
their talents are better aligned.

-Bryan
0
4/10/2012 7:44:32 AM
On Apr 10, 3:44=A0am, Bryan <bryanjugglercryptograp...@yahoo.com> wrote:
> Peter Olcott wrote:
> > In every case where halting is not decidable, there is an error of
> > reasoning within the problem. Halting always decidable for every non
> > erroneous case.
>
> A bold proclamation. Alas, math and logic disagree.

Bryan, thank you, in all sincerity, you are much more helpful than
Ben,
but please, do NOT let this pass: he CAN'T SAY that an individual case
(erroneous or not) is "decidable" or "undecidable".  Decidability is a
property
OF INFINITARY questions.  Just because something is undecidable FOR
HIS INDIVIDUAL PolAAAAhatm(,) does NOT make THAT INDIVIDUAL CASE
undecidable -- all you have to do to decide that individual case IS
ENHANCE his TM *to* decide it!

If we can't get him to stop calling it Halts(,) then we may have to
give up,
though.  He seems to think that since the name doesn't matter, he can
keep using a bad name without risking greater error.  Theory and
practice unfortunately diverge on that point.

After he changes the name, he also needs to say something about when
his analyzer does or doesn't loop.  Presumably he thinks that an
individual
case, encoded as a TM input string, is "undecidable for" an individual
TM when the TM loops on the input string, or returns as output
something outside the  domain over which the TM's mission was to
"decide".

OUR point must remain, we CAN'T ACCEPT any of that because TMs
DON'T COME with built-in "missions".  It is simply not possible for
their
inputs or their outputs TO EVER be "erroneous".  EVERY tm ALWAYS
does, CORRECTLY AND EXACTLY, what it was programmed to do.
If a human wrote the TM then the human may have failed to write a TM
whose behavior meets all the criteria that human wanted it to meet,
but
when that happens, that is THE HUMAN'S fault AND NOT the TM's.
Neither the TM nor its input (nor its output) IS EVER "erroneous".
Allowing him to CALL it "Halts" will wrongly REinforce his FALSE claim
that some sort of behavior (or the input that produced it) was
"erroneous".
0
greeneg9613 (188)
4/10/2012 4:33:01 PM
On 4/9/2012 10:21 PM, Ben Bacarisse wrote:
>> In every case where halting is not decidable, there is an error of
>> >  reasoning within the problem. Halting always decidable for every non
>> >  erroneous case.
> That's not where the error of reasoning lies.
>
> Halting is undecidable, period.  The term decidable should not be applied
> to individual cases.
>
Since the only times that it does not get the right answer, the question 
itself is malformed, it should still be considered a decider. It is 
incorrect to require it to correctly answer incorrect questions.
0
NoSpam271 (937)
4/10/2012 11:59:44 PM
On 4/9/2012 10:21 PM, Ben Bacarisse wrote:
>> >  You won't ever be able to correctly refute any self-evident truth, you
>> >  can feel free to fail to comprehend it though.
> Self-evident truths are often the easiest to refute.
OK fine prove the 3 > 5!
0
NoSpam271 (937)
4/11/2012 12:00:21 AM
On 4/9/2012 10:21 PM, Ben Bacarisse wrote:
>> You won't ever be able to correctly refute any self-evident truth, you
>> >  can feel free to fail to comprehend it though.
> Self-evident truths are often the easiest to refute.  Proved theorems
> are much harder.  When you write your paper (you are writing one, yes?)
> you will need to do a lot more than just make claims.
>
> "Self-evident" is only applied to claims that have no proof -- things
> so obvious that, surely, no one could dispute them -- but which have,
> for some reason, eluded all attempt to actually prove them.
Self evident means logical tautology, a statement that is defined to be 
true. Example: 3 < 5.
0
NoSpam271 (937)
4/11/2012 12:02:02 AM
On 4/10/2012 2:44 AM, Bryan wrote:
> Peter Olcott wrote:
>> In every case where halting is not decidable, there is an error of
>> reasoning within the problem. Halting always decidable for every non
>> erroneous case.
> A bold proclamation. Alas, math and logic disagree.
>
> We *can* construct a TM that:
>
>    1) Never answers the halting problem incorrectly, and
>    2) Always answers correctly when the answer is 'Halts'.
>
> If you check your textbooks, you'll likely find 'Halts' defined as a
> language, something like the set of strings encoding pairs (m, s)
> where Turing machine m halts on input s. A TM with the two properties
> above *accepts* the language 'Halts'. There does not exist a TM that
> *decides* Halts.
>
> What's more, given a TM, call it 'PHaults' (pseudo-halts), that never
> answers incorrectly, we can construct a TM that correctly answers all
> the same cases as PHaults, plus always answers correctly when the
> answer is 'Halts'. Proof by construction: We interleave emulation of
> both PHalts on input (m, s) and m on input s. When either of them
> halts we have the answer: the output of PHaults if it halts first, or
> 'Halts' if m halts first.
>
> Now assume, Peter, that you are correct. Then there exists a TM
> 'PHaults', that only fails to decide in erroneous cases, and we can
> construct a TM, call it "Patho", that takes as input a TM and a
> halting problem instance, and decides whether the instance is an
> undecidable case for the given machine.
>
>  From PHaults, I can construct PHaultsP, (pseudo-halts-plus) that
> decides every case PHaults decides, plus always answers correctly when
> the answer is 'Halts'. I showed how above.
>
> Now I can build a TM 'Halts' that takes input (m, s), and interleaves
> emulation of Patho on (PHaultsP,  (m, s)) and PHaultsP on (m, s). If
> PHaultsP halts, I output its answer. If Patho find the s to be
> undecidable by PHaultsP, I output "Does not halt", which has to be
> correct because PHaultsP decides every instance where the answer is
> 'Halts'.
>
> My Turing machine, 'Halts', decides the halting problem. I showed how
> to construct it, given certain assumptions. Since no TM decides the
> halting problem, at least one of the assumptions must be wrong.
> They're all solid -- by UseNet standards and could clearly be made
> rigorous -- except for what I introduced with "Now assume...".
>
> Peter, the hour is late. I can understand how a novice, a student in a
> theory course, might think, "Hey, even if they've proven I can't
> decide every case, maybe I can distinguish which cases are
> undecidable". The brighter students in this area figure out that it's
> the same problem. Most of the rest move on to apply themselves where
> their talents are better aligned.
>
> -Bryan
The problem seems to be that no one has yet completely understood *all* 
the very subtle nuances of meaning that are logically entailed by *all* 
of the various and sundry self-reference paradoxes.

If this is examined closely enough where not the slightest trace of 
semantic meaning is allowed to slip through the cracks of complete 
comprehension, one realizes that there is unsound reasoning at the basis 
of *all* of these paradoxes.

In order to do this one must treat natural language as a
mathematical formalism. This is an aspect of mathematics
(more precisely the knowledge representation (KR) sub-field of
the artificial intelligence (AI) branch of computer science)
that is mostly not invented yet.

My point of view comes from KR rather than the Theory of
Computation.

In my March 14, 2012 6:52 PM CDT posting:
Pathological Self-Reference and the Halting Problem
I quoted Daryl McCullough's perfect analogy where
he translated the Halting Problem into a question
posted to a human "volunteer".

This perfect analogy showed another example of the
Pathological Self-Reference error that is identical
to the error of the Halting Problem. Alas no one
(not even Daryl) understood this perfect analogy (so far).




0
NoSpam271 (937)
4/11/2012 12:22:54 AM
On 4/10/2012 11:33 AM, George Greene wrote:
> OUR point must remain, we CAN'T ACCEPT any of that because TMs
> DON'T COME with built-in "missions".  It is simply not possible for
> their
> inputs or their outputs TO EVER be "erroneous".  EVERY tm ALWAYS
> does, CORRECTLY AND EXACTLY, what it was programmed to do.
> If a human wrote the TM then the human may have failed to write a TM
> whose behavior meets all the criteria that human wanted it to meet,
> but
> when that happens, that is THE HUMAN'S fault AND NOT the TM's.
> Neither the TM nor its input (nor its output) IS EVER "erroneous".
> Allowing him to CALL it "Halts" will wrongly REinforce his FALSE claim
> that some sort of behavior (or the input that produced it) was
> "erroneous".

The Halting Problem is undecidable if one is allowed to count 
semantically incorrect input against the TM as a failure of the TM.

 From this failure (to correctly process incorrect input) computing 
theory poses a fundamental limitation of the capability of computation.

This limitation does not actually exist, it is a mere artifact of the 
incorrect way that the problem was framed.

0
NoSpam271 (937)
4/11/2012 12:33:57 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/9/2012 10:21 PM, Ben Bacarisse wrote:
>>> In every case where halting is not decidable, there is an error of
>>> >  reasoning within the problem. Halting always decidable for every non
>>> >  erroneous case.
>> That's not where the error of reasoning lies.
>>
>> Halting is undecidable, period.  The term decidable should not be applied
>> to individual cases.
>>
> Since the only times that it does not get the right answer, the
> question itself is malformed, it should still be considered a
> decider. It is incorrect to require it to correctly answer incorrect
> questions.

So we are back where it all started.  You still don't accept the simple
fact that all halting questions have correct true/false answers, but you
can't say what option, other than hating or not hating, a TM has.

The fact that no one machine can answer all of some class of questions
does not mean that any of that any of those questions are, necessarily,
malformed.

There are no "undecidable" cases, yet every machine has at least one
input what it will incorrectly classify.  All of the these inputs have a
correct answer -- that's how we can know that a particular machine gets
the answer wrong.

-- 
Ben.
0
ben.usenet (6790)
4/11/2012 12:59:35 AM
On Apr 10, 8:33=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> =A0From this failure (to correctly process incorrect input) computing
> theory poses a fundamental limitation of the capability of computation.
>
> This limitation does not actually exist, it is a mere artifact of the
> incorrect way that the problem was framed.

This is just bullshit.  "The Halting Problem" actually CAN'T be
"framed"
in terms of TMs AT ALL because THERE IS NO Halts() TM.

If you would ever start talking about TMs THAT ACTUALLY EXIST
and STOP talking about Halts(), THEN MAYBE WE COULD GET
somewhere.  You have already conceded that there cannot exist
a TM that always gets all the Halts(m,i) pairs right.  Do you think
you have written a TM that deserves to be EXCUSED for getting some of
them WRONG?  Do you think you can show that EVERY (m,i) pair that
YOUR tm gets wrong can be "shown to be semantically ill-formed"?
Well, I'm sorry, YOU'RE JUST WRONG, NO (m,i) pair IS EVER
"semantically
ill-formed).  EVERY tm JUST DOES WHAT IT DOES on EVERY input, and
it is ALWAYS doing what *IT* was written to do, CORRECTLY, on THAT
input.
The fact that it isn't always telling (if its input is m,i) whether m
halts on i does
NOT make inCORRECT -- it JUST makes it not HALTS(,)!!


0
greeneg9613 (188)
4/11/2012 1:11:59 AM
On 4/10/2012 7:59 PM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>
>> On 4/9/2012 10:21 PM, Ben Bacarisse wrote:
>>>> In every case where halting is not decidable, there is an error of
>>>>>   reasoning within the problem. Halting always decidable for every non
>>>>>   erroneous case.
>>> That's not where the error of reasoning lies.
>>>
>>> Halting is undecidable, period.  The term decidable should not be applied
>>> to individual cases.
>>>
>> Since the only times that it does not get the right answer, the
>> question itself is malformed, it should still be considered a
>> decider. It is incorrect to require it to correctly answer incorrect
>> questions.
> So we are back where it all started.  You still don't accept the simple
> fact that all halting questions have correct true/false answers,

Pathological Self-Reference as clearly demonstrated by Daryl's
"Volunteer" example shows that the question posed to the TM/Volunteer
is not the same question posed to someone else, even though these two 
different question may have identical words.

The fact that the TM can not possibly provide a correct return value 
from the set of {true, false} answering the question about whether or 
not TM M will halt on input M, and someone else can correctly answer 
what appears to be the same question conclusively proves that the 
semantics varies across the two instances, and thus even though they may 
have identical words, they are *not* the same question.

> but you
> can't say what option, other than hating or not hating, a TM has.
>
> The fact that no one machine can answer all of some class of questions
> does not mean that any of that any of those questions are, necessarily,
> malformed.
In this case it does.

> There are no "undecidable" cases, yet every machine has at least one
> input what it will incorrectly classify.  All of the these inputs have a
> correct answer -- that's how we can know that a particular machine gets
> the answer wrong.
>

0
NoSpam271 (937)
4/11/2012 1:52:30 AM
On 4/10/2012 8:11 PM, George Greene wrote:
> On Apr 10, 8:33 pm, Peter Olcott<NoS...@OCR4Screen.com>  wrote:
>> >    From this failure (to correctly process incorrect input) computing
>> >  theory poses a fundamental limitation of the capability of computation.
>> >
>> >  This limitation does not actually exist, it is a mere artifact of the
>> >  incorrect way that the problem was framed.
> This is just bullshit.  "The Halting Problem" actually CAN'T be
> "framed"
> in terms of TMs AT ALL because THERE IS NO Halts() TM.
>
> If you would ever start talking about TMs THAT ACTUALLY EXIST
> and STOP talking about Halts(), THEN MAYBE WE COULD GET
> somewhere.
Halts() always correct determines the halting or failure to halt for any 
input that is not malformed.

if (Decidable(Halts, "", ""))
   if (Halts("", ""))
     return true;
   else
     return false;
else
   return MalformedInput;

As it turns out the TM specified by a blank tape can not possibly be a 
valid TM because blanks are not within the input alphabet.

Since the TM specified by the empty-string neither halts nor fails to 
halt the only correct return value is MalformedInput.


0
NoSpam271 (937)
4/11/2012 1:58:26 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/10/2012 7:59 PM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>
>>> On 4/9/2012 10:21 PM, Ben Bacarisse wrote:
>>>>> In every case where halting is not decidable, there is an error of
>>>>>>   reasoning within the problem. Halting always decidable for every non
>>>>>>   erroneous case.
>>>> That's not where the error of reasoning lies.
>>>>
>>>> Halting is undecidable, period.  The term decidable should not be applied
>>>> to individual cases.
>>>>
>>> Since the only times that it does not get the right answer, the
>>> question itself is malformed, it should still be considered a
>>> decider. It is incorrect to require it to correctly answer incorrect
>>> questions.
>> So we are back where it all started.  You still don't accept the simple
>> fact that all halting questions have correct true/false answers,
>
> Pathological Self-Reference as clearly demonstrated by Daryl's
> "Volunteer" example shows that the question posed to the TM/Volunteer
> is not the same question posed to someone else, even though these two
> different question may have identical words.
>
> The fact that the TM can not possibly provide a correct return value
> from the set of {true, false} answering the question about whether or
> not TM M will halt on input M, and someone else can correctly answer
> what appears to be the same question conclusively proves that the
> semantics varies across the two instances, and thus even though they
> may have identical words, they are *not* the same question.

They are not even questions.  They are simply machines with an input
tape.  The questions are of the form "does TM t halt on input i" and
they all have correct true/false answers.

Anyway, I am a little tired of going round the same issues again and
again, and there are others who will pay attention to you now so you
don't need me anymore.

<snip>
-- 
Ben.
0
ben.usenet (6790)
4/11/2012 2:06:28 AM
On 4/10/2012 7:22 PM, Peter Olcott wrote:
> The problem seems to be that no one has yet completely understood *all*
> the very subtle nuances of meaning that are logically entailed by *all*
> of the various and sundry self-reference paradoxes.

To quote my math professor, mathematicians are (selectively) lazy and 
sloppy. People use underdefined terminology all the time in proofs 
because the precise definition is both understood by convention and 
often mildly irrelevant to the proof. But when you start doing the 
nitpicking, the locating of "very subtle nuances", you have to step back 
and make sure that the precision comes back out again. Stepping back and 
showing you a real world example:

The natural logarithm, ln(x) [1], is sometimes defined to be ln(x) = y 
iff e^y = x. It is also sometimes defined as ln(x) = integral from 1 to 
x of 1/y with respect to y (this is what my calculus textbook did). If 
you blunder naively, you could use these two different definitions to 
"prove" that the antiderivative of 1/x is the inverse operation to 
exponentiation, merely by using the differing definitions of ln(x) at 
different points of time. It happens to be true, but only because people 
have actually proved that the definitions are equivalent.

> If this is examined closely enough where not the slightest trace of
> semantic meaning is allowed to slip through the cracks of complete
> comprehension, one realizes that there is unsound reasoning at the basis
> of *all* of these paradoxes.

The unsound reasoning, of course, being that people are ascribing 
different meanings to the same words in different contexts.

> In my March 14, 2012 6:52 PM CDT posting:
> Pathological Self-Reference and the Halting Problem
> I quoted Daryl McCullough's perfect analogy where
> he translated the Halting Problem into a question
> posted to a human "volunteer".
>
> This perfect analogy showed another example of the
> Pathological Self-Reference error that is identical
> to the error of the Halting Problem. Alas no one
> (not even Daryl) understood this perfect analogy (so far).

Another great chance for me to describe what I'm saying perfectly.

Your quote understands the question to be "Will your next answer be 
no?", from whence you continue on to note that it is impossible to 
answer that question correctly. The context of the formal mathematical 
operation in question is that there is a machine INANE(M) that first 
queries if DEAR accepts (M, M) and proceeds to do the opposite of what 
DEAR does. DEAR attempts to (for the proof proceeds shows that it cannot 
fulfill this goal) accept (M, w) only if M would accept w. The 
contradiction is then found by noting that DEAR(INANE, INANE) cannot be 
the same answer as INANE(INANE).

Translating this analogy precisely is difficult, but the proposed 
translation of "Will your next answer be no?" is incorrect, since at no 
point is any machine being directly asked what it would itself do--the 
concept of "you", or of second person in general, is not a well-formed 
concept in formal computer algorithms. A more accurate translation would 
be that the question is "32. Will Crazy Tom answer no to question 32 on 
this test?"

You have blindly asserted that your proposed question is the best 
mapping and proceeded from that assertion to claim that the question has 
"no correct answer." The question I give clearly has a correct 
answer--either Crazy Tom answers "no" or he doesn't. It is possible for, 
say, Sally, to answer this question correctly, but note that Crazy Tom 
himself cannot answer the question correctly.

Returning to formalism, the proof of the undecidability all of the 
halting problem boils down to the statement "For all machines, there 
exists a question which it gets wrong." When we are sloppy, the 
"question" it gets wrong boils down might be phrased as "Will the answer 
to this question be no?". You then look at this question and deduce that 
it relates to "there exists a question which all machines get wrong"--it 
is from that premise that you then proceed to argue that we ought to 
exclude all questions that all machines get wrong, completely oblivious 
to the fact that the proof never asserted nor relied on such questions 
in the first place [2].

When people use "this" in reference to things like Turing machines, the 
operation being applied is actually something like the Recursion 
Theorem. The example (I think it comes from Wikipedia) I like to think 
of is the following:

", when preceded by itself in quotes, is unprovable.", when preceded by 
itself in quotes, is unprovable.

The act of "computing" the statement makes the statement apparently 
self-referential, but at no point does it actually make any 
self-referential claims. In other words, the underlying rationale is 
actually much more powerful and broader: sufficiently complex systems 
can fake self-reference well-enough to be able to render completeness 
claims false. The only way to get rid of these issues is to make the 
system unusably simple (not that PDA and DFA don't have these issues at 
the cost of being too weak to be usable models for computation).

In short, if you bother to read this far, your claim that no one 
understood the analogy rests on an interpretation that starts from a 
different statement than what the proof shows. The nuance that you've 
missed (not that we've missed) is the order of quantification in the 
formal proof and the implicit quantification in the informal analogy.

[1] This example brings up another excellent case of sloppiness. What is 
the base understood if I just say "log(x)"? When first introduced in 
algebra, the base is generally understood to be 10. In some math 
circles, it's generally understood to be e (Euler's constant). In 
computational theory, it's generally understood to be 2. Abuse of this 
could lead you to say that 4 is about equal to 100 (since log(4) = 2 [in 
base 2] and log(100) = 2 [in base 10], so log(4) = log(100) and thence 4 
= 100).

[2] Actually, it is trivial to prove that there is no question that all 
machines get wrong. Decidable languages are closed under complement 
(proof: swap accept and reject states). So for any machine M1, there 
exists a machine M2 such that M1 gets right all cases that M2 gets wrong 
and vice versa. For all possible inputs, either M1 gets it right or M2 
gets it right, so there always exists a machine that gets a question right.
-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/11/2012 2:28:38 AM
Peter Olcott wrote:
> The problem seems to be that no one has yet completely understood *all*
> the very subtle nuances of meaning that are logically entailed by *all*
> of the various and sundry self-reference paradoxes.

No, the problem here is that your claim was false, as far as it was
well enough defined to be true or false. You seemed to think some TM
could decide which instances were undecidable for another given TM. I
proved that no TM can.

As for the subtle nuances of self-reference, no one wants to discuss
Godel's theorem with someone who founders on proof-by-contradiction.

[...]
> In order to do this one must treat natural language as a
> mathematical formalism. This is an aspect of mathematics

Peter, over and over you've failed to mathematically formalize
problems that are *easy* to mathematically formalize.

[...]
> My point of view comes from KR rather than the Theory of
> Computation.

Your point of view turned out to be wrong. I don't see any reason to
blame KR for that.

-Bryan
0
4/11/2012 3:43:55 AM
On 4/10/2012 9:06 PM, Ben Bacarisse wrote:
>> >  Pathological Self-Reference as clearly demonstrated by Daryl's
>> >  "Volunteer" example shows that the question posed to the TM/Volunteer
>> >  is not the same question posed to someone else, even though these two
>> >  different question may have identical words.
>> >
>> >  The fact that the TM can not possibly provide a correct return value
>> >  from the set of {true, false} answering the question about whether or
>> >  not TM M will halt on input M, and someone else can correctly answer
>> >  what appears to be the same question conclusively proves that the
>> >  semantics varies across the two instances, and thus even though they
>> >  may have identical words, they are*not*  the same question.
> They are not even questions.  They are simply machines with an input
> tape.  The questions are of the form "does TM t halt on input i" and
> they all have correct true/false answers.
>
> Anyway, I am a little tired of going round the same issues again and
> again, and there are others who will pay attention to you now so you
> don't need me anymore.
>
> <snip>
> -- Ben.
If you ever did pay attention you would have understood long ago.
0
NoSpam271 (937)
4/11/2012 9:43:08 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:
<snip>
> If you ever did pay attention you would have understood long ago.

If you have a friend whose opinion you value, ask them what they thing
of this: you've spotted a truth that has escaped the likes of Church,
Turing, Post and Kleene and, when trying to explain it to people in the
field, they did not understand because they were not paying attention.

-- 
Ben.
0
ben.usenet (6790)
4/11/2012 4:45:15 PM
On 4/11/2012 9:45 AM, Ben Bacarisse wrote:
> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
> <snip>
>> If you ever did pay attention you would have understood long ago.
>
> If you have a friend whose opinion you value, ask them what they thing
> of this: you've spotted a truth that has escaped the likes of Church,
> Turing, Post and Kleene and, when trying to explain it to people in the
> field, they did not understand because they were not paying attention.
>

Remember to mention that several of the people who failed to understand
because they were not paying attention wrote thousands of words of
carefully reasoned responses and commentary on your ideas.

Patricia
0
pats (3556)
4/11/2012 6:29:22 PM
On Apr 10, 7:59=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> Since the only times that it does not get the right answer, the question
> itself is malformed,

This is just ridiculous.
The question "Does M halt on I" IS NEVER malformed.
The only problem is, posing this question TO ANY TURING MACHINE
is arguably IMPOSSIBLE because THERE IS NO TM that
MEANS "Halts(,)".

If Peter Olcott writes a machine then it will necessarily be
"Phaults(,)"
AND NOT Halts(,) -- SINCE NO TM is Halts(,) -- and the only kinds of
questions that CAN be posed to IT will be questions of the form
Does M Phault on I ?
And the answers will be, well, who gives a shit ?
0
greeneg9613 (188)
4/11/2012 7:43:08 PM
On Mar 27, 8:03=A0pm, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> Boolean AnyString()
> {
> =A0 =A0TM m; =A0 =A0 // Turing Machine hard-wired into finite-control
> =A0 =A0String x; =A0// Input data hard-wired into finite-control
> =A0 =A0m(x);
> =A0 =A0return true;
>
> }
>
> // This function works correctly for all input that is decidable:

This is a LIE, Peter.
In the first place, this function DOESN'T EVEN HAVE ANY input:
You have NOT NAMED an input-string as a parameter.
Any TM implementing this function can IGNORE its input.
What MIGHT have been its input IS ALREADY HARD-WIRED INTO IT
as m and x.  These are NOT input TO the program; m and x here
ARE PART of the program.

In the second place, IT IS NOT POSSIBLE for individual input TO BE
"decidable" or "undecidable".  What IS possible is for this TM
to either Loop on some inputs or Halt on others.  But you canNOT
keep SAYING "this input is undecidable for this TM" when what you MEAN
is "this TM does not halt on this input".  You have TO SAY "this TM
does not halt on this input" or "This TM Loops on this input".
"Undecidable"  MEANS SOMETHING ELSE!!
0
greeneg9613 (188)
4/11/2012 7:53:01 PM
On Mar 27, 9:56=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> 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?


ANYbody can prove THAT, since he mis-stated since definition.
As he defined it, the trivial TM that always loops on everything
is a bug-free halt analyzer: since it never answers any question at
all,
it NEVER answers any halting question WRONGLY, so it is "bug-free".
The error he made in stating his intended definition is very minor and
very common but therefore also very IMPORTANT, pedagogically; it
is one that teachers generally need to be in the HABIT of explaining
and correcting, because it will be made so often as to force you to
DEVELOP the habit.   He said:

> 1) Whenever Halts() halts in its accept state its input tm would halt on
> its input.

I retorted:
 : Since Halts() does not exist, THIS IS MEANINGLESS.
 : What you MEAN to say is that if you have some CANDIDATE tm
 : h -- NOT Halts(), then *h*, NOT Halts(), is bug-free if  h
satisfies
 : all these constraints.   It will of course turn out that you have
 : specified the constraints SO POORLY that TONS of h's will meet them
 : WITHOUT being "bug-free" -- they will have TONS of bugs in the form
 : of FAILURE TO ANSWER questions that CLEARLY ARE answerable.

This is one of the reasons why I got angry 4 days ago when you said
I wasn't quite on P.O.'s point about this -- I was THE FIRST person on
this point, even before P.O. was.  His concession that no TM always
gets
Halts(,) right would've been a big breakthrough had he not insisted on
CONTINUING to violate the lesson taught here by CONTINUING to call
his candidate/approximator/analyzer Halts(,) even though it is
definitionally
wrong an infinite amount of the time.

But that was not the error we were talking about.  We were
talking about his minor error in the specification.  This error
sort of trivializes his definition but that arguably should not be
held against it since it allows SIMPLY-definable TMs to satisfy
the definition and since putting those SIMPLE pegs in the h-hole here
(as Patricia and others, you and me both, did in fact try)
COULD have proven educational (or at least we had grounds to hope).
I got distracted from the error by the h-vs."halts()" name-controversy
above, but no fear: he repeats the error in the 2nd clause:

> 2) Whenever Halts() halts in its reject state its input tm would not
> halt on its input.

The error in both cases is that he says "Whenever" when he MEANS
"Whenever AND ONLY  when".
A CORRECT "halting analyzer" of m and i would accept-halt
If AND ONLY If m halted on i, and would reject-halt if AND ONLY if m
did not halt on i.  Of course, if m or i were ever "invalid" or
"malformed" or "incorrect", this would not leave an option for that,
but since THAT NEVER HAPPENS with TMs IN ANY case, that is not a REAL
problem.  He may have wanted to allow a third possibility but if that
is the case then his wording is still wrong in
allowing EVERYthing to (possibly) fall into that ill-formed-input
hole.

Basically, he said "bug-free" means "if it accept-halts then m halts
on i,
and if it reject-halts then m doesn't halt on i", when WHAT EVERYBODY
WANTS is of course actually THE OTHER WAY AROUND, NAMELY,
"if m halts on i then Phault accept-halts, and if m loops on i then
Phault reject-halts".  This is of course nowhere near achievable but
the other way around, as he has it, achieves triviality in most cases.
0
greeneg9613 (188)
4/11/2012 8:08:56 PM
On 4/11/2012 1:29 PM, Patricia Shanahan wrote:
> On 4/11/2012 9:45 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com> writes:
>> <snip>
>>> If you ever did pay attention you would have understood long ago.
>>
>> If you have a friend whose opinion you value, ask them what they thing
>> of this: you've spotted a truth that has escaped the likes of Church,
>> Turing, Post and Kleene and, when trying to explain it to people in the
>> field, they did not understand because they were not paying attention.
>>
>
> Remember to mention that several of the people who failed to understand
> because they were not paying attention wrote thousands of words of
> carefully reasoned responses and commentary on your ideas.

And that these responses utilized several threads of argumentation with 
a variety of arguments if it was clear that one was failing to persuade you.


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/11/2012 10:28:42 PM
On 4/10/2012 9:28 PM, Joshua Cranmer wrote:
> On 4/10/2012 7:22 PM, Peter Olcott wrote:
>> The problem seems to be that no one has yet completely understood *all*
>> the very subtle nuances of meaning that are logically entailed by *all*
>> of the various and sundry self-reference paradoxes.
>
> To quote my math professor, mathematicians are (selectively) lazy and 
> sloppy. People use underdefined terminology all the time in proofs 
> because the precise definition is both understood by convention and 
> often mildly irrelevant to the proof. But when you start doing the 
> nitpicking, the locating of "very subtle nuances", you have to step 
> back and make sure that the precision comes back out again. Stepping 
> back and showing you a real world example:
>
> The natural logarithm, ln(x) [1], is sometimes defined to be ln(x) = y 
> iff e^y = x. It is also sometimes defined as ln(x) = integral from 1 
> to x of 1/y with respect to y (this is what my calculus textbook did). 
> If you blunder naively, you could use these two different definitions 
> to "prove" that the antiderivative of 1/x is the inverse operation to 
> exponentiation, merely by using the differing definitions of ln(x) at 
> different points of time. It happens to be true, but only because 
> people have actually proved that the definitions are equivalent.
>
>> If this is examined closely enough where not the slightest trace of
>> semantic meaning is allowed to slip through the cracks of complete
>> comprehension, one realizes that there is unsound reasoning at the basis
>> of *all* of these paradoxes.
>
> The unsound reasoning, of course, being that people are ascribing 
> different meanings to the same words in different contexts.
>
>> In my March 14, 2012 6:52 PM CDT posting:
>> Pathological Self-Reference and the Halting Problem
>> I quoted Daryl McCullough's perfect analogy where
>> he translated the Halting Problem into a question
>> posted to a human "volunteer".
>>
>> This perfect analogy showed another example of the
>> Pathological Self-Reference error that is identical
>> to the error of the Halting Problem. Alas no one
>> (not even Daryl) understood this perfect analogy (so far).
>
> Another great chance for me to describe what I'm saying perfectly.
>
> Your quote understands the question to be "Will your next answer be 
> no?", from whence you continue on to note that it is impossible to 
> answer that question correctly. The context of the formal mathematical 
> operation in question is that there is a machine INANE(M) that first 
> queries if DEAR accepts (M, M) and proceeds to do the opposite of what 
> DEAR does. DEAR attempts to (for the proof proceeds shows that it 
> cannot fulfill this goal) accept (M, w) only if M would accept w. The 
> contradiction is then found by noting that DEAR(INANE, INANE) cannot 
> be the same answer as INANE(INANE).
>
> Translating this analogy precisely is difficult, but the proposed 
> translation of "Will your next answer be no?" is incorrect, since at 
> no point is any machine being directly asked what it would itself 
> do--the concept of "you", 

Incorrect. In this case the term "you" maps to the TM itself, thus self 
reference.

> or of second person in general, is not a well-formed concept in formal 
> computer algorithms. A more accurate translation would be that the 
> question is "32. Will Crazy Tom answer no to question 32 on this test?"
>
> You have blindly asserted that your proposed question is the best 
> mapping and proceeded from that assertion to claim that the question 
> has "no correct answer." 

The question with Pathological Self-Reference:
(1) Halts(M, M) as previously described.
(2) Will the volunteer's next answer be "no" ?
Is the question that has not possible correct answer.

The other identically worded question without Pathological 
Self-Reference is a different question entirely, and it is this question 
that you refer to when you say that the question has a correct answer, 
not the one with Pathological Self-Reference.

> The question I give clearly has a correct answer--either Crazy Tom 
> answers "no" or he doesn't. It is possible for, say, Sally, to answer 
> this question correctly, but note that Crazy Tom himself cannot answer 
> the question correctly.
>
> Returning to formalism, the proof of the undecidability all of the 
> halting problem boils down to the statement "For all machines, there 
> exists a question which it gets wrong." When we are sloppy, the 

Yes like does the Turning Machine specified by the empty string (the TM 
that is essentially defined to not exist) halt or fail to halt on the 
empty string?
(1) In order for it to halt it must have been running, so it can't 
possibly halt.

(2) In order for it to fail to halt it must currently be running, thus 
it is not this either.

Undecidable *only* because the question itself is ill-formed.

> "question" it gets wrong boils down might be phrased as "Will the 
> answer to this question be no?". You then look at this question and 
> deduce that it relates to "there exists a question which all machines 
> get wrong"--it is from that premise that you then proceed to argue 

Anyone and anything must always get ill-formed questions wrong.

> that we ought to exclude all questions that all machines get wrong, 
> completely oblivious to the fact that the proof never asserted nor 
> relied on such questions in the first place [2].
>
> When people use "this" in reference to things like Turing machines, 
> the operation being applied is actually something like the Recursion 
> Theorem. The example (I think it comes from Wikipedia) I like to think 
> of is the following:
>
> ", when preceded by itself in quotes, is unprovable.", when preceded 
> by itself in quotes, is unprovable.
>
> The act of "computing" the statement makes the statement apparently 
> self-referential, but at no point does it actually make any 
> self-referential claims. In other words, the underlying rationale is 
> actually much more powerful and broader: sufficiently complex systems 
> can fake self-reference well-enough to be able to render completeness 
> claims false. The only way to get rid of these issues is to make the 
> system unusably simple (not that PDA and DFA don't have these issues 
> at the cost of being too weak to be usable models for computation).
>
> In short, if you bother to read this far, your claim that no one 
> understood the analogy rests on an interpretation that starts from a 
> different statement than what the proof shows. The nuance that you've 
> missed (not that we've missed) is the order of quantification in the 
> formal proof and the implicit quantification in the informal analogy.

I think that this may be an error of the mathematical mapping from the 
concrete to the abstract where the formal mathematical abstraction loses 
essential details.

>
> [1] This example brings up another excellent case of sloppiness. What 
> is the base understood if I just say "log(x)"? When first introduced 
> in algebra, the base is generally understood to be 10. In some math 
> circles, it's generally understood to be e (Euler's constant). In 
> computational theory, it's generally understood to be 2. Abuse of this 
> could lead you to say that 4 is about equal to 100 (since log(4) = 2 
> [in base 2] and log(100) = 2 [in base 10], so log(4) = log(100) and 
> thence 4 = 100).
>
> [2] Actually, it is trivial to prove that there is no question that 
> all machines get wrong. Decidable languages are closed under 

What about my question about whether or not the TM specified by the 
empty string halts of fails to halt?

> complement (proof: swap accept and reject states). So for any machine 
> M1, there exists a machine M2 such that M1 gets right all cases that 
> M2 gets wrong and vice versa. For all possible inputs, either M1 gets 
> it right or M2 gets it right, so there always exists a machine that 
> gets a question right.

0
NoSpam271 (937)
4/11/2012 11:47:30 PM
On 4/10/2012 10:43 PM, Bryan wrote:
> Peter Olcott wrote:
>> >  The problem seems to be that no one has yet completely understood*all*
>> >  the very subtle nuances of meaning that are logically entailed by*all*
>> >  of the various and sundry self-reference paradoxes.
> No, the problem here is that your claim was false, as far as it was
> well enough defined to be true or false. You seemed to think some TM
> could decide which instances were undecidable for another given TM. I
> proved that no TM can.
I never saw that. If I saw it I might be able to point out the mistake. 
So far no one has shown that decidability is not *always* decidable.

TriState HaltingDecider(String tm, String input)
{
   if (Decidable(Halts, M, M))
     if (Halts(M, M))
       return True;
     else
       return False;
   else
     return InvalidInput;
}

It certainly seems like Dexter Kozen's example of Diagonalization on 
page 233 of his 1997 book, Automata and Computability is incorrect.

On the first row of the table on the top of the page it shows that the 
TM specified by the empty string (the TM essentially defined to not 
exist) halts on some inputs and fails to halt on others.
0
NoSpam271 (937)
4/11/2012 11:58:53 PM
On 4/11/2012 1:29 PM, Patricia Shanahan wrote:
> On 4/11/2012 9:45 AM, Ben Bacarisse wrote:
>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>> <snip>
>>> If you ever did pay attention you would have understood long ago.
>>
>> If you have a friend whose opinion you value, ask them what they thing
>> of this: you've spotted a truth that has escaped the likes of Church,
>> Turing, Post and Kleene and, when trying to explain it to people in the
>> field, they did not understand because they were not paying attention.
>>
>
> Remember to mention that several of the people who failed to understand
> because they were not paying attention wrote thousands of words of
> carefully reasoned responses and commentary on your ideas.
>
> Patricia

It was only Ben that was not paying enough attention. It took me four 
postings to get him to see a word that he kept missing.
0
NoSpam271 (937)
4/12/2012 12:00:51 AM
On 4/11/2012 2:43 PM, George Greene wrote:
> On Apr 10, 7:59 pm, Peter Olcott<NoS...@OCR4Screen.com>  wrote:
>> Since the only times that it does not get the right answer, the question
>> itself is malformed,
> This is just ridiculous.
> The question "Does M halt on I" IS NEVER malformed.

It is unconventional (yet essential) to consider whether or not input is 
semantically well-formed. Most often only syntax is considered.

> The only problem is, posing this question TO ANY TURING MACHINE
> is arguably IMPOSSIBLE because THERE IS NO TM that
> MEANS "Halts(,)".
>
> If Peter Olcott writes a machine then it will necessarily be
> "Phaults(,)"
> AND NOT Halts(,) -- SINCE NO TM is Halts(,) -- and the only kinds of
> questions that CAN be posed to IT will be questions of the form
> Does M Phault on I ?
> And the answers will be, well, who gives a shit ?

0
NoSpam271 (937)
4/12/2012 12:02:50 AM
On 4/11/2012 6:47 PM, Peter Olcott wrote:
> On 4/10/2012 9:28 PM, Joshua Cranmer wrote:
>> Translating this analogy precisely is difficult, but the proposed
>> translation of "Will your next answer be no?" is incorrect, since at
>> no point is any machine being directly asked what it would itself
>> do--the concept of "you",
>
> Incorrect. In this case the term "you" maps to the TM itself, thus self
> reference.

Obviously, you failed to read the next line:
>> or of second person in general, is not a well-formed concept in formal
>> computer algorithms. A more accurate translation would be that the
>> question is "32. Will Crazy Tom answer no to question 32 on this test?"

Either that, you failed to understand it. Let me give more detailed 
reasoning as to why this is the case.

In standard conversation, there are two people, the speaker (the first 
person) and the listener (the second person); everyone else not a party 
to the conversation comprises the third person.

In formal mathematics, there are propositions that assert truths. This 
turns into, at best, a binary disposition: a proposition can discuss 
itself (first person) or other propositions (third person). Second 
person fails to enter the picture. Furthermore, due to the inherent 
paradoxes allowed when propositions discuss themselves, use of the first 
person is generally considered invalid. However, sufficiently powerful 
systems allow a first person to be carefully faked: think the Recursion 
Theorem or Godel numbering. Sloppily, we can call this construct "first 
person", BUT it's not a true first person, but rather a construct in 
third person which happens to refer to the same proposition as itself.

In other words, it is not a case of ExAy, but rather of AxEy. It is 
permissible to call the fake first person first person, but only so long 
as you also keep in mind that it's not fully quantified and you need 
context to discuss it further.

> The question with Pathological Self-Reference:
> (1) Halts(M, M) as previously described.
> (2) Will the volunteer's next answer be "no" ?
> Is the question that has not possible correct answer.

It may be that (2) has no correct answer, but (1) is not equivalent to 
(2) in any manner.

>> Returning to formalism, the proof of the undecidability all of the
>> halting problem boils down to the statement "For all machines, there
>> exists a question which it gets wrong." When we are sloppy, the
>
> Yes like does the Turning Machine specified by the empty string (the TM
> that is essentially defined to not exist) halt or fail to halt on the
> empty string?

Which encoding are you using? Since you assert that the empty string 
defines a Turing Machine, and you failed to specify an encoding, I am 
going to assume that the mapping of f: w -> TM is defined by some 
arbitrary g: N -> TM, where f(w) = g(|w|). In this case, then, the TM I 
will select is the one that exists solely of an accept state. So it halts.

> (1) In order for it to halt it must have been running, so it can't
> possibly halt.
>
> (2) In order for it to fail to halt it must currently be running, thus
> it is not this either.
>
> Undecidable *only* because the question itself is ill-formed.

If the question is ill-formed, it's because you don't give enough 
context to answer it. Again, most mathematicians are sloppy and start by 
saying something along the lines of "since it's known that it can be 
done, fix any encoding of TM" (or sometimes, just leaving that implied). 
If I do fix the encoding schema, it becomes possible to answer the question.

Also, note that a TM cannot be "defined to not exist". The closest I can 
think of for what you would mean by that is a TM that has no states, but 
no TM can have no states since the definition of a TM requires that you 
specify a member of the set of states to start in: if the set of states 
is empty, you can't have a start state, so you can't have a TM. Also, 
since TMs are bijective with natural numbers, it is possible to 
enumerate all TMs, so all TMs are in effect computable and thus exist.

I've apologized before that mathematicians get sloppy, but when you're 
trying to pick out nuances, any sloppiness is unaffordable. So stop 
being sloppy.

>> "question" it gets wrong boils down might be phrased as "Will the
>> answer to this question be no?". You then look at this question and
>> deduce that it relates to "there exists a question which all machines
>> get wrong"--it is from that premise that you then proceed to argue
>
> Anyone and anything must always get ill-formed questions wrong.

What is an ill-formed question? You've never answered that. Well, you've 
made some reference to pathological self-reference, but that appears to 
be defined in terms of ill-formed questions, so it's a circular 
definition and hence doesn't count.

You've also done it again: you've turned the AxEy into a EyAx problem 
and argued from that. Considering I can easily prove ~EyAx, it's a 
really dumb thing to be doing.

>> In short, if you bother to read this far, your claim that no one
>> understood the analogy rests on an interpretation that starts from a
>> different statement than what the proof shows. The nuance that you've
>> missed (not that we've missed) is the order of quantification in the
>> formal proof and the implicit quantification in the informal analogy.
>
> I think that this may be an error of the mathematical mapping from the
> concrete to the abstract where the formal mathematical abstraction loses
> essential details.

Why should your mapping be right instead of the past 100 years of 
received wisdom? I've given what I feel to be persuasive evidence that 
your reasoning wrong and the received wisdom is right...

>> [2] Actually, it is trivial to prove that there is no question that
>> all machines get wrong. Decidable languages are closed under
>
> What about my question about whether or not the TM specified by the
> empty string halts of fails to halt?

As long as you define the encoding scheme, this is perfectly decidable. 
Indeed, to sidestep your complaints about strings that fail to map to 
TMs, note that it is possible to map every integer onto a TM (since TMs 
are countable), so we can map the size of the input into a TM 
(independent of the alphabet used), so every string gets mapped into a TM.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/12/2012 12:44:46 AM
Peter Olcott <NoSpam@OCR4Screen.com> writes:

> On 4/11/2012 1:29 PM, Patricia Shanahan wrote:
>> On 4/11/2012 9:45 AM, Ben Bacarisse wrote:
>>> Peter Olcott<NoSpam@OCR4Screen.com>  writes:
>>> <snip>
>>>> If you ever did pay attention you would have understood long ago.
>>>
>>> If you have a friend whose opinion you value, ask them what they thing
>>> of this: you've spotted a truth that has escaped the likes of Church,
>>> Turing, Post and Kleene and, when trying to explain it to people in the
>>> field, they did not understand because they were not paying attention.
>>>
>>
>> Remember to mention that several of the people who failed to understand
>> because they were not paying attention wrote thousands of words of
>> carefully reasoned responses and commentary on your ideas.
>>
>> Patricia
>
> It was only Ben that was not paying enough attention. It took me four
> postings to get him to see a word that he kept missing.

Oh good.  I'm fine with that.  I am glad that all the other posters who
have been saying that you are flat out wrong *have* been paying enough
attention to have understood.  I was just lucky, I guess, to reach the
same conclusion in total ignorance.

-- 
Ben.
0
ben.usenet (6790)
4/12/2012 1:58:03 AM
This is excellent.
I just wanted to re-quote it by way of endorsing it.
This is better than what I said.  If I had seen this first
then I would've waited a day to see whether this would
have any effect.

On Apr 11, 8:44=A0pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
> In standard conversation, there are two people, the speaker (the first
> person) and the listener (the second person); everyone else not a party
> to the conversation comprises the third person.
>
> In formal mathematics, there are propositions that assert truths. This
> turns into, at best, a binary disposition: a proposition can discuss
> itself (first person) or other propositions (third person). Second
> person fails to enter the picture. Furthermore, due to the inherent
> paradoxes allowed when propositions discuss themselves, use of the first
> person is generally considered invalid. However, sufficiently powerful
> systems allow a first person to be carefully faked: think the Recursion
> Theorem or Godel numbering. Sloppily, we can call this construct "first
> person", BUT it's not a true first person, but rather a construct in
> third person which happens to refer to the same proposition as itself.

Exactly.  This is what CAN be achieved in TMspeak and P.O. has come
close to achieving it some of the time, but he doesn't yet understand
that he HAS to be INTENTIONALLY doing this ALL the time if he wants
to achieve the analogy he is trying to make.  The question that IS
TM-translatable is not "will your answer to this question be "no"?"
but rather, 32.  Will Peter Olcott's answer to question 32 be "no"?
This is a question where different "Askings" or "invocations" CAN be
relevant because when this question is asked of anybody OTHER than
Peter Olcott, IT CAN be answered correctly BY ANYONE WHO KNOWS
ENOUGH ABOUT PETER OLCOTT, but even though Peter Olcott knows
MORE than they do about Peter Olcott (presumably he knows everything,
MAYBE EVEN HIS NAME), HE STILL canNOT answer this question correctly.

P.O. would like to go on to say that this question is "semantically
ill-formed
when it is asked of" Peter Olcott but not "semantically ill-formed"
when it is
asked of anyone else.   Or rather, not this question as a textual/
syntactic
entity, BUT RATHER, AN UTTERANCE or AN ASKING  of this question,
which, even though it doesn't textually contain an "askee", is in fact
ALWAYS
(as all questions arguably are) ALWAYS being posed TO or asked OF
*some*body.

In the case of using a TM to answer a question, the TM from which
the answer is coming would have to be the entity being asked,
so the TM itself is the askee.
That, however, makes it IMpossible to have DIFFERENT askee's!
The TM is ALSO the thing that embodies the meaning OF THE QUESTION!
If you ask a different TM then you are asking a different question,
unless its
input/output behavior is the same.

As for translating "you", since every TM can be referred to by a code-
string,
one could argue that if your code-string arrives as an input-
parameter,
it "means" YOU in that context.  The only problem is, most TMs
DON'T KNOW their own code-string.

It is similarly possible for somebody to ask you how a person named N
is
going to react to something withOUT your knowing that N is one of YOUR
names.
0
greeneg9613 (188)
4/12/2012 2:20:27 AM
Peter Olcott wrote:
> Bryan wrote:
> Peter Olcott wrote:
> >> > =A0The problem seems to be that no one has yet completely understood=
*all*
> >> > =A0the very subtle nuances of meaning that are logically entailed by=
*all*
> >> > =A0of the various and sundry self-reference paradoxes.
> > No, the problem here is that your claim was false, as far as it was
> > well enough defined to be true or false. You seemed to think some TM
> > could decide which instances were undecidable for another given TM. I
> > proved that no TM can.
>
> I never saw that. If I saw it I might be able to point out the mistake.

Why didn't you? You followed up with something about your interest in
some other field. You decided not to address the proof.

> So far no one has shown that decidability is not *always* decidable.

Proof beats proclamation:
http://groups.google.com/group/comp.theory/msg/f65c300bf2fb4467

> It certainly seems like Dexter Kozen's example of Diagonalization on
> page 233 of his 1997 book, Automata and Computability is incorrect.

I suggest you not submit an errata item.

-Bryan
0
4/12/2012 6:21:08 AM
On 4/11/2012 11:21 PM, Bryan wrote:
> Peter Olcott wrote:
>> Bryan wrote:
>> Peter Olcott wrote:
>>>>>   The problem seems to be that no one has yet completely understood*all*
>>>>>   the very subtle nuances of meaning that are logically entailed by*all*
>>>>>   of the various and sundry self-reference paradoxes.
>>> No, the problem here is that your claim was false, as far as it was
>>> well enough defined to be true or false. You seemed to think some TM
>>> could decide which instances were undecidable for another given TM. I
>>> proved that no TM can.
>>
>> I never saw that. If I saw it I might be able to point out the mistake.
>
> Why didn't you? You followed up with something about your interest in
> some other field. You decided not to address the proof.

In an earlier article,
(https://groups.google.com/group/comp.theory/msg/ada9e7bbe7b1f3f6) he
said "If any response takes more than five minutes it takes to long.".

He probably could not understand your proof, or indeed any non-trivial
proof, within his self-imposed time limit. His standard action in those
situations seems to be to follow-up with something that neither
questions the content of the proof nor accepts its result.

Patricia
0
pats (3556)
4/12/2012 2:46:11 PM
On 4/11/2012 7:44 PM, Joshua Cranmer wrote:
> On 4/11/2012 6:47 PM, Peter Olcott wrote:
>> On 4/10/2012 9:28 PM, Joshua Cranmer wrote:
>>> Translating this analogy precisely is difficult, but the proposed
>>> translation of "Will your next answer be no?" is incorrect, since at
>>> no point is any machine being directly asked what it would itself
>>> do--the concept of "you",
>>
>> Incorrect. In this case the term "you" maps to the TM itself, thus self
>> reference.
>
> Obviously, you failed to read the next line:
>>> or of second person in general, is not a well-formed concept in formal
>>> computer algorithms. A more accurate translation would be that the
>>> question is "32. Will Crazy Tom answer no to question 32 on this test?"
>
> Either that, you failed to understand it. Let me give more detailed 
> reasoning as to why this is the case.
>
> In standard conversation, there are two people, the speaker (the first 
> person) and the listener (the second person); everyone else not a 
> party to the conversation comprises the third person.
>
> In formal mathematics, there are propositions that assert truths. This 
> turns into, at best, a binary disposition: a proposition can discuss 
> itself (first person) or other propositions (third person). Second 
> person fails to enter the picture. Furthermore, due to the inherent 
> paradoxes allowed when propositions discuss themselves, use of the 
> first person is generally considered invalid. However, sufficiently 
> powerful systems allow a first person to be carefully faked: think the 
> Recursion Theorem or Godel numbering. Sloppily, we can call this 
> construct "first person", BUT it's not a true first person, but rather 
> a construct in third person which happens to refer to the same 
> proposition as itself.
>
> In other words, it is not a case of ExAy, but rather of AxEy. It is 
> permissible to call the fake first person first person, but only so 
> long as you also keep in mind that it's not fully quantified and you 
> need context to discuss it further.
>
>> The question with Pathological Self-Reference:
>> (1) Halts(M, M) as previously described.
>> (2) Will the volunteer's next answer be "no" ?
>> Is the question that has not possible correct answer.
>
> It may be that (2) has no correct answer, but (1) is not equivalent to 
> (2) in any manner.

It is exactly analogous. I don't see how this is not completely obvious. 
If you really think that it is not exactly analogous, please 
specifically point out the failing of the mathematical mapping from one 
to the other.

An answer from a person and a return value from a Turing Machine are 
equivalent, the only thing that changes is the interface, not the 
underlying semantics. It would be possible to wrap the invocation of a 
Turing Machine within a natural language interface such that the natural 
language completely precisely mathematically maps to both the invocation 
and the return value of the Turing Machine.

M( String Input )
{
if ( Halts( Input, Input ) )
   Loop Forever;
else
   Exit;
}

I am pointing out the mappings that make these two analogous:

(1) In both cases there is no correct answer that can be provided:
  (a) The return value from the invocation of Halts(M, M)
  (b) The answer to the question:
      "Will the next word out of the Volunteer’s mouth be 'no'?"

Halts() can neither correctly halt its accept state nor correctly halt 
in its reject state, and the Volunteer can neither correctly answer 
"yes" nor correctly answer "no". Thus the two problems are exactly 
analogous in that no correct {return value/answer} can be provided by 
either of them.

(2) In both cases the reason why neither Halts() nor the Volunteer can 
provide a correct answer is (because of self-reference) the the act of 
providing the answer makes this answer incorrect. Again we have a 
perfect correspondence across this dimension: In both cases 
self-reference causes any answer provided to be incorrect.

Summary:
(1) A machine invocation and a question to a person are analogous 
because a natural language interface can be added to the former that 
precisely mathematically maps to the invocation.

(2) In both cases no correct answer can be provided from the complete 
set of possible answers.

(3) The reason for (2) in both cases is that self-reference is what 
causes the lack of possible correct answers.

(4) There are no other relevant factors that are not analogous.

>
>>> Returning to formalism, the proof of the undecidability all of the
>>> halting problem boils down to the statement "For all machines, there
>>> exists a question which it gets wrong." When we are sloppy, the
>>
>> Yes like does the Turning Machine specified by the empty string (the TM
>> that is essentially defined to not exist) halt or fail to halt on the
>> empty string?
>

The empty string is defined by the tape containing only blanks, and the 
blank is not an element of the input alphabet. So essentially the TM 
specified by the empty string, is the TM that is specified by the lack 
of an encoding.

> Which encoding are you using? Since you assert that the empty string 
> defines a Turing Machine, and you failed to specify an encoding, I am 
> going to assume that the mapping of f: w -> TM is defined by some 
> arbitrary g: N -> TM, where f(w) = g(|w|). In this case, then, the TM 
> I will select is the one that exists solely of an accept state. So it 
> halts.
>

No that is incorrect. The TM specified by the lack of being specified is 
the TM that does not exist, thus neither halts nor fails to halt.

>> (1) In order for it to halt it must have been running, so it can't
>> possibly halt.
>>
>> (2) In order for it to fail to halt it must currently be running, thus
>> it is not this either.
>>
>> Undecidable *only* because the question itself is ill-formed.
>
> If the question is ill-formed, it's because you don't give enough 
> context to answer it. Again, most mathematicians are sloppy and start 
> by saying something along the lines of "since it's known that it can 
> be done, fix any encoding of TM" (or sometimes, just leaving that 
> implied). If I do fix the encoding schema, it becomes possible to 
> answer the question.
>

Does the TM that is not specified (thus specified as non existent) at 
all halt or fail to halt?

> Also, note that a TM cannot be "defined to not exist". 

The TM specified entirely by the lack of any encoding what-so-ever, is 
the TM specified to be non existent.

> The closest I can think of for what you would mean by that is a TM 
> that has no states, but no TM can have no states since the definition 

Exactly my point. Thus the TM specified with no states is an ill-defined 
TM that can neither halt nor fail to halt. If we ask another TM to 
determine whether or not an ill-defined TM halts or fails to halt, the 
TM can not correctly decide because neither answer is correct.

> of a TM requires that you specify a member of the set of states to 
> start in: if the set of states is empty, you can't have a start state, 
> so you can't have a TM. Also, since TMs are bijective with natural 
> numbers, it is possible to enumerate all TMs, so all TMs are in effect 
> computable and thus exist.
>
> I've apologized before that mathematicians get sloppy, but when you're 
> trying to pick out nuances, any sloppiness is unaffordable. So stop 
> being sloppy.
>
>>> "question" it gets wrong boils down might be phrased as "Will the
>>> answer to this question be no?". You then look at this question and
>>> deduce that it relates to "there exists a question which all machines
>>> get wrong"--it is from that premise that you then proceed to argue
>>
>> Anyone and anything must always get ill-formed questions wrong.
>
> What is an ill-formed question? You've never answered that.

I have answered that many times: An ill-formed question is any question 
lacking a correct answer from the set of possible answers.

> Well, you've made some reference to pathological self-reference, but 
> that appears to be defined in terms of ill-formed questions, so it's a 
> circular definition and hence doesn't count.

I have also defined this before:
Pathological Self-Reference, is any self-reference that derives 
ill-formed questions (as defined above).

The Halting Problem, Liar Paradox, Godel's Incompleteness Theorem and 
Russell's Barber Paradox are all examples of Pathological Self-Reference.

>
> You've also done it again: you've turned the AxEy into a EyAx problem 
> and argued from that. Considering I can easily prove ~EyAx, it's a 
> really dumb thing to be doing.
>
>>> In short, if you bother to read this far, your claim that no one
>>> understood the analogy rests on an interpretation that starts from a
>>> different statement than what the proof shows. The nuance that you've
>>> missed (not that we've missed) is the order of quantification in the
>>> formal proof and the implicit quantification in the informal analogy.
>>
>> I think that this may be an error of the mathematical mapping from the
>> concrete to the abstract where the formal mathematical abstraction loses
>> essential details.
>
> Why should your mapping be right instead of the past 100 years of 
> received wisdom? I've given what I feel to be persuasive evidence that 
> your reasoning wrong and the received wisdom is right...
Truth is not based on evidence:
http://en.wikipedia.org/wiki/Problem_of_induction
Truth is only based on tautology:

The mathematical mapping between representations of actuality and 
actuality itself. The actuality itself can be either empirical or 
conceptual or a hybrid combination of the two:
(a) The memory of the direct sensation of the taste of strawberries.
(b) The comprehension that 5 > 3 is true.
(c) That Bill had five dollars and spent two dollars thus leaving three 
dollars.

>
>>> [2] Actually, it is trivial to prove that there is no question that
>>> all machines get wrong. Decidable languages are closed under
>>
>> What about my question about whether or not the TM specified by the
>> empty string halts of fails to halt?
>
> As long as you define the encoding scheme, 

The encoding scheme of the TM specified by the empty string is the TM 
that is not specified at all. In other words the string is literally 
empty in that there is no string at all.

> this is perfectly decidable. Indeed, to sidestep your complaints about 
> strings that fail to map to TMs, note that it is possible to map every 
> integer onto a TM (since TMs are countable), so we can map the size of 
> the input into a TM (independent of the alphabet used), so every 
> string gets mapped into a TM.
>

0
NoSpam271 (937)
4/12/2012 8:56:02 PM
On 4/12/2012 9:46 AM, Patricia Shanahan wrote:
> On 4/11/2012 11:21 PM, Bryan wrote:
>> Peter Olcott wrote:
>>> Bryan wrote:
>>> Peter Olcott wrote:
>>>>>>   The problem seems to be that no one has yet completely 
>>>>>> understood*all*
>>>>>>   the very subtle nuances of meaning that are logically entailed 
>>>>>> by*all*
>>>>>>   of the various and sundry self-reference paradoxes.
>>>> No, the problem here is that your claim was false, as far as it was
>>>> well enough defined to be true or false. You seemed to think some TM
>>>> could decide which instances were undecidable for another given TM. I
>>>> proved that no TM can.
>>>
>>> I never saw that. If I saw it I might be able to point out the mistake.
>>
>> Why didn't you? You followed up with something about your interest in
>> some other field. You decided not to address the proof.
>
> In an earlier article,
> (https://groups.google.com/group/comp.theory/msg/ada9e7bbe7b1f3f6) he
> said "If any response takes more than five minutes it takes to long.".
>
> He probably could not understand your proof, or indeed any non-trivial
> proof, within his self-imposed time limit. His standard action in those
> situations seems to be to follow-up with something that neither
> questions the content of the proof nor accepts its result.
>
> Patricia

So where is the proof? The link contained no proof.
0
NoSpam271 (937)
4/12/2012 9:35:42 PM
On 4/10/2012 2:44 AM, Bryan wrote:
> Peter Olcott wrote:
>> In every case where halting is not decidable, there is an error of
>> reasoning within the problem. Halting always decidable for every non
>> erroneous case.
> A bold proclamation. Alas, math and logic disagree.
>
> We *can* construct a TM that:
>
>    1) Never answers the halting problem incorrectly, and
>    2) Always answers correctly when the answer is 'Halts'.

I have already shown how to do that and more, so I don't see your point.

>
> If you check your textbooks, you'll likely find 'Halts' defined as a
> language, something like the set of strings encoding pairs (m, s)
> where Turing machine m halts on input s. A TM with the two properties
> above *accepts* the language 'Halts'. There does not exist a TM that
> *decides* Halts.

I think that essential detail is lost when the conception of an actual 
machine that can execute instructions is mapped to the abstraction of a 
set of strings the are elements of a language. The essential detail that 
is lost is that when this mapping occurs we lose the reason why halting 
is undecidable, we remember that it is undecidable, but forget why.

>
> What's more, given a TM, call it 'PHaults' (pseudo-halts), that never
> answers incorrectly, we can construct a TM that correctly answers all
> the same cases as PHaults, plus always answers correctly when the
> answer is 'Halts'. Proof by construction: We interleave emulation of
> both PHalts on input (m, s) and m on input s. When either of them
> halts we have the answer: the output of PHaults if it halts first, or
> 'Halts' if m halts first.
>
> Now assume, Peter, that you are correct. Then there exists a TM
> 'PHaults', that only fails to decide in erroneous cases, and we can
> construct a TM, call it "Patho", that takes as input a TM and a
> halting problem instance, and decides whether the instance is an
> undecidable case for the given machine.
>
>  From PHaults, I can construct PHaultsP, (pseudo-halts-plus) that
> decides every case PHaults decides, plus always answers correctly when
> the answer is 'Halts'. I showed how above.
>
> Now I can build a TM 'Halts' that takes input (m, s), and interleaves
> emulation of Patho on (PHaultsP,  (m, s)) and PHaultsP on (m, s). If
> PHaultsP halts, I output its answer. If Patho find the s to be
> undecidable by PHaultsP, I output "Does not halt", which has to be
> correct because PHaultsP decides every instance where the answer is
> 'Halts'.
>
> My Turing machine, 'Halts', decides the halting problem. I showed how
> to construct it, given certain assumptions. Since no TM decides the
> halting problem, at least one of the assumptions must be wrong.

The above is far too convoluted. Also your naming conventions are less 
than 100% completely self descriptive.

Simply show why this will not work:

TriState HaltingDecider(String tm, String input)
{
   if (Decidable(Halts, tm, input))
     if (Halts(tm, input))
       return true;
     else
       return false;
   else
     return InvalidInput;
}

Make sure that your answer is as simple as possible so that no nuance of 
meaning is lost.

> They're all solid -- by UseNet standards and could clearly be made
> rigorous -- except for what I introduced with "Now assume...".
>
> Peter, the hour is late. I can understand how a novice, a student in a
> theory course, might think, "Hey, even if they've proven I can't
> decide every case, maybe I can distinguish which cases are
> undecidable". The brighter students in this area figure out that it's
> the same problem. Most of the rest move on to apply themselves where
> their talents are better aligned.
>
> -Bryan

0
NoSpam271 (937)
4/12/2012 10:03:50 PM
On 4/12/2012 3:56 PM, Peter Olcott wrote:
> On 4/11/2012 7:44 PM, Joshua Cranmer wrote:
>> On 4/11/2012 6:47 PM, Peter Olcott wrote:
>>> The question with Pathological Self-Reference:
>>> (1) Halts(M, M) as previously described.
>>> (2) Will the volunteer's next answer be "no" ?
>>> Is the question that has not possible correct answer.
>>
>> It may be that (2) has no correct answer, but (1) is not equivalent to
>> (2) in any manner.
>
> It is exactly analogous. I don't see how this is not completely obvious.
> If you really think that it is not exactly analogous, please
> specifically point out the failing of the mathematical mapping from one
> to the other.

I explicitly stated it twice. Let me explicitly state the problem again 
in yet another way:

The function we are mapping contains, in some sense, something that I 
think we could both agree is "this_machine". This is the construct you 
are trying to map to "the volunteer", or, more or less equivalently, 
"you".  The problem is that "this_machine" contains a free variable, so 
a fully-closed question must resolve it to "this_machine(x), where x is 
<something>." When you take the closure, the question becomes not about 
"the volunteer" but rather about "Sam". Alternatively, you can also talk 
about it without closing it, but you need to be careful to note that 
you're not talking about a single thing.

> (2) In both cases the reason why neither Halts() nor the Volunteer can
> provide a correct answer is (because of self-reference) the the act of
> providing the answer makes this answer incorrect. Again we have a
> perfect correspondence across this dimension: In both cases
> self-reference causes any answer provided to be incorrect.

The distinction you're missing is that, when discussing the closed form, 
there is a correct answer that someone can provide. However, it is 
impossible for the specific person or machine to answer it correctly, 
but that doesn't mean that it can't be done so.

> The empty string is defined by the tape containing only blanks, and the
> blank is not an element of the input alphabet. So essentially the TM
> specified by the empty string, is the TM that is specified by the lack
> of an encoding.

Under the definitions of TMs that I am used to seeing, the input tape 
cannot contain anything not in the input alphabet. Leaving that aside, 
though, it is still possible to define that the empty string would 
logically be equivalent to 0 and use natural numbers to do the mapping.

>> Which encoding are you using? Since you assert that the empty string
>> defines a Turing Machine, and you failed to specify an encoding, I am
>> going to assume that the mapping of f: w -> TM is defined by some
>> arbitrary g: N -> TM, where f(w) = g(|w|). In this case, then, the TM
>> I will select is the one that exists solely of an accept state. So it
>> halts.
>>
>
> No that is incorrect. The TM specified by the lack of being specified is
> the TM that does not exist, thus neither halts nor fails to halt.

I can define a total mapping that makes all inputs map to a TM that 
exists. I described it to you. If you strongly disagree with my 
definition of the encoding, then please explain the encoding you wish to 
use.

>> The closest I can think of for what you would mean by that is a TM
>> that has no states, but no TM can have no states since the definition
>
> Exactly my point. Thus the TM specified with no states is an ill-defined
> TM that can neither halt nor fail to halt. If we ask another TM to
> determine whether or not an ill-defined TM halts or fails to halt, the
> TM can not correctly decide because neither answer is correct.

Finish reading the paragraph first:
>> of a TM requires that you specify a member of the set of states to
>> start in: if the set of states is empty, you can't have a start state,
>> so you can't have a TM.

All TMs must have at least one state. So it is impossible to have a "TM 
specified with no states", because what you have is not a TM, nor is it 
an "ill-defined TM". What you have is nothing.

>> What is an ill-formed question? You've never answered that.
>
> I have answered that many times: An ill-formed question is any question
> lacking a correct answer from the set of possible answers.

Under the assumed definitions of "question", "correct answer", and 
"possible answer", the set of ill-formed questions thus becomes the 
empty set, so it is meaningless to ask if a machine can solve an 
ill-formed question, since none exist in the first place.

>> Why should your mapping be right instead of the past 100 years of
>> received wisdom? I've given what I feel to be persuasive evidence that
>> your reasoning wrong and the received wisdom is right...
> Truth is not based on evidence:

No, but evidence is generally a powerful indication of truth. Or, in the 
case of things which cannot be generally proven, evidence is taken to be 
the proof of truth.

> The encoding scheme of the TM specified by the empty string is the TM
> that is not specified at all. In other words the string is literally
> empty in that there is no string at all.

I defined a total mapping of inputs. The empty string has size 0, so the 
TM that corresponds to 0 in a given mapping of natural numbers to Turing 
machines would be specified by the empty string.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Pidgeot18 (1520)
4/12/2012 10:38:01 PM
On 4/12/2012 5:38 PM, Joshua Cranmer wrote:
> On 4/12/2012 3:56 PM, Peter Olcott wrote:
>> On 4/11/2012 7:44 PM, Joshua Cranmer wrote:
>>> On 4/11/2012 6:47 PM, Peter Olcott wrote:
>>>> The question with Pathological Self-Reference:
>>>> (1) Halts(M, M) as previously described.
>>>> (2) Will the volunteer's next answer be "no" ?
>>>> Is the question that has not possible correct answer.
>>>
>>> It may be that (2) has no correct answer, but (1) is not equivalent to
>>> (2) in any manner.
>>
>> It is exactly analogous. I don't see how this is not completely obvious.
>> If you really think that it is not exactly analogous, please
>> specifically point out the failing of the mathematical mapping from one
>> to the other.
>
> I explicitly stated it twice. Let me explicitly state the problem 
> again in yet another way:
>
> The function we are mapping contains, in some sense, something that I 
> think we could both agree is "this_machine". This is the construct you 
> are trying to map to "the volunteer", or, more or less equivalently, 
> "you".  The problem is that "this_machine" contains a free variable, 
> so a fully-closed question must resolve it to "this_machine(x), where 
> x is <something>." When you take the closure, the question becomes not 
> about "the volunteer" but rather about "Sam". Alternatively, you can 
> also talk about it without closing it, but you need to be careful to 
> note that you're not talking about a single thing.

M( String Input )
{
if ( Halts( Input, Input ) )
   Loop Forever;
else
   Exit;
}

This specification is sufficiently closed such that every possible 
element of the set of Turing Machines that can implement Halts() has no 
possible correct return value from the set of {true, false}.
0
NoSpam271 (937)
4/13/2012 12:10:43 AM
On 4/12/2012 5:38 PM, Joshua Cranmer wrote:
>> (2) In both cases the reason why neither Halts() nor the Volunteer can
>> provide a correct answer is (because of self-reference) the the act of
>> providing the answer makes this answer incorrect. Again we have a
>> perfect correspondence across this dimension: In both cases
>> self-reference causes any answer provided to be incorrect.
>
> The distinction you're missing is that, when discussing the closed 
> form, there is a correct answer that someone can provide. However, it 
> is impossible for the specific person or machine to answer it 
> correctly, but that doesn't mean that it can't be done so. 

That was very clumsy wording.

This part is clear:
it is impossible for the specific person or
machine to answer it correctly,

This part is very poorly worded:
but that doesn't mean that it can't be done so.

It looks like you are stating the absurdity that just because something 
is impossible does not mean that it can not be accomplished.

If you keep up with such tactics you might be able to avoid 
understanding me forever.
0
NoSpam271 (937)
4/13/2012 12:14:50 AM
On 4/12/2012 5:38 PM, Joshua Cranmer wrote:
>> The empty string is defined by the tape containing only blanks, and the
>> blank is not an element of the input alphabet. So essentially the TM
>> specified by the empty string, is the TM that is specified by the lack
>> of an encoding.
>
> Under the definitions of TMs that I am used to seeing, the input tape 
> cannot contain anything not in the input alphabet. Leaving that aside, 
> though, it is still possible to define that the empty string would 
> logically be equivalent to 0 and use natural numbers to do the mapping. 
Then you have it incorrectly. (At least according to Kozen) The input 
alphabet is a subset of the tape alphabet such that the blank character 
is not in the input alphabet. The left end-marker is also not in the 
input alphabet.

The non-existence of a thing does not precisely map to an existent zero. 
In the first case we are referring to the thing itself, in the second 
case we are referring to counting the number of things. This is yet 
another failing of precise semantic mapping.

The whole point is that it is possible to incorrectly specify a valid 
TM. To square-peg in round hole with sledgehammer the empty string into 
defining a valid TM is woefully incorrect. It only works if you are not 
really paying much attention to the details.
0
NoSpam271 (937)
4/13/2012 12:25:04 AM
On 4/12/2012 5:38 PM, Joshua Cranmer wrote:
>>> Which encoding are you using? Since you assert that the empty string
>>> defines a Turing Machine, and you failed to specify an encoding, I am
>>> going to assume that the mapping of f: w -> TM is defined by some
>>> arbitrary g: N -> TM, where f(w) = g(|w|). In this case, then, the TM
>>> I will select is the one that exists solely of an accept state. So it
>>> halts.
>>>
>>
>> No that is incorrect. The TM specified by the lack of being specified is
>> the TM that does not exist, thus neither halts nor fails to halt.
>
> I can define a total mapping that makes all inputs map to a TM that 
> exists. I described it to you. If you strongly disagree with my 
> definition of the encoding, then please explain the encoding you wish 
> to use. 

Since it is so difficult for people to understand to that Pathological 
Self-Reference derives semantically incorrect input that causes the 
Halting Problem to fail, I was trying a much simpler example of showing 
that it is possible to incorrectly specify a TM, such that the specified 
TM is ill-formed.

Then I could ask does an incorrectly specified (thus non existent) TM 
halt or fail to halt? (The correct answer is neither).
0
NoSpam271 (937)
4/13/2012 12:31:43 AM
On 4/12/2012 5:38 PM, Joshua Cranmer wrote:
>> Exactly my point. Thus the TM specified with no states is an ill-defined
>> TM that can neither halt nor fail to halt. If we ask another TM to
>> determine whether or not an ill-defined TM halts or fails to halt, the
>> TM can not correctly decide because neither answer is correct.
>
> Finish reading the paragraph first:
>>> of a TM requires that you specify a member of the set of states to
>>> start in: if the set of states is empty, you can't have a start state,
>>> so you can't have a TM.
>
> All TMs must have at least one state. So it is impossible to have a 
> "TM specified with no states", because what you have is not a TM, nor 
> is it an "ill-defined TM". What you have is nothing. 

And if one is asked the forced choice question does this non existent TM 
halt or does it fail to halt (those are the only two choices) there is 
no possible correct answer.

M( String Input )
{
if ( Halts( Input, Input ) )
   Loop Forever;
else
   Exit;
}

It is exactly the same way when one is asked:
What is the correct return value from the set of {true, false} that the 
invocation of Halts(M, M) can provide?

or answer the question what is the correct answer that the Volunteer can 
provide from the set of {yes, no} to the question:
"Will the next word out of the Volunteer’s mouth be 'no'?"

No one can correctly answer either of the above two questions because in 
both cases Pathological Self-Reference eliminates all possible answers.
0
NoSpam271 (937)
4/13/2012 12:42:11 AM
On 4/12/2012 5:38 PM, Joshua Cranmer wrote:
>
>>> What is an ill-formed question? You've never answered that.
>>
>> I have answered that many times: An ill-formed question is any question
>> lacking a correct answer from the set of possible answers.
>
> Under the assumed definitions of "question", "correct answer", and 
> "possible answer", the set of ill-formed questions thus becomes the 
> empty set, so it is meaningless to ask if a machine can solve an 
> ill-formed question, since none exist in the first place. 

Then correctly answer this question:
How many feet long is the color of your car?
0
NoSpam271 (937)
4/13/2012 12:43:12 AM
On 4/12/2012 5:38 PM, Joshua Cranmer wrote:
> in the first place.
>
>>> Why should your mapping be right instead of the past 100 years of
>>> received wisdom? I've given what I feel to be persuasive evidence that
>>> your reasoning wrong and the received wisdom is right...
>> Truth is not based on evidence:
>
> No, but evidence is generally a powerful indication of truth.

That is also an assumption that might prove to be as much as entirely 
false.
0