Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.software-eng > #2966 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-07-05 11:28 -0500 |
| Last post | 2021-07-07 18:04 -0500 |
| Articles | 20 on this page of 89 — 6 participants |
Back to article view | Back to comp.software-eng
How do we know that H(P,P)==0 is correct? olcott <NoOne@NoWhere.com> - 2021-07-05 11:28 -0500
Re: How do we know that H(P,P)==0 is correct? olcott <NoOne@NoWhere.com> - 2021-07-05 14:30 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-05 16:40 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 19:04 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 20:01 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 21:37 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 22:06 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-06 10:59 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-06 11:33 -0500
Re: How do we know that H(P,P)==0 is correct? (V2) olcott <NoOne@NoWhere.com> - 2021-07-06 21:00 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 11:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 13:10 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 14:51 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 20:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 21:04 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ independent v dependent variables ] olcott <NoOne@NoWhere.com> - 2021-07-08 07:46 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ independent v dependent variables ] olcott <NoOne@NoWhere.com> - 2021-07-08 22:54 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) olcott <NoOne@NoWhere.com> - 2021-07-08 11:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) olcott <NoOne@NoWhere.com> - 2021-07-08 20:07 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-08 21:21 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-08 21:36 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 08:59 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-09 18:06 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 12:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-09 20:16 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 14:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-09 22:08 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 16:13 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 10:00 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-10 16:15 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 10:21 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-10 16:25 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 11:08 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ]( You and I ) olcott <NoOne@NoWhere.com> - 2021-07-10 11:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-10 15:19 -0700
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] gazelle@shell.xmission.com (Kenny McCormack) - 2021-07-11 00:29 +0000
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 19:57 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 17:29 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 18:31 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 19:33 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-10 20:00 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ suspended not halted ] olcott <NoOne@NoWhere.com> - 2021-07-11 09:14 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-11 09:30 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ]( Flibble agrees ) olcott <NoOne@NoWhere.com> - 2021-07-11 14:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-12 17:18 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 08:41 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 09:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 10:02 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 15:52 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 16:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 22:12 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-15 09:17 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-15 19:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-15 19:52 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) olcott <NoOne@NoWhere.com> - 2021-07-15 22:03 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) olcott <NoOne@NoWhere.com> - 2021-07-16 21:48 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) olcott <NoOne@NoWhere.com> - 2021-07-19 10:11 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 10:33 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 10:43 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 17:21 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 20:11 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 20:52 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 21:14 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 21:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 15:53 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 10:07 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 22:18 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 23:01 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 23:45 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-10 09:25 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ type mismatch error ] olcott <NoOne@NoWhere.com> - 2021-07-10 10:32 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ type mismatch error ] olcott <NoOne@NoWhere.com> - 2021-07-10 11:19 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 20:31 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 21:07 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ global halt decider ] olcott <NoOne@NoWhere.com> - 2021-07-08 08:29 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ global halt decider ] olcott <NoOne@NoWhere.com> - 2021-07-09 09:02 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-05 23:15 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-06 10:26 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-06 21:18 +0100
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-06 15:41 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-06 23:18 +0100
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 09:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 20:15 -0500
Re: How do we know that H(P,P)==0 is correct? Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-07 14:18 +0200
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 13:43 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) scott@slp53.sl.home (Scott Lurndal) - 2021-07-07 19:01 +0000
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 14:39 -0500
Re: How do we know that H(P,P)==0 is correct? olcott <NoOne@NoWhere.com> - 2021-07-07 17:05 -0500
Re: How do we know that H(P,P)==0 is correct? [ proof ] olcott <NoOne@NoWhere.com> - 2021-07-07 18:04 -0500
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-10 20:00 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <l9ydnQjoXoMD33f9nZ2dnUU7-UOdnZ2d@giganews.com> |
| In reply to | #3023 |
On 7/10/2021 7:57 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 7/9/2021 7:13 PM, Ben Bacarisse wrote: > >>> For some H to be correct >>> >>> H(P,I) != 0 if and only if P(I) halts and >>> H(P,I) != 1 if and only if P(I) does not halt. >>> >>> If H is a pure simulator it will not meet this specification. But your >>> H is not a pure simulator. It is simply wrong about P(P). It is wrong >>> based in fact you have reported: that H(P,P) == 0 and that P(P) halts. >> >> Simulating halt decider H is only answering the question: >> Would the input halt on its input if H never stopped simulating it? > > So you've flipped back and admit (again) that you are not talking about > the halting problem. Why do you think anyone else cares about this > problem? Why don't you give it a name? I'm going with the PO > Other-Halting problem. > > Why do you think it has any impact on the proof that so obsesses you? > > When I asked you: > > || So which of your statements is the one you want to stand by? > || > || "We can know that my halt deciding criteria is the same as the halting > || problem" > || or > || "This maps to every element of the conventional halting problem set of > || non-halting computations and a few more." > > and you replied > > | The first one. > > that was wrong (if not an outright lie -- it's hard to tell with you). > Your H is deciding the silly criterion you made so clear last year and > which you've been trying to make sound reasonable ever since. > > Noting to see here... move along... > Maybe you are dumber than a box of rocks? Simulating halt decider H is only answering the question: Would the input halt on its input if H never stopped simulating it? (a) An answer of "no" universally means that the input never halts. Which is this Halt Deciding Axiom: When the pure simulation of the machine description ⟨P⟩ of a machine P on its input I never halts we know that P(I) never halts. (b) An answer of "yes" universally means that the input halts. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-11 09:14 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ suspended not halted ] |
| Message-ID | <OImdnbfdo8JIYXf9nZ2dnUU7-RXNnZ2d@giganews.com> |
| In reply to | #3050 |
On 7/11/2021 8:54 AM, Malcolm McLean wrote:
> On Sunday, 11 July 2021 at 04:13:28 UTC+1, olcott wrote:
>> On 7/10/2021 9:08 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/10/2021 7:57 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 7/9/2021 7:13 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> For some H to be correct
>>>>>>>
>>>>>>> H(P,I) != 0 if and only if P(I) halts and
>>>>>>> H(P,I) != 1 if and only if P(I) does not halt.
>>>>>>>
>>>>>>> If H is a pure simulator it will not meet this specification. But your
>>>>>>> H is not a pure simulator. It is simply wrong about P(P). It is wrong
>>>>>>> based in fact you have reported: that H(P,P) == 0 and that P(P) halts.
>>>>>>
>>>>>> Simulating halt decider H is only answering the question:
>>>>>> Would the input halt on its input if H never stopped simulating it?
>>>>> So you've flipped back and admit (again) that you are not talking about
>>>>> the halting problem. Why do you think anyone else cares about this
>>>>> problem? Why don't you give it a name? I'm going with the PO
>>>>> Other-Halting problem.
>>>>> Why do you think it has any impact on the proof that so obsesses you?
>>>>> When I asked you:
>>>>> || So which of your statements is the one you want to stand by?
>>>>> ||
>>>>> || "We can know that my halt deciding criteria is the same as the halting
>>>>> || problem"
>>>>> || or
>>>>> || "This maps to every element of the conventional halting problem set of
>>>>> || non-halting computations and a few more."
>>>>> and you replied
>>>>> | The first one.
>>>>> that was wrong (if not an outright lie -- it's hard to tell with you).
>>>>> Your H is deciding the silly criterion you made so clear last year and
>>>>> which you've been trying to make sound reasonable ever since.
>>>>> Noting to see here... move along...
>>>>
>>>> Maybe you are dumber than a box of rocks?
>>>
>>> Who knows? You are not equipped to tell.
>>>
>>>> Simulating halt decider H is only answering the question:
>>>> Would the input halt on its input if H never stopped simulating it?
>>>
>>> That's not the halting problem, it's the POOH problem.
>>>
>>>> (a) An answer of "no" universally means that the input never halts.
>>>
>> When the pure simulation of the machine description ⟨P⟩ of a machine P
>> on its input I never halts we know that P(I) never halts.
>>
>> When the pure simulation of the machine description ⟨P⟩ of a machine P
>> on its input I never halts we know that P(I) never halts.
>>
>> When the pure simulation of the machine description ⟨P⟩ of a machine P
>> on its input I never halts we know that P(I) never halts.
>> You dishonestly remove this from your reply because you are apparently a
>> dishonest scoundrel.
>>
> What you have created is a sort of paradox in its own right, that doesn't rely
> on the "invert" step of Linz's proof.
> If H detects P(P) as "run forever" then it halts it. If H doesn't detect this,
> P(P) runs forever. H has to be wrong about P(P), but it's nothing to do with
> the inverting infinite loop, but because P references H and, because H is a
> simulating decider, that leads to infinite nesting.
>
When we ask what Boolean value can a halt decider return to an input
that changes its behavior to contradict this value we cannot answer this
question because it is an incorrect type mismatch error question.
The answer is restricted to {true, false} thus excluding the correct
answer of “neither” making the question itself incorrect.
The TM / input pairs that “prove” the halting problem is undecidable
have the same pathological self-reference(Olcott 2004) error as the
self-contradictory liar paradox.
To eliminate this pathological feedback loop error we examine the
behavior of the input with a pure simulator that has no effect
what-so-ever on the behavior of the input.
As correct science requires the dependent variable (the halt status
decision) must only have the independent variable (the behavior of the
input) and be isolated from all other influences. Only when we do it
this way do we get the correct halt status decision for the input.
Until the behavior of its input proves that it will never halt every H
remains a pure simulator of this input.
This single fact by itself proves that the behavior of H has no effect
what-so-ever on its halt status decision. When H stops simulating its
input the execution of the input has been suspended, this does not count
as halting.
> There might be a footnote out of this. But not something revolutionary.
>>
>>> After all these years you have nothing. Please do something that brings
>>> joy into your life. You can't enjoy this, can you?
>>>
>> My cancer is at stage III, I am going to pursue this until it is
>> understood to be correct.
>>
> Your medical condition will bring your life into sharp focus. But I wouldn't
> centre your sense of self-worth on the halting problem.
>
It means that I cannot quite until validated, it is my whole legacy.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-11 09:30 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <5ridnUN6v4MNnXb9nZ2dnUU7-Q_NnZ2d@giganews.com> |
| In reply to | #3050 |
On 7/11/2021 5:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/10/2021 9:08 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/10/2021 7:57 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/9/2021 7:13 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> For some H to be correct
>>>>>>>
>>>>>>> H(P,I) != 0 if and only if P(I) halts and
>>>>>>> H(P,I) != 1 if and only if P(I) does not halt.
>>>>>>>
>>>>>>> If H is a pure simulator it will not meet this specification. But your
>>>>>>> H is not a pure simulator. It is simply wrong about P(P). It is wrong
>>>>>>> based in fact you have reported: that H(P,P) == 0 and that P(P) halts.
>>>>>>
>>>>>> Simulating halt decider H is only answering the question:
>>>>>> Would the input halt on its input if H never stopped simulating it?
>>>>> So you've flipped back and admit (again) that you are not talking about
>>>>> the halting problem. Why do you think anyone else cares about this
>>>>> problem? Why don't you give it a name? I'm going with the PO
>>>>> Other-Halting problem.
>>>>> Why do you think it has any impact on the proof that so obsesses you?
>>>>> When I asked you:
>>>>> || So which of your statements is the one you want to stand by?
>>>>> ||
>>>>> || "We can know that my halt deciding criteria is the same as the halting
>>>>> || problem"
>>>>> || or
>>>>> || "This maps to every element of the conventional halting problem set of
>>>>> || non-halting computations and a few more."
>>>>> and you replied
>>>>> | The first one.
>>>>> that was wrong (if not an outright lie -- it's hard to tell with you).
>>>>> Your H is deciding the silly criterion you made so clear last year and
>>>>> which you've been trying to make sound reasonable ever since.
>>>>> Noting to see here... move along...
>>>>
>>>> Maybe you are dumber than a box of rocks?
>>> Who knows? You are not equipped to tell.
>>>
>>>> Simulating halt decider H is only answering the question:
>>>> Would the input halt on its input if H never stopped simulating it?
>>> That's not the halting problem, it's the POOH problem.
>>>
>>>> (a) An answer of "no" universally means that the input never halts.
>>
>> When the pure simulation of the machine description ⟨P⟩ of a machine P
>> on its input I never halts we know that P(I) never halts.
>
> You have trouble keeping up with what's been said. This has never been
> in doubt.
Then you understand that any computation that never halts while H
remains a pure simulator it a computation that never halts. When H
aborts its simulation of this computation the computation has been
suspended and still never halts.
> I've said it myself, and at one point I even made sure you
> agreed with it (though I also added the other half, that a simulation of
> any halting computation halts).
>
> P(P) halts, and a simulation of <P> on input <P> will also halt. H(P,P)
> == 0 is wrong.
>
When we ask what Boolean value can a halt decider return to an input
that changes its behavior to contradict this value we cannot answer this
question because it is an incorrect type mismatch error question.
The answer is restricted to {true, false} thus excluding the correct
answer of “neither” making the question itself incorrect. The TM / input
pairs that “prove” the halting problem is undecidable have the same
pathological self-reference(Olcott 2004) error as the self-contradictory
liar paradox.
To eliminate this pathological feedback loop error we examine the
behavior of the input with a pure simulator that has no effect
what-so-ever on the behavior of the input.
As correct science requires the dependent variable (the halt status
decision) must only have the independent variable (the behavior of the
input) and be isolated from all other influences. Only when we do it
this way do we get the correct halt status decision for the input.
Until the behavior of its input proves that it will never halt every H
remains a pure simulator of this input.
This single fact by itself proves that the behavior of H has no effect
what-so-ever on its halt status decision. When H stops simulating its
input the execution of the input has been suspended, this does not count
as halting.
When the pure simulation of the machine description ⟨P⟩ of a machine P
on its input I never halts we know that P(I) never halts.
According to this criteria P(P) specifies a computation that never halts.
> We also know, from your unfortunately clear "line 15 commented out"
> days, that you claim H(P,P) == 0 is right (despite P(P) halting) because
> of what a related computation (P built from a proper simulator rather
> than H) would do.
>
>> You dishonestly remove this from your reply because you are apparently
>> a dishonest scoundrel.
>
> I remove it because it is not in dispute. Why should I agree, yet
> again, with an irrelevant remark?
>
> It's not even in dispute that you assert that 0 or false or no is the
> correct answer for some halting computations. It just means you are not
> talking about the halting problem where 0 or false or no is only correct
> for non-halting computations. The only point of dispute is that you
> want to find words that suggest to the gullible that your "adapted"
> criterion is the same as what everyone else calls halting.
>
>> While the simulating halt decider acts as a pure simulator on its
>> input P(P) would never ever halt, thus meeting the above criteria.
>
> P(P) halts. What it "would do", if it were not the halting computation
> it really is, is just your sleight of hand (or possibly your
> self-deception). What matters for the halting problem is what a
> computation does (though I don't like even this operational language)
> and P(P) halts.
>
>> My cancer is at stage III, I am going to pursue this until it is
>> understood to be correct.
>
> I find this very sad. Do you enjoy posting here? I hope so, because
> that would make me feel a little less guilty about having encouraged
> behaviour that I would consider toxic (and would have strongly
> discouraged) if I were a friend of yours. Even if you do enjoy it, I
> think I should stop.
>
> Wouldn't you rather go walk shelter dogs? That's what I'd do, while I
> had the strength.
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-11 14:47 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ]( Flibble agrees ) |
| Message-ID | <K6WdnS5epNZS13b9nZ2dnUU7-fnNnZ2d@giganews.com> |
| In reply to | #3054 |
On 7/11/2021 2:04 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 7/11/2021 5:10 AM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 7/10/2021 9:08 PM, Ben Bacarisse wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> On 7/10/2021 7:57 PM, Ben Bacarisse wrote: >>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>> >>>>>>>> On 7/9/2021 7:13 PM, Ben Bacarisse wrote: >>>>>>> >>>>>>>>> For some H to be correct >>>>>>>>> >>>>>>>>> H(P,I) != 0 if and only if P(I) halts and >>>>>>>>> H(P,I) != 1 if and only if P(I) does not halt. >>>>>>>>> >>>>>>>>> If H is a pure simulator it will not meet this specification. But your >>>>>>>>> H is not a pure simulator. It is simply wrong about P(P). It is wrong >>>>>>>>> based in fact you have reported: that H(P,P) == 0 and that P(P) halts. >>>>>>>> >>>>>>>> Simulating halt decider H is only answering the question: >>>>>>>> Would the input halt on its input if H never stopped simulating it? >>>>>>> So you've flipped back and admit (again) that you are not talking about >>>>>>> the halting problem. Why do you think anyone else cares about this >>>>>>> problem? Why don't you give it a name? I'm going with the PO >>>>>>> Other-Halting problem. >>>>>>> Why do you think it has any impact on the proof that so obsesses you? >>>>>>> When I asked you: >>>>>>> || So which of your statements is the one you want to stand by? >>>>>>> || >>>>>>> || "We can know that my halt deciding criteria is the same as the halting >>>>>>> || problem" >>>>>>> || or >>>>>>> || "This maps to every element of the conventional halting problem set of >>>>>>> || non-halting computations and a few more." >>>>>>> and you replied >>>>>>> | The first one. >>>>>>> that was wrong (if not an outright lie -- it's hard to tell with you). >>>>>>> Your H is deciding the silly criterion you made so clear last year and >>>>>>> which you've been trying to make sound reasonable ever since. >>>>>>> Noting to see here... move along... >>>>>> >>>>>> Maybe you are dumber than a box of rocks? >>>>> Who knows? You are not equipped to tell. >>>>> >>>>>> Simulating halt decider H is only answering the question: >>>>>> Would the input halt on its input if H never stopped simulating it? >>>>> That's not the halting problem, it's the POOH problem. >>>>> >>>>>> (a) An answer of "no" universally means that the input never halts. >>>> >>>> When the pure simulation of the machine description ⟨P⟩ of a machine P >>>> on its input I never halts we know that P(I) never halts. >>> You have trouble keeping up with what's been said. This has never been >>> in doubt. >> >> Then you understand that any computation that never halts while H >> remains a pure simulator it a computation that never halts. When H >> aborts its simulation of this computation the computation has been >> suspended and still never halts. > > You assured Mike Terry that H computed a function of it's arguments. > It's odd, given that you are breaking this rule, that you've not decided > to make H(P,P) correct. You could have arranged for H(P,P) == 0 and to > have P(P) not halt. Or you could just as well have arranged for H(P,P) > != 0 and have P(P) halt. [Olcott's theory] Mr Flibble Jul 10, 2021, 12:00:56 PM I agree with Olcott that a halt decider can NOT be part of that which is being decided (see [Strachey 1965]) which, if Olcott is correct, falsifies a collection of proofs (which I don't have the time to examine) which rely on that mistake. https://groups.google.com/g/comp.theory/c/6cEnndkkrKA/m/gRj0x9KOBgAJ To correct the pathological self reference(Olcott 2004) error the halt decider bases its halt status decision on the behavior its input while H merely observes this behavior as a pure simulator of this input. If you are dumber than a box of rocks you may fail to grasp this. > > You decided to be wrong twice. H does not compute any function of its > arguments, and H is wrong about the halting of the key computation. Oh > well... > > Is there a dog shelter near where you live? > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-12 17:18 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <CbqdnTORaaoqInH9nZ2dnUU7-InNnZ2d@giganews.com> |
| In reply to | #3054 |
On 7/12/2021 1:39 PM, André G. Isaak wrote: > On 2021-07-12 11:35, olcott wrote: >> On 7/12/2021 10:20 AM, André G. Isaak wrote: >>> On 2021-07-12 08:13, olcott wrote: >>>> On 7/11/2021 11:35 PM, Richard Damon wrote: >>>>> On 7/11/21 9:30 AM, olcott wrote: >>>>> >>>>>> According to this criteria P(P) specifies a computation that never >>>>>> halts. >>>>> >>>>> Which since even YOU have shown that if H does give the answer of >>>>> Non-Halting, that P(P) will halt when run as an independent >>>>> machine, so >>>>> the logic must be wrong. >>>>> >>>> >>>> It does not halt it has its execution suspended. >>>> If its execution was not suspended it would never halt. >>> >>> The SIMULATION OF ITS INPUT is suspended. But when we ask whether >>> P(P) halts we're not asking about the input to P(P). We're asking >>> about P(P) proper. >> >> *You must be dumber than a box of rocks* >> Do you know know that when any function call (of infinite recursion) >> from the first to the trillionth is aborted that even though this >> infinite recursion stops running IT IS STILL INFINITE RECURSION !!! > > > By that "reasoning" (using the term very loosely), when you run > H(Infinite_Recursion) and H suspends Infinite_recursion, it not only > entails that Infinite_Recursion (the thing being simulating) is > non-halting, but also that H (the simulator) is non-halting. > I prove that this is not true by actually showing the steps of infinite recursion being decided: https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation > Remember that a decider, *by definition* must be guaranteed to halt and > return a result. > I am not dumber than a box of rocks so I already know this. > When you run P(P) as an independent computation, the H inside P behaves > identically to the *top-level* H in H(P, P). Both are the thing doing > the simulating, not the thing being simulated. > > André > When you do not segregate the behavior being measured from the measure of the behavior pathological self-reference(Olcott 2004) occurs. Even after thousands of years people still do not understand that self contradictory expressions of language do not map to a Boolean value only because they are erroneous. Tarski has a whole undefinability of truth theorem that is entirely based on the impossibility of proving that a lie is true. How dumb is that? http://www.liarparadox.org/Tarski_247_248.pdf http://www.liarparadox.org/Tarski_275_276.pdf The Tarski theorem is exactly as if the 1931 Gödel incompleteness theorem has been translated to HOL having an actual provability predicate: x ∉ Pr if and only if p In the above expression x ∉ Pr is intended to mean: Provable(x) -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 08:41 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <3sadnQAKPPuWBXD9nZ2dnUU7-aXNnZ2d@giganews.com> |
| In reply to | #3060 |
On 7/12/2021 7:00 PM, André G. Isaak wrote: > On 2021-07-12 16:18, olcott wrote: >> On 7/12/2021 1:39 PM, André G. Isaak wrote: >>> On 2021-07-12 11:35, olcott wrote: >>>> On 7/12/2021 10:20 AM, André G. Isaak wrote: >>>>> On 2021-07-12 08:13, olcott wrote: >>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote: >>>>>>> On 7/11/21 9:30 AM, olcott wrote: >>>>>>> >>>>>>>> According to this criteria P(P) specifies a computation that >>>>>>>> never halts. >>>>>>> >>>>>>> Which since even YOU have shown that if H does give the answer of >>>>>>> Non-Halting, that P(P) will halt when run as an independent >>>>>>> machine, so >>>>>>> the logic must be wrong. >>>>>>> >>>>>> >>>>>> It does not halt it has its execution suspended. >>>>>> If its execution was not suspended it would never halt. >>>>> >>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask whether >>>>> P(P) halts we're not asking about the input to P(P). We're asking >>>>> about P(P) proper. >>>> >>>> *You must be dumber than a box of rocks* >>>> Do you know know that when any function call (of infinite recursion) >>>> from the first to the trillionth is aborted that even though this >>>> infinite recursion stops running IT IS STILL INFINITE RECURSION !!! >>> >>> >>> By that "reasoning" (using the term very loosely), when you run >>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not only >>> entails that Infinite_Recursion (the thing being simulating) is >>> non-halting, but also that H (the simulator) is non-halting. >>> >> >> I prove that this is not true by actually showing the steps of >> infinite recursion being decided: >> >> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >> >> >>> Remember that a decider, *by definition* must be guaranteed to halt >>> and return a result. >>> >> >> I am not dumber than a box of rocks so I already know this. > > You seem to be entirely missing my point. > > Compare the following: > > (1) When we run H(P, P), the topmost H is *not* being simulated. It > starts simulating its input, and at some point it suspends that simulation. > The fact that it must suspend the simulation at one point because the simulation <is> infinite proves beyond all possible doubt that the halt decider was correct at that point. It does not matter what happens after that point. It does not matter what happens after that point. It does not matter what happens after that point. If you know that an animal is a cat by testing its DNA then you know that it is a cat even if this cat barks. > (2) When we run P(P), the H at the beginning of the topmost P is *not* > being simulated. It starts simulating its input and at some point it > suspends its simulation. > > In the first case, you conclude that the input to H is non-halting based > on the fact that it has been suspended, but you acknowledge that H halts. > This is where you <are> dumber than a box of rocks. This is where you <are> dumber than a box of rocks. This is where you <are> dumber than a box of rocks. It is not that H made some arbitrary decision to suspend its input and we are relying on this arbitrary decision. It is the logical necessity that unless H suspends its input the simulation of its input is necessarily infinite thus conclusively proving beyond all possible doubt that P(P) <is> a computation that never halts. > In the second case, you conclude that the input the the H at the > beginning of the topmost P is non-halting based on the fact that it has > been suspended, but you somehow also conclude that the topmost P does > not halt. > > How can you claim that the topmost H halts in (1), but that the topmost > P doesn't halt in (2). These are identical in all respects. Either your > argument that P(P) doesn't halt is invalid, or your reasoning also > entails that H(P, P) does not halt (which would violate the claim that H > is a decider). Which is it? > > André > When H can monitor all of the behavior of P(P) H immediately aborts P before ever returning any value to P. When P has sneaky behavior behind the back of H, H cannot immediately terminate P. Drug dealers can get away with bad things until the cops are watching. When the cops are watching the behavior of the drug dealer is aborted. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 09:42 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <j5adnWfddJLxO3D9nZ2dnUU7-fvNnZ2d@giganews.com> |
| In reply to | #3066 |
On 7/13/2021 8:57 AM, André G. Isaak wrote: > On 2021-07-13 07:41, olcott wrote: >> On 7/12/2021 7:00 PM, André G. Isaak wrote: >>> On 2021-07-12 16:18, olcott wrote: >>>> On 7/12/2021 1:39 PM, André G. Isaak wrote: >>>>> On 2021-07-12 11:35, olcott wrote: >>>>>> On 7/12/2021 10:20 AM, André G. Isaak wrote: >>>>>>> On 2021-07-12 08:13, olcott wrote: >>>>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote: >>>>>>>>> On 7/11/21 9:30 AM, olcott wrote: >>>>>>>>> >>>>>>>>>> According to this criteria P(P) specifies a computation that >>>>>>>>>> never halts. >>>>>>>>> >>>>>>>>> Which since even YOU have shown that if H does give the answer of >>>>>>>>> Non-Halting, that P(P) will halt when run as an independent >>>>>>>>> machine, so >>>>>>>>> the logic must be wrong. >>>>>>>>> >>>>>>>> >>>>>>>> It does not halt it has its execution suspended. >>>>>>>> If its execution was not suspended it would never halt. >>>>>>> >>>>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask whether >>>>>>> P(P) halts we're not asking about the input to P(P). We're asking >>>>>>> about P(P) proper. >>>>>> >>>>>> *You must be dumber than a box of rocks* >>>>>> Do you know know that when any function call (of infinite >>>>>> recursion) from the first to the trillionth is aborted that even >>>>>> though this infinite recursion stops running IT IS STILL INFINITE >>>>>> RECURSION !!! >>>>> >>>>> >>>>> By that "reasoning" (using the term very loosely), when you run >>>>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not >>>>> only entails that Infinite_Recursion (the thing being simulating) >>>>> is non-halting, but also that H (the simulator) is non-halting. >>>>> >>>> >>>> I prove that this is not true by actually showing the steps of >>>> infinite recursion being decided: >>>> >>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>>> >>>> >>>>> Remember that a decider, *by definition* must be guaranteed to halt >>>>> and return a result. >>>>> >>>> >>>> I am not dumber than a box of rocks so I already know this. >>> >>> You seem to be entirely missing my point. >>> >>> Compare the following: >>> >>> (1) When we run H(P, P), the topmost H is *not* being simulated. It >>> starts simulating its input, and at some point it suspends that >>> simulation. >>> >> >> The fact that it must suspend the simulation at one point because the >> simulation <is> infinite proves beyond all possible doubt that the >> halt decider was correct at that point. >> >> It does not matter what happens after that point. >> It does not matter what happens after that point. >> It does not matter what happens after that point. >> >> If you know that an animal is a cat by testing its DNA then you know >> that it is a cat even if this cat barks. >> >>> (2) When we run P(P), the H at the beginning of the topmost P is >>> *not* being simulated. It starts simulating its input and at some >>> point it suspends its simulation. >>> >>> In the first case, you conclude that the input to H is non-halting >>> based on the fact that it has been suspended, but you acknowledge >>> that H halts. >>> >> >> This is where you <are> dumber than a box of rocks. >> This is where you <are> dumber than a box of rocks. >> This is where you <are> dumber than a box of rocks. >> >> It is not that H made some arbitrary decision to suspend its input and >> we are relying on this arbitrary decision. > > Nowhere above do I claim the decision is arbitrary, nor is that relevant > to the point I am making. > >> It is the logical necessity that unless H suspends its input the >> simulation of its input is necessarily infinite thus conclusively >> proving beyond all possible doubt that P(P) <is> a computation that >> never halts. >> >>> In the second case, you conclude that the input the the H at the >>> beginning of the topmost P is non-halting based on the fact that it >>> has been suspended, but you somehow also conclude that the topmost P >>> does not halt. >>> >>> How can you claim that the topmost H halts in (1), but that the >>> topmost P doesn't halt in (2). These are identical in all respects. >>> Either your argument that P(P) doesn't halt is invalid, or your >>> reasoning also entails that H(P, P) does not halt (which would >>> violate the claim that H is a decider). Which is it? >>> >>> André >>> >> >> When H can monitor all of the behavior of P(P) H immediately aborts P >> before ever returning any value to P. When P has sneaky behavior >> behind the back of H, H cannot immediately terminate P. Drug dealers >> can get away with bad things until the cops are watching. When the >> cops are watching the behavior of the drug dealer is aborted. > > > You seem to be entirely ignoring my question. Do you claim that H(P, P) > halts? > I claim that H(P,P) always correctly decides that its input never halts. This remains true no matter what happens after H(P,P) is correctly decided. > If so, how can you claim that P(P), when run as an *independent* > computation, does not halt given that it performs the exact same steps When we test the DNA of a cat and find that it is definitely a cat and this cat later gives birth to purebred Chihuahua puppies we know for sure that it is definitely a cat. > as H(P, P)? Both start simulating what you describe as an 'infinitely > nested simulation' and both suspend that simulation at some point for > identical reasons. > > André > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 10:02 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <0eudnTXpfb-MNnD9nZ2dnUU7-e-dnZ2d@giganews.com> |
| In reply to | #3071 |
On 7/13/2021 9:54 AM, wij wrote: > On Tuesday, 13 July 2021 at 22:42:59 UTC+8, olcott wrote: >> On 7/13/2021 8:57 AM, André G. Isaak wrote: >>> On 2021-07-13 07:41, olcott wrote: >>>> On 7/12/2021 7:00 PM, André G. Isaak wrote: >>>>> On 2021-07-12 16:18, olcott wrote: >>>>>> On 7/12/2021 1:39 PM, André G. Isaak wrote: >>>>>>> On 2021-07-12 11:35, olcott wrote: >>>>>>>> On 7/12/2021 10:20 AM, André G. Isaak wrote: >>>>>>>>> On 2021-07-12 08:13, olcott wrote: >>>>>>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote: >>>>>>>>>>> On 7/11/21 9:30 AM, olcott wrote: >>>>>>>>>>> >>>>>>>>>>>> According to this criteria P(P) specifies a computation that >>>>>>>>>>>> never halts. >>>>>>>>>>> >>>>>>>>>>> Which since even YOU have shown that if H does give the answer of >>>>>>>>>>> Non-Halting, that P(P) will halt when run as an independent >>>>>>>>>>> machine, so >>>>>>>>>>> the logic must be wrong. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It does not halt it has its execution suspended. >>>>>>>>>> If its execution was not suspended it would never halt. >>>>>>>>> >>>>>>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask whether >>>>>>>>> P(P) halts we're not asking about the input to P(P). We're asking >>>>>>>>> about P(P) proper. >>>>>>>> >>>>>>>> *You must be dumber than a box of rocks* >>>>>>>> Do you know know that when any function call (of infinite >>>>>>>> recursion) from the first to the trillionth is aborted that even >>>>>>>> though this infinite recursion stops running IT IS STILL INFINITE >>>>>>>> RECURSION !!! >>>>>>> >>>>>>> >>>>>>> By that "reasoning" (using the term very loosely), when you run >>>>>>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not >>>>>>> only entails that Infinite_Recursion (the thing being simulating) >>>>>>> is non-halting, but also that H (the simulator) is non-halting. >>>>>>> >>>>>> >>>>>> I prove that this is not true by actually showing the steps of >>>>>> infinite recursion being decided: >>>>>> >>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>>>>> >>>>>> >>>>>>> Remember that a decider, *by definition* must be guaranteed to halt >>>>>>> and return a result. >>>>>>> >>>>>> >>>>>> I am not dumber than a box of rocks so I already know this. >>>>> >>>>> You seem to be entirely missing my point. >>>>> >>>>> Compare the following: >>>>> >>>>> (1) When we run H(P, P), the topmost H is *not* being simulated. It >>>>> starts simulating its input, and at some point it suspends that >>>>> simulation. >>>>> >>>> >>>> The fact that it must suspend the simulation at one point because the >>>> simulation <is> infinite proves beyond all possible doubt that the >>>> halt decider was correct at that point. >>>> >>>> It does not matter what happens after that point. >>>> It does not matter what happens after that point. >>>> It does not matter what happens after that point. >>>> >>>> If you know that an animal is a cat by testing its DNA then you know >>>> that it is a cat even if this cat barks. >>>> >>>>> (2) When we run P(P), the H at the beginning of the topmost P is >>>>> *not* being simulated. It starts simulating its input and at some >>>>> point it suspends its simulation. >>>>> >>>>> In the first case, you conclude that the input to H is non-halting >>>>> based on the fact that it has been suspended, but you acknowledge >>>>> that H halts. >>>>> >>>> >>>> This is where you <are> dumber than a box of rocks. >>>> This is where you <are> dumber than a box of rocks. >>>> This is where you <are> dumber than a box of rocks. >>>> >>>> It is not that H made some arbitrary decision to suspend its input and >>>> we are relying on this arbitrary decision. >>> >>> Nowhere above do I claim the decision is arbitrary, nor is that relevant >>> to the point I am making. >>> >>>> It is the logical necessity that unless H suspends its input the >>>> simulation of its input is necessarily infinite thus conclusively >>>> proving beyond all possible doubt that P(P) <is> a computation that >>>> never halts. >>>> >>>>> In the second case, you conclude that the input the the H at the >>>>> beginning of the topmost P is non-halting based on the fact that it >>>>> has been suspended, but you somehow also conclude that the topmost P >>>>> does not halt. >>>>> >>>>> How can you claim that the topmost H halts in (1), but that the >>>>> topmost P doesn't halt in (2). These are identical in all respects. >>>>> Either your argument that P(P) doesn't halt is invalid, or your >>>>> reasoning also entails that H(P, P) does not halt (which would >>>>> violate the claim that H is a decider). Which is it? >>>>> >>>>> André >>>>> >>>> >>>> When H can monitor all of the behavior of P(P) H immediately aborts P >>>> before ever returning any value to P. When P has sneaky behavior >>>> behind the back of H, H cannot immediately terminate P. Drug dealers >>>> can get away with bad things until the cops are watching. When the >>>> cops are watching the behavior of the drug dealer is aborted. >>> >>> >>> You seem to be entirely ignoring my question. Do you claim that H(P, P) >>> halts? >>> >> I claim that H(P,P) always correctly decides that its input never halts. >> This remains true no matter what happens after H(P,P) is correctly decided. > > According to GUA https://groups.google.com/g/comp.theory/c/65ZaXe9Sabk, H tries > to decide the (dynamic) property of P that P can defy, thus, H is undecidable. > > Your H is a false teller. When-so-ever any yes/no question lacks a correct yes/no answer this question is incorrect. When-so-ever a TM/input pair to a decision problem lacks a correct Boolean return value the TM/input pair is incorrect. > > -- > Copyright 2021 WIJ > "If I can see further it is by standing on top of the tower of dwarfs." > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-14 15:52 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <8Nidndv-pbwO03L9nZ2dnUU7-RXNnZ2d@giganews.com> |
| In reply to | #3074 |
On 7/13/2021 11:23 PM, Richard Damon wrote: > On 7/13/21 9:02 AM, olcott wrote: >> On 7/13/2021 9:54 AM, wij wrote: >>> On Tuesday, 13 July 2021 at 22:42:59 UTC+8, olcott wrote: >>>> On 7/13/2021 8:57 AM, André G. Isaak wrote: >>>>> On 2021-07-13 07:41, olcott wrote: >>>>>> On 7/12/2021 7:00 PM, André G. Isaak wrote: >>>>>>> On 2021-07-12 16:18, olcott wrote: >>>>>>>> On 7/12/2021 1:39 PM, André G. Isaak wrote: >>>>>>>>> On 2021-07-12 11:35, olcott wrote: >>>>>>>>>> On 7/12/2021 10:20 AM, André G. Isaak wrote: >>>>>>>>>>> On 2021-07-12 08:13, olcott wrote: >>>>>>>>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote: >>>>>>>>>>>>> On 7/11/21 9:30 AM, olcott wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> According to this criteria P(P) specifies a computation that >>>>>>>>>>>>>> never halts. >>>>>>>>>>>>> >>>>>>>>>>>>> Which since even YOU have shown that if H does give the >>>>>>>>>>>>> answer of >>>>>>>>>>>>> Non-Halting, that P(P) will halt when run as an independent >>>>>>>>>>>>> machine, so >>>>>>>>>>>>> the logic must be wrong. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It does not halt it has its execution suspended. >>>>>>>>>>>> If its execution was not suspended it would never halt. >>>>>>>>>>> >>>>>>>>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask whether >>>>>>>>>>> P(P) halts we're not asking about the input to P(P). We're asking >>>>>>>>>>> about P(P) proper. >>>>>>>>>> >>>>>>>>>> *You must be dumber than a box of rocks* >>>>>>>>>> Do you know know that when any function call (of infinite >>>>>>>>>> recursion) from the first to the trillionth is aborted that even >>>>>>>>>> though this infinite recursion stops running IT IS STILL INFINITE >>>>>>>>>> RECURSION !!! >>>>>>>>> >>>>>>>>> >>>>>>>>> By that "reasoning" (using the term very loosely), when you run >>>>>>>>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not >>>>>>>>> only entails that Infinite_Recursion (the thing being simulating) >>>>>>>>> is non-halting, but also that H (the simulator) is non-halting. >>>>>>>>> >>>>>>>> >>>>>>>> I prove that this is not true by actually showing the steps of >>>>>>>> infinite recursion being decided: >>>>>>>> >>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Remember that a decider, *by definition* must be guaranteed to halt >>>>>>>>> and return a result. >>>>>>>>> >>>>>>>> >>>>>>>> I am not dumber than a box of rocks so I already know this. >>>>>>> >>>>>>> You seem to be entirely missing my point. >>>>>>> >>>>>>> Compare the following: >>>>>>> >>>>>>> (1) When we run H(P, P), the topmost H is *not* being simulated. It >>>>>>> starts simulating its input, and at some point it suspends that >>>>>>> simulation. >>>>>>> >>>>>> >>>>>> The fact that it must suspend the simulation at one point because the >>>>>> simulation <is> infinite proves beyond all possible doubt that the >>>>>> halt decider was correct at that point. >>>>>> >>>>>> It does not matter what happens after that point. >>>>>> It does not matter what happens after that point. >>>>>> It does not matter what happens after that point. >>>>>> >>>>>> If you know that an animal is a cat by testing its DNA then you know >>>>>> that it is a cat even if this cat barks. >>>>>> >>>>>>> (2) When we run P(P), the H at the beginning of the topmost P is >>>>>>> *not* being simulated. It starts simulating its input and at some >>>>>>> point it suspends its simulation. >>>>>>> >>>>>>> In the first case, you conclude that the input to H is non-halting >>>>>>> based on the fact that it has been suspended, but you acknowledge >>>>>>> that H halts. >>>>>>> >>>>>> >>>>>> This is where you <are> dumber than a box of rocks. >>>>>> This is where you <are> dumber than a box of rocks. >>>>>> This is where you <are> dumber than a box of rocks. >>>>>> >>>>>> It is not that H made some arbitrary decision to suspend its input and >>>>>> we are relying on this arbitrary decision. >>>>> >>>>> Nowhere above do I claim the decision is arbitrary, nor is that >>>>> relevant >>>>> to the point I am making. >>>>> >>>>>> It is the logical necessity that unless H suspends its input the >>>>>> simulation of its input is necessarily infinite thus conclusively >>>>>> proving beyond all possible doubt that P(P) <is> a computation that >>>>>> never halts. >>>>>> >>>>>>> In the second case, you conclude that the input the the H at the >>>>>>> beginning of the topmost P is non-halting based on the fact that it >>>>>>> has been suspended, but you somehow also conclude that the topmost P >>>>>>> does not halt. >>>>>>> >>>>>>> How can you claim that the topmost H halts in (1), but that the >>>>>>> topmost P doesn't halt in (2). These are identical in all respects. >>>>>>> Either your argument that P(P) doesn't halt is invalid, or your >>>>>>> reasoning also entails that H(P, P) does not halt (which would >>>>>>> violate the claim that H is a decider). Which is it? >>>>>>> >>>>>>> André >>>>>>> >>>>>> >>>>>> When H can monitor all of the behavior of P(P) H immediately aborts P >>>>>> before ever returning any value to P. When P has sneaky behavior >>>>>> behind the back of H, H cannot immediately terminate P. Drug dealers >>>>>> can get away with bad things until the cops are watching. When the >>>>>> cops are watching the behavior of the drug dealer is aborted. >>>>> >>>>> >>>>> You seem to be entirely ignoring my question. Do you claim that H(P, P) >>>>> halts? >>>>> >>>> I claim that H(P,P) always correctly decides that its input never halts. >>>> This remains true no matter what happens after H(P,P) is correctly >>>> decided. >>> >>> According to GUA >>> https://groups.google.com/g/comp.theory/c/65ZaXe9Sabk, H tries >>> to decide the (dynamic) property of P that P can defy, thus, H is >>> undecidable. >>> >>> Your H is a false teller. >> >> When-so-ever any yes/no question lacks a correct yes/no answer this >> question is incorrect. > > SO that means your question about what H needs to return is incorrect. > > Note, the Question of the Halting Problem is does P(I) reach its halt > state in a finite number of steps, which given your H, then for P and I > being the machine H^ as defined by Linz, their IS a definite answer: YES. > > H just doesn't give that answer, so is wrong. The question of the halting problem is exactly like the question: Have you stopped beating your wife? The context matters. When you ask a guy that has never been married the question is incorrect because both yes and no are the wrong answer. When you ask a guy that is married and has beaten his wife then exactly one of yes or no is the correct answer. When you ask whether or not a program halts on its input and you are asking what Boolean value can a TM correctly return to its input when its input does the opposite of whatever value the TM returns, this is an incorrect question when all of the context of the question is considered because both Boolean values are the wrong return value. We are not asking whether or not the input halts on its input that question always has a correct answer for every TM / input pair. We are asking which Boolean value can H return to P is the correct halt status of P? false is wrong, true is wrong thus the question is wrong. >> >> When-so-ever a TM/input pair to a decision problem lacks a correct >> Boolean return value the TM/input pair is incorrect. > > SO actually DEFINE your TM, the problem is you question isn't really > about a TM/input pair, but about the design of a TM, so you 'impossible' > answer just says that such a TM doesn't exist, so PROVES the theory you > are trying to refute. > > > FAIL. > >> >> >> >>> >>> -- >>> Copyright 2021 WIJ >>> "If I can see further it is by standing on top of the tower of dwarfs." >>> >> >> > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-14 16:47 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <eJSdnVmyGIQexnL9nZ2dnUU7-bfNnZ2d@giganews.com> |
| In reply to | #3097 |
On 7/14/2021 4:09 PM, Andy Walker wrote: > On 14/07/2021 21:52, olcott wrote: > [...] >> We are not asking whether or not the input halts on its input that >> question always has a correct answer for every TM / input pair. >> We are asking which Boolean value can H return to P is the correct >> halt status of P? false is wrong, true is wrong thus the question is >> wrong. > > So near and yet so far! /You/ are asking the second question, > the rest of us are asking the first. > When the halting problem is applied to a TM/input such that the TM must return a halt status value to an input that does the opposite of whatever it decides both true and false are incorrect return values thus proving the error in this precise context of the halting problem. Woefully dishonest people continually ignore this key context. When we ask a man that has never been married: Have you stopped beating your wife? the context (that he has never been married) makes the question itself incorrect. It is the same context (that the input P does the opposite of whatever H decides) that makes the halting problem question incorrect in this case. My H does provide the correct answer because it essentially tells its input P to shut the Hell up by aborting its whole process. https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-14 22:12 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <ZKGdnXf__7kEOnL9nZ2dnUU7-cXNnZ2d@giganews.com> |
| In reply to | #3097 |
On 7/14/2021 9:57 PM, Richard Damon wrote: > On 7/14/21 2:52 PM, olcott wrote: >> On 7/13/2021 11:23 PM, Richard Damon wrote: >>> On 7/13/21 9:02 AM, olcott wrote: >>>> On 7/13/2021 9:54 AM, wij wrote: >>>>> On Tuesday, 13 July 2021 at 22:42:59 UTC+8, olcott wrote: >>>>>> On 7/13/2021 8:57 AM, André G. Isaak wrote: >>>>>>> On 2021-07-13 07:41, olcott wrote: >>>>>>>> On 7/12/2021 7:00 PM, André G. Isaak wrote: >>>>>>>>> On 2021-07-12 16:18, olcott wrote: >>>>>>>>>> On 7/12/2021 1:39 PM, André G. Isaak wrote: >>>>>>>>>>> On 2021-07-12 11:35, olcott wrote: >>>>>>>>>>>> On 7/12/2021 10:20 AM, André G. Isaak wrote: >>>>>>>>>>>>> On 2021-07-12 08:13, olcott wrote: >>>>>>>>>>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote: >>>>>>>>>>>>>>> On 7/11/21 9:30 AM, olcott wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> According to this criteria P(P) specifies a computation that >>>>>>>>>>>>>>>> never halts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Which since even YOU have shown that if H does give the >>>>>>>>>>>>>>> answer of >>>>>>>>>>>>>>> Non-Halting, that P(P) will halt when run as an independent >>>>>>>>>>>>>>> machine, so >>>>>>>>>>>>>>> the logic must be wrong. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It does not halt it has its execution suspended. >>>>>>>>>>>>>> If its execution was not suspended it would never halt. >>>>>>>>>>>>> >>>>>>>>>>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask >>>>>>>>>>>>> whether >>>>>>>>>>>>> P(P) halts we're not asking about the input to P(P). We're >>>>>>>>>>>>> asking >>>>>>>>>>>>> about P(P) proper. >>>>>>>>>>>> >>>>>>>>>>>> *You must be dumber than a box of rocks* >>>>>>>>>>>> Do you know know that when any function call (of infinite >>>>>>>>>>>> recursion) from the first to the trillionth is aborted that even >>>>>>>>>>>> though this infinite recursion stops running IT IS STILL >>>>>>>>>>>> INFINITE >>>>>>>>>>>> RECURSION !!! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> By that "reasoning" (using the term very loosely), when you run >>>>>>>>>>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not >>>>>>>>>>> only entails that Infinite_Recursion (the thing being simulating) >>>>>>>>>>> is non-halting, but also that H (the simulator) is non-halting. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I prove that this is not true by actually showing the steps of >>>>>>>>>> infinite recursion being decided: >>>>>>>>>> >>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Remember that a decider, *by definition* must be guaranteed to >>>>>>>>>>> halt >>>>>>>>>>> and return a result. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am not dumber than a box of rocks so I already know this. >>>>>>>>> >>>>>>>>> You seem to be entirely missing my point. >>>>>>>>> >>>>>>>>> Compare the following: >>>>>>>>> >>>>>>>>> (1) When we run H(P, P), the topmost H is *not* being simulated. It >>>>>>>>> starts simulating its input, and at some point it suspends that >>>>>>>>> simulation. >>>>>>>>> >>>>>>>> >>>>>>>> The fact that it must suspend the simulation at one point because >>>>>>>> the >>>>>>>> simulation <is> infinite proves beyond all possible doubt that the >>>>>>>> halt decider was correct at that point. >>>>>>>> >>>>>>>> It does not matter what happens after that point. >>>>>>>> It does not matter what happens after that point. >>>>>>>> It does not matter what happens after that point. >>>>>>>> >>>>>>>> If you know that an animal is a cat by testing its DNA then you know >>>>>>>> that it is a cat even if this cat barks. >>>>>>>> >>>>>>>>> (2) When we run P(P), the H at the beginning of the topmost P is >>>>>>>>> *not* being simulated. It starts simulating its input and at some >>>>>>>>> point it suspends its simulation. >>>>>>>>> >>>>>>>>> In the first case, you conclude that the input to H is non-halting >>>>>>>>> based on the fact that it has been suspended, but you acknowledge >>>>>>>>> that H halts. >>>>>>>>> >>>>>>>> >>>>>>>> This is where you <are> dumber than a box of rocks. >>>>>>>> This is where you <are> dumber than a box of rocks. >>>>>>>> This is where you <are> dumber than a box of rocks. >>>>>>>> >>>>>>>> It is not that H made some arbitrary decision to suspend its >>>>>>>> input and >>>>>>>> we are relying on this arbitrary decision. >>>>>>> >>>>>>> Nowhere above do I claim the decision is arbitrary, nor is that >>>>>>> relevant >>>>>>> to the point I am making. >>>>>>> >>>>>>>> It is the logical necessity that unless H suspends its input the >>>>>>>> simulation of its input is necessarily infinite thus conclusively >>>>>>>> proving beyond all possible doubt that P(P) <is> a computation that >>>>>>>> never halts. >>>>>>>> >>>>>>>>> In the second case, you conclude that the input the the H at the >>>>>>>>> beginning of the topmost P is non-halting based on the fact that it >>>>>>>>> has been suspended, but you somehow also conclude that the >>>>>>>>> topmost P >>>>>>>>> does not halt. >>>>>>>>> >>>>>>>>> How can you claim that the topmost H halts in (1), but that the >>>>>>>>> topmost P doesn't halt in (2). These are identical in all respects. >>>>>>>>> Either your argument that P(P) doesn't halt is invalid, or your >>>>>>>>> reasoning also entails that H(P, P) does not halt (which would >>>>>>>>> violate the claim that H is a decider). Which is it? >>>>>>>>> >>>>>>>>> André >>>>>>>>> >>>>>>>> >>>>>>>> When H can monitor all of the behavior of P(P) H immediately >>>>>>>> aborts P >>>>>>>> before ever returning any value to P. When P has sneaky behavior >>>>>>>> behind the back of H, H cannot immediately terminate P. Drug dealers >>>>>>>> can get away with bad things until the cops are watching. When the >>>>>>>> cops are watching the behavior of the drug dealer is aborted. >>>>>>> >>>>>>> >>>>>>> You seem to be entirely ignoring my question. Do you claim that >>>>>>> H(P, P) >>>>>>> halts? >>>>>>> >>>>>> I claim that H(P,P) always correctly decides that its input never >>>>>> halts. >>>>>> This remains true no matter what happens after H(P,P) is correctly >>>>>> decided. >>>>> >>>>> According to GUA >>>>> https://groups.google.com/g/comp.theory/c/65ZaXe9Sabk, H tries >>>>> to decide the (dynamic) property of P that P can defy, thus, H is >>>>> undecidable. >>>>> >>>>> Your H is a false teller. >>>> >>>> When-so-ever any yes/no question lacks a correct yes/no answer this >>>> question is incorrect. >>> >>> SO that means your question about what H needs to return is incorrect. >>> >>> Note, the Question of the Halting Problem is does P(I) reach its halt >>> state in a finite number of steps, which given your H, then for P and I >>> being the machine H^ as defined by Linz, their IS a definite answer: YES. >>> >>> H just doesn't give that answer, so is wrong. >> >> The question of the halting problem is exactly like the question: >> Have you stopped beating your wife? > > Well Have you? > > And actually, it isn't. > > The REAL question of the Halting Problem is "Does the Turing Machine P > given input I come to a halting state in a finite number of steps, or not?" > When you provide the context of a TM/input pair then the brand new idea that I created "incorrect question" is formed: When-so-ever a yes/no question has no correct answer from the set of yes/no or a decision problem TM/input pair has has no final state indicting a correct Boolean value then it is an error. Undecidability has always only been an error. It is not that the correct true/false value cannot be chosen by the TM. It is that both true/false values are the wrong answer. In my case this issue is solved. H(P,P) always aborts its input never returning any value to its input. > THIS question ALWAYS has a correct answer, as it will ALWAYS be either > Yes it Halts, or No it never halts. >> >> The context matters. >> When you ask a guy that has never been married the question is incorrect >> because both yes and no are the wrong answer. > > So in what context does a Turing Machine neither Halt or Not-Halt? The > only case I can think of is if it isn't a Turing Machine, but the > question is only asked of Turing Machines. > > Yes, YOUR WRONG question can be a bit like that, >> >> When you ask a guy that is married and has beaten his wife then exactly >> one of yes or no is the correct answer. > > But this isn't the case. >> >> When you ask whether or not a program halts on its input and you are >> asking what Boolean value can a TM correctly return to its input when >> its input does the opposite of whatever value the TM returns, this is an >> incorrect question when all of the context of the question is considered >> because both Boolean values are the wrong return value. > > You have it wrong here. There IS a right answer to the question of P(I) > halting. H can never give that answer, in part because H has to be fixed > before H^ (which you are calling P) is created. There is NO > contradiction here, H is just wrong. There is NO rule that you can quote > to say that there has to be an H that can get this problem right. NONE. > > That is the flaw in your argument, you PRESUME that there exists a > machine that can universally answer the Question of the Halting Problem, > when there actually is none. > >> >> We are not asking whether or not the input halts on its input that >> question always has a correct answer for every TM / input pair. > > And why not, that IS the Question of the Halting Problem? Which even > youy agree always has an answer. >> >> We are asking which Boolean value can H return to P is the correct halt >> status of P? false is wrong, true is wrong thus the question is wrong. > > And as said above, this is NOT the question of the Halting Problem. > > This is the question needed to be solved to DESIGN a Halting Decider > that can counter something like the Linz proof. Your proof that there is > no right answer just reconfirms Linz and the like, showing that it is > impossible to design an H that can correctly answer to the H^ machine > made from it. (I perfectly legal Turing Machine Transform). > > And this gets back to the one exception to the rule that all Turing > Machine have a definite answer that the Halt or they are Non-Halting, if > H doesn't exist, then neither does H^, so H^(H^) isn't a Turing Machine > and doesn't need to Halt or not. > > > FAIR WARNING. > > You have made this same arguement many times, and totally ignore the > responses that show you are wrong. > > If you fail to actually provide a REAL SOUND ANALYTICAL argument showing > an error in this rebuttal, I reserve the right to just refer to this > message to indicate that you arguement has been disproven and anythig > that follows from it is thus an unsound argument. > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-15 09:17 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <i4SdndRj-7MT3m39nZ2dnUU7-QXNnZ2d@giganews.com> |
| In reply to | #3101 |
On 7/15/2021 3:44 AM, Malcolm McLean wrote: > On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote: >> On 7/14/2021 9:57 PM, Richard Damon wrote: >> >> When you provide the context of a TM/input pair then the brand new idea >> that I created "incorrect question" is formed: >> >> When-so-ever a yes/no question has no correct answer from the set of >> yes/no or a decision problem TM/input pair has has no final state >> indicting a correct Boolean value then it is an error. >> >> Undecidability has always only been an error. >> It is not that the correct true/false value cannot be chosen by the TM. >> It is that both true/false values are the wrong answer. >> > H_Hat is constructed after H. Both H and P are static machine-code in a COFF object file. > There's always a right answer - When the question is what Boolean value can H correctly return to an input that does the opposite of what H decides it is as obvious as Hell that there is no correct answer to this specific question. When you change the question to: Does H P halt on its input you are not answering the actual question with its full context. > H_Hat(H_Hat) either halts or it does not. But H always gets that answer > wrong. Because the full context of the question proves that no Boolean value returned by H to an input that does the opposite of whatever H decides is a correct answer. When-so-ever zero elements of the solution set are a correct answer then the question itself is incorrect. >> >> In my case this issue is solved. H(P,P) always aborts its input never >> returning any value to its input. >> > We seem to be going back to the "abort rather than return control" and > maybe "the operating system contains a halt decider" ideas. > No H has ever returned any value to its input. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-15 19:42 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <I6adnY5HUo6SS239nZ2dnUU7-c3NnZ2d@giganews.com> |
| In reply to | #3102 |
On 7/15/2021 6:54 PM, dklei...@gmail.com wrote: >> David Kleineke will agree that the context is crucial: >> He disagreed with Frege's principle of compositionality specifically >> because it ignores context. https://iep.utm.edu/composit/ >> David and I have spoke very much on sci.lang. > > I do reject the idea of compositionality that Frege advanced because it > ignores context. But this is a natural language problem. Mathematics, > unlike natural language, does not use the idea of context. The argument > that has been going on in comp.theory is about neither natural language > nor mathematics. To supply a name I call it "logic". And I deplore it. > > I want clear definitions and proof steps. I admit I don't like the current > popular definitions of Turing Machines and would start by re-defining > them. I am curious how a higher language could be said to be > equivalent to a Turing Machine. > CONTEXT MATTERS: If you ask a man: Are you president of the United States? Only Joe Biden can say yes and not be a God damned liar. Who you ask determines the correct answer to many questions. When a program H is defined such that its input P does the opposite of whatever halt status that H decides for this input P both values of true(halts) and false(never halts) are the wrong answer. This is exactly like the liar paradox in that because both Boolean values are contradicted neither Boolean value is correct. Flibble is the only one that has understood this in the 17 years since I first pointed it out. You ask someone (we'll call him "Jack") to give a truthful yes/no answer to the following question: Will Jack's answer to this question be no? Jack can't possibly give a correct yes/no answer to the question. (Daryl McCullough Jun 25, 2004, 6:30:39 PM) https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ Everyone else can possibly give a correct answer to that question because when context is considered it becomes a different question for them. Does X halt on its input P? Has classically been understood to lack a correct Boolean return value from some software functions in (function / input) pair. This has been classically presented as proof that the halting problem is undecidable, as if the function is unable to choose between true and false. The actual case is that both true and false are incorrect return values for this (function / input) pair. This rigged game does not count. My partial decider correctly decides even this rigged game. H aborts the simulation of its input P before any simulated H ever returns any value to P. H is basically telling lying cheating P to STFU. https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-15 19:52 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <ub2dnZT5z7agRW39nZ2dnUU7-SfNnZ2d@giganews.com> |
| In reply to | #3102 |
On 7/15/2021 7:17 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 7/15/2021 3:04 PM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote: >>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote: >>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote: >>>>>> >>>>>> When you provide the context of a TM/input pair then the brand new idea >>>>>> that I created "incorrect question" is formed: >>>>>> >>>>>> When-so-ever a yes/no question has no correct answer from the set of >>>>>> yes/no or a decision problem TM/input pair has has no final state >>>>>> indicting a correct Boolean value then it is an error. >>>>>> >>>>>> Undecidability has always only been an error. >>>>>> It is not that the correct true/false value cannot be chosen by the TM. >>>>>> It is that both true/false values are the wrong answer. >>>>>> >>>>> H_Hat is constructed after H. >>> >>>>> There's always a right answer - >>>> >>>> When the question is what Boolean value can H correctly return to an >>>> input that does the opposite of what H decides it is as obvious as >>>> Hell that there is no correct answer to this specific question. >>> >>> That's your question. It's not the halting problem "question". You >> >> You are a God damned liar. > > Don't be so dramatic! You really should know what the halting problem > is about by now. Did you not understand any of the definitions you've > read? What about Sipser's? Did you understand his definition? > >>>> When you change the question to: Does H P halt on its input you are >>>> not answering the actual question with its full context. >>> >>> You are, instead, asking the halting problem "question". This is a >>> question that always has a correct yes/no answer, thought algorithm can >>> determine which in every case. >>> >> >> Like the God damned liar that you have always been you stick with your >> God damned lies. > > Oh don't be such a drama queen! I am simply defining the halting > problem, and you are denying the basic facts of the matter, just as you > have been doing for years. > >> Please quit being a God damned liar. > > Did Sipser lie when he defined the halting problem as I do? Did Linz? > What about Church, Kleene, Davis, Moore and all the others? Were they > lying too? You really need to get over yourself. > You are a God damned liar when you insist that the context of the question is not an intrinsic aspect of the question itself: David Kleineke knows that the context of a question is a crucial and intrinsic aspect of the question and that an otherwise identically worded question is a different question in different contexts. When a program H is defined such that its input P does the opposite of whatever halt status that H decides for this input P both values of true(halts) and false(never halts) are the wrong answer. This is not the same freaking question as: Does program P halt on its input I? This is exactly like the liar paradox in that because both Boolean values are contradicted neither Boolean value is correct. Flibble is the only one that has understood this in the 17 years since I first pointed it out. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-15 22:03 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) |
| Message-ID | <h_mdnS8SrMGPam39nZ2dnUU7-IXNnZ2d@giganews.com> |
| In reply to | #3116 |
On 7/15/2021 9:09 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/15/2021 7:17 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/15/2021 3:04 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote:
>>>>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>>>>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> When you provide the context of a TM/input pair then the brand new idea
>>>>>>>> that I created "incorrect question" is formed:
>>>>>>>>
>>>>>>>> When-so-ever a yes/no question has no correct answer from the set of
>>>>>>>> yes/no or a decision problem TM/input pair has has no final state
>>>>>>>> indicting a correct Boolean value then it is an error.
>>>>>>>>
>>>>>>>> Undecidability has always only been an error.
>>>>>>>> It is not that the correct true/false value cannot be chosen by the TM.
>>>>>>>> It is that both true/false values are the wrong answer.
>>>>>>>>
>>>>>>> H_Hat is constructed after H.
>>>>>
>>>>>>> There's always a right answer -
>>>>>>
>>>>>> When the question is what Boolean value can H correctly return to an
>>>>>> input that does the opposite of what H decides it is as obvious as
>>>>>> Hell that there is no correct answer to this specific question.
>>>>>
>>>>> That's your question. It's not the halting problem "question". You
>>>>
>>>> You are a God damned liar.
>>> Don't be so dramatic! You really should know what the halting problem
>>> is about by now. Did you not understand any of the definitions you've
>>> read? What about Sipser's? Did you understand his definition?
>>>
>>>>>> When you change the question to: Does H P halt on its input you are
>>>>>> not answering the actual question with its full context.
>>>>>
>>>>> You are, instead, asking the halting problem "question". This is a
>>>>> question that always has a correct yes/no answer, thought algorithm can
>>>>> determine which in every case.
>>>>>
>>>>
>>>> Like the God damned liar that you have always been you stick with your
>>>> God damned lies.
>>>
>>> Oh don't be such a drama queen! I am simply defining the halting
>>> problem, and you are denying the basic facts of the matter, just as you
>>> have been doing for years.
>>>
>>>> Please quit being a God damned liar.
>>>
>>> Did Sipser lie when he defined the halting problem as I do? Did Linz?
>>> What about Church, Kleene, Davis, Moore and all the others? Were they
>>> lying too? You really need to get over yourself.
>>
>> You are a God damned liar when you insist that the context of the
>> question is not an intrinsic aspect of the question itself:
>
> The context is clear. There is a set of strings
>
> { <M, w> | M is a TM and H halts on input w }
>
> (I'm using Siper here.) The problem is whether this set is decidable.
> Is he lying? No. Like everyone but you, he clearly states the problem
> with all the context needed to understand it.
>
>> When a program H is defined such that its input P does the opposite of
>> whatever halt status that H decides for this input P both values of
>> true(halts) and false(never halts) are the wrong answer.
>>
>> This is not the same freaking question as:
>> Does program P halt on its input I?
>
> I am glad we agree. Since we both agree there are two separate
> questions, do you have anything at all to say about the second one? I'd
Does program P halting on input I?
Is a correct question for some H and an incorrect question for H that is
defined such that its input does the opposite of whatever it decides.
If we ask Donald Trump:
Are you the president of the United States?
He will lie and say yes.
If we ask Joe Biden:
Are you the president of the United States?
He provide the same answer to the same question except this time it is
true.
Context <is> part of the question. David Kleineke will back me up on
this. We spoke quite extensively on sci.lang, (the linguistics forum)
for several years.
> really like to hear you to say that you are not considering the question
> "Does program P halt on its input I?" but you are, instead, considering
> the first one -- the one that is somewhat like the liar.
>
>> This is exactly like the liar paradox in that because both Boolean
>> values are contradicted neither Boolean value is correct.
>
> Not for the second question which is the halting problem. There is
> always a correct answer for the question "Does program P halt on its
> input I?". Are you willing to say that this is not the question you
> have been considering for the last 16 years?
>
Every TM either halts on its input or fails to halt on its input.
Now that I understand these things at a much deeper level I can commit
to that.
>> Flibble is the only one that has understood this in the 17 years since
>> I first pointed it out.
>
> You know he's a crank too, yes?
>
Until he explained why he agreed with me I had simply thought that he
was totally clueless about the halting problem:
On 7/10/2021 12:00 PM, Mr Flibble wrote:
> I agree with Olcott that a halt decider can NOT be part of that which
> is being decided (see [Strachey 1965]) which, if Olcott is correct,
> falsifies a collection of proofs (which I don't have the time to
> examine) which rely on that mistake.
>
> /Flibble
>
The above proves to me that he fully understands the essence of the
pathological self-reference(Olcott 2004) error:
On Sunday, September 5, 2004 at 11:21:57 AM UTC-5, Peter Olcott wrote:
> The Liar Paradox can be shown to be nothing more than
> a incorrectly formed statement because of its pathological
> self-reference. The Halting Problem can only exist because
> of this same sort of pathological self-reference.
You can simply write him off as a crank and gullible fools will believe
that to be a sufficient rebuttal. That his reasoning specifically
matches my reasoning can only be written off by damned liars.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-16 21:48 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) |
| Message-ID | <IJGdnTat_8KK2G_9nZ2dnUU7-c_NnZ2d@giganews.com> |
| In reply to | #3119 |
On 7/16/2021 7:43 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/15/2021 9:09 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/15/2021 7:17 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/15/2021 3:04 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote:
>>>>>>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>>>>>>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> When you provide the context of a TM/input pair then the brand new idea
>>>>>>>>>> that I created "incorrect question" is formed:
>>>>>>>>>>
>>>>>>>>>> When-so-ever a yes/no question has no correct answer from the set of
>>>>>>>>>> yes/no or a decision problem TM/input pair has has no final state
>>>>>>>>>> indicting a correct Boolean value then it is an error.
>>>>>>>>>>
>>>>>>>>>> Undecidability has always only been an error.
>>>>>>>>>> It is not that the correct true/false value cannot be chosen by the TM.
>>>>>>>>>> It is that both true/false values are the wrong answer.
>>>>>>>>>>
>>>>>>>>> H_Hat is constructed after H.
>>>>>>>
>>>>>>>>> There's always a right answer -
>>>>>>>>
>>>>>>>> When the question is what Boolean value can H correctly return to an
>>>>>>>> input that does the opposite of what H decides it is as obvious as
>>>>>>>> Hell that there is no correct answer to this specific question.
>>>>>>>
>>>>>>> That's your question. It's not the halting problem "question". You
>>>>>>
>>>>>> You are a God damned liar.
>>>>> Don't be so dramatic! You really should know what the halting problem
>>>>> is about by now. Did you not understand any of the definitions you've
>>>>> read? What about Sipser's? Did you understand his definition?
>>>>>
>>>>>>>> When you change the question to: Does H P halt on its input you are
>>>>>>>> not answering the actual question with its full context.
>>>>>>>
>>>>>>> You are, instead, asking the halting problem "question". This is a
>>>>>>> question that always has a correct yes/no answer, thought algorithm can
>>>>>>> determine which in every case.
>>>>>>>
>>>>>>
>>>>>> Like the God damned liar that you have always been you stick with your
>>>>>> God damned lies.
>>>>>
>>>>> Oh don't be such a drama queen! I am simply defining the halting
>>>>> problem, and you are denying the basic facts of the matter, just as you
>>>>> have been doing for years.
>>>>>
>>>>>> Please quit being a God damned liar.
>>>>>
>>>>> Did Sipser lie when he defined the halting problem as I do? Did Linz?
>>>>> What about Church, Kleene, Davis, Moore and all the others? Were they
>>>>> lying too? You really need to get over yourself.
>>>>
>>>> You are a God damned liar when you insist that the context of the
>>>> question is not an intrinsic aspect of the question itself:
>>> The context is clear. There is a set of strings
>>> { <M, w> | M is a TM and H halts on input w }
>>> (I'm using Siper here.) The problem is whether this set is decidable.
>>> Is he lying? No. Like everyone but you, he clearly states the problem
>>> with all the context needed to understand it.
>>>
>>>> When a program H is defined such that its input P does the opposite of
>>>> whatever halt status that H decides for this input P both values of
>>>> true(halts) and false(never halts) are the wrong answer.
>>>>
>>>> This is not the same freaking question as:
>>>> Does program P halt on its input I?
>>>
>>> I am glad we agree. Since we both agree there are two separate
>>> questions, do you have anything at all to say about the second one? I'd
>>
>> Does program P halting on input I?
>> Is a correct question for some H and an incorrect question for H that
>> is defined such that its input does the opposite of whatever it
>> decides.
>
> The second question: "Does program P halt on input I?" is the halting
> problem. The "incorrect question for" junk is your other question --
> the one you say, and I agree, is "not the same freaking question".
>
>> If we ask Donald Trump:
>> Are you the president of the United States?
>> He will lie and say yes.
>
> The halting problem is "Does program P halt on input I?". The correct
> answer is not defined or constrained by who or what we ask. The correct
> answer simply "yes" if, an only if, P(I) halts.
Everyone the understands the science of language fully knows that who is
being asked a question is an intrinsic aspect of the semantic meaning of
this question. I have spoken with David Kleinke on the linguistics forum
about natural language semantics for many years.
You ask someone (we'll call him "Jack") to give a truthful
yes/no answer to the following question:
Will Jack's answer to this question be no?
Jack can't possibly give a correct yes/no answer to the question.
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
That a question has no correct answer when we ask Jack and the exact
same worded question does have a correct answer when we ask someone
besides Jack conclusively proves beyond all possible doubt that it is
not the same question even though it has identical words.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.
> If you are not addressing the halting problem, fine. But if you are,
> your H which has H(P,P) == 0 (AKA "no") when P(P) halts is simply wrong.
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-19 10:11 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) |
| Message-ID | <CLWdnetcAdqgC2j9nZ2dnUU7-R2dnZ2d@giganews.com> |
| In reply to | #3144 |
On 7/17/2021 8:27 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/16/2021 7:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/15/2021 9:09 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/15/2021 7:17 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/15/2021 3:04 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>>>>>>>>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> When you provide the context of a TM/input pair then the brand new idea
>>>>>>>>>>>> that I created "incorrect question" is formed:
>>>>>>>>>>>>
>>>>>>>>>>>> When-so-ever a yes/no question has no correct answer from the set of
>>>>>>>>>>>> yes/no or a decision problem TM/input pair has has no final state
>>>>>>>>>>>> indicting a correct Boolean value then it is an error.
>>>>>>>>>>>>
>>>>>>>>>>>> Undecidability has always only been an error.
>>>>>>>>>>>> It is not that the correct true/false value cannot be chosen by the TM.
>>>>>>>>>>>> It is that both true/false values are the wrong answer.
>>>>>>>>>>>>
>>>>>>>>>>> H_Hat is constructed after H.
>>>>>>>>>
>>>>>>>>>>> There's always a right answer -
>>>>>>>>>>
>>>>>>>>>> When the question is what Boolean value can H correctly return to an
>>>>>>>>>> input that does the opposite of what H decides it is as obvious as
>>>>>>>>>> Hell that there is no correct answer to this specific question.
>>>>>>>>>
>>>>>>>>> That's your question. It's not the halting problem "question". You
>>>>>>>>
>>>>>>>> You are a God damned liar.
>>>>>>> Don't be so dramatic! You really should know what the halting problem
>>>>>>> is about by now. Did you not understand any of the definitions you've
>>>>>>> read? What about Sipser's? Did you understand his definition?
>>>>>>>
>>>>>>>>>> When you change the question to: Does H P halt on its input you are
>>>>>>>>>> not answering the actual question with its full context.
>>>>>>>>>
>>>>>>>>> You are, instead, asking the halting problem "question". This is a
>>>>>>>>> question that always has a correct yes/no answer, thought algorithm can
>>>>>>>>> determine which in every case.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Like the God damned liar that you have always been you stick with your
>>>>>>>> God damned lies.
>>>>>>>
>>>>>>> Oh don't be such a drama queen! I am simply defining the halting
>>>>>>> problem, and you are denying the basic facts of the matter, just as you
>>>>>>> have been doing for years.
>>>>>>>
>>>>>>>> Please quit being a God damned liar.
>>>>>>>
>>>>>>> Did Sipser lie when he defined the halting problem as I do? Did Linz?
>>>>>>> What about Church, Kleene, Davis, Moore and all the others? Were they
>>>>>>> lying too? You really need to get over yourself.
>>>>>>
>>>>>> You are a God damned liar when you insist that the context of the
>>>>>> question is not an intrinsic aspect of the question itself:
>>>>> The context is clear. There is a set of strings
>>>>> { <M, w> | M is a TM and H halts on input w }
>>>>> (I'm using Siper here.) The problem is whether this set is decidable.
>>>>> Is he lying? No. Like everyone but you, he clearly states the problem
>>>>> with all the context needed to understand it.
>>>>>
>>>>>> When a program H is defined such that its input P does the opposite of
>>>>>> whatever halt status that H decides for this input P both values of
>>>>>> true(halts) and false(never halts) are the wrong answer.
>>>>>>
>>>>>> This is not the same freaking question as:
>>>>>> Does program P halt on its input I?
>>>>>
>>>>> I am glad we agree. Since we both agree there are two separate
>>>>> questions, do you have anything at all to say about the second one? I'd
>>>>
>>>> Does program P halting on input I?
>>>> Is a correct question for some H and an incorrect question for H that
>>>> is defined such that its input does the opposite of whatever it
>>>> decides.
>>> The second question: "Does program P halt on input I?" is the halting
>>> problem. The "incorrect question for" junk is your other question --
>>> the one you say, and I agree, is "not the same freaking question".
>>>
>>>> If we ask Donald Trump:
>>>> Are you the president of the United States?
>>>> He will lie and say yes.
>>>
>>> The halting problem is "Does program P halt on input I?". The correct
>>> answer is not defined or constrained by who or what we ask. The correct
>>> answer simply "yes" if, an only if, P(I) halts.
>>
>> Everyone the understands the science of language fully knows that who
>> is being asked a question is an intrinsic aspect of the semantic
>> meaning of this question.
>
> No. Whether P(I) is or is not a finite computation depends only on P
> and I. Whether you get the right answer depends on who or what you ask,
> but the correct answer is determined solely by the objects involved.
>
> P(P) halts (according to you). H(P, P) == 0 (according to you). That
> is wrong (according to everyone but you).
>
Pathological Input to a halt decider is defined as any input that was
defined to do the opposite of whatever its corresponding halt decider
decides.
This question can only be correctly answered after the pathology has
been removed. When a halt decider only acts as a pure simulator of its
input until after its halt status decision is made there is no feedback
loop of back channel communication between the halt decider and its
input that can prevent a correct halt status decision.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 10:33 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <7ZKdnUD6mMrCL3D9nZ2dnUU7-IudnZ2d@giganews.com> |
| In reply to | #3071 |
On 7/13/2021 10:08 AM, André G. Isaak wrote: > On 2021-07-13 08:42, olcott wrote: >> On 7/13/2021 8:57 AM, André G. Isaak wrote: > >>> You seem to be entirely ignoring my question. Do you claim that H(P, >>> P) halts? >>> >> >> I claim that H(P,P) always correctly decides that its input never halts. >> This remains true no matter what happens after H(P,P) is correctly >> decided. > > Once again, you are evading the question. > > Does H(P, P) halt? I am not asking what it decides. I am asking whether > it halts. > H(P,P) never halts. If H(P,P) ever stops running this is because its infinitely nested simulation has had its execution suspended. This does not count as halting. >>> If so, how can you claim that P(P), when run as an *independent* >>> computation, does not halt given that it performs the exact same steps >> >> When we test the DNA of a cat and find that it is definitely a cat and >> this cat later gives birth to purebred Chihuahua puppies we know for >> sure that it is definitely a cat. >> >>> as H(P, P)? Both start simulating what you describe as an 'infinitely >>> nested simulation' and both suspend that simulation at some point for >>> identical reasons. >>> >>> André >>> >> >> > > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 10:43 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <b6Cdncyk_NU4KXD9nZ2dnUU7-SmdnZ2d@giganews.com> |
| In reply to | #3075 |
On 7/13/2021 10:36 AM, André G. Isaak wrote: > On 2021-07-13 09:33, olcott wrote: >> On 7/13/2021 10:08 AM, André G. Isaak wrote: >>> On 2021-07-13 08:42, olcott wrote: >>>> On 7/13/2021 8:57 AM, André G. Isaak wrote: >>> >>>>> You seem to be entirely ignoring my question. Do you claim that >>>>> H(P, P) halts? >>>>> >>>> >>>> I claim that H(P,P) always correctly decides that its input never >>>> halts. >>>> This remains true no matter what happens after H(P,P) is correctly >>>> decided. >>> >>> Once again, you are evading the question. >>> >>> Does H(P, P) halt? I am not asking what it decides. I am asking >>> whether it halts. >>> >> >> H(P,P) never halts. If H(P,P) ever stops running this is because its >> infinitely nested simulation has had its execution suspended. This >> does not count as halting. > > > If H(P, P) never halts, then it cannot return an answer. That is an > admission that you don't have a decider at all. > > André > H forces its input to stop running so that H remains a decider. When H forces its input to stop running this does not make its input halt. Aborted simulations do not count as halting executions. I think that your behavior is dumber than a box of rocks only because you make sure to hardly pay any attention at all. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 17:21 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <FJKdnefzHr9sjHP9nZ2dnUU7-UXNnZ2d@giganews.com> |
| In reply to | #3077 |
On 7/13/2021 11:11 AM, André G. Isaak wrote: > On 2021-07-13 09:43, olcott wrote: >> On 7/13/2021 10:36 AM, André G. Isaak wrote: >>> On 2021-07-13 09:33, olcott wrote: >>>> On 7/13/2021 10:08 AM, André G. Isaak wrote: >>>>> On 2021-07-13 08:42, olcott wrote: >>>>>> On 7/13/2021 8:57 AM, André G. Isaak wrote: >>>>> >>>>>>> You seem to be entirely ignoring my question. Do you claim that >>>>>>> H(P, P) halts? >>>>>>> >>>>>> >>>>>> I claim that H(P,P) always correctly decides that its input never >>>>>> halts. >>>>>> This remains true no matter what happens after H(P,P) is correctly >>>>>> decided. >>>>> >>>>> Once again, you are evading the question. >>>>> >>>>> Does H(P, P) halt? I am not asking what it decides. I am asking >>>>> whether it halts. >>>>> >>>> >>>> H(P,P) never halts. If H(P,P) ever stops running this is because its >>>> infinitely nested simulation has had its execution suspended. This >>>> does not count as halting. >>> >>> >>> If H(P, P) never halts, then it cannot return an answer. That is an >>> admission that you don't have a decider at all. >>> >>> André >>> >> >> H forces its input to stop running so that H remains a decider. When H >> forces its input to stop running this does not make its input halt. >> Aborted simulations do not count as halting executions. > > I never claimed that aborting was the equivalent of halting, and I was > quite clear above that I wasn't talking about the input to H(P, P) but > to the computation H(P, P) itself. These are all elements of the same infinite chain. > Above you state that H(P, P) doesn't > halt. > Yes I am saying that H(P,P) stops running only because the third element of its infinite invocation sequence is aborted, thus never halts. > If H(P, P) returns a decision, that means it reaches one of its final > states which is, *by definition*, what it means for something to halt. > Are you now retracting your above claim that H(P, P) never halts? > > André > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.software-eng
csiph-web