Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

System checkpoint complete.


devel / comp.theory / Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

SubjectAuthor
* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ keyolcott
+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
 `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |+* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    ||`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    || `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    ||  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    ||   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    ||   |  `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | |     `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |     +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      |   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |       `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |   |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Jeff Barnett
    |   |        |    |      |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Jeff Barnett
    |   |        |    |      |   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |       +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |       |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |       `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |      |   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |       `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |        `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |         `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |          +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |          `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |           `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |            |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Dennis Bush
    |   |        |    |            | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |            | | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | | | +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |            | | | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            | | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |            | |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |             +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    |   |        |    |             `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |              `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |               `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |                `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |                 `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Andy Walker
    `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse

Pages:12345678910111213141516171819202122232425262728293031323334353637383940
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29755&group=comp.theory#29755

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 16:40:35 -0500
Date: Fri, 8 Apr 2022 16:40:33 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org>
<87y20iguq6.fsf@bsb.me.uk> <Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87bkxb9tc9.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 62
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-lroPXmoPCtfeW3COrgiWSahO2IyfOO25xsHvXwqiYNfHXLVFtARclwXILYpZwfx+9BfkgnHZ8utCGeJ!dWpPesaGr7RJ3DDgczOqA1Pdrz1M3Qen1cEWSGDHoWrVbciNEzEf/Kvjd1Fjhr6lHkJEdfZfC8/c!Gg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4522
 by: olcott - Fri, 8 Apr 2022 21:40 UTC

On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>
>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>
>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>> validating my 17 years worth of work.
>>>>>
>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>> about why you are wrong, they will do so.
>>>>>
>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>> any of these facts if the mood takes you.)
>>>>
>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>
>>> I believe what you've told me: that you claim that H(P,P)==false is
>>> correct despite the fact that P(P) halts. That's wrong.
>>
>> If the input to H(P,P) cannot possibly reach its final state then this
>> input is correctly rejected and nothing in the universe can possibly
>> contradict this.
>
> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
> either (indeed they come from you).
>
> Your new line in waffle is just an attempt to distract attention from a
> very simple claim: that the wrong answer is the right one.
>

Even Linz got this wrong because it is counter-intuitive.

A halt decider must compute the mapping from its inputs (not any damn
thing else in the universe) to its own final state on the basis of

the behavior specified by these inputs (thus their simulated execution
trace) and not anything else in the universe such as P(P).

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<h4ydnXOGgtbIMc3_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29756&group=comp.theory#29756

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 16:42:45 -0500
Date: Fri, 8 Apr 2022 16:42:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<VbOdnZhgTpAb9s3_nZ2dnUU7_8zNnZ2d@giganews.com>
<aae01e42-9022-46c7-b15d-a27a86f0ed3bn@googlegroups.com>
<6uOdnQl5KJnU7c3_nZ2dnUU7_83NnZ2d@giganews.com> <t2ps4p$t87$1@dont-email.me>
<hOGdnZiVNKYg6s3_nZ2dnUU7_8zNnZ2d@giganews.com> <87mtgva0ov.fsf@bsb.me.uk>
<iZOdnZmSB6slHs3_nZ2dnUU7_83NnZ2d@giganews.com>
<e65fc661-c6a8-4aaa-aea9-2d1ff0ecaecfn@googlegroups.com>
<Z6udncUXXLVhF83_nZ2dnUU7_8xh4p2d@giganews.com>
<b01bc1fa-d83d-4e6a-bdbd-4de745e1482fn@googlegroups.com>
<F7KdnUaeUOveD83_nZ2dnUU7_83NnZ2d@giganews.com>
<1c7d9131-34ff-47f8-920b-8d156a67d443n@googlegroups.com>
<LdydnSzUr7PBCM3_nZ2dnUU7_81QAAAA@giganews.com>
<deffd27f-683f-4f1a-8ad5-57f6cc5f9316n@googlegroups.com>
<VZOdnRr6E8sRBc3_nZ2dnUU7_8xh4p2d@giganews.com>
<4efaaab0-7155-4d53-8fd3-24a86024e3f9n@googlegroups.com>
<aMmdneBcA94dNM3_nZ2dnUU7_83NnZ2d@giganews.com>
<c6b7675d-6f0b-44ed-af9d-244e40d149ddn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <c6b7675d-6f0b-44ed-af9d-244e40d149ddn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <h4ydnXOGgtbIMc3_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 107
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-p112i1qTloJrHj4pc+ZPIqlYebbmeOxZkt+4eQBrhsrQUzpLvHvAZr8952wK51eMSCDcrrBiuzNIKKB!d24voGeIlEpTU33pPzGQTgZLZcSXy/58yYe9Sr0ctL7jIZV4SexAOdi7kX2Lai4HTcKtrBoUWtSZ!Gw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7806
 by: olcott - Fri, 8 Apr 2022 21:42 UTC

On 4/8/2022 4:36 PM, Dennis Bush wrote:
> On Friday, April 8, 2022 at 5:30:48 PM UTC-4, olcott wrote:
>> On 4/8/2022 3:36 PM, Dennis Bush wrote:
>>> On Friday, April 8, 2022 at 4:18:27 PM UTC-4, olcott wrote:
>>>> On 4/8/2022 3:09 PM, Dennis Bush wrote:
>>>>> On Friday, April 8, 2022 at 4:04:51 PM UTC-4, olcott wrote:
>>>>>> On 4/8/2022 2:56 PM, Dennis Bush wrote:
>>>>>>> On Friday, April 8, 2022 at 3:51:38 PM UTC-4, olcott wrote:
>>>>>>>> On 4/8/2022 2:38 PM, Dennis Bush wrote:
>>>>>>>>> On Friday, April 8, 2022 at 3:20:35 PM UTC-4, olcott wrote:
>>>>>>>>>> On 4/8/2022 2:16 PM, Dennis Bush wrote:
>>>>>>>>>>> On Friday, April 8, 2022 at 2:49:36 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 4/8/2022 1:29 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Linz makes this difficult to understand because he simply erases key
>>>>>>>>>>>>>> elements of the definition of Ĥ:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> You have erased them. Linz specifies Ĥ properly based on what H is
>>>>>>>>>>>>> supposed to do:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You have spent an inordinate amount of time over the years copying out
>>>>>>>>>>>>> those lines and dishonestly removing the key conditions. We all know
>>>>>>>>>>>>> why.
>>>>>>>>>>>>>
>>>>>>>>>>>> <Linz:1990:320>
>>>>>>>>>>>> Now Ĥ is a Turing machine, so that it will have some description in
>>>>>>>>>>>> Σ*, say ŵ. This string, in addition to being the description of Ĥ can
>>>>>>>>>>>> also be used as input string. We can therefore legitimately ask what
>>>>>>>>>>>> would happen if Ĥ is applied to ŵ.
>>>>>>>>>>>>
>>>>>>>>>>>> q0ŵ ⊢* Ĥ ∞
>>>>>>>>>>>> if Ĥ applied to ŵ halts, and
>>>>>>>>>>>>
>>>>>>>>>>>> q0ŵ ⊢* Ĥy1qny2
>>>>>>>>>>>> if Ĥ applied to ŵ does not halt. This is clearly nonsense. The
>>>>>>>>>>>> contradiction tells us that...
>>>>>>>>>>>> </Linz:1990:320>
>>>>>>>>>>>>
>>>>>>>>>>>> In other words the copy of H embedded within Ĥ is incorrect to either
>>>>>>>>>>>> reject or accept its input.
>>>>>>>>>>>
>>>>>>>>>>> What you fail to notice is that there is more than one H and H^ in play. For example:
>>>>>>>>>>>
>>>>>>>>>>> A: an H that always accepts
>>>>>>>>>>> R: an H that always rejects
>>>>>>>>>>>
>>>>>>>>>>> What the above is saying is that R / embedded_R rejecting <R^><R^> is incorrect and that A / embedded_A accepting <A^><A^> is incorrect. So not a *single* H but two *different* H's. This also means that A accepting <R^><R^> is correct and R rejecting <A^><A^> is correct.
>>>>>>>>>>>
>>>>>>>>>>> In other words, no H can give a correct halting/non-halting answer for an H^ built from it (even though some other H could).
>>>>>>>>>> So when I show that the H embedded within Ĥ does correctly decide its
>>>>>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩, Linz has been refuted.
>>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>>>> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>>> H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>> Then these steps would keep repeating:
>>>>>>>> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>> Since we can see that the simulated input: ⟨Ĥ0⟩ to embedded_H never
>>>>>>>> reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is
>>>>>>>> non-halting.
>>>>>>>
>>>>>>> That pattern only exists in Hn^.
>>>>>>
>>>>>> Since we can see that the simulated input: ⟨Ĥ0⟩ to embedded_H never
>>>>>> reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is
>>>>>> non-halting.
>>>>>> Changing the subject is lying.
>>>>>
>>>>> No, hiding which H you're talking about is lying. I just used Hn to demonstrate that.
>>>> The H that I am talking about is specified above:
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>> It has no subscript. Putting a subscript on it is an act of deception.
>>>
>>> No, deception is using "H" to pretend that this:
>>>
>>> When Ĥn is applied to ⟨Ĥn0⟩
>> I am referring only to the unsubscripted H embedded within Ĥ shown below.
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>> The instances of H that do have subscripts have no "n", and I am not
>> referring to any of these.
>
> Yes you are. You just don't realize it.
>
> For an H that aborts, it rejects <H^><H^> but some other halt decider accepts <H^><H^>, so H is wrong. That's what I mean when I say Ha is wrong to reject <Ha^><Ha^> because Hb accepts <Ha^><Ha^>.
I am only talking about what the actual H actually does.

All of your (in theory there could be an H that gets the wrong answer)
is dishonest distraction away from what the actual H actually does.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<h4ydnXKGgtZEMc3_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29757&group=comp.theory#29757

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 16:44:57 -0500
Date: Fri, 8 Apr 2022 16:44:55 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<b3188924-889f-45ec-8820-e1d896f73d21n@googlegroups.com>
<Hsedneu45OxO0M3_nZ2dnUU7_8xh4p2d@giganews.com>
<9a7bd82f-3dc1-4826-bd13-653bbe6dee60n@googlegroups.com>
<XpadnXQg2qObyM3_nZ2dnUU7_8xh4p2d@giganews.com>
<a41685c8-bb40-43ee-a32b-095ae506ee13n@googlegroups.com>
<ZqSdnUXjCr39xs3_nZ2dnUU7_8zNnZ2d@giganews.com> <t2pnj2$i9v$2@gioia.aioe.org>
<7PCdnYv_0Mo4_83_nZ2dnUU7_8zNnZ2d@giganews.com>
<b8bf0bd7-3a1d-4d8a-bd75-342ad8d49becn@googlegroups.com>
<VbOdnZhgTpAb9s3_nZ2dnUU7_8zNnZ2d@giganews.com>
<aae01e42-9022-46c7-b15d-a27a86f0ed3bn@googlegroups.com>
<6uOdnQl5KJnU7c3_nZ2dnUU7_83NnZ2d@giganews.com> <t2ps4p$t87$1@dont-email.me>
<hOGdnZiVNKYg6s3_nZ2dnUU7_8zNnZ2d@giganews.com> <87mtgva0ov.fsf@bsb.me.uk>
<iZOdnZmSB6slHs3_nZ2dnUU7_83NnZ2d@giganews.com> <87h7739u7q.fsf@bsb.me.uk>
<65ednegr_7I3N83_nZ2dnUU7_8zNnZ2d@giganews.com>
<9b20c42a-288b-497b-8f24-0e6c94409c05n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <9b20c42a-288b-497b-8f24-0e6c94409c05n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <h4ydnXKGgtZEMc3_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 65
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-tfX3MOyJenDETVyPnAiZ0Za7lw5ijom1gcq4Q8A2lznkLPICUlB0fpI5iDLrwea19Q7B3EDPRWDJEQq!L++cIZFnHlN6TgCVzeH/kxZPt454UTl7+96Dr7gOM1OjnERIX43OwQc+YVT1GMucZKwxwt5DdCbj!kg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5205
 by: olcott - Fri, 8 Apr 2022 21:44 UTC

On 4/8/2022 4:39 PM, Dennis Bush wrote:
> On Friday, April 8, 2022 at 5:35:46 PM UTC-4, olcott wrote:
>> On 4/8/2022 3:49 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 4/8/2022 1:29 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> Linz makes this difficult to understand because he simply erases key
>>>>>> elements of the definition of Ĥ:
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> You have erased them. Linz specifies Ĥ properly based on what H is
>>>>> supposed to do:
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>> You have spent an inordinate amount of time over the years copying out
>>>>> those lines and dishonestly removing the key conditions. We all know
>>>>> why.
>>>>
>>>> <Linz:1990:320>
>>>> Now Ĥ is a Turing machine, so that it will have some description in
>>>> Σ*, say ŵ. This string, in addition to being the description of Ĥ can
>>>> also be used as input string. We can therefore legitimately ask what
>>>> would happen if Ĥ is applied to ŵ.
>>>>
>>>> q0ŵ ⊢* Ĥ ∞
>>>> if Ĥ applied to ŵ halts, and
>>>>
>>>> q0ŵ ⊢* Ĥy1qny2
>>>
>>>> if Ĥ applied to ŵ does not halt. This is clearly nonsense. The
>>>> contradiction tells us that...
>>>> </Linz:1990:320>
>>>
>>> I know what Linz wrote. You could have just said "yes, I should keep
>>> the conditions in -- my mistake".
>>>
>>>> In other words the copy of H embedded within Ĥ is incorrect to either
>>>> reject or accept its input.
>>>
>>> No, that is not what Linz wrote "in other words". You've toyed with
>>> this misconception for a long time. For years you refused to agree with
>>> the simple fact that every instance of the halting problem has a correct
>>> yes/no answer. Even now I am not 100% sure you agree with it. But
>>> since Linz has always known it he would never conclude (or even
>>> contemplate) that neither answer is correct.
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>> Linz says that when embedded_H transitions to H.qy it is wrong and when
>> embedded_H transitions to H.qn it is wrong.
>
> More specifically, it says (given the earlier definitions of A and R) that A is wrong to accept <A^><A^> and R is wrong to reject <R^><R^>. Two different halt deciders, two different machines, two different results.

Thus when I prove
Ĥ applied to ⟨Ĥ⟩ ⊢* H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
is correct, then Linz has been refuted.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<d6f21583-88f1-4d4f-94f3-3f8a654efb04n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29758&group=comp.theory#29758

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ad4:5fc5:0:b0:444:3057:5626 with SMTP id jq5-20020ad45fc5000000b0044430575626mr363558qvb.86.1649454473893;
Fri, 08 Apr 2022 14:47:53 -0700 (PDT)
X-Received: by 2002:a25:780a:0:b0:633:ccea:3430 with SMTP id
t10-20020a25780a000000b00633ccea3430mr15374726ybc.26.1649454473699; Fri, 08
Apr 2022 14:47:53 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 8 Apr 2022 14:47:53 -0700 (PDT)
In-Reply-To: <h4ydnXOGgtbIMc3_nZ2dnUU7_8xh4p2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<VbOdnZhgTpAb9s3_nZ2dnUU7_8zNnZ2d@giganews.com> <aae01e42-9022-46c7-b15d-a27a86f0ed3bn@googlegroups.com>
<6uOdnQl5KJnU7c3_nZ2dnUU7_83NnZ2d@giganews.com> <t2ps4p$t87$1@dont-email.me>
<hOGdnZiVNKYg6s3_nZ2dnUU7_8zNnZ2d@giganews.com> <87mtgva0ov.fsf@bsb.me.uk>
<iZOdnZmSB6slHs3_nZ2dnUU7_83NnZ2d@giganews.com> <e65fc661-c6a8-4aaa-aea9-2d1ff0ecaecfn@googlegroups.com>
<Z6udncUXXLVhF83_nZ2dnUU7_8xh4p2d@giganews.com> <b01bc1fa-d83d-4e6a-bdbd-4de745e1482fn@googlegroups.com>
<F7KdnUaeUOveD83_nZ2dnUU7_83NnZ2d@giganews.com> <1c7d9131-34ff-47f8-920b-8d156a67d443n@googlegroups.com>
<LdydnSzUr7PBCM3_nZ2dnUU7_81QAAAA@giganews.com> <deffd27f-683f-4f1a-8ad5-57f6cc5f9316n@googlegroups.com>
<VZOdnRr6E8sRBc3_nZ2dnUU7_8xh4p2d@giganews.com> <4efaaab0-7155-4d53-8fd3-24a86024e3f9n@googlegroups.com>
<aMmdneBcA94dNM3_nZ2dnUU7_83NnZ2d@giganews.com> <c6b7675d-6f0b-44ed-af9d-244e40d149ddn@googlegroups.com>
<h4ydnXOGgtbIMc3_nZ2dnUU7_8xh4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d6f21583-88f1-4d4f-94f3-3f8a654efb04n@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Fri, 08 Apr 2022 21:47:53 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 157
 by: Dennis Bush - Fri, 8 Apr 2022 21:47 UTC

On Friday, April 8, 2022 at 5:42:52 PM UTC-4, olcott wrote:
> On 4/8/2022 4:36 PM, Dennis Bush wrote:
> > On Friday, April 8, 2022 at 5:30:48 PM UTC-4, olcott wrote:
> >> On 4/8/2022 3:36 PM, Dennis Bush wrote:
> >>> On Friday, April 8, 2022 at 4:18:27 PM UTC-4, olcott wrote:
> >>>> On 4/8/2022 3:09 PM, Dennis Bush wrote:
> >>>>> On Friday, April 8, 2022 at 4:04:51 PM UTC-4, olcott wrote:
> >>>>>> On 4/8/2022 2:56 PM, Dennis Bush wrote:
> >>>>>>> On Friday, April 8, 2022 at 3:51:38 PM UTC-4, olcott wrote:
> >>>>>>>> On 4/8/2022 2:38 PM, Dennis Bush wrote:
> >>>>>>>>> On Friday, April 8, 2022 at 3:20:35 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 4/8/2022 2:16 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Friday, April 8, 2022 at 2:49:36 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 4/8/2022 1:29 PM, Ben Bacarisse wrote:
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Linz makes this difficult to understand because he simply erases key
> >>>>>>>>>>>>>> elements of the definition of Ĥ:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> >>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You have erased them. Linz specifies Ĥ properly based on what H is
> >>>>>>>>>>>>> supposed to do:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
> >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You have spent an inordinate amount of time over the years copying out
> >>>>>>>>>>>>> those lines and dishonestly removing the key conditions. We all know
> >>>>>>>>>>>>> why.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> <Linz:1990:320>
> >>>>>>>>>>>> Now Ĥ is a Turing machine, so that it will have some description in
> >>>>>>>>>>>> Σ*, say ŵ. This string, in addition to being the description of Ĥ can
> >>>>>>>>>>>> also be used as input string. We can therefore legitimately ask what
> >>>>>>>>>>>> would happen if Ĥ is applied to ŵ.
> >>>>>>>>>>>>
> >>>>>>>>>>>> q0ŵ ⊢* Ĥ ∞
> >>>>>>>>>>>> if Ĥ applied to ŵ halts, and
> >>>>>>>>>>>>
> >>>>>>>>>>>> q0ŵ ⊢* Ĥy1qny2
> >>>>>>>>>>>> if Ĥ applied to ŵ does not halt. This is clearly nonsense. The
> >>>>>>>>>>>> contradiction tells us that...
> >>>>>>>>>>>> </Linz:1990:320>
> >>>>>>>>>>>>
> >>>>>>>>>>>> In other words the copy of H embedded within Ĥ is incorrect to either
> >>>>>>>>>>>> reject or accept its input.
> >>>>>>>>>>>
> >>>>>>>>>>> What you fail to notice is that there is more than one H and H^ in play. For example:
> >>>>>>>>>>>
> >>>>>>>>>>> A: an H that always accepts
> >>>>>>>>>>> R: an H that always rejects
> >>>>>>>>>>>
> >>>>>>>>>>> What the above is saying is that R / embedded_R rejecting <R^><R^> is incorrect and that A / embedded_A accepting <A^><A^> is incorrect. So not a *single* H but two *different* H's. This also means that A accepting <R^><R^> is correct and R rejecting <A^><A^> is correct.
> >>>>>>>>>>>
> >>>>>>>>>>> In other words, no H can give a correct halting/non-halting answer for an H^ built from it (even though some other H could).
> >>>>>>>>>> So when I show that the H embedded within Ĥ does correctly decide its
> >>>>>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩, Linz has been refuted.
> >>>>>>>>>
> >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >>>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
> >>>>>>>> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
> >>>>>>>> H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
> >>>>>>>> Then these steps would keep repeating:
> >>>>>>>> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
> >>>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
> >>>>>>>> Since we can see that the simulated input: ⟨Ĥ0⟩ to embedded_H never
> >>>>>>>> reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is
> >>>>>>>> non-halting.
> >>>>>>>
> >>>>>>> That pattern only exists in Hn^.
> >>>>>>
> >>>>>> Since we can see that the simulated input: ⟨Ĥ0⟩ to embedded_H never
> >>>>>> reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is
> >>>>>> non-halting.
> >>>>>> Changing the subject is lying.
> >>>>>
> >>>>> No, hiding which H you're talking about is lying. I just used Hn to demonstrate that.
> >>>> The H that I am talking about is specified above:
> >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >>>> It has no subscript. Putting a subscript on it is an act of deception.
> >>>
> >>> No, deception is using "H" to pretend that this:
> >>>
> >>> When Ĥn is applied to ⟨Ĥn0⟩
> >> I am referring only to the unsubscripted H embedded within Ĥ shown below.
> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >> The instances of H that do have subscripts have no "n", and I am not
> >> referring to any of these.
> >
> > Yes you are. You just don't realize it.
> >
> > For an H that aborts, it rejects <H^><H^> but some other halt decider accepts <H^><H^>, so H is wrong. That's what I mean when I say Ha is wrong to reject <Ha^><Ha^> because Hb accepts <Ha^><Ha^>.
> I am only talking about what the actual H actually does.
>
> All of your (in theory there could be an H that gets the wrong answer)
> is dishonest distraction away from what the actual H actually does.

You don't have an "actual H", that's part of your problem. You're using "H" to refer to multiple machines at the same time, and sometimes different ones in the same sentence. I do have an actual H which I call Ha (which is exactly the H you refer to that aborts its simulation), and I show how it's wrong.

If you're going to go back to only H being the source of truth for its input, then you need to answer for Ha3 rejecting <N><5>.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29759&group=comp.theory#29759

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a37:b442:0:b0:69a:fc75:ca52 with SMTP id d63-20020a37b442000000b0069afc75ca52mr4184187qkf.730.1649454577844;
Fri, 08 Apr 2022 14:49:37 -0700 (PDT)
X-Received: by 2002:a81:3489:0:b0:2eb:8b8e:c02c with SMTP id
b131-20020a813489000000b002eb8b8ec02cmr17810998ywa.213.1649454577695; Fri, 08
Apr 2022 14:49:37 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 8 Apr 2022 14:49:37 -0700 (PDT)
In-Reply-To: <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org> <87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Fri, 08 Apr 2022 21:49:37 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 69
 by: Dennis Bush - Fri, 8 Apr 2022 21:49 UTC

On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
> > olcott <No...@NoWhere.com> writes:
> >
> >> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
> >>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>>>> THIS PROVES THAT I AM CORRECT
> >>>>>>>> It is the case that the correctly simulated input to embedded_H can
> >>>>>>>> never possibly reach its own final state under any condition at all.
> >>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
> >>>>>>>
> >>>>>>> Yet you won't answer two simple questions! Why?
> >>>>>>
> >>>>>> Because I absolutely positively will not tolerate divergence from
> >>>>>> validating my 17 years worth of work.
> >>>>>
> >>>>> But you have no choice but to tolerate it. If someone wants to talk
> >>>>> about why you are wrong, they will do so.
> >>>>>
> >>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
> >>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
> >>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
> >>>>> any of these facts if the mood takes you.)
> >>>>
> >>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
> >>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
> >>>
> >>> I believe what you've told me: that you claim that H(P,P)==false is
> >>> correct despite the fact that P(P) halts. That's wrong.
> >>
> >> If the input to H(P,P) cannot possibly reach its final state then this
> >> input is correctly rejected and nothing in the universe can possibly
> >> contradict this.
> >
> > Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
> > either (indeed they come from you).
> >
> > Your new line in waffle is just an attempt to distract attention from a
> > very simple claim: that the wrong answer is the right one.
> >
> Even Linz got this wrong because it is counter-intuitive.
>
> A halt decider must compute the mapping from its inputs (not any damn
> thing else in the universe) to its own final state on the basis of
>
> the behavior specified by these inputs

Which is stipulated to be H^ applied to <H^>

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<x_24K.36164$Kdf.6757@fx96.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29760&group=comp.theory#29760

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx96.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<i42dnadnt_tPrNL_nZ2dnUU7_8xh4p2d@giganews.com>
<e0933c8a-0c19-4e96-884a-5ef48c8dc1a8n@googlegroups.com>
<W4adnSbpjeTnrtL_nZ2dnUU7_8xh4p2d@giganews.com>
<8be39aff-211d-4bd8-ab6c-e20c04ce27aan@googlegroups.com>
<o6CdnRI_dqq9pNL_nZ2dnUU7_8xh4p2d@giganews.com>
<a01c542d-a304-4c93-bab0-2754f9107761n@googlegroups.com>
<leudnbOlIa_Z39L_nZ2dnUU7_8zNnZ2d@giganews.com>
<d80b5ae3-7a01-470b-8fd5-2ba0b9155e2fn@googlegroups.com>
<VeOdnVB44dRE3tL_nZ2dnUU7_8xh4p2d@giganews.com>
<f80eca4c-f2a2-4a9c-877e-874e9442c7bfn@googlegroups.com>
<FeKdnbo027NvydL_nZ2dnUU7_83NnZ2d@giganews.com>
<e0ea227c-6761-4a6e-a9c5-eb30304e5c93n@googlegroups.com>
<QI-dncdxv-h6wdL_nZ2dnUU7_8zNnZ2d@giganews.com>
<8a79b5c6-826a-440f-8469-b222c055548dn@googlegroups.com>
<u8CdnXIcU9Va9NL_nZ2dnUU7_8zNnZ2d@giganews.com>
<10c9ba24-251a-4425-8e33-854d56f91ef7n@googlegroups.com>
<WuWdnRn38KCCw83_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <WuWdnRn38KCCw83_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 326
Message-ID: <x_24K.36164$Kdf.6757@fx96.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 18:50:06 -0400
X-Received-Bytes: 19153
 by: Richard Damon - Fri, 8 Apr 2022 22:50 UTC

On 4/8/22 12:09 PM, olcott wrote:
> On 4/7/2022 5:51 PM, Dennis Bush wrote:
>> On Thursday, April 7, 2022 at 6:46:37 PM UTC-4, olcott wrote:
>>> On 4/7/2022 5:18 PM, Dennis Bush wrote:
>>>> On Thursday, April 7, 2022 at 5:51:41 PM UTC-4, olcott wrote:
>>>>> On 4/7/2022 4:37 PM, Dennis Bush wrote:
>>>>>> On Thursday, April 7, 2022 at 5:17:44 PM UTC-4, olcott wrote:
>>>>>>> On 4/7/2022 3:21 PM, Dennis Bush wrote:
>>>>>>>> On Thursday, April 7, 2022 at 4:04:48 PM UTC-4, olcott wrote:
>>>>>>>>> On 4/7/2022 3:00 PM, Dennis Bush wrote:
>>>>>>>>>> On Thursday, April 7, 2022 at 3:58:03 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 4/7/2022 2:38 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Thursday, April 7, 2022 at 3:19:03 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 4/7/2022 2:07 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:54:57 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 4/7/2022 1:51 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:47:53 PM UTC-4, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 4/7/2022 1:45 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:24:01 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 4/7/2022 1:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:04:41 PM UTC-4,
>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 1:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 12:59 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:37:20 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 12:09 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:02:27 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 11:52 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 12:16:56 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 9:45 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 10:35:31 AM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 5:58 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 8:49 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 7:34 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 6:35 PM, Ben Bacarisse
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 4:36 PM, Ben Bacarisse
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 9:19 AM, Ben
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As for the main mistake, I know
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enough about cranks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to aim for only one
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of two things: can they be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> persuaded to say enough
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to show others that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they are wrong (for example PO
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> admission that H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> == false is correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> despite the fact that P(P) halts),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If it is the case that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input to H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state under any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> then H correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maps this finite string input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its reject state and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nothing in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe can correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> contradict that H is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you have a white dog in your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> living room and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> everyone in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe disagrees, you still
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have a white dog in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your living room.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good to see that you are still
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asserting that false is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result from a halt decider for at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> least one halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the input to the halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations then any damn thing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anywhere else is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> totally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If P(P) halts, H(P,P) should be true.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Like I said any damn thing else is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually 100%
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> perfectly totally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes! The only thing that matters is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether the "input",
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (P,P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies a halting computation or not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The "input" to H is two
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameters that specify the halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation P(P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halting computation that cannot
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition what-so-ever?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Either P(P) halts or it does not. Did
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you tell a fib when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you said it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does? Since it halts, H(P,P) == false
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The input to H(P,P) cannot possibly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state under
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any condition what-so-ever, thus if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> God and all his
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> angels and every
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being great and small said that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H specifies
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation they would all be liars.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You told that us P(P) halts. Until
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you retract that, I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will take it to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be true. You also told us that H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> == false. Do you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need to correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one or other of these statements?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As long as the input to H(P,P) never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches its final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state under any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever then no matter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what P(P) does H was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct because P(P) is not an input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and H is only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accountable for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getting its inputs correctly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So what two arguments must be passed to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H to get H to tell
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> us whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) halts or not? (Already asked, of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> course, but you a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dodging this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue for obvious reasons.)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You won't understand what I am saying
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until you first
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your question has nothing to do with the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctness of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rejection
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am referring to a point that is so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subtle that no one ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> noticed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this subtle point for 90 years.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I WILL KEEP REPEATING THIS UNTIL YOU
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RESPOND
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Of course you will. You can't answer the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> question without being
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously wrong,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the case that the correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input to embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never possibly reach its own final state
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct to reject its input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will not talk to you about anything
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> besides that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The input to UTM applied to <H^><H^>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Is not what I am talking about.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> You said "under any condition at all",
>>>>>>>>>>>>>>>>>>>>>>>>>> Within the scope of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>> Should I just ignore your next 20 replies?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So embedded_H, and therefore H, is the sole
>>>>>>>>>>>>>>>>>>>>>>>>> source of truth for if
>>>>>>>>>>>>>>>>>>>>>>>>> it's input reaches a final state?
>>>>>>>>>>>>>>>>>>>>>>>> The scope only includes embedded_H applied to
>>>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ and explicitly
>>>>>>>>>>>>>>>>>>>>>>>> excludes everything else in the whole universe.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So you're saying and embedded_H and H give
>>>>>>>>>>>>>>>>>>>>>>> different output for the
>>>>>>>>>>>>>>>>>>>>>>> same input?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I am saying that H is off topic bitch.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> STFU about it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In other words,
>>>>>>>>>>>>>>>>>>> I absolutely positively will not tolerate the most
>>>>>>>>>>>>>>>>>>> microscopic
>>>>>>>>>>>>>>>>>>> divergence from: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any replies with microscopic divergences will simply
>>>>>>>>>>>>>>>>>>> be ignored.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So you've implicitly agreed that embedded_H and H are
>>>>>>>>>>>>>>>>>> the same,
>>>>>>>>>>>>>>>>> I have done no such thing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Until you provide an example of H and embedded_H giving
>>>>>>>>>>>>>>>> different results from the same input, yes you have.
>>>>>>>>>>>>>>> Liar !!!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is when everyone watching sees that you know you
>>>>>>>>>>>>>> don't have a case.
>>>>>>>>>>>>> If I tolerate the slightest microscopic divergence from the
>>>>>>>>>>>>> point at
>>>>>>>>>>>>> hand you will never understand what I am saying in a
>>>>>>>>>>>>> million years.
>>>>>>>>>>>>>
>>>>>>>>>>>>> STFU about H !!!
>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Because embedded_H is the same as H
>>>>>>>>>>> Because the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H specifies a non-halting
>>>>>>>>>>> sequence of configurations
>>>>>>>>>>
>>>>>>>>>> It does not:
>>>>>>>>>>
>>>>>>>>> So the simulated input can possibly reach its own final state?
>>>>>>>>
>>>>>>>> Yep.
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>
>>>>>>> Show exactly where in this execution trace that the simulated
>>>>>>> ⟨Ĥ0⟩ would
>>>>>>> transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.
>>>>>>>
>>>>>>> Ĥ is applied to ⟨Ĥ0⟩
>>>>>>> (a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>> (b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>> Then these steps would keep repeating:
>>>>>>> (c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>> (d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>
>>>>>> Now you're talking about Hn which never aborts.
>>>>> All that I am saying is that if the simulated ⟨Ĥ0⟩ cannot possibly
>>>>> reach
>>>>> its own final state of ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩ then that proves that it is
>>>>> not
>>>>> a halting computation.
>>>>>
>>>>> You are saying know I must be wrong because that goes against your
>>>>> intuition.
>>>>>
>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>
>>>> ⟨Ĥn0⟩ never does transition to a final state. And yes Ĥn applies to
>>>> ⟨Ĥn⟩ does not halt. But Hn is unable to report that fact because it
>>>> can't abort its simulation and is therefore wrong by default.
>>> The fact that the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H cannot possibly reach its
>>> final state under any condition what-so-ever conclusively proves that it
>>> is not a halting computation.
>>
>> Yes, we agree that ⟨Ĥn⟩ ⟨Ĥn⟩ is non-halting.
>
> Conclusively proving that embedded_H would be correct when it rejects
> its input.


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29761&group=comp.theory#29761

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 17:51:23 -0500
Date: Fri, 8 Apr 2022 17:51:21 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org>
<87y20iguq6.fsf@bsb.me.uk> <Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 75
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-J4ZUpdMIja7S5K8/9FCBL4t/Ns+1a0BpKgjnh/q1bTi+ErPpvfI8k8TK8erGZVCVhrTyjuvm4CUSOxO!yWP/DJUQa4Ze5beHJBMHp9eh81RInU74F5q2+ytAeSUepPw01gABNDTvvNwYOMW03TlZtz1J++Zh!Cg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5296
 by: olcott - Fri, 8 Apr 2022 22:51 UTC

On 4/8/2022 4:49 PM, Dennis Bush wrote:
> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>
>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>
>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>> validating my 17 years worth of work.
>>>>>>>
>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>> about why you are wrong, they will do so.
>>>>>>>
>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>> any of these facts if the mood takes you.)
>>>>>>
>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>
>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>
>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>> input is correctly rejected and nothing in the universe can possibly
>>>> contradict this.
>>>
>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>> either (indeed they come from you).
>>>
>>> Your new line in waffle is just an attempt to distract attention from a
>>> very simple claim: that the wrong answer is the right one.
>>>
>> Even Linz got this wrong because it is counter-intuitive.
>>
>> A halt decider must compute the mapping from its inputs (not any damn
>> thing else in the universe) to its own final state on the basis of
>>
>> the behavior specified by these inputs
>
> Which is stipulated to be H^ applied to <H^>

When Ĥ is applied to ⟨Ĥ0⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩

Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H reaches
its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<b034K.36165$Kdf.1035@fx96.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29762&group=comp.theory#29762

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx96.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<W4adnSbpjeTnrtL_nZ2dnUU7_8xh4p2d@giganews.com>
<8be39aff-211d-4bd8-ab6c-e20c04ce27aan@googlegroups.com>
<o6CdnRI_dqq9pNL_nZ2dnUU7_8xh4p2d@giganews.com>
<a01c542d-a304-4c93-bab0-2754f9107761n@googlegroups.com>
<leudnbOlIa_Z39L_nZ2dnUU7_8zNnZ2d@giganews.com>
<d80b5ae3-7a01-470b-8fd5-2ba0b9155e2fn@googlegroups.com>
<VeOdnVB44dRE3tL_nZ2dnUU7_8xh4p2d@giganews.com>
<f80eca4c-f2a2-4a9c-877e-874e9442c7bfn@googlegroups.com>
<FeKdnbo027NvydL_nZ2dnUU7_83NnZ2d@giganews.com>
<e0ea227c-6761-4a6e-a9c5-eb30304e5c93n@googlegroups.com>
<QI-dncdxv-h6wdL_nZ2dnUU7_8zNnZ2d@giganews.com>
<8a79b5c6-826a-440f-8469-b222c055548dn@googlegroups.com>
<u8CdnXIcU9Va9NL_nZ2dnUU7_8zNnZ2d@giganews.com>
<10c9ba24-251a-4425-8e33-854d56f91ef7n@googlegroups.com>
<WuWdnRn38KCCw83_nZ2dnUU7_83NnZ2d@giganews.com>
<c146edb7-aa55-4c05-8859-343fcc870e14n@googlegroups.com>
<N7qdnbRbV7YE983_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <N7qdnbRbV7YE983_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 327
Message-ID: <b034K.36165$Kdf.1035@fx96.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 18:51:52 -0400
X-Received-Bytes: 19822
 by: Richard Damon - Fri, 8 Apr 2022 22:51 UTC

On 4/8/22 1:02 PM, olcott wrote:
> On 4/8/2022 11:45 AM, Dennis Bush wrote:
>> On Friday, April 8, 2022 at 12:09:10 PM UTC-4, olcott wrote:
>>> On 4/7/2022 5:51 PM, Dennis Bush wrote:
>>>> On Thursday, April 7, 2022 at 6:46:37 PM UTC-4, olcott wrote:
>>>>> On 4/7/2022 5:18 PM, Dennis Bush wrote:
>>>>>> On Thursday, April 7, 2022 at 5:51:41 PM UTC-4, olcott wrote:
>>>>>>> On 4/7/2022 4:37 PM, Dennis Bush wrote:
>>>>>>>> On Thursday, April 7, 2022 at 5:17:44 PM UTC-4, olcott wrote:
>>>>>>>>> On 4/7/2022 3:21 PM, Dennis Bush wrote:
>>>>>>>>>> On Thursday, April 7, 2022 at 4:04:48 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 4/7/2022 3:00 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Thursday, April 7, 2022 at 3:58:03 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 4/7/2022 2:38 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 3:19:03 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 4/7/2022 2:07 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:54:57 PM UTC-4, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 4/7/2022 1:51 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:47:53 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 4/7/2022 1:45 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:24:01 PM UTC-4,
>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 1:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 2:04:41 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 1:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 12:59 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:37:20 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 12:09 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:02:27 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 11:52 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 12:16:56 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 9:45 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 10:35:31 AM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/7/2022 5:58 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 8:49 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 7:34 PM, Ben Bacarisse
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 6:35 PM, Ben Bacarisse
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 4:36 PM, Ben
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 4/6/2022 9:19 AM, Ben
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As for the main mistake, I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> know enough about cranks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to aim for only one
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of two things: can they be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> persuaded to say enough
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to show others that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they are wrong (for example
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PO admission that H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> == false is correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> despite the fact that P(P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halts),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If it is the case that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input to H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state under any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> then H correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maps this finite string input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to its reject state and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nothing in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe can correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> contradict that H is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you have a white dog in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your living room and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> everyone in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe disagrees, you still
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have a white dog in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your living room.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good to see that you are still
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asserting that false is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result from a halt decider for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at least one halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If the input to the halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting sequence of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations then any damn
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thing anywhere else is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> totally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If P(P) halts, H(P,P) should be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> true.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Like I said any damn thing else is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually 100%
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> perfectly totally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes! The only thing that matters is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether the "input",
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (P,P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies a halting computation or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The "input" to H is two
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameters that specify the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halting computation P(P).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halting computation that cannot
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition what-so-ever?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Either P(P) halts or it does not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you tell a fib when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you said it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does? Since it halts, H(P,P) ==
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> false is wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The input to H(P,P) cannot
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possibly reach its own final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state under
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any condition what-so-ever, thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if God and all his
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> angels and every
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being great and small said that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H specifies
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation they would all be liars.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You told that us P(P) halts. Until
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you retract that, I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will take it to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be true. You also told us that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) == false. Do you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need to correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one or other of these statements?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As long as the input to H(P,P) never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches its final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state under any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever then no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> matter what P(P) does H was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct because P(P) is not an input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and H is only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accountable for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getting its inputs correctly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So what two arguments must be passed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H to get H to tell
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> us whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> P(P) halts or not? (Already asked, of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> course, but you a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dodging this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue for obvious reasons.)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You won't understand what I am saying
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until you first
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your question has nothing to do with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the correctness of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rejection
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am referring to a point that is so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subtle that no one ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> noticed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this subtle point for 90 years.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I WILL KEEP REPEATING THIS UNTIL YOU
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> RESPOND
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Of course you will. You can't answer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the question without being
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> obviously wrong,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the case that the correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated input to embedded_H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never possibly reach its own final state
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct to reject its input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will not talk to you about anything
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> besides that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The input to UTM applied to <H^><H^>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Is not what I am talking about.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You said "under any condition at all",
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Within the scope of embedded_H applied to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Should I just ignore your next 20 replies?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> So embedded_H, and therefore H, is the sole
>>>>>>>>>>>>>>>>>>>>>>>>>>> source of truth for if
>>>>>>>>>>>>>>>>>>>>>>>>>>> it's input reaches a final state?
>>>>>>>>>>>>>>>>>>>>>>>>>> The scope only includes embedded_H applied to
>>>>>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ and explicitly
>>>>>>>>>>>>>>>>>>>>>>>>>> excludes everything else in the whole universe.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So you're saying and embedded_H and H give
>>>>>>>>>>>>>>>>>>>>>>>>> different output for the
>>>>>>>>>>>>>>>>>>>>>>>>> same input?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I am saying that H is off topic bitch.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> STFU about it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> In other words,
>>>>>>>>>>>>>>>>>>>>> I absolutely positively will not tolerate the most
>>>>>>>>>>>>>>>>>>>>> microscopic
>>>>>>>>>>>>>>>>>>>>> divergence from: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any replies with microscopic divergences will
>>>>>>>>>>>>>>>>>>>>> simply be ignored.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So you've implicitly agreed that embedded_H and H
>>>>>>>>>>>>>>>>>>>> are the same,
>>>>>>>>>>>>>>>>>>> I have done no such thing.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Until you provide an example of H and embedded_H
>>>>>>>>>>>>>>>>>> giving different results from the same input, yes you
>>>>>>>>>>>>>>>>>> have.
>>>>>>>>>>>>>>>>> Liar !!!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is when everyone watching sees that you know you
>>>>>>>>>>>>>>>> don't have a case.
>>>>>>>>>>>>>>> If I tolerate the slightest microscopic divergence from
>>>>>>>>>>>>>>> the point at
>>>>>>>>>>>>>>> hand you will never understand what I am saying in a
>>>>>>>>>>>>>>> million years.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> STFU about H !!!
>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because embedded_H is the same as H
>>>>>>>>>>>>> Because the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H specifies a
>>>>>>>>>>>>> non-halting
>>>>>>>>>>>>> sequence of configurations
>>>>>>>>>>>>
>>>>>>>>>>>> It does not:
>>>>>>>>>>>>
>>>>>>>>>>> So the simulated input can possibly reach its own final state?
>>>>>>>>>>
>>>>>>>>>> Yep.
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>
>>>>>>>>> Show exactly where in this execution trace that the simulated
>>>>>>>>> ⟨Ĥ0⟩ would
>>>>>>>>> transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.
>>>>>>>>>
>>>>>>>>> Ĥ is applied to ⟨Ĥ0⟩
>>>>>>>>> (a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>>>> (b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>> (c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>> (d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>
>>>>>>>> Now you're talking about Hn which never aborts.
>>>>>>> All that I am saying is that if the simulated ⟨Ĥ0⟩ cannot
>>>>>>> possibly reach
>>>>>>> its own final state of ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩ then that proves that it
>>>>>>> is not
>>>>>>> a halting computation.
>>>>>>>
>>>>>>> You are saying know I must be wrong because that goes against your
>>>>>>> intuition.
>>>>>>>
>>>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>>>> SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
>>>>>>
>>>>>> ⟨Ĥn0⟩ never does transition to a final state. And yes Ĥn applies
>>>>>> to ⟨Ĥn⟩ does not halt. But Hn is unable to report that fact
>>>>>> because it can't abort its simulation and is therefore wrong by
>>>>>> default.
>>>>> The fact that the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H cannot possibly
>>>>> reach its
>>>>> final state under any condition what-so-ever conclusively proves
>>>>> that it
>>>>> is not a halting computation.
>>>>
>>>> Yes, we agree that ⟨Ĥn⟩ ⟨Ĥn⟩ is non-halting.
>>> Conclusively proving that embedded_H would be correct when it rejects
>>> its input.
>>
>> Correction: conclusively proves that Hn (which you implicitly agree is
>> the same as embedded_Hn due to lack of evidence to the contrary)
>
> I asked about Ĥ0 and you answered with Ĥn which includes Ĥ[0...n].
>
> As long as Ĥ0 never halts then embedded_H is correct to report that Ĥ0
> never halts.
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<Up34K.210947$4JN7.93777@fx05.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29763&group=comp.theory#29763

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx05.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<8be39aff-211d-4bd8-ab6c-e20c04ce27aan@googlegroups.com>
<o6CdnRI_dqq9pNL_nZ2dnUU7_8xh4p2d@giganews.com>
<a01c542d-a304-4c93-bab0-2754f9107761n@googlegroups.com>
<leudnbOlIa_Z39L_nZ2dnUU7_8zNnZ2d@giganews.com>
<d80b5ae3-7a01-470b-8fd5-2ba0b9155e2fn@googlegroups.com>
<VeOdnVB44dRE3tL_nZ2dnUU7_8xh4p2d@giganews.com>
<f80eca4c-f2a2-4a9c-877e-874e9442c7bfn@googlegroups.com>
<FeKdnbo027NvydL_nZ2dnUU7_83NnZ2d@giganews.com>
<e0ea227c-6761-4a6e-a9c5-eb30304e5c93n@googlegroups.com>
<QI-dncdxv-h6wdL_nZ2dnUU7_8zNnZ2d@giganews.com>
<8a79b5c6-826a-440f-8469-b222c055548dn@googlegroups.com>
<u8CdnXIcU9Va9NL_nZ2dnUU7_8zNnZ2d@giganews.com>
<10c9ba24-251a-4425-8e33-854d56f91ef7n@googlegroups.com>
<WuWdnRn38KCCw83_nZ2dnUU7_83NnZ2d@giganews.com>
<c146edb7-aa55-4c05-8859-343fcc870e14n@googlegroups.com>
<N7qdnbRbV7YE983_nZ2dnUU7_8zNnZ2d@giganews.com> <t2ps9b$t87$2@dont-email.me>
<m5adnTn0-vXQ5M3_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <m5adnTn0-vXQ5M3_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 57
Message-ID: <Up34K.210947$4JN7.93777@fx05.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 19:19:17 -0400
X-Received-Bytes: 4102
 by: Richard Damon - Fri, 8 Apr 2022 23:19 UTC

On 4/8/22 2:04 PM, olcott wrote:
> On 4/8/2022 12:44 PM, André G. Isaak wrote:
>> On 2022-04-08 11:02, olcott wrote:
>>
>>> I asked about Ĥ0 and you answered with Ĥn which includes Ĥ[0...n].
>>
>> You need to go back to the point where Dennis defined his Ha and Hn.
>> They don't mean what you seem to think they mean.
>>
>> André
>>
>
> The fact that they do not mean embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is enough
> to know that they must be utterly rejected out-of-hand.
>
> That the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H is non-halting is the only thing
> that is relevant to the correctness of embedded_H rejecting this input.

Then you must be admitting that you aren't working on the Halting Problem.

The Halting Problem is concerned about the behavior of the computation
represented by the input to the Halt Decider, that is H^ applied to
<H^>, NOT the behavior of the Halt Decider to the input, that is your
embedded_H applied to <H^> H^>

>
> Everything else is the God damned lie of a God damned liar.
>
> When I say "God damned" I mean in the sense of being eternally
> incinerated in actual Hell.
>
> Revelation 21:8 King James Version
> ...all liars, shall have their part in the lake which burneth with fire
> and brimstone: which is the second death.
>
>

Yep, you are quoting what is going to happen to you since YOU are the
LIAR, since you do not speak what is actually the Truth.

Remember, THE DEFINITION, and thus THE TRUTH about what a Halt Decider
needs to consider is that H applied to <M> w needs to go to Qy or Qn
depending on whether M applied to w will Halt or not.

There is NO mention about the simulation done by H, so you claim that
this simulation is important is just a damning lie.

Truth IS Truth, and will have nothing to do with those that pervert it.

Your WHOLE THESIS is based on a LIE about what is Halting.

You have WASTED about 17 years of your life working on a LIE, and
spreading FALSEHOODS.

Since you seem to know what happens to liars, think carefully about what
you are trusting as your sources of Truth.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<hu34K.402096$iK66.61808@fx46.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29764&group=comp.theory#29764

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<8735it7zaj.fsf@bsb.me.uk> <t2hsgu$mmd$1@gioia.aioe.org>
<878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org>
<87y20iguq6.fsf@bsb.me.uk> <Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 75
Message-ID: <hu34K.402096$iK66.61808@fx46.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 19:23:57 -0400
X-Received-Bytes: 4652
 by: Richard Damon - Fri, 8 Apr 2022 23:23 UTC

On 4/8/22 10:46 AM, olcott wrote:
> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>
>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>
>>>>> Because I absolutely positively will not tolerate divergence from
>>>>> validating my 17 years worth of work.
>>>>
>>>> But you have no choice but to tolerate it.  If someone wants to talk
>>>> about why you are wrong, they will do so.
>>>>
>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>> any of these facts if the mood takes you.)
>>>
>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>
>> I believe what you've told me: that you claim that H(P,P)==false is
>> correct despite the fact that P(P) halts.  That's wrong.
>>
>
> If the input to H(P,P) cannot possibly reach its final state then this
> input is correctly rejected and nothing in the universe can possibly
> contradict this.
>

Except that YOU posted a trace of the input to H, that is P(P) reaching
its final state, so your statement if untrue. Or are you saying we can't
trust you because you lie?

> You just don't know the computer science of it. H computes the mapping
> from its input to its reject state on the basis that this simulated
> input never halts.

And thus computes the WRONG mapping. It needs to compute the mapping
based on what the direct execution of the input would do, or the FULL
CORRECT simulation (by the equivalency of a UTM).

If H answers, it is by construction of P, wrong.

>
> Your example keeps assuming the counter-factual that H computes the
> mapping from non-inputs. Deciders never do this !!!

The 'input' is always what was given as the input, which is the string P, P

The MAPPING (which isn't 'an input') is based on the behavior of P(P)

You just don't understand that basic concept of requirements.

>
>> I also believe that you can't answer these questions because you know
>> the answers to them also show you to be wrong.
>>
>> What string must be passed to H so that H can tell us whether or not Ĥ
>> applied to ⟨Ĥ⟩ halts, and what state does H ⟨Ĥ⟩ ⟨Ĥ⟩ transition to?
>>
>
>

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<jw34K.402097$iK66.11580@fx46.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29765&group=comp.theory#29765

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<b3188924-889f-45ec-8820-e1d896f73d21n@googlegroups.com>
<Hsedneu45OxO0M3_nZ2dnUU7_8xh4p2d@giganews.com>
<9a7bd82f-3dc1-4826-bd13-653bbe6dee60n@googlegroups.com>
<XpadnXQg2qObyM3_nZ2dnUU7_8xh4p2d@giganews.com>
<a41685c8-bb40-43ee-a32b-095ae506ee13n@googlegroups.com>
<ZqSdnUXjCr39xs3_nZ2dnUU7_8zNnZ2d@giganews.com> <t2pnj2$i9v$2@gioia.aioe.org>
<7PCdnYv_0Mo4_83_nZ2dnUU7_8zNnZ2d@giganews.com>
<b8bf0bd7-3a1d-4d8a-bd75-342ad8d49becn@googlegroups.com>
<VbOdnZhgTpAb9s3_nZ2dnUU7_8zNnZ2d@giganews.com>
<dd108703-e6b9-49f7-ade3-18df78290ed1n@googlegroups.com>
<Ku-dnbmvpPT58s3_nZ2dnUU7_81g4p2d@giganews.com>
<b928a14d-8798-426c-9481-94954e93c27cn@googlegroups.com>
<942dnQMvqrF5783_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <942dnQMvqrF5783_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 68
Message-ID: <jw34K.402097$iK66.11580@fx46.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 19:26:08 -0400
X-Received-Bytes: 4913
 by: Richard Damon - Fri, 8 Apr 2022 23:26 UTC

On 4/8/22 1:37 PM, olcott wrote:
> On 4/8/2022 12:32 PM, Dennis Bush wrote:
>> On Friday, April 8, 2022 at 1:22:52 PM UTC-4, olcott wrote:
>>> On 4/8/2022 12:13 PM, Dennis Bush wrote:
>>>> On Friday, April 8, 2022 at 1:06:21 PM UTC-4, olcott wrote:
>>>>> On 4/8/2022 11:46 AM, Dennis Bush wrote:
>>>>>> On Friday, April 8, 2022 at 12:28:28 PM UTC-4, olcott wrote:
>>>>>>> On 4/8/2022 11:24 AM, Python wrote:
>>>>>>>> Stupid Crank Peter Olcott wrote:
>>>>>>>>> On 4/8/2022 10:34 AM, Dennis Bush wrote:
>>>>>>>> ...
>>>>>>>>>> Not dishonent, just showing the flaws in your logic
>>>>>>>>>
>>>>>>>>> I proved that I have a white dog in my living room thus any
>>>>>>>>> discussion
>>>>>>>>> about black cats in my kitchen is merely a deceitful attempt to
>>>>>>>>> try
>>>>>>>>> and get away with the strawman error.
>>>>>>>>
>>>>>>>> You pretend to have a white dog in your living room with the
>>>>>>>> argument
>>>>>>>> that it has four legs and is white, then you dodge criticisms
>>>>>>>> pointing
>>>>>>>> out that you "dog" is purring.
>>>>>>> On 4/7/2022 5:51 PM, Dennis Bush wrote:
>>>>>>>> Yes, we agree that ⟨Ĥn⟩ ⟨Ĥn⟩ is non-halting.
>>>>>>> Therefore embedded_H is correct to reject this input.
>>>>>>
>>>>>> embedded_Hn is correct to reject this input, but it is unable to
>>>>>> abort to do so.
>>>>> Even if your ridiculously stupid idea that embedded_H cannot abort its
>>>>> input ⟨Ĥ0⟩ is correct, the simple fact remains that Linz has still
>>>>> been
>>>>> refuted: When embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ rejects its input it would
>>>>> be correct, directly contradicting the Linz assertion that both
>>>>> rejecting and accepting are the wrong answer.
>>>>
>>>> You're mixing up your H's yet again. embedded_Hn / Hn cannot abort.
>>>> embedded_Ha / Ha can.
>>>>
>>>> Ha / embedded_Ha rejects <Ĥa><Ĥa> but incorrectly as demonstrated by
>>>> Hb simulating <Ĥa><Ĥa> to its final state of <Ĥa.qn>
>>>>
>>> It is the case that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H never halts
>>> therefore embedded_H would correctly reject its input.
>>>
>>> All of you Ha Ha crap is pure deceptive bullshit.
>>
>> Just the opposite.  The fact that I use Ha and Hn catches you when
>> you're being deceptive when you say "H" because it makes it clear
>> exactly which H you're referring to.
>>
>> That's why you don't like talking about Ha and Hn because it exposes
>> your errors.  Which is why I'll continue to use them.
>
> Does the simulated input: <Ĥ> <Ĥ> to embedded_H reach its own simulated
> final state?
>
> YES OR NO any other answer is the God damned lie of a God damned liar.
>

IF embedded_H applied to <H^ <H^> -> Qn, then the answer is YES, when
PROPERLY simulated (i.e. simulated by a UTM as required by the
DDEFINTION of Halting).

All you can do is prove that ebedded_H does correct POOP deciding.

FAIL.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<2B34K.792470$aT3.128169@fx09.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29766&group=comp.theory#29766

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news.uzoreto.com!feeder.usenetexpress.com!tr3.eu1.usenetexpress.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com> <878rsj3rdn.fsf@bsb.me.uk> <t2k1bu$1srt$1@gioia.aioe.org> <87y20iguq6.fsf@bsb.me.uk> <Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com> <5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com> <v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 100
Message-ID: <2B34K.792470$aT3.128169@fx09.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 19:31:10 -0400
X-Received-Bytes: 6033
 by: Richard Damon - Fri, 8 Apr 2022 23:31 UTC

On 4/8/22 6:51 PM, olcott wrote:
> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>> embedded_H can
>>>>>>>>>>> never possibly reach its own final state under any condition
>>>>>>>>>>> at all.
>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>
>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>
>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>
>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>
>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false
>>>>>>>> but P(P)
>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>> transitions to
>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to
>>>>>>>> deny
>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>
>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>
>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>
>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>> contradict this.
>>>>
>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>> either (indeed they come from you).
>>>>
>>>> Your new line in waffle is just an attempt to distract attention from a
>>>> very simple claim: that the wrong answer is the right one.
>>>>
>>> Even Linz got this wrong because it is counter-intuitive.
>>>
>>> A halt decider must compute the mapping from its inputs (not any damn
>>> thing else in the universe) to its own final state on the basis of
>>>
>>> the behavior specified by these inputs
>>
>> Which is stipulated to be H^ applied to <H^>
>
>
> When Ĥ is applied to ⟨Ĥ0⟩
>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>    H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
> Then these steps would keep repeating:
>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>
> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H reaches
> its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>
>

If that IS the proper trace, then it doesn't, but H and embedded_H have
also failed to decide, because they will NEVER 'abort' their simulation
and return an answer.

They would be correct to return that answer, but they don't, so they are
wrong. Maybe they just die knowing the answer, but that still makes them
wrong.

CHANGE H / embedded_H to now give that answer, and you have changed H^,
and the trace no longer occurs, so you proof just vanished in a puff if
inky black smoke.

You seem to confuse the fact that H needs to be actually defined by an
actual algorithm that will, but the fundamental nature of algorithms,
always do the same thing with the same input.

H / embedded_H applied to <H^> <H^> will EITHER simulate for ever and
fail to answer or will abort it simulation and be guilty of unsound
logic and gives the wrong answer.

You are just to dumb to understand that.

FAIL.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29767&group=comp.theory#29767

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 18:34:55 -0500
Date: Fri, 8 Apr 2022 18:34:53 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<t2k1bu$1srt$1@gioia.aioe.org> <87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com> <87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <2B34K.792470$aT3.128169@fx09.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 95
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-olu3gKTqmXGwDNlbTUoyHnfKxVflq5J8IyiJH0XEqFKDx2ld6c0q5BpH7Sf7epLTETZaYUYKuD75veS!m73TRPFD7zRYftduC83GpXArVnZmk6c0t8AhdiaAF0tspoEsGhAoFZcHbtNof+9DJ2UbeUDa1JW4!tA==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6000
 by: olcott - Fri, 8 Apr 2022 23:34 UTC

On 4/8/2022 6:31 PM, Richard Damon wrote:
>
> On 4/8/22 6:51 PM, olcott wrote:
>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>> never possibly reach its own final state under any condition
>>>>>>>>>>>> at all.
>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>
>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>
>>>>>>>>> But you have no choice but to tolerate it. If someone wants to
>>>>>>>>> talk
>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>
>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false
>>>>>>>>> but P(P)
>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>> transitions to
>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free
>>>>>>>>> to deny
>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>
>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>
>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>
>>>>>> If the input to H(P,P) cannot possibly reach its final state then
>>>>>> this
>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>> contradict this.
>>>>>
>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>> either (indeed they come from you).
>>>>>
>>>>> Your new line in waffle is just an attempt to distract attention
>>>>> from a
>>>>> very simple claim: that the wrong answer is the right one.
>>>>>
>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>
>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>> thing else in the universe) to its own final state on the basis of
>>>>
>>>> the behavior specified by these inputs
>>>
>>> Which is stipulated to be H^ applied to <H^>
>>
>>
>> When Ĥ is applied to ⟨Ĥ0⟩
>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>> Then these steps would keep repeating:
>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>
>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H reaches
>> its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>
>>
>
> If that IS the proper trace, then it doesn't, but H and embedded_H have
> also failed to decide, because they will NEVER 'abort' their simulation
> and return an answer.
That is a proper trace and in the next step embedded_H aborts the
simulation of its input and transitions to its reject state.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<GF44K.31231$r_.15461@fx41.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29769&group=comp.theory#29769

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx41.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87y20iguq6.fsf@bsb.me.uk> <Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 107
Message-ID: <GF44K.31231$r_.15461@fx41.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 20:44:22 -0400
X-Received-Bytes: 6142
 by: Richard Damon - Sat, 9 Apr 2022 00:44 UTC

On 4/8/22 7:34 PM, olcott wrote:
> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>
>> On 4/8/22 6:51 PM, olcott wrote:
>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>
>>>>>>>>>>> Because I absolutely positively will not tolerate divergence
>>>>>>>>>>> from
>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>
>>>>>>>>>> But you have no choice but to tolerate it. If someone wants to
>>>>>>>>>> talk
>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>
>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false
>>>>>>>>>> but P(P)
>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>> transitions to
>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free
>>>>>>>>>> to deny
>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>
>>>>>>>>> If you believe (against the verified facts) that the simulated
>>>>>>>>> ⟨Ĥ0⟩
>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>
>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>
>>>>>>> If the input to H(P,P) cannot possibly reach its final state then
>>>>>>> this
>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>> contradict this.
>>>>>>
>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>> either (indeed they come from you).
>>>>>>
>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>> from a
>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>
>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>
>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>> thing else in the universe) to its own final state on the basis of
>>>>>
>>>>> the behavior specified by these inputs
>>>>
>>>> Which is stipulated to be H^ applied to <H^>
>>>
>>>
>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>> Then these steps would keep repeating:
>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>
>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H reaches
>>> its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>
>>>
>>
>> If that IS the proper trace, then it doesn't, but H and embedded_H
>> have also failed to decide, because they will NEVER 'abort' their
>> simulation and return an answer.
> That is a proper trace and in the next step embedded_H aborts the
> simulation of its input and transitions to its reject state.
>
>

Then the words "Keep on Repeating" are a LIE.

FAIL.

If embedded_H DOES abort at the next step, then the trace shows that H^
applied to <H^> Halts, and thus <H^> <H^> represents a Halting
Computation and thus the CORRECT answer is Halting, or Qy,

This is by the meaning of the words from the DEFINITION of the Halting
Problem.

Thus your embedded_H is WRONG.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29770&group=comp.theory#29770

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 20:01:15 -0500
Date: Fri, 8 Apr 2022 20:01:13 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <GF44K.31231$r_.15461@fx41.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 115
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-zz2EI+HUvlyz+5rLrTqLPftwv869xTyqfxxA6w+G/7hI9aHLrH0Gep+RSX+4UILuseU6XK8hg0C56om!x6vYighyE8TznsHbCkFiyVRuj/JOTiQaWDwPgchUBgfpLv90e+xib9SVVx6Z5ab0UQzpqnufwU5c!1Q==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6818
 by: olcott - Sat, 9 Apr 2022 01:01 UTC

On 4/8/2022 7:44 PM, Richard Damon wrote:
> On 4/8/22 7:34 PM, olcott wrote:
>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>
>>> On 4/8/22 6:51 PM, olcott wrote:
>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>
>>>>>>>>>>>> Because I absolutely positively will not tolerate divergence
>>>>>>>>>>>> from
>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>
>>>>>>>>>>> But you have no choice but to tolerate it. If someone wants
>>>>>>>>>>> to talk
>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>
>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>> false but P(P)
>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>> transitions to
>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free
>>>>>>>>>>> to deny
>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>
>>>>>>>>>> If you believe (against the verified facts) that the simulated
>>>>>>>>>> ⟨Ĥ0⟩
>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>
>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>> H(P,P)==false is
>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>
>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>> then this
>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>> possibly
>>>>>>>> contradict this.
>>>>>>>
>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>>> either (indeed they come from you).
>>>>>>>
>>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>>> from a
>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>
>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>
>>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>>> thing else in the universe) to its own final state on the basis of
>>>>>>
>>>>>> the behavior specified by these inputs
>>>>>
>>>>> Which is stipulated to be H^ applied to <H^>
>>>>
>>>>
>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>> Then these steps would keep repeating:
>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>
>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>
>>>>
>>>
>>> If that IS the proper trace, then it doesn't, but H and embedded_H
>>> have also failed to decide, because they will NEVER 'abort' their
>>> simulation and return an answer.
>> That is a proper trace and in the next step embedded_H aborts the
>> simulation of its input and transitions to its reject state.
>>
>>
>
> Then the words "Keep on Repeating" are a LIE.
>

I needed my readers to get one single point from the above sequence that
the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its own final
state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.

It has taken you about three months to get this one single point.

Now that you have gotten this point we move on to the next step,
embedded_H aborts its simulation and transitions to its own reject state.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<Ml54K.792474$aT3.709472@fx09.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29771&group=comp.theory#29771

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 139
Message-ID: <Ml54K.792474$aT3.709472@fx09.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 21:31:24 -0400
X-Received-Bytes: 7685
 by: Richard Damon - Sat, 9 Apr 2022 01:31 UTC

On 4/8/22 9:01 PM, olcott wrote:
> On 4/8/2022 7:44 PM, Richard Damon wrote:
>> On 4/8/22 7:34 PM, olcott wrote:
>>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>>
>>>> On 4/8/22 6:51 PM, olcott wrote:
>>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>
>>>>>>>>>>>> But you have no choice but to tolerate it. If someone wants
>>>>>>>>>>>> to talk
>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>
>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>> transitions to
>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>> free to deny
>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>
>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>
>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>> H(P,P)==false is
>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>
>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>> then this
>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>> possibly
>>>>>>>>> contradict this.
>>>>>>>>
>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't
>>>>>>>> dispute
>>>>>>>> either (indeed they come from you).
>>>>>>>>
>>>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>>>> from a
>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>
>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>
>>>>>>> A halt decider must compute the mapping from its inputs (not any
>>>>>>> damn
>>>>>>> thing else in the universe) to its own final state on the basis of
>>>>>>>
>>>>>>> the behavior specified by these inputs
>>>>>>
>>>>>> Which is stipulated to be H^ applied to <H^>
>>>>>
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>> Then these steps would keep repeating:
>>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>
>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>
>>>>>
>>>>
>>>> If that IS the proper trace, then it doesn't, but H and embedded_H
>>>> have also failed to decide, because they will NEVER 'abort' their
>>>> simulation and return an answer.
>>> That is a proper trace and in the next step embedded_H aborts the
>>> simulation of its input and transitions to its reject state.
>>>
>>>
>>
>> Then the words "Keep on Repeating" are a LIE.
>>
>
> I needed my readers to get one single point from the above sequence that
> the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its own final
> state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>
> It has taken you about three months to get this one single point.
>
> Now that you have gotten this point we move on to the next step,
> embedded_H aborts its simulation and transitions to its own reject state.
>

The point YOU keep missing is that you have to keep on telling
half-truths (which is another name for a LIE) to make your statement
even seem possible.

Yes, H^ applied to <H^> can be non-halting, but only if H or embedded_H
applied to <H^> <H^> doesn't answer Qn, so if fails to be the needed
decider.

If it does answer Qn, then H^ applied to <H^> will Halt.

So there is NO case where either H or embedded_H gives a CORRECT
non-halting answer to the correct question.

Sometimes your lie is that you are confusing two different machines that
you LIE by calling both 'H' (or embedded_H) and you give the H^ but on
one to the other, This is were people come back and point out that you
have two different versions of the machine (which we typically call Ha
and Hn), and point out that you actually are looking at one H and the
OTHER H^, which means you LIE that you are following Linz.

Ultimately, you WHOLE ARGUEMENT is based on LYING about something, but
you keep on changing which meaning you are using which just compounds
your lies.

You have basically DESTROYED any reputation you might have had, and are
going to be know for as long as you are remembered as the LYING CRACKPOT.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29772&group=comp.theory#29772

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 20:46:41 -0500
Date: Fri, 8 Apr 2022 20:46:39 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <Ml54K.792474$aT3.709472@fx09.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 138
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-o63DbXAhGEpgv90cZBnGQ92yRH2U35fdxXiHK6hHz+lF3uoHK/7wR3VMEiy2G9ycqh4OtkG2gQJ372k!vUx5h/cgr2uDFL01zgB/voUrmFfJqgufAGRRUmN4hMFXoxG+6uIrJTGboArOVZbcTGC2jlaa4hN/!Jw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7884
 by: olcott - Sat, 9 Apr 2022 01:46 UTC

On 4/8/2022 8:31 PM, Richard Damon wrote:
>
> On 4/8/22 9:01 PM, olcott wrote:
>> On 4/8/2022 7:44 PM, Richard Damon wrote:
>>> On 4/8/22 7:34 PM, olcott wrote:
>>>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>>>
>>>>> On 4/8/22 6:51 PM, olcott wrote:
>>>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But you have no choice but to tolerate it. If someone wants
>>>>>>>>>>>>> to talk
>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>
>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>
>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>>
>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>> then this
>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>> possibly
>>>>>>>>>> contradict this.
>>>>>>>>>
>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't
>>>>>>>>> dispute
>>>>>>>>> either (indeed they come from you).
>>>>>>>>>
>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>> attention from a
>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>
>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>
>>>>>>>> A halt decider must compute the mapping from its inputs (not any
>>>>>>>> damn
>>>>>>>> thing else in the universe) to its own final state on the basis of
>>>>>>>>
>>>>>>>> the behavior specified by these inputs
>>>>>>>
>>>>>>> Which is stipulated to be H^ applied to <H^>
>>>>>>
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>> Then these steps would keep repeating:
>>>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>
>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>
>>>>>>
>>>>>
>>>>> If that IS the proper trace, then it doesn't, but H and embedded_H
>>>>> have also failed to decide, because they will NEVER 'abort' their
>>>>> simulation and return an answer.
>>>> That is a proper trace and in the next step embedded_H aborts the
>>>> simulation of its input and transitions to its reject state.
>>>>
>>>>
>>>
>>> Then the words "Keep on Repeating" are a LIE.
>>>
>>
>> I needed my readers to get one single point from the above sequence
>> that the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its own
>> final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>
>> It has taken you about three months to get this one single point.
>>
>> Now that you have gotten this point we move on to the next step,
>> embedded_H aborts its simulation and transitions to its own reject state.
>>
>
> The point YOU keep missing is that you have to keep on telling
> half-truths (which is another name for a LIE) to make your statement
> even seem possible.

I tell one tiny piece of the truth until someone gets it. Then I move on
to the next tiny piece of the truth until someone gets it.

It took you three months to understand that the simulated input ⟨Ĥ0⟩
⟨Ĥ1⟩ to embedded_H never reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.

It may take you three more months to understand that a simulated input
that never reaches it own final state is a non-halting input.

Six months from now when you understand that the input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
embedded_H never halts you may begin to see that embedded_H can
correctly report this fact.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<iW54K.547991$7F2.157695@fx12.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29774&group=comp.theory#29774

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx12.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 171
Message-ID: <iW54K.547991$7F2.157695@fx12.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 22:10:22 -0400
X-Received-Bytes: 8874
 by: Richard Damon - Sat, 9 Apr 2022 02:10 UTC

On 4/8/22 9:46 PM, olcott wrote:
> On 4/8/2022 8:31 PM, Richard Damon wrote:
>>
>> On 4/8/22 9:01 PM, olcott wrote:
>>> On 4/8/2022 7:44 PM, Richard Damon wrote:
>>>> On 4/8/22 7:34 PM, olcott wrote:
>>>>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 4/8/22 6:51 PM, olcott wrote:
>>>>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But you have no choice but to tolerate it. If someone
>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>>>
>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>> then this
>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>> possibly
>>>>>>>>>>> contradict this.
>>>>>>>>>>
>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't
>>>>>>>>>> dispute
>>>>>>>>>> either (indeed they come from you).
>>>>>>>>>>
>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>> attention from a
>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>>
>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>
>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>> any damn
>>>>>>>>> thing else in the universe) to its own final state on the basis of
>>>>>>>>>
>>>>>>>>> the behavior specified by these inputs
>>>>>>>>
>>>>>>>> Which is stipulated to be H^ applied to <H^>
>>>>>>>
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>> Then these steps would keep repeating:
>>>>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>
>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> If that IS the proper trace, then it doesn't, but H and embedded_H
>>>>>> have also failed to decide, because they will NEVER 'abort' their
>>>>>> simulation and return an answer.
>>>>> That is a proper trace and in the next step embedded_H aborts the
>>>>> simulation of its input and transitions to its reject state.
>>>>>
>>>>>
>>>>
>>>> Then the words "Keep on Repeating" are a LIE.
>>>>
>>>
>>> I needed my readers to get one single point from the above sequence
>>> that the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>> own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>
>>> It has taken you about three months to get this one single point.
>>>
>>> Now that you have gotten this point we move on to the next step,
>>> embedded_H aborts its simulation and transitions to its own reject
>>> state.
>>>
>>
>> The point YOU keep missing is that you have to keep on telling
>> half-truths (which is another name for a LIE) to make your statement
>> even seem possible.
>
> I tell one tiny piece of the truth until someone gets it. Then I move on
> to the next tiny piece of the truth until someone gets it.

Nope, you tell a lot of partial truths where you try to focus the
attention on the part that is true, while trying to hide the lies you
need to tell to make that one piece true.

Like, Yes, you CAN make H^ applied to <H^> non-halting, but when you do,
your H / embedded_H now fails to answer.

>
> It took you three months to understand that the simulated input ⟨Ĥ0⟩
> ⟨Ĥ1⟩ to embedded_H never reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.

Nope, I ALWAYS knew that H^ applied to <H^> could be non-halting (and
thus the corret simulation of it is also non-halting) but this ONLY
occurs when H fails to answer Qn.

Sometimes, when your context is clearly a case where H answers Qn, I
won't add the condition. but it has always been seen.

>
> It may take you three more months to understand that a simulated input
> that never reaches it own final state is a non-halting input.


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<ib2dneZxLv8sds3_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29775&group=comp.theory#29775

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 21:13:05 -0500
Date: Fri, 8 Apr 2022 21:13:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
<iW54K.547991$7F2.157695@fx12.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <iW54K.547991$7F2.157695@fx12.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <ib2dneZxLv8sds3_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 150
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jwEWePzX61LfLmjPtz1Fwz1JY9Mk3lh3JyVsOBsc+Omz5EFnz1EelBNDc+fwCyFc5LiTmGKK8d+17Qg!u1o2EIx9W5mAbwNSGbrn5fcg/DdZRCLrsbdXXmhDyWMVzkmz0Qn8VIJvZrKo1WRu+3Ufhluo0WzP!pw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8543
 by: olcott - Sat, 9 Apr 2022 02:13 UTC

On 4/8/2022 9:10 PM, Richard Damon wrote:
>
> On 4/8/22 9:46 PM, olcott wrote:
>> On 4/8/2022 8:31 PM, Richard Damon wrote:
>>>
>>> On 4/8/22 9:01 PM, olcott wrote:
>>>> On 4/8/2022 7:44 PM, Richard Damon wrote:
>>>>> On 4/8/22 7:34 PM, olcott wrote:
>>>>>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 4/8/22 6:51 PM, olcott wrote:
>>>>>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But you have no choice but to tolerate it. If someone
>>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>>
>>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>>> then this
>>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>>> possibly
>>>>>>>>>>>> contradict this.
>>>>>>>>>>>
>>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't
>>>>>>>>>>> dispute
>>>>>>>>>>> either (indeed they come from you).
>>>>>>>>>>>
>>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>>> attention from a
>>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>>>
>>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>>
>>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>>> any damn
>>>>>>>>>> thing else in the universe) to its own final state on the
>>>>>>>>>> basis of
>>>>>>>>>>
>>>>>>>>>> the behavior specified by these inputs
>>>>>>>>>
>>>>>>>>> Which is stipulated to be H^ applied to <H^>
>>>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>
>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>>>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> If that IS the proper trace, then it doesn't, but H and
>>>>>>> embedded_H have also failed to decide, because they will NEVER
>>>>>>> 'abort' their simulation and return an answer.
>>>>>> That is a proper trace and in the next step embedded_H aborts the
>>>>>> simulation of its input and transitions to its reject state.
>>>>>>
>>>>>>
>>>>>
>>>>> Then the words "Keep on Repeating" are a LIE.
>>>>>
>>>>
>>>> I needed my readers to get one single point from the above sequence
>>>> that the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>> own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>
>>>> It has taken you about three months to get this one single point.
>>>>
>>>> Now that you have gotten this point we move on to the next step,
>>>> embedded_H aborts its simulation and transitions to its own reject
>>>> state.
>>>>
>>>
>>> The point YOU keep missing is that you have to keep on telling
>>> half-truths (which is another name for a LIE) to make your statement
>>> even seem possible.
>>
>> I tell one tiny piece of the truth until someone gets it. Then I move
>> on to the next tiny piece of the truth until someone gets it.
>
> Nope, you tell a lot of partial truths where you try to focus the
> attention on the part that is true, while trying to hide the lies you
> need to tell to make that one piece true.
>
> Like, Yes, you CAN make H^ applied to <H^> non-halting, but when you do,
> your H / embedded_H now fails to answer.
>
>>
>> It took you three months to understand that the simulated input ⟨Ĥ0⟩
>> ⟨Ĥ1⟩ to embedded_H never reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>
> Nope, I ALWAYS knew that H^ applied to <H^> could be non-halting (and
> thus the corret simulation of it is also non-halting) but this ONLY
> occurs when H fails to answer Qn.


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<U72dnQYEnOKgcM3_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29776&group=comp.theory#29776

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 08 Apr 2022 21:19:41 -0500
Date: Fri, 8 Apr 2022 21:19:40 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
<iW54K.547991$7F2.157695@fx12.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <iW54K.547991$7F2.157695@fx12.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <U72dnQYEnOKgcM3_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 153
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-oHxhRXJUZ7F0DW6qFGzJcY7AxTPReNY9rD3t2mgxC99qkDJXeM49q+8Usq8NQ81EJ9ypDs4SK6ocL2+!ORwSgofwhx/cB7CvGPdLGUbtNJhGqcAHvm48XBEeSZBb9xT2edbkQNueH9FuE6MnLw9Cbm5TMS2s!9g==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8636
 by: olcott - Sat, 9 Apr 2022 02:19 UTC

On 4/8/2022 9:10 PM, Richard Damon wrote:
>
> On 4/8/22 9:46 PM, olcott wrote:
>> On 4/8/2022 8:31 PM, Richard Damon wrote:
>>>
>>> On 4/8/22 9:01 PM, olcott wrote:
>>>> On 4/8/2022 7:44 PM, Richard Damon wrote:
>>>>> On 4/8/22 7:34 PM, olcott wrote:
>>>>>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 4/8/22 6:51 PM, olcott wrote:
>>>>>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But you have no choice but to tolerate it. If someone
>>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>>
>>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>>> then this
>>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>>> possibly
>>>>>>>>>>>> contradict this.
>>>>>>>>>>>
>>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't
>>>>>>>>>>> dispute
>>>>>>>>>>> either (indeed they come from you).
>>>>>>>>>>>
>>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>>> attention from a
>>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>>>
>>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>>
>>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>>> any damn
>>>>>>>>>> thing else in the universe) to its own final state on the
>>>>>>>>>> basis of
>>>>>>>>>>
>>>>>>>>>> the behavior specified by these inputs
>>>>>>>>>
>>>>>>>>> Which is stipulated to be H^ applied to <H^>
>>>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>
>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>>>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> If that IS the proper trace, then it doesn't, but H and
>>>>>>> embedded_H have also failed to decide, because they will NEVER
>>>>>>> 'abort' their simulation and return an answer.
>>>>>> That is a proper trace and in the next step embedded_H aborts the
>>>>>> simulation of its input and transitions to its reject state.
>>>>>>
>>>>>>
>>>>>
>>>>> Then the words "Keep on Repeating" are a LIE.
>>>>>
>>>>
>>>> I needed my readers to get one single point from the above sequence
>>>> that the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>> own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>
>>>> It has taken you about three months to get this one single point.
>>>>
>>>> Now that you have gotten this point we move on to the next step,
>>>> embedded_H aborts its simulation and transitions to its own reject
>>>> state.
>>>>
>>>
>>> The point YOU keep missing is that you have to keep on telling
>>> half-truths (which is another name for a LIE) to make your statement
>>> even seem possible.
>>
>> I tell one tiny piece of the truth until someone gets it. Then I move
>> on to the next tiny piece of the truth until someone gets it.
>
> Nope, you tell a lot of partial truths where you try to focus the
> attention on the part that is true, while trying to hide the lies you
> need to tell to make that one piece true.
>
> Like, Yes, you CAN make H^ applied to <H^> non-halting, but when you do,
> your H / embedded_H now fails to answer.
>
>>
>> It took you three months to understand that the simulated input ⟨Ĥ0⟩
>> ⟨Ĥ1⟩ to embedded_H never reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>
> Nope, I ALWAYS knew that H^ applied to <H^> could be non-halting (and
> thus the corret simulation of it is also non-halting) but this ONLY
> occurs when H fails to answer Qn.
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<T564K.185537$yi_7.10523@fx39.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29777&group=comp.theory#29777

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.swapon.de!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!nntp.speedium.network!feeder01!81.171.65.14.MISMATCH!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
<iW54K.547991$7F2.157695@fx12.iad>
<ib2dneZxLv8sds3_nZ2dnUU7_8xh4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ib2dneZxLv8sds3_nZ2dnUU7_8xh4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 148
Message-ID: <T564K.185537$yi_7.10523@fx39.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 22:22:43 -0400
X-Received-Bytes: 8417
 by: Richard Damon - Sat, 9 Apr 2022 02:22 UTC

On 4/8/22 10:13 PM, olcott wrote:
> On 4/8/2022 9:10 PM, Richard Damon wrote:
>>
>> On 4/8/22 9:46 PM, olcott wrote:
>>> On 4/8/2022 8:31 PM, Richard Damon wrote:
>>>>
>>>> On 4/8/22 9:01 PM, olcott wrote:
>>>>> On 4/8/2022 7:44 PM, Richard Damon wrote:
>>>>>> On 4/8/22 7:34 PM, olcott wrote:
>>>>>>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 4/8/22 6:51 PM, olcott wrote:
>>>>>>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>>>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But you have no choice but to tolerate it. If someone
>>>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final
>>>>>>>>>>>>> state then this
>>>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>>>> possibly
>>>>>>>>>>>>> contradict this.
>>>>>>>>>>>>
>>>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't
>>>>>>>>>>>> dispute
>>>>>>>>>>>> either (indeed they come from you).
>>>>>>>>>>>>
>>>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>>>> attention from a
>>>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>>>>
>>>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>>>
>>>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>>>> any damn
>>>>>>>>>>> thing else in the universe) to its own final state on the
>>>>>>>>>>> basis of
>>>>>>>>>>>
>>>>>>>>>>> the behavior specified by these inputs
>>>>>>>>>>
>>>>>>>>>> Which is stipulated to be H^ applied to <H^>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>
>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>>>>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> If that IS the proper trace, then it doesn't, but H and
>>>>>>>> embedded_H have also failed to decide, because they will NEVER
>>>>>>>> 'abort' their simulation and return an answer.
>>>>>>> That is a proper trace and in the next step embedded_H aborts the
>>>>>>> simulation of its input and transitions to its reject state.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Then the words "Keep on Repeating" are a LIE.
>>>>>>
>>>>>
>>>>> I needed my readers to get one single point from the above sequence
>>>>> that the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>>> own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>
>>>>> It has taken you about three months to get this one single point.
>>>>>
>>>>> Now that you have gotten this point we move on to the next step,
>>>>> embedded_H aborts its simulation and transitions to its own reject
>>>>> state.
>>>>>
>>>>
>>>> The point YOU keep missing is that you have to keep on telling
>>>> half-truths (which is another name for a LIE) to make your statement
>>>> even seem possible.
>>>
>>> I tell one tiny piece of the truth until someone gets it. Then I move
>>> on to the next tiny piece of the truth until someone gets it.
>>
>> Nope, you tell a lot of partial truths where you try to focus the
>> attention on the part that is true, while trying to hide the lies you
>> need to tell to make that one piece true.
>>
>> Like, Yes, you CAN make H^ applied to <H^> non-halting, but when you
>> do, your H / embedded_H now fails to answer.
>>
>>>
>>> It took you three months to understand that the simulated input ⟨Ĥ0⟩
>>> ⟨Ĥ1⟩ to embedded_H never reaches its own final state: ⟨Ĥ0.qy⟩ or
>>> ⟨Ĥ0.qn⟩.
>>
>> Nope, I ALWAYS knew that H^ applied to <H^> could be non-halting (and
>> thus the corret simulation of it is also non-halting) but this ONLY
>> occurs when H fails to answer Qn.
>
> OK back to square one. I will stop talking to you again, it is more
> aggravating than I can tolerate.
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<3964K.3327$1%.3278@fx42.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29778&group=comp.theory#29778

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx42.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
<iW54K.547991$7F2.157695@fx12.iad>
<U72dnQYEnOKgcM3_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <U72dnQYEnOKgcM3_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 168
Message-ID: <3964K.3327$1%.3278@fx42.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 8 Apr 2022 22:26:08 -0400
X-Received-Bytes: 9092
 by: Richard Damon - Sat, 9 Apr 2022 02:26 UTC

On 4/8/22 10:19 PM, olcott wrote:
> On 4/8/2022 9:10 PM, Richard Damon wrote:
>>
>> On 4/8/22 9:46 PM, olcott wrote:
>>> On 4/8/2022 8:31 PM, Richard Damon wrote:
>>>>
>>>> On 4/8/22 9:01 PM, olcott wrote:
>>>>> On 4/8/2022 7:44 PM, Richard Damon wrote:
>>>>>> On 4/8/22 7:34 PM, olcott wrote:
>>>>>>> On 4/8/2022 6:31 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 4/8/22 6:51 PM, olcott wrote:
>>>>>>>>> On 4/8/2022 4:49 PM, Dennis Bush wrote:
>>>>>>>>>> On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But you have no choice but to tolerate it. If someone
>>>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final
>>>>>>>>>>>>> state then this
>>>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>>>> possibly
>>>>>>>>>>>>> contradict this.
>>>>>>>>>>>>
>>>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't
>>>>>>>>>>>> dispute
>>>>>>>>>>>> either (indeed they come from you).
>>>>>>>>>>>>
>>>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>>>> attention from a
>>>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>>>>
>>>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>>>
>>>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>>>> any damn
>>>>>>>>>>> thing else in the universe) to its own final state on the
>>>>>>>>>>> basis of
>>>>>>>>>>>
>>>>>>>>>>> the behavior specified by these inputs
>>>>>>>>>>
>>>>>>>>>> Which is stipulated to be H^ applied to <H^>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ0⟩
>>>>>>>>>     Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
>>>>>>>>>     H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>     Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>     Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>
>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
>>>>>>>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> If that IS the proper trace, then it doesn't, but H and
>>>>>>>> embedded_H have also failed to decide, because they will NEVER
>>>>>>>> 'abort' their simulation and return an answer.
>>>>>>> That is a proper trace and in the next step embedded_H aborts the
>>>>>>> simulation of its input and transitions to its reject state.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Then the words "Keep on Repeating" are a LIE.
>>>>>>
>>>>>
>>>>> I needed my readers to get one single point from the above sequence
>>>>> that the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>>> own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>
>>>>> It has taken you about three months to get this one single point.
>>>>>
>>>>> Now that you have gotten this point we move on to the next step,
>>>>> embedded_H aborts its simulation and transitions to its own reject
>>>>> state.
>>>>>
>>>>
>>>> The point YOU keep missing is that you have to keep on telling
>>>> half-truths (which is another name for a LIE) to make your statement
>>>> even seem possible.
>>>
>>> I tell one tiny piece of the truth until someone gets it. Then I move
>>> on to the next tiny piece of the truth until someone gets it.
>>
>> Nope, you tell a lot of partial truths where you try to focus the
>> attention on the part that is true, while trying to hide the lies you
>> need to tell to make that one piece true.
>>
>> Like, Yes, you CAN make H^ applied to <H^> non-halting, but when you
>> do, your H / embedded_H now fails to answer.
>>
>>>
>>> It took you three months to understand that the simulated input ⟨Ĥ0⟩
>>> ⟨Ĥ1⟩ to embedded_H never reaches its own final state: ⟨Ĥ0.qy⟩ or
>>> ⟨Ĥ0.qn⟩.
>>
>> Nope, I ALWAYS knew that H^ applied to <H^> could be non-halting (and
>> thus the corret simulation of it is also non-halting) but this ONLY
>> occurs when H fails to answer Qn.
>>
>
> So when embedded_H aborts the simulation of its input ⟨Ĥ0⟩ ⟨Ĥ1⟩ this
> completely dead process keeps going until it reaches its own final
> state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ ???
>
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<87ee268n4f.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29780&group=comp.theory#29780

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Sat, 09 Apr 2022 13:20:00 +0100
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <87ee268n4f.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87y20iguq6.fsf@bsb.me.uk>
<Ad-dnXUjt5cmLND_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="2630da725f1c40a67041b54d153ac828";
logging-data="4068"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/y5DDrcSpywMJX9vpTyj1Kw6/0Izkx79Y="
Cancel-Lock: sha1:N0FzxHthXfr9H7WI65gtpAbjgwY=
sha1:8XxEltC7IBvpmPCwL6KIqTQrWuw=
X-BSB-Auth: 1.770b5584f94b1ffc042f.20220409132000BST.87ee268n4f.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 9 Apr 2022 12:20 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>
>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>
>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>> validating my 17 years worth of work.
>>>>>>
>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>> about why you are wrong, they will do so.
>>>>>>
>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>> any of these facts if the mood takes you.)
>>>>>
>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>
>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>> correct despite the fact that P(P) halts. That's wrong.
>>>
>>> If the input to H(P,P) cannot possibly reach its final state then this
>>> input is correctly rejected and nothing in the universe can possibly
>>> contradict this.
>>
>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>> either (indeed they come from you).

At least you don't contend these facts.

>> Your new line in waffle is just an attempt to distract attention from a
>> very simple claim: that the wrong answer is the right one.
>
> Even Linz got this wrong because it is counter-intuitive.
>
> A halt decider must compute the mapping from its inputs (not any damn
> thing else in the universe) to its own final state on the basis of the
> behavior specified by these inputs

That's not counter intuitive, it's basic. Everyone knows this, though
it took you a while to get round to it. A halt decider accepts or
rejects a string based on the behaviour of the computation specified by
that string. Of course, you never got as far in my exercises as
specifying any TM that decides something on the basis of behaviour, so
you really don't know how it's actually done. That was, I thought, the
whole point of the exercises -- to see how TMs are specified to decide
properties of computations.

> (thus their simulated execution
> trace) and not anything else in the universe such as P(P).

Don't be silly. The H/P names refer to your C version in the days
before you even bothered with strings since they were, in your words,
"extraneous complexity". In that words, If H has any pretence of being
a halt decider there must some "input" (i.e. two arguments) that we can
pass to it so that it's decision will be based of the halting or
otherwise of P(P). If H can't report about P(P) it's not a halt
decider.

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<878rse8mpz.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29781&group=comp.theory#29781

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Sat, 09 Apr 2022 13:28:40 +0100
Organization: A noiseless patient Spider
Lines: 19
Message-ID: <878rse8mpz.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<5ba98982-64c6-4169-93d3-170bdff4033fn@googlegroups.com>
<v8ednWienfL2Ic3_nZ2dnUU7_83NnZ2d@giganews.com>
<2B34K.792470$aT3.128169@fx09.iad>
<_YidneB_LP4CW83_nZ2dnUU7_81g4p2d@giganews.com>
<GF44K.31231$r_.15461@fx41.iad>
<A7ednRZ2DIJGR83_nZ2dnUU7_83NnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="2630da725f1c40a67041b54d153ac828";
logging-data="4068"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Hb1v8NWXQ5XxIKfL/4gA3ehEgE8w8kqI="
Cancel-Lock: sha1:6X3Q++vvR2TMfuuciBIBK5ov/Yo=
sha1:gKu5VEINuvpPzVy7OJ1ml8siIDo=
X-BSB-Auth: 1.66e8dbe7e15549c64fa3.20220409132840BST.878rse8mpz.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 9 Apr 2022 12:28 UTC

olcott <NoOne@NoWhere.com> writes:

> I tell one tiny piece of the truth until someone gets it. Then I move
> on to the next tiny piece of the truth until someone gets it.

Oh pull the other one, it's got bells on! Actually, you often tell
massive whoppers and then spend months backpedalling.

There's the "I've got an actual TM" when you didn't. There's the "I
have a halt decider" when you didn't. There's the "two identical TMs
can do different things" when they can't. There "the fact that a
computation halts does not entail that it is a halting computation" when
it does. And these are just the recent ones!

Basically you hose down comp.theory with a spatter gun of nonsense to
see if you can get any of it will stick.

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<t2ruva$1qn8$3@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=29782&group=comp.theory#29782

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!7a25jG6pUKCqa0zKnKnvdg.user.46.165.242.75.POSTED!not-for-mail
From: pyt...@example.invalid (Python)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Date: Sat, 9 Apr 2022 14:42:22 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t2ruva$1qn8$3@gioia.aioe.org>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<8be39aff-211d-4bd8-ab6c-e20c04ce27aan@googlegroups.com>
<o6CdnRI_dqq9pNL_nZ2dnUU7_8xh4p2d@giganews.com>
<a01c542d-a304-4c93-bab0-2754f9107761n@googlegroups.com>
<leudnbOlIa_Z39L_nZ2dnUU7_8zNnZ2d@giganews.com>
<d80b5ae3-7a01-470b-8fd5-2ba0b9155e2fn@googlegroups.com>
<VeOdnVB44dRE3tL_nZ2dnUU7_8xh4p2d@giganews.com>
<f80eca4c-f2a2-4a9c-877e-874e9442c7bfn@googlegroups.com>
<FeKdnbo027NvydL_nZ2dnUU7_83NnZ2d@giganews.com>
<e0ea227c-6761-4a6e-a9c5-eb30304e5c93n@googlegroups.com>
<QI-dncdxv-h6wdL_nZ2dnUU7_8zNnZ2d@giganews.com>
<8a79b5c6-826a-440f-8469-b222c055548dn@googlegroups.com>
<u8CdnXIcU9Va9NL_nZ2dnUU7_8zNnZ2d@giganews.com>
<10c9ba24-251a-4425-8e33-854d56f91ef7n@googlegroups.com>
<WuWdnRn38KCCw83_nZ2dnUU7_83NnZ2d@giganews.com>
<c146edb7-aa55-4c05-8859-343fcc870e14n@googlegroups.com>
<N7qdnbRbV7YE983_nZ2dnUU7_8zNnZ2d@giganews.com> <t2ps9b$t87$2@dont-email.me>
<m5adnTn0-vXQ5M3_nZ2dnUU7_8zNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="60136"; posting-host="7a25jG6pUKCqa0zKnKnvdg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: fr
 by: Python - Sat, 9 Apr 2022 12:42 UTC

Bigot and crank Peter Olcott wrote:
....
> Everything else is the God damned lie of a God damned liar.
>
> When I say "God damned" I mean in the sense of being eternally
> incinerated in actual Hell.
>
> Revelation 21:8 King James Version
> ...all liars, shall have their part in the lake which burneth with fire
> and brimstone: which is the second death.

Then you should start putting your own head into an oven a
few minutes a day, just to prepare yourself to your fate.

Pages:12345678910111213141516171819202122232425262728293031323334353637383940
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor