Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Bus error -- driver executed.


computers / comp.ai.philosophy / The key mistake of the Peter Linz HP proof

SubjectAuthor
* The key mistake of the Peter Linz HP proofolcott
+* Re: The key mistake of the Peter Linz HP proofolcott
|+- Re: The key mistake of the Peter Linz HP proofolcott
|`- Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ]olcott
`- Re: _The_key_mistake_of_the_Peter_Linz_HP_proof:_[_Ĥ applied to ⟨Ĥ⟩ ]olcott

1
Subject: The key mistake of the Peter Linz HP proof
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math
Date: Sat, 4 Sep 2021 00:18 UTC
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
View all headers
    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


Subject: Re: The key mistake of the Peter Linz HP proof
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.logic
Date: Sat, 4 Sep 2021 14:06 UTC
References: 1 2 3 4 5 6
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
View all headers
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


Subject: Re: The key mistake of the Peter Linz HP proof
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.theory, sci.logic
Date: Sat, 4 Sep 2021 15:16 UTC
References: 1 2 3 4 5 6 7 8
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
View all headers
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


Subject: Re:_The_key_mistake_of_the_Peter_Linz_HP_proof:_[_Ĥ applied to ⟨Ĥ⟩ ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Date: Sun, 5 Sep 2021 14:46 UTC
References: 1 2 3 4 5 6
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 05 Sep 2021 09:46:13 -0500
Subject: Re:_The_key_mistake_of_the_Peter_Linz_HP_proof:_[_Ĥ applied to ⟨Ĥ⟩ ]
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@giganews.com> <sh0cej$24fe$1@news.muc.de> <96WdnSMro6-uKq78nZ2dnUU7-aOdnZ2d@giganews.com> <bSOYI.24045$nR3.12924@fx38.iad> <87sfykoyo2.fsf@bsb.me.uk> <sh234f$nmu$1@news.muc.de>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 5 Sep 2021 09:46:11 -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: <sh234f$nmu$1@news.muc.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <QPqdnUqStcKoRan8nZ2dnUU7-eHNnZ2d@giganews.com>
Lines: 59
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-6Z5YycE5Fmwit98pJEwTHV2+AWCT2dDLElMzhvMFzrz2a3UGHccNR1eFV0vEqxwenupiIucxhQefGhf!19ZlaTbDItaDKRN6VdPp11MGUv/Y6dFt0HMQ61ukNmFrNjlucLMIQkya0UDGQIkSN8lWQUtEKIUh!yoc=
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: 3594
View all headers
On 9/5/2021 4:37 AM, Alan Mackenzie wrote:
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
Richard Damon <Richard@Damon-Family.org> writes:

On 9/4/21 2:13 PM, olcott wrote:
On 9/4/2021 1:04 PM, Alan Mackenzie wrote:
[ Malicious cross posting snipped. ]

In comp.theory olcott <NoOne@nowhere.com> wrote:

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

I am stopping here. If it is impossible to simulate the TM description
of a TM then it is not a proper TM.

I am pretty sure he is referring to the unwarranted assumption that any
simulation at all is involved.

Thanks, Ben, that's exactly what I was trying to say.  Apologies to PO
for being unclear, here.

Yet the point that I am making is that when a simulating halt decider applies this criteria to its input:

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

Then the Peter Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts and transitions to H.qy on the basis of Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input does not halt and transitions to Ĥ.qn.



The context has been lost, including the key part that Alan was
objecting to:

||    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 phrase "the simulation" implies there is simulation involved.  Had
PO written "whether /a/ simulation of this program runs forever" the
reference to simulation would be silly and superfluous, but not wrong.

-- Ben.



--
Copyright 2021 Pete Olcott

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


Subject: Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Date: Fri, 17 Sep 2021 18:41 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 17 Sep 2021 13:41:38 -0500
Subject: Re: The key mistake of the Peter Linz HP proof [ Liar Liar pants on fire ]
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <2KidnW0lAqejJq_8nZ2dnUU7-UXNnZ2d@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> <C7OdneoKVKpgLa78nZ2dnUU7-WFQAAAA@giganews.com> <%IOYI.30135$VZ1.3323@fx08.iad> <EvqdncHbTYDcIq78nZ2dnUU7-UfNnZ2d@giganews.com> <TYQYI.1171$g_4.1135@fx14.iad> <08udndz4u-u5Q678nZ2dnUU7-dXNnZ2d@giganews.com> <P0SYI.23667$md6.11113@fx36.iad> <fPmdnUyPuOOHba78nZ2dnUU7-QnNnZ2d@giganews.com> <LASYI.13939$rsCb.9272@fx01.iad> <_IOdnQE0FbMxZa78nZ2dnUU7-eXNnZ2d@giganews.com> <20210917192719.00001cc0@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 17 Sep 2021 13:41:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <20210917192719.00001cc0@reddwarf.jmc>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <m6KdncZvr9L_fNn8nZ2dnUU7-UHNnZ2d@giganews.com>
Lines: 229
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-3YbT6fcleH5PNCF6179tdCkIVr+aulzvLuuSxsuxfdbA8T7me/nqFTI1pg5rgIYSjMZtfrQrOcqgPbR!v0TjuQFS7pMNSGkoBwrOLkKfyehn/cc1RpD5fxcR3EIUbvwhnVB4E8istpydkcjf5WCL4ALL21rp!C7Q=
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: 12196
View all headers
On 9/17/2021 1:27 PM, Mr Flibble wrote:
On Sat, 4 Sep 2021 17:52:27 -0500
olcott <NoOne@NoWhere.com> wrote:

On 9/4/2021 5:39 PM, Richard Damon wrote:
On 9/4/21 6:15 PM, olcott wrote:
On 9/4/2021 5:01 PM, Richard Damon wrote:
On 9/4/21 4:59 PM, olcott wrote:
On 9/4/2021 3:48 PM, Richard Damon wrote:
On 9/4/21 2:47 PM, olcott wrote:
On 9/4/2021 1:15 PM, Richard Damon wrote:
On 9/4/21 1:46 PM, olcott wrote:
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.

Nope, maybe he doesn't explicitly call it that, but his words
definitely
reference the well known and studied limitation of simulation
for halt
deciding.

Of course. If you want to tell if an infinite loops halts you
sure as Hell can't simply wait and see what happens.

It is getting to the point where I am convinced that you are
simply lying. If you are aware of any source besides me that
proposes a simulating halt decider that specifically examines
the execution trace of its simulation to match non-halting
behavior patterns of its input then PUT UP OR SHUT UP !!!
 

Most of the stuff I know was pre-internet, so not easy to find.

Here is one example of a reference to this from a decade ago:
https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines



This mentions one of the techniques used for detecting SOME
forms of infinite loops.

Here is another person needing to solve the halting problem for
a limited case, and was given a few examples of classical
methods (like detecting repeating state) to detect an infinite
loop.

https://try2explore.com/questions/10671161

And then there is this article on detecting the non-termination
of Turing Machines, to look for solutions to things like the
Busy-Beaver problem:

https://dl.acm.org/doi/pdf/10.5555/1273694.1273703

While not specifically a 'simulating Halt Decider' it is trying
to solve
the same basic problem.
 
Maybe the fact that you refuse to study the field means you
don't recognize that, and are dooming yourself to repeating
all the mistakes that have been worked through over the
century,

PUT UP OR SHUT UP !!!
PUT UP OR SHUT UP !!!
PUT UP OR SHUT UP !!!
PUT UP OR SHUT UP !!!

Will you now SHUT UP that NO ONE has looked at this before?

My original words included to the same extent that I have.

None-the-less is seems clear that you now do understand that
when Linz referred to a UTM he was only referring to using a UTM
as a halt decider, not using a hybrid UTM halt decider that
examines the execution trace of its input.
 

Nope, because I remember when I was in school, it was already
established that Simulating Halt Deciding did not show much
promise as there were serious limits as to what you could detect.
Linz knew that and knew that mentiones in passing that it
couldn't know enough to make the decision.

Also, since he proved it for ALL Halt deciders, he proved it for
Simulating Halt Deciders, as those are within the class of Halt
Deciders, and can't do anything that a 'generic' Halt Decider
can't do.

None-the-less int main() { H1(P,P); } does correctly report that
its input halts on the basis that H(P,P) does correctly report
that its input never halts.
 

But since H^ was built on H, it is H that needs to get the answer
right, not H1, and it doesn't

If you want to claim that they are the same machine, you need to
explain how they give different answers for the same input, which
shows they are Computations.
  
If you knew the x86 language and software engineering well enough
you would know that the following execution trace of the
simulation of P(P) matches the infinite recursion behavior pattern
and you would know that the infinite recursion behavior pattern is
correct.

Nope, since it skips over the CONDITIONAL code of H.

That code needs to be traced and shown to be unconditional.
  
THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY
THE FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT
POINTING OUT ANY ERROR
 

WRONG. I keep pointing out that you build your arguement on false
foundations.
  >
Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55          push ebp
[00000c37][002117ca][002117ce] 8bec        mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50          push eax       // push P
[00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51          push ecx       // push P
[00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
H(P,P)

[00000c36][0025c1f2][0025c1f6] 55          push ebp
[00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50          push eax       // push P
[00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51          push ecx       // push P
[00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation
Stopped

This infinite recursion detection criteria are met by the above
execution trace:
(a) P calls H twice in sequence from the same machine address.
(b) With the same parameters: (P,P) to H.
(c) With no conditional branch or indexed jump instructions in the
execution trace of P.

Only because the trace is incorrect.
  
(d) We know that there are no return instructions in H because we
know that H is in pure simulation mode.


The H can NEVER answer even as a top level machine, so THAT is
false too.

Remember there is no such thing a 'Pure Simulator Mode', something
is or it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)
 

That the entire time that the halt decider is making its halt status
decision the halt decider has no behavior what-so-ever that can have
any effect on the behavior of its simulated input seems to be beyond
your intellectual capacity to comprehend.

The ad hominem attack is a logical fallacy: attack the argument and not
the person and progress might be made.

/Flibble


It seems to be an objective fact that most people here simply do not want an honest dialogue and/or lack the intellectual capacity / prerequisite knowledge to comprehend what is being said.

This is assessed on the basis that no actual valid reasoning is applied as rebuttals to my ideas. Most of the fake rebuttals are the dishonest dodge tactic of changing the subject rather than directly addressing any key points that have been made, AKA the strawman error:

A straw man (sometimes written as strawman) is a form of argument and an informal fallacy of having the impression of refuting an argument, whereas the real subject of the argument was not addressed or refuted, but instead replaced with a false one.
https://en.wikipedia.org/wiki/Straw_man

--
Copyright 2021 Pete Olcott

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


1
rocksolid light 0.7.2
clearneti2ptor