Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Every program is a part of some other program, and rarely fits.


devel / comp.theory / Re: The key mistake of the Peter Linz HP proof

SubjectAuthor
* The key mistake of the Peter Linz HP proofolcott
+* The key mistake of the Peter Linz HP proofRichard Damon
|`* The key mistake of the Peter Linz HP proofolcott
| `* The key mistake of the Peter Linz HP proofRichard Damon
|  `* The key mistake of the Peter Linz HP proofolcott
|   `* The key mistake of the Peter Linz HP proofRichard Damon
|    +* The key mistake of the Peter Linz HP proofolcott
|    |`- The key mistake of the Peter Linz HP proofRichard Damon
|    `* The key mistake of the Peter Linz HP proofolcott
|     +* The key mistake of the Peter Linz HP proofRichard Damon
|     |+* The key mistake of the Peter Linz HP proofolcott
|     ||`* The key mistake of the Peter Linz HP proofRichard Damon
|     || `* The key mistake of the Peter Linz HP proofolcott
|     ||  `* The key mistake of the Peter Linz HP proofRichard Damon
|     ||   `* The key mistake of the Peter Linz HP proofolcott
|     ||    `* The key mistake of the Peter Linz HP proofRichard Damon
|     ||     `* The key mistake of the Peter Linz HP proofolcott
|     ||      `* The key mistake of the Peter Linz HP proofRichard Damon
|     ||       `* The key mistake of the Peter Linz HP proofolcott
|     ||        `* The key mistake of the Peter Linz HP proofRichard Damon
|     ||         `* The key mistake of the Peter Linz HP proofolcott
|     ||          `* The key mistake of the Peter Linz HP proofRichard Damon
|     ||           `* The key mistake of the Peter Linz HP proofolcott
|     ||            `* The key mistake of the Peter Linz HP proofRichard Damon
|     ||             `* The key mistake of the Peter Linz HP proofolcott
|     ||              +- The key mistake of the Peter Linz HP proofBen Bacarisse
|     ||              `* The key mistake of the Peter Linz HP proofRichard Damon
|     ||               `* The key mistake of the Peter Linz HP proof [ Liar Liar pants onolcott
|     ||                `* The key mistake of the Peter Linz HP proof [ Liar Liar pants onRichard Damon
|     ||                 `* The key mistake of the Peter Linz HP proof [ Liar Liar pants onolcott
|     ||                  +- The key mistake of the Peter Linz HP proof [ Liar Liar pants onRichard Damon
|     ||                  `* The key mistake of the Peter Linz HP proof [ Liar Liar pants onMr Flibble
|     ||                   +* The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ]olcott
|     ||                   |`* The key mistake of the Peter Linz HP proof [ Liar Liar pants onRichard Damon
|     ||                   | `* The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ]olcott
|     ||                   |  `- The key mistake of the Peter Linz HP proof [ Liar Liar pants onRichard Damon
|     ||                   `* The key mistake of the Peter Linz HP proof [ Liar Liar pants onMalcolm McLean
|     ||                    `* The key mistake of the Peter Linz HP proof [ Liar Liar pants onolcott
|     ||                     `- The key mistake of the Peter Linz HP proof [ Liar Liar pants onRichard Damon
|     |`* The key mistake of the Peter Linz HP proofolcott
|     | `- The key mistake of the Peter Linz HP proofRichard Damon
|     `- The key mistake of the Peter Linz HP proofRichard Damon
+* The key mistake of the Peter Linz HP proofAlan Mackenzie
|`* The key mistake of the Peter Linz HP proofolcott
| `* The key mistake of the Peter Linz HP proofRichard Damon
|  `* The key mistake of the Peter Linz HP proofBen Bacarisse
|   `* The key mistake of the Peter Linz HP proofAlan Mackenzie
|    `* _The_key_mistake_of_the_Peter_Linz_HP_proof:_[_Ĥ applied to ⟨Ĥ⟩ ]olcott
|     +- The key mistake of the Peter Linz HP proof: [Ben Bacarisse
|     `- _The_key_mistake_of_the_Peter_Linz_HP_proof:_[_Richard Damon
`- The key mistake of the Peter Linz HP proofBen Bacarisse

Pages:123
The key mistake of the Peter Linz HP proof

<2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 03 Sep 2021 19:18:06 -0500
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math
X-Mozilla-News-Host: news://news.giganews.com:119
From: NoO...@NoWhere.com (olcott)
Subject: The key mistake of the Peter Linz HP proof
Date: Fri, 3 Sep 2021 19:18:05 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
Lines: 47
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-6mAvLbyNSrnbdCehAjHbSq6xFfYXj5Xz5KMyFqcxfAAcOggVPK1ZncztY3b+aASduWOpw1IIbIWYOzg!BxcrkReuQ/VHppCuom8BXSlIHBQhtZJjLydFCmcPZj0mPgslEhKZ95/tm8bewm/rDm1McytU2ak9!MzA=
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: 3055
 by: olcott - Sat, 4 Sep 2021 00:18 UTC

In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input,

whether the simulation of this program must be aborted to
prevent it from running forever.

The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.

The Peter Linz H is defined to be a simulating halt decider that applies
the above criteria and the halt decider at Ĥ.qx is an exact copy of H.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

The mistake of the Linz proof is forming a conclusion
based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.

This is only answering the question:
Can changes be made to an otherwise correct halt decider
such that this halt decider is no longer correct?

The required question is:
Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt status
of its input?

Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩

This is proved in section V3 of my paper by the analogous example of:
int main() { H1(P,P); } // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

The full Linz Proof:
https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<nDzYI.36338$rl3.29330@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 55
Message-ID: <nDzYI.36338$rl3.29330@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: Fri, 3 Sep 2021 21:05:21 -0400
X-Received-Bytes: 3249
 by: Richard Damon - Sat, 4 Sep 2021 01:05 UTC

On 9/3/21 8:18 PM, olcott wrote:
>    In computability theory, the halting problem is the
>    problem of determining, from a description of an arbitrary
>    computer program and an input,
>
>    whether the simulation of this program must be aborted to
>    prevent it from running forever.
>
> The above criteria is valid on the basis of the known equivalence
> between the direct execution of a computation and its simulation
> by a UTM. The same criteria universally works on all inputs allowing
> their halting status to be correctly decided.
>
> The Peter Linz H is defined to be a simulating halt decider that applies
> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> The mistake of the Linz proof is forming a conclusion
> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>
> This is only answering the question:
> Can changes be made to an otherwise correct halt decider
> such that this halt decider is no longer correct?
>
> The required question is:
> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt status
> of its input?
>
> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>
> This is proved in section V3 of my paper by the analogous example of:
> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> The full Linz Proof:
> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>

So, do you claim H1 is the SAME computation as H, and thus neither is
actually a computation as the same computation can't give two different
answers to the same input.

Or, is the fact that H1 gives the right answer an irrelevent fact
because H1 is a different computation than H, so it needs to bet right
the H1^ instead of H^ since each ^ machine is only designed to confound
a single computation?

Seems to be a fatal flaw to your logic.

Re: The key mistake of the Peter Linz HP proof

<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 03 Sep 2021 20:19:07 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 3 Sep 2021 20:18:54 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <nDzYI.36338$rl3.29330@fx45.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
Lines: 77
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LemreanHXpCeD0lI7M+vig/P5HEyOHe3ZRGdCMgVQ94Mfc1VzQsXJXa16AA0C7i5Ll98thmHz0GoDSk!HILW2H73E2Lo4eQguvcGI7D2eONI6zmTfF9/yrCDlapFZACtV36rtC47XcI2gWhzHhgcjWuEaGMG!D9M=
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: 4224
 by: olcott - Sat, 4 Sep 2021 01:18 UTC

On 9/3/2021 8:05 PM, Richard Damon wrote:
> On 9/3/21 8:18 PM, olcott wrote:
>>    In computability theory, the halting problem is the
>>    problem of determining, from a description of an arbitrary
>>    computer program and an input,
>>
>>    whether the simulation of this program must be aborted to
>>    prevent it from running forever.
>>
>> The above criteria is valid on the basis of the known equivalence
>> between the direct execution of a computation and its simulation
>> by a UTM. The same criteria universally works on all inputs allowing
>> their halting status to be correctly decided.
>>
>> The Peter Linz H is defined to be a simulating halt decider that applies
>> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>
>> The mistake of the Linz proof is forming a conclusion
>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>
>> This is only answering the question:
>> Can changes be made to an otherwise correct halt decider
>> such that this halt decider is no longer correct?
>>
>> The required question is:
>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt status
>> of its input?
>>
>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>
>> This is proved in section V3 of my paper by the analogous example of:
>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> The full Linz Proof:
>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>
>
> So, do you claim H1 is the SAME computation as H, and thus neither is
> actually a computation as the same computation can't give two different
> answers to the same input.
>

I claim that H1 has identical machine code as H.
Their execution order makes them distinctly different computations.

H1 can see that H(P,P) aborts the simulation of its input.
H(P,P) cannot see anything that aborts the simulation of its input.

This execution sequence order makes them distinctly different
computations.

This is exactly the same as the when the original Linz H is applied to
⟨Ĥ⟩ ⟨Ĥ⟩.

> Or, is the fact that H1 gives the right answer an irrelevent fact
> because H1 is a different computation than H, so it needs to bet right
> the H1^ instead of H^ since each ^ machine is only designed to confound
> a single computation?
>
> Seems to be a fatal flaw to your logic.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<XkAYI.19068$z%4.13606@fx37.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 83
Message-ID: <XkAYI.19068$z%4.13606@fx37.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 3 Sep 2021 21:53:58 -0400
X-Received-Bytes: 4317
 by: Richard Damon - Sat, 4 Sep 2021 01:53 UTC

On 9/3/21 9:18 PM, olcott wrote:
> On 9/3/2021 8:05 PM, Richard Damon wrote:
>> On 9/3/21 8:18 PM, olcott wrote:
>>>     In computability theory, the halting problem is the
>>>     problem of determining, from a description of an arbitrary
>>>     computer program and an input,
>>>
>>>     whether the simulation of this program must be aborted to
>>>     prevent it from running forever.
>>>
>>> The above criteria is valid on the basis of the known equivalence
>>> between the direct execution of a computation and its simulation
>>> by a UTM. The same criteria universally works on all inputs allowing
>>> their halting status to be correctly decided.
>>>
>>> The Peter Linz H is defined to be a simulating halt decider that applies
>>> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>
>>> The mistake of the Linz proof is forming a conclusion
>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>
>>> This is only answering the question:
>>> Can changes be made to an otherwise correct halt decider
>>> such that this halt decider is no longer correct?
>>>
>>> The required question is:
>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt status
>>> of its input?
>>>
>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>
>>> This is proved in section V3 of my paper by the analogous example of:
>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>>
>>> The full Linz Proof:
>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>
>>
>> So, do you claim H1 is the SAME computation as H, and thus neither is
>> actually a computation as the same computation can't give two different
>> answers to the same input.
>>
>
> I claim that H1 has identical machine code as H.
> Their execution order makes them distinctly different computations.
>
> H1 can see that H(P,P) aborts the simulation of its input.
> H(P,P) cannot see anything that aborts the simulation of its input.
>
> This execution sequence order makes them distinctly different computations.
>
> This is exactly the same as the when the original Linz H is applied to
> ⟨Ĥ⟩ ⟨Ĥ⟩.

IF H1 is a different computation than H, then the fact that it can get
the answer right doesn't matter, as it wasn't the computation that H^
was built on.

On the other hand, I think this really indicates that H isn't really a
computation, as making a copy of a computation shouldn't change the
computation.

>
>> Or, is the fact that H1 gives the right answer an irrelevent fact
>> because H1 is a different computation than H, so it needs to bet right
>> the H1^ instead of H^ since each ^ machine is only designed to confound
>> a single computation?
>>
>> Seems to be a fatal flaw to your logic.
>>
>
>

Re: The key mistake of the Peter Linz HP proof

<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 03 Sep 2021 21:13:37 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 3 Sep 2021 21:13:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <XkAYI.19068$z%4.13606@fx37.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
Lines: 110
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-tzsHIexb2bEG6IwzKbD6btWCMJaoHXQoFh808rXT1VZF78aqnmaKu5Exp7ruGTpjjaCtQOfWqQDo5mr!dG7ci9vmGAedvPOzhM7v2YeKS+Y+9zZ3Ib1XLwhDRwbt1BO+FFsFqGKU0CuTsmFUlebvzdPWdnoi!CdY=
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: 5721
 by: olcott - Sat, 4 Sep 2021 02:13 UTC

On 9/3/2021 8:53 PM, Richard Damon wrote:
> On 9/3/21 9:18 PM, olcott wrote:
>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>     In computability theory, the halting problem is the
>>>>     problem of determining, from a description of an arbitrary
>>>>     computer program and an input,
>>>>
>>>>     whether the simulation of this program must be aborted to
>>>>     prevent it from running forever.
>>>>
>>>> The above criteria is valid on the basis of the known equivalence
>>>> between the direct execution of a computation and its simulation
>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>> their halting status to be correctly decided.
>>>>
>>>> The Peter Linz H is defined to be a simulating halt decider that applies
>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>
>>>> The mistake of the Linz proof is forming a conclusion
>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>
>>>> This is only answering the question:
>>>> Can changes be made to an otherwise correct halt decider
>>>> such that this halt decider is no longer correct?
>>>>
>>>> The required question is:
>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt status
>>>> of its input?
>>>>
>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>
>>>> This is proved in section V3 of my paper by the analogous example of:
>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>>
>>>> The full Linz Proof:
>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>
>>>
>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>> actually a computation as the same computation can't give two different
>>> answers to the same input.
>>>
>>
>> I claim that H1 has identical machine code as H.
>> Their execution order makes them distinctly different computations.
>>
>> H1 can see that H(P,P) aborts the simulation of its input.
>> H(P,P) cannot see anything that aborts the simulation of its input.
>>
>> This execution sequence order makes them distinctly different computations.
>>
>> This is exactly the same as the when the original Linz H is applied to
>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> IF H1 is a different computation than H, then the fact that it can get
> the answer right doesn't matter, as it wasn't the computation that H^
> was built on.
>

The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
It turns out that using my simulating halt decider criteria H would
correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.

This computation is precisely analogous to int main() { H1(P,P); } shown
in section V3 of my paper. H1 has identical machine code as my C/x86 H.

Even though H1 has identical code to H its behavior varies because its
execution trace of its simulation of P(P) sees that H(P,P) will abort
its input. H(P,P) does not see any halt decider that will abort the
simulation of its input.

The simulator aspect of H1 and H have the same input: (P,P).
The halt decider aspect has the generated simulation as its input.

The input to the halt decider varies even through the input to the
simulator is the same.

> On the other hand, I think this really indicates that H isn't really a
> computation, as making a copy of a computation shouldn't change the
> computation.
>
>>
>>> Or, is the fact that H1 gives the right answer an irrelevent fact
>>> because H1 is a different computation than H, so it needs to bet right
>>> the H1^ instead of H^ since each ^ machine is only designed to confound
>>> a single computation?
>>>
>>> Seems to be a fatal flaw to your logic.
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<ecIYI.71866$T_8.30491@fx48.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx48.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 141
Message-ID: <ecIYI.71866$T_8.30491@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, 4 Sep 2021 06:50:49 -0400
X-Received-Bytes: 6919
 by: Richard Damon - Sat, 4 Sep 2021 10:50 UTC

On 9/3/21 10:13 PM, olcott wrote:
> On 9/3/2021 8:53 PM, Richard Damon wrote:
>> On 9/3/21 9:18 PM, olcott wrote:
>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>      In computability theory, the halting problem is the
>>>>>      problem of determining, from a description of an arbitrary
>>>>>      computer program and an input,
>>>>>
>>>>>      whether the simulation of this program must be aborted to
>>>>>      prevent it from running forever.
>>>>>
>>>>> The above criteria is valid on the basis of the known equivalence
>>>>> between the direct execution of a computation and its simulation
>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>> their halting status to be correctly decided.
>>>>>
>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>> applies
>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>
>>>>> The mistake of the Linz proof is forming a conclusion
>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>
>>>>> This is only answering the question:
>>>>> Can changes be made to an otherwise correct halt decider
>>>>> such that this halt decider is no longer correct?
>>>>>
>>>>> The required question is:
>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>> status
>>>>> of its input?
>>>>>
>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>
>>>>> This is proved in section V3 of my paper by the analogous example of:
>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The full Linz Proof:
>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>
>>>>
>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>> actually a computation as the same computation can't give two different
>>>> answers to the same input.
>>>>
>>>
>>> I claim that H1 has identical machine code as H.
>>> Their execution order makes them distinctly different computations.
>>>
>>> H1 can see that H(P,P) aborts the simulation of its input.
>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>
>>> This execution sequence order makes them distinctly different
>>> computations.
>>>
>>> This is exactly the same as the when the original Linz H is applied to
>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> IF H1 is a different computation than H, then the fact that it can get
>> the answer right doesn't matter, as it wasn't the computation that H^
>> was built on.
>>
>
> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
> It turns out that using my simulating halt decider criteria H would
> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.

Not quite, you are missing the meaning of words here. H was supposed to
be a Turing Machine, an exact copy of a Turing Machine will behave
identically to the original. This is a fundamental property of being a
Computation, if you make an exact copy of the algorithm, you will get
the identical behavior.

If, for your H, making an exact copy of the algorithm doesn't result in
something that behaves identically, then either you didn't copy that
algorithm correctly, or the thing you copied wasn't the algorithm of a
Computation.

Since H1 and H don't behave the same, as they give different answers
when given the same input, if that was a correct copy, you have just
PROVED that you H isn't a Computation per the definitions, and thus
can't be a Decider.

If you didn't make a correct copy, then the fact that H1 gets the answer
right means nothing as it isn't the same computation that H^ was built on.

> This computation is precisely analogous to int main() { H1(P,P); } shown
> in section V3 of my paper. H1 has identical machine code as my C/x86 H.
>
> Even though H1 has identical code to H its behavior varies because its
> execution trace of its simulation of P(P) sees that H(P,P) will abort
> its input. H(P,P) does not see any halt decider that will abort the
> simulation of its input.

Which is just you making fancy words to try to get around that H must
not be a Computation. If H WAS a computation, then the copy of it would
behave just the same, so given the same input it would 'see' exactly the
same thing, and make the same decision.

FAIKL.

>
> The simulator aspect of H1 and H have the same input: (P,P).
> The halt decider aspect has the generated simulation as its input.
>
> The input to the halt decider varies even through the input to the
> simulator is the same.
>
>> On the other hand, I think this really indicates that H isn't really a
>> computation, as making a copy of a computation shouldn't change the
>> computation.
>>
>>>
>>>> Or, is the fact that H1 gives the right answer an irrelevent fact
>>>> because H1 is a different computation than H, so it needs to bet right
>>>> the H1^ instead of H^ since each ^ machine is only designed to confound
>>>> a single computation?
>>>>
>>>> Seems to be a fatal flaw to your logic.
>>>>
>>>
>>>
>>
>
>

Basically, you don't understand what the actual definition of a
Computation is. Remember, this words was defined long before the modern
Computer had been invented.

Re: The key mistake of the Peter Linz HP proof

<5N-dnUE4t6SP5678nZ2dnUU7-LXNnZ2d@giganews.com>

 copy mid

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

 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, 04 Sep 2021 08:52:18 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 08:52:18 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <ecIYI.71866$T_8.30491@fx48.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <5N-dnUE4t6SP5678nZ2dnUU7-LXNnZ2d@giganews.com>
Lines: 164
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-U5MUyayZ7IoEgRUgXBzzyFEWm6KNYZ0TonzySvZa8wH1n/e/6Oh6vfSUPV3rTXz5Owbefo4+mu/lZuB!Z8kScAc1kCiFR+qjXlHHSb8yZWtOaqxzdpOa6l4QX6H8YuDigXOwbmRrpmyIxSedlHhFQt+0UVT8!2jg=
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: 8057
 by: olcott - Sat, 4 Sep 2021 13:52 UTC

On 9/4/2021 5:50 AM, Richard Damon wrote:
> On 9/3/21 10:13 PM, olcott wrote:
>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>> On 9/3/21 9:18 PM, olcott wrote:
>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>      In computability theory, the halting problem is the
>>>>>>      problem of determining, from a description of an arbitrary
>>>>>>      computer program and an input,
>>>>>>
>>>>>>      whether the simulation of this program must be aborted to
>>>>>>      prevent it from running forever.
>>>>>>
>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>> between the direct execution of a computation and its simulation
>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>> their halting status to be correctly decided.
>>>>>>
>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>> applies
>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>
>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>
>>>>>> This is only answering the question:
>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>> such that this halt decider is no longer correct?
>>>>>>
>>>>>> The required question is:
>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>> status
>>>>>> of its input?
>>>>>>
>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>
>>>>>> This is proved in section V3 of my paper by the analogous example of:
>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The full Linz Proof:
>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>
>>>>>
>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>> actually a computation as the same computation can't give two different
>>>>> answers to the same input.
>>>>>
>>>>
>>>> I claim that H1 has identical machine code as H.
>>>> Their execution order makes them distinctly different computations.
>>>>
>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>
>>>> This execution sequence order makes them distinctly different
>>>> computations.
>>>>
>>>> This is exactly the same as the when the original Linz H is applied to
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> IF H1 is a different computation than H, then the fact that it can get
>>> the answer right doesn't matter, as it wasn't the computation that H^
>>> was built on.
>>>
>>
>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>> It turns out that using my simulating halt decider criteria H would
>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>
> Not quite, you are missing the meaning of words here. H was supposed to
> be a Turing Machine, an exact copy of a Turing Machine will behave
> identically to the original.

I have empirically proved that this is merely a false assumption.
int main() { H1(P,P); } sees a different execution trace than H(P,P).

In the first case we have a halt decider that sees another halt decider
abort the simulation of its input.

In the second case we have a halt decider that does not see another halt
decider abort the simulation of its input.

The execution order of with H1 before H derives a different execution
trace for H1 than for H.

> This is a fundamental property of being a
> Computation, if you make an exact copy of the algorithm, you will get
> the identical behavior.
>
> If, for your H, making an exact copy of the algorithm doesn't result in
> something that behaves identically, then either you didn't copy that
> algorithm correctly, or the thing you copied wasn't the algorithm of a
> Computation.
>
> Since H1 and H don't behave the same, as they give different answers
> when given the same input, if that was a correct copy, you have just
> PROVED that you H isn't a Computation per the definitions, and thus
> can't be a Decider.
>
> If you didn't make a correct copy, then the fact that H1 gets the answer
> right means nothing as it isn't the same computation that H^ was built on.
>
>> This computation is precisely analogous to int main() { H1(P,P); } shown
>> in section V3 of my paper. H1 has identical machine code as my C/x86 H.
>>
>> Even though H1 has identical code to H its behavior varies because its
>> execution trace of its simulation of P(P) sees that H(P,P) will abort
>> its input. H(P,P) does not see any halt decider that will abort the
>> simulation of its input.
>
> Which is just you making fancy words to try to get around that H must
> not be a Computation. If H WAS a computation, then the copy of it would
> behave just the same, so given the same input it would 'see' exactly the
> same thing, and make the same decision.
>
> FAIKL.
>
>>
>> The simulator aspect of H1 and H have the same input: (P,P).
>> The halt decider aspect has the generated simulation as its input.
>>
>> The input to the halt decider varies even through the input to the
>> simulator is the same.
>>
>>> On the other hand, I think this really indicates that H isn't really a
>>> computation, as making a copy of a computation shouldn't change the
>>> computation.
>>>
>>>>
>>>>> Or, is the fact that H1 gives the right answer an irrelevent fact
>>>>> because H1 is a different computation than H, so it needs to bet right
>>>>> the H1^ instead of H^ since each ^ machine is only designed to confound
>>>>> a single computation?
>>>>>
>>>>> Seems to be a fatal flaw to your logic.
>>>>>
>>>>
>>>>
>>>
>>
>>
>
> Basically, you don't understand what the actual definition of a
> Computation is. Remember, this words was defined long before the modern
> Computer had been invented.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.logic
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, 04 Sep 2021 09:06:36 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 09:06:34 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <ecIYI.71866$T_8.30491@fx48.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
Lines: 105
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-vnuTTTCeKVp2RMNVrY3W9F13aPR776H2PH076VbVnmJp6dOB1f0FmxC3DL2zNzWNRQxwN8G/LQVJE0E!GZhtujzSf8Y3+JuZmJTcgpyvklJFvFvzqKp7QT5+dQi+jNtgAowr0PFBwGHnabqyOmc5utOgitEa!vOE=
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: 5926
 by: olcott - Sat, 4 Sep 2021 14:06 UTC

On 9/4/2021 5:50 AM, Richard Damon wrote:
> On 9/3/21 10:13 PM, olcott wrote:
>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>> On 9/3/21 9:18 PM, olcott wrote:
>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>      In computability theory, the halting problem is the
>>>>>>      problem of determining, from a description of an arbitrary
>>>>>>      computer program and an input,
>>>>>>
>>>>>>      whether the simulation of this program must be aborted to
>>>>>>      prevent it from running forever.
>>>>>>
>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>> between the direct execution of a computation and its simulation
>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>> their halting status to be correctly decided.
>>>>>>
>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>> applies
>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>
>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>
>>>>>> This is only answering the question:
>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>> such that this halt decider is no longer correct?
>>>>>>
>>>>>> The required question is:
>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>> status
>>>>>> of its input?
>>>>>>
>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>
>>>>>> This is proved in section V3 of my paper by the analogous example of:
>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The full Linz Proof:
>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>
>>>>>
>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>> actually a computation as the same computation can't give two different
>>>>> answers to the same input.
>>>>>
>>>>
>>>> I claim that H1 has identical machine code as H.
>>>> Their execution order makes them distinctly different computations.
>>>>
>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>
>>>> This execution sequence order makes them distinctly different
>>>> computations.
>>>>
>>>> This is exactly the same as the when the original Linz H is applied to
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> IF H1 is a different computation than H, then the fact that it can get
>>> the answer right doesn't matter, as it wasn't the computation that H^
>>> was built on.
>>>
>>
>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>> It turns out that using my simulating halt decider criteria H would
>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>
> Not quite, you are missing the meaning of words here. H was supposed to
> be a Turing Machine, an exact copy of a Turing Machine will behave
> identically to the original. This is a fundamental property of being a
> Computation, if you make an exact copy of the algorithm, you will get
> the identical behavior.
I have empirically proved that this is merely a false assumption.
int main() { H1(P,P); } sees a different execution trace than H(P,P).

In the first case we have a halt decider that sees another halt decider
abort the simulation of its input.

In the second case we have a halt decider that does not see another halt
decider abort the simulation of its input.

The execution order of with H1 before H derives a different execution
trace for H1 than for H.

H1 is an identical copy of H and has different behavior than H because
its execution trace input is different than H.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<2bLYI.19913$g81.2199@fx33.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx33.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<5N-dnUE4t6SP5678nZ2dnUU7-LXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <5N-dnUE4t6SP5678nZ2dnUU7-LXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 183
Message-ID: <2bLYI.19913$g81.2199@fx33.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, 4 Sep 2021 10:14:22 -0400
X-Received-Bytes: 8462
 by: Richard Damon - Sat, 4 Sep 2021 14:14 UTC

On 9/4/21 9:52 AM, olcott wrote:
> On 9/4/2021 5:50 AM, Richard Damon wrote:
>> On 9/3/21 10:13 PM, olcott wrote:
>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>       In computability theory, the halting problem is the
>>>>>>>       problem of determining, from a description of an arbitrary
>>>>>>>       computer program and an input,
>>>>>>>
>>>>>>>       whether the simulation of this program must be aborted to
>>>>>>>       prevent it from running forever.
>>>>>>>
>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>> between the direct execution of a computation and its simulation
>>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>>> their halting status to be correctly decided.
>>>>>>>
>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>> applies
>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>> of H.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>
>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>
>>>>>>> This is only answering the question:
>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>> such that this halt decider is no longer correct?
>>>>>>>
>>>>>>> The required question is:
>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>> status
>>>>>>> of its input?
>>>>>>>
>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>> of:
>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The full Linz Proof:
>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>
>>>>>>
>>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>>> actually a computation as the same computation can't give two
>>>>>> different
>>>>>> answers to the same input.
>>>>>>
>>>>>
>>>>> I claim that H1 has identical machine code as H.
>>>>> Their execution order makes them distinctly different computations.
>>>>>
>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>
>>>>> This execution sequence order makes them distinctly different
>>>>> computations.
>>>>>
>>>>> This is exactly the same as the when the original Linz H is applied to
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> IF H1 is a different computation than H, then the fact that it can get
>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>> was built on.
>>>>
>>>
>>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>>> It turns out that using my simulating halt decider criteria H would
>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>
>> Not quite, you are missing the meaning of words here. H was supposed to
>> be a Turing Machine, an exact copy of a Turing Machine will behave
>> identically to the original.
>
> I have empirically proved that this is merely a false assumption.
> int main() { H1(P,P); } sees a different execution trace than H(P,P).

Which proves that H and H1 are not the same computation. If they have
the same code, then that code does not express a true Mathematical
Computation, and thus H and H1 aren't computations at all.

>
> In the first case we have a halt decider that sees another halt decider
> abort the simulation of its input.
>
> In the second case we have a halt decider that does not see another halt
> decider abort the simulation of its input.
>
> The execution order of with H1 before H derives a different execution
> trace for H1 than for H.

Right, you have just proved that H doesn't qualify to be a decider as
its code does not represent a Mathematical Computation, and thus is not
qualified to be a Decider.

Same Algorithm, Same Input, different results. Not a Computation, by
definition.

Thank you, your job is done. F-

>
>> This is a fundamental property of being a
>> Computation, if you make an exact copy of the algorithm, you will get
>> the identical behavior.
>>
>> If, for your H, making an exact copy of the algorithm doesn't result in
>> something that behaves identically, then either you didn't copy that
>> algorithm correctly, or the thing you copied wasn't the algorithm of a
>> Computation.
>>
>> Since H1 and H don't behave the same, as they give different answers
>> when given the same input, if that was a correct copy, you have just
>> PROVED that you H isn't a Computation per the definitions, and thus
>> can't be a Decider.
>>
>> If you didn't make a correct copy, then the fact that H1 gets the answer
>> right means nothing as it isn't the same computation that H^ was built
>> on.
>>
>>> This computation is precisely analogous to int main() { H1(P,P); } shown
>>> in section V3 of my paper. H1 has identical machine code as my C/x86 H.
>>>
>>> Even though H1 has identical code to H its behavior varies because its
>>> execution trace of its simulation of P(P) sees that H(P,P) will abort
>>> its input. H(P,P) does not see any halt decider that will abort the
>>> simulation of its input.
>>
>> Which is just you making fancy words to try to get around that H must
>> not be a Computation. If H WAS a computation, then the copy of it would
>> behave just the same, so given the same input it would 'see' exactly the
>> same thing, and make the same decision.
>>
>> FAIKL.
>>
>>>
>>> The simulator aspect of H1 and H have the same input: (P,P).
>>> The halt decider aspect has the generated simulation as its input.
>>>
>>> The input to the halt decider varies even through the input to the
>>> simulator is the same.
>>>
>>>> On the other hand, I think this really indicates that H isn't really a
>>>> computation, as making a copy of a computation shouldn't change the
>>>> computation.
>>>>
>>>>>
>>>>>> Or, is the fact that H1 gives the right answer an irrelevent fact
>>>>>> because H1 is a different computation than H, so it needs to bet
>>>>>> right
>>>>>> the H1^ instead of H^ since each ^ machine is only designed to
>>>>>> confound
>>>>>> a single computation?
>>>>>>
>>>>>> Seems to be a fatal flaw to your logic.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> Basically, you don't understand what the actual definition of a
>> Computation is. Remember, this words was defined long before the modern
>> Computer had been invented.
>>
>
>


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<dfLYI.6743$3p3.5819@fx16.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 120
Message-ID: <dfLYI.6743$3p3.5819@fx16.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, 4 Sep 2021 10:18:47 -0400
X-Received-Bytes: 6354
 by: Richard Damon - Sat, 4 Sep 2021 14:18 UTC

On 9/4/21 10:06 AM, olcott wrote:
> On 9/4/2021 5:50 AM, Richard Damon wrote:
>> On 9/3/21 10:13 PM, olcott wrote:
>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>       In computability theory, the halting problem is the
>>>>>>>       problem of determining, from a description of an arbitrary
>>>>>>>       computer program and an input,
>>>>>>>
>>>>>>>       whether the simulation of this program must be aborted to
>>>>>>>       prevent it from running forever.
>>>>>>>
>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>> between the direct execution of a computation and its simulation
>>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>>> their halting status to be correctly decided.
>>>>>>>
>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>> applies
>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>> of H.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>
>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>
>>>>>>> This is only answering the question:
>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>> such that this halt decider is no longer correct?
>>>>>>>
>>>>>>> The required question is:
>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>> status
>>>>>>> of its input?
>>>>>>>
>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>> of:
>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The full Linz Proof:
>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>
>>>>>>
>>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>>> actually a computation as the same computation can't give two
>>>>>> different
>>>>>> answers to the same input.
>>>>>>
>>>>>
>>>>> I claim that H1 has identical machine code as H.
>>>>> Their execution order makes them distinctly different computations.
>>>>>
>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>
>>>>> This execution sequence order makes them distinctly different
>>>>> computations.
>>>>>
>>>>> This is exactly the same as the when the original Linz H is applied to
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> IF H1 is a different computation than H, then the fact that it can get
>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>> was built on.
>>>>
>>>
>>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>>> It turns out that using my simulating halt decider criteria H would
>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>
>> Not quite, you are missing the meaning of words here. H was supposed to
>> be a Turing Machine, an exact copy of a Turing Machine will behave
>> identically to the original. This is a fundamental property of being a
>> Computation, if you make an exact copy of the algorithm, you will get
>> the identical behavior.
> I have empirically proved that this is merely a false assumption.
> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>
> In the first case we have a halt decider that sees another halt decider
> abort the simulation of its input.
>
> In the second case we have a halt decider that does not see another halt
> decider abort the simulation of its input.
>
> The execution order of with H1 before H derives a different execution
> trace for H1 than for H.
>
> H1 is an identical copy of H and has different behavior than H because
> its execution trace input is different than H.
>

Since Execution Trace is NOT defined as an input to that Computation
(the only inputs are the representation of the machine and its input),
the dependency of the result on that just proves that H and H1 are not
properly Computation, and thus not eligable to be a Decider.

PERIOD. DEFINITION.

H is NOT the Computational Equivalent of the Turing Machine it is
claimed to be, as that machine would be Computation (as Turing Machines,
but structure HAVE to be), so you argument fails at line 1 when you make
that claim.

You clearly do not understand the meaning of Computation as used in the
field you are trying to muddle in.

Re: The key mistake of the Peter Linz HP proof

<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>

 copy mid

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

 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, 04 Sep 2021 09:58:30 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 09:58:29 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <dfLYI.6743$3p3.5819@fx16.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
Lines: 132
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CcGRiM7OdwSyPgLp/BXld0AR/aw1igjMpKUF9H+x6bFnf7dvSFGHqzPSf0oLZtdIpsCxpCO0mWHO6P0!GQoTgVzWQKxj/c+sADbzrpJpEX/xak3YTa7xcfoTDNWuWiIzfqEb2SNmbOC13yOVtLFGLEj5dDVU!mY4=
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: 7103
 by: olcott - Sat, 4 Sep 2021 14:58 UTC

On 9/4/2021 9:18 AM, Richard Damon wrote:
> On 9/4/21 10:06 AM, olcott wrote:
>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>> On 9/3/21 10:13 PM, olcott wrote:
>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>       In computability theory, the halting problem is the
>>>>>>>>       problem of determining, from a description of an arbitrary
>>>>>>>>       computer program and an input,
>>>>>>>>
>>>>>>>>       whether the simulation of this program must be aborted to
>>>>>>>>       prevent it from running forever.
>>>>>>>>
>>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>>>> their halting status to be correctly decided.
>>>>>>>>
>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>> applies
>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>> of H.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>
>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>
>>>>>>>> This is only answering the question:
>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>
>>>>>>>> The required question is:
>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>> status
>>>>>>>> of its input?
>>>>>>>>
>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>>> of:
>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The full Linz Proof:
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>
>>>>>>>
>>>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>>>> actually a computation as the same computation can't give two
>>>>>>> different
>>>>>>> answers to the same input.
>>>>>>>
>>>>>>
>>>>>> I claim that H1 has identical machine code as H.
>>>>>> Their execution order makes them distinctly different computations.
>>>>>>
>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>>
>>>>>> This execution sequence order makes them distinctly different
>>>>>> computations.
>>>>>>
>>>>>> This is exactly the same as the when the original Linz H is applied to
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> IF H1 is a different computation than H, then the fact that it can get
>>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>>> was built on.
>>>>>
>>>>
>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>>>> It turns out that using my simulating halt decider criteria H would
>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>
>>> Not quite, you are missing the meaning of words here. H was supposed to
>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>> identically to the original. This is a fundamental property of being a
>>> Computation, if you make an exact copy of the algorithm, you will get
>>> the identical behavior.
>> I have empirically proved that this is merely a false assumption.
>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>
>> In the first case we have a halt decider that sees another halt decider
>> abort the simulation of its input.
>>
>> In the second case we have a halt decider that does not see another halt
>> decider abort the simulation of its input.
>>
>> The execution order of with H1 before H derives a different execution
>> trace for H1 than for H.
>>
>> H1 is an identical copy of H and has different behavior than H because
>> its execution trace input is different than H.
>>
>
> Since Execution Trace is NOT defined as an input to that Computation
> (the only inputs are the representation of the machine and its input),
> the dependency of the result on that just proves that H and H1 are not
> properly Computation, and thus not eligable to be a Decider.
>
> PERIOD. DEFINITION.

The input to the halt deciders is their different execution trace thus
the halt deciders are a pure function of their input.

> H is NOT the Computational Equivalent of the Turing Machine it is
> claimed to be, as that machine would be Computation (as Turing Machines,
> but structure HAVE to be), so you argument fails at line 1 when you make
> that claim.
>
> You clearly do not understand the meaning of Computation as used in the
> field you are trying to muddle in.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<e5MYI.63146$o45.48779@fx46.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 173
Message-ID: <e5MYI.63146$o45.48779@fx46.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 4 Sep 2021 11:16:25 -0400
X-Received-Bytes: 8800
 by: Richard Damon - Sat, 4 Sep 2021 15:16 UTC

On 9/4/21 10:58 AM, olcott wrote:
> On 9/4/2021 9:18 AM, Richard Damon wrote:
>> On 9/4/21 10:06 AM, olcott wrote:
>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>        In computability theory, the halting problem is the
>>>>>>>>>        problem of determining, from a description of an arbitrary
>>>>>>>>>        computer program and an input,
>>>>>>>>>
>>>>>>>>>        whether the simulation of this program must be aborted to
>>>>>>>>>        prevent it from running forever.
>>>>>>>>>
>>>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>> allowing
>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>
>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>>> applies
>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>>> of H.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>
>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>>
>>>>>>>>> This is only answering the question:
>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>
>>>>>>>>> The required question is:
>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>>> status
>>>>>>>>> of its input?
>>>>>>>>>
>>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩
>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>
>>>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>>>> of:
>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The full Linz Proof:
>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>> neither is
>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>> different
>>>>>>>> answers to the same input.
>>>>>>>>
>>>>>>>
>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>> Their execution order makes them distinctly different computations.
>>>>>>>
>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>>>
>>>>>>> This execution sequence order makes them distinctly different
>>>>>>> computations.
>>>>>>>
>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>> applied to
>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>
>>>>>> IF H1 is a different computation than H, then the fact that it can
>>>>>> get
>>>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>>>> was built on.
>>>>>>
>>>>>
>>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at
>>>>> Ĥ.qx.
>>>>> It turns out that using my simulating halt decider criteria H would
>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>
>>>> Not quite, you are missing the meaning of words here. H was supposed to
>>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>>> identically to the original. This is a fundamental property of being a
>>>> Computation, if you make an exact copy of the algorithm, you will get
>>>> the identical behavior.
>>> I have empirically proved that this is merely a false assumption.
>>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>>
>>> In the first case we have a halt decider that sees another halt decider
>>> abort the simulation of its input.
>>>
>>> In the second case we have a halt decider that does not see another halt
>>> decider abort the simulation of its input.
>>>
>>> The execution order of with H1 before H derives a different execution
>>> trace for H1 than for H.
>>>
>>> H1 is an identical copy of H and has different behavior than H because
>>> its execution trace input is different than H.
>>>
>>
>> Since Execution Trace is NOT defined as an input to that Computation
>> (the only inputs are the representation of the machine and its input),
>> the dependency of the result on that just proves that H and H1 are not
>> properly Computation, and thus not eligable to be a Decider.
>>
>> PERIOD. DEFINITION.
>
> The input to the halt deciders is their different execution trace thus
> the halt deciders are a pure function of their input.

No, The input to the Halt Deciders are the representation of the Machine
and its input.

What has gone on before the 'call' to that decider is NOT an input to
it, so it is NOT allowed to change its behavior.

If H1 is supposed to be a copy of the computation H, then H1 <H^> <H^>
and H <H^> <H^> are copies of the same computation given the same input
so must return the same answer, or H and H1 are not copies of the same
computation BY DEFINITION.

Since a Computation is defined as the combination of the step by step
algorithm with its data input, and H and H1 supposedly have the same
step by step algorithm (code) and the same input, the fact that they
generate different answers says that the must be a flaw in the
definition of the Computation, in this case, apparently taking in as an
input something not provided as an input (the execution state).

This is easy to do an Von Neumann machines, as that structure has a
poorly defined 'input' space, so proving that an algorithm on such a
machine actually encodes a Computation requries detailed analysis to
make sure that everything used by the code is derived from the formally
defined inputs, and never uses memory with values outside that set.

The advantage of Turing Machines for this sort of operation is that, by
their structure, the algorithm and input are clearly seperated and the
input cleanly defined, thus by simply defining the 'input' to be the
contents of the tape (and the starting state) ALL Turing Machines encode
computations.

To get the same effect for a Von Neumann machine, you would need to
define ALL of the ram of the machine as its input, but since that
includes the program loaded into that machine too, and all the state
from any calling program, that ends up not being workable.


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<lIOdnaRe2ItREK78nZ2dnUU7-QXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.theory sci.logic
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, 04 Sep 2021 10:16:27 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory,comp.ai.philosophy,comp.theory,sci.logic
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 10:16:27 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <dfLYI.6743$3p3.5819@fx16.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <lIOdnaRe2ItREK78nZ2dnUU7-QXNnZ2d@giganews.com>
Lines: 132
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-VrHQytaYRRA3EfHlzIkXbnmzYTgFIM/8HriPXY4ouUmYuaD2xgtl4mh72EKJZ6CBvYbrX2Cblyj0FlY!MimZURwFZeDGdJzgMVi4QOnochm3xqvdf75M4pelFBgy/K+0TVwEc8plAKb2vDUQbuppjrfCeBqd!xzA=
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: 7144
 by: olcott - Sat, 4 Sep 2021 15:16 UTC

On 9/4/2021 9:18 AM, Richard Damon wrote:
> On 9/4/21 10:06 AM, olcott wrote:
>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>> On 9/3/21 10:13 PM, olcott wrote:
>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>       In computability theory, the halting problem is the
>>>>>>>>       problem of determining, from a description of an arbitrary
>>>>>>>>       computer program and an input,
>>>>>>>>
>>>>>>>>       whether the simulation of this program must be aborted to
>>>>>>>>       prevent it from running forever.
>>>>>>>>
>>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>>>> their halting status to be correctly decided.
>>>>>>>>
>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>> applies
>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>> of H.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>
>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>
>>>>>>>> This is only answering the question:
>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>
>>>>>>>> The required question is:
>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>> status
>>>>>>>> of its input?
>>>>>>>>
>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>>> of:
>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The full Linz Proof:
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>
>>>>>>>
>>>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>>>> actually a computation as the same computation can't give two
>>>>>>> different
>>>>>>> answers to the same input.
>>>>>>>
>>>>>>
>>>>>> I claim that H1 has identical machine code as H.
>>>>>> Their execution order makes them distinctly different computations.
>>>>>>
>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>>
>>>>>> This execution sequence order makes them distinctly different
>>>>>> computations.
>>>>>>
>>>>>> This is exactly the same as the when the original Linz H is applied to
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> IF H1 is a different computation than H, then the fact that it can get
>>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>>> was built on.
>>>>>
>>>>
>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>>>> It turns out that using my simulating halt decider criteria H would
>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>
>>> Not quite, you are missing the meaning of words here. H was supposed to
>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>> identically to the original. This is a fundamental property of being a
>>> Computation, if you make an exact copy of the algorithm, you will get
>>> the identical behavior.
>> I have empirically proved that this is merely a false assumption.
>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>
>> In the first case we have a halt decider that sees another halt decider
>> abort the simulation of its input.
>>
>> In the second case we have a halt decider that does not see another halt
>> decider abort the simulation of its input.
>>
>> The execution order of with H1 before H derives a different execution
>> trace for H1 than for H.
>>
>> H1 is an identical copy of H and has different behavior than H because
>> its execution trace input is different than H.
>>
>
> Since Execution Trace is NOT defined as an input to that Computation
> (the only inputs are the representation of the machine and its input),
> the dependency of the result on that just proves that H and H1 are not
> properly Computation, and thus not eligable to be a Decider.
>
> PERIOD. DEFINITION.

The input to the halt deciders is their different execution trace thus
the halt deciders are a pure function of their input.

> H is NOT the Computational Equivalent of the Turing Machine it is
> claimed to be, as that machine would be Computation (as Turing Machines,
> but structure HAVE to be), so you argument fails at line 1 when you make
> that claim.
>
> You clearly do not understand the meaning of Computation as used in the
> field you are trying to muddle in.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<sh02pf$kib$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: The key mistake of the Peter Linz HP proof
Date: Sat, 4 Sep 2021 10:19:11 -0500
Organization: A noiseless patient Spider
Lines: 184
Message-ID: <sh02pf$kib$1@dont-email.me>
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 4 Sep 2021 15:19:12 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="1e489f112018c2cab336a4e333a2570a";
logging-data="21067"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX183VyOX0qFe+KXisFJyDToL"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:gY7fpsExWEV8VQfn+o49Hbip1XY=
In-Reply-To: <e5MYI.63146$o45.48779@fx46.iad>
Content-Language: en-US
 by: olcott - Sat, 4 Sep 2021 15:19 UTC

On 9/4/2021 10:16 AM, Richard Damon wrote:
> On 9/4/21 10:58 AM, olcott wrote:
>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>> On 9/4/21 10:06 AM, olcott wrote:
>>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>>        In computability theory, the halting problem is the
>>>>>>>>>>        problem of determining, from a description of an arbitrary
>>>>>>>>>>        computer program and an input,
>>>>>>>>>>
>>>>>>>>>>        whether the simulation of this program must be aborted to
>>>>>>>>>>        prevent it from running forever.
>>>>>>>>>>
>>>>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>>> allowing
>>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>>
>>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>>>> applies
>>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>>>> of H.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>>
>>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>>>
>>>>>>>>>> This is only answering the question:
>>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>>
>>>>>>>>>> The required question is:
>>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>>>> status
>>>>>>>>>> of its input?
>>>>>>>>>>
>>>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩
>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>
>>>>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>>>>> of:
>>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The full Linz Proof:
>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>>> neither is
>>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>>> different
>>>>>>>>> answers to the same input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>>> Their execution order makes them distinctly different computations.
>>>>>>>>
>>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>>>>
>>>>>>>> This execution sequence order makes them distinctly different
>>>>>>>> computations.
>>>>>>>>
>>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>>> applied to
>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>
>>>>>>> IF H1 is a different computation than H, then the fact that it can
>>>>>>> get
>>>>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>>>>> was built on.
>>>>>>>
>>>>>>
>>>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at
>>>>>> Ĥ.qx.
>>>>>> It turns out that using my simulating halt decider criteria H would
>>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>>
>>>>> Not quite, you are missing the meaning of words here. H was supposed to
>>>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>>>> identically to the original. This is a fundamental property of being a
>>>>> Computation, if you make an exact copy of the algorithm, you will get
>>>>> the identical behavior.
>>>> I have empirically proved that this is merely a false assumption.
>>>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>>>
>>>> In the first case we have a halt decider that sees another halt decider
>>>> abort the simulation of its input.
>>>>
>>>> In the second case we have a halt decider that does not see another halt
>>>> decider abort the simulation of its input.
>>>>
>>>> The execution order of with H1 before H derives a different execution
>>>> trace for H1 than for H.
>>>>
>>>> H1 is an identical copy of H and has different behavior than H because
>>>> its execution trace input is different than H.
>>>>
>>>
>>> Since Execution Trace is NOT defined as an input to that Computation
>>> (the only inputs are the representation of the machine and its input),
>>> the dependency of the result on that just proves that H and H1 are not
>>> properly Computation, and thus not eligable to be a Decider.
>>>
>>> PERIOD. DEFINITION.
>>
>> The input to the halt deciders is their different execution trace thus
>> the halt deciders are a pure function of their input.
>
> No, The input to the Halt Deciders are the representation of the Machine
> and its input.
>

That is not an input to the halt deciders, that it an input to the
simulators.

> What has gone on before the 'call' to that decider is NOT an input to
> it, so it is NOT allowed to change its behavior.
>
> If H1 is supposed to be a copy of the computation H, then H1 <H^> <H^>
> and H <H^> <H^> are copies of the same computation given the same input
> so must return the same answer, or H and H1 are not copies of the same
> computation BY DEFINITION.
>
> Since a Computation is defined as the combination of the step by step
> algorithm with its data input, and H and H1 supposedly have the same
> step by step algorithm (code) and the same input, the fact that they
> generate different answers says that the must be a flaw in the
> definition of the Computation, in this case, apparently taking in as an
> input something not provided as an input (the execution state).
>
> This is easy to do an Von Neumann machines, as that structure has a
> poorly defined 'input' space, so proving that an algorithm on such a
> machine actually encodes a Computation requries detailed analysis to
> make sure that everything used by the code is derived from the formally
> defined inputs, and never uses memory with values outside that set.
>
> The advantage of Turing Machines for this sort of operation is that, by
> their structure, the algorithm and input are clearly seperated and the
> input cleanly defined, thus by simply defining the 'input' to be the
> contents of the tape (and the starting state) ALL Turing Machines encode
> computations.
>
> To get the same effect for a Von Neumann machine, you would need to
> define ALL of the ram of the machine as its input, but since that
> includes the program loaded into that machine too, and all the state
> from any calling program, that ends up not being workable.
>
>
>>
>>> H is NOT the Computational Equivalent of the Turing Machine it is
>>> claimed to be, as that machine would be Computation (as Turing Machines,
>>> but structure HAVE to be), so you argument fails at line 1 when you make
>>> that claim.
>>>
>>> You clearly do not understand the meaning of Computation as used in the
>>> field you are trying to muddle in.
>>>
>>
>>
>


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<qvMYI.67006$Kv2.65930@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lIOdnaRe2ItREK78nZ2dnUU7-QXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <lIOdnaRe2ItREK78nZ2dnUU7-QXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 155
Message-ID: <qvMYI.67006$Kv2.65930@fx47.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, 4 Sep 2021 11:44:22 -0400
X-Received-Bytes: 7722
 by: Richard Damon - Sat, 4 Sep 2021 15:44 UTC

On 9/4/21 11:16 AM, olcott wrote:
> On 9/4/2021 9:18 AM, Richard Damon wrote:
>> On 9/4/21 10:06 AM, olcott wrote:
>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>        In computability theory, the halting problem is the
>>>>>>>>>        problem of determining, from a description of an arbitrary
>>>>>>>>>        computer program and an input,
>>>>>>>>>
>>>>>>>>>        whether the simulation of this program must be aborted to
>>>>>>>>>        prevent it from running forever.
>>>>>>>>>
>>>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>> allowing
>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>
>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>>> applies
>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>>> of H.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>
>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>>
>>>>>>>>> This is only answering the question:
>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>
>>>>>>>>> The required question is:
>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>>> status
>>>>>>>>> of its input?
>>>>>>>>>
>>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩
>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>
>>>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>>>> of:
>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The full Linz Proof:
>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>> neither is
>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>> different
>>>>>>>> answers to the same input.
>>>>>>>>
>>>>>>>
>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>> Their execution order makes them distinctly different computations.
>>>>>>>
>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>>>
>>>>>>> This execution sequence order makes them distinctly different
>>>>>>> computations.
>>>>>>>
>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>> applied to
>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>
>>>>>> IF H1 is a different computation than H, then the fact that it can
>>>>>> get
>>>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>>>> was built on.
>>>>>>
>>>>>
>>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at
>>>>> Ĥ.qx.
>>>>> It turns out that using my simulating halt decider criteria H would
>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>
>>>> Not quite, you are missing the meaning of words here. H was supposed to
>>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>>> identically to the original. This is a fundamental property of being a
>>>> Computation, if you make an exact copy of the algorithm, you will get
>>>> the identical behavior.
>>> I have empirically proved that this is merely a false assumption.
>>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>>
>>> In the first case we have a halt decider that sees another halt decider
>>> abort the simulation of its input.
>>>
>>> In the second case we have a halt decider that does not see another halt
>>> decider abort the simulation of its input.
>>>
>>> The execution order of with H1 before H derives a different execution
>>> trace for H1 than for H.
>>>
>>> H1 is an identical copy of H and has different behavior than H because
>>> its execution trace input is different than H.
>>>
>>
>> Since Execution Trace is NOT defined as an input to that Computation
>> (the only inputs are the representation of the machine and its input),
>> the dependency of the result on that just proves that H and H1 are not
>> properly Computation, and thus not eligable to be a Decider.
>>
>> PERIOD. DEFINITION.
>
> The input to the halt deciders is their different execution trace thus
> the halt deciders are a pure function of their input.
>

WRONG. Read the definition of a Halt Decider again.

the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

The input to the Halt Decider is a Description of a Turing machine M and
an input w.

A simulating Halt decider may pass the input to its simulator part and
look at the results, but its input is just the Description of the
machine and input, and it derives all the rest of its information from that.

It gets NO knowledge about surrounding computations, so its answer can
not be dependent on them.

>> H is NOT the Computational Equivalent of the Turing Machine it is
>> claimed to be, as that machine would be Computation (as Turing Machines,
>> but structure HAVE to be), so you argument fails at line 1 when you make
>> that claim.
>>
>> You clearly do not understand the meaning of Computation as used in the
>> field you are trying to muddle in.
>>
>
>

Re: The key mistake of the Peter Linz HP proof

<NuMYI.67005$Kv2.12465@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!rocksolid2!i2pn.org!news.swapon.de!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!peer03.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 120
Message-ID: <NuMYI.67005$Kv2.12465@fx47.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, 4 Sep 2021 11:43:41 -0400
X-Received-Bytes: 6178
 by: Richard Damon - Sat, 4 Sep 2021 15:43 UTC

On 9/4/21 10:06 AM, olcott wrote:
> On 9/4/2021 5:50 AM, Richard Damon wrote:
>> On 9/3/21 10:13 PM, olcott wrote:
>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>       In computability theory, the halting problem is the
>>>>>>>       problem of determining, from a description of an arbitrary
>>>>>>>       computer program and an input,
>>>>>>>
>>>>>>>       whether the simulation of this program must be aborted to
>>>>>>>       prevent it from running forever.
>>>>>>>
>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>> between the direct execution of a computation and its simulation
>>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>>> their halting status to be correctly decided.
>>>>>>>
>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>> applies
>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>> of H.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>
>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>
>>>>>>> This is only answering the question:
>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>> such that this halt decider is no longer correct?
>>>>>>>
>>>>>>> The required question is:
>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>> status
>>>>>>> of its input?
>>>>>>>
>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>> of:
>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The full Linz Proof:
>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>
>>>>>>
>>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>>> actually a computation as the same computation can't give two
>>>>>> different
>>>>>> answers to the same input.
>>>>>>
>>>>>
>>>>> I claim that H1 has identical machine code as H.
>>>>> Their execution order makes them distinctly different computations.
>>>>>
>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>
>>>>> This execution sequence order makes them distinctly different
>>>>> computations.
>>>>>
>>>>> This is exactly the same as the when the original Linz H is applied to
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> IF H1 is a different computation than H, then the fact that it can get
>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>> was built on.
>>>>
>>>
>>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>>> It turns out that using my simulating halt decider criteria H would
>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>
>> Not quite, you are missing the meaning of words here. H was supposed to
>> be a Turing Machine, an exact copy of a Turing Machine will behave
>> identically to the original. This is a fundamental property of being a
>> Computation, if you make an exact copy of the algorithm, you will get
>> the identical behavior.
> I have empirically proved that this is merely a false assumption.
> int main() { H1(P,P); } sees a different execution trace than H(P,P).

This means that H is not a computation, as otherwise this is not possible.

F-

>
> In the first case we have a halt decider that sees another halt decider
> abort the simulation of its input.
>
> In the second case we have a halt decider that does not see another halt
> decider abort the simulation of its input.

Why not, it is the same input to the same computation? Only possibility
is we don't have computations here, so you have just proved that H is
not a computation and thus not eligable to be a Halt Decider.
>
> The execution order of with H1 before H derives a different execution
> trace for H1 than for H.

Because H is not a Computation,
>
> H1 is an identical copy of H and has different behavior than H because
> its execution trace input is different than H.

But 'execution trace' is not defined as an input so if it makes a
difference you have just proved that H is not a computation.
>

Re: The key mistake of the Peter Linz HP proof

<xrMYI.67004$Kv2.7463@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <sh02pf$kib$1@dont-email.me>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 165
Message-ID: <xrMYI.67004$Kv2.7463@fx47.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, 4 Sep 2021 11:40:12 -0400
X-Received-Bytes: 8054
 by: Richard Damon - Sat, 4 Sep 2021 15:40 UTC

On 9/4/21 11:19 AM, olcott wrote:
> On 9/4/2021 10:16 AM, Richard Damon wrote:
>> On 9/4/21 10:58 AM, olcott wrote:
>>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>>> On 9/4/21 10:06 AM, olcott wrote:
>>>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>>>         In computability theory, the halting problem is the
>>>>>>>>>>>         problem of determining, from a description of an
>>>>>>>>>>> arbitrary
>>>>>>>>>>>         computer program and an input,
>>>>>>>>>>>
>>>>>>>>>>>         whether the simulation of this program must be
>>>>>>>>>>> aborted to
>>>>>>>>>>>         prevent it from running forever.
>>>>>>>>>>>
>>>>>>>>>>> The above criteria is valid on the basis of the known
>>>>>>>>>>> equivalence
>>>>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>>>> allowing
>>>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>>>
>>>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>>>>> applies
>>>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>>>>> of H.
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>>>
>>>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>>>>
>>>>>>>>>>> This is only answering the question:
>>>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>>>
>>>>>>>>>>> The required question is:
>>>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>>>>> status
>>>>>>>>>>> of its input?
>>>>>>>>>>>
>>>>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩
>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>
>>>>>>>>>>> This is proved in section V3 of my paper by the analogous
>>>>>>>>>>> example
>>>>>>>>>>> of:
>>>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>
>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The full Linz Proof:
>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>>>> neither is
>>>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>>>> different
>>>>>>>>>> answers to the same input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>>>> Their execution order makes them distinctly different
>>>>>>>>> computations.
>>>>>>>>>
>>>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>>>> H(P,P) cannot see anything that aborts the simulation of its
>>>>>>>>> input.
>>>>>>>>>
>>>>>>>>> This execution sequence order makes them distinctly different
>>>>>>>>> computations.
>>>>>>>>>
>>>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>>>> applied to
>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>
>>>>>>>> IF H1 is a different computation than H, then the fact that it can
>>>>>>>> get
>>>>>>>> the answer right doesn't matter, as it wasn't the computation
>>>>>>>> that H^
>>>>>>>> was built on.
>>>>>>>>
>>>>>>>
>>>>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at
>>>>>>> Ĥ.qx.
>>>>>>> It turns out that using my simulating halt decider criteria H would
>>>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>>>
>>>>>> Not quite, you are missing the meaning of words here. H was
>>>>>> supposed to
>>>>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>>>>> identically to the original. This is a fundamental property of
>>>>>> being a
>>>>>> Computation, if you make an exact copy of the algorithm, you will get
>>>>>> the identical behavior.
>>>>> I have empirically proved that this is merely a false assumption.
>>>>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>>>>
>>>>> In the first case we have a halt decider that sees another halt
>>>>> decider
>>>>> abort the simulation of its input.
>>>>>
>>>>> In the second case we have a halt decider that does not see another
>>>>> halt
>>>>> decider abort the simulation of its input.
>>>>>
>>>>> The execution order of with H1 before H derives a different execution
>>>>> trace for H1 than for H.
>>>>>
>>>>> H1 is an identical copy of H and has different behavior than H because
>>>>> its execution trace input is different than H.
>>>>>
>>>>
>>>> Since Execution Trace is NOT defined as an input to that Computation
>>>> (the only inputs are the representation of the machine and its input),
>>>> the dependency of the result on that just proves that H and H1 are not
>>>> properly Computation, and thus not eligable to be a Decider.
>>>>
>>>> PERIOD. DEFINITION.
>>>
>>> The input to the halt deciders is their different execution trace thus
>>> the halt deciders are a pure function of their input.
>>
>> No, The input to the Halt Deciders are the representation of the Machine
>> and its input.
>>
>
> That is not an input to the halt deciders, that it an input to the
> simulators.
>
>


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 04 Sep 2021 11:09:37 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
<xrMYI.67004$Kv2.7463@fx47.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 11:09:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <xrMYI.67004$Kv2.7463@fx47.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
Lines: 185
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Doz92delaGoutGQR3hs03Xn0tzAGWben1UOm86wQTDeU8gMGI/Daf6IaC/wHcLRmSGa198ZrDlgJxok!vf4tSoQWZWEc9AvbbEwW62kg4/7Wu+xrXh0G0q3BN+Sn7FQnDGTUkkUTntMmHa1M0q5aDtDmxeph!GIc=
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: 9168
 by: olcott - Sat, 4 Sep 2021 16:09 UTC

On 9/4/2021 10:40 AM, Richard Damon wrote:
> On 9/4/21 11:19 AM, olcott wrote:
>> On 9/4/2021 10:16 AM, Richard Damon wrote:
>>> On 9/4/21 10:58 AM, olcott wrote:
>>>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>>>> On 9/4/21 10:06 AM, olcott wrote:
>>>>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>>>>         In computability theory, the halting problem is the
>>>>>>>>>>>>         problem of determining, from a description of an
>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>         computer program and an input,
>>>>>>>>>>>>
>>>>>>>>>>>>         whether the simulation of this program must be
>>>>>>>>>>>> aborted to
>>>>>>>>>>>>         prevent it from running forever.
>>>>>>>>>>>>
>>>>>>>>>>>> The above criteria is valid on the basis of the known
>>>>>>>>>>>> equivalence
>>>>>>>>>>>> between the direct execution of a computation and its simulation
>>>>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>>>>> allowing
>>>>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>>>>
>>>>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>>>>>>> applies
>>>>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>>>>>>> of H.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>>>>
>>>>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>>>>>
>>>>>>>>>>>> This is only answering the question:
>>>>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>>>>
>>>>>>>>>>>> The required question is:
>>>>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>>>>>>> status
>>>>>>>>>>>> of its input?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩
>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>
>>>>>>>>>>>> This is proved in section V3 of my paper by the analogous
>>>>>>>>>>>> example
>>>>>>>>>>>> of:
>>>>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The full Linz Proof:
>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>>>>> neither is
>>>>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>>>>> different
>>>>>>>>>>> answers to the same input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>>>>> Their execution order makes them distinctly different
>>>>>>>>>> computations.
>>>>>>>>>>
>>>>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>>>>> H(P,P) cannot see anything that aborts the simulation of its
>>>>>>>>>> input.
>>>>>>>>>>
>>>>>>>>>> This execution sequence order makes them distinctly different
>>>>>>>>>> computations.
>>>>>>>>>>
>>>>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>>>>> applied to
>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>
>>>>>>>>> IF H1 is a different computation than H, then the fact that it can
>>>>>>>>> get
>>>>>>>>> the answer right doesn't matter, as it wasn't the computation
>>>>>>>>> that H^
>>>>>>>>> was built on.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at
>>>>>>>> Ĥ.qx.
>>>>>>>> It turns out that using my simulating halt decider criteria H would
>>>>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>>>>
>>>>>>> Not quite, you are missing the meaning of words here. H was
>>>>>>> supposed to
>>>>>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>>>>>> identically to the original. This is a fundamental property of
>>>>>>> being a
>>>>>>> Computation, if you make an exact copy of the algorithm, you will get
>>>>>>> the identical behavior.
>>>>>> I have empirically proved that this is merely a false assumption.
>>>>>> int main() { H1(P,P); } sees a different execution trace than H(P,P).
>>>>>>
>>>>>> In the first case we have a halt decider that sees another halt
>>>>>> decider
>>>>>> abort the simulation of its input.
>>>>>>
>>>>>> In the second case we have a halt decider that does not see another
>>>>>> halt
>>>>>> decider abort the simulation of its input.
>>>>>>
>>>>>> The execution order of with H1 before H derives a different execution
>>>>>> trace for H1 than for H.
>>>>>>
>>>>>> H1 is an identical copy of H and has different behavior than H because
>>>>>> its execution trace input is different than H.
>>>>>>
>>>>>
>>>>> Since Execution Trace is NOT defined as an input to that Computation
>>>>> (the only inputs are the representation of the machine and its input),
>>>>> the dependency of the result on that just proves that H and H1 are not
>>>>> properly Computation, and thus not eligable to be a Decider.
>>>>>
>>>>> PERIOD. DEFINITION.
>>>>
>>>> The input to the halt deciders is their different execution trace thus
>>>> the halt deciders are a pure function of their input.
>>>
>>> No, The input to the Halt Deciders are the representation of the Machine
>>> and its input.
>>>
>>
>> That is not an input to the halt deciders, that it an input to the
>> simulators.
>>
>>
>
>
> WRONG. Read the definition of a Halt Decider again.
>


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<HdNYI.9968$2B4.2576@fx04.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx04.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
<xrMYI.67004$Kv2.7463@fx47.iad>
<JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 222
Message-ID: <HdNYI.9968$2B4.2576@fx04.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, 4 Sep 2021 12:33:42 -0400
X-Received-Bytes: 10257
 by: Richard Damon - Sat, 4 Sep 2021 16:33 UTC

On 9/4/21 12:09 PM, olcott wrote:
> On 9/4/2021 10:40 AM, Richard Damon wrote:
>> On 9/4/21 11:19 AM, olcott wrote:
>>> On 9/4/2021 10:16 AM, Richard Damon wrote:
>>>> On 9/4/21 10:58 AM, olcott wrote:
>>>>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>>>>> On 9/4/21 10:06 AM, olcott wrote:
>>>>>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>>>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>>>>>          In computability theory, the halting problem is the
>>>>>>>>>>>>>          problem of determining, from a description of an
>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>          computer program and an input,
>>>>>>>>>>>>>
>>>>>>>>>>>>>          whether the simulation of this program must be
>>>>>>>>>>>>> aborted to
>>>>>>>>>>>>>          prevent it from running forever.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The above criteria is valid on the basis of the known
>>>>>>>>>>>>> equivalence
>>>>>>>>>>>>> between the direct execution of a computation and its
>>>>>>>>>>>>> simulation
>>>>>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>>>>>> allowing
>>>>>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider
>>>>>>>>>>>>> that
>>>>>>>>>>>>> applies
>>>>>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact
>>>>>>>>>>>>> copy
>>>>>>>>>>>>> of H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is only answering the question:
>>>>>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The required question is:
>>>>>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the
>>>>>>>>>>>>> halt
>>>>>>>>>>>>> status
>>>>>>>>>>>>> of its input?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes the original H does correctly decide the halt status of
>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is proved in section V3 of my paper by the analogous
>>>>>>>>>>>>> example
>>>>>>>>>>>>> of:
>>>>>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The full Linz Proof:
>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>>>>>> neither is
>>>>>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>>>>>> different
>>>>>>>>>>>> answers to the same input.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>>>>>> Their execution order makes them distinctly different
>>>>>>>>>>> computations.
>>>>>>>>>>>
>>>>>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>>>>>> H(P,P) cannot see anything that aborts the simulation of its
>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>> This execution sequence order makes them distinctly different
>>>>>>>>>>> computations.
>>>>>>>>>>>
>>>>>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>>>>>> applied to
>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>
>>>>>>>>>> IF H1 is a different computation than H, then the fact that it
>>>>>>>>>> can
>>>>>>>>>> get
>>>>>>>>>> the answer right doesn't matter, as it wasn't the computation
>>>>>>>>>> that H^
>>>>>>>>>> was built on.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at
>>>>>>>>> Ĥ.qx.
>>>>>>>>> It turns out that using my simulating halt decider criteria H
>>>>>>>>> would
>>>>>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>>>>>
>>>>>>>> Not quite, you are missing the meaning of words here. H was
>>>>>>>> supposed to
>>>>>>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>>>>>>> identically to the original. This is a fundamental property of
>>>>>>>> being a
>>>>>>>> Computation, if you make an exact copy of the algorithm, you
>>>>>>>> will get
>>>>>>>> the identical behavior.
>>>>>>> I have empirically proved that this is merely a false assumption.
>>>>>>> int main() { H1(P,P); } sees a different execution trace than
>>>>>>> H(P,P).
>>>>>>>
>>>>>>> In the first case we have a halt decider that sees another halt
>>>>>>> decider
>>>>>>> abort the simulation of its input.
>>>>>>>
>>>>>>> In the second case we have a halt decider that does not see another
>>>>>>> halt
>>>>>>> decider abort the simulation of its input.
>>>>>>>
>>>>>>> The execution order of with H1 before H derives a different
>>>>>>> execution
>>>>>>> trace for H1 than for H.
>>>>>>>
>>>>>>> H1 is an identical copy of H and has different behavior than H
>>>>>>> because
>>>>>>> its execution trace input is different than H.
>>>>>>>
>>>>>>
>>>>>> Since Execution Trace is NOT defined as an input to that Computation
>>>>>> (the only inputs are the representation of the machine and its
>>>>>> input),
>>>>>> the dependency of the result on that just proves that H and H1 are
>>>>>> not
>>>>>> properly Computation, and thus not eligable to be a Decider.
>>>>>>
>>>>>> PERIOD. DEFINITION.
>>>>>
>>>>> The input to the halt deciders is their different execution trace thus
>>>>> the halt deciders are a pure function of their input.
>>>>
>>>> No, The input to the Halt Deciders are the representation of the
>>>> Machine
>>>> and its input.
>>>>
>>>
>>> That is not an input to the halt deciders, that it an input to the
>>> simulators.
>>>
>>>
>>
>>
>> WRONG. Read the definition of a Halt Decider again.
>>
>
> It has never occurred to anyone ever before that there could be such a
> thing as a simulating halt decider, at least not to the extent that I
> have elaborated it.
>


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<x9ednXSZ5LuCOK78nZ2dnUU7-cvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 04 Sep 2021 11:55:59 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
<xrMYI.67004$Kv2.7463@fx47.iad>
<JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
<HdNYI.9968$2B4.2576@fx04.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 11:55:50 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <HdNYI.9968$2B4.2576@fx04.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <x9ednXSZ5LuCOK78nZ2dnUU7-cvNnZ2d@giganews.com>
Lines: 247
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-XdecBNmImgTaqOqN+sOLDZW2+Y097ENi1jcPBaBClFlWmcU1DoyJP9JxY4pHIIIi+DSDrE0Q+wd6MK+!c5i1p9qGeP3Gywplzztj25vVHeujGEtqEQN67lrblpXSgXKxErSpUzAO/mAEEYYUpEOzf6i8h8kR!F7w=
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: 11531
 by: olcott - Sat, 4 Sep 2021 16:55 UTC

On 9/4/2021 11:33 AM, Richard Damon wrote:
> On 9/4/21 12:09 PM, olcott wrote:
>> On 9/4/2021 10:40 AM, Richard Damon wrote:
>>> On 9/4/21 11:19 AM, olcott wrote:
>>>> On 9/4/2021 10:16 AM, Richard Damon wrote:
>>>>> On 9/4/21 10:58 AM, olcott wrote:
>>>>>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>>>>>> On 9/4/21 10:06 AM, olcott wrote:
>>>>>>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>>>>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>>>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>          In computability theory, the halting problem is the
>>>>>>>>>>>>>>          problem of determining, from a description of an
>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>          computer program and an input,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          whether the simulation of this program must be
>>>>>>>>>>>>>> aborted to
>>>>>>>>>>>>>>          prevent it from running forever.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The above criteria is valid on the basis of the known
>>>>>>>>>>>>>> equivalence
>>>>>>>>>>>>>> between the direct execution of a computation and its
>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>>>>>>> allowing
>>>>>>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> applies
>>>>>>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact
>>>>>>>>>>>>>> copy
>>>>>>>>>>>>>> of H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is only answering the question:
>>>>>>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The required question is:
>>>>>>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the
>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>> status
>>>>>>>>>>>>>> of its input?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes the original H does correctly decide the halt status of
>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is proved in section V3 of my paper by the analogous
>>>>>>>>>>>>>> example
>>>>>>>>>>>>>> of:
>>>>>>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The full Linz Proof:
>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>>>>>>> neither is
>>>>>>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>>>>>>> different
>>>>>>>>>>>>> answers to the same input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>>>>>>> Their execution order makes them distinctly different
>>>>>>>>>>>> computations.
>>>>>>>>>>>>
>>>>>>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>>>>>>> H(P,P) cannot see anything that aborts the simulation of its
>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> This execution sequence order makes them distinctly different
>>>>>>>>>>>> computations.
>>>>>>>>>>>>
>>>>>>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>>>>>>> applied to
>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>
>>>>>>>>>>> IF H1 is a different computation than H, then the fact that it
>>>>>>>>>>> can
>>>>>>>>>>> get
>>>>>>>>>>> the answer right doesn't matter, as it wasn't the computation
>>>>>>>>>>> that H^
>>>>>>>>>>> was built on.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The Linz Ĥ is only required to have an exact copy of the Linz H at
>>>>>>>>>> Ĥ.qx.
>>>>>>>>>> It turns out that using my simulating halt decider criteria H
>>>>>>>>>> would
>>>>>>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>>>>>>
>>>>>>>>> Not quite, you are missing the meaning of words here. H was
>>>>>>>>> supposed to
>>>>>>>>> be a Turing Machine, an exact copy of a Turing Machine will behave
>>>>>>>>> identically to the original. This is a fundamental property of
>>>>>>>>> being a
>>>>>>>>> Computation, if you make an exact copy of the algorithm, you
>>>>>>>>> will get
>>>>>>>>> the identical behavior.
>>>>>>>> I have empirically proved that this is merely a false assumption.
>>>>>>>> int main() { H1(P,P); } sees a different execution trace than
>>>>>>>> H(P,P).
>>>>>>>>
>>>>>>>> In the first case we have a halt decider that sees another halt
>>>>>>>> decider
>>>>>>>> abort the simulation of its input.
>>>>>>>>
>>>>>>>> In the second case we have a halt decider that does not see another
>>>>>>>> halt
>>>>>>>> decider abort the simulation of its input.
>>>>>>>>
>>>>>>>> The execution order of with H1 before H derives a different
>>>>>>>> execution
>>>>>>>> trace for H1 than for H.
>>>>>>>>
>>>>>>>> H1 is an identical copy of H and has different behavior than H
>>>>>>>> because
>>>>>>>> its execution trace input is different than H.
>>>>>>>>
>>>>>>>
>>>>>>> Since Execution Trace is NOT defined as an input to that Computation
>>>>>>> (the only inputs are the representation of the machine and its
>>>>>>> input),
>>>>>>> the dependency of the result on that just proves that H and H1 are
>>>>>>> not
>>>>>>> properly Computation, and thus not eligable to be a Decider.
>>>>>>>
>>>>>>> PERIOD. DEFINITION.
>>>>>>
>>>>>> The input to the halt deciders is their different execution trace thus
>>>>>> the halt deciders are a pure function of their input.
>>>>>
>>>>> No, The input to the Halt Deciders are the representation of the
>>>>> Machine
>>>>> and its input.
>>>>>
>>>>
>>>> That is not an input to the halt deciders, that it an input to the
>>>> simulators.
>>>>
>>>>
>>>
>>>
>>> WRONG. Read the definition of a Halt Decider again.
>>>
>>
>> It has never occurred to anyone ever before that there could be such a
>> thing as a simulating halt decider, at least not to the extent that I
>> have elaborated it.
>>
>
> That is incorrect. Look at page 317, Linz discusses the issue of using a
> UTM as the basis for a Halt Decider. YOU have yet to disprove his claim


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<ePNYI.24764$tA2.4582@fx02.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
<xrMYI.67004$Kv2.7463@fx47.iad>
<JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
<HdNYI.9968$2B4.2576@fx04.iad>
<x9ednXSZ5LuCOK78nZ2dnUU7-cvNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <x9ednXSZ5LuCOK78nZ2dnUU7-cvNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 298
Message-ID: <ePNYI.24764$tA2.4582@fx02.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, 4 Sep 2021 13:13:46 -0400
X-Received-Bytes: 13333
 by: Richard Damon - Sat, 4 Sep 2021 17:13 UTC

On 9/4/21 12:55 PM, olcott wrote:
> On 9/4/2021 11:33 AM, Richard Damon wrote:
>> On 9/4/21 12:09 PM, olcott wrote:
>>> On 9/4/2021 10:40 AM, Richard Damon wrote:
>>>> On 9/4/21 11:19 AM, olcott wrote:
>>>>> On 9/4/2021 10:16 AM, Richard Damon wrote:
>>>>>> On 9/4/21 10:58 AM, olcott wrote:
>>>>>>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>>>>>>> On 9/4/21 10:06 AM, olcott wrote:
>>>>>>>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>>>>>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>>>>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>           In computability theory, the halting problem is
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>           problem of determining, from a description of an
>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>           computer program and an input,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>           whether the simulation of this program must be
>>>>>>>>>>>>>>> aborted to
>>>>>>>>>>>>>>>           prevent it from running forever.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The above criteria is valid on the basis of the known
>>>>>>>>>>>>>>> equivalence
>>>>>>>>>>>>>>> between the direct execution of a computation and its
>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>>>>>>>> allowing
>>>>>>>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> applies
>>>>>>>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact
>>>>>>>>>>>>>>> copy
>>>>>>>>>>>>>>> of H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>>>>>>>> based on Ĥ applied to its own Turing machine description
>>>>>>>>>>>>>>> ⟨Ĥ⟩.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is only answering the question:
>>>>>>>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The required question is:
>>>>>>>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the
>>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>>> status
>>>>>>>>>>>>>>> of its input?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes the original H does correctly decide the halt status of
>>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is proved in section V3 of my paper by the analogous
>>>>>>>>>>>>>>> example
>>>>>>>>>>>>>>> of:
>>>>>>>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The full Linz Proof:
>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>>>>>>>> neither is
>>>>>>>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> answers to the same input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>>>>>>>> Their execution order makes them distinctly different
>>>>>>>>>>>>> computations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>>>>>>>> H(P,P) cannot see anything that aborts the simulation of its
>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This execution sequence order makes them distinctly different
>>>>>>>>>>>>> computations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>>>>>>>> applied to
>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>
>>>>>>>>>>>> IF H1 is a different computation than H, then the fact that it
>>>>>>>>>>>> can
>>>>>>>>>>>> get
>>>>>>>>>>>> the answer right doesn't matter, as it wasn't the computation
>>>>>>>>>>>> that H^
>>>>>>>>>>>> was built on.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The Linz Ĥ is only required to have an exact copy of the Linz
>>>>>>>>>>> H at
>>>>>>>>>>> Ĥ.qx.
>>>>>>>>>>> It turns out that using my simulating halt decider criteria H
>>>>>>>>>>> would
>>>>>>>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>>>>>>>
>>>>>>>>>> Not quite, you are missing the meaning of words here. H was
>>>>>>>>>> supposed to
>>>>>>>>>> be a Turing Machine, an exact copy of a Turing Machine will
>>>>>>>>>> behave
>>>>>>>>>> identically to the original. This is a fundamental property of
>>>>>>>>>> being a
>>>>>>>>>> Computation, if you make an exact copy of the algorithm, you
>>>>>>>>>> will get
>>>>>>>>>> the identical behavior.
>>>>>>>>> I have empirically proved that this is merely a false assumption.
>>>>>>>>> int main() { H1(P,P); } sees a different execution trace than
>>>>>>>>> H(P,P).
>>>>>>>>>
>>>>>>>>> In the first case we have a halt decider that sees another halt
>>>>>>>>> decider
>>>>>>>>> abort the simulation of its input.
>>>>>>>>>
>>>>>>>>> In the second case we have a halt decider that does not see
>>>>>>>>> another
>>>>>>>>> halt
>>>>>>>>> decider abort the simulation of its input.
>>>>>>>>>
>>>>>>>>> The execution order of with H1 before H derives a different
>>>>>>>>> execution
>>>>>>>>> trace for H1 than for H.
>>>>>>>>>
>>>>>>>>> H1 is an identical copy of H and has different behavior than H
>>>>>>>>> because
>>>>>>>>> its execution trace input is different than H.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Since Execution Trace is NOT defined as an input to that
>>>>>>>> Computation
>>>>>>>> (the only inputs are the representation of the machine and its
>>>>>>>> input),
>>>>>>>> the dependency of the result on that just proves that H and H1 are
>>>>>>>> not
>>>>>>>> properly Computation, and thus not eligable to be a Decider.
>>>>>>>>
>>>>>>>> PERIOD. DEFINITION.
>>>>>>>
>>>>>>> The input to the halt deciders is their different execution trace
>>>>>>> thus
>>>>>>> the halt deciders are a pure function of their input.
>>>>>>
>>>>>> No, The input to the Halt Deciders are the representation of the
>>>>>> Machine
>>>>>> and its input.
>>>>>>
>>>>>
>>>>> That is not an input to the halt deciders, that it an input to the
>>>>> simulators.
>>>>>
>>>>>
>>>>
>>>>
>>>> WRONG. Read the definition of a Halt Decider again.
>>>>
>>>
>>> It has never occurred to anyone ever before that there could be such a
>>> thing as a simulating halt decider, at least not to the extent that I
>>> have elaborated it.
>>>
>>
>> That is incorrect. Look at page 317, Linz discusses the issue of using a
>> UTM as the basis for a Halt Decider. YOU have yet to disprove his claim
>
> He is not referring to is simulating halt decider he is referring to
> using a simulator as a decider to simply wait and see what the inputs does.


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<gLKdnctwNpqsNq78nZ2dnUU7-bfNnZ2d@giganews.com>

 copy mid

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

 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, 04 Sep 2021 12:21:53 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
<xrMYI.67004$Kv2.7463@fx47.iad>
<JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
<HdNYI.9968$2B4.2576@fx04.iad>
<x9ednXSZ5LuCOK78nZ2dnUU7-cvNnZ2d@giganews.com>
<ePNYI.24764$tA2.4582@fx02.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 12:21:53 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <ePNYI.24764$tA2.4582@fx02.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <gLKdnctwNpqsNq78nZ2dnUU7-bfNnZ2d@giganews.com>
Lines: 312
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-EaRK3WpvfCzaQ7my755Db23pAwnfHId6sRuy2yFHQ66mhgC0GtoSfLfTa5BtGItGLYCb/RpLtKq/VKW!ye5CNpli6A2xVHtrDyR0UgKi3Tz0CqTXfeFXSG2onnx4ZfFBG+AqdP00XMGdv/0HOVEqCCyW5Llu!jAI=
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: 14396
 by: olcott - Sat, 4 Sep 2021 17:21 UTC

On 9/4/2021 12:13 PM, Richard Damon wrote:
> On 9/4/21 12:55 PM, olcott wrote:
>> On 9/4/2021 11:33 AM, Richard Damon wrote:
>>> On 9/4/21 12:09 PM, olcott wrote:
>>>> On 9/4/2021 10:40 AM, Richard Damon wrote:
>>>>> On 9/4/21 11:19 AM, olcott wrote:
>>>>>> On 9/4/2021 10:16 AM, Richard Damon wrote:
>>>>>>> On 9/4/21 10:58 AM, olcott wrote:
>>>>>>>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>>>>>>>> On 9/4/21 10:06 AM, olcott wrote:
>>>>>>>>>> On 9/4/2021 5:50 AM, Richard Damon wrote:
>>>>>>>>>>> On 9/3/21 10:13 PM, olcott wrote:
>>>>>>>>>>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>           In computability theory, the halting problem is
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>           problem of determining, from a description of an
>>>>>>>>>>>>>>>> arbitrary
>>>>>>>>>>>>>>>>           computer program and an input,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>           whether the simulation of this program must be
>>>>>>>>>>>>>>>> aborted to
>>>>>>>>>>>>>>>>           prevent it from running forever.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The above criteria is valid on the basis of the known
>>>>>>>>>>>>>>>> equivalence
>>>>>>>>>>>>>>>> between the direct execution of a computation and its
>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>> by a UTM. The same criteria universally works on all inputs
>>>>>>>>>>>>>>>> allowing
>>>>>>>>>>>>>>>> their halting status to be correctly decided.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The Peter Linz H is defined to be a simulating halt decider
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> applies
>>>>>>>>>>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact
>>>>>>>>>>>>>>>> copy
>>>>>>>>>>>>>>>> of H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>>>>>>>>>>> based on Ĥ applied to its own Turing machine description
>>>>>>>>>>>>>>>> ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is only answering the question:
>>>>>>>>>>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>>>>>>>>>>> such that this halt decider is no longer correct?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The required question is:
>>>>>>>>>>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the
>>>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>>>> status
>>>>>>>>>>>>>>>> of its input?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes the original H does correctly decide the halt status of
>>>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is proved in section V3 of my paper by the analogous
>>>>>>>>>>>>>>>> example
>>>>>>>>>>>>>>>> of:
>>>>>>>>>>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>> ⟨Ĥ⟩
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The full Linz Proof:
>>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, do you claim H1 is the SAME computation as H, and thus
>>>>>>>>>>>>>>> neither is
>>>>>>>>>>>>>>> actually a computation as the same computation can't give two
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> answers to the same input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I claim that H1 has identical machine code as H.
>>>>>>>>>>>>>> Their execution order makes them distinctly different
>>>>>>>>>>>>>> computations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>>>>>>>>>>> H(P,P) cannot see anything that aborts the simulation of its
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This execution sequence order makes them distinctly different
>>>>>>>>>>>>>> computations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is exactly the same as the when the original Linz H is
>>>>>>>>>>>>>> applied to
>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>
>>>>>>>>>>>>> IF H1 is a different computation than H, then the fact that it
>>>>>>>>>>>>> can
>>>>>>>>>>>>> get
>>>>>>>>>>>>> the answer right doesn't matter, as it wasn't the computation
>>>>>>>>>>>>> that H^
>>>>>>>>>>>>> was built on.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The Linz Ĥ is only required to have an exact copy of the Linz
>>>>>>>>>>>> H at
>>>>>>>>>>>> Ĥ.qx.
>>>>>>>>>>>> It turns out that using my simulating halt decider criteria H
>>>>>>>>>>>> would
>>>>>>>>>>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>>>>>>>>>>
>>>>>>>>>>> Not quite, you are missing the meaning of words here. H was
>>>>>>>>>>> supposed to
>>>>>>>>>>> be a Turing Machine, an exact copy of a Turing Machine will
>>>>>>>>>>> behave
>>>>>>>>>>> identically to the original. This is a fundamental property of
>>>>>>>>>>> being a
>>>>>>>>>>> Computation, if you make an exact copy of the algorithm, you
>>>>>>>>>>> will get
>>>>>>>>>>> the identical behavior.
>>>>>>>>>> I have empirically proved that this is merely a false assumption.
>>>>>>>>>> int main() { H1(P,P); } sees a different execution trace than
>>>>>>>>>> H(P,P).
>>>>>>>>>>
>>>>>>>>>> In the first case we have a halt decider that sees another halt
>>>>>>>>>> decider
>>>>>>>>>> abort the simulation of its input.
>>>>>>>>>>
>>>>>>>>>> In the second case we have a halt decider that does not see
>>>>>>>>>> another
>>>>>>>>>> halt
>>>>>>>>>> decider abort the simulation of its input.
>>>>>>>>>>
>>>>>>>>>> The execution order of with H1 before H derives a different
>>>>>>>>>> execution
>>>>>>>>>> trace for H1 than for H.
>>>>>>>>>>
>>>>>>>>>> H1 is an identical copy of H and has different behavior than H
>>>>>>>>>> because
>>>>>>>>>> its execution trace input is different than H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Since Execution Trace is NOT defined as an input to that
>>>>>>>>> Computation
>>>>>>>>> (the only inputs are the representation of the machine and its
>>>>>>>>> input),
>>>>>>>>> the dependency of the result on that just proves that H and H1 are
>>>>>>>>> not
>>>>>>>>> properly Computation, and thus not eligable to be a Decider.
>>>>>>>>>
>>>>>>>>> PERIOD. DEFINITION.
>>>>>>>>
>>>>>>>> The input to the halt deciders is their different execution trace
>>>>>>>> thus
>>>>>>>> the halt deciders are a pure function of their input.
>>>>>>>
>>>>>>> No, The input to the Halt Deciders are the representation of the
>>>>>>> Machine
>>>>>>> and its input.
>>>>>>>
>>>>>>
>>>>>> That is not an input to the halt deciders, that it an input to the
>>>>>> simulators.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> WRONG. Read the definition of a Halt Decider again.
>>>>>
>>>>
>>>> It has never occurred to anyone ever before that there could be such a
>>>> thing as a simulating halt decider, at least not to the extent that I
>>>> have elaborated it.
>>>>
>>>
>>> That is incorrect. Look at page 317, Linz discusses the issue of using a
>>> UTM as the basis for a Halt Decider. YOU have yet to disprove his claim
>>
>> He is not referring to is simulating halt decider he is referring to
>> using a simulator as a decider to simply wait and see what the inputs does.
>
>
> He says:
>
> If M enters an infinite loop, then no matter how long we wait, we can
> never be sure that M is in fact in a loop. It may simply be a case of a
> very long computation. What we need is an algorithm that can determine
> the correct answer for any M and w by performing some analysis on the
> machine's description and the input. But as we now show, no such
> algorithm exists.
>
> Thus he recognized that the issue with a simulating decider would be it


Click here to read the complete article
Re: The key mistake of the Peter Linz HP proof

<sh0an6$f8o$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: news.x.r...@xoxy.net (Richard Damon)
Newsgroups: comp.theory
Subject: Re: The key mistake of the Peter Linz HP proof
Date: Sat, 4 Sep 2021 13:34:29 -0400
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <sh0an6$f8o$1@dont-email.me>
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
<xrMYI.67004$Kv2.7463@fx47.iad>
<JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
<HdNYI.9968$2B4.2576@fx04.iad>
<x9ednXSZ5LuCOK78nZ2dnUU7-cvNnZ2d@giganews.com>
<ePNYI.24764$tA2.4582@fx02.iad>
<gLKdnctwNpqsNq78nZ2dnUU7-bfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 4 Sep 2021 17:34:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a6e2067bdff134fdeb62d68b685a33c7";
logging-data="15640"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+/+9pmefrhB/ixLG3WHwXj0tKYDC4O/6A="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
Cancel-Lock: sha1:y190NQT2C/CSACkDvjvKl59xfuU=
In-Reply-To: <gLKdnctwNpqsNq78nZ2dnUU7-bfNnZ2d@giganews.com>
Content-Language: en-US
 by: Richard Damon - Sat, 4 Sep 2021 17:34 UTC

On 9/4/21 1:21 PM, olcott wrote:
> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>
>>
>> He says:
>>
>> If M enters an infinite loop, then no matter how long we wait, we can
>> never be sure that M is in fact in a loop. It may simply be a case of a
>> very long computation. What we need is an algorithm that can determine
>> the correct answer for any M and w by performing some analysis on the
>> machine's description and the input. But as we now show, no such
>> algorithm exists.
>>
>> Thus he recognized that the issue with a simulating decider would be it
>
> No he recognized the very obvious issue of using a simulator instead of
> a decider. No one besides me has ever considered a simulating halt
> decider that examines the simulated execution trace for non halting
> patterns of behavior.

Nope, He understood the issues involved. Maybe if you had studied some
of the field you would know that the limitation of Halt Deciding by
Simulating are WELL known, and have been shown to be impossible in general.

They can answer some SPECIFIC forms of infinite behavior, but can not in
general.

I think part of your problem is that YOU don't understand some of the
forms that are proven impossible, as shown by your claim that 'ALL' of
the proofs of the Halting Problem are based on this one method, which is
a demonstratably false statement.

It may be the only one you understand, but it isn't the only one.

Re: The key mistake of the Peter Linz HP proof

<C7OdneoKVKpgLa78nZ2dnUU7-WFQAAAA@giganews.com>

 copy mid

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

 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, 04 Sep 2021 12:46:37 -0500
Subject: Re: The key mistake of the Peter Linz HP proof
Newsgroups: comp.theory
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
<nDzYI.36338$rl3.29330@fx45.iad>
<wuWdnbKfmPAWVK_8nZ2dnUU7-VnNnZ2d@giganews.com>
<XkAYI.19068$z%4.13606@fx37.iad>
<JomdnWOlb7DMS6_8nZ2dnUU7-YfNnZ2d@giganews.com>
<ecIYI.71866$T_8.30491@fx48.iad>
<dYmdnfYvyfXx4K78nZ2dnUU7-YPNnZ2d@giganews.com>
<dfLYI.6743$3p3.5819@fx16.iad>
<lJOdnbkpMN0LFK78nZ2dnUU7-bXNnZ2d@giganews.com>
<e5MYI.63146$o45.48779@fx46.iad> <sh02pf$kib$1@dont-email.me>
<xrMYI.67004$Kv2.7463@fx47.iad>
<JJOdnfu1wu_cB678nZ2dnUU78LXNnZ2d@giganews.com>
<HdNYI.9968$2B4.2576@fx04.iad>
<x9ednXSZ5LuCOK78nZ2dnUU7-cvNnZ2d@giganews.com>
<ePNYI.24764$tA2.4582@fx02.iad>
<gLKdnctwNpqsNq78nZ2dnUU7-bfNnZ2d@giganews.com> <sh0an6$f8o$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 4 Sep 2021 12:46:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <sh0an6$f8o$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <C7OdneoKVKpgLa78nZ2dnUU7-WFQAAAA@giganews.com>
Lines: 48
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LIZqFpJGApcTNmS+ky70TQcXeeFCVGRqK70pjiISbuCXgDntk+5BqNxHW9b8xq++LQbv8sX7kcQsH5e!N0/OqXQRWGX2+Ay8P3kd4463XfmndCJ6sippgZs7igA/CSt/ZABzMkDJ50qjUAJ7MItjcxQzBsYU!tAc=
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: 3795
 by: olcott - Sat, 4 Sep 2021 17:46 UTC

On 9/4/2021 12:34 PM, Richard Damon wrote:
> On 9/4/21 1:21 PM, olcott wrote:
>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>
>>>
>>> He says:
>>>
>>> If M enters an infinite loop, then no matter how long we wait, we can
>>> never be sure that M is in fact in a loop. It may simply be a case of a
>>> very long computation. What we need is an algorithm that can determine
>>> the correct answer for any M and w by performing some analysis on the
>>> machine's description and the input. But as we now show, no such
>>> algorithm exists.
>>>
>>> Thus he recognized that the issue with a simulating decider would be it
>>
>> No he recognized the very obvious issue of using a simulator instead of
>> a decider. No one besides me has ever considered a simulating halt
>> decider that examines the simulated execution trace for non halting
>> patterns of behavior.
>
> Nope, He understood the issues involved. Maybe if you had studied some
> of the field you would know that the limitation of Halt Deciding by
> Simulating are WELL known, and have been shown to be impossible in general.
>

In the text that you referenced he was only referring to using a
simulator as a decider. He was not referring to using a simulating
decider that examines the execution trace of the simulation to look for
non halting behavior patterns.

> They can answer some SPECIFIC forms of infinite behavior, but can not in
> general.
>
> I think part of your problem is that YOU don't understand some of the
> forms that are proven impossible, as shown by your claim that 'ALL' of
> the proofs of the Halting Problem are based on this one method, which is
> a demonstratably false statement.
>
> It may be the only one you understand, but it isn't the only one.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: The key mistake of the Peter Linz HP proof

<sh0cej$24fe$1@news.muc.de>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.szaf.org!news.karotte.org!news.space.net!news.muc.de!.POSTED.news.muc.de!not-for-mail
From: acm...@muc.de (Alan Mackenzie)
Newsgroups: comp.theory
Subject: Re: The key mistake of the Peter Linz HP proof
Date: Sat, 4 Sep 2021 18:04:03 -0000 (UTC)
Organization: muc.de e.V.
Message-ID: <sh0cej$24fe$1@news.muc.de>
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 4 Sep 2021 18:04:03 -0000 (UTC)
Injection-Info: news.muc.de; posting-host="news.muc.de:2001:608:1000::2";
logging-data="70126"; mail-complaints-to="news-admin@muc.de"
User-Agent: tin/2.4.5-20201224 ("Glen Albyn") (FreeBSD/12.2-RELEASE-p7 (amd64))
 by: Alan Mackenzie - Sat, 4 Sep 2021 18:04 UTC

[ Malicious cross posting snipped. ]

In comp.theory olcott <NoOne@nowhere.com> wrote:
> In computability theory, the halting problem is the
> problem of determining, from a description of an arbitrary
> computer program and an input,

> whether the simulation of this program must be aborted to
> prevent it from running forever.

No, it is not. There might well not be a simulation of the program.

> The above criteria is ...

Just as a matter of interest, "criteria" is plural. The singular is
"criterion".

> .... valid on the basis of the known equivalence between the direct
> execution of a computation and its simulation by a UTM.

Not really. There might well not be a simulation of the program.

> The same criteria universally works on all inputs allowing their
> halting status to be correctly decided.

No, they do not. It has been proven that there is no such set of
criteria (aka a turing machine) that can decide this.

> The Peter Linz H is defined to be a simulating halt decider that applies
> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.

No. The Peter Linz H doesn't exist. It's existence is posited purely
to demonstrate the contradiction that proves it cannot exist.

[ .... ]

> The mistake of the Linz proof is forming a conclusion based on Ĥ
> applied to its own Turing machine description ⟨Ĥ⟩.

No. A universal halt decider would necessarily work correctly on its
own turing machine description.

> This is only answering the question: Can changes be made to an
> otherwise correct halt decider such that this halt decider is no
> longer correct?

Are you talking about a partial halt decider, here? What does
"otherwise correct" actually mean, here? "Otherwise" than what?

> The required question is: Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
> correctly decide the halt status of its input?

The correct question was half-stated by you at the top of the post.
It's is there a turing machine which can decide the halting status of
any turing machine?

[ .... ]

> The full Linz Proof:
> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

> --
> Copyright 2021 Pete Olcott

> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

--
Alan Mackenzie (Nuremberg, Germany).

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor