Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The bigger the theory the better.


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 ]

<8735im7zsl.fsf@bsb.me.uk>

 copy mid

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

 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 21:43:54 +0100
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <8735im7zsl.fsf@bsb.me.uk>
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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="2630da725f1c40a67041b54d153ac828";
logging-data="11333"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182Daxvc/zKth0joMO+nutIBDs24KEW/qE="
Cancel-Lock: sha1:TIpTpLwQYLTHa55D8opCIHHuqp8=
sha1:VeqEiJke+HX3cDUBKPxuWQr3g1c=
X-BSB-Auth: 1.f7c8a2f2222927247372.20220409214354BST.8735im7zsl.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 9 Apr 2022 20:43 UTC

Richard Damon <Richard@Damon-Family.org> writes:

> My interpretation of whats going on it Peter's head is that he doesn't
> understand to concept of something not existing. He seems to have a
> notion that if you can describe something, there must be some way to
> make it.

I agree. I have thought the same for some time. It's an odd sort of
engineering perspective -- if I can conceive it, I can build it.

This is why he thinks Linz is saying that neither answer is correct.
What Linz is really saying -- that there can be no such TM is simply
beyond PO's comprehension.

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ ridiculously stupid ]

<wpm4K.327356$Lbb6.198361@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.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) [
ridiculously stupid ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_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> <878rse8mpz.fsf@bsb.me.uk>
<8qOdnanOrqcPBsz_nZ2dnUU7_81g4p2d@giganews.com>
<esh4K.210689$OT%7.200542@fx07.iad>
<bOudnetnF9vGOcz_nZ2dnUU7_81g4p2d@giganews.com>
<cbk4K.149257$dln7.89696@fx03.iad>
<o7-dnVJPXvNjTcz_nZ2dnUU7_83NnZ2d@giganews.com>
<YCk4K.64531$e%.7672@fx36.iad>
<ntCdnSt0qr7uSsz_nZ2dnUU7_83NnZ2d@giganews.com>
<V1l4K.810561$aT3.662905@fx09.iad>
<7JGdnZEzGrp2Q8z_nZ2dnUU7_8zNnZ2d@giganews.com>
<Gkl4K.564829$7F2.521914@fx12.iad>
<OrWdnfFdxKTdfsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<DNl4K.327353$Lbb6.62351@fx45.iad>
<zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 163
Message-ID: <wpm4K.327356$Lbb6.198361@fx45.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: Sat, 9 Apr 2022 16:55:57 -0400
X-Received-Bytes: 8855
 by: Richard Damon - Sat, 9 Apr 2022 20:55 UTC

On 4/9/22 4:18 PM, olcott wrote:
> On 4/9/2022 3:13 PM, Richard Damon wrote:
>> On 4/9/22 3:49 PM, olcott wrote:
>>> On 4/9/2022 2:42 PM, Richard Damon wrote:
>>>> On 4/9/22 3:30 PM, olcott wrote:
>>>>> On 4/9/2022 2:22 PM, Richard Damon wrote:
>>>>>> On 4/9/22 2:58 PM, olcott wrote:
>>>>>>> On 4/9/2022 1:53 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 4/9/22 2:31 PM, olcott wrote:
>>>>>>>>> On 4/9/2022 1:24 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 4/9/22 11:20 AM, olcott wrote:
>>>>>>>>>>> On 4/9/2022 10:17 AM, Richard Damon wrote:
>>>>>>>>>>>> On 4/9/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>> On 4/9/2022 7:28 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.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⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>>>>>>> embedded_H reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Your right, it doesn't in THAT case,
>>>>>>>>>>>
>>>>>>>>>>> and when embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ it
>>>>>>>>>>> still never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, while embedded_H's simulation never reached thqt state,
>>>>>>>>>> that doesn't matter,
>>>>>>>>> Because the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H would never
>>>>>>>>> reach its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any
>>>>>>>>> condition what-so-ever it is by logical necessity that
>>>>>>>>> embedded_H would be correct to transition to its own reject state.
>>>>>>>>
>>>>>>>> No, that is NOT true. The CORRECT simulation of the input to
>>>>>>>> embedded_H DOES reach its final state if embedded_H goes to its
>>>>>>>> non-halting answer state. This has been established. This is the
>>>>>>>> condition that Halting looks at.
>>>>>>>
>>>>>>> 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⟩
>>>>>>>
>>>>>>> then embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ causing this
>>>>>>> simulated input to immediately stop never ever reaching its own
>>>>>>> final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Nope, and simulator that aborts its simulation my terminate its
>>>>>> own action, but does NOT change the behavior of the input,
>>>>>
>>>>> It is ridiculously stupid to believe that an aborted simulation
>>>>> keeps running after it have been aborted.
>>>>>
>>>>
>>>> You just aren't understanding the words.
>>>>
>>>> I am not saying the ABORTED simulation continues, but the CORRECT
>>>> simulation and the actual machine behavior do, by definition.
>>>
>>> Under no circumstances what-so-ever does the simulated input ⟨Ĥ0⟩
>>> ⟨Ĥ1⟩ to embedded_H meet this Linz criteria of a halting computation:
>>
>> That is just a LIE based on NOT looking at an ACTUAL CORRECT
>> simulation of the input.
>>
>> The ACTUAL behavior of the input to H / embedded_H, the input string
>> <H^> <H^> has been PROVEN to Halt if H / embedded_H reject that input
>> and go to Qn.
>>
>>
>>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>
>> Which means the ACTUAL TURING MACHINE, not a simulation.
>>
>> For this definition, the ONLY thing that the input <H^> <H^> looks at
>> is the actual computation H^ applied to <H^> PERIOD, DEFINITION.
>>
>> Anythibng else can only be used by first showing actual equivalence to
>> that DEFINITION.
>>
>> The 'simulation' of the input by H / embedded_H FAILS to meet that
>> equivalence test if it aborts its simulation, so is irrelevent.
>>
>>>
>>> Therefore people that do not have severe brain damage will understand
>>> that embedded_H would be correct to reject this input as non-halting.
>>>
>>
>> Nope. That you don't understand it just shows that you are the
>> strawman and don't have a brain.
>>
>> Remember the DEFINITION of the correct answer is:
>
> The computation of the mapping of the inputs to an accept or reject
> state based on the actual behavior of these actual inputs.

Right, and the "ACTUAL BEHAVIOR of the input" <H^> <H^< is BY DEFINITION
the behavior of H^ applid to <H^>.

Remember Definition 12.1 H applied to <M> w -> Qy if M applied to w
Halts and -> Qn if M applied to w never halts. Thus the 'behavior' that
H decides on is the behavior of the machine describe by its input.

You keep on wanting to look at the behavior of the simulation by H of
its input instead of the actual behavior of the input to H.

The 'input' is JUST the <H^> <H^> and makes NO reference to H (or
embedded_H) and actually needs to be independent of the machine that is
looking at it.

>
> The actual behavior of the actual input never meets the Linz definition
> of halting under any condition what-so-ever thus is correctly judged as
> a non-halting input.

But it does. You just keep looking at the WRONG behavior.

You don't look at <H^> <H^> and what it represents (H^ applied to <H^>)
but to the behavior of H

>
> You reasoning goes like this: We know that a dog is an animal and we
> know that a cat is an animal therefore a dog is a cat.
>


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

<Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 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: Sat, 09 Apr 2022 15:57:56 -0500
Date: Sat, 9 Apr 2022 15:57: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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <8735im7zsl.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 26
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WKRBBzi3NrVYNgHbUfUKDxS6UvTtx9bM5CxlbwX8W3zfktUyP9Um/u4imuHV5JeE8tRNLca1QLUXicO!sIM0fT5BXR8VpkojPMfy97+Hz9+Otxeure//RW79G4pZALFRGWZSv8qlCng3Oh3yqrECRyy4Mo8L
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: 3023
 by: olcott - Sat, 9 Apr 2022 20:57 UTC

On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> My interpretation of whats going on it Peter's head is that he doesn't
>> understand to concept of something not existing. He seems to have a
>> notion that if you can describe something, there must be some way to
>> make it.
>
> I agree. I have thought the same for some time. It's an odd sort of
> engineering perspective -- if I can conceive it, I can build it.
>
> This is why he thinks Linz is saying that neither answer is correct.
> What Linz is really saying -- that there can be no such TM is simply
> beyond PO's comprehension.
>

He is saying that if embedeed_H accepts or rejects its input a
contradiction is formed. The truth is that when embedded_H rejects its
input no contradiction is formed.

--
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) [ ridiculously stupid ]

<Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

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

 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: Sat, 09 Apr 2022 16:00:10 -0500
Date: Sat, 9 Apr 2022 16:00:08 -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) [
ridiculously stupid ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.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> <878rse8mpz.fsf@bsb.me.uk>
<8qOdnanOrqcPBsz_nZ2dnUU7_81g4p2d@giganews.com>
<esh4K.210689$OT%7.200542@fx07.iad>
<bOudnetnF9vGOcz_nZ2dnUU7_81g4p2d@giganews.com>
<cbk4K.149257$dln7.89696@fx03.iad>
<o7-dnVJPXvNjTcz_nZ2dnUU7_83NnZ2d@giganews.com>
<YCk4K.64531$e%.7672@fx36.iad>
<ntCdnSt0qr7uSsz_nZ2dnUU7_83NnZ2d@giganews.com>
<V1l4K.810561$aT3.662905@fx09.iad>
<7JGdnZEzGrp2Q8z_nZ2dnUU7_8zNnZ2d@giganews.com>
<Gkl4K.564829$7F2.521914@fx12.iad>
<OrWdnfFdxKTdfsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<DNl4K.327353$Lbb6.62351@fx45.iad>
<zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
<wpm4K.327356$Lbb6.198361@fx45.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <wpm4K.327356$Lbb6.198361@fx45.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 164
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-h1OmH/lsmWjAzVNmI7/gE62cFH0VmJBC2ijWnIrQkjJM/wS8BZnDEW+LI7kyyH0wYxQUjVLpiTvUoq1!iHL3cSd1nL9qTOLJOtJxBZP5a0DAJvQJUhstvQcfN9/Xx4c0C4wjnWoh+3NuZxN6XBdeoLc3qXPH
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: 9104
 by: olcott - Sat, 9 Apr 2022 21:00 UTC

On 4/9/2022 3:55 PM, Richard Damon wrote:
> On 4/9/22 4:18 PM, olcott wrote:
>> On 4/9/2022 3:13 PM, Richard Damon wrote:
>>> On 4/9/22 3:49 PM, olcott wrote:
>>>> On 4/9/2022 2:42 PM, Richard Damon wrote:
>>>>> On 4/9/22 3:30 PM, olcott wrote:
>>>>>> On 4/9/2022 2:22 PM, Richard Damon wrote:
>>>>>>> On 4/9/22 2:58 PM, olcott wrote:
>>>>>>>> On 4/9/2022 1:53 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 4/9/22 2:31 PM, olcott wrote:
>>>>>>>>>> On 4/9/2022 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 4/9/22 11:20 AM, olcott wrote:
>>>>>>>>>>>> On 4/9/2022 10:17 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 4/9/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>>> On 4/9/2022 7:28 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.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⟩
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>>>>>>>> embedded_H reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your right, it doesn't in THAT case,
>>>>>>>>>>>>
>>>>>>>>>>>> and when embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ it
>>>>>>>>>>>> still never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope, while embedded_H's simulation never reached thqt state,
>>>>>>>>>>> that doesn't matter,
>>>>>>>>>> Because the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H would
>>>>>>>>>> never reach its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
>>>>>>>>>> any condition what-so-ever it is by logical necessity that
>>>>>>>>>> embedded_H would be correct to transition to its own reject
>>>>>>>>>> state.
>>>>>>>>>
>>>>>>>>> No, that is NOT true. The CORRECT simulation of the input to
>>>>>>>>> embedded_H DOES reach its final state if embedded_H goes to its
>>>>>>>>> non-halting answer state. This has been established. This is
>>>>>>>>> the condition that Halting looks at.
>>>>>>>>
>>>>>>>> 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⟩
>>>>>>>>
>>>>>>>> then embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ causing this
>>>>>>>> simulated input to immediately stop never ever reaching its own
>>>>>>>> final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Nope, and simulator that aborts its simulation my terminate its
>>>>>>> own action, but does NOT change the behavior of the input,
>>>>>>
>>>>>> It is ridiculously stupid to believe that an aborted simulation
>>>>>> keeps running after it have been aborted.
>>>>>>
>>>>>
>>>>> You just aren't understanding the words.
>>>>>
>>>>> I am not saying the ABORTED simulation continues, but the CORRECT
>>>>> simulation and the actual machine behavior do, by definition.
>>>>
>>>> Under no circumstances what-so-ever does the simulated input ⟨Ĥ0⟩
>>>> ⟨Ĥ1⟩ to embedded_H meet this Linz criteria of a halting computation:
>>>
>>> That is just a LIE based on NOT looking at an ACTUAL CORRECT
>>> simulation of the input.
>>>
>>> The ACTUAL behavior of the input to H / embedded_H, the input string
>>> <H^> <H^> has been PROVEN to Halt if H / embedded_H reject that input
>>> and go to Qn.
>>>
>>>
>>>>
>>>> computation that halts … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>
>>> Which means the ACTUAL TURING MACHINE, not a simulation.
>>>
>>> For this definition, the ONLY thing that the input <H^> <H^> looks at
>>> is the actual computation H^ applied to <H^> PERIOD, DEFINITION.
>>>
>>> Anythibng else can only be used by first showing actual equivalence
>>> to that DEFINITION.
>>>
>>> The 'simulation' of the input by H / embedded_H FAILS to meet that
>>> equivalence test if it aborts its simulation, so is irrelevent.
>>>
>>>>
>>>> Therefore people that do not have severe brain damage will
>>>> understand that embedded_H would be correct to reject this input as
>>>> non-halting.
>>>>
>>>
>>> Nope. That you don't understand it just shows that you are the
>>> strawman and don't have a brain.
>>>
>>> Remember the DEFINITION of the correct answer is:
>>
>> The computation of the mapping of the inputs to an accept or reject
>> state based on the actual behavior of these actual inputs.
>
> Right, and the "ACTUAL BEHAVIOR of the input" <H^> <H^< is BY DEFINITION
> the behavior of H^ applid to <H^>.
>
> Remember Definition 12.1 H applied to <M> w -> Qy if M applied to w
> Halts and -> Qn if M applied to w never halts. Thus the 'behavior' that
> H decides on is the behavior of the machine describe by its input.
>
> You keep on wanting to look at the behavior of the simulation by H of
> its input instead of the actual behavior of the input to H.
>
> The 'input' is JUST the <H^> <H^> and makes NO reference to H (or
> embedded_H) and actually needs to be independent of the machine that is
> looking at it.
>
>>
>> The actual behavior of the actual input never meets the Linz
>> definition of halting under any condition what-so-ever thus is
>> correctly judged as a non-halting input.
>
> But it does.


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

<czm4K.562186$LN2.149461@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <8735im7zsl.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 47
Message-ID: <czm4K.562186$LN2.149461@fx13.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: Sat, 9 Apr 2022 17:06:18 -0400
X-Received-Bytes: 3992
 by: Richard Damon - Sat, 9 Apr 2022 21:06 UTC

On 4/9/22 4:43 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> My interpretation of whats going on it Peter's head is that he doesn't
>> understand to concept of something not existing. He seems to have a
>> notion that if you can describe something, there must be some way to
>> make it.
>
> I agree. I have thought the same for some time. It's an odd sort of
> engineering perspective -- if I can conceive it, I can build it.
>
> This is why he thinks Linz is saying that neither answer is correct.
> What Linz is really saying -- that there can be no such TM is simply
> beyond PO's comprehension.
>

Well that is a different dichotomy.

We can either say that NO H, that is a correct Halt Decider, can exist,
or you can say that any prospective Halt Decider that you can think of,
it going to be wrong.

Engineers, can sometimes think better in the second method, I know I can
build something that CLAIMS to be a Halt Decider and that even can do a
lot of the job of a Halt Decider, and thus for 'practical purposes' I
might actually call it a Halt Decider.

I accept that it isn't 100% correct, but maybe it is 'correct enough'
for the task at hand. If we want to automatically load shead baddly
behaving programs, then perhaps missing a few non-halting ones is ok, as
an operator can still catch those, but we save a lot of cycles stopping
the easy to find cases (maybe this is processing student homework
exercises, so we get a lot of mistakes that cause infinite loops).

Maybe even falsely rejecting a very few Halting programs is ok, and
programs that we think might get falsely markd as non-halting we need to
specially mark to make the protection need to be more certain.

That is a perfectly fine engineering version, even though it isn't a
perfectly correct mathematical one.

WIth that mind set, we accept that we have a 'candidate' halt decider H,
and we need to validate it. (and it is often impossible to totally
validate a practical program, but it can be easy to show it is broken)

PO's problem is he just doesn't seem to understand the concept of actual
requirements, and needing to follow them.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ ridiculously stupid ]

<aEm4K.562187$LN2.503847@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.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) [
ridiculously stupid ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@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> <878rse8mpz.fsf@bsb.me.uk>
<8qOdnanOrqcPBsz_nZ2dnUU7_81g4p2d@giganews.com>
<esh4K.210689$OT%7.200542@fx07.iad>
<bOudnetnF9vGOcz_nZ2dnUU7_81g4p2d@giganews.com>
<cbk4K.149257$dln7.89696@fx03.iad>
<o7-dnVJPXvNjTcz_nZ2dnUU7_83NnZ2d@giganews.com>
<YCk4K.64531$e%.7672@fx36.iad>
<ntCdnSt0qr7uSsz_nZ2dnUU7_83NnZ2d@giganews.com>
<V1l4K.810561$aT3.662905@fx09.iad>
<7JGdnZEzGrp2Q8z_nZ2dnUU7_8zNnZ2d@giganews.com>
<Gkl4K.564829$7F2.521914@fx12.iad>
<OrWdnfFdxKTdfsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<DNl4K.327353$Lbb6.62351@fx45.iad>
<zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
<wpm4K.327356$Lbb6.198361@fx45.iad>
<Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 174
Message-ID: <aEm4K.562187$LN2.503847@fx13.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: Sat, 9 Apr 2022 17:11:36 -0400
X-Received-Bytes: 9320
 by: Richard Damon - Sat, 9 Apr 2022 21:11 UTC

On 4/9/22 5:00 PM, olcott wrote:
> On 4/9/2022 3:55 PM, Richard Damon wrote:
>> On 4/9/22 4:18 PM, olcott wrote:
>>> On 4/9/2022 3:13 PM, Richard Damon wrote:
>>>> On 4/9/22 3:49 PM, olcott wrote:
>>>>> On 4/9/2022 2:42 PM, Richard Damon wrote:
>>>>>> On 4/9/22 3:30 PM, olcott wrote:
>>>>>>> On 4/9/2022 2:22 PM, Richard Damon wrote:
>>>>>>>> On 4/9/22 2:58 PM, olcott wrote:
>>>>>>>>> On 4/9/2022 1:53 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 4/9/22 2:31 PM, olcott wrote:
>>>>>>>>>>> On 4/9/2022 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/9/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>> On 4/9/2022 10:17 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 4/9/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>>>> On 4/9/2022 7:28 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.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⟩
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>>>>>>>>> embedded_H reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your right, it doesn't in THAT case,
>>>>>>>>>>>>>
>>>>>>>>>>>>> and when embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ it
>>>>>>>>>>>>> still never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, while embedded_H's simulation never reached thqt
>>>>>>>>>>>> state, that doesn't matter,
>>>>>>>>>>> Because the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H would
>>>>>>>>>>> never reach its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
>>>>>>>>>>> any condition what-so-ever it is by logical necessity that
>>>>>>>>>>> embedded_H would be correct to transition to its own reject
>>>>>>>>>>> state.
>>>>>>>>>>
>>>>>>>>>> No, that is NOT true. The CORRECT simulation of the input to
>>>>>>>>>> embedded_H DOES reach its final state if embedded_H goes to
>>>>>>>>>> its non-halting answer state. This has been established. This
>>>>>>>>>> is the condition that Halting looks at.
>>>>>>>>>
>>>>>>>>> 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⟩
>>>>>>>>>
>>>>>>>>> then embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ causing this
>>>>>>>>> simulated input to immediately stop never ever reaching its own
>>>>>>>>> final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, and simulator that aborts its simulation my terminate its
>>>>>>>> own action, but does NOT change the behavior of the input,
>>>>>>>
>>>>>>> It is ridiculously stupid to believe that an aborted simulation
>>>>>>> keeps running after it have been aborted.
>>>>>>>
>>>>>>
>>>>>> You just aren't understanding the words.
>>>>>>
>>>>>> I am not saying the ABORTED simulation continues, but the CORRECT
>>>>>> simulation and the actual machine behavior do, by definition.
>>>>>
>>>>> Under no circumstances what-so-ever does the simulated input ⟨Ĥ0⟩
>>>>> ⟨Ĥ1⟩ to embedded_H meet this Linz criteria of a halting computation:
>>>>
>>>> That is just a LIE based on NOT looking at an ACTUAL CORRECT
>>>> simulation of the input.
>>>>
>>>> The ACTUAL behavior of the input to H / embedded_H, the input string
>>>> <H^> <H^> has been PROVEN to Halt if H / embedded_H reject that
>>>> input and go to Qn.
>>>>
>>>>
>>>>>
>>>>> computation that halts … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> Which means the ACTUAL TURING MACHINE, not a simulation.
>>>>
>>>> For this definition, the ONLY thing that the input <H^> <H^> looks
>>>> at is the actual computation H^ applied to <H^> PERIOD, DEFINITION.
>>>>
>>>> Anythibng else can only be used by first showing actual equivalence
>>>> to that DEFINITION.
>>>>
>>>> The 'simulation' of the input by H / embedded_H FAILS to meet that
>>>> equivalence test if it aborts its simulation, so is irrelevent.
>>>>
>>>>>
>>>>> Therefore people that do not have severe brain damage will
>>>>> understand that embedded_H would be correct to reject this input as
>>>>> non-halting.
>>>>>
>>>>
>>>> Nope. That you don't understand it just shows that you are the
>>>> strawman and don't have a brain.
>>>>
>>>> Remember the DEFINITION of the correct answer is:
>>>
>>> The computation of the mapping of the inputs to an accept or reject
>>> state based on the actual behavior of these actual inputs.
>>
>> Right, and the "ACTUAL BEHAVIOR of the input" <H^> <H^< is BY
>> DEFINITION the behavior of H^ applid to <H^>.
>>
>> Remember Definition 12.1 H applied to <M> w -> Qy if M applied to w
>> Halts and -> Qn if M applied to w never halts. Thus the 'behavior'
>> that H decides on is the behavior of the machine describe by its input.
>>
>> You keep on wanting to look at the behavior of the simulation by H of
>> its input instead of the actual behavior of the input to H.
>>
>> The 'input' is JUST the <H^> <H^> and makes NO reference to H (or
>> embedded_H) and actually needs to be independent of the machine that
>> is looking at it.
>>
>>>
>>> The actual behavior of the actual input never meets the Linz
>>> definition of halting under any condition what-so-ever thus is
>>> correctly judged as a non-halting input.
>>
>> But it does.
>
> The actual input is ⟨Ĥ0⟩ ⟨Ĥ1⟩.


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

<MrWdnYre_oxZa8z_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 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: Sat, 09 Apr 2022 16:12:35 -0500
Date: Sat, 9 Apr 2022 16:12: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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <czm4K.562186$LN2.149461@fx13.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <czm4K.562186$LN2.149461@fx13.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <MrWdnYre_oxZa8z_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 30
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-lYK7PpNPkJ9KiBiAWMcnCNRf7f0x48Q9ZbQOyx1rYJYlyr0Uw2e/XVy4zf22lp4LBRS8xmhUJQr5Cpi!JPsp65uVEmezcYwMHThAjALOGr8bNmMJtZ7agKVvCCyIxG8shS/DL1R3RJ/4AoDZ9axyy+YObhjg
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: 3223
 by: olcott - Sat, 9 Apr 2022 21:12 UTC

On 4/9/2022 4:06 PM, Richard Damon wrote:
> On 4/9/22 4:43 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> My interpretation of whats going on it Peter's head is that he doesn't
>>> understand to concept of something not existing. He seems to have a
>>> notion that if you can describe something, there must be some way to
>>> make it.
>>
>> I agree.  I have thought the same for some time.  It's an odd sort of
>> engineering perspective -- if I can conceive it, I can build it.
>>
>> This is why he thinks Linz is saying that neither answer is correct.
>> What Linz is really saying -- that there can be no such TM is simply
>> beyond PO's comprehension.
>>
>
> Well that is a different dichotomy.
>
> We can either say that NO H, that is a correct Halt Decider, can exist,
> or you can say that any prospective Halt Decider that you can think of,
> it going to be wrong.
This is the first thing that you said that I agree.

--
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) [ ridiculously stupid ]

<07Cdnbe0F50Basz_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 16:16:12 -0500
Date: Sat, 9 Apr 2022 16:16:09 -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) [
ridiculously stupid ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@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> <878rse8mpz.fsf@bsb.me.uk>
<8qOdnanOrqcPBsz_nZ2dnUU7_81g4p2d@giganews.com>
<esh4K.210689$OT%7.200542@fx07.iad>
<bOudnetnF9vGOcz_nZ2dnUU7_81g4p2d@giganews.com>
<cbk4K.149257$dln7.89696@fx03.iad>
<o7-dnVJPXvNjTcz_nZ2dnUU7_83NnZ2d@giganews.com>
<YCk4K.64531$e%.7672@fx36.iad>
<ntCdnSt0qr7uSsz_nZ2dnUU7_83NnZ2d@giganews.com>
<V1l4K.810561$aT3.662905@fx09.iad>
<7JGdnZEzGrp2Q8z_nZ2dnUU7_8zNnZ2d@giganews.com>
<Gkl4K.564829$7F2.521914@fx12.iad>
<OrWdnfFdxKTdfsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<DNl4K.327353$Lbb6.62351@fx45.iad>
<zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
<wpm4K.327356$Lbb6.198361@fx45.iad>
<Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>
<aEm4K.562187$LN2.503847@fx13.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <aEm4K.562187$LN2.503847@fx13.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <07Cdnbe0F50Basz_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 183
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-vRpXTZ8lKNoV7aMSJBPoNQnxtyH/9DEgyP8cY3a94wxx5LBJzS8fmhEe2BalXJ5cqSvpxl6JAjfSMd4!ZIbmqcyuCg5PGBXWG3yh83SqpOgstc3TmpN7SZYhWcjSWCG/Bl94+jADDBwOyTBLSc+oLIaoOWwi
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: 10126
 by: olcott - Sat, 9 Apr 2022 21:16 UTC

On 4/9/2022 4:11 PM, Richard Damon wrote:
>
> On 4/9/22 5:00 PM, olcott wrote:
>> On 4/9/2022 3:55 PM, Richard Damon wrote:
>>> On 4/9/22 4:18 PM, olcott wrote:
>>>> On 4/9/2022 3:13 PM, Richard Damon wrote:
>>>>> On 4/9/22 3:49 PM, olcott wrote:
>>>>>> On 4/9/2022 2:42 PM, Richard Damon wrote:
>>>>>>> On 4/9/22 3:30 PM, olcott wrote:
>>>>>>>> On 4/9/2022 2:22 PM, Richard Damon wrote:
>>>>>>>>> On 4/9/22 2:58 PM, olcott wrote:
>>>>>>>>>> On 4/9/2022 1:53 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 4/9/22 2:31 PM, olcott wrote:
>>>>>>>>>>>> On 4/9/2022 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/9/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>>> On 4/9/2022 10:17 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 4/9/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 4/9/2022 7:28 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ĥ.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⟩
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>>>>>>>>>> embedded_H reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your right, it doesn't in THAT case,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and when embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ it
>>>>>>>>>>>>>> still never reaches its own final state of ⟨Ĥ0.qy⟩ or
>>>>>>>>>>>>>> ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, while embedded_H's simulation never reached thqt
>>>>>>>>>>>>> state, that doesn't matter,
>>>>>>>>>>>> Because the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H would
>>>>>>>>>>>> never reach its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
>>>>>>>>>>>> any condition what-so-ever it is by logical necessity that
>>>>>>>>>>>> embedded_H would be correct to transition to its own reject
>>>>>>>>>>>> state.
>>>>>>>>>>>
>>>>>>>>>>> No, that is NOT true. The CORRECT simulation of the input to
>>>>>>>>>>> embedded_H DOES reach its final state if embedded_H goes to
>>>>>>>>>>> its non-halting answer state. This has been established. This
>>>>>>>>>>> is the condition that Halting looks at.
>>>>>>>>>>
>>>>>>>>>> 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⟩
>>>>>>>>>>
>>>>>>>>>> then embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ causing
>>>>>>>>>> this simulated input to immediately stop never ever reaching
>>>>>>>>>> its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nope, and simulator that aborts its simulation my terminate its
>>>>>>>>> own action, but does NOT change the behavior of the input,
>>>>>>>>
>>>>>>>> It is ridiculously stupid to believe that an aborted simulation
>>>>>>>> keeps running after it have been aborted.
>>>>>>>>
>>>>>>>
>>>>>>> You just aren't understanding the words.
>>>>>>>
>>>>>>> I am not saying the ABORTED simulation continues, but the CORRECT
>>>>>>> simulation and the actual machine behavior do, by definition.
>>>>>>
>>>>>> Under no circumstances what-so-ever does the simulated input ⟨Ĥ0⟩
>>>>>> ⟨Ĥ1⟩ to embedded_H meet this Linz criteria of a halting computation:
>>>>>
>>>>> That is just a LIE based on NOT looking at an ACTUAL CORRECT
>>>>> simulation of the input.
>>>>>
>>>>> The ACTUAL behavior of the input to H / embedded_H, the input
>>>>> string <H^> <H^> has been PROVEN to Halt if H / embedded_H reject
>>>>> that input and go to Qn.
>>>>>
>>>>>
>>>>>>
>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> Which means the ACTUAL TURING MACHINE, not a simulation.
>>>>>
>>>>> For this definition, the ONLY thing that the input <H^> <H^> looks
>>>>> at is the actual computation H^ applied to <H^> PERIOD, DEFINITION.
>>>>>
>>>>> Anythibng else can only be used by first showing actual equivalence
>>>>> to that DEFINITION.
>>>>>
>>>>> The 'simulation' of the input by H / embedded_H FAILS to meet that
>>>>> equivalence test if it aborts its simulation, so is irrelevent.
>>>>>
>>>>>>
>>>>>> Therefore people that do not have severe brain damage will
>>>>>> understand that embedded_H would be correct to reject this input
>>>>>> as non-halting.
>>>>>>
>>>>>
>>>>> Nope. That you don't understand it just shows that you are the
>>>>> strawman and don't have a brain.
>>>>>
>>>>> Remember the DEFINITION of the correct answer is:
>>>>
>>>> The computation of the mapping of the inputs to an accept or reject
>>>> state based on the actual behavior of these actual inputs.
>>>
>>> Right, and the "ACTUAL BEHAVIOR of the input" <H^> <H^< is BY
>>> DEFINITION the behavior of H^ applid to <H^>.
>>>
>>> Remember Definition 12.1 H applied to <M> w -> Qy if M applied to w
>>> Halts and -> Qn if M applied to w never halts. Thus the 'behavior'
>>> that H decides on is the behavior of the machine describe by its input.
>>>
>>> You keep on wanting to look at the behavior of the simulation by H of
>>> its input instead of the actual behavior of the input to H.
>>>
>>> The 'input' is JUST the <H^> <H^> and makes NO reference to H (or
>>> embedded_H) and actually needs to be independent of the machine that
>>> is looking at it.
>>>
>>>>
>>>> The actual behavior of the actual input never meets the Linz
>>>> definition of halting under any condition what-so-ever thus is
>>>> correctly judged as a non-halting input.
>>>
>>> But it does.
>>
>> The actual input is ⟨Ĥ0⟩ ⟨Ĥ1⟩.
>
> But ALL <H^i> are the exact same string, so ALL copies act the same.
>
>>
>> The actual behavior of this input is non-halting and you already
>> admitted this.
>
> Nope, I have PROVED that it is halting if H rejects this 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 ]

<JKm4K.349131$Gojc.128381@fx99.iad>

 copy mid

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

 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!fx99.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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 52
Message-ID: <JKm4K.349131$Gojc.128381@fx99.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: Sat, 9 Apr 2022 17:18:35 -0400
X-Received-Bytes: 3931
 by: Richard Damon - Sat, 9 Apr 2022 21:18 UTC

On 4/9/22 4:57 PM, olcott wrote:
> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> My interpretation of whats going on it Peter's head is that he doesn't
>>> understand to concept of something not existing. He seems to have a
>>> notion that if you can describe something, there must be some way to
>>> make it.
>>
>> I agree.  I have thought the same for some time.  It's an odd sort of
>> engineering perspective -- if I can conceive it, I can build it.
>>
>> This is why he thinks Linz is saying that neither answer is correct.
>> What Linz is really saying -- that there can be no such TM is simply
>> beyond PO's comprehension.
>>
>
> He is saying that if embedeed_H accepts or rejects its input a
> contradiction is formed. The truth is that when embedded_H rejects its
> input no contradiction is formed.
>

Tou just don't understand the contradiction.

If H / embedded_H reject the input, the machine it represents must be
non-halting, but if H / embedded_H reject the input, the machine it
represents is Halting.

H^ applied to <H^> can't be both Halting and Non-Halting, thus there is
a contradiction.

You 'forget' that the input <H^> <H^> represents the Machine H^ applied
to <H^> (or LIE and claim it doesn't).

THE DEFINITION of H is that H applied to <M> w will go to Qn only if M
applied to w is non-halting.

That means that by definition H applied to <H^> <H^> will go to Qn only
if H^ applied to <H^> is Non-Halting.

But, by the design H^ applied to <H^> will use its copy of H, that will
do exactly the same thing as the independent machine H would do, and
apply it to <H^> <H^>, and if that copy of H rejects the input (saying
it is non-halting) it Halts, and makes that input represent a Halting
Computation.

Thus, we have the contradiction, If H is correct, then H^ applied to
<H^> can't have H go to its reject state and then H^ Halt, and that says
that H^ applied to <H^> is both Halting and Non-Halting, thus no such H
can exist.

FAIL.

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

<O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 16:24:03 -0500
Date: Sat, 9 Apr 2022 16:24:00 -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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<JKm4K.349131$Gojc.128381@fx99.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <JKm4K.349131$Gojc.128381@fx99.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 36
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-yX5hOwtu0dP2d/4c5lHzLlhqubSd4q7AETYIWZ5fk2npPZsfEkmbG0WB1O7K/PjgiMco95gtnph80lf!qF/STT6CHxLEsdEcUQ9RFlu0v9/Ms243Lhh6USOdn1NqwRaOm6Hc6tRjBnIWp2FahibiKxOuHPDV
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: 3515
 by: olcott - Sat, 9 Apr 2022 21:24 UTC

On 4/9/2022 4:18 PM, Richard Damon wrote:
> On 4/9/22 4:57 PM, olcott wrote:
>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> My interpretation of whats going on it Peter's head is that he doesn't
>>>> understand to concept of something not existing. He seems to have a
>>>> notion that if you can describe something, there must be some way to
>>>> make it.
>>>
>>> I agree.  I have thought the same for some time.  It's an odd sort of
>>> engineering perspective -- if I can conceive it, I can build it.
>>>
>>> This is why he thinks Linz is saying that neither answer is correct.
>>> What Linz is really saying -- that there can be no such TM is simply
>>> beyond PO's comprehension.
>>>
>>
>> He is saying that if embedeed_H accepts or rejects its input a
>> contradiction is formed. The truth is that when embedded_H rejects its
>> input no contradiction is formed.
>>
>
> Tou just don't understand the contradiction.
Watch the front door for white dogs coming into the living room (the
actual behavior of the actual input).

A black cat came in the back door into the kitchen so the halt decider
is wrong. (behavior of non inputs).

--
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 ]

<5Sm4K.359681$f2a5.198994@fx48.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx48.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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <czm4K.562186$LN2.149461@fx13.iad>
<MrWdnYre_oxZa8z_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <MrWdnYre_oxZa8z_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 59
Message-ID: <5Sm4K.359681$f2a5.198994@fx48.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: Sat, 9 Apr 2022 17:26:26 -0400
X-Received-Bytes: 4193
 by: Richard Damon - Sat, 9 Apr 2022 21:26 UTC

On 4/9/22 5:12 PM, olcott wrote:
> On 4/9/2022 4:06 PM, Richard Damon wrote:
>> On 4/9/22 4:43 PM, Ben Bacarisse wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> My interpretation of whats going on it Peter's head is that he doesn't
>>>> understand to concept of something not existing. He seems to have a
>>>> notion that if you can describe something, there must be some way to
>>>> make it.
>>>
>>> I agree.  I have thought the same for some time.  It's an odd sort of
>>> engineering perspective -- if I can conceive it, I can build it.
>>>
>>> This is why he thinks Linz is saying that neither answer is correct.
>>> What Linz is really saying -- that there can be no such TM is simply
>>> beyond PO's comprehension.
>>>
>>
>> Well that is a different dichotomy.
>>
>> We can either say that NO H, that is a correct Halt Decider, can
>> exist, or you can say that any prospective Halt Decider that you can
>> think of, it going to be wrong.
> This is the first thing that you said that I agree.
>

So you agree that your 'prospective' Halt Decider H / embedded_H needs
to be tested by the definition/requirements, and it has been show that
it FAILS.

Requirement:

H applied to <M> w only goes to Qn if M applied to w Never Halts.

Test Case

H applied to <H^> <H^>, by the requirement, H can only go to Qn if H^
applied to <H^> will never halt.

Your claimed 'correct' output REJECT (go to Qn)

But, from the design of H^, H^ applied to <H^> will use a copy of H,
which will behave just like all other copies of H applied to the same
input, and apply it to <H^> <H^>, and when that copy of H rejects its
input, this copy of H^ will Halt.

Thus we have shown that given H applied to <H^> <H^> -> Qn that we have
that H^ applied to <H^> will Halt.

By the requirements stated above, H applied to <H^> <H^ could only go to
Qn if H^ applied to <H^> never halts, but we just showed it did halt and
thus H has FAILED its test.

Note, there is no looking at other possible H's to says that none of
them could have simulated the input to a halting state, we are testing
THIS SPECIFIC H that you have brought to the table, which you claim goes
to Qn when this H is applied to <H^> <H^> for the H^ built on it.

IT FAILS.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ ridiculously stupid ]

<AZm4K.327357$Lbb6.233639@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!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!fx45.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) [
ridiculously stupid ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@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> <878rse8mpz.fsf@bsb.me.uk>
<8qOdnanOrqcPBsz_nZ2dnUU7_81g4p2d@giganews.com>
<esh4K.210689$OT%7.200542@fx07.iad>
<bOudnetnF9vGOcz_nZ2dnUU7_81g4p2d@giganews.com>
<cbk4K.149257$dln7.89696@fx03.iad>
<o7-dnVJPXvNjTcz_nZ2dnUU7_83NnZ2d@giganews.com>
<YCk4K.64531$e%.7672@fx36.iad>
<ntCdnSt0qr7uSsz_nZ2dnUU7_83NnZ2d@giganews.com>
<V1l4K.810561$aT3.662905@fx09.iad>
<7JGdnZEzGrp2Q8z_nZ2dnUU7_8zNnZ2d@giganews.com>
<Gkl4K.564829$7F2.521914@fx12.iad>
<OrWdnfFdxKTdfsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<DNl4K.327353$Lbb6.62351@fx45.iad>
<zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
<wpm4K.327356$Lbb6.198361@fx45.iad>
<Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>
<aEm4K.562187$LN2.503847@fx13.iad>
<07Cdnbe0F50Basz_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <07Cdnbe0F50Basz_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 203
Message-ID: <AZm4K.327357$Lbb6.233639@fx45.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: Sat, 9 Apr 2022 17:34:26 -0400
X-Received-Bytes: 10969
 by: Richard Damon - Sat, 9 Apr 2022 21:34 UTC

On 4/9/22 5:16 PM, olcott wrote:
> On 4/9/2022 4:11 PM, Richard Damon wrote:
>>
>> On 4/9/22 5:00 PM, olcott wrote:
>>> On 4/9/2022 3:55 PM, Richard Damon wrote:
>>>> On 4/9/22 4:18 PM, olcott wrote:
>>>>> On 4/9/2022 3:13 PM, Richard Damon wrote:
>>>>>> On 4/9/22 3:49 PM, olcott wrote:
>>>>>>> On 4/9/2022 2:42 PM, Richard Damon wrote:
>>>>>>>> On 4/9/22 3:30 PM, olcott wrote:
>>>>>>>>> On 4/9/2022 2:22 PM, Richard Damon wrote:
>>>>>>>>>> On 4/9/22 2:58 PM, olcott wrote:
>>>>>>>>>>> On 4/9/2022 1:53 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/9/22 2:31 PM, olcott wrote:
>>>>>>>>>>>>> On 4/9/2022 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/9/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>>>> On 4/9/2022 10:17 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 4/9/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 4/9/2022 7:28 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ĥ.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⟩
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>>>>>>>>>>> embedded_H reaches its own final state: ⟨Ĥ0.qy⟩ or
>>>>>>>>>>>>>>>>> ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your right, it doesn't in THAT case,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and when embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ it
>>>>>>>>>>>>>>> still never reaches its own final state of ⟨Ĥ0.qy⟩ or
>>>>>>>>>>>>>>> ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, while embedded_H's simulation never reached thqt
>>>>>>>>>>>>>> state, that doesn't matter,
>>>>>>>>>>>>> Because the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H would
>>>>>>>>>>>>> never reach its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
>>>>>>>>>>>>> any condition what-so-ever it is by logical necessity that
>>>>>>>>>>>>> embedded_H would be correct to transition to its own reject
>>>>>>>>>>>>> state.
>>>>>>>>>>>>
>>>>>>>>>>>> No, that is NOT true. The CORRECT simulation of the input to
>>>>>>>>>>>> embedded_H DOES reach its final state if embedded_H goes to
>>>>>>>>>>>> its non-halting answer state. This has been established.
>>>>>>>>>>>> This is the condition that Halting looks at.
>>>>>>>>>>>
>>>>>>>>>>> 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⟩
>>>>>>>>>>>
>>>>>>>>>>> then embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ causing
>>>>>>>>>>> this simulated input to immediately stop never ever reaching
>>>>>>>>>>> its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, and simulator that aborts its simulation my terminate
>>>>>>>>>> its own action, but does NOT change the behavior of the input,
>>>>>>>>>
>>>>>>>>> It is ridiculously stupid to believe that an aborted simulation
>>>>>>>>> keeps running after it have been aborted.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You just aren't understanding the words.
>>>>>>>>
>>>>>>>> I am not saying the ABORTED simulation continues, but the
>>>>>>>> CORRECT simulation and the actual machine behavior do, by
>>>>>>>> definition.
>>>>>>>
>>>>>>> Under no circumstances what-so-ever does the simulated input ⟨Ĥ0⟩
>>>>>>> ⟨Ĥ1⟩ to embedded_H meet this Linz criteria of a halting computation:
>>>>>>
>>>>>> That is just a LIE based on NOT looking at an ACTUAL CORRECT
>>>>>> simulation of the input.
>>>>>>
>>>>>> The ACTUAL behavior of the input to H / embedded_H, the input
>>>>>> string <H^> <H^> has been PROVEN to Halt if H / embedded_H reject
>>>>>> that input and go to Qn.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>
>>>>>> Which means the ACTUAL TURING MACHINE, not a simulation.
>>>>>>
>>>>>> For this definition, the ONLY thing that the input <H^> <H^> looks
>>>>>> at is the actual computation H^ applied to <H^> PERIOD, DEFINITION.
>>>>>>
>>>>>> Anythibng else can only be used by first showing actual
>>>>>> equivalence to that DEFINITION.
>>>>>>
>>>>>> The 'simulation' of the input by H / embedded_H FAILS to meet that
>>>>>> equivalence test if it aborts its simulation, so is irrelevent.
>>>>>>
>>>>>>>
>>>>>>> Therefore people that do not have severe brain damage will
>>>>>>> understand that embedded_H would be correct to reject this input
>>>>>>> as non-halting.
>>>>>>>
>>>>>>
>>>>>> Nope. That you don't understand it just shows that you are the
>>>>>> strawman and don't have a brain.
>>>>>>
>>>>>> Remember the DEFINITION of the correct answer is:
>>>>>
>>>>> The computation of the mapping of the inputs to an accept or reject
>>>>> state based on the actual behavior of these actual inputs.
>>>>
>>>> Right, and the "ACTUAL BEHAVIOR of the input" <H^> <H^< is BY
>>>> DEFINITION the behavior of H^ applid to <H^>.
>>>>
>>>> Remember Definition 12.1 H applied to <M> w -> Qy if M applied to w
>>>> Halts and -> Qn if M applied to w never halts. Thus the 'behavior'
>>>> that H decides on is the behavior of the machine describe by its input.
>>>>
>>>> You keep on wanting to look at the behavior of the simulation by H
>>>> of its input instead of the actual behavior of the input to H.
>>>>
>>>> The 'input' is JUST the <H^> <H^> and makes NO reference to H (or
>>>> embedded_H) and actually needs to be independent of the machine that
>>>> is looking at it.
>>>>
>>>>>
>>>>> The actual behavior of the actual input never meets the Linz
>>>>> definition of halting under any condition what-so-ever thus is
>>>>> correctly judged as a non-halting input.
>>>>
>>>> But it does.
>>>
>>> The actual input is ⟨Ĥ0⟩ ⟨Ĥ1⟩.
>>
>> But ALL <H^i> are the exact same string, so ALL copies act the same.
>>
>>>
>>> The actual behavior of this input is non-halting and you already
>>> admitted this.
>>
>> Nope, I have PROVED that it is halting if H rejects this input.
>
> 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⟩
> then embedded_H rejects ⟨Ĥ0⟩ ⟨Ĥ1⟩
>
> Show how ⟨Ĥ0⟩ reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>
Remember ALL <H^i> are the same, so we can look at the above and see
that the ACTUAL BEHAVIOR of <H^0> <H^1> would be:


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

<y1n4K.544956$mF2.32160@fx11.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<JKm4K.349131$Gojc.128381@fx99.iad>
<O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 54
Message-ID: <y1n4K.544956$mF2.32160@fx11.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: Sat, 9 Apr 2022 17:38:39 -0400
X-Received-Bytes: 3937
 by: Richard Damon - Sat, 9 Apr 2022 21:38 UTC

On 4/9/22 5:24 PM, olcott wrote:
> On 4/9/2022 4:18 PM, Richard Damon wrote:
>> On 4/9/22 4:57 PM, olcott wrote:
>>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> My interpretation of whats going on it Peter's head is that he doesn't
>>>>> understand to concept of something not existing. He seems to have a
>>>>> notion that if you can describe something, there must be some way to
>>>>> make it.
>>>>
>>>> I agree.  I have thought the same for some time.  It's an odd sort of
>>>> engineering perspective -- if I can conceive it, I can build it.
>>>>
>>>> This is why he thinks Linz is saying that neither answer is correct.
>>>> What Linz is really saying -- that there can be no such TM is simply
>>>> beyond PO's comprehension.
>>>>
>>>
>>> He is saying that if embedeed_H accepts or rejects its input a
>>> contradiction is formed. The truth is that when embedded_H rejects
>>> its input no contradiction is formed.
>>>
>>
>> Tou just don't understand the contradiction.
> Watch the front door for white dogs coming into the living room (the
> actual behavior of the actual input).
>
> A black cat came in the back door into the kitchen so the halt decider
> is wrong. (behavior of non inputs).
>

Nope. you have your analogy backwards.

BY DEFINITION, the 'white dog' is teh behavior of H^ applied to <H^>,
and that halts.

Your guards are looking at 'black cats' which are the behavior of the
simulation of the input possibly aborted by H/embedded_H.

Remember the definition 12.1

H applied to <M> w -> Qn iff M applied to w Halts and -> Qn if M applied
to w never halts.

The front door is M applied to w, or for this case, H^ applied to <H^>,
which you have even admitted halts, but you just claim it isn't what you
should be looking at because you ignore your instructions and look for
the wrong things.

You need to clean up the messs you POOP leaves behind.

FAIL.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ ridiculously stupid ]

<QNKdnSFSIYpVYMz_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 16:42:32 -0500
Date: Sat, 9 Apr 2022 16:42:29 -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) [
ridiculously stupid ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@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> <878rse8mpz.fsf@bsb.me.uk>
<8qOdnanOrqcPBsz_nZ2dnUU7_81g4p2d@giganews.com>
<esh4K.210689$OT%7.200542@fx07.iad>
<bOudnetnF9vGOcz_nZ2dnUU7_81g4p2d@giganews.com>
<cbk4K.149257$dln7.89696@fx03.iad>
<o7-dnVJPXvNjTcz_nZ2dnUU7_83NnZ2d@giganews.com>
<YCk4K.64531$e%.7672@fx36.iad>
<ntCdnSt0qr7uSsz_nZ2dnUU7_83NnZ2d@giganews.com>
<V1l4K.810561$aT3.662905@fx09.iad>
<7JGdnZEzGrp2Q8z_nZ2dnUU7_8zNnZ2d@giganews.com>
<Gkl4K.564829$7F2.521914@fx12.iad>
<OrWdnfFdxKTdfsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<DNl4K.327353$Lbb6.62351@fx45.iad>
<zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
<wpm4K.327356$Lbb6.198361@fx45.iad>
<Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>
<aEm4K.562187$LN2.503847@fx13.iad>
<07Cdnbe0F50Basz_nZ2dnUU7_8zNnZ2d@giganews.com>
<AZm4K.327357$Lbb6.233639@fx45.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <AZm4K.327357$Lbb6.233639@fx45.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <QNKdnSFSIYpVYMz_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 208
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-8UKntgJanpldCdEx6hl8Ct1gL6BJPGdBLCteqfCmlMcY5Y8V0bQsJouuTIXjlNKCxNkfAtrwbTwMUf7!jUm9ZenY//u8EW+JAMCsksZrTEvHpy/jDiYJ44wLeDSeWmX566C6gYdJlQp0qBHxJsRNYejv7WHz
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: 11324
 by: olcott - Sat, 9 Apr 2022 21:42 UTC

On 4/9/2022 4:34 PM, Richard Damon wrote:
>
> On 4/9/22 5:16 PM, olcott wrote:
>> On 4/9/2022 4:11 PM, Richard Damon wrote:
>>>
>>> On 4/9/22 5:00 PM, olcott wrote:
>>>> On 4/9/2022 3:55 PM, Richard Damon wrote:
>>>>> On 4/9/22 4:18 PM, olcott wrote:
>>>>>> On 4/9/2022 3:13 PM, Richard Damon wrote:
>>>>>>> On 4/9/22 3:49 PM, olcott wrote:
>>>>>>>> On 4/9/2022 2:42 PM, Richard Damon wrote:
>>>>>>>>> On 4/9/22 3:30 PM, olcott wrote:
>>>>>>>>>> On 4/9/2022 2:22 PM, Richard Damon wrote:
>>>>>>>>>>> On 4/9/22 2:58 PM, olcott wrote:
>>>>>>>>>>>> On 4/9/2022 1:53 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/9/22 2:31 PM, olcott wrote:
>>>>>>>>>>>>>> On 4/9/2022 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/9/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 4/9/2022 10:17 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 4/9/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 4/9/2022 7:28 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ĥ.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⟩
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>>>>>>>>>>>> embedded_H reaches its own final state: ⟨Ĥ0.qy⟩ or
>>>>>>>>>>>>>>>>>> ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Your right, it doesn't in THAT case,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and when embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>>>>>> it still never reaches its own final state of ⟨Ĥ0.qy⟩ or
>>>>>>>>>>>>>>>> ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, while embedded_H's simulation never reached thqt
>>>>>>>>>>>>>>> state, that doesn't matter,
>>>>>>>>>>>>>> Because the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H would
>>>>>>>>>>>>>> never reach its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>>>>>>>>>>>>> under any condition what-so-ever it is by logical
>>>>>>>>>>>>>> necessity that embedded_H would be correct to transition
>>>>>>>>>>>>>> to its own reject state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, that is NOT true. The CORRECT simulation of the input
>>>>>>>>>>>>> to embedded_H DOES reach its final state if embedded_H goes
>>>>>>>>>>>>> to its non-halting answer state. This has been established.
>>>>>>>>>>>>> This is the condition that Halting looks at.
>>>>>>>>>>>>
>>>>>>>>>>>> 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⟩
>>>>>>>>>>>>
>>>>>>>>>>>> then embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ causing
>>>>>>>>>>>> this simulated input to immediately stop never ever reaching
>>>>>>>>>>>> its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope, and simulator that aborts its simulation my terminate
>>>>>>>>>>> its own action, but does NOT change the behavior of the input,
>>>>>>>>>>
>>>>>>>>>> It is ridiculously stupid to believe that an aborted
>>>>>>>>>> simulation keeps running after it have been aborted.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You just aren't understanding the words.
>>>>>>>>>
>>>>>>>>> I am not saying the ABORTED simulation continues, but the
>>>>>>>>> CORRECT simulation and the actual machine behavior do, by
>>>>>>>>> definition.
>>>>>>>>
>>>>>>>> Under no circumstances what-so-ever does the simulated input
>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H meet this Linz criteria of a halting
>>>>>>>> computation:
>>>>>>>
>>>>>>> That is just a LIE based on NOT looking at an ACTUAL CORRECT
>>>>>>> simulation of the input.
>>>>>>>
>>>>>>> The ACTUAL behavior of the input to H / embedded_H, the input
>>>>>>> string <H^> <H^> has been PROVEN to Halt if H / embedded_H reject
>>>>>>> that input and go to Qn.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> computation that halts … the Turing machine will halt whenever
>>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> Which means the ACTUAL TURING MACHINE, not a simulation.
>>>>>>>
>>>>>>> For this definition, the ONLY thing that the input <H^> <H^>
>>>>>>> looks at is the actual computation H^ applied to <H^> PERIOD,
>>>>>>> DEFINITION.
>>>>>>>
>>>>>>> Anythibng else can only be used by first showing actual
>>>>>>> equivalence to that DEFINITION.
>>>>>>>
>>>>>>> The 'simulation' of the input by H / embedded_H FAILS to meet
>>>>>>> that equivalence test if it aborts its simulation, so is irrelevent.
>>>>>>>
>>>>>>>>
>>>>>>>> Therefore people that do not have severe brain damage will
>>>>>>>> understand that embedded_H would be correct to reject this input
>>>>>>>> as non-halting.
>>>>>>>>
>>>>>>>
>>>>>>> Nope. That you don't understand it just shows that you are the
>>>>>>> strawman and don't have a brain.
>>>>>>>
>>>>>>> Remember the DEFINITION of the correct answer is:
>>>>>>
>>>>>> The computation of the mapping of the inputs to an accept or
>>>>>> reject state based on the actual behavior of these actual inputs.
>>>>>
>>>>> Right, and the "ACTUAL BEHAVIOR of the input" <H^> <H^< is BY
>>>>> DEFINITION the behavior of H^ applid to <H^>.
>>>>>
>>>>> Remember Definition 12.1 H applied to <M> w -> Qy if M applied to w
>>>>> Halts and -> Qn if M applied to w never halts. Thus the 'behavior'
>>>>> that H decides on is the behavior of the machine describe by its
>>>>> input.
>>>>>
>>>>> You keep on wanting to look at the behavior of the simulation by H
>>>>> of its input instead of the actual behavior of the input to H.
>>>>>
>>>>> The 'input' is JUST the <H^> <H^> and makes NO reference to H (or
>>>>> embedded_H) and actually needs to be independent of the machine
>>>>> that is looking at it.
>>>>>
>>>>>>
>>>>>> The actual behavior of the actual input never meets the Linz
>>>>>> definition of halting under any condition what-so-ever thus is
>>>>>> correctly judged as a non-halting input.
>>>>>
>>>>> But it does.
>>>>
>>>> The actual input is ⟨Ĥ0⟩ ⟨Ĥ1⟩.
>>>
>>> But ALL <H^i> are the exact same string, so ALL copies act the same.
>>>
>>>>
>>>> The actual behavior of this input is non-halting and you already
>>>> admitted this.
>>>
>>> Nope, I have PROVED that it is halting if H rejects this input.
>>
>> 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⟩
>> then embedded_H rejects ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>
>> Show how ⟨Ĥ0⟩ reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>
> Remember ALL <H^i> are the same, so we can look at the above and see
> that the ACTUAL BEHAVIOR of <H^0> <H^1> would be:
>
> H^0 is applied to <H^1>
>   H0 copies its input <H^1) to <H^2> then
>   H0 simulates <H^1> <H^2>
> H0 THINKS these keep repeating (but they don't)
>   H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>   H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
> Then embedded_H0 rejects <H^1> <H^2>


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

<pcKdnbg0ctxgY8z_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 16:47:41 -0500
Date: Sat, 9 Apr 2022 16:47:38 -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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<JKm4K.349131$Gojc.128381@fx99.iad>
<O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com>
<y1n4K.544956$mF2.32160@fx11.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <y1n4K.544956$mF2.32160@fx11.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <pcKdnbg0ctxgY8z_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 62
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-vxsl/vwrpsow55C3Od1m0CMixwAoCSKG1kf3ZO4vFbyKIc9xwyBSaWVXpJQjqq6KAitIZBK7arkDmje!RQiWevAsLpLOWkZ0hhsdLyQTlgcTzRnfu/qxNUOuOwLIhsAK23DyoGni/g1+cqlqhPU3IqqLMQbB
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: 4434
 by: olcott - Sat, 9 Apr 2022 21:47 UTC

On 4/9/2022 4:38 PM, Richard Damon wrote:
> On 4/9/22 5:24 PM, olcott wrote:
>> On 4/9/2022 4:18 PM, Richard Damon wrote:
>>> On 4/9/22 4:57 PM, olcott wrote:
>>>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>
>>>>>> My interpretation of whats going on it Peter's head is that he
>>>>>> doesn't
>>>>>> understand to concept of something not existing. He seems to have a
>>>>>> notion that if you can describe something, there must be some way to
>>>>>> make it.
>>>>>
>>>>> I agree.  I have thought the same for some time.  It's an odd sort of
>>>>> engineering perspective -- if I can conceive it, I can build it.
>>>>>
>>>>> This is why he thinks Linz is saying that neither answer is correct.
>>>>> What Linz is really saying -- that there can be no such TM is simply
>>>>> beyond PO's comprehension.
>>>>>
>>>>
>>>> He is saying that if embedeed_H accepts or rejects its input a
>>>> contradiction is formed. The truth is that when embedded_H rejects
>>>> its input no contradiction is formed.
>>>>
>>>
>>> Tou just don't understand the contradiction.
>> Watch the front door for white dogs coming into the living room (the
>> actual behavior of the actual input).
>>
>> A black cat came in the back door into the kitchen so the halt decider
>> is wrong. (behavior of non inputs).
>>
>
>
> Nope. you have your analogy backwards.
>
> BY DEFINITION, the 'white dog' is teh behavior of H^ applied to <H^>,
> and that halts.

Deciders compute the mapping from their inputs
from their inputs
from their inputs
from their inputs
from their inputs

Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H

Therefore Richard has severe brain damage when he keeps insisting that a
decider must not compute the mapping from its inputs and instead must
compute the mapping from a non-input.

--
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) [ ridiculously stupid ]

<rHn4K.62611$Kdf.27971@fx96.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!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!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) [
ridiculously stupid ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<Ml54K.792474$aT3.709472@fx09.iad>
<dPKdnYwT-JcceM3_nZ2dnUU7_83NnZ2d@giganews.com> <878rse8mpz.fsf@bsb.me.uk>
<8qOdnanOrqcPBsz_nZ2dnUU7_81g4p2d@giganews.com>
<esh4K.210689$OT%7.200542@fx07.iad>
<bOudnetnF9vGOcz_nZ2dnUU7_81g4p2d@giganews.com>
<cbk4K.149257$dln7.89696@fx03.iad>
<o7-dnVJPXvNjTcz_nZ2dnUU7_83NnZ2d@giganews.com>
<YCk4K.64531$e%.7672@fx36.iad>
<ntCdnSt0qr7uSsz_nZ2dnUU7_83NnZ2d@giganews.com>
<V1l4K.810561$aT3.662905@fx09.iad>
<7JGdnZEzGrp2Q8z_nZ2dnUU7_8zNnZ2d@giganews.com>
<Gkl4K.564829$7F2.521914@fx12.iad>
<OrWdnfFdxKTdfsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<DNl4K.327353$Lbb6.62351@fx45.iad>
<zM2dnSfUtf-vd8z_nZ2dnUU7_83NnZ2d@giganews.com>
<wpm4K.327356$Lbb6.198361@fx45.iad>
<Jo2dnV8tnJFGbsz_nZ2dnUU7_8xh4p2d@giganews.com>
<aEm4K.562187$LN2.503847@fx13.iad>
<07Cdnbe0F50Basz_nZ2dnUU7_8zNnZ2d@giganews.com>
<AZm4K.327357$Lbb6.233639@fx45.iad>
<QNKdnSFSIYpVYMz_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <QNKdnSFSIYpVYMz_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 224
Message-ID: <rHn4K.62611$Kdf.27971@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: Sat, 9 Apr 2022 18:23:19 -0400
X-Received-Bytes: 11932
 by: Richard Damon - Sat, 9 Apr 2022 22:23 UTC

On 4/9/22 5:42 PM, olcott wrote:
> On 4/9/2022 4:34 PM, Richard Damon wrote:
>>
>> On 4/9/22 5:16 PM, olcott wrote:
>>> On 4/9/2022 4:11 PM, Richard Damon wrote:
>>>>
>>>> On 4/9/22 5:00 PM, olcott wrote:
>>>>> On 4/9/2022 3:55 PM, Richard Damon wrote:
>>>>>> On 4/9/22 4:18 PM, olcott wrote:
>>>>>>> On 4/9/2022 3:13 PM, Richard Damon wrote:
>>>>>>>> On 4/9/22 3:49 PM, olcott wrote:
>>>>>>>>> On 4/9/2022 2:42 PM, Richard Damon wrote:
>>>>>>>>>> On 4/9/22 3:30 PM, olcott wrote:
>>>>>>>>>>> On 4/9/2022 2:22 PM, Richard Damon wrote:
>>>>>>>>>>>> On 4/9/22 2:58 PM, olcott wrote:
>>>>>>>>>>>>> On 4/9/2022 1:53 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/9/22 2:31 PM, olcott wrote:
>>>>>>>>>>>>>>> On 4/9/2022 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/9/22 11:20 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 4/9/2022 10:17 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 4/9/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 4/9/2022 7:28 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ĥ.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⟩
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>>>>>>>>>>>>> embedded_H reaches its own final state: ⟨Ĥ0.qy⟩ or
>>>>>>>>>>>>>>>>>>> ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your right, it doesn't in THAT case,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and when embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>>>>>>>> it still never reaches its own final state of ⟨Ĥ0.qy⟩
>>>>>>>>>>>>>>>>> or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, while embedded_H's simulation never reached thqt
>>>>>>>>>>>>>>>> state, that doesn't matter,
>>>>>>>>>>>>>>> Because the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H would
>>>>>>>>>>>>>>> never reach its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>>>>>>>>>>>>>> under any condition what-so-ever it is by logical
>>>>>>>>>>>>>>> necessity that embedded_H would be correct to transition
>>>>>>>>>>>>>>> to its own reject state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, that is NOT true. The CORRECT simulation of the input
>>>>>>>>>>>>>> to embedded_H DOES reach its final state if embedded_H
>>>>>>>>>>>>>> goes to its non-halting answer state. This has been
>>>>>>>>>>>>>> established. This is the condition that Halting looks at.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> then embedded_H aborts its simulation of ⟨Ĥ0⟩ ⟨Ĥ1⟩ causing
>>>>>>>>>>>>> this simulated input to immediately stop never ever
>>>>>>>>>>>>> reaching its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, and simulator that aborts its simulation my terminate
>>>>>>>>>>>> its own action, but does NOT change the behavior of the input,
>>>>>>>>>>>
>>>>>>>>>>> It is ridiculously stupid to believe that an aborted
>>>>>>>>>>> simulation keeps running after it have been aborted.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You just aren't understanding the words.
>>>>>>>>>>
>>>>>>>>>> I am not saying the ABORTED simulation continues, but the
>>>>>>>>>> CORRECT simulation and the actual machine behavior do, by
>>>>>>>>>> definition.
>>>>>>>>>
>>>>>>>>> Under no circumstances what-so-ever does the simulated input
>>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H meet this Linz criteria of a halting
>>>>>>>>> computation:
>>>>>>>>
>>>>>>>> That is just a LIE based on NOT looking at an ACTUAL CORRECT
>>>>>>>> simulation of the input.
>>>>>>>>
>>>>>>>> The ACTUAL behavior of the input to H / embedded_H, the input
>>>>>>>> string <H^> <H^> has been PROVEN to Halt if H / embedded_H
>>>>>>>> reject that input and go to Qn.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> computation that halts … the Turing machine will halt whenever
>>>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>>
>>>>>>>> Which means the ACTUAL TURING MACHINE, not a simulation.
>>>>>>>>
>>>>>>>> For this definition, the ONLY thing that the input <H^> <H^>
>>>>>>>> looks at is the actual computation H^ applied to <H^> PERIOD,
>>>>>>>> DEFINITION.
>>>>>>>>
>>>>>>>> Anythibng else can only be used by first showing actual
>>>>>>>> equivalence to that DEFINITION.
>>>>>>>>
>>>>>>>> The 'simulation' of the input by H / embedded_H FAILS to meet
>>>>>>>> that equivalence test if it aborts its simulation, so is
>>>>>>>> irrelevent.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Therefore people that do not have severe brain damage will
>>>>>>>>> understand that embedded_H would be correct to reject this
>>>>>>>>> input as non-halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope. That you don't understand it just shows that you are the
>>>>>>>> strawman and don't have a brain.
>>>>>>>>
>>>>>>>> Remember the DEFINITION of the correct answer is:
>>>>>>>
>>>>>>> The computation of the mapping of the inputs to an accept or
>>>>>>> reject state based on the actual behavior of these actual inputs.
>>>>>>
>>>>>> Right, and the "ACTUAL BEHAVIOR of the input" <H^> <H^< is BY
>>>>>> DEFINITION the behavior of H^ applid to <H^>.
>>>>>>
>>>>>> Remember Definition 12.1 H applied to <M> w -> Qy if M applied to
>>>>>> w Halts and -> Qn if M applied to w never halts. Thus the
>>>>>> 'behavior' that H decides on is the behavior of the machine
>>>>>> describe by its input.
>>>>>>
>>>>>> You keep on wanting to look at the behavior of the simulation by H
>>>>>> of its input instead of the actual behavior of the input to H.
>>>>>>
>>>>>> The 'input' is JUST the <H^> <H^> and makes NO reference to H (or
>>>>>> embedded_H) and actually needs to be independent of the machine
>>>>>> that is looking at it.
>>>>>>
>>>>>>>
>>>>>>> The actual behavior of the actual input never meets the Linz
>>>>>>> definition of halting under any condition what-so-ever thus is
>>>>>>> correctly judged as a non-halting input.
>>>>>>
>>>>>> But it does.
>>>>>
>>>>> The actual input is ⟨Ĥ0⟩ ⟨Ĥ1⟩.
>>>>
>>>> But ALL <H^i> are the exact same string, so ALL copies act the same.
>>>>
>>>>>
>>>>> The actual behavior of this input is non-halting and you already
>>>>> admitted this.
>>>>
>>>> Nope, I have PROVED that it is halting if H rejects this input.
>>>
>>> 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⟩
>>> then embedded_H rejects ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>
>>> Show how ⟨Ĥ0⟩ reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
>>>
>> Remember ALL <H^i> are the same, so we can look at the above and see
>> that the ACTUAL BEHAVIOR of <H^0> <H^1> would be:
>>
>> H^0 is applied to <H^1>
>>    H0 copies its input <H^1) to <H^2> then
>>    H0 simulates <H^1> <H^2>
>> H0 THINKS these keep repeating (but they don't)
>>    H^1 copies its input <H^2> to <H^3> then H1 simulates <H^2> <H^3>
>>    H^2 copies its input <H^3> to <H^4> then H2 simulates <H^3> <H^4>
>> Then embedded_H0 rejects <H^1> <H^2>
>
> You can't even pay attention to the facts.
> embedded_H0 does not reject any damn thing I already specified that the
> only rejection is embedded_H rejects ⟨Ĥ0⟩ ⟨Ĥ1⟩.
>


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

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

 copy mid

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

 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 23:25:39 +0100
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <87tub17v30.fsf@bsb.me.uk>
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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk>
<Jo2dnVwtnJHJbsz_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="0edcfd0a497f6252059b74307060f33c";
logging-data="22599"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/U7/x+I9/Vrgl2IplhQk0+yhLHsueRibs="
Cancel-Lock: sha1:gJu3ffK9mgnRX1EStuaZUp/F/IE=
sha1:PqpQh3NlmHXdLtDDGoSXvy+9Fg8=
X-BSB-Auth: 1.214d276db684a7ec0c28.20220409232539BST.87tub17v30.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 9 Apr 2022 22:25 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> My interpretation of whats going on it Peter's head is that he doesn't
>>> understand to concept of something not existing. He seems to have a
>>> notion that if you can describe something, there must be some way to
>>> make it.
>> I agree. I have thought the same for some time. It's an odd sort of
>> engineering perspective -- if I can conceive it, I can build it.
>> This is why he thinks Linz is saying that neither answer is correct.
>> What Linz is really saying -- that there can be no such TM is simply
>> beyond PO's comprehension.
>>
>
> He is saying that if embedeed_H accepts or rejects its input a
> contradiction is formed. The truth is that when embedded_H rejects its
> input no contradiction is formed.

You state that for the H you are championing

Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.

To see why this H is not a halt decider, you must answer the two
questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
transition to, and what string must be passed to H for H to tell us
whether or not Ĥ applied to <Ĥ> halts or not?

As soon as you'd like to have some time for something else, just answer
them, and all will be revealed. Of course you know the answers. You
just have to face the music and confront them.

--
Ben.

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

<lLn4K.62612$Kdf.59400@fx96.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!nntp.speedium.network!feeder01!81.171.65.16.MISMATCH!peer03.ams4!peer.am4.highwinds-media.com!peer02.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> <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> <87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad> <8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com> <JKm4K.349131$Gojc.128381@fx99.iad> <O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com> <y1n4K.544956$mF2.32160@fx11.iad> <pcKdnbg0ctxgY8z_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <pcKdnbg0ctxgY8z_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 78
Message-ID: <lLn4K.62612$Kdf.59400@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: Sat, 9 Apr 2022 18:27:31 -0400
X-Received-Bytes: 4738
 by: Richard Damon - Sat, 9 Apr 2022 22:27 UTC

On 4/9/22 5:47 PM, olcott wrote:
> On 4/9/2022 4:38 PM, Richard Damon wrote:
>> On 4/9/22 5:24 PM, olcott wrote:
>>> On 4/9/2022 4:18 PM, Richard Damon wrote:
>>>> On 4/9/22 4:57 PM, olcott wrote:
>>>>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>
>>>>>>> My interpretation of whats going on it Peter's head is that he
>>>>>>> doesn't
>>>>>>> understand to concept of something not existing. He seems to have a
>>>>>>> notion that if you can describe something, there must be some way to
>>>>>>> make it.
>>>>>>
>>>>>> I agree.  I have thought the same for some time.  It's an odd sort of
>>>>>> engineering perspective -- if I can conceive it, I can build it.
>>>>>>
>>>>>> This is why he thinks Linz is saying that neither answer is correct.
>>>>>> What Linz is really saying -- that there can be no such TM is simply
>>>>>> beyond PO's comprehension.
>>>>>>
>>>>>
>>>>> He is saying that if embedeed_H accepts or rejects its input a
>>>>> contradiction is formed. The truth is that when embedded_H rejects
>>>>> its input no contradiction is formed.
>>>>>
>>>>
>>>> Tou just don't understand the contradiction.
>>> Watch the front door for white dogs coming into the living room (the
>>> actual behavior of the actual input).
>>>
>>> A black cat came in the back door into the kitchen so the halt
>>> decider is wrong. (behavior of non inputs).
>>>
>>
>>
>> Nope. you have your analogy backwards.
>>
>> BY DEFINITION, the 'white dog' is teh behavior of H^ applied to <H^>,
>> and that halts.
>
> Deciders compute the mapping from their inputs
> from their inputs
> from their inputs
> from their inputs
> from their inputs
>
> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>
> Therefore Richard has severe brain damage when he keeps insisting that a
> decider must not compute the mapping from its inputs and instead must
> compute the mapping from a non-input.
>
>

And Peter can't read. I never said H^ applied to <H^> was in input.

The input is <H^> <H^>

The MAPPING is based on H^ applied to <H^>

As has been mentioned before, you seem to have a blind spot reguarding
requirements.

And, you seem to have a fundamental error in your understanding of a
decider.

Too bad you dropped out of class in front of everyone as you were
getting close to actually learning about what that means.

You are just proving you are totally ignorant about this field and
NOTHING you 'claim' based on being 'self-evident' or 'by the meaning of
the words' as ANY validitiy.

FAIL.

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

<37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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: Sat, 09 Apr 2022 17:34:26 -0500
Date: Sat, 9 Apr 2022 17:34:23 -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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87tub17v30.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 63
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-nQ0qKllzuf4ALbyOjuMk0YCqvFl7PDEK/WrLIXYqeZMnz+1BJZdR09NG+HtGvDomE3rzWqtWoPlvmq+!6++7A7jN2xI8sF4ZWsk6tyMxL8p4fik9WK6nyhgDA3Oi97qshuCFnGAt8h9pnHxuRfB3doqKK2J/
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: 4552
 by: olcott - Sat, 9 Apr 2022 22:34 UTC

On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> My interpretation of whats going on it Peter's head is that he doesn't
>>>> understand to concept of something not existing. He seems to have a
>>>> notion that if you can describe something, there must be some way to
>>>> make it.
>>> I agree. I have thought the same for some time. It's an odd sort of
>>> engineering perspective -- if I can conceive it, I can build it.
>>> This is why he thinks Linz is saying that neither answer is correct.
>>> What Linz is really saying -- that there can be no such TM is simply
>>> beyond PO's comprehension.
>>>
>>
>> He is saying that if embedeed_H accepts or rejects its input a
>> contradiction is formed. The truth is that when embedded_H rejects its
>> input no contradiction is formed.
>
> You state that for the H you are championing
>
> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>
> To see why this H is not a halt decider, you must answer the two
> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
> transition to, and what string must be passed to H for H to tell us
> whether or not Ĥ applied to <Ĥ> halts or not?
>

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.

No matter what H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to it is the case that
embedded_H applied to ⟨Ĥ0⟩ ⟨Ĥ1⟩ would be correct to rejects its input.

Is the input to embedded_H non-halting? YES

It is correct for embedded_H to report that its input is non-halting
when its input is non-halting? YES

> As soon as you'd like to have some time for something else, just answer
> them, and all will be revealed. Of course you know the answers. You
> just have to face the music and confront them.
>

--
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 ]

<37adneY3mr8Yl8__nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 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: Sat, 09 Apr 2022 17:36:53 -0500
Date: Sat, 9 Apr 2022 17:36:50 -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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<JKm4K.349131$Gojc.128381@fx99.iad>
<O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com>
<y1n4K.544956$mF2.32160@fx11.iad>
<pcKdnbg0ctxgY8z_nZ2dnUU7_83NnZ2d@giganews.com>
<lLn4K.62612$Kdf.59400@fx96.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <lLn4K.62612$Kdf.59400@fx96.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <37adneY3mr8Yl8__nZ2dnUU7_81g4p2d@giganews.com>
Lines: 72
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-RSjHLA+ElPgUasZYu4hDRW390oMArHnAVJTRH+rIdw5wIFJWjOaoN+ZKw+uB3fIsx4U3zmf8vwjLbbl!u4/pPw1CCv9zzjjSwGuQSPrsmyTBQUvZ3SQiILhn2kKYKHJOts4clueD06FG8Jxa25vX4toObiVr
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: 4870
 by: olcott - Sat, 9 Apr 2022 22:36 UTC

On 4/9/2022 5:27 PM, Richard Damon wrote:
> On 4/9/22 5:47 PM, olcott wrote:
>> On 4/9/2022 4:38 PM, Richard Damon wrote:
>>> On 4/9/22 5:24 PM, olcott wrote:
>>>> On 4/9/2022 4:18 PM, Richard Damon wrote:
>>>>> On 4/9/22 4:57 PM, olcott wrote:
>>>>>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>
>>>>>>>> My interpretation of whats going on it Peter's head is that he
>>>>>>>> doesn't
>>>>>>>> understand to concept of something not existing. He seems to have a
>>>>>>>> notion that if you can describe something, there must be some
>>>>>>>> way to
>>>>>>>> make it.
>>>>>>>
>>>>>>> I agree.  I have thought the same for some time.  It's an odd
>>>>>>> sort of
>>>>>>> engineering perspective -- if I can conceive it, I can build it.
>>>>>>>
>>>>>>> This is why he thinks Linz is saying that neither answer is correct.
>>>>>>> What Linz is really saying -- that there can be no such TM is simply
>>>>>>> beyond PO's comprehension.
>>>>>>>
>>>>>>
>>>>>> He is saying that if embedeed_H accepts or rejects its input a
>>>>>> contradiction is formed. The truth is that when embedded_H rejects
>>>>>> its input no contradiction is formed.
>>>>>>
>>>>>
>>>>> Tou just don't understand the contradiction.
>>>> Watch the front door for white dogs coming into the living room (the
>>>> actual behavior of the actual input).
>>>>
>>>> A black cat came in the back door into the kitchen so the halt
>>>> decider is wrong. (behavior of non inputs).
>>>>
>>>
>>>
>>> Nope. you have your analogy backwards.
>>>
>>> BY DEFINITION, the 'white dog' is teh behavior of H^ applied to <H^>,
>>> and that halts.
>>
>> Deciders compute the mapping from their inputs
>> from their inputs
>> from their inputs
>> from their inputs
>> from their inputs
>>
>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>>
>> Therefore Richard has severe brain damage when he keeps insisting that
>> a decider must not compute the mapping from its inputs and instead
>> must compute the mapping from a non-input.
>>
>>
>
> And Peter can't read. I never said H^ applied to <H^> was in input.

Then your freakingly well know that it does not have one damn thing to
do with the halting status decision, SO STFU ABOUT IT

--
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 ]

<d5o4K.29026$I_.13732@fx44.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx44.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> <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> <87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad> <8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com> <JKm4K.349131$Gojc.128381@fx99.iad> <O6qdneFwEqbuZMz_nZ2dnUU7_8zNnZ2d@giganews.com> <y1n4K.544956$mF2.32160@fx11.iad> <pcKdnbg0ctxgY8z_nZ2dnUU7_83NnZ2d@giganews.com> <lLn4K.62612$Kdf.59400@fx96.iad> <37adneY3mr8Yl8__nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <37adneY3mr8Yl8__nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 88
Message-ID: <d5o4K.29026$I_.13732@fx44.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: Sat, 9 Apr 2022 18:50:50 -0400
X-Received-Bytes: 5191
 by: Richard Damon - Sat, 9 Apr 2022 22:50 UTC

On 4/9/22 6:36 PM, olcott wrote:
> On 4/9/2022 5:27 PM, Richard Damon wrote:
>> On 4/9/22 5:47 PM, olcott wrote:
>>> On 4/9/2022 4:38 PM, Richard Damon wrote:
>>>> On 4/9/22 5:24 PM, olcott wrote:
>>>>> On 4/9/2022 4:18 PM, Richard Damon wrote:
>>>>>> On 4/9/22 4:57 PM, olcott wrote:
>>>>>>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>>>
>>>>>>>>> My interpretation of whats going on it Peter's head is that he
>>>>>>>>> doesn't
>>>>>>>>> understand to concept of something not existing. He seems to
>>>>>>>>> have a
>>>>>>>>> notion that if you can describe something, there must be some
>>>>>>>>> way to
>>>>>>>>> make it.
>>>>>>>>
>>>>>>>> I agree.  I have thought the same for some time.  It's an odd
>>>>>>>> sort of
>>>>>>>> engineering perspective -- if I can conceive it, I can build it.
>>>>>>>>
>>>>>>>> This is why he thinks Linz is saying that neither answer is
>>>>>>>> correct.
>>>>>>>> What Linz is really saying -- that there can be no such TM is
>>>>>>>> simply
>>>>>>>> beyond PO's comprehension.
>>>>>>>>
>>>>>>>
>>>>>>> He is saying that if embedeed_H accepts or rejects its input a
>>>>>>> contradiction is formed. The truth is that when embedded_H
>>>>>>> rejects its input no contradiction is formed.
>>>>>>>
>>>>>>
>>>>>> Tou just don't understand the contradiction.
>>>>> Watch the front door for white dogs coming into the living room
>>>>> (the actual behavior of the actual input).
>>>>>
>>>>> A black cat came in the back door into the kitchen so the halt
>>>>> decider is wrong. (behavior of non inputs).
>>>>>
>>>>
>>>>
>>>> Nope. you have your analogy backwards.
>>>>
>>>> BY DEFINITION, the 'white dog' is teh behavior of H^ applied to
>>>> <H^>, and that halts.
>>>
>>> Deciders compute the mapping from their inputs
>>> from their inputs
>>> from their inputs
>>> from their inputs
>>> from their inputs
>>>
>>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>>> Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H
>>>
>>> Therefore Richard has severe brain damage when he keeps insisting
>>> that a decider must not compute the mapping from its inputs and
>>> instead must compute the mapping from a non-input.
>>>
>>>
>>
>> And Peter can't read. I never said H^ applied to <H^> was in input.
>
> Then your freakingly well know that it does not have one damn thing to
> do with the halting status decision, SO STFU ABOUT IT
>

Then you are just admitting you don't understand what a REQUIREMENT, or
a MAPPING is.

DEFINITION of the CORRECT behavior of H:

H applied to <M> w -> Qy if M applied to w Halts and -> Qn if M applied
to w never halts.

Thus the CORRECT answer for H applied to <H^> <H^> is to go to Qy if H^
applied to <H^> Halts and to Qn if H^ applied to <H^> never halts.

If you say the DEFINITION of the right answer doesn't have a damn thing
to do with the decision, I guess you are just admitting that your H just
isn't a Halt Decider but must be something else and you are just LYING
about what it is supposed to do.

I think your problem is you just don't know the meaning of Truth.

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

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

 copy mid

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

 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 23:54:24 +0100
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <87ilrh7tr3.fsf@bsb.me.uk>
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>
<87ee268n4f.fsf@bsb.me.uk>
<8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@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="0edcfd0a497f6252059b74307060f33c";
logging-data="7499"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hVk492jT2flBFDu6Fd1gtAza1eL9hEhQ="
Cancel-Lock: sha1:x6iV3H8RvFCBYXg8EB2buIp5Znw=
sha1:TiM/2pVNwPrwfr0Y/I8mcjYr42I=
X-BSB-Auth: 1.f57a18b46c90f2e4d78c.20220409235424BST.87ilrh7tr3.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 9 Apr 2022 22:54 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>> 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.
>
> You have to actually pay attention to this,

Flip, flop! Back to being wrong about TMs rather than being wrong about
your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
halts are why your H and P are wrong.

To see why your Turing machine H is not a halt decider you need to
answer those terrifying questions that have you ducking and diving all
over the place rather than simply answering them.

> it is the key gap in your reasoning. The following proves that the
> simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H cannot possibly reach its own
> final state under any condition what-so-ever.

I'm not inclined to take advice about gaps in my reasoning from someone
who does not know what a proof is ("if A ⊦ X then A,~A ⊬ X"), who
doesn't know how to specify a simple Turing machine, who appears
incapable of writing a parity deciding TM, who talks nonsense like this:

"the fact that a computation halts does not entail that it is a
halting computation"

and who flatly contradicts himself as needed to get out of a bind:

"Furthermore I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many
times"

"No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
times"

To see why you are wrong (about Turing machines), you just need to say
what string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts, and to what state H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to. Then
all will become clear.

To see why you are wrong about your C code H and P, just refer to the
facts you stated about them quoted above.

--
Ben.

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

<Psqdnc0cGv81jc__nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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: Sat, 09 Apr 2022 18:03:04 -0500
Date: Sat, 9 Apr 2022 18:03:01 -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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87ilrh7tr3.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Psqdnc0cGv81jc__nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 104
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-N3UakzhVi8qyNcy+PqCJ2BhTGIFQ1bXQuVnWGdwdOvFyiEqsj7bg+xD1PStYYmT3JFv4XNfjYORlIL6!pBv3nmcb1QVD2d1FBkGxVNQfeD7quVxMDVdTDoT5ZyfP/WpZwFjr89ZY90P2dteTCdFcMYJtFfmS
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: 6734
 by: olcott - Sat, 9 Apr 2022 23:03 UTC

On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>> 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.
>>
>> You have to actually pay attention to this,
>
> Flip, flop! Back to being wrong about TMs rather than being wrong about
> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
> halts are why your H and P are wrong.
>
> To see why your Turing machine H is not a halt decider you need to
> answer those terrifying questions that have you ducking and diving all
> over the place rather than simply answering them.
>
>> it is the key gap in your reasoning. The following proves that the
>> simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H cannot possibly reach its own
>> final state under any condition what-so-ever.
>
> I'm not inclined to take advice about gaps in my reasoning from someone
> who does not know what a proof is ("if A ⊦ X then A,~A ⊬ X"), who
> doesn't know how to specify a simple Turing machine, who appears
> incapable of writing a parity deciding TM, who talks nonsense like this:
>
> "the fact that a computation halts does not entail that it is a
> halting computation"
>

Yes it does. The fact the a computation stops running. does not prove
that it halts.

If the input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H is non-halting then only a God
damned liar would say the embedded_H would be incorrect to reject this
input.

--
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 ]

<Yyo4K.544972$mF2.150679@fx11.iad>

 copy mid

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

 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!fx11.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>
<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>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk> <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 113
Message-ID: <Yyo4K.544972$mF2.150679@fx11.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: Sat, 9 Apr 2022 19:22:33 -0400
X-Received-Bytes: 6452
 by: Richard Damon - Sat, 9 Apr 2022 23:22 UTC

On 4/9/22 6:34 PM, olcott wrote:
> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 3:43 PM, Ben Bacarisse wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> My interpretation of whats going on it Peter's head is that he doesn't
>>>>> understand to concept of something not existing. He seems to have a
>>>>> notion that if you can describe something, there must be some way to
>>>>> make it.
>>>> I agree.  I have thought the same for some time.  It's an odd sort of
>>>> engineering perspective -- if I can conceive it, I can build it.
>>>> This is why he thinks Linz is saying that neither answer is correct.
>>>> What Linz is really saying -- that there can be no such TM is simply
>>>> beyond PO's comprehension.
>>>>
>>>
>>> He is saying that if embedeed_H accepts or rejects its input a
>>> contradiction is formed. The truth is that when embedded_H rejects its
>>> input no contradiction is formed.
>>
>> You state that for the H you are championing
>>
>>     Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>
>> To see why this H is not a halt decider, you must answer the two
>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>> transition to, and what string must be passed to H for H to tell us
>> whether or not Ĥ applied to <Ĥ> halts or not?
>>
>
> 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.

But ONLY because H / embedded_H never reject their input.

>
> No matter what H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to it is the case that
> embedded_H applied to ⟨Ĥ0⟩ ⟨Ĥ1⟩ would be correct to rejects its input.

Nope. FAIL.

>
> Is the input to embedded_H non-halting? YES

Nope.

>
> It is correct for embedded_H to report that its input is non-halting
> when its input is non-halting? YES
>
>
>> As soon as you'd like to have some time for something else, just answer
>> them, and all will be revealed.  Of course you know the answers.  You
>> just have to face the music and confront them.
>>
>
>

You seem to have a problem with the specification to the halt Decider.

The 'halting' property of the input is NOT based on whether H /
embedded_H can simulate the input to a final state, but whether the
actual machine represented by that input would halt.

It has been shown, and you have even agreeds, that H^ applied to <H^>
will halt if H / embedded_H rejects its input.

THe problem is you don't understand that this IS the specification of
what H should do.

Note, Halting is NOT defined by 'an algorithm', but is a property of the
Turing Machine the input represents.

Remember, H applied to <M> w -> Qy if M applied to w Halts and -> Qn if
M applied to w will never halt.

Note, the deciding factor is the computation M applied to w.

It turns out that in some cases, it is impossible for H to actually
compute that answer based on the input <M> w, but that is still the
specificatioh of what it needs to do.

This is why Halting is NOT a computable Function and a Universal Halt
Decider can not exist.

I am reminded that during your 'class' you just could NOT come up with a
specification that did not involve writing an algorithm.

Since Halting is NOT specified by an algorithm, and no finite algorithm
can exist for it, this seems to be a blind spot for you.

Yes, there are some pseudo-algorithms that involve infinite work that
may be able to express the definition of Halting, but that hits your
other blind spot, you don't seem to understand how non-finites work.

I think ultimately, you brain just doesn't have the wiring to handle
this sort of problem, and is why you make up such weird ideas, because
you can't admit to yourself you don't understand it, so you make up
insain ideas, and call yourself a 'Genius'. The problem is a Genius can
take their novel ideas and break them down so an ordinary person has a
chance to understand them. The insain person just goes more insain
trying to do that as there ISN'T logic behind their thoughts.

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

<t2t4g3$4dc$1@gioia.aioe.org>

 copy mid

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

 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: Sun, 10 Apr 2022 01:22:49 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t2t4g3$4dc$1@gioia.aioe.org>
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>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <Psqdnc0cGv81jc__nZ2dnUU7_83NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="4524"; 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 23:22 UTC

Utter Crank Peter Olcott wrote:
> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
....
>>    "the fact that a computation halts does not entail that it is a
>>    halting computation"
>>
>
> Yes it does. The fact the a computation stops running.  does not prove
> that it halts.

Then the fact that you claims abvious fallacies does not prove that you
lie?

Pages:12345678910111213141516171819202122232425262728293031323334353637383940
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor