Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Today is a good day for information-gathering. Read someone else's mail file.


computers / comp.ai.philosophy / Concise refutation of halting problem proofs V52 [ Linz Proof ]

SubjectAuthor
* Concise refutation of halting problem proofs V52 [ Linz Proof ]olcott
+* Re: Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|`* Re: Concise refutation of halting problem proofs V52 [ Ignorant orolcott
| `* Re: Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|  `* Re: Concise refutation of halting problem proofs V52 [ Ignorant orolcott
|   `- Re: Concise refutation of halting problem proofs V52 [ Ignorant orolcott
`* Re: Concise refutation of halting problem proofs V52 [ Honestolcott
 `* Re: Concise refutation of halting problem proofs V52 [ Honestolcott
  `* Re: Concise refutation of halting problem proofs V52 [ Honestolcott
   `* Re: Concise refutation of halting problem proofs V52 [ Honestolcott
    `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
     `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
      `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
       `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
        +- Re: Concise refutation of halting problem proofs V52 [ error orolcott
        +- Re: Concise refutation of halting problem proofs V52 [ THE KEYolcott
        `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
         `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
          `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
           `* Re: Concise refutation of halting problem proofs V52 [ error orolcott
            +* Re: Concise refutation of halting problem proofs V52 [ error orolcott
            |`* Re: Concise refutation of halting problem proofs V52 [ dishonesty ! ]olcott
            | `* Re: Concise refutation of halting problem proofs V52 [ ignorance? ]olcott
            |  `* Re: Concise refutation of halting problem proofs V52 [ ignorance? ]olcott
            |   `* Re: Concise refutation of halting problem proofs V59 [ key essence ]olcott
            |    +- Re: Concise refutation of halting problem proofs V59 [ key essence ]olcott
            |    +* Re: Concise refutation of halting problem proofs V59 [ key essence ]olcott
            |    |+* Re: Concise refutation of halting problem proofs V59 [ key essence ]olcott
            |    ||+- Re: Concise refutation of halting problem proofs V59 [ ignoranceolcott
            |    ||+- Re: Concise refutation of halting problem proofs V59 [ key essence ]olcott
            |    ||`* Re: Concise refutation of halting problem proofs V59 [ ignoranceolcott
            |    || `* Re: Concise refutation of halting problem proofs V59 [ self-evidentolcott
            |    ||  `* Re: Concise refutation of halting problem proofs V59 [ self-evidentolcott
            |    ||   `* Re: Concise refutation of halting problem proofs V59 [ self-evidentolcott
            |    ||    `- Re: Concise refutation of halting problem proofs V59 [ self-evidentolcott
            |    |`- Re: Concise refutation of halting problem proofs V59 [ key essence ]olcott
            |    `- Re: Concise refutation of halting problem proofs V59 [ key essence ]olcott
            +- Re: Concise refutation of halting problem proofs V52 [ error orolcott
            `* Re: Concise refutation of halting problem proofs V52 [ ignoranceolcott
             `* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
              `* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               +* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               |`* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               | `* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               |  `* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               |   `* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               |    `* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               |     +- Re: Concise refutation of halting problem proofs V52 [ pants on fireolcott
               |     +- Re: Concise refutation of halting problem proofs V52 [ pants on fireolcott
               |     `* Re: Concise refutation of halting problem proofs V52 [ pants on fireolcott
               |      `* Re: Concise refutation of halting problem proofs V52 [ pants on fireolcott
               |       `* Re: Concise refutation of halting problem proofs V52 [ pants on fireolcott
               |        `* Re: Concise refutation of halting problem proofs V52 [ ignorance orolcott
               |         `- Re: Concise refutation of halting problem proofs V52 [ ignorance orolcott
               +* Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               |`- Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott
               `- Re: Concise refutation of halting problem proofs V52 [ dodgy doubleolcott

Pages:123
Subject: Concise refutation of halting problem proofs V52 [ Linz Proof ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Sat, 22 Jan 2022 15:48 UTC
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Concise refutation of halting problem proofs V52 [ Linz Proof ]
Followup-To: comp.theory
Date: Sat, 22 Jan 2022 09:48:11 -0600
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <ssh8vu$4c0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 22 Jan 2022 15:48:14 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="dc1cf4ef75100646f2ff207bba193441";
logging-data="4480"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MNMyz96aDbSNX+MGL0Baq"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:9N+ULtp5COFGrJ7ilm0EMn10TpY=
Content-Language: en-US
View all headers
Halting problem undecidability and infinitely nested simulation (V3)

We define Linz H to base its halt status decision on the behavior of its pure simulation of N steps of its input. N is either the number of steps that it takes for its simulated input to reach its final state or the number of steps required for H to match an infinite behavior pattern proving that the simulated input would never reach its own final state. In this case H aborts the simulation of this input and transitions to H.qn.

The following simplifies the syntax for the definition of the Linz Turing machine Ĥ, it is now a single machine with a single start state. A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because it is known that the UTM simulation of a machine is computationally equivalent to the direct execution of this same machine H can always form its halt status decision on the basis of what the behavior of the UTM simulation of its inputs would be.

When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...

computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)

This shows that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach its final state conclusively proving that this simulated input never halts. This enables embedded_H to abort the simulation of its input and correctly transition to Ĥ.qn.

if embedded_H does correctly recognize an infinitely repeating behavior pattern in the behavior of its simulated input: ⟨Ĥ⟩ applied to ⟨Ĥ⟩ then embedded_H is necessarily correct to abort the simulation of its input and transition to Ĥ.qn.

Because a halt decider is a decider embedded_H is only accountable for computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn on the basis of the behavior specified by these inputs. embedded_H is not accountable for the behavior of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩ because this is not an actual input to embedded_H.




Halting problem undecidability and infinitely nested simulation (V3)

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3 --
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sat, 22 Jan 2022 16:29 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 22 Jan 2022 10:29:33 -0600
Date: Sat, 22 Jan 2022 10:29:33 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or
Dishonest ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <7cWGJ.53033$Y01.48629@fx45.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <7cWGJ.53033$Y01.48629@fx45.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <O_2dnZH5oMRzrXH8nZ2dnUU7-L3NnZ2d@giganews.com>
Lines: 118
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fPcbiFoicv+s/rEBbgmL9kR1HjGeChgka+IU8pn1VluHqSuKWT9jVFLiKcbNfr+QsBnohL2UmEsCjp2!8Wf96c2E5rO7cZ5IndFZ/cED3ySNXJernULF6IUQ3Jl6TK3CirokjhR9F4LO/oGQS/ycJRW114dZ
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: 5991
View all headers
On 1/22/2022 10:23 AM, Richard Damon wrote:

On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested simulation (V3)

Take FIFTY TWO, I think you are stuck in an apparent infinite loop.

You keep on repeating the same basic mistakes.


We define Linz H to base its halt status decision on the behavior of its pure simulation of N steps of its input. N is either the number of steps that it takes for its simulated input to reach its final state or the number of steps required for H to match an infinite behavior pattern proving that the simulated input would never reach its own final state. In this case H aborts the simulation of this input and transitions to H.qn.

Such a pattern NOT existing for the <H^> <H^> pattern, thus your H can't correctly abort and becomes non-answering and thus FAILS to be a decider.

The non-existance has been proven and you have ignored that proof, showing you have no counter for the proof.

If you want to claim such a pattern exists, you MUST provide it or accept that your logic is just plain flawed as you are claiming the existance of something that is impossible.

In effect, you are saying that if you have a halt decider for you halt decider to use, you can write a halt decider.

FAIL.


The following simplifies the syntax for the definition of the Linz Turing machine Ĥ, it is now a single machine with a single start state. A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because it is known that the UTM simulation of a machine is computationally equivalent to the direct execution of this same machine H can always form its halt status decision on the basis of what the behavior of the UTM simulation of its inputs would be.

When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...

But only if H never aborts, if H does abort, then the pattern is broken.


YOU ARE EITHER TOO IGNORANT OR DISHONEST TO ACKNOWLEDGE THE TRUTH OF THIS:

The fact that there are no finite number of steps that the simulated input to embedded_H would ever reach its final state conclusively proves that embedded_H is correct to abort its simulation of this input and transition to Ĥ.qn.


computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)

This shows that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach its final state conclusively proving that this simulated input never halts. This enables embedded_H to abort the simulation of its input and correctly transition to Ĥ.qn.

No, it doesn't, it shows that the H^ built on an H that doesn't abort will not halt, but that H doesn't answer. If H does abort, and thus can give the answer, the logic is incorrect.

FAIL.


if embedded_H does correctly recognize an infinitely repeating behavior pattern in the behavior of its simulated input: ⟨Ĥ⟩ applied to ⟨Ĥ⟩ then embedded_H is necessarily correct to abort the simulation of its input and transition to Ĥ.qn.

Which it can not do, as shown to be impossible.


Because a halt decider is a decider embedded_H is only accountable for computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn on the basis of the behavior specified by these inputs. embedded_H is not accountable for the behavior of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩ because this is not an actual input to embedded_H.


As mentioned before, for the input <H^> <H^> when H^ is based on the H that claims to correctly go to H.Qn, then UTM(<H^>,<H^>) is shown to also go to H^.Qn and Halt, so the input that H IS accountable for doesn't match the behavior that H assigns to it.

FAIL.




Halting problem undecidability and infinitely nested simulation (V3)

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

You are still using Fairy Dust powered Unicorns as the basis of your proof.

FAIL.


--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sat, 22 Jan 2022 17:19 UTC
References: 1 2 3 4 5 6
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 22 Jan 2022 11:19:23 -0600
Date: Sat, 22 Jan 2022 11:19:22 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or
Dishonest ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <7cWGJ.53033$Y01.48629@fx45.iad>
<O_2dnZH5oMRzrXH8nZ2dnUU7-L3NnZ2d@giganews.com>
<YqWGJ.17235$OU.1179@fx22.iad>
<VuWdnWDDRYaYqHH8nZ2dnUU7-UXNnZ2d@giganews.com> <7XWGJ.2501$2V.1175@fx07.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <7XWGJ.2501$2V.1175@fx07.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <MJudnaGsk80GoXH8nZ2dnUU7-cPNnZ2d@giganews.com>
Lines: 95
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Or4OCcfXX7PggWWR7iHGj1/vdJ0P6ZU75BtriIZ+DDMdQUiGg3umECr26EQtlkwDtnZWxJ/bKKiGTzb!mv/sDJi0Ayay3DPzrF5yDyY16FbNIaAWTf+9kCOq6hC1ghf8rdPmIfAEabQklVwLSH12Vpf4MYLO
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: 5491
View all headers
On 1/22/2022 11:13 AM, Richard Damon wrote:
On 1/22/22 11:47 AM, olcott wrote:
On 1/22/2022 10:39 AM, Richard Damon wrote:
On 1/22/22 11:29 AM, olcott wrote:
On 1/22/2022 10:23 AM, Richard Damon wrote:

On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested simulation (V3)

Take FIFTY TWO, I think you are stuck in an apparent infinite loop.

You keep on repeating the same basic mistakes.


We define Linz H to base its halt status decision on the behavior of its pure simulation of N steps of its input. N is either the number of steps that it takes for its simulated input to reach its final state or the number of steps required for H to match an infinite behavior pattern proving that the simulated input would never reach its own final state. In this case H aborts the simulation of this input and transitions to H.qn.

Such a pattern NOT existing for the <H^> <H^> pattern, thus your H can't correctly abort and becomes non-answering and thus FAILS to be a decider.

The non-existance has been proven and you have ignored that proof, showing you have no counter for the proof.

If you want to claim such a pattern exists, you MUST provide it or accept that your logic is just plain flawed as you are claiming the existance of something that is impossible.

In effect, you are saying that if you have a halt decider for you halt decider to use, you can write a halt decider.

FAIL.


The following simplifies the syntax for the definition of the Linz Turing machine Ĥ, it is now a single machine with a single start state. A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because it is known that the UTM simulation of a machine is computationally equivalent to the direct execution of this same machine H can always form its halt status decision on the basis of what the behavior of the UTM simulation of its inputs would be.

When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...

But only if H never aborts, if H does abort, then the pattern is broken.


YOU ARE EITHER TOO IGNORANT OR DISHONEST TO ACKNOWLEDGE THE TRUTH OF THIS:

The fact that there are no finite number of steps that the simulated input to embedded_H would ever reach its final state conclusively proves that embedded_H is correct to abort its simulation of this input and transition to Ĥ.qn.


The problem is that any H that aborts after a finite number of steps, gives the wrong answer because it only looked to see if the input doesn't halt at some specific finite number.

OK IGNORANT it is. When there exists no finite (or infinite) number of steps such that the simulated input to embedded_H reaches its final state then we know that this simulated input does not halt.

And the only case when that happens is when H does not abort its simulation,

WRONG !!!  That happens in every possible case. The simulated input to embedded_H cannot possibly ever reach its final state NO MATTER WHAT !!!



Halting problem undecidability and infinitely nested simulation (V3)

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3 --
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sat, 22 Jan 2022 17:53 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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 22 Jan 2022 11:53:13 -0600
Date: Sat, 22 Jan 2022 11:53:12 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or
Dishonest ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <7cWGJ.53033$Y01.48629@fx45.iad>
<O_2dnZH5oMRzrXH8nZ2dnUU7-L3NnZ2d@giganews.com>
<YqWGJ.17235$OU.1179@fx22.iad>
<VuWdnWDDRYaYqHH8nZ2dnUU7-UXNnZ2d@giganews.com> <7XWGJ.2501$2V.1175@fx07.iad>
<MJudnaGsk80GoXH8nZ2dnUU7-cPNnZ2d@giganews.com>
<8eXGJ.53034$Y01.12453@fx45.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <8eXGJ.53034$Y01.12453@fx45.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <rY2dnfFFpOQU2XH8nZ2dnUU7-KPNnZ2d@giganews.com>
Lines: 126
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-By8cKaAQZqr9U19RVWYlzzaX2tA9jwKzYRDBagzWxImJ76HOVqqpo1KblCse31NJOX+Ui+bvK92+fCU!jvH7jtcHivYPOs8YQsNdx1o4Dcu9UAt0alwzR/TQexsW8wIXhnB+u+RbayFz9mbnJ/hEGrufpLys
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: 6841
View all headers
On 1/22/2022 11:33 AM, Richard Damon wrote:
On 1/22/22 12:19 PM, olcott wrote:
On 1/22/2022 11:13 AM, Richard Damon wrote:
On 1/22/22 11:47 AM, olcott wrote:
On 1/22/2022 10:39 AM, Richard Damon wrote:
On 1/22/22 11:29 AM, olcott wrote:
On 1/22/2022 10:23 AM, Richard Damon wrote:

On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested simulation (V3)

Take FIFTY TWO, I think you are stuck in an apparent infinite loop.

You keep on repeating the same basic mistakes.


We define Linz H to base its halt status decision on the behavior of its pure simulation of N steps of its input. N is either the number of steps that it takes for its simulated input to reach its final state or the number of steps required for H to match an infinite behavior pattern proving that the simulated input would never reach its own final state. In this case H aborts the simulation of this input and transitions to H.qn.

Such a pattern NOT existing for the <H^> <H^> pattern, thus your H can't correctly abort and becomes non-answering and thus FAILS to be a decider.

The non-existance has been proven and you have ignored that proof, showing you have no counter for the proof.

If you want to claim such a pattern exists, you MUST provide it or accept that your logic is just plain flawed as you are claiming the existance of something that is impossible.

In effect, you are saying that if you have a halt decider for you halt decider to use, you can write a halt decider.

FAIL.


The following simplifies the syntax for the definition of the Linz Turing machine Ĥ, it is now a single machine with a single start state. A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because it is known that the UTM simulation of a machine is computationally equivalent to the direct execution of this same machine H can always form its halt status decision on the basis of what the behavior of the UTM simulation of its inputs would be.

When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...

But only if H never aborts, if H does abort, then the pattern is broken.


YOU ARE EITHER TOO IGNORANT OR DISHONEST TO ACKNOWLEDGE THE TRUTH OF THIS:

The fact that there are no finite number of steps that the simulated input to embedded_H would ever reach its final state conclusively proves that embedded_H is correct to abort its simulation of this input and transition to Ĥ.qn.


The problem is that any H that aborts after a finite number of steps, gives the wrong answer because it only looked to see if the input doesn't halt at some specific finite number.

OK IGNORANT it is. When there exists no finite (or infinite) number of steps such that the simulated input to embedded_H reaches its final state then we know that this simulated input does not halt.

And the only case when that happens is when H does not abort its simulation,

WRONG !!!  That happens in every possible case. The simulated input to embedded_H cannot possibly ever reach its final state NO MATTER WHAT !!!

But if H/embedded_H aborts its simulation, it doesn't matter if IT sees it or not, as it isn't then a UTM any longer.


It remains true (invariant) that the simulated input to embedded_H cannot possibly ever reach its final state no matter what embedded_H does, thus conclusively proving that this input never halts.

If H aborts its simulation and goes to H.Qn then H^ applied to <H^> and the UTM Simulation of <H^> <H^> will go to H^.Qn and Halt.


Because a halt decider is a decider embedded_H is only accountable for computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn on the basis of the behavior specified by these inputs. embedded_H is not accountable for the behavior of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩ because this is not an actual input to embedded_H.


THAT is what matters, and shows that H was wromg.

You keep on believing a false source of 'truth'.

FAIL.



Halting problem undecidability and infinitely nested simulation (V3)

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3



--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sat, 22 Jan 2022 21:25 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
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, 22 Jan 2022 15:25:57 -0600
Date: Sat, 22 Jan 2022 15:25:56 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or
Dishonest ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <7cWGJ.53033$Y01.48629@fx45.iad>
<O_2dnZH5oMRzrXH8nZ2dnUU7-L3NnZ2d@giganews.com>
<YqWGJ.17235$OU.1179@fx22.iad>
<VuWdnWDDRYaYqHH8nZ2dnUU7-UXNnZ2d@giganews.com> <7XWGJ.2501$2V.1175@fx07.iad>
<MJudnaGsk80GoXH8nZ2dnUU7-cPNnZ2d@giganews.com>
<8eXGJ.53034$Y01.12453@fx45.iad>
<rY2dnfFFpOQU2XH8nZ2dnUU7-KPNnZ2d@giganews.com>
<pWXGJ.18523$VK4.16193@fx08.iad>
<i4idnXTXWeLE0XH8nZ2dnUU7-WfNnZ2d@giganews.com> <AeYGJ.3517$2W.1872@fx36.iad>
<a6-dnU-EiYU0z3H8nZ2dnUU7-SHNnZ2d@giganews.com>
<7NZGJ.253260$VS2.134222@fx44.iad>
<_c-dnS9uAqrU8XH8nZ2dnUU7-YvNnZ2d@giganews.com> <8y_GJ.7767$tW.1827@fx39.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <8y_GJ.7767$tW.1827@fx39.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <JOqdnYm4c7z463H8nZ2dnUU7-anNnZ2d@giganews.com>
Lines: 192
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jHMWingvAD6mNbhopQ1kcYVKtOlHW5Wh0/5fK47DvxJexDR3tW5fpM9PGRPOTrayjAGnUMnQ6bb1jae!R2BNln26NeC6odENE4IIMM6uVBC5fazT5T3i7WMPWBB3+EjcTJC1XfKyITLo/BZhS93nWFSGv0B1
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: 10463
View all headers
On 1/22/2022 3:20 PM, Richard Damon wrote:

On 1/22/22 3:42 PM, olcott wrote:
On 1/22/2022 2:27 PM, Richard Damon wrote:
On 1/22/22 1:53 PM, olcott wrote:
On 1/22/2022 12:42 PM, Richard Damon wrote:
On 1/22/22 1:26 PM, olcott wrote:
On 1/22/2022 12:21 PM, Richard Damon wrote:
On 1/22/22 12:53 PM, olcott wrote:
On 1/22/2022 11:33 AM, Richard Damon wrote:
On 1/22/22 12:19 PM, olcott wrote:
On 1/22/2022 11:13 AM, Richard Damon wrote:
On 1/22/22 11:47 AM, olcott wrote:
On 1/22/2022 10:39 AM, Richard Damon wrote:
On 1/22/22 11:29 AM, olcott wrote:
On 1/22/2022 10:23 AM, Richard Damon wrote:

On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested simulation (V3)

Take FIFTY TWO, I think you are stuck in an apparent infinite loop.

You keep on repeating the same basic mistakes.


We define Linz H to base its halt status decision on the behavior of its pure simulation of N steps of its input. N is either the number of steps that it takes for its simulated input to reach its final state or the number of steps required for H to match an infinite behavior pattern proving that the simulated input would never reach its own final state. In this case H aborts the simulation of this input and transitions to H.qn.

Such a pattern NOT existing for the <H^> <H^> pattern, thus your H can't correctly abort and becomes non-answering and thus FAILS to be a decider.

The non-existance has been proven and you have ignored that proof, showing you have no counter for the proof.

If you want to claim such a pattern exists, you MUST provide it or accept that your logic is just plain flawed as you are claiming the existance of something that is impossible.

In effect, you are saying that if you have a halt decider for you halt decider to use, you can write a halt decider.

FAIL.


The following simplifies the syntax for the definition of the Linz Turing machine Ĥ, it is now a single machine with a single start state. A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because it is known that the UTM simulation of a machine is computationally equivalent to the direct execution of this same machine H can always form its halt status decision on the basis of what the behavior of the UTM simulation of its inputs would be.

When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...

But only if H never aborts, if H does abort, then the pattern is broken.


YOU ARE EITHER TOO IGNORANT OR DISHONEST TO ACKNOWLEDGE THE TRUTH OF THIS:

The fact that there are no finite number of steps that the simulated input to embedded_H would ever reach its final state conclusively proves that embedded_H is correct to abort its simulation of this input and transition to Ĥ.qn.


The problem is that any H that aborts after a finite number of steps, gives the wrong answer because it only looked to see if the input doesn't halt at some specific finite number.

OK IGNORANT it is. When there exists no finite (or infinite) number of steps such that the simulated input to embedded_H reaches its final state then we know that this simulated input does not halt.

And the only case when that happens is when H does not abort its simulation,

WRONG !!!  That happens in every possible case. The simulated input to embedded_H cannot possibly ever reach its final state NO MATTER WHAT !!!

But if H/embedded_H aborts its simulation, it doesn't matter if IT sees it or not, as it isn't then a UTM any longer.


It remains true (invariant) that the simulated input to embedded_H cannot possibly ever reach its final state no matter what embedded_H does, thus conclusively proving that this input never halts.

If H aborts its simulation and goes to H.Qn then H^ applied to <H^> and the UTM Simulation of <H^> <H^> will go to H^.Qn and Halt.


Because a halt decider is a decider embedded_H is only accountable for computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn on the basis of the behavior specified by these inputs. embedded_H is not accountable for the behavior of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩ because this is not an actual input to embedded_H.


Right, and if H(<H^>,<H^>) -> H.Qn then the proper simulation by the computation UTM(<H^>,<H^>) will show that H^ also go to H^.Qn and Halt.

THAT is the defined behavior of the actual input to H.


You can define that a cat is a dog, yet the actual simulated input to embedded_H cannot possibly reach its final state NO MATTER WHAT.

But it does. embeddd_H can't simuate to that point,

If the simulated input cannot possibly every reach its final state no matter what embedded_H does then this simulated input is correctly determined to meet the Linz definition of never halting.


Except that the simulated input DOES reach its final state if H/embeded_H goes to H.Qn.

Before embedded_H transitions to Ĥ.qn it has already aborted its simulated input making it utterly impossible for any aspect of this simulated input to do anything at all.

Then you are just talking POOP and not halting.


It is simply beyond your intellectual capacity:

This is true for infinite loops, infinite recursion, infinitely nested simulation and all other non halting inputs:

When-so-ever any simulated input to any simulating halt decider would never reach the final state of this simulated input in any finite number of steps it is always correct for the simulating halt decider to abort its simulation and transition to its reject state.

Remember, the definition of Halting is based on what a UTM does with the exact same input, and the UTM WON'T (in fact CAN'T) abort the simulation at that point but continues on, and that H^ will continue on to use a copy of H that will do that exact same simulation and abort its simulation (but not the running of its 'caller'), and transition to H.Qn which means H^ goes to H^.Qn and Halts.

FAIL.




It is just like unplugging your computer, zero more steps are executed.


Except Halting isn't based on what a particular copy does, but what any copy would do if allowed to run.

FAIL

Seems to me to be just more POOP.

CLEANUP ON AISLE 52, someone has left POOP all over the floor.


--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or Dishonest ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sun, 23 Jan 2022 19:19 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
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: Sun, 23 Jan 2022 13:19:24 -0600
Date: Sun, 23 Jan 2022 13:19:00 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Subject: Re: Concise refutation of halting problem proofs V52 [ Ignorant or
Dishonest ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <7cWGJ.53033$Y01.48629@fx45.iad>
<O_2dnZH5oMRzrXH8nZ2dnUU7-L3NnZ2d@giganews.com>
<YqWGJ.17235$OU.1179@fx22.iad>
<VuWdnWDDRYaYqHH8nZ2dnUU7-UXNnZ2d@giganews.com> <7XWGJ.2501$2V.1175@fx07.iad>
<MJudnaGsk80GoXH8nZ2dnUU7-cPNnZ2d@giganews.com>
<8eXGJ.53034$Y01.12453@fx45.iad>
<rY2dnfFFpOQU2XH8nZ2dnUU7-KPNnZ2d@giganews.com>
<pWXGJ.18523$VK4.16193@fx08.iad>
<i4idnXTXWeLE0XH8nZ2dnUU7-WfNnZ2d@giganews.com> <AeYGJ.3517$2W.1872@fx36.iad>
<a6-dnU-EiYU0z3H8nZ2dnUU7-SHNnZ2d@giganews.com>
<7NZGJ.253260$VS2.134222@fx44.iad>
<_c-dnS9uAqrU8XH8nZ2dnUU7-YvNnZ2d@giganews.com> <8y_GJ.7767$tW.1827@fx39.iad>
<JOqdnYm4c7z463H8nZ2dnUU7-anNnZ2d@giganews.com>
<UN_GJ.275715$1d1.2334@fx99.iad>
<wYOdnZZx16xyR3H8nZ2dnUU7-afNnZ2d@giganews.com> <a25HJ.3979$CW.1138@fx17.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <a25HJ.3979$CW.1138@fx17.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Z_ydnS3z8MehN3D8nZ2dnUU7-e3NnZ2d@giganews.com>
Lines: 113
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-kFPWfNTK0zlxrY39gfETOrmwydvBTAngQ0RZkJNC8sI0joRB7PL1GmFNfYKYrp8Ao9+rxU2c+sXyRXA!SZlcA3acuUOw3Bd2f7DcywBGz5sGPVCgkGgA1k6z++K65yWvB90J3GgwwVGsmnMprZG7sPw1ieVC
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: 5853
View all headers
On 1/22/2022 10:43 PM, Richard Damon wrote:
On 1/22/22 11:34 PM, olcott wrote:
On 1/22/2022 3:36 PM, Richard Damon wrote:
On 1/22/22 4:25 PM, olcott wrote:
On 1/22/2022 3:20 PM, Richard Damon wrote:


This is true for infinite loops, infinite recursion, infinitely nested simulation and all other non halting inputs:

When-so-ever any simulated input to any simulating halt decider would never reach the final state of this simulated input in any finite number of steps it is always correct for the simulating halt decider to abort its simulation and transition to its reject state.


Can you PROVE that statement, or is this just one of your false 'self evident truth'.

Anyone that knows that x86 language can tell that its easy to match the infinite loop pattern:

_Infinite_Loop()
[000015fa](01)  55              push ebp
[000015fb](02)  8bec            mov ebp,esp
[000015fd](02)  ebfe            jmp 000015fd
[000015ff](01)  5d              pop ebp
[00001600](01)  c3              ret
Size in bytes:(0007) [00001600]

---[000015fa][002126f0][002126f4] 55              push ebp
---[000015fb][002126f0][002126f4] 8bec            mov ebp,esp
---[000015fd][002126f0][002126f4] ebfe            jmp 000015fd
---[000015fd][002126f0][002126f4] ebfe            jmp 000015fd

Showing that you can do one case does not prove that the same method works on all, particularly harder methods.

That is just you serving Red Herring.

And that pattern does NOT show up in the simulation by H of H^

Which makes it MORE lies by Red Herring.

FAIL.

Total lack of proof.

Does the proof include the posibility that the input includes a copy of the decider?


It is always the case that a simulating halt decider can correctly base its halt status decision on the behavior pure simulation of its input.

LIE.

Proven incorrect.

If H -> H.Qn then H^ -> H^.Qn and Halts and for H^ <H^> proves H wrong.


We know that this must be true because we know that the pure UTM simulation of an Turing Machine description is defined to have equivalent behavior to that of the direct execution of the same machine


Right, but that does't prove what you sy.

You are just LYING out of your POOP.


The problem is that IF the simulating halt decider does abort its input based on some condition, then it is no longer a source of truth for the halting status of that input.


It is not answering the question: Does the input stop running?


YOU need to answer, which H are you using?

If H doesn't abort, then H^ is non-halting, but H will never answer.

If H does abort and go to H.Qn, then the pure simulation of the input WILL halt at H^.Qn, so H was wrong.

FAIL.


It is answering the question:
Would the pure simulation of the input ever stop running?

Right, and if H -> H.Qn it will.

FAIL.

YOU JUST AREN'T BRIGHT ENOUGH TO GET THIS. IT CAN BE VERIFIED AS COMPLETELY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS.

It is the case that if embedded_H recognizes an infinitely repeating pattern in the simulation of its input such that this correctly simulated input cannot possibly reach its final state then this is complete prove that this simulated input never halts.


--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ Honest Dialogue Begins ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Date: Tue, 25 Jan 2022 03:45 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!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: Mon, 24 Jan 2022 21:45:25 -0600
Date: Mon, 24 Jan 2022 21:45:23 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Subject: Re: Concise refutation of halting problem proofs V52 [ Honest
Dialogue Begins ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <87mHJ.22633$dG7.7407@fx47.iad>
<GNqdnSg7oc-Eb3D8nZ2dnUU7-XHNnZ2d@giganews.com>
<wSmHJ.53088$Y01.31344@fx45.iad>
<KJ-dnWCshr7gYXD8nZ2dnUU7-TXNnZ2d@giganews.com>
<aGnHJ.254127$VS2.43875@fx44.iad>
<u9Kdna64maOflHP8nZ2dnUU7-U_NnZ2d@giganews.com> <sYnHJ.6193$9O.3928@fx12.iad>
<ofSdnRQ7qYe8knP8nZ2dnUU7-XHNnZ2d@giganews.com>
<NmoHJ.22635$dG7.20402@fx47.iad>
<mZSdnWvt5_EXhXP8nZ2dnUU7-Q_NnZ2d@giganews.com>
<0_oHJ.254128$VS2.188172@fx44.iad>
<qvWdncTddvgAgnP8nZ2dnUU7-QHNnZ2d@giganews.com> <CspHJ.6567$uP.5786@fx16.iad>
<ld2dnW-kzJX_tXP8nZ2dnUU7-W3NnZ2d@giganews.com> <z9qHJ.3181$rU.2919@fx34.iad>
<i7qdnYQH-OUoInP8nZ2dnUU7-b3NnZ2d@giganews.com>
<qWGHJ.11522$2W.7884@fx36.iad>
<yuWdnWDd8speonL8nZ2dnUU7-cPNnZ2d@giganews.com>
<KPHHJ.311933$qz4.109480@fx97.iad>
<OMGdndHAM9CDznL8nZ2dnUU7-YfNnZ2d@giganews.com>
<1UIHJ.282256$1d1.28846@fx99.iad>
<5p-dnZEaj-b4wXL8nZ2dnUU7-fHNnZ2d@giganews.com>
<3dJHJ.17533$f04.698@fx23.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <3dJHJ.17533$f04.698@fx23.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <eICdne89nPPI73L8nZ2dnUU7-V3NnZ2d@giganews.com>
Lines: 507
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9nhIeSxdV8ZMURuc/YOG/VrWDTZQb+/TCh0AUOtht6zzYt951+0VWic1UxEn0aoYf4rmzmK6FI4Z7pT!nhhI1EKzf+E3an78r/fXCctFb87b5+sL7is1gMEVVz5BfvdvF98irupBBT4gBLD9BHimqk+xbRED
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: 28129
View all headers
On 1/24/2022 8:26 PM, Richard Damon wrote:
On 1/24/22 9:11 PM, olcott wrote:
On 1/24/2022 8:03 PM, Richard Damon wrote:

On 1/24/22 8:32 PM, olcott wrote:
On 1/24/2022 6:50 PM, Richard Damon wrote:
On 1/24/22 7:09 PM, olcott wrote:
On 1/24/2022 5:49 PM, Richard Damon wrote:
On 1/24/22 10:03 AM, olcott wrote:
On 1/23/2022 10:45 PM, Richard Damon wrote:
On 1/23/22 11:17 PM, olcott wrote:
On 1/23/2022 9:57 PM, Richard Damon wrote:

On 1/23/22 10:40 PM, olcott wrote:
On 1/23/2022 9:24 PM, Richard Damon wrote:
On 1/23/22 10:10 PM, olcott wrote:
On 1/23/2022 8:42 PM, Richard Damon wrote:
On 1/23/22 9:29 PM, olcott wrote:
On 1/23/2022 8:14 PM, Richard Damon wrote:

On 1/23/22 9:03 PM, olcott wrote:
On 1/23/2022 7:55 PM, Richard Damon wrote:
On 1/23/22 8:10 PM, olcott wrote:
On 1/23/2022 7:00 PM, Richard Damon wrote:
On 1/23/22 7:25 PM, olcott wrote:
On 1/23/2022 6:09 PM, Richard Damon wrote:
On 1/23/22 7:00 PM, olcott wrote:
On 1/23/2022 5:50 PM, Richard Damon wrote:
On 1/23/22 6:16 PM, olcott wrote:
On 1/23/2022 5:06 PM, Richard Damon wrote:
On 1/23/22 5:47 PM, olcott wrote:
On 1/23/2022 4:40 PM, Richard Damon wrote:
On 1/23/22 5:18 PM, olcott wrote:
On 1/23/2022 4:01 PM, Richard Damon wrote:
On 1/23/22 4:40 PM, olcott wrote:
On 1/23/2022 2:25 PM, Richard Damon wrote:

On 1/23/22 2:19 PM, olcott wrote:
On 1/22/2022 10:43 PM, Richard Damon wrote:
On 1/22/22 11:34 PM, olcott wrote:
On 1/22/2022 3:36 PM, Richard Damon wrote:
On 1/22/22 4:25 PM, olcott wrote:
On 1/22/2022 3:20 PM, Richard Damon wrote:


This is true for infinite loops, infinite recursion, infinitely nested simulation and all other non halting inputs:

When-so-ever any simulated input to any simulating halt decider would never reach the final state of this simulated input in any finite number of steps it is always correct for the simulating halt decider to abort its simulation and transition to its reject state.


Can you PROVE that statement, or is this just one of your false 'self evident truth'.

Anyone that knows that x86 language can tell that its easy to match the infinite loop pattern:

_Infinite_Loop()
[000015fa](01)  55              push ebp
[000015fb](02)  8bec            mov ebp,esp
[000015fd](02)  ebfe            jmp 000015fd
[000015ff](01)  5d              pop ebp
[00001600](01)  c3              ret
Size in bytes:(0007) [00001600]

---[000015fa][002126f0][002126f4] 55 push ebp
---[000015fb][002126f0][002126f4] 8bec mov ebp,esp
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd

Showing that you can do one case does not prove that the same method works on all, particularly harder methods.

That is just you serving Red Herring.

And that pattern does NOT show up in the simulation by H of H^

Which makes it MORE lies by Red Herring.

FAIL.

Total lack of proof.

Does the proof include the posibility that the input includes a copy of the decider?


It is always the case that a simulating halt decider can correctly base its halt status decision on the behavior pure simulation of its input.

LIE.

Proven incorrect.

If H -> H.Qn then H^ -> H^.Qn and Halts and for H^ <H^> proves H wrong.


We know that this must be true because we know that the pure UTM simulation of an Turing Machine description is defined to have equivalent behavior to that of the direct execution of the same machine


Right, but that does't prove what you sy.

You are just LYING out of your POOP.


The problem is that IF the simulating halt decider does abort its input based on some condition, then it is no longer a source of truth for the halting status of that input.


It is not answering the question: Does the input stop running?


YOU need to answer, which H are you using?

If H doesn't abort, then H^ is non-halting, but H will never answer.

If H does abort and go to H.Qn, then the pure simulation of the input WILL halt at H^.Qn, so H was wrong.

FAIL.


It is answering the question:
Would the pure simulation of the input ever stop running?

Right, and if H -> H.Qn it will.

FAIL.

YOU JUST AREN'T BRIGHT ENOUGH TO GET THIS. IT CAN BE VERIFIED AS COMPLETELY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS.

It is the case that if embedded_H recognizes an infinitely repeating pattern in the simulation of its input such that this correctly simulated input cannot possibly reach its final state then this is complete prove that this simulated input never halts.

If it COULD CORRECTLY recognize an infinitely repeating pattern in its
simulation that can not possibly reach its final state (when simulated by a UTM, not just H) then, YES, H can go to H.Qn.

The problem is that due to 'pathological self-reference' in H^, ANY pattern that H sees in its simulation of <H^> <H^> that it transitions to H.Qn, will BY DEFINITION, become a halting pattern.


So a correctly simulated INPUT that cannot possibly reach its final state reaches its final state anyway. YOU ARE DUMBER THAN A BOX OF ROCKS !!!



That's not what I said, I said there is no pattern that H use to detect that it won't halt, as any pattern that H uses to decide to go to H.Qn will be WRONG for H^ as if H goes to H.Qn, then H^ also goes to H^.Qn and Halts.


When the correctly simulated INPUT to embedded_H cannot possibly reach its final state it is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



Right,  but you have only proved that H^ is non-halting for the case where H doesn't abort its simulation.


Because you are dumber than a box of rocks (or perhaps you are a bot?)
You did not notice that I never mentioned the word: "halting".

For a human being you are much dumber than a box of rocks.

For a bot you did quite well (you nearly passed the Turing test) it took me this long to realize that you are not a human being.


But reaching final state is the same as Halting.

You have only prove that the pure simulation of the input to H never reaches a final state for case when H doesn't abort its simulation.

You deliberate weasel words do not apply to what I said:

(1) Premise: When the correctly simulated INPUT to embedded_H cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



And the correct simulation of the input to H is determined by the UTM, not H.


(2) is a logical consequence of (1).
It is logically incorrect to argue with a deductive logical premise.


But 1 is only true if H doesn't go to H.Qn, so H can't correctly go to H.Qn.


You are quite the deceiver making sure to always change the subject rather than directly address the point at hand.

And you seem quite dense. I did NOT change the subject, I pointed out an error in your statement. You seem to be unable to comprehend that.


(2) logically follows from (1) is true.

But 1 ISN'T True if H <H^> <H^> -> H.Qn, as the correctly simulate input

When testing whether or not one assertion logically follows from another the premises are always "given" to be true even if they are false.

Don't know what sort of logic you are claiming.

And arguemnt with a false premise is unsound.


We are not yet looking at soundness we are looking at validity.
It is true that (2) logically follows from (1).
We can't move on from this one point until we have mutual agreement.


Very strange then, why are you arguing about that which was accepted unless you disagree to the conditions that they were accepted under?

It has long been accepted that the under the hypothetical condition where H can actually determine that the UTM will run forever, it is correct (and in fact needed to be correct) for H to go to H.Qn and say non-halting.


OKAY so then you agree with this?

(1) Premise: When the correctly simulated INPUT to embedded_H
cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to
report that its correctly simulated INPUT cannot possibly
reach its final state.


Under the definition that 'correctly simulated input' is as determined by a UTM, not H (if it aborts its simulation).


It is only stipulated to be correct other details are currently unspecified.

That isn't a 'stipulation', that is a DEFINITION.

This is obviously your attempt at being a weasel.

The DEFINITION of correct simulation is the results of a UTM simulating the input.

Any deviaiton in this means you are just eating your POOP.


It also does not presume that H CAN determine that this condition exists, so it would be correct, but H might not be able to decide to do so. So it may be correct for it to do so, but it might not actually be able to do it.

There is also the case you tend to ignore that you start with an H that is defined to NOT abort, but you try to use (2) to claim that it now can abort, the H is (2) must be the same H that the H^ in (1) was built form

All of these restrictions are actually in the actual meaning of the words you are using, from the context of the problem, but I state them because knowing you, you are going to try to break that restrictions.


This seems to be the very first time that you actually paid close attention, good jo

Click here to read the complete article
Subject: Re: Concise refutation of halting problem proofs V52 [ Honest Dialogue Begins ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Date: Tue, 25 Jan 2022 14:44 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 25
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 25 Jan 2022 08:44:10 -0600
Date: Tue, 25 Jan 2022 08:44:09 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ Honest
Dialogue Begins ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me>
<qvWdncTddvgAgnP8nZ2dnUU7-QHNnZ2d@giganews.com> <CspHJ.6567$uP.5786@fx16.iad>
<ld2dnW-kzJX_tXP8nZ2dnUU7-W3NnZ2d@giganews.com> <z9qHJ.3181$rU.2919@fx34.iad>
<i7qdnYQH-OUoInP8nZ2dnUU7-b3NnZ2d@giganews.com>
<qWGHJ.11522$2W.7884@fx36.iad>
<yuWdnWDd8speonL8nZ2dnUU7-cPNnZ2d@giganews.com>
<KPHHJ.311933$qz4.109480@fx97.iad>
<OMGdndHAM9CDznL8nZ2dnUU7-YfNnZ2d@giganews.com>
<1UIHJ.282256$1d1.28846@fx99.iad>
<5p-dnZEaj-b4wXL8nZ2dnUU7-fHNnZ2d@giganews.com>
<3dJHJ.17533$f04.698@fx23.iad>
<eICdne89nPPI73L8nZ2dnUU7-V3NnZ2d@giganews.com>
<fsKHJ.15868$yS2.11625@fx20.iad> <ssnshc$jfl$1@dont-email.me>
<7QKHJ.3189$rU.3101@fx34.iad> <5aOdnY1a4_Xt53L8nZ2dnUU7-SvNnZ2d@giganews.com>
<EYKHJ.8824$2V.6890@fx07.iad> <_u-dnQzrFvT54XL8nZ2dnUU7-XednZ2d@giganews.com>
<DoLHJ.5615$QO.1124@fx29.iad> <dJ6dnbZdb_R0GXL8nZ2dnUU7-W-dnZ2d@giganews.com>
<oHLHJ.138400$Gco3.122595@fx01.iad>
<2sWdndujvZPKF3L8nZ2dnUU7-V_NnZ2d@giganews.com> <7zRHJ.3234$rU.2663@fx34.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <7zRHJ.3234$rU.2663@fx34.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <qOWdnYg47f8nkW38nZ2dnUU7-XvNnZ2d@giganews.com>
Lines: 679
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1RuiVfzdSQNirHwjuwoZSJem9krQ0Oi9htSOTpmJxQwY2CjBGBHslnEHEBeLyBPmJ26zkU3+c2tk2Ag!8DH3Ddp6y5/B+QT0SC3LFQkRIR4aBSy45zhr3exY+cxgXqxwXi87OGPwrqLUxbVYwTAyg5aTxGQF
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: 41176
X-Received-Bytes: 41358
View all headers
On 1/25/2022 5:55 AM, Richard Damon wrote:
On 1/25/22 12:27 AM, olcott wrote:
On 1/24/2022 11:15 PM, Richard Damon wrote:

On 1/25/22 12:04 AM, olcott wrote:
On 1/24/2022 10:54 PM, Richard Damon wrote:

On 1/24/22 11:28 PM, olcott wrote:
On 1/24/2022 10:25 PM, Richard Damon wrote:
On 1/24/22 11:19 PM, olcott wrote:
On 1/24/2022 10:16 PM, Richard Damon wrote:
On 1/24/22 10:58 PM, olcott wrote:
On 1/24/2022 9:50 PM, Richard Damon wrote:
On 1/24/22 10:45 PM, olcott wrote:
On 1/24/2022 8:26 PM, Richard Damon wrote:
On 1/24/22 9:11 PM, olcott wrote:
On 1/24/2022 8:03 PM, Richard Damon wrote:

On 1/24/22 8:32 PM, olcott wrote:
On 1/24/2022 6:50 PM, Richard Damon wrote:
On 1/24/22 7:09 PM, olcott wrote:
On 1/24/2022 5:49 PM, Richard Damon wrote:
On 1/24/22 10:03 AM, olcott wrote:
On 1/23/2022 10:45 PM, Richard Damon wrote:
On 1/23/22 11:17 PM, olcott wrote:
On 1/23/2022 9:57 PM, Richard Damon wrote:

On 1/23/22 10:40 PM, olcott wrote:
On 1/23/2022 9:24 PM, Richard Damon wrote:
On 1/23/22 10:10 PM, olcott wrote:
On 1/23/2022 8:42 PM, Richard Damon wrote:
On 1/23/22 9:29 PM, olcott wrote:
On 1/23/2022 8:14 PM, Richard Damon wrote:

On 1/23/22 9:03 PM, olcott wrote:
On 1/23/2022 7:55 PM, Richard Damon wrote:
On 1/23/22 8:10 PM, olcott wrote:
On 1/23/2022 7:00 PM, Richard Damon wrote:
On 1/23/22 7:25 PM, olcott wrote:
On 1/23/2022 6:09 PM, Richard Damon wrote:
On 1/23/22 7:00 PM, olcott wrote:
On 1/23/2022 5:50 PM, Richard Damon wrote:
On 1/23/22 6:16 PM, olcott wrote:
On 1/23/2022 5:06 PM, Richard Damon wrote:
On 1/23/22 5:47 PM, olcott wrote:
On 1/23/2022 4:40 PM, Richard Damon wrote:
On 1/23/22 5:18 PM, olcott wrote:
On 1/23/2022 4:01 PM, Richard Damon wrote:
On 1/23/22 4:40 PM, olcott wrote:
On 1/23/2022 2:25 PM, Richard Damon wrote:

On 1/23/22 2:19 PM, olcott wrote:
On 1/22/2022 10:43 PM, Richard Damon wrote:
On 1/22/22 11:34 PM, olcott wrote:
On 1/22/2022 3:36 PM, Richard Damon wrote:
On 1/22/22 4:25 PM, olcott wrote:
On 1/22/2022 3:20 PM, Richard Damon wrote:


This is true for infinite loops, infinite recursion, infinitely nested simulation and all other non halting inputs:

When-so-ever any simulated input to any simulating halt decider would never reach the final state of this simulated input in any finite number of steps it is always correct for the simulating halt decider to abort its simulation and transition to its reject state.


Can you PROVE that statement, or is this just one of your false 'self evident truth'.

Anyone that knows that x86 language can tell that its easy to match the infinite loop pattern:

_Infinite_Loop()
[000015fa](01)  55 push ebp
[000015fb](02)  8bec mov ebp,esp
[000015fd](02)  ebfe jmp 000015fd
[000015ff](01)  5d pop ebp
[00001600](01)  c3 ret
Size in bytes:(0007) [00001600]

---[000015fa][002126f0][002126f4] 55 push ebp
---[000015fb][002126f0][002126f4] 8bec mov ebp,esp
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd

Showing that you can do one case does not prove that the same method works on all, particularly harder methods.

That is just you serving Red Herring.

And that pattern does NOT show up in the simulation by H of H^

Which makes it MORE lies by Red Herring.

FAIL.

Total lack of proof.

Does the proof include the posibility that the input includes a copy of the decider?


It is always the case that a simulating halt decider can correctly base its halt status decision on the behavior pure simulation of its input.

LIE.

Proven incorrect.

If H -> H.Qn then H^ -> H^.Qn and Halts and for H^ <H^> proves H wrong.


We know that this must be true because we know that the pure UTM simulation of an Turing Machine description is defined to have equivalent behavior to that of the direct execution of the same machine


Right, but that does't prove what you sy.

You are just LYING out of your POOP.


The problem is that IF the simulating halt decider does abort its input based on some condition, then it is no longer a source of truth for the halting status of that input.


It is not answering the question: Does the input stop running?


YOU need to answer, which H are you using?

If H doesn't abort, then H^ is non-halting, but H will never answer.

If H does abort and go to H.Qn, then the pure simulation of the input WILL halt at H^.Qn, so H was wrong.

FAIL.


It is answering the question:
Would the pure simulation of the input ever stop running?

Right, and if H -> H.Qn it will.

FAIL.

YOU JUST AREN'T BRIGHT ENOUGH TO GET THIS. IT CAN BE VERIFIED AS COMPLETELY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS.

It is the case that if embedded_H recognizes an infinitely repeating pattern in the simulation of its input such that this correctly simulated input cannot possibly reach its final state then this is complete prove that this simulated input never halts.

If it COULD CORRECTLY recognize an infinitely repeating pattern in its
simulation that can not possibly reach its final state (when simulated by a UTM, not just H) then, YES, H can go to H.Qn.

The problem is that due to 'pathological self-reference' in H^, ANY pattern that H sees in its simulation of <H^> <H^> that it transitions to H.Qn, will BY DEFINITION, become a halting pattern.


So a correctly simulated INPUT that cannot possibly reach its final state reaches its final state anyway. YOU ARE DUMBER THAN A BOX OF ROCKS !!!



That's not what I said, I said there is no pattern that H use to detect that it won't halt, as any pattern that H uses to decide to go to H.Qn will be WRONG for H^ as if H goes to H.Qn, then H^ also goes to H^.Qn and Halts.


When the correctly simulated INPUT to embedded_H cannot possibly reach its final state it is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



Right,  but you have only proved that H^ is non-halting for the case where H doesn't abort its simulation.


Because you are dumber than a box of rocks (or perhaps you are a bot?)
You did not notice that I never mentioned the word: "halting".

For a human being you are much dumber than a box of rocks.

For a bot you did quite well (you nearly passed the Turing test) it took me this long to realize that you are not a human being.


But reaching final state is the same as Halting.

You have only prove that the pure simulation of the input to H never reaches a final state for case when H doesn't abort its simulation.

You deliberate weasel words do not apply to what I said:

(1) Premise: When the correctly simulated INPUT to embedded_H cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



And the correct simulation of the input to H is determined by the UTM, not H.


(2) is a logical consequence of (1).
It is logically incorrect to argue with a deductive logical premise.


But 1 is only true if H doesn't go to H.Qn, so H can't correctly go to H.Qn.


You are quite the deceiver making sure to always change the subject rather than directly address the point at hand.

And you seem quite dense. I did NOT change the subject, I pointed out an error in your statement. You seem to be unable to comprehend that.


(2) logically follows from (1) is true.

But 1 ISN'T True if H <H^> <H^> -> H.Qn, as the correctly simulate input

When testing whether or not one assertion logically follows from another the premises are always "given" to be true even if they are false.

Don't know what sort of logic you are claiming.

And arguemnt with a false premise is unsound.


We are not yet looking at soundness we are looking at validity.
It is true that (2) logically follows from (1).
We can't move on from this one point until we have mutual agreement.


Very strange then, why are you arguing about that which was accepted unless you disagree to the conditions that they were accepted under?

It has long been accepted that the under the hypothetical condition where H can actually determine that the UTM will run forever, it is correct (and in fact needed to be correct) for H to go to H.Qn and say non-halting.


OKAY so then you agree with this?

(1) Premise: When the correctly simulated INPUT to embedded_H
cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to
report that its correctly simulated INPUT cannot possibly
reach its final state.


Under the definition that 'correctly simulated input' is as determined by a UTM, not H (if it aborts its simulation).


It is only stipulated to be correct other details are currently unspecified.

That isn't a 'stipulation', that is a DEFINITION.

This is obviously your attempt at being a weasel.

The DEFINITION of correct simulation is the results of a UTM simulating the input.

Any deviaiton in this means you are just eating your POOP.


It also does not presume that H CAN determine that this condition exists, so it would be correct, but H might not be able to decide to do so. So it may be correct for it to do so, but it might not actually be able to do it.

There is also the case you tend to ignore that you start with an H that is defined to NOT abort, but you try to use (2) to claim that it now can abort, the H is (2) must be the same H that the H^ in (1) was built form

Click here to read the complete article
Subject: Re: Concise refutation of halting problem proofs V52 [ Honest Dialogue Begins ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Wed, 26 Jan 2022 00:03 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 25
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: Tue, 25 Jan 2022 18:03:06 -0600
Date: Tue, 25 Jan 2022 18:03:05 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ Honest
Dialogue Begins ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me>
<ld2dnW-kzJX_tXP8nZ2dnUU7-W3NnZ2d@giganews.com> <z9qHJ.3181$rU.2919@fx34.iad>
<i7qdnYQH-OUoInP8nZ2dnUU7-b3NnZ2d@giganews.com>
<qWGHJ.11522$2W.7884@fx36.iad>
<yuWdnWDd8speonL8nZ2dnUU7-cPNnZ2d@giganews.com>
<KPHHJ.311933$qz4.109480@fx97.iad>
<OMGdndHAM9CDznL8nZ2dnUU7-YfNnZ2d@giganews.com>
<1UIHJ.282256$1d1.28846@fx99.iad>
<5p-dnZEaj-b4wXL8nZ2dnUU7-fHNnZ2d@giganews.com>
<3dJHJ.17533$f04.698@fx23.iad>
<eICdne89nPPI73L8nZ2dnUU7-V3NnZ2d@giganews.com>
<fsKHJ.15868$yS2.11625@fx20.iad> <ssnshc$jfl$1@dont-email.me>
<7QKHJ.3189$rU.3101@fx34.iad> <5aOdnY1a4_Xt53L8nZ2dnUU7-SvNnZ2d@giganews.com>
<EYKHJ.8824$2V.6890@fx07.iad> <_u-dnQzrFvT54XL8nZ2dnUU7-XednZ2d@giganews.com>
<DoLHJ.5615$QO.1124@fx29.iad> <dJ6dnbZdb_R0GXL8nZ2dnUU7-W-dnZ2d@giganews.com>
<oHLHJ.138400$Gco3.122595@fx01.iad>
<2sWdndujvZPKF3L8nZ2dnUU7-V_NnZ2d@giganews.com> <7zRHJ.3234$rU.2663@fx34.iad>
<qOWdnYg47f8nkW38nZ2dnUU7-XvNnZ2d@giganews.com>
<yW%HJ.7148$h91.5996@fx48.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <yW%HJ.7148$h91.5996@fx48.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <pMmdnUSKnpgnEm38nZ2dnUU7-bnNnZ2d@giganews.com>
Lines: 728
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Mk8tsfNBfEsKJl0Xr/i+NL+nr+U/ZPxITLrSsa/gXUTq5rYGJ0GN+HAHnUsdsVM5tqeGa7g/udqlYZc!wV7dQRjrapSoBevhAVC0nwbOkOZlZPU035lTnzE2UXDxbANTX46z04CK1H+l6yFejUaK4iQkrLN4
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: 44546
View all headers
On 1/25/2022 5:43 PM, Richard Damon wrote:
On 1/25/22 9:44 AM, olcott wrote:
On 1/25/2022 5:55 AM, Richard Damon wrote:
On 1/25/22 12:27 AM, olcott wrote:
On 1/24/2022 11:15 PM, Richard Damon wrote:

On 1/25/22 12:04 AM, olcott wrote:
On 1/24/2022 10:54 PM, Richard Damon wrote:

On 1/24/22 11:28 PM, olcott wrote:
On 1/24/2022 10:25 PM, Richard Damon wrote:
On 1/24/22 11:19 PM, olcott wrote:
On 1/24/2022 10:16 PM, Richard Damon wrote:
On 1/24/22 10:58 PM, olcott wrote:
On 1/24/2022 9:50 PM, Richard Damon wrote:
On 1/24/22 10:45 PM, olcott wrote:
On 1/24/2022 8:26 PM, Richard Damon wrote:
On 1/24/22 9:11 PM, olcott wrote:
On 1/24/2022 8:03 PM, Richard Damon wrote:

On 1/24/22 8:32 PM, olcott wrote:
On 1/24/2022 6:50 PM, Richard Damon wrote:
On 1/24/22 7:09 PM, olcott wrote:
On 1/24/2022 5:49 PM, Richard Damon wrote:
On 1/24/22 10:03 AM, olcott wrote:
On 1/23/2022 10:45 PM, Richard Damon wrote:
On 1/23/22 11:17 PM, olcott wrote:
On 1/23/2022 9:57 PM, Richard Damon wrote:

On 1/23/22 10:40 PM, olcott wrote:
On 1/23/2022 9:24 PM, Richard Damon wrote:
On 1/23/22 10:10 PM, olcott wrote:
On 1/23/2022 8:42 PM, Richard Damon wrote:
On 1/23/22 9:29 PM, olcott wrote:
On 1/23/2022 8:14 PM, Richard Damon wrote:

On 1/23/22 9:03 PM, olcott wrote:
On 1/23/2022 7:55 PM, Richard Damon wrote:
On 1/23/22 8:10 PM, olcott wrote:
On 1/23/2022 7:00 PM, Richard Damon wrote:
On 1/23/22 7:25 PM, olcott wrote:
On 1/23/2022 6:09 PM, Richard Damon wrote:
On 1/23/22 7:00 PM, olcott wrote:
On 1/23/2022 5:50 PM, Richard Damon wrote:
On 1/23/22 6:16 PM, olcott wrote:
On 1/23/2022 5:06 PM, Richard Damon wrote:
On 1/23/22 5:47 PM, olcott wrote:
On 1/23/2022 4:40 PM, Richard Damon wrote:
On 1/23/22 5:18 PM, olcott wrote:
On 1/23/2022 4:01 PM, Richard Damon wrote:
On 1/23/22 4:40 PM, olcott wrote:
On 1/23/2022 2:25 PM, Richard Damon wrote:

On 1/23/22 2:19 PM, olcott wrote:
On 1/22/2022 10:43 PM, Richard Damon wrote:
On 1/22/22 11:34 PM, olcott wrote:
On 1/22/2022 3:36 PM, Richard Damon wrote:
On 1/22/22 4:25 PM, olcott wrote:
On 1/22/2022 3:20 PM, Richard Damon wrote:


This is true for infinite loops, infinite recursion, infinitely nested simulation and all other non halting inputs:

When-so-ever any simulated input to any simulating halt decider would never reach the final state of this simulated input in any finite number of steps it is always correct for the simulating halt decider to abort its simulation and transition to its reject state.


Can you PROVE that statement, or is this just one of your false 'self evident truth'.

Anyone that knows that x86 language can tell that its easy to match the infinite loop pattern:

_Infinite_Loop()
[000015fa](01)  55 push ebp
[000015fb](02)  8bec mov ebp,esp
[000015fd](02)  ebfe jmp 000015fd
[000015ff](01)  5d pop ebp
[00001600](01)  c3 ret
Size in bytes:(0007) [00001600]

---[000015fa][002126f0][002126f4] 55 push ebp
---[000015fb][002126f0][002126f4] 8bec mov ebp,esp
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd

Showing that you can do one case does not prove that the same method works on all, particularly harder methods.

That is just you serving Red Herring.

And that pattern does NOT show up in the simulation by H of H^

Which makes it MORE lies by Red Herring.

FAIL.

Total lack of proof.

Does the proof include the posibility that the input includes a copy of the decider?


It is always the case that a simulating halt decider can correctly base its halt status decision on the behavior pure simulation of its input.

LIE.

Proven incorrect.

If H -> H.Qn then H^ -> H^.Qn and Halts and for H^ <H^> proves H wrong.


We know that this must be true because we know that the pure UTM simulation of an Turing Machine description is defined to have equivalent behavior to that of the direct execution of the same machine


Right, but that does't prove what you sy.

You are just LYING out of your POOP.


The problem is that IF the simulating halt decider does abort its input based on some condition, then it is no longer a source of truth for the halting status of that input.


It is not answering the question: Does the input stop running?


YOU need to answer, which H are you using?

If H doesn't abort, then H^ is non-halting, but H will never answer.

If H does abort and go to H.Qn, then the pure simulation of the input WILL halt at H^.Qn, so H was wrong.

FAIL.


It is answering the question:
Would the pure simulation of the input ever stop running?

Right, and if H -> H.Qn it will.

FAIL.

YOU JUST AREN'T BRIGHT ENOUGH TO GET THIS. IT CAN BE VERIFIED AS COMPLETELY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS.

It is the case that if embedded_H recognizes an infinitely repeating pattern in the simulation of its input such that this correctly simulated input cannot possibly reach its final state then this is complete prove that this simulated input never halts.

If it COULD CORRECTLY recognize an infinitely repeating pattern in its
simulation that can not possibly reach its final state (when simulated by a UTM, not just H) then, YES, H can go to H.Qn.

The problem is that due to 'pathological self-reference' in H^, ANY pattern that H sees in its simulation of <H^> <H^> that it transitions to H.Qn, will BY DEFINITION, become a halting pattern.


So a correctly simulated INPUT that cannot possibly reach its final state reaches its final state anyway. YOU ARE DUMBER THAN A BOX OF ROCKS !!!



That's not what I said, I said there is no pattern that H use to detect that it won't halt, as any pattern that H uses to decide to go to H.Qn will be WRONG for H^ as if H goes to H.Qn, then H^ also goes to H^.Qn and Halts.


When the correctly simulated INPUT to embedded_H cannot possibly reach its final state it is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



Right,  but you have only proved that H^ is non-halting for the case where H doesn't abort its simulation.


Because you are dumber than a box of rocks (or perhaps you are a bot?)
You did not notice that I never mentioned the word: "halting".

For a human being you are much dumber than a box of rocks.

For a bot you did quite well (you nearly passed the Turing test) it took me this long to realize that you are not a human being.


But reaching final state is the same as Halting.

You have only prove that the pure simulation of the input to H never reaches a final state for case when H doesn't abort its simulation.

You deliberate weasel words do not apply to what I said:

(1) Premise: When the correctly simulated INPUT to embedded_H cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



And the correct simulation of the input to H is determined by the UTM, not H.


(2) is a logical consequence of (1).
It is logically incorrect to argue with a deductive logical premise.


But 1 is only true if H doesn't go to H.Qn, so H can't correctly go to H.Qn.


You are quite the deceiver making sure to always change the subject rather than directly address the point at hand.

And you seem quite dense. I did NOT change the subject, I pointed out an error in your statement. You seem to be unable to comprehend that.


(2) logically follows from (1) is true.

But 1 ISN'T True if H <H^> <H^> -> H.Qn, as the correctly simulate input

When testing whether or not one assertion logically follows from another the premises are always "given" to be true even if they are false.

Don't know what sort of logic you are claiming.

And arguemnt with a false premise is unsound.


We are not yet looking at soundness we are looking at validity.
It is true that (2) logically follows from (1).
We can't move on from this one point until we have mutual agreement.


Very strange then, why are you arguing about that which was accepted unless you disagree to the conditions that they were accepted under?

It has long been accepted that the under the hypothetical condition where H can actually determine that the UTM will run forever, it is correct (and in fact needed to be correct) for H to go to H.Qn and say non-halting.


OKAY so then you agree with this?

(1) Premise: When the correctly simulated INPUT to embedded_H
cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to
report that its correctly simulated INPUT cannot possibly
reach its final state.


Under the definition that 'correctly simulated input' is as determined by a UTM, not H (if it aborts its simulation).


It is only stipulated to be correct other details are currently unspecified.

That isn't a 'stipulation', that is a DEFINITION.

This is obviously your attempt at being a weasel.

The DEFINITION of correct simulation is the results of a UTM simulating the input.

Any deviaiton in this means you are just eating your POOP.


It also does not presume that H CAN determine that this condition exists, so it would be correct, but H might not be able to decide to do so. So it may be correct for it to do so, but it might not actually be able to do it.


Click here to read the complete article
Subject: Re: Concise refutation of halting problem proofs V52 [ Honest Dialogue Begins ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Wed, 26 Jan 2022 01:11 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 25
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: Tue, 25 Jan 2022 19:11:38 -0600
Date: Tue, 25 Jan 2022 19:11:37 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ Honest
Dialogue Begins ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me>
<i7qdnYQH-OUoInP8nZ2dnUU7-b3NnZ2d@giganews.com>
<qWGHJ.11522$2W.7884@fx36.iad>
<yuWdnWDd8speonL8nZ2dnUU7-cPNnZ2d@giganews.com>
<KPHHJ.311933$qz4.109480@fx97.iad>
<OMGdndHAM9CDznL8nZ2dnUU7-YfNnZ2d@giganews.com>
<1UIHJ.282256$1d1.28846@fx99.iad>
<5p-dnZEaj-b4wXL8nZ2dnUU7-fHNnZ2d@giganews.com>
<3dJHJ.17533$f04.698@fx23.iad>
<eICdne89nPPI73L8nZ2dnUU7-V3NnZ2d@giganews.com>
<fsKHJ.15868$yS2.11625@fx20.iad> <ssnshc$jfl$1@dont-email.me>
<7QKHJ.3189$rU.3101@fx34.iad> <5aOdnY1a4_Xt53L8nZ2dnUU7-SvNnZ2d@giganews.com>
<EYKHJ.8824$2V.6890@fx07.iad> <_u-dnQzrFvT54XL8nZ2dnUU7-XednZ2d@giganews.com>
<DoLHJ.5615$QO.1124@fx29.iad> <dJ6dnbZdb_R0GXL8nZ2dnUU7-W-dnZ2d@giganews.com>
<oHLHJ.138400$Gco3.122595@fx01.iad>
<2sWdndujvZPKF3L8nZ2dnUU7-V_NnZ2d@giganews.com> <7zRHJ.3234$rU.2663@fx34.iad>
<qOWdnYg47f8nkW38nZ2dnUU7-XvNnZ2d@giganews.com>
<yW%HJ.7148$h91.5996@fx48.iad>
<pMmdnUSKnpgnEm38nZ2dnUU7-bnNnZ2d@giganews.com>
<Bq0IJ.313197$qz4.269632@fx97.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <Bq0IJ.313197$qz4.269632@fx97.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <GbOdnRAEI7BXAm38nZ2dnUU7-XnNnZ2d@giganews.com>
Lines: 801
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-JH2VFlACuigyZJ480tJDuVDLDSF28rOKXPt0lExIAeEOHApbf7TlGMYTpJhNY4M93F0PDXQgFoFWljK!+qXwvMPBaLCWSXzkkyoojQ3Hi8hu5h32puKsuAZ+6c45ofkWstN/KsYLr8p8IRnon5OCeI8bQ2WY
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: 48949
View all headers
On 1/25/2022 6:17 PM, Richard Damon wrote:

On 1/25/22 7:03 PM, olcott wrote:
On 1/25/2022 5:43 PM, Richard Damon wrote:
On 1/25/22 9:44 AM, olcott wrote:
On 1/25/2022 5:55 AM, Richard Damon wrote:
On 1/25/22 12:27 AM, olcott wrote:
On 1/24/2022 11:15 PM, Richard Damon wrote:

On 1/25/22 12:04 AM, olcott wrote:
On 1/24/2022 10:54 PM, Richard Damon wrote:

On 1/24/22 11:28 PM, olcott wrote:
On 1/24/2022 10:25 PM, Richard Damon wrote:
On 1/24/22 11:19 PM, olcott wrote:
On 1/24/2022 10:16 PM, Richard Damon wrote:
On 1/24/22 10:58 PM, olcott wrote:
On 1/24/2022 9:50 PM, Richard Damon wrote:
On 1/24/22 10:45 PM, olcott wrote:
On 1/24/2022 8:26 PM, Richard Damon wrote:
On 1/24/22 9:11 PM, olcott wrote:
On 1/24/2022 8:03 PM, Richard Damon wrote:

On 1/24/22 8:32 PM, olcott wrote:
On 1/24/2022 6:50 PM, Richard Damon wrote:
On 1/24/22 7:09 PM, olcott wrote:
On 1/24/2022 5:49 PM, Richard Damon wrote:
On 1/24/22 10:03 AM, olcott wrote:
On 1/23/2022 10:45 PM, Richard Damon wrote:
On 1/23/22 11:17 PM, olcott wrote:
On 1/23/2022 9:57 PM, Richard Damon wrote:

On 1/23/22 10:40 PM, olcott wrote:
On 1/23/2022 9:24 PM, Richard Damon wrote:
On 1/23/22 10:10 PM, olcott wrote:
On 1/23/2022 8:42 PM, Richard Damon wrote:
On 1/23/22 9:29 PM, olcott wrote:
On 1/23/2022 8:14 PM, Richard Damon wrote:

On 1/23/22 9:03 PM, olcott wrote:
On 1/23/2022 7:55 PM, Richard Damon wrote:
On 1/23/22 8:10 PM, olcott wrote:
On 1/23/2022 7:00 PM, Richard Damon wrote:
On 1/23/22 7:25 PM, olcott wrote:
On 1/23/2022 6:09 PM, Richard Damon wrote:
On 1/23/22 7:00 PM, olcott wrote:
On 1/23/2022 5:50 PM, Richard Damon wrote:
On 1/23/22 6:16 PM, olcott wrote:
On 1/23/2022 5:06 PM, Richard Damon wrote:
On 1/23/22 5:47 PM, olcott wrote:
On 1/23/2022 4:40 PM, Richard Damon wrote:
On 1/23/22 5:18 PM, olcott wrote:
On 1/23/2022 4:01 PM, Richard Damon wrote:
On 1/23/22 4:40 PM, olcott wrote:
On 1/23/2022 2:25 PM, Richard Damon wrote:

On 1/23/22 2:19 PM, olcott wrote:
On 1/22/2022 10:43 PM, Richard Damon wrote:
On 1/22/22 11:34 PM, olcott wrote:
On 1/22/2022 3:36 PM, Richard Damon wrote:
On 1/22/22 4:25 PM, olcott wrote:
On 1/22/2022 3:20 PM, Richard Damon wrote:


This is true for infinite loops, infinite recursion, infinitely nested simulation and all other non halting inputs:

When-so-ever any simulated input to any simulating halt decider would never reach the final state of this simulated input in any finite number of steps it is always correct for the simulating halt decider to abort its simulation and transition to its reject state.


Can you PROVE that statement, or is this just one of your false 'self evident truth'.

Anyone that knows that x86 language can tell that its easy to match the infinite loop pattern:

_Infinite_Loop()
[000015fa](01)  55 push ebp
[000015fb](02)  8bec mov ebp,esp
[000015fd](02)  ebfe jmp 000015fd
[000015ff](01)  5d pop ebp
[00001600](01)  c3 ret
Size in bytes:(0007) [00001600]

---[000015fa][002126f0][002126f4] 55 push ebp
---[000015fb][002126f0][002126f4] 8bec mov ebp,esp
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd

Showing that you can do one case does not prove that the same method works on all, particularly harder methods.

That is just you serving Red Herring.

And that pattern does NOT show up in the simulation by H of H^

Which makes it MORE lies by Red Herring.

FAIL.

Total lack of proof.

Does the proof include the posibility that the input includes a copy of the decider?


It is always the case that a simulating halt decider can correctly base its halt status decision on the behavior pure simulation of its input.

LIE.

Proven incorrect.

If H -> H.Qn then H^ -> H^.Qn and Halts and for H^ <H^> proves H wrong.


We know that this must be true because we know that the pure UTM simulation of an Turing Machine description is defined to have equivalent behavior to that of the direct execution of the same machine


Right, but that does't prove what you sy.

You are just LYING out of your POOP.


The problem is that IF the simulating halt decider does abort its input based on some condition, then it is no longer a source of truth for the halting status of that input.


It is not answering the question: Does the input stop running?


YOU need to answer, which H are you using?

If H doesn't abort, then H^ is non-halting, but H will never answer.

If H does abort and go to H.Qn, then the pure simulation of the input WILL halt at H^.Qn, so H was wrong.

FAIL.


It is answering the question:
Would the pure simulation of the input ever stop running?

Right, and if H -> H.Qn it will.

FAIL.

YOU JUST AREN'T BRIGHT ENOUGH TO GET THIS. IT CAN BE VERIFIED AS COMPLETELY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS.

It is the case that if embedded_H recognizes an infinitely repeating pattern in the simulation of its input such that this correctly simulated input cannot possibly reach its final state then this is complete prove that this simulated input never halts.

If it COULD CORRECTLY recognize an infinitely repeating pattern in its
simulation that can not possibly reach its final state (when simulated by a UTM, not just H) then, YES, H can go to H.Qn.

The problem is that due to 'pathological self-reference' in H^, ANY pattern that H sees in its simulation of <H^> <H^> that it transitions to H.Qn, will BY DEFINITION, become a halting pattern.


So a correctly simulated INPUT that cannot possibly reach its final state reaches its final state anyway. YOU ARE DUMBER THAN A BOX OF ROCKS !!!



That's not what I said, I said there is no pattern that H use to detect that it won't halt, as any pattern that H uses to decide to go to H.Qn will be WRONG for H^ as if H goes to H.Qn, then H^ also goes to H^.Qn and Halts.


When the correctly simulated INPUT to embedded_H cannot possibly reach its final state it is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



Right,  but you have only proved that H^ is non-halting for the case where H doesn't abort its simulation.


Because you are dumber than a box of rocks (or perhaps you are a bot?)
You did not notice that I never mentioned the word: "halting".

For a human being you are much dumber than a box of rocks.

For a bot you did quite well (you nearly passed the Turing test) it took me this long to realize that you are not a human being.


But reaching final state is the same as Halting.

You have only prove that the pure simulation of the input to H never reaches a final state for case when H doesn't abort its simulation.

You deliberate weasel words do not apply to what I said:

(1) Premise: When the correctly simulated INPUT to embedded_H cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to report that its correctly simulated INPUT cannot possibly reach its final state.



And the correct simulation of the input to H is determined by the UTM, not H.


(2) is a logical consequence of (1).
It is logically incorrect to argue with a deductive logical premise.


But 1 is only true if H doesn't go to H.Qn, so H can't correctly go to H.Qn.


You are quite the deceiver making sure to always change the subject rather than directly address the point at hand.

And you seem quite dense. I did NOT change the subject, I pointed out an error in your statement. You seem to be unable to comprehend that.


(2) logically follows from (1) is true.

But 1 ISN'T True if H <H^> <H^> -> H.Qn, as the correctly simulate input

When testing whether or not one assertion logically follows from another the premises are always "given" to be true even if they are false.

Don't know what sort of logic you are claiming.

And arguemnt with a false premise is unsound.


We are not yet looking at soundness we are looking at validity.
It is true that (2) logically follows from (1).
We can't move on from this one point until we have mutual agreement.


Very strange then, why are you arguing about that which was accepted unless you disagree to the conditions that they were accepted under?

It has long been accepted that the under the hypothetical condition where H can actually determine that the UTM will run forever, it is correct (and in fact needed to be correct) for H to go to H.Qn and say non-halting.


OKAY so then you agree with this?

(1) Premise: When the correctly simulated INPUT to embedded_H
cannot possibly reach its final state

(2) Conclusion: It is necessarily correct for embedded_H to
report that its correctly simulated INPUT cannot possibly
reach its final state.


Under the definition that 'correctly simulated input' is as determined by a UTM, not H (if it aborts its simulation).


It is only stipulated to be correct other details are currently unspecified.

That isn't a 'stipulation', that is a DEFINITION.

This is obviously your attempt at being a weasel.

The DEFINITION of correct simulation is the results of a UTM simulating the input.

Any deviaiton in this means you are just eating your POOP.


It also does not presume that H CAN determine that this condition exists, so it would be correct, but H might not be able to decide to do so. So it may be correct for it to do so, but it might not actually be able to do it.

Click here to read the complete article
Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Thu, 27 Jan 2022 03:59 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 25
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: Wed, 26 Jan 2022 22:00:00 -0600
Date: Wed, 26 Jan 2022 21:59:59 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me>
<qOWdnYg47f8nkW38nZ2dnUU7-XvNnZ2d@giganews.com>
<yW%HJ.7148$h91.5996@fx48.iad>
<pMmdnUSKnpgnEm38nZ2dnUU7-bnNnZ2d@giganews.com>
<Bq0IJ.313197$qz4.269632@fx97.iad>
<GbOdnRAEI7BXAm38nZ2dnUU7-XnNnZ2d@giganews.com>
<UW1IJ.38990$i%.5899@fx04.iad>
<1IudnXCb-OzhJm38nZ2dnUU7-bvNnZ2d@giganews.com>
<Dq3IJ.17537$f04.1511@fx23.iad>
<ubqdneNkd89jWG38nZ2dnUU7-SnNnZ2d@giganews.com>
<S64IJ.27704$7U.16191@fx42.iad>
<8eydnSpcWIVSUm38nZ2dnUU7-XvNnZ2d@giganews.com>
<9k4IJ.15452$jb4.2046@fx24.iad>
<SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <N9oIJ.384$N31.159@fx45.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
Lines: 157
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-OGH+nNh+R0CFdqezZIlxRKasDJIm+/qnHK0cp41Pkd4pbTp4+kzZHW1pQqjAzsqNWElNUZRxuCodQG4!SyCI84szFbLJaKqyPgvPT7GSn6WXkkySRmi4t3Tv24Aw5ha37bbfTGzVNGRCB62C+/5kzbYZFmIj
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: 8977
View all headers
On 1/26/2022 9:18 PM, Richard Damon wrote:
On 1/26/22 9:42 PM, olcott wrote:
On 1/26/2022 8:29 PM, Richard Damon wrote:
On 1/26/22 9:18 PM, olcott wrote:
On 1/26/2022 7:25 PM, Richard Damon wrote:
On 1/26/22 8:07 PM, olcott wrote:
On 1/26/2022 6:46 PM, Richard Damon wrote:
On 1/26/22 7:09 PM, olcott wrote:
On 1/26/2022 5:54 PM, Richard Damon wrote:
On 1/26/22 9:39 AM, olcott wrote:
On 1/26/2022 6:03 AM, Richard Damon wrote:


_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You keep coming back to the idea that only an infinite simulation of an infinite sequence of configurations can recognize an infinite sequence of configurations.

That is ridiculously stupid.



You can detect SOME (not all) infinite execution in finite time due to patterns.

There is no finite pattern in the H^ based on an H that at some point goest to H.Qn that correctly detects the infinite behavior.

THAT is the point you miss, SOME infinite patterns are only really infinite when you work them out to infinitity.

Part of your problem is that the traces you look at are wrong. When H simulates H^, it needs to trace out the actual execution path of the H that part of H^, not switch to tracing what it was tracing.


You simply lack the intellectual capacity to understand that when embedded_H simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the pattern:

Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...



Which only happens if H NEVER aborts its simulation and thus can't give an answer.

If H DOES abort its simulation at ANY point, then the above is NOT the accurate trace of the behavior of the input.


YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE

_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You exactly same jackass point equally applies to this case:

Unless H simulates the infinite loop infinitely it is not an accurate simulation.


So, no rubbutal just red herring sushi.


The key point you miss is that if H does abort its simulation, then it needs to take into account that the machine it is simulating will do so too.


As long as H correctly determines that its simulated input cannot possibly reach its final state in any finite number of steps it has conclusively proved that this input never halts according to the Linz definition:


But it needs to prove that the UTM of its input never halts, and for H^, that means even if the H insisde H^ goes to H.Qn which means that H^ goes to H^.Qn, which of course Halts.


As soon as embedded_H (not H) determines that its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach its final state in any finite number of steps it terminates this simulation immediately stopping every element of the entire chain of nested simulations.


If you are claiming that embedded_H and H behave differently then you have been lying that you built H^ by the instruction of Linz, as the copy of H inside H^ is IDENTICAL (except what happens AFTER getting to H.Qy)

Now, IF H could make that proof, then it would be correct to go to H.Qn, but it would need to take into account that H^ halts if its copy of H goes to H.Qn, so this is NEVER possible.

FAIL

Then embedded_H transitions to Ĥ.qn which causes the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H and a decider is only accountable for computing the mapping from its actual inputs to an accept or reject state it makes no difference that Ĥ applied to ⟨Ĥ⟩ halts.

Thus you have admitted to LYING about working on the Halting problem as if you were the embedded_H would be the same algorithm as H, and the requirement on H was that is IS accoutable for the machine its input represents,

You are simply too freaking stupid to understand that deciders thus halt deciders are only accountable for computing the mapping from their actual inputs (nothing else in the whole freaking universe besides their actual inputs) to an accept or reject state.

An actual computer scientist would know this.


It seems you don't understand the difference between capabilities and requirements.

H is only CAPABLE of deciding based on what it can do. It can only computate a mapping based on what it actually can do.

It is REQUIRED to meet its requirements, which is to decide on the behavior of what its input would do if given to a UTM.


embedded_H must only determine whether or not is simulated input can ever reach its final state in any finite number of steps.


--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Thu, 27 Jan 2022 04:37 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 25
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 26 Jan 2022 22:38:01 -0600
Date: Wed, 26 Jan 2022 22:37:59 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me>
<pMmdnUSKnpgnEm38nZ2dnUU7-bnNnZ2d@giganews.com>
<Bq0IJ.313197$qz4.269632@fx97.iad>
<GbOdnRAEI7BXAm38nZ2dnUU7-XnNnZ2d@giganews.com>
<UW1IJ.38990$i%.5899@fx04.iad>
<1IudnXCb-OzhJm38nZ2dnUU7-bvNnZ2d@giganews.com>
<Dq3IJ.17537$f04.1511@fx23.iad>
<ubqdneNkd89jWG38nZ2dnUU7-SnNnZ2d@giganews.com>
<S64IJ.27704$7U.16191@fx42.iad>
<8eydnSpcWIVSUm38nZ2dnUU7-XvNnZ2d@giganews.com>
<9k4IJ.15452$jb4.2046@fx24.iad>
<SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <JToIJ.296644$1d1.101887@fx99.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
Lines: 184
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4f9ZddPX4EweR/MZrwL8NC40SW8otcHnrzX1StLmkpI6HZkyIBNRS0VSTg+IYm1yQxhW46tomeh6cDw!AU3GARXVUufheDkg0bO2yrzgy0rsRAMo1OQBir4K0svzCn0lbm7mtdFD+3/EvvjWF5uhL5JVQX5k
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: 10331
View all headers
On 1/26/2022 10:07 PM, Richard Damon wrote:
On 1/26/22 10:59 PM, olcott wrote:
On 1/26/2022 9:18 PM, Richard Damon wrote:
On 1/26/22 9:42 PM, olcott wrote:
On 1/26/2022 8:29 PM, Richard Damon wrote:
On 1/26/22 9:18 PM, olcott wrote:
On 1/26/2022 7:25 PM, Richard Damon wrote:
On 1/26/22 8:07 PM, olcott wrote:
On 1/26/2022 6:46 PM, Richard Damon wrote:
On 1/26/22 7:09 PM, olcott wrote:
On 1/26/2022 5:54 PM, Richard Damon wrote:
On 1/26/22 9:39 AM, olcott wrote:
On 1/26/2022 6:03 AM, Richard Damon wrote:


_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You keep coming back to the idea that only an infinite simulation of an infinite sequence of configurations can recognize an infinite sequence of configurations.

That is ridiculously stupid.



You can detect SOME (not all) infinite execution in finite time due to patterns.

There is no finite pattern in the H^ based on an H that at some point goest to H.Qn that correctly detects the infinite behavior.

THAT is the point you miss, SOME infinite patterns are only really infinite when you work them out to infinitity.

Part of your problem is that the traces you look at are wrong. When H simulates H^, it needs to trace out the actual execution path of the H that part of H^, not switch to tracing what it was tracing.


You simply lack the intellectual capacity to understand that when embedded_H simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the pattern:

Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...



Which only happens if H NEVER aborts its simulation and thus can't give an answer.

If H DOES abort its simulation at ANY point, then the above is NOT the accurate trace of the behavior of the input.


YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE

_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You exactly same jackass point equally applies to this case:

Unless H simulates the infinite loop infinitely it is not an accurate simulation.


So, no rubbutal just red herring sushi.


The key point you miss is that if H does abort its simulation, then it needs to take into account that the machine it is simulating will do so too.


As long as H correctly determines that its simulated input cannot possibly reach its final state in any finite number of steps it has conclusively proved that this input never halts according to the Linz definition:


But it needs to prove that the UTM of its input never halts, and for H^, that means even if the H insisde H^ goes to H.Qn which means that H^ goes to H^.Qn, which of course Halts.


As soon as embedded_H (not H) determines that its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach its final state in any finite number of steps it terminates this simulation immediately stopping every element of the entire chain of nested simulations.


If you are claiming that embedded_H and H behave differently then you have been lying that you built H^ by the instruction of Linz, as the copy of H inside H^ is IDENTICAL (except what happens AFTER getting to H.Qy)

Now, IF H could make that proof, then it would be correct to go to H.Qn, but it would need to take into account that H^ halts if its copy of H goes to H.Qn, so this is NEVER possible.

FAIL

Then embedded_H transitions to Ĥ.qn which causes the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H and a decider is only accountable for computing the mapping from its actual inputs to an accept or reject state it makes no difference that Ĥ applied to ⟨Ĥ⟩ halts.

Thus you have admitted to LYING about working on the Halting problem as if you were the embedded_H would be the same algorithm as H, and the requirement on H was that is IS accoutable for the machine its input represents,

You are simply too freaking stupid to understand that deciders thus halt deciders are only accountable for computing the mapping from their actual inputs (nothing else in the whole freaking universe besides their actual inputs) to an accept or reject state.

An actual computer scientist would know this.


It seems you don't understand the difference between capabilities and requirements.

H is only CAPABLE of deciding based on what it can do. It can only computate a mapping based on what it actually can do.

It is REQUIRED to meet its requirements, which is to decide on the behavior of what its input would do if given to a UTM.


embedded_H must only determine whether or not is simulated input can ever reach its final state in any finite number of steps.


Again, you seem to be lying about working on the Halting Problem and Linz proof.

If you were working on the Halting Problem and Linz proof then embedded_H would be identical to H, as required by Linz, and the correct answer for the 'behavior' of the input to embedded_H <H^> <H^> would be the behavior of UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we know that H^ will go to H^.Qn and Halt, and thus H/embedded_H going to H.Qn is incorrect.

So, you are just admitting that you are lying or are too stupid to understan what you are talking about.

Which is it?


I will not tolerate any digression from the point at hand until we have mutual agreement. This is verified as completely true entirely on the basis of the meaning of its words:

embedded_H must only determine whether or not its simulated input can
ever reach its final state in any finite number of steps.


--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Thu, 27 Jan 2022 15:25 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 25
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Followup-To: comp.theory
Date: Thu, 27 Jan 2022 09:25:04 -0600
Organization: A noiseless patient Spider
Lines: 202
Message-ID: <ssudgi$3gj$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me>
<GbOdnRAEI7BXAm38nZ2dnUU7-XnNnZ2d@giganews.com>
<UW1IJ.38990$i%.5899@fx04.iad>
<1IudnXCb-OzhJm38nZ2dnUU7-bvNnZ2d@giganews.com>
<Dq3IJ.17537$f04.1511@fx23.iad>
<ubqdneNkd89jWG38nZ2dnUU7-SnNnZ2d@giganews.com>
<S64IJ.27704$7U.16191@fx42.iad>
<8eydnSpcWIVSUm38nZ2dnUU7-XvNnZ2d@giganews.com>
<9k4IJ.15452$jb4.2046@fx24.iad>
<SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Jan 2022 15:25:06 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="373489d2d6a220e692ee02a77dd0e5a7";
logging-data="3603"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19qnI25Q8zptSPSDSe9+bxi"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:FaFkobH0USt9ezfnALXSoVuj/oA=
In-Reply-To: <7MvIJ.16685$V31.12106@fx47.iad>
Content-Language: en-US
View all headers
On 1/27/2022 5:56 AM, Richard Damon wrote:
On 1/26/22 11:37 PM, olcott wrote:
On 1/26/2022 10:07 PM, Richard Damon wrote:
On 1/26/22 10:59 PM, olcott wrote:
On 1/26/2022 9:18 PM, Richard Damon wrote:
On 1/26/22 9:42 PM, olcott wrote:
On 1/26/2022 8:29 PM, Richard Damon wrote:
On 1/26/22 9:18 PM, olcott wrote:
On 1/26/2022 7:25 PM, Richard Damon wrote:
On 1/26/22 8:07 PM, olcott wrote:
On 1/26/2022 6:46 PM, Richard Damon wrote:
On 1/26/22 7:09 PM, olcott wrote:
On 1/26/2022 5:54 PM, Richard Damon wrote:
On 1/26/22 9:39 AM, olcott wrote:
On 1/26/2022 6:03 AM, Richard Damon wrote:


_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You keep coming back to the idea that only an infinite simulation of an infinite sequence of configurations can recognize an infinite sequence of configurations.

That is ridiculously stupid.



You can detect SOME (not all) infinite execution in finite time due to patterns.

There is no finite pattern in the H^ based on an H that at some point goest to H.Qn that correctly detects the infinite behavior.

THAT is the point you miss, SOME infinite patterns are only really infinite when you work them out to infinitity.

Part of your problem is that the traces you look at are wrong. When H simulates H^, it needs to trace out the actual execution path of the H that part of H^, not switch to tracing what it was tracing.


You simply lack the intellectual capacity to understand that when embedded_H simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the pattern:

Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...



Which only happens if H NEVER aborts its simulation and thus can't give an answer.

If H DOES abort its simulation at ANY point, then the above is NOT the accurate trace of the behavior of the input.


YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE

_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You exactly same jackass point equally applies to this case:

Unless H simulates the infinite loop infinitely it is not an accurate simulation.


So, no rubbutal just red herring sushi.


The key point you miss is that if H does abort its simulation, then it needs to take into account that the machine it is simulating will do so too.


As long as H correctly determines that its simulated input cannot possibly reach its final state in any finite number of steps it has conclusively proved that this input never halts according to the Linz definition:


But it needs to prove that the UTM of its input never halts, and for H^, that means even if the H insisde H^ goes to H.Qn which means that H^ goes to H^.Qn, which of course Halts.


As soon as embedded_H (not H) determines that its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach its final state in any finite number of steps it terminates this simulation immediately stopping every element of the entire chain of nested simulations.


If you are claiming that embedded_H and H behave differently then you have been lying that you built H^ by the instruction of Linz, as the copy of H inside H^ is IDENTICAL (except what happens AFTER getting to H.Qy)

Now, IF H could make that proof, then it would be correct to go to H.Qn, but it would need to take into account that H^ halts if its copy of H goes to H.Qn, so this is NEVER possible.

FAIL

Then embedded_H transitions to Ĥ.qn which causes the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H and a decider is only accountable for computing the mapping from its actual inputs to an accept or reject state it makes no difference that Ĥ applied to ⟨Ĥ⟩ halts.

Thus you have admitted to LYING about working on the Halting problem as if you were the embedded_H would be the same algorithm as H, and the requirement on H was that is IS accoutable for the machine its input represents,

You are simply too freaking stupid to understand that deciders thus halt deciders are only accountable for computing the mapping from their actual inputs (nothing else in the whole freaking universe besides their actual inputs) to an accept or reject state.

An actual computer scientist would know this.


It seems you don't understand the difference between capabilities and requirements.

H is only CAPABLE of deciding based on what it can do. It can only computate a mapping based on what it actually can do.

It is REQUIRED to meet its requirements, which is to decide on the behavior of what its input would do if given to a UTM.


embedded_H must only determine whether or not is simulated input can ever reach its final state in any finite number of steps.


Again, you seem to be lying about working on the Halting Problem and Linz proof.

If you were working on the Halting Problem and Linz proof then embedded_H would be identical to H, as required by Linz, and the correct answer for the 'behavior' of the input to embedded_H <H^> <H^> would be the behavior of UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we know that H^ will go to H^.Qn and Halt, and thus H/embedded_H going to H.Qn is incorrect.

So, you are just admitting that you are lying or are too stupid to understan what you are talking about.

Which is it?


I will not tolerate any digression from the point at hand until we have mutual agreement. This is verified as completely true entirely on the basis of the meaning of its words:

embedded_H must only determine whether or not its simulated input can
ever reach its final state in any finite number of steps.



Translation: You will ignroe any disagreement with your incorrect statement because you need to get people to accept your falso premise for your unsound argument to work.

The problem with your statement is that you are showing that you atually mean something different than the true meaning of the words.

H (and thus embedded_H) need to determine whether or not its simuleted input will ever reach its final state for EVERY POSSIBLE finite number of steps, i.e. as determine by a UTM.


∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.



--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.math, sci.logic
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Thu, 27 Jan 2022 15:34 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 25
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.math,sci.logic
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Followup-To: comp.theory
Date: Thu, 27 Jan 2022 09:34:08 -0600
Organization: A noiseless patient Spider
Lines: 209
Message-ID: <ssue1i$81l$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me> <UW1IJ.38990$i%.5899@fx04.iad>
<1IudnXCb-OzhJm38nZ2dnUU7-bvNnZ2d@giganews.com>
<Dq3IJ.17537$f04.1511@fx23.iad>
<ubqdneNkd89jWG38nZ2dnUU7-SnNnZ2d@giganews.com>
<S64IJ.27704$7U.16191@fx42.iad>
<8eydnSpcWIVSUm38nZ2dnUU7-XvNnZ2d@giganews.com>
<9k4IJ.15452$jb4.2046@fx24.iad>
<SNudnYZfaZX6Tm38nZ2dnUU7-I3NnZ2d@giganews.com> <LMaIJ.8332$V31.330@fx47.iad>
<hsCdneOV_eybwGz8nZ2dnUU7-KPNnZ2d@giganews.com> <xalIJ.8632$rQ.8159@fx18.iad>
<r8OdnZwzO4tUf2z8nZ2dnUU7-SnNnZ2d@giganews.com> <eXlIJ.16438$2W.334@fx36.iad>
<zIKdnXB_n-rDbWz8nZ2dnUU7-enNnZ2d@giganews.com> <0wmIJ.176$XDR2.80@fx02.iad>
<37adnXNhdcJynW_8nZ2dnUU7-d3NnZ2d@giganews.com>
<csnIJ.19295$OU.5598@fx22.iad>
<vvWdnWkD_aAWm2_8nZ2dnUU7-UHNnZ2d@giganews.com> <N9oIJ.384$N31.159@fx45.iad>
<PaqdncLyCYZdhW_8nZ2dnUU7-evNnZ2d@giganews.com>
<JToIJ.296644$1d1.101887@fx99.iad>
<QZWdncKZjYg0vG_8nZ2dnUU7-SPNnZ2d@giganews.com>
<7MvIJ.16685$V31.12106@fx47.iad> <ssudgi$3gj$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Jan 2022 15:34:10 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="373489d2d6a220e692ee02a77dd0e5a7";
logging-data="8245"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Hqmm9SrVqoT/M5S0svHhn"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:LJcEDFkBuF4/v6kIVzJFXZ7frdo=
In-Reply-To: <ssudgi$3gj$1@dont-email.me>
Content-Language: en-US
View all headers
On 1/27/2022 9:25 AM, olcott wrote:
On 1/27/2022 5:56 AM, Richard Damon wrote:
On 1/26/22 11:37 PM, olcott wrote:
On 1/26/2022 10:07 PM, Richard Damon wrote:
On 1/26/22 10:59 PM, olcott wrote:
On 1/26/2022 9:18 PM, Richard Damon wrote:
On 1/26/22 9:42 PM, olcott wrote:
On 1/26/2022 8:29 PM, Richard Damon wrote:
On 1/26/22 9:18 PM, olcott wrote:
On 1/26/2022 7:25 PM, Richard Damon wrote:
On 1/26/22 8:07 PM, olcott wrote:
On 1/26/2022 6:46 PM, Richard Damon wrote:
On 1/26/22 7:09 PM, olcott wrote:
On 1/26/2022 5:54 PM, Richard Damon wrote:
On 1/26/22 9:39 AM, olcott wrote:
On 1/26/2022 6:03 AM, Richard Damon wrote:


_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You keep coming back to the idea that only an infinite simulation of an infinite sequence of configurations can recognize an infinite sequence of configurations.

That is ridiculously stupid.



You can detect SOME (not all) infinite execution in finite time due to patterns.

There is no finite pattern in the H^ based on an H that at some point goest to H.Qn that correctly detects the infinite behavior.

THAT is the point you miss, SOME infinite patterns are only really infinite when you work them out to infinitity.

Part of your problem is that the traces you look at are wrong. When H simulates H^, it needs to trace out the actual execution path of the H that part of H^, not switch to tracing what it was tracing.


You simply lack the intellectual capacity to understand that when embedded_H simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the pattern:

Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...



Which only happens if H NEVER aborts its simulation and thus can't give an answer.

If H DOES abort its simulation at ANY point, then the above is NOT the accurate trace of the behavior of the input.


YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE

_Infinite_Loop()
[00000d9a](01)  55              push ebp
[00000d9b](02)  8bec            mov ebp,esp
[00000d9d](02)  ebfe            jmp 00000d9d
[00000d9f](01)  5d              pop ebp
[00000da0](01)  c3              ret
Size in bytes:(0007) [00000da0]

You exactly same jackass point equally applies to this case:

Unless H simulates the infinite loop infinitely it is not an accurate simulation.


So, no rubbutal just red herring sushi.


The key point you miss is that if H does abort its simulation, then it needs to take into account that the machine it is simulating will do so too.


As long as H correctly determines that its simulated input cannot possibly reach its final state in any finite number of steps it has conclusively proved that this input never halts according to the Linz definition:


But it needs to prove that the UTM of its input never halts, and for H^, that means even if the H insisde H^ goes to H.Qn which means that H^ goes to H^.Qn, which of course Halts.


As soon as embedded_H (not H) determines that its simulated input ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach its final state in any finite number of steps it terminates this simulation immediately stopping every element of the entire chain of nested simulations.


If you are claiming that embedded_H and H behave differently then you have been lying that you built H^ by the instruction of Linz, as the copy of H inside H^ is IDENTICAL (except what happens AFTER getting to H.Qy)

Now, IF H could make that proof, then it would be correct to go to H.Qn, but it would need to take into account that H^ halts if its copy of H goes to H.Qn, so this is NEVER possible.

FAIL

Then embedded_H transitions to Ĥ.qn which causes the original Ĥ applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to ⟨Ĥ⟩ is not an input to embedded_H and a decider is only accountable for computing the mapping from its actual inputs to an accept or reject state it makes no difference that Ĥ applied to ⟨Ĥ⟩ halts.

Thus you have admitted to LYING about working on the Halting problem as if you were the embedded_H would be the same algorithm as H, and the requirement on H was that is IS accoutable for the machine its input represents,

You are simply too freaking stupid to understand that deciders thus halt deciders are only accountable for computing the mapping from their actual inputs (nothing else in the whole freaking universe besides their actual inputs) to an accept or reject state.

An actual computer scientist would know this.


It seems you don't understand the difference between capabilities and requirements.

H is only CAPABLE of deciding based on what it can do. It can only computate a mapping based on what it actually can do.

It is REQUIRED to meet its requirements, which is to decide on the behavior of what its input would do if given to a UTM.


embedded_H must only determine whether or not is simulated input can ever reach its final state in any finite number of steps.


Again, you seem to be lying about working on the Halting Problem and Linz proof.

If you were working on the Halting Problem and Linz proof then embedded_H would be identical to H, as required by Linz, and the correct answer for the 'behavior' of the input to embedded_H <H^> <H^> would be the behavior of UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we know that H^ will go to H^.Qn and Halt, and thus H/embedded_H going to H.Qn is incorrect.

So, you are just admitting that you are lying or are too stupid to understan what you are talking about.

Which is it?


I will not tolerate any digression from the point at hand until we have mutual agreement. This is verified as completely true entirely on the basis of the meaning of its words:

embedded_H must only determine whether or not its simulated input can
ever reach its final state in any finite number of steps.



Translation: You will ignroe any disagreement with your incorrect statement because you need to get people to accept your falso premise for your unsound argument to work.

The problem with your statement is that you are showing that you atually mean something different than the true meaning of the words.

H (and thus embedded_H) need to determine whether or not its simuleted input will ever reach its final state for EVERY POSSIBLE finite number of steps, i.e. as determine by a UTM.


∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.

Halts(⟨Ĥ⟩, ⟨Ĥ⟩) ≡
(∃N such that the pure simulation of the input
to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps)





--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Sat, 29 Jan 2022 18:09 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Followup-To: comp.theory
Date: Sat, 29 Jan 2022 12:09:01 -0600
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <st3vrv$hnh$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 29 Jan 2022 18:09:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="119090c1a975c238d4973f53c8b6cad8";
logging-data="18161"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WlvoZL9V18be7WhHuFbSA"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:lSZyzSD4lDQo+ze3ZX795hbcmvc=
In-Reply-To: <875yq2h2ea.fsf@bsb.me.uk>
Content-Language: en-US
View all headers
On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

And the 'actual behavior of its actual inputs' is DEFINED to be what
the computation the input actually does when run as an independent
machine, or what a UTM will do when simulating that input.

If that isn't the meaning you are using, then you are just lying that
you are working on the halting problem, which is what seems to be the
case. (That you are lying that is).

It is certainly true that PO is not addressing the halting problem.  He
has been 100% clear that false is, in his "opinion", the correct result
for at least one halting computation.  This is not in dispute (unless
he's retracted that and I missed it).


The following simplifies the syntax for the definition of the Linz Turing machine Ĥ, it is now a single machine with a single start state. A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

There are no finite number of steps of the pure simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by embedded_H such that this simulated input meets the Linz definition of halting:

computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)

Therefore it is correct to say that the input to embedded_H specifies a sequence of configurations that never halts.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

To you and I, this means that he's not working on the halting problem,
but I am not sure you can say he is lying about that.  For one thing,
how can he be intending to deceive (a core part of lying) when he's been
clear the he accepts the wrong answer as being the right one?  If
someone claims to be working on "the addition problem", and also claims
that 2+2=5 is correct, it's hard to consider either claim to be a lie.
The person is just deeply confused.

But what sort of confused can explain this nonsense?  I think the answer
lies in PO's background.  The "binary square root" function is not
computable as far as a mathematician is concerned because no TM can halt
with, say, sqrt(0b10) on the tape.  But to an engineer, the function
poses no problem because we can get as close as we like.  If
0b1.01101010000 is not good enough, just add more digits.

The point is I think PO does not know what a formal, mathematical
problem really is.  To him, anything about code, machines or programs is
about solving an engineering problem "well enough" -- with "well enough"
open to be defined by PO himself.

More disturbing to me is that he is not even talking about Turing
machines, again as evidenced by his own plain words.  It is not in
dispute that he claims that two (deterministic) TMs, one an identical
copy of the other, can transition to different states despite both being
presented with identical input.  These are not Turing machines but Magic
machines, and I can't see how any discussion can be had while the action
of the things being considered is not a simple function of the input and
the state transition graph.


H and embedded_H are not identical, one has an infinite loop appended to its accept state.

I will not tolerate digression into this side issue until after mutual agreement is achieved on the first point. Until then these side issues are no more than a dishonest dodge distraction away from the main point.

This is why I stopped replying.  While there are things to say about
PO's Other Halting problem (principally that even the POOH problem can't
be solved), I had nothing more to say while the "machines" being
discussed are magic.



--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ THE KEY QUESTION ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.logic
Followup: comp.theory
Date: Sat, 29 Jan 2022 20:29 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 29 Jan 2022 14:29:40 -0600
Date: Sat, 29 Jan 2022 14:29:39 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ THE KEY
QUESTION ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.logic
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <875yq2h2ea.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <iqGdnZERkLUpPmj8nZ2dnUU7-QnNnZ2d@giganews.com>
Lines: 96
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-PKgJKs9fF0uO3KfJg6PdonhWel4aYGRC5/coGSQ1fFtyQ926HMOdvVAlPWDK0ynAb9bkyZemNN2xj85!X39UpbrHuAPF/j2EoiLOISRIAU63SsVqbV0cEJ518tV8XCbh9TrQKkkDx2I5tVADWG+kb0AtiuMr
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: 6376
View all headers
On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

And the 'actual behavior of its actual inputs' is DEFINED to be what
the computation the input actually does when run as an independent
machine, or what a UTM will do when simulating that input.

If that isn't the meaning you are using, then you are just lying that
you are working on the halting problem, which is what seems to be the
case. (That you are lying that is).

It is certainly true that PO is not addressing the halting problem.  He
has been 100% clear that false is, in his "opinion", the correct result
for at least one halting computation.  This is not in dispute (unless
he's retracted that and I missed it).


THIS POINT ADDRESSES THE KEY QUESTION
Which state does Ĥ applied to ⟨Ĥ⟩ transition to correctly ?


The following simplifies the syntax for the definition of the Linz Turing machine Ĥ, it is now a single machine with a single start state. A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

There are no finite number of steps of the pure simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by embedded_H such that this simulated input meets the Linz definition of halting:

computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)

Therefore it is correct to say that the input to embedded_H specifies a sequence of configurations that never halts.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

To you and I, this means that he's not working on the halting problem,
but I am not sure you can say he is lying about that.  For one thing,
how can he be intending to deceive (a core part of lying) when he's been
clear the he accepts the wrong answer as being the right one?  If
someone claims to be working on "the addition problem", and also claims
that 2+2=5 is correct, it's hard to consider either claim to be a lie.
The person is just deeply confused.

But what sort of confused can explain this nonsense?  I think the answer
lies in PO's background.  The "binary square root" function is not
computable as far as a mathematician is concerned because no TM can halt
with, say, sqrt(0b10) on the tape.  But to an engineer, the function
poses no problem because we can get as close as we like.  If
0b1.01101010000 is not good enough, just add more digits.

The point is I think PO does not know what a formal, mathematical
problem really is.  To him, anything about code, machines or programs is
about solving an engineering problem "well enough" -- with "well enough"
open to be defined by PO himself.

More disturbing to me is that he is not even talking about Turing
machines, again as evidenced by his own plain words.  It is not in
dispute that he claims that two (deterministic) TMs, one an identical
copy of the other, can transition to different states despite both being
presented with identical input.  These are not Turing machines but Magic
machines, and I can't see how any discussion can be had while the action
of the things being considered is not a simple function of the input and
the state transition graph.


THIS POINT ADDRESSES A SIDE ISSUE NOT RELEVANT TO THE KEY QUESTION:
What are the details of how ⟨Ĥ⟩ applied to ⟨Ĥ⟩ behaves?



H and embedded_H are not identical, one has an infinite loop appended to its accept state.

I will not tolerate digression into this side issue until after mutual agreement is achieved on the first point. Until then these side issues are no more than a dishonest dodge distraction away from the main point.


This is why I stopped replying.  While there are things to say about
PO's Other Halting problem (principally that even the POOH problem can't
be solved), I had nothing more to say while the "machines" being
discussed are magic.



--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sun, 30 Jan 2022 15:32 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!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: Sun, 30 Jan 2022 09:32:27 -0600
Date: Sun, 30 Jan 2022 09:32:26 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st62tu$f6h$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <LCwJJ.50318$gX.12924@fx40.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com>
Lines: 108
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Z78/x3nXMocqJXGOWt06yTkPvDApB8G8FPFYCH0Fb2jNPT0lG8kROvWKpORA1mF1JkzJt86cpukO4N9!bxOKyxQmO1HoPQK4avvqm5ilOQ1JvlKGVL/iZ6xPzWXkasMQRy6r9GaIOU4+SdqRAefC3nJsMKjI
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: 7439
View all headers
On 1/30/2022 7:44 AM, Richard Damon wrote:
On 1/30/22 8:13 AM, olcott wrote:
On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

And the 'actual behavior of its actual inputs' is DEFINED to be what
the computation the input actually does when run as an independent
machine, or what a UTM will do when simulating that input.

If that isn't the meaning you are using, then you are just lying that
you are working on the halting problem, which is what seems to be the
case. (That you are lying that is).

It is certainly true that PO is not addressing the halting problem.  He
has been 100% clear that false is, in his "opinion", the correct result
for at least one halting computation.  This is not in dispute (unless
he's retracted that and I missed it).

To you and I, this means that he's not working on the halting problem,
but I am not sure you can say he is lying about that.  For one thing,
how can he be intending to deceive (a core part of lying) when he's been
clear the he accepts the wrong answer as being the right one?  If
someone claims to be working on "the addition problem", and also claims
that 2+2=5 is correct, it's hard to consider either claim to be a lie.
The person is just deeply confused.

But what sort of confused can explain this nonsense?  I think the answer
lies in PO's background.  The "binary square root" function is not
computable as far as a mathematician is concerned because no TM can halt
with, say, sqrt(0b10) on the tape.  But to an engineer, the function
poses no problem because we can get as close as we like.  If
0b1.01101010000 is not good enough, just add more digits.

The point is I think PO does not know what a formal, mathematical
problem really is.  To him, anything about code, machines or programs is
about solving an engineering problem "well enough" -- with "well enough"
open to be defined by PO himself.

More disturbing to me is that he is not even talking about Turing
machines, again as evidenced by his own plain words.  It is not in
dispute that he claims that two (deterministic) TMs, one an identical
copy of the other, can transition to different states despite both being
presented with identical input.  These are not Turing machines but Magic
machines, and I can't see how any discussion can be had while the action
of the things being considered is not a simple function of the input and
the state transition graph.


Although Turing machines might not be able to tell that two computations differ on their basis of their machine address x86 machines can do this.

But the proof is on Turing Machines, and not all x86 'programs' are the equivalent to Turing Machines, only those that meet the requirements of being a Computation.

This seems to be the core of your problem, you don't understand what a computation actually is, and want to use the WRONG definition of it being anything a modern computer does. Wrong defintions, wrong results.


When a halt decider bases its halt status decision on the behavior of the correct simulation of a finite number of N steps of its input there is nothing about this that is not a computation.

When this simulating halt decider correctly determines that its simulated input cannot possibly reach its final state in any finite number of steps this too is computable.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

When the copy of H embedded at Ĥ.qx correctly recognizes this repeating pattern:

When Ĥ is applied to ⟨Ĥ⟩
   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

This too is a computation.

When embedded_H correctly recognizes the above repeating pattern then this gives embedded_H the basis to know that its simulated input will never reach its final state thus fails to meet this Linz definition of halting: computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234).

The source of the errors of everyone else on this is failing to realize that:

Because all simulating halt deciders are deciders they are only accountable for computing the mapping from their input finite strings to an accept or reject state on the basis of whether or not their correctly simulated input can possibly reach its final state in any finite number of steps.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sun, 30 Jan 2022 17:05 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 25 26
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: Sun, 30 Jan 2022 11:05:11 -0600
Date: Sun, 30 Jan 2022 11:05:10 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <ssue1i$81l$1@dont-email.me>
<AfGIJ.3844$dV.1984@fx44.iad> <sOSdnaE1LMP1qG78nZ2dnUU7-L3NnZ2d@giganews.com>
<UHGIJ.15876$mS1.15729@fx10.iad>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st62tu$f6h$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
<UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com> <_bzJJ.7760$rU.4222@fx34.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <_bzJJ.7760$rU.4222@fx34.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
Lines: 116
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Hwpsx6Yi8dygfjBGmby6b9otIJ+OdxcW63BD5KrsL7YL56oPF9XdIFwn3n5CblSdvyHFhoBRLCs6RI8!oI8iJ6tE+ONwWjE5YmkQgYKnN5QYvMlv5xff15Q84vjaTL04HAEMMU3lZGbuQ7IrZR4DUHnA9TB2
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: 7428
View all headers
On 1/30/2022 10:40 AM, Richard Damon wrote:
On 1/30/22 10:32 AM, olcott wrote:
On 1/30/2022 7:44 AM, Richard Damon wrote:
On 1/30/22 8:13 AM, olcott wrote:
On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

And the 'actual behavior of its actual inputs' is DEFINED to be what
the computation the input actually does when run as an independent
machine, or what a UTM will do when simulating that input.

If that isn't the meaning you are using, then you are just lying that
you are working on the halting problem, which is what seems to be the
case. (That you are lying that is).

It is certainly true that PO is not addressing the halting problem.  He
has been 100% clear that false is, in his "opinion", the correct result
for at least one halting computation.  This is not in dispute (unless
he's retracted that and I missed it).

To you and I, this means that he's not working on the halting problem,
but I am not sure you can say he is lying about that.  For one thing,
how can he be intending to deceive (a core part of lying) when he's been
clear the he accepts the wrong answer as being the right one?  If
someone claims to be working on "the addition problem", and also claims
that 2+2=5 is correct, it's hard to consider either claim to be a lie.
The person is just deeply confused.

But what sort of confused can explain this nonsense?  I think the answer
lies in PO's background.  The "binary square root" function is not
computable as far as a mathematician is concerned because no TM can halt
with, say, sqrt(0b10) on the tape.  But to an engineer, the function
poses no problem because we can get as close as we like.  If
0b1.01101010000 is not good enough, just add more digits.

The point is I think PO does not know what a formal, mathematical
problem really is.  To him, anything about code, machines or programs is
about solving an engineering problem "well enough" -- with "well enough"
open to be defined by PO himself.

More disturbing to me is that he is not even talking about Turing
machines, again as evidenced by his own plain words.  It is not in
dispute that he claims that two (deterministic) TMs, one an identical
copy of the other, can transition to different states despite both being
presented with identical input.  These are not Turing machines but Magic
machines, and I can't see how any discussion can be had while the action
of the things being considered is not a simple function of the input and
the state transition graph.


Although Turing machines might not be able to tell that two computations differ on their basis of their machine address x86 machines can do this.

But the proof is on Turing Machines, and not all x86 'programs' are the equivalent to Turing Machines, only those that meet the requirements of being a Computation.

This seems to be the core of your problem, you don't understand what a computation actually is, and want to use the WRONG definition of it being anything a modern computer does. Wrong defintions, wrong results.


When a halt decider bases its halt status decision on the behavior of the correct simulation of a finite number of N steps of its input there is nothing about this that is not a computation.

Except that that is the WRONG definition of Halting. You can NOT accurate determine halting with only FIXED number N of steps.


This is a stupid mistake on your part.

It is dead obvious that the correct simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by embedded_H shows an infinitely repeating pattern in less than four simulation cycles.

That you deny things that are dead obvious is what I call your mistakes stupid mistakes rather than simply mistakes.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

When the copy of H embedded at Ĥ.qx correctly recognizes this repeating pattern:

When Ĥ is applied to ⟨Ĥ⟩
   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3


--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Sun, 30 Jan 2022 20:09 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 25 26
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: Sun, 30 Jan 2022 14:09:23 -0600
Date: Sun, 30 Jan 2022 14:09:17 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me>
<Q-qdnbZG2LyroG78nZ2dnUU7-LfNnZ2d@giganews.com>
<_2IIJ.42013$i%.2716@fx04.iad>
<j7qdnfXC79Kv0m78nZ2dnUU7-UWdnZ2d@giganews.com> <dsIIJ.28249$XU.692@fx38.iad>
<F5udnWZWAajYx278nZ2dnUU7-dfNnZ2d@giganews.com>
<g%IIJ.21397$1_.9729@fx37.iad> <ssvnfc$4lt$2@dont-email.me>
<vEJIJ.5949$rU.2844@fx34.iad> <n42dnQN47syP9W78nZ2dnUU7-LXNnZ2d@giganews.com>
<d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st62tu$f6h$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
<UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com> <_bzJJ.7760$rU.4222@fx34.iad>
<gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
<d5AJJ.57716$4C3.3626@fx13.iad>
<g6WdndvEcI0PeWv8nZ2dnUU7-VPNnZ2d@giganews.com>
<gVBJJ.317834$qz4.289863@fx97.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <gVBJJ.317834$qz4.289863@fx97.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
Lines: 191
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-vLqVUpfayTLbXXXxUQOBs+9YsvvTfPpKgLAqYY/bzMsj2o/lG5zoEcwEl4uivSqKw0ahWoaW6iAvqBT!3cTVT81iLcalYXLzKGhTX1pAAyA3AGDwbjOolrHuPW/MpFJWdfQ52COU3riLWjSYnXy1GCiJgX/b
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: 10908
View all headers
On 1/30/2022 1:45 PM, Richard Damon wrote:
On 1/30/22 2:18 PM, olcott wrote:
On 1/30/2022 11:41 AM, Richard Damon wrote:
On 1/30/22 12:05 PM, olcott wrote:
On 1/30/2022 10:40 AM, Richard Damon wrote:
On 1/30/22 10:32 AM, olcott wrote:
On 1/30/2022 7:44 AM, Richard Damon wrote:
On 1/30/22 8:13 AM, olcott wrote:
On 1/29/2022 11:34 AM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

And the 'actual behavior of its actual inputs' is DEFINED to be what
the computation the input actually does when run as an independent
machine, or what a UTM will do when simulating that input.

If that isn't the meaning you are using, then you are just lying that
you are working on the halting problem, which is what seems to be the
case. (That you are lying that is).

It is certainly true that PO is not addressing the halting problem.  He
has been 100% clear that false is, in his "opinion", the correct result
for at least one halting computation.  This is not in dispute (unless
he's retracted that and I missed it).

To you and I, this means that he's not working on the halting problem,
but I am not sure you can say he is lying about that.  For one thing,
how can he be intending to deceive (a core part of lying) when he's been
clear the he accepts the wrong answer as being the right one?  If
someone claims to be working on "the addition problem", and also claims
that 2+2=5 is correct, it's hard to consider either claim to be a lie.
The person is just deeply confused.

But what sort of confused can explain this nonsense?  I think the answer
lies in PO's background.  The "binary square root" function is not
computable as far as a mathematician is concerned because no TM can halt
with, say, sqrt(0b10) on the tape.  But to an engineer, the function
poses no problem because we can get as close as we like.  If
0b1.01101010000 is not good enough, just add more digits.

The point is I think PO does not know what a formal, mathematical
problem really is.  To him, anything about code, machines or programs is
about solving an engineering problem "well enough" -- with "well enough"
open to be defined by PO himself.

More disturbing to me is that he is not even talking about Turing
machines, again as evidenced by his own plain words.  It is not in
dispute that he claims that two (deterministic) TMs, one an identical
copy of the other, can transition to different states despite both being
presented with identical input.  These are not Turing machines but Magic
machines, and I can't see how any discussion can be had while the action
of the things being considered is not a simple function of the input and
the state transition graph.


Although Turing machines might not be able to tell that two computations differ on their basis of their machine address x86 machines can do this.

But the proof is on Turing Machines, and not all x86 'programs' are the equivalent to Turing Machines, only those that meet the requirements of being a Computation.

This seems to be the core of your problem, you don't understand what a computation actually is, and want to use the WRONG definition of it being anything a modern computer does. Wrong defintions, wrong results.


When a halt decider bases its halt status decision on the behavior of the correct simulation of a finite number of N steps of its input there is nothing about this that is not a computation.

Except that that is the WRONG definition of Halting. You can NOT accurate determine halting with only FIXED number N of steps.


This is a stupid mistake on your part.

It is dead obvious that the correct simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by embedded_H shows an infinitely repeating pattern in less than four simulation cycles.

That you deny things that are dead obvious is what I call your mistakes stupid mistakes rather than simply mistakes.

You need to use the right definition, based on the Halting Problem.


computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)

Right, NOT "When a halt decider bases its halt status decision on the behavior of the correct simulation of a finite number of N steps of its input there is nothing about this that is not a computation."

We need to look at the ACTUAL TURING MACHINE, even if you want to call that comming in the 'back door;

Because all simulating halt deciders are deciders they are only accountable for computing the mapping from their input finite strings to an accept or reject state on the basis of whether or not their correct simulation of this input can possibly reach the final state of this simulated input in any finite number of steps.


The fact that you need to change it just proves that your haven't got a prayer with the right definitions.

NOTHING in the actual definition mentions anything about the behavior of the decider in determining if the computation actually halts.

In fact, if you knew the first thing of Computation Theory, you would know that such a definition that includes that would actually be IMPOSSIBLE, as Halting is a Property of the Computation itself, and needs to be the same no matter what decider tries to decide on it.

The fact that you rely on things that seem 'dead obvious' to you shows that you just don't understand how actual logic and proofs work. You don't start with things that are 'obvious', you start with the things DEFINED to be true, and the things that have been proven to be true based on those definition.

Using the 'obvious' is one of the biggest sources of fallacies.


We can show that your 'claim' is not true, at least for a H that aborts its simulation and goes to H.Qn,

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

So in other words you believe that when embedded_H aborts the simulation of its input that this aborted input transitions to ⟨Ĥ⟩.qn even though it has been aborted?


You mincing your words again.

The DEFINITION of the operation that determines the 'Halting Behavior of the Input', is the ACTUAL RUNNING OF THE MACHINE REPRESENTED BY THE INPUT.

That machine does not halt just because H/embedded_H aborts its simulation of its input.

So, YES, when embedded_H aborts ITS PARTIAL simulation of its input, that the ACTUAL MACHINE it represents will continue on to H^.Qn.
Because all simulating halt deciders are deciders they are only accountable for computing the mapping from their input finite strings to an accept or reject state on the basis of whether or not their correct simulation of this input can possibly reach the final state of this simulated input in any finite number of steps.

It is like you put a guard on the front door that is supposed to report anyone coming in the front door (the actual inputs). Then someone comes in the back door (non inputs) and the guard does not report this. Since the guard is only supposed to report people coming in the front door it is incorrect to say that the guard made a mistake by not reporting people that came in the back door.

embedded_H is not supposed to report on the halt status of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩.


--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, sci.logic, sci.math, comp.ai.philosophy
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Mon, 31 Jan 2022 00:21 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 25
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math,comp.ai.philosophy
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Followup-To: comp.theory
Date: Sun, 30 Jan 2022 18:21:31 -0600
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <st7a2e$oo$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me> <d2KIJ.24507$541.2175@fx35.iad>
<4KSdnY1xDqmF8m78nZ2dnUU7-dnNnZ2d@giganews.com>
<QRKIJ.10111$uP.9595@fx16.iad>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st62tu$f6h$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
<UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com> <_bzJJ.7760$rU.4222@fx34.iad>
<gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
<d5AJJ.57716$4C3.3626@fx13.iad>
<g6WdndvEcI0PeWv8nZ2dnUU7-VPNnZ2d@giganews.com>
<gVBJJ.317834$qz4.289863@fx97.iad>
<a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
<mWCJJ.57596$zV.23696@fx43.iad>
<ZrSdnQfr6bvYnGr8nZ2dnUU7-UvNnZ2d@giganews.com>
<osEJJ.11004$uP.10312@fx16.iad>
<9P6dnTtqj-DZhmr8nZ2dnUU7-VnNnZ2d@giganews.com>
<ecFJJ.19021$mS1.7877@fx10.iad>
<sMCdnTPlr-FDvWr8nZ2dnUU7-KXNnZ2d@giganews.com>
<7FFJJ.29151$541.18496@fx35.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Jan 2022 00:21:34 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e4aef017c60113144c86a33a4df4f7d0";
logging-data="792"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+PrPZmbTqxLYHYzDnnelHg"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:OtYwhKhkWeL0jOFm3n+dIGTklEE=
In-Reply-To: <7FFJJ.29151$541.18496@fx35.iad>
Content-Language: en-US
View all headers
On 1/30/2022 6:01 PM, Richard Damon wrote:
On 1/30/22 6:35 PM, olcott wrote:
On 1/30/2022 5:30 PM, Richard Damon wrote:
On 1/30/22 6:12 PM, olcott wrote:
On 1/30/2022 4:39 PM, Richard Damon wrote:
On 1/30/22 4:21 PM, olcott wrote:
On 1/30/2022 2:54 PM, Richard Damon wrote:
On 1/30/22 3:09 PM, olcott wrote:

Because all simulating halt deciders are deciders they are only accountable for computing the mapping from their input finite strings to an accept or reject state on the basis of whether or not their correct simulation of this input can possibly reach the final state of this simulated input in any finite number of steps.

It is like you put a guard on the front door that is supposed to report anyone coming in the front door (the actual inputs). Then someone comes in the back door (non inputs) and the guard does not report this. Since the guard is only supposed to report people coming in the front door it is incorrect to say that the guard made a mistake by not reporting people that came in the back door.

embedded_H is not supposed to report on the halt status of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩.



So, you have just admitted that you aren't working on the Halting Problem, so any claims therein are just lies.

Since the definition of the Halting Problem refers to the ACTUAL behavior of the machine the input represents, and NOT the partial simulation that some simulating halt decider might do, you are admitting that you H is NOT using the Halting Problem definition and thus your claims that your results apply to the Halting problem are just lies.

For the Halting Problem, the correct results for the inputs is based on the actual behavior of the machine, or its equivalent the simulation of the input with a REAL UTM. Thus the 'Front Door' to the problem s based on that, so either you your guards are lying or, what seems more likely, you posted them to the wrong door.

You have basically just proved that you have totally wasted the last years of your life, as you have been working on the wrong problem, because you just don't understand what the problem you wanted to solve actually was.

FAIL.

Sum(int X, int Y) { return X + Y );

It is true that halt deciders must report on the actual behavior of their actual inputs in the same way that Sum(2,5) must return 7.

Right, and the correct answer for if H(wM, w) should report halting is if M x will reach a final state in a finite number of steps. This is identical to if UTM(wM, w) will halt. Dosn't matter what you think otherwise, that IS the definition of the actual behavior.

It is NOT something based on the partial simulation that H does.


The you cannot understand how all kinds of infinite behavior patterns can be easily recognized in a finite number of steps is not any mistake on my part:

Yes, MANY can, but not ALL.

If you need to change the definition, then you are not working on the halting problem.



I don't have to change the definition I merely make it much more precise:

Except that the original definition IS exactly precise. The is a single WELL DEFINED answer for any instance of the question. The fact that you see some abiguity just shows you don't really understand the field.


(1) Halting is defined as reaching a final state.

But you change the 'of what'.

A directly executed TM halts when it reaches the final state of this directly executed TM.

A simulated TM description halts when the simulated TM description reaches it final state.

If you weren't focused on rebuttal and instead focused on truth you would have agreed to this long ago.

(2) Halt deciders like all deciders can and must ignore everything that is not a direct input.


And the 'direct input' of <H^> <H^> directly refers to the computation of H^ applied to <H^> by DEFINITION.


Stupidly WRONG !!!

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The direct input to embedded_H is ⟨Ĥ⟩ ⟨Ĥ⟩ and is not Ĥ applied to ⟨Ĥ⟩.

If you weren't focused on rebuttal and instead focused on truth you would have agreed to this long ago.


--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Mon, 31 Jan 2022 16:06 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 25 26
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Followup-To: comp.theory
Date: Mon, 31 Jan 2022 10:06:42 -0600
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <st91ek$p4g$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st62tu$f6h$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
<UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com> <_bzJJ.7760$rU.4222@fx34.iad>
<gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
<d5AJJ.57716$4C3.3626@fx13.iad>
<g6WdndvEcI0PeWv8nZ2dnUU7-VPNnZ2d@giganews.com>
<gVBJJ.317834$qz4.289863@fx97.iad>
<a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
<mWCJJ.57596$zV.23696@fx43.iad>
<ZrSdnQfr6bvYnGr8nZ2dnUU7-UvNnZ2d@giganews.com>
<osEJJ.11004$uP.10312@fx16.iad>
<9P6dnTtqj-DZhmr8nZ2dnUU7-VnNnZ2d@giganews.com>
<ecFJJ.19021$mS1.7877@fx10.iad>
<sMCdnTPlr-FDvWr8nZ2dnUU7-KXNnZ2d@giganews.com>
<7FFJJ.29151$541.18496@fx35.iad> <st7a2e$oo$1@dont-email.me>
<ibHJJ.56320$u41.55552@fx41.iad>
<hK-dnaKCNvKd2Wr8nZ2dnUU7-fPNnZ2d@giganews.com>
<gIHJJ.29153$541.4042@fx35.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Jan 2022 16:06:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e4aef017c60113144c86a33a4df4f7d0";
logging-data="25744"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+7ul4OmT0oKgRYIPDx1emG"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:I2MIm3+Ip4ineUetVETXZyie+6k=
In-Reply-To: <gIHJJ.29153$541.4042@fx35.iad>
Content-Language: en-US
View all headers
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:


Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

These statements need the conditions, that H^ goes to H^.Qy/H^.Qn iff H goes to that corresponding state.


⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H in the same way that (5,3) is syntactically specified as an input to Sum(5,3)

Right, and the


Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to embedded_H in the same way that (1,2) is NOT syntactically specified as an input to Sum(5,3)


Right, but perhaps you don't understand that from you above statement the right answer is based on if UTM(<H^>,<H^>) Halts which by the definition of a UTM means if H^ applied to <H^> Halts.


The biggest reason for your huge mistakes is that you cannot stay sharply focused on a single point. It is as if you either have attention deficit disorder ADD or are addicted to methamphetamine.

 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.

After we have mutual agreement on this point we will move on to the points that logically follow from this one.


--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ error or dishonesty ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Mon, 31 Jan 2022 16:53 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 25 26
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Concise refutation of halting problem proofs V52 [ error or
dishonesty ]
Followup-To: comp.theory
Date: Mon, 31 Jan 2022 10:53:45 -0600
Organization: A noiseless patient Spider
Lines: 184
Message-ID: <st946r$oq0$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me>
<v8udnTw-8aE_4G78nZ2dnUU7-cnNnZ2d@giganews.com>
<mIQIJ.34880$%T.27606@fx06.iad>
<2ZqdnX-fD72xnWn8nZ2dnUU7-LHNnZ2d@giganews.com>
<Ol0JJ.27499$541.4855@fx35.iad> <875yq2h2ea.fsf@bsb.me.uk>
<st62tu$f6h$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
<UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com> <_bzJJ.7760$rU.4222@fx34.iad>
<gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
<d5AJJ.57716$4C3.3626@fx13.iad>
<g6WdndvEcI0PeWv8nZ2dnUU7-VPNnZ2d@giganews.com>
<gVBJJ.317834$qz4.289863@fx97.iad>
<a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
<mWCJJ.57596$zV.23696@fx43.iad>
<ZrSdnQfr6bvYnGr8nZ2dnUU7-UvNnZ2d@giganews.com>
<osEJJ.11004$uP.10312@fx16.iad>
<9P6dnTtqj-DZhmr8nZ2dnUU7-VnNnZ2d@giganews.com>
<ecFJJ.19021$mS1.7877@fx10.iad>
<sMCdnTPlr-FDvWr8nZ2dnUU7-KXNnZ2d@giganews.com>
<7FFJJ.29151$541.18496@fx35.iad> <st7a2e$oo$1@dont-email.me>
<ibHJJ.56320$u41.55552@fx41.iad>
<hK-dnaKCNvKd2Wr8nZ2dnUU7-fPNnZ2d@giganews.com>
<gIHJJ.29153$541.4042@fx35.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Jan 2022 16:53:47 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e4aef017c60113144c86a33a4df4f7d0";
logging-data="25408"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/veMeeTf1j0mtNRWVZIU1W"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:KOR0ov/ToMLHMbgp9opfiKNP+88=
In-Reply-To: <gIHJJ.29153$541.4042@fx35.iad>
Content-Language: en-US
View all headers
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:
On 1/30/2022 7:45 PM, Richard Damon wrote:
On 1/30/22 7:21 PM, olcott wrote:
On 1/30/2022 6:01 PM, Richard Damon wrote:
On 1/30/22 6:35 PM, olcott wrote:
On 1/30/2022 5:30 PM, Richard Damon wrote:
On 1/30/22 6:12 PM, olcott wrote:
On 1/30/2022 4:39 PM, Richard Damon wrote:
On 1/30/22 4:21 PM, olcott wrote:
On 1/30/2022 2:54 PM, Richard Damon wrote:
On 1/30/22 3:09 PM, olcott wrote:

Because all simulating halt deciders are deciders they are only accountable for computing the mapping from their input finite strings to an accept or reject state on the basis of whether or not their correct simulation of this input can possibly reach the final state of this simulated input in any finite number of steps.

It is like you put a guard on the front door that is supposed to report anyone coming in the front door (the actual inputs). Then someone comes in the back door (non inputs) and the guard does not report this. Since the guard is only supposed to report people coming in the front door it is incorrect to say that the guard made a mistake by not reporting people that came in the back door.

embedded_H is not supposed to report on the halt status of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩.



So, you have just admitted that you aren't working on the Halting Problem, so any claims therein are just lies.

Since the definition of the Halting Problem refers to the ACTUAL behavior of the machine the input represents, and NOT the partial simulation that some simulating halt decider might do, you are admitting that you H is NOT using the Halting Problem definition and thus your claims that your results apply to the Halting problem are just lies.

For the Halting Problem, the correct results for the inputs is based on the actual behavior of the machine, or its equivalent the simulation of the input with a REAL UTM. Thus the 'Front Door' to the problem s based on that, so either you your guards are lying or, what seems more likely, you posted them to the wrong door.

You have basically just proved that you have totally wasted the last years of your life, as you have been working on the wrong problem, because you just don't understand what the problem you wanted to solve actually was.

FAIL.

Sum(int X, int Y) { return X + Y );

It is true that halt deciders must report on the actual behavior of their actual inputs in the same way that Sum(2,5) must return 7.

Right, and the correct answer for if H(wM, w) should report halting is if M x will reach a final state in a finite number of steps. This is identical to if UTM(wM, w) will halt. Dosn't matter what you think otherwise, that IS the definition of the actual behavior.

It is NOT something based on the partial simulation that H does.


The you cannot understand how all kinds of infinite behavior patterns can be easily recognized in a finite number of steps is not any mistake on my part:

Yes, MANY can, but not ALL.

If you need to change the definition, then you are not working on the halting problem.



I don't have to change the definition I merely make it much more precise:

Except that the original definition IS exactly precise. The is a single WELL DEFINED answer for any instance of the question. The fact that you see some abiguity just shows you don't really understand the field.


(1) Halting is defined as reaching a final state.

But you change the 'of what'.

A directly executed TM halts when it reaches the final state of this directly executed TM.

A simulated TM description halts when the simulated TM description reaches it final state.


Right, but if the simulator isn't a real UTM and stops simulating, the 'pure simulation' continues until it either halts or runs for ever.


H.q0 Wm W ⊢* H.qy
iff UTM Wm W reaches its final state

H.q0 Wm W ⊢* H.qn
iff UTM Wm W never reaches its final state


Right, and that is the REAL UTM, not H playing one on TV and stopping when it thinks it has an answer.
As your scatterbrained mind keep repeating....
Yet I have kept correcting. It is not necessary for a simulating halt decider to execute an infinite number of steps of an infinite sequence of configurations for it to determine that a pure simulation of its input would never stop running.

_Infinite_Loop()
[00000946](01)  55              push ebp
[00000947](02)  8bec            mov ebp,esp
[00000949](02)  ebfe            jmp 00000949
[0000094b](01)  5d              pop ebp
[0000094c](01)  c3              ret
Size in bytes:(0007) [0000094c]

It is self-evident that the second time the instruction at [00000949] is executed with no other instructions inbetween an infinite loop has been recognized.



_Infinite_Recursion()
[00000926](01)  55              push ebp
[00000927](02)  8bec            mov ebp,esp
[00000929](03)  8b4508          mov eax,[ebp+08]
[0000092c](01)  50              push eax
[0000092d](05)  e8f4ffffff      call 00000926
[00000932](03)  83c404          add esp,+04
[00000935](01)  5d              pop ebp
[00000936](01)  c3              ret
Size in bytes:(0017) [00000936]

Begin Local Halt Decider Simulation   Execution Trace Stored at:211356

  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00000926][00211342][00211346] 55         push ebp
[00000927][00211342][00211346] 8bec       mov  ebp,esp
[00000929][00211342][00211346] 8b4508     mov  eax,[ebp+08]
[0000092c][0021133e][00000777] 50         push eax
[0000092d][0021133a][00000932] e8f4ffffff call 00000926
[00000926][00211336][00211342] 55         push ebp
[00000927][00211336][00211342] 8bec       mov  ebp,esp
[00000929][00211336][00211342] 8b4508     mov  eax,[ebp+08]
[0000092c][00211332][00000777] 50         push eax
[0000092d][0021132e][00000932] e8f4ffffff call 00000926
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is self-evident that the second time the instruction at [0000092d] is executed with with the same input infinite recursion has been recognized.



It is self evident that when Ĥ is applied to ⟨Ĥ⟩ simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never transitions to ⟨Ĥ⟩.qn.

When Ĥ is applied to ⟨Ĥ⟩
   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...


--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ dishonesty ! ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Tue, 1 Feb 2022 03:40 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 25 26
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Concise refutation of halting problem proofs V52 [ dishonesty ! ]
Followup-To: comp.theory
Date: Mon, 31 Jan 2022 21:40:47 -0600
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <staa42$dgq$1@dont-email.me>
References: <ssh8vu$4c0$1@dont-email.me> <875yq2h2ea.fsf@bsb.me.uk>
<st62tu$f6h$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
<UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com> <_bzJJ.7760$rU.4222@fx34.iad>
<gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
<d5AJJ.57716$4C3.3626@fx13.iad>
<g6WdndvEcI0PeWv8nZ2dnUU7-VPNnZ2d@giganews.com>
<gVBJJ.317834$qz4.289863@fx97.iad>
<a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
<mWCJJ.57596$zV.23696@fx43.iad>
<ZrSdnQfr6bvYnGr8nZ2dnUU7-UvNnZ2d@giganews.com>
<osEJJ.11004$uP.10312@fx16.iad>
<9P6dnTtqj-DZhmr8nZ2dnUU7-VnNnZ2d@giganews.com>
<ecFJJ.19021$mS1.7877@fx10.iad>
<sMCdnTPlr-FDvWr8nZ2dnUU7-KXNnZ2d@giganews.com>
<7FFJJ.29151$541.18496@fx35.iad> <st7a2e$oo$1@dont-email.me>
<ibHJJ.56320$u41.55552@fx41.iad>
<hK-dnaKCNvKd2Wr8nZ2dnUU7-fPNnZ2d@giganews.com>
<gIHJJ.29153$541.4042@fx35.iad> <st91ek$p4g$1@dont-email.me>
<st9fn6$60s$2@gioia.aioe.org> <RqidnSdLIdwH2GX8nZ2dnUU7-SXNnZ2d@giganews.com>
<Kk%JJ.20609$OF3.19827@fx14.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 1 Feb 2022 03:40:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="28983ca16e79dc928ce542fd236fedda";
logging-data="13850"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19iqMXDxnfN1EWVrcFjrmUk"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Cancel-Lock: sha1:KvN8EvaXqojPL7bpN8t2VNLAzyE=
In-Reply-To: <Kk%JJ.20609$OF3.19827@fx14.iad>
Content-Language: en-US
View all headers
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:


Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

These statements need the conditions, that H^ goes to H^.Qy/H^.Qn iff H goes to that corresponding state.


⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H in the same way that (5,3) is syntactically specified as an input to Sum(5,3)

Right, and the


Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to embedded_H in the same way that (1,2) is NOT syntactically specified as an input to Sum(5,3)


Right, but perhaps you don't understand that from you above statement the right answer is based on if UTM(<H^>,<H^>) Halts which by the definition of a UTM means if H^ applied to <H^> Halts.


The biggest reason for your huge mistakes is that you cannot stay sharply focused on a single point. It is as if you either have attention deficit disorder ADD or are addicted to methamphetamine.

 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.

After we have mutual agreement on this point we will move on to the points that logically follow from this one.


Holy shit try to post something that makes sense.


Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Richard does not accept that the input to the copy of Linz H embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.



No, but apparently you can't understand actual English words.

The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must give is based on the behavior of H^ applied to <H^> BECAUSE OF THE DEFINITION of H.

In other words Sum(3,5) must return the value of Sum(7,8)?

Any moron knows that a function is only accountable for its actual inputs.

embedded_H is only accountable for the actual behavior specified by its actual inputs ⟨Ĥ⟩ ⟨Ĥ⟩.

Since the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx cannot possibly transition to its final state: ⟨Ĥ⟩.qn we know that this input never halts even if it stops running.

computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)



--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer


Subject: Re: Concise refutation of halting problem proofs V52 [ ignorance? ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Tue, 1 Feb 2022 04:24 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 25 26
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: Mon, 31 Jan 2022 22:24:32 -0600
Date: Mon, 31 Jan 2022 22:24:27 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ ignorance? ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <LCwJJ.50318$gX.12924@fx40.iad>
<UK-dnQx29oAWMmv8nZ2dnUU7-WvNnZ2d@giganews.com> <_bzJJ.7760$rU.4222@fx34.iad>
<gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
<d5AJJ.57716$4C3.3626@fx13.iad>
<g6WdndvEcI0PeWv8nZ2dnUU7-VPNnZ2d@giganews.com>
<gVBJJ.317834$qz4.289863@fx97.iad>
<a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
<mWCJJ.57596$zV.23696@fx43.iad>
<ZrSdnQfr6bvYnGr8nZ2dnUU7-UvNnZ2d@giganews.com>
<osEJJ.11004$uP.10312@fx16.iad>
<9P6dnTtqj-DZhmr8nZ2dnUU7-VnNnZ2d@giganews.com>
<ecFJJ.19021$mS1.7877@fx10.iad>
<sMCdnTPlr-FDvWr8nZ2dnUU7-KXNnZ2d@giganews.com>
<7FFJJ.29151$541.18496@fx35.iad> <st7a2e$oo$1@dont-email.me>
<ibHJJ.56320$u41.55552@fx41.iad>
<hK-dnaKCNvKd2Wr8nZ2dnUU7-fPNnZ2d@giganews.com>
<gIHJJ.29153$541.4042@fx35.iad> <st91ek$p4g$1@dont-email.me>
<st9fn6$60s$2@gioia.aioe.org> <RqidnSdLIdwH2GX8nZ2dnUU7-SXNnZ2d@giganews.com>
<Kk%JJ.20609$OF3.19827@fx14.iad> <staa42$dgq$1@dont-email.me>
<wv2KJ.25296$tW.1549@fx39.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <wv2KJ.25296$tW.1549@fx39.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <b_SdnVRGB-GdK2X8nZ2dnUU7-YPNnZ2d@giganews.com>
Lines: 92
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MSPD3nfE5DhEbPutxrdcdNJA/T5dLw4AFXfXh5F1+Xq7b+eiVkILBoCfTzuj5lra29va9QSSdAoSXb1!1pjDLytRSDcZV6E1rSaMgxfuIe/+SwPyKYpSMN9EcYum4xC/MEGQNpVLvey8+Ku0d18q5mLtckQ3
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: 5749
View all headers
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:


Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

These statements need the conditions, that H^ goes to H^.Qy/H^.Qn iff H goes to that corresponding state.


⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H in the same way that (5,3) is syntactically specified as an input to Sum(5,3)

Right, and the


Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to embedded_H in the same way that (1,2) is NOT syntactically specified as an input to Sum(5,3)


Right, but perhaps you don't understand that from you above statement the right answer is based on if UTM(<H^>,<H^>) Halts which by the definition of a UTM means if H^ applied to <H^> Halts.


The biggest reason for your huge mistakes is that you cannot stay sharply focused on a single point. It is as if you either have attention deficit disorder ADD or are addicted to methamphetamine.

 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.

After we have mutual agreement on this point we will move on to the points that logically follow from this one.


Holy shit try to post something that makes sense.


Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Richard does not accept that the input to the copy of Linz H embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.



No, but apparently you can't understand actual English words.

The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must give is based on the behavior of H^ applied to <H^> BECAUSE OF THE DEFINITION of H.

In other words Sum(3,5) must return the value of Sum(7,8)?

Don't know how you get that from what I said.


Any moron knows that a function is only accountable for its actual inputs.


And the actual input to H is <H^> <H^> which MEANS by the DEFINITION of the Halting Problem that H is being asked to decide on the Halting Status of H^ applied to <H^>
No that is not it. That is like saying "by definition" Sum(3,5) is being asked about Sum(7,8).

Halt decider are deciders thus are only ever accountable for the properties of their actual inputs.

The function that embedded_H computes is being asked about the actual behavior of the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ at Ĥ.qx.

--
Copyright 2021 Pete Olcott

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


Subject: Re: Concise refutation of halting problem proofs V52 [ ignorance? ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Date: Tue, 1 Feb 2022 04:42 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 25 26
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: Mon, 31 Jan 2022 22:42:57 -0600
Date: Mon, 31 Jan 2022 22:42:56 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V52 [ ignorance? ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <_bzJJ.7760$rU.4222@fx34.iad>
<gv2dneHXF-XaWGv8nZ2dnUU7-KfNnZ2d@giganews.com>
<d5AJJ.57716$4C3.3626@fx13.iad>
<g6WdndvEcI0PeWv8nZ2dnUU7-VPNnZ2d@giganews.com>
<gVBJJ.317834$qz4.289863@fx97.iad>
<a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
<mWCJJ.57596$zV.23696@fx43.iad>
<ZrSdnQfr6bvYnGr8nZ2dnUU7-UvNnZ2d@giganews.com>
<osEJJ.11004$uP.10312@fx16.iad>
<9P6dnTtqj-DZhmr8nZ2dnUU7-VnNnZ2d@giganews.com>
<ecFJJ.19021$mS1.7877@fx10.iad>
<sMCdnTPlr-FDvWr8nZ2dnUU7-KXNnZ2d@giganews.com>
<7FFJJ.29151$541.18496@fx35.iad> <st7a2e$oo$1@dont-email.me>
<ibHJJ.56320$u41.55552@fx41.iad>
<hK-dnaKCNvKd2Wr8nZ2dnUU7-fPNnZ2d@giganews.com>
<gIHJJ.29153$541.4042@fx35.iad> <st91ek$p4g$1@dont-email.me>
<st9fn6$60s$2@gioia.aioe.org> <RqidnSdLIdwH2GX8nZ2dnUU7-SXNnZ2d@giganews.com>
<Kk%JJ.20609$OF3.19827@fx14.iad> <staa42$dgq$1@dont-email.me>
<wv2KJ.25296$tW.1549@fx39.iad>
<b_SdnVRGB-GdK2X8nZ2dnUU7-YPNnZ2d@giganews.com>
<4L2KJ.23685$jb1.8458@fx46.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <4L2KJ.23685$jb1.8458@fx46.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <rv2dnc__PYfMJ2X8nZ2dnUU7-WHNnZ2d@giganews.com>
Lines: 103
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-h1gOYojHfdeAWp8KLqFO2LNdXuJCJamr4FT1oRWY96y9JJYB8iBQ0Ds4O4Bm958LcM2UcZJLJtUCQeV!E+U4Usz4OW/GATjzv3WnXxHkRkulJXAgQHDLBXR6h0FGkPGQy47xBbLRnA+OEq6JR60kUlLk8zgr
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: 6080
View all headers
On 1/31/2022 10:33 PM, Richard Damon wrote:

On 1/31/22 11:24 PM, olcott wrote:
On 1/31/2022 10:17 PM, Richard Damon wrote:
On 1/31/22 10:40 PM, olcott wrote:
On 1/31/2022 6:41 PM, Richard Damon wrote:
On 1/31/22 3:24 PM, olcott wrote:
On 1/31/2022 2:10 PM, Ben wrote:
On 1/31/2022 8:06 AM, olcott wrote:
On 1/30/2022 8:20 PM, Richard Damon wrote:
On 1/30/22 9:05 PM, olcott wrote:


Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

These statements need the conditions, that H^ goes to H^.Qy/H^.Qn iff H goes to that corresponding state.


⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H in the same way that (5,3) is syntactically specified as an input to Sum(5,3)

Right, and the


Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to embedded_H in the same way that (1,2) is NOT syntactically specified as an input to Sum(5,3)


Right, but perhaps you don't understand that from you above statement the right answer is based on if UTM(<H^>,<H^>) Halts which by the definition of a UTM means if H^ applied to <H^> Halts.


The biggest reason for your huge mistakes is that you cannot stay sharply focused on a single point. It is as if you either have attention deficit disorder ADD or are addicted to methamphetamine.

 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
 >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H and
Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.

After we have mutual agreement on this point we will move on to the points that logically follow from this one.


Holy shit try to post something that makes sense.


Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Richard does not accept that the input to the copy of Linz H embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.



No, but apparently you can't understand actual English words.

The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must give is based on the behavior of H^ applied to <H^> BECAUSE OF THE DEFINITION of H.

In other words Sum(3,5) must return the value of Sum(7,8)?

Don't know how you get that from what I said.


Any moron knows that a function is only accountable for its actual inputs.


And the actual input to H is <H^> <H^> which MEANS by the DEFINITION of the Halting Problem that H is being asked to decide on the Halting Status of H^ applied to <H^>
No that is not it. That is like saying "by definition" Sum(3,5) is being asked about Sum(7,8).

Again your RED HERRING.

H is being asked EXACTLY what it being asked

H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't

AGREED?


No that is wrong. embedded_H is being asked:
Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?

--
Copyright 2021 Pete Olcott

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


Pages:123
rocksolid light 0.7.2
clearneti2ptor