Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

One can't proceed from the informal to the formal by formal means.


devel / comp.theory / Re: Concise refutation of halting problem proofs V42 [where people get stuck]

SubjectAuthor
* Concise refutation of halting problem proofs V42 [where people getolcott
+* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
|+- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
|`* Concise refutation of halting problem proofs V42 [where peopleolcott
| +* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
| |`* Concise refutation of halting problem proofs V42 [where peopleolcott
| | +- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
| | `* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
| |  `* Concise refutation of halting problem proofs V42 [where peopleolcott
| |   +* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
| |   |+* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
| |   ||`* Concise refutation of halting problem proofs V42 [where peopleolcott
| |   || +- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
| |   || `* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
| |   ||  `* Concise refutation of halting problem proofs V42 [where peopleolcott
| |   ||   +* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
| |   ||   |`* Concise refutation of halting problem proofs V42 [where peopleolcott
| |   ||   | `- Concise refutation of halting problem proofs V42 [where people get stuck]Richard Damon
| |   ||   `- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
| |   |`* Concise refutation of halting problem proofs V42 [where peopleolcott
| |   | +* Concise refutation of halting problem proofs V42 [where peopleAndré G. Isaak
| |   | |`* Concise refutation of halting problem proofs V42 [where people get stuck]olcott
| |   | | `- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
| |   | `- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
| |   `- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
| `- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
+- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
`* Concise refutation of halting problem proofs V42 [where people get stuck]Ben Bacarisse
 +* Concise refutation of halting problem proofs V42 [where peopleolcott
 |`- Concise refutation of halting problem proofs V42 [where peopleRichard Damon
 `* Concise refutation of halting problem proofs V42 [compute theolcott
  `* Concise refutation of halting problem proofs V42 [compute theRichard Damon
   `* Concise refutation of halting problem proofs V42 [compute theolcott
    +* Concise refutation of halting problem proofs V42 [compute theAndré G. Isaak
    |+- Concise refutation of halting problem proofs V42 [compute the mapping]Julio Di Egidio
    |`* Concise refutation of halting problem proofs V42 [compute theolcott
    | `* Concise refutation of halting problem proofs V42 [compute theRichard Damon
    |  `* Concise refutation of halting problem proofs V42 [compute theolcott
    |   `* Concise refutation of halting problem proofs V42 [compute theRichard Damon
    |    `* Concise refutation of halting problem proofs V42 [ultimateolcott
    |     +* Concise refutation of halting problem proofs V42 [ultimateRichard Damon
    |     |`* Concise refutation of halting problem proofs V42 [ultimateolcott
    |     | `- Concise refutation of halting problem proofs V42 [ultimateRichard Damon
    |     `* Concise refutation of halting problem proofs V42 [ultimateAndré G. Isaak
    |      `* Concise refutation of halting problem proofs V42 [ultimateolcott
    |       +- Concise refutation of halting problem proofs V42 [ultimateRichard Damon
    |       `* Concise refutation of halting problem proofs V42 [ultimateAndré G. Isaak
    |        `* Concise refutation of halting problem proofs V42 [ultimateolcott
    |         +* Concise refutation of halting problem proofs V42 [ultimateAndré G. Isaak
    |         |+* Concise refutation of halting problem proofs V42 [ultimateolcott
    |         ||+- Concise refutation of halting problem proofs V42 [ultimateRichard Damon
    |         ||`* Concise refutation of halting problem proofs V42 [ultimateAndré G. Isaak
    |         || `* Concise refutation of halting problem proofs V42 [ultimateolcott
    |         ||  +* Concise refutation of halting problem proofs V42 [ultimateAndré G. Isaak
    |         ||  |`* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  | +* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  | |`* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  | | `* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  | |  `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  | |   `- Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  | `* Concise refutation of halting problem proofs V42 [computerAndré G. Isaak
    |         ||  |  `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |   `* Concise refutation of halting problem proofs V42 [computerAndré G. Isaak
    |         ||  |    +* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |`* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    | `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |  `* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    |   `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |    `* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    |     `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |      `* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    |       `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |        `* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    |         `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |          `* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    |           `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |            `* Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    |             `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |              `* Concise refutation of halting problem proofs V42 [computer scientist]Richard Damon
    |         ||  |    |               `* Concise refutation of halting problem proofs V42 [computerolcott
    |         ||  |    |                `- Concise refutation of halting problem proofs V42 [computerRichard Damon
    |         ||  |    +* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |`* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    | `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |  `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |   `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |    `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |     `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |      `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |       `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |        `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |         `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |          `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |           `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |            `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |             `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |              `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |               `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |                `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |                 `* Concise refutation of halting problem proofs V42 [honestolcott
    |         ||  |    |                  +- Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    |                  `* Concise refutation of halting problem proofs V42 [honestRichard Damon
    |         ||  |    `* Concise refutation of halting problem proofs V46 [computerolcott
    |         ||  `- Concise refutation of halting problem proofs V42 [ultimateRichard Damon
    |         |+- Concise refutation of halting problem proofs V42 [ultimateRichard Damon
    |         |`* Concise refutation of halting problem proofs V42 [ultimateolcott
    |         `- Concise refutation of halting problem proofs V42 [ultimateRichard Damon
    `* Concise refutation of halting problem proofs V42 [compute theRichard Damon

Pages:123456
Concise refutation of halting problem proofs V42 [where people get stuck]

<rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 10:49:53 -0600
Date: Wed, 29 Dec 2021 10:49:53 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Content-Language: en-US
From: NoO...@NoWhere.com (olcott)
Subject: Concise refutation of halting problem proofs V42 [where people get
stuck]
Followup-To: comp.theory
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
Lines: 41
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Sto8GI/iUkeNJc99iwzbVSt0yE5x6NbbgOR23B1+LrpWgMZu+L2M0zA4k5i+bGfhl/D0DF3Zs5gP6/e!pPeuSWJkuDUWOkhUiyuZOyvHBLq6rQu96PYizDzFTG+aMGt4/Swi3wVjFu4jUClmDo8fMZMEIUw+!tw==
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: 2690
 by: olcott - Wed, 29 Dec 2021 16:49 UTC

Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
Ĥ.qn on the basis of the behavior of the UTM simulation of these inputs.

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

*My criterion measure with Ben's notational conventions*
H.q0 wM w ⊢* H.qy iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn iff UTM(wM, w) does not halt

We know that H would correctly decide the halt status of its input on
the basis of correctly deciding the halt status of the UTM simulation of
its input.

We know this because a UTM simulation of the Turing machine description
is computationally equivalent to the direct execution of this same
Turing machine.

HERE IS WHERE PEOPLE GET STUCK
HERE IS WHERE PEOPLE GET STUCK
HERE IS WHERE PEOPLE GET STUCK

We know that the copy of H is at Ĥ.qx (AKA embedded_H) applies this same
criterion measure to every instance of embedded_H to any recursive depth.

If the UTM simulation of the input to any embedded_H would never stop
running without being aborted by this embedded_H then this embedded_H
has met its non-halting criteria.

https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (315-320)

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<sqi88u$ai9$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Date: Wed, 29 Dec 2021 11:09:32 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 78
Message-ID: <sqi88u$ai9$1@dont-email.me>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 29 Dec 2021 18:09:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="93859a21b83bba53cad11e036d0d03fd";
logging-data="10825"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/y0glDIzP75813jlVzisnt"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:Gl4dKq0F2ODMdojnlm96Uwq/bhk=
In-Reply-To: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Wed, 29 Dec 2021 18:09 UTC

On 2021-12-29 09:49, olcott wrote:
> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
> Ĥ.qn on the basis of the behavior of the UTM simulation of these inputs.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Those should be:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt

Why do you insist on omitting the conditions in the above? They are just
as mandatory for Ĥ as they are for H.

> *My criterion measure with Ben's notational conventions*
> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>
> We know that H would correctly decide the halt status of its input on
> the basis of correctly deciding the halt status of the UTM simulation of
> its input.

Right. What that means in that H applied to wM w should transition to
H.qy in exactly those cases where the *independent* computation UTM(wM,
w) halts.

That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.

And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.

> We know this because a UTM simulation of the Turing machine description
> is computationally equivalent to the direct execution of this same
> Turing machine.
>
> HERE IS WHERE PEOPLE GET STUCK
> HERE IS WHERE PEOPLE GET STUCK
> HERE IS WHERE PEOPLE GET STUCK

You are the only one who is stuck.

> We know that the copy of H is at Ĥ.qx (AKA embedded_H) applies this same
> criterion measure to every instance of embedded_H to any recursive depth.

This isn't even a coherent sentence.

> If the UTM simulation of the input to any embedded_H would never stop
> running without being aborted by this embedded_H then this embedded_H
> has met its non-halting criteria.

This is nonsense. The conditions which you state above indicate that the
final state is contingent on whether UTM(wM, w) halts. That condition
makes no mention of things being aborted, and it certainly doesn't
mention anything about replacing embedded_H with a UTM as you have
claimed in a previous post.

The bit that you're not getting is that since your "embedded_H" is
exactly the same algorithm as H with a loop added after H.qy this means
that either

H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qy

OR

H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn

In either case a contradiction arises.

It's not possible for H and embedded_H to reach different final states
when they are given the same input since they use the same algorithm.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<SP1zJ.175154$Wkjc.158269@fx35.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 65
Message-ID: <SP1zJ.175154$Wkjc.158269@fx35.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 13:31:14 -0500
X-Received-Bytes: 3392
 by: Richard Damon - Wed, 29 Dec 2021 18:31 UTC

On 12/29/21 11:49 AM, olcott wrote:
> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
> Ĥ.qn on the basis of the behavior of the UTM simulation of these inputs.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> *My criterion measure with Ben's notational conventions*
> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>
> We know that H would correctly decide the halt status of its input on
> the basis of correctly deciding the halt status of the UTM simulation of
> its input.

NO. We know that it MATCHES the 'results' of the UTM, but H needs to
give the non-halting answer in finite time, while the UTM will, by
definition, take un

>
> We know this because a UTM simulation of the Turing machine description
> is computationally equivalent to the direct execution of this same
> Turing machine.
>
> HERE IS WHERE PEOPLE GET STUCK
> HERE IS WHERE PEOPLE GET STUCK
> HERE IS WHERE PEOPLE GET STUCK
>
> We know that the copy of H is at Ĥ.qx (AKA embedded_H) applies this same
> criterion measure to every instance of embedded_H to any recursive depth.
>

Right, but H can't 'just use' a UTM, or it fails to answer.

Its answer must MATCH that of the UTM, but the UTM is allowed to take
forever to be given, but H isn't givn that option.

> If the UTM simulation of the input to any embedded_H would never stop
> running without being aborted by this embedded_H then this embedded_H
> has met its non-halting criteria.
>

But, unless H DOES abort its simulation, the H^ built on it will be
unanswerable. Since you claim that H gives an answer, then looking at an
embedded_H that does't is unsound logic, embeddd_H behaves just like H,
or you have LIED about building H^ but the rules.

Thus, if H DOES abort its simulation, and answer Qn, then UTM*<H^>,<H^>)
will see its copy of H do that same thing, and thus see H^ go to Qn and
then Halt.

FAIL.

>
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (315-320)
>

Your logic is inconsistent because you have assumed FALSE premises.

YOU are stuck in the LIAR'S PARADOX because YOU are the LIAR.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<L_1zJ.211$jW.99@fx05.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx05.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <sqi88u$ai9$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 95
Message-ID: <L_1zJ.211$jW.99@fx05.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 13:42:51 -0500
X-Received-Bytes: 4885
 by: Richard Damon - Wed, 29 Dec 2021 18:42 UTC

On 12/29/21 1:09 PM, André G. Isaak wrote:
> On 2021-12-29 09:49, olcott wrote:
>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
>> Ĥ.qn on the basis of the behavior of the UTM simulation of these inputs.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Those should be:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>
> Why do you insist on omitting the conditions in the above? They are just
> as mandatory for Ĥ as they are for H.

I suspect we really need to hold him to the FULL requirement here.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
iff H.q0 ⟨Ĥ⟩ ⊢* H.qy which requires that UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
iff H.q0 ⟨Ĥ⟩ ⊢* H.qyn which requires that UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt

To make it clear that BY CONSTRUCTION the copy of H at Ĥ.qx behaves
exactly the same as the 'plain' H, and the end state requirement derives
from the requirements of H, so only hold under the condition of H being
a correct Halt Decider.

This get rid of his distraction of having a different embedded_H that
behaves differently, which of course is NOT possible.

>
>> *My criterion measure with Ben's notational conventions*
>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>
>> We know that H would correctly decide the halt status of its input on
>> the basis of correctly deciding the halt status of the UTM simulation
>> of its input.
>
> Right. What that means in that H applied to wM w should transition to
> H.qy in exactly those cases where the *independent* computation UTM(wM,
> w) halts.
>
> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.
>
> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>
>> We know this because a UTM simulation of the Turing machine
>> description is computationally equivalent to the direct execution of
>> this same Turing machine.
>>
>> HERE IS WHERE PEOPLE GET STUCK
>> HERE IS WHERE PEOPLE GET STUCK
>> HERE IS WHERE PEOPLE GET STUCK
>
> You are the only one who is stuck.
>
>> We know that the copy of H is at Ĥ.qx (AKA embedded_H) applies this
>> same criterion measure to every instance of embedded_H to any
>> recursive depth.
>
> This isn't even a coherent sentence.
>
>> If the UTM simulation of the input to any embedded_H would never stop
>> running without being aborted by this embedded_H then this embedded_H
>> has met its non-halting criteria.
>
> This is nonsense. The conditions which you state above indicate that the
> final state is contingent on whether UTM(wM, w) halts. That condition
> makes no mention of things being aborted, and it certainly doesn't
> mention anything about replacing embedded_H with a UTM as you have
> claimed in a previous post.
>
> The bit that you're not getting is that since your "embedded_H" is
> exactly the same algorithm as H with a loop added after H.qy this means
> that either
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qy
>
> OR
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn
>
> In either case a contradiction arises.
>
> It's not possible for H and embedded_H to reach different final states
> when they are given the same input since they use the same algorithm.
>
> André
>

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

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

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people get stuck]
Date: Wed, 29 Dec 2021 19:16:53 +0000
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <87ee5v5ihm.fsf@bsb.me.uk>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="083ad936e143772a02e05e9c745cd6fa";
logging-data="1876"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18KgH+4kDaB3R0YSrnZVA8zuQgItghmedU="
Cancel-Lock: sha1:v6FRv6x967zXC4wy3TEAiJUnb+o=
sha1:dRYUlqcVO+4ZK+shTmz6se5sA+o=
X-BSB-Auth: 1.34d6cb398edea13093ca.20211229191653GMT.87ee5v5ihm.fsf@bsb.me.uk
 by: Ben Bacarisse - Wed, 29 Dec 2021 19:16 UTC

olcott <NoOne@NoWhere.com> writes:

> *My criterion measure with Ben's notational conventions*
> H.q0 wM w ⊢* H.qy iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn iff UTM(wM, w) does not halt

It's not your criterion, it's mine. It's also Linz's. If yours is not
the same as his (and mine), it should be different in some way. (And we
can safely ignore it, since no one cares about your alternative
criteria.)

--
Ben.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 14:13:27 -0600
Date: Wed, 29 Dec 2021 14:13:26 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sqi88u$ai9$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
Lines: 105
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-bj16SNJkr6N+W8AfvljwYm6crVd7CaaooMfRcDGwMYZstJCb/NGpk2d7huF1qjvynjqeS03BEFzU8yc!Pu9Ynft7xSGZqetzaCcRlEmGSgElZnKU+JZcJMcoVNO0QAIfwUy99NKTxhCmf7zce1ZCaI2nzZFv!0Q==
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: 5389
 by: olcott - Wed, 29 Dec 2021 20:13 UTC

On 12/29/2021 12:09 PM, André G. Isaak wrote:
> On 2021-12-29 09:49, olcott wrote:
>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
>> Ĥ.qn on the basis of the behavior of the UTM simulation of these inputs.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Those should be:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>
> Why do you insist on omitting the conditions in the above? They are just
> as mandatory for Ĥ as they are for H.
>

When the conditions are applied to H it is every clear that H is
determining whether or not its input halts. When they are applied to Ĥ
it is ambiguous whether that apply to embedded_H or to the input to
embedded_H.

>> *My criterion measure with Ben's notational conventions*
>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>
>> We know that H would correctly decide the halt status of its input on
>> the basis of correctly deciding the halt status of the UTM simulation
>> of its input.
>
> Right. What that means in that H applied to wM w should transition to
> H.qy in exactly those cases where the *independent* computation UTM(wM,
> w) halts.
>
> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.
>
> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>

You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.

>> We know this because a UTM simulation of the Turing machine
>> description is computationally equivalent to the direct execution of
>> this same Turing machine.
>>
>> HERE IS WHERE PEOPLE GET STUCK
>> HERE IS WHERE PEOPLE GET STUCK
>> HERE IS WHERE PEOPLE GET STUCK
>
> You are the only one who is stuck.
>
>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H) applies this
>> same criterion measure to every instance of embedded_H to any
>> recursive depth.
>
> This isn't even a coherent sentence.
>

When H is defined to base its halt status decision on the UTM simulation
of its input then every embedded_H in Ĥ will do this same thing.

If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating its own
Turing machine description then this simulated embedded_H will also base
its halt status decision on the UTM simulation of its input.

Richard could never understand this, he thinks that the second
embedded_H no longer has the same criterion measure as H.

>> If the UTM simulation of the input to any embedded_H would never stop
>> running without being aborted by this embedded_H then this embedded_H
>> has met its non-halting criteria.
>
> This is nonsense. The conditions which you state above indicate that the
> final state is contingent on whether UTM(wM, w) halts. That condition
> makes no mention of things being aborted, and it certainly doesn't
> mention anything about replacing embedded_H with a UTM as you have
> claimed in a previous post.
>
> The bit that you're not getting is that since your "embedded_H" is
> exactly the same algorithm as H with a loop added after H.qy this means
> that either
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qy
>
> OR
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn
>
> In either case a contradiction arises.
>
> It's not possible for H and embedded_H to reach different final states
> when they are given the same input since they use the same algorithm.
>
> André
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<HYudnbkt0sUMWFH8nZ2dnUU7-eHNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 14:31:13 -0600
Date: Wed, 29 Dec 2021 14:31:13 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<87ee5v5ihm.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87ee5v5ihm.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <HYudnbkt0sUMWFH8nZ2dnUU7-eHNnZ2d@giganews.com>
Lines: 47
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FWHrXK0DiTsaM5knIWJPZFKYXHf3sDD4tjjzHmTUKaQjKLNv385JWRvLU81hHYySpOpLL132P9gLsk7!BiIj9nEvXYU9UttclNUFT1bPkTPLkSQPHOBo8kHfxkWah/A5DkFMYMbTu5DKrolUAfnIQ9NykxDi!Rg==
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: 3039
 by: olcott - Wed, 29 Dec 2021 20:31 UTC

On 12/29/2021 1:16 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> *My criterion measure with Ben's notational conventions*
>> H.q0 wM w ⊢* H.qy iff UTM(wM, w) halts
>> H.q0 wM w ⊢* H.qn iff UTM(wM, w) does not halt
>
> It's not your criterion, it's mine. It's also Linz's. If yours is not
> the same as his (and mine), it should be different in some way. (And we
> can safely ignore it, since no one cares about your alternative
> criteria.)
>

It is my criterion measure that embedded_H bases its halt status
decision on the pure simulation of its input. Many posts for many months
proves that I am the one saying this.

That the simulation of a TM description and an input is typically
referred to as a UTM simulation is simply conventional knowledge.

It was your notational convention applied to H that broke the logjam we
were having about whether or not my criterion measure for the basis of
the halt status decision directly applies to the halting problem or not.

It is not clear that the pure simulation of an input to a halt decider
is a correct basis for its halt status decision.

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

The criterion measure can be applied to the above by referring to the
embedded copy of H at Ĥ.qx as embedded_H.

The input to embedded_H halts on its input
iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.

The input to embedded_H halts on its input
iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<sqihk3$e5u$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Date: Wed, 29 Dec 2021 13:48:59 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 122
Message-ID: <sqihk3$e5u$1@dont-email.me>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 29 Dec 2021 20:49:11 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="93859a21b83bba53cad11e036d0d03fd";
logging-data="14526"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18EHecawT6XGlbAZOiPtiy4"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:x0BWVjReiJ/Y98Dr/tfPOLQ+Czc=
In-Reply-To: <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Wed, 29 Dec 2021 20:48 UTC

On 2021-12-29 13:13, olcott wrote:
> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>> On 2021-12-29 09:49, olcott wrote:
>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>> Ĥ.qn on the basis of the behavior of the UTM simulation of these inputs.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Those should be:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>
>> Why do you insist on omitting the conditions in the above? They are
>> just as mandatory for Ĥ as they are for H.
>>
>
> When the conditions are applied to H it is every clear that H is
> determining whether or not its input halts. When they are applied to Ĥ
> it is ambiguous whether that apply to embedded_H or to the input to
> embedded_H.

There is no ambiguity here, nor has there ever been any ambiguity. The
fact that you think there is simply demonstrates that you don't
understand the notation being used. And until you learn what the
notation means you really shouldn't be arguing about such things.

>>> *My criterion measure with Ben's notational conventions*
>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>
>>> We know that H would correctly decide the halt status of its input on
>>> the basis of correctly deciding the halt status of the UTM simulation
>>> of its input.
>>
>> Right. What that means in that H applied to wM w should transition to
>> H.qy in exactly those cases where the *independent* computation
>> UTM(wM, w) halts.
>>
>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
>> halts.
>>
>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>
>
> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.

Based on *your* descriptions of how your H and Ĥ work.

And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
occasions.

>>> We know this because a UTM simulation of the Turing machine
>>> description is computationally equivalent to the direct execution of
>>> this same Turing machine.
>>>
>>> HERE IS WHERE PEOPLE GET STUCK
>>> HERE IS WHERE PEOPLE GET STUCK
>>> HERE IS WHERE PEOPLE GET STUCK
>>
>> You are the only one who is stuck.
>>
>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>> applies this same criterion measure to every instance of embedded_H
>>> to any recursive depth.
>>
>> This isn't even a coherent sentence.
>>
>
> When H is defined to base its halt status decision on the UTM simulation
> of its input then every embedded_H in Ĥ will do this same thing.
>
> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating its own
> Turing machine description then this simulated embedded_H will also base
> its halt status decision on the UTM simulation of its input.

The problem is that the criterion which you are using (to the extent
that it is interpretable) *isn't* the actual condition indicated in the
description given above, i.e.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt

> Richard could never understand this, he thinks that the second
> embedded_H no longer has the same criterion measure as H.

Richard has never claimed any such thing.

>>> If the UTM simulation of the input to any embedded_H would never stop
>>> running without being aborted by this embedded_H then this embedded_H
>>> has met its non-halting criteria.
>>
>> This is nonsense. The conditions which you state above indicate that
>> the final state is contingent on whether UTM(wM, w) halts. That
>> condition makes no mention of things being aborted, and it certainly
>> doesn't mention anything about replacing embedded_H with a UTM as you
>> have claimed in a previous post.
>>
>> The bit that you're not getting is that since your "embedded_H" is
>> exactly the same algorithm as H with a loop added after H.qy this
>> means that either
>>
>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qy
>>
>> OR
>>
>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn
>>
>> In either case a contradiction arises.

Why not actually address the above contradiction? It's the one you
cannot get out of since it exists *no* *matter* *what* condition is used
to determine the behaviour of H and Ĥ.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<V%3zJ.169557$SW5.150560@fx45.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 126
Message-ID: <V%3zJ.169557$SW5.150560@fx45.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 16:00:37 -0500
X-Received-Bytes: 6271
 by: Richard Damon - Wed, 29 Dec 2021 21:00 UTC

On 12/29/21 3:13 PM, olcott wrote:
> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>> On 2021-12-29 09:49, olcott wrote:
>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>> Ĥ.qn on the basis of the behavior of the UTM simulation of these inputs.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Those should be:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>
>> Why do you insist on omitting the conditions in the above? They are
>> just as mandatory for Ĥ as they are for H.
>>
>
> When the conditions are applied to H it is every clear that H is
> determining whether or not its input halts. When they are applied to Ĥ
> it is ambiguous whether that apply to embedded_H or to the input to
> embedded_H.
>
>>> *My criterion measure with Ben's notational conventions*
>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>
>>> We know that H would correctly decide the halt status of its input on
>>> the basis of correctly deciding the halt status of the UTM simulation
>>> of its input.
>>
>> Right. What that means in that H applied to wM w should transition to
>> H.qy in exactly those cases where the *independent* computation
>> UTM(wM, w) halts.
>>
>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
>> halts.
>>
>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>
>
> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>
>>> We know this because a UTM simulation of the Turing machine
>>> description is computationally equivalent to the direct execution of
>>> this same Turing machine.
>>>
>>> HERE IS WHERE PEOPLE GET STUCK
>>> HERE IS WHERE PEOPLE GET STUCK
>>> HERE IS WHERE PEOPLE GET STUCK
>>
>> You are the only one who is stuck.
>>
>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>> applies this same criterion measure to every instance of embedded_H
>>> to any recursive depth.
>>
>> This isn't even a coherent sentence.
>>
>
> When H is defined to base its halt status decision on the UTM simulation
> of its input then every embedded_H in Ĥ will do this same thing.

But everfy embedded_H must do exactly the same thing as H since they are
the exact same algorithm (to the point of Qn and Qy) with the exact same
input. This means that if H is know to give an answer, embedded_H can't
get stuck in an infinite simulation loop with H^, as then it isn't
acting the same.

Also, If H does try to 'just use' a UTM, it fails by not answering on
any non-halting input, or any input that uses a recursive usage of H,
even if it could be a halting computation with an H that actually meets
its requirements.

This seems to be your problem. Your embedded_H and H are written
differently to the same specs, where embedded_H gets stuck in the
infinite recursion loop, but H solve it, but that means they are
different, when the must be the same.

>
> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating its own
> Turing machine description then this simulated embedded_H will also base
> its halt status decision on the UTM simulation of its input.
>
> Richard could never understand this, he thinks that the second
> embedded_H no longer has the same criterion measure as H.

No, it has EXACTLY the same criteria as H, and behaves EXACTLY like H does.

THus, if H will halt in finite time in the H.qn state, so will your
'embedded_H', which also means, so will H^, and thus H was WRONG with
its decision, BECAUSE H/embedded_H do halt in the H.qn state.

>
>>> If the UTM simulation of the input to any embedded_H would never stop
>>> running without being aborted by this embedded_H then this embedded_H
>>> has met its non-halting criteria.
>>
>> This is nonsense. The conditions which you state above indicate that
>> the final state is contingent on whether UTM(wM, w) halts. That
>> condition makes no mention of things being aborted, and it certainly
>> doesn't mention anything about replacing embedded_H with a UTM as you
>> have claimed in a previous post.
>>
>> The bit that you're not getting is that since your "embedded_H" is
>> exactly the same algorithm as H with a loop added after H.qy this
>> means that either
>>
>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qy
>>
>> OR
>>
>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn
>>
>> In either case a contradiction arises.
>>
>> It's not possible for H and embedded_H to reach different final states
>> when they are given the same input since they use the same algorithm.
>>
>> André
>>
>
>

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<Nd4zJ.222923$aF1.77764@fx98.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx98.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<87ee5v5ihm.fsf@bsb.me.uk> <HYudnbkt0sUMWFH8nZ2dnUU7-eHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <HYudnbkt0sUMWFH8nZ2dnUU7-eHNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 70
Message-ID: <Nd4zJ.222923$aF1.77764@fx98.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 16:15:25 -0500
X-Received-Bytes: 3706
 by: Richard Damon - Wed, 29 Dec 2021 21:15 UTC

On 12/29/21 3:31 PM, olcott wrote:
> On 12/29/2021 1:16 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> *My criterion measure with Ben's notational conventions*
>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>
>> It's not your criterion, it's mine.  It's also Linz's.  If yours is not
>> the same as his (and mine), it should be different in some way.  (And we
>> can safely ignore it, since no one cares about your alternative
>> criteria.)
>>
>
> It is my criterion measure that embedded_H bases its halt status
> decision on the pure simulation of its input. Many posts for many months
> proves that I am the one saying this.

Then so must H.

If embedded_H doesn't abort, then neither can H, so H doesn't answer,
and FAILS.

>
> That the simulation of a TM description and an input is typically
> referred to as a UTM simulation is simply conventional knowledge.

UTM means a PURE SIMULATION that EXACTLY recreates the behavior of its
input.

Note, a UTM running the description of a non-halting computatation is
non-halting itself.

>
> It was your notational convention applied to H that broke the logjam we
> were having about whether or not my criterion measure for the basis of
> the halt status decision directly applies to the halting problem or not.
>
> It is not clear that the pure simulation of an input to a halt decider
> is a correct basis for its halt status decision.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
iff H.q0 ⟨Ĥ⟩ ⊢* H.qy because UTM(⟨Ĥ⟩,⟨Ĥ⟩) Halted

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
iff H.q0 ⟨Ĥ⟩ ⊢* H.qn because UTM(⟨Ĥ⟩,⟨Ĥ⟩) Never Halted

>
> The criterion measure can be applied to the above by referring to the
> embedded copy of H at Ĥ.qx as embedded_H.
>
> The input to embedded_H halts on its input
> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>
> The input to embedded_H halts on its input
> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.
>

thus embedded_H is identical to H (by construction),

Note. unless you are claiming that H IS a UTM, then it is an error to
presume that there is a UTM at Ĥ.qx.

If there IS a UTM at Ĥ.qx, then you have previously proven that this H
can never answer H (Ĥ) (Ĥ), as it gets stuck in an infinite simulation
loop, so either you are looking at a case that you have proven doesn't
work, or you are looking at a case that isn't actually what is before your.

FAIL.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 16:14:34 -0600
Date: Wed, 29 Dec 2021 16:14:33 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sqihk3$e5u$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
Lines: 158
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-yDLDJPD4+GGN8W2tP2vIELQxGm7R49w0bj1Y1XpuhjN9L3Urnn60leKkErDkNZFn6M71V2Ozzg8ngMQ!i2iL8/PaTH0RLxHG5XYYSlHLfXssyzzt093H7L92yA/ztsiMfsgmlhijNNvaDDg4Nasz82xvYLvl!9Q==
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: 7550
 by: olcott - Wed, 29 Dec 2021 22:14 UTC

On 12/29/2021 2:48 PM, André G. Isaak wrote:
> On 2021-12-29 13:13, olcott wrote:
>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>> On 2021-12-29 09:49, olcott wrote:
>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>> Ĥ.qn on the basis of the behavior of the UTM simulation of these
>>>> inputs.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> Those should be:
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>
>>> Why do you insist on omitting the conditions in the above? They are
>>> just as mandatory for Ĥ as they are for H.
>>>
>>
>> When the conditions are applied to H it is every clear that H is
>> determining whether or not its input halts. When they are applied to Ĥ
>> it is ambiguous whether that apply to embedded_H or to the input to
>> embedded_H.
>
> There is no ambiguity here, nor has there ever been any ambiguity. The
> fact that you think there is simply demonstrates that you don't
> understand the notation being used. And until you learn what the
> notation means you really shouldn't be arguing about such things.
>

When Linz says
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if Ĥ applied to ⟨Ĥ⟩ halts, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
He is wrong.

>>>> *My criterion measure with Ben's notational conventions*
>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>
>>>> We know that H would correctly decide the halt status of its input
>>>> on the basis of correctly deciding the halt status of the UTM
>>>> simulation of its input.
>>>
>>> Right. What that means in that H applied to wM w should transition to
>>> H.qy in exactly those cases where the *independent* computation
>>> UTM(wM, w) halts.
>>>
>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
>>> halts.
>>>
>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>
>>
>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>
> Based on *your* descriptions of how your H and Ĥ work.

Not at all. When we are analysing whether or not embedded_H transitions
to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.

> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
> occasions.
>
>>>> We know this because a UTM simulation of the Turing machine
>>>> description is computationally equivalent to the direct execution of
>>>> this same Turing machine.
>>>>
>>>> HERE IS WHERE PEOPLE GET STUCK
>>>> HERE IS WHERE PEOPLE GET STUCK
>>>> HERE IS WHERE PEOPLE GET STUCK
>>>
>>> You are the only one who is stuck.
>>>
>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>>> applies this same criterion measure to every instance of embedded_H
>>>> to any recursive depth.
>>>
>>> This isn't even a coherent sentence.
>>>
>>
>> When H is defined to base its halt status decision on the UTM
>> simulation of its input then every embedded_H in Ĥ will do this same
>> thing.
>>
>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating its
>> own Turing machine description then this simulated embedded_H will
>> also base its halt status decision on the UTM simulation of its input.
>
> The problem is that the criterion which you are using (to the extent
> that it is interpretable) *isn't* the actual condition indicated in the
> description given above, i.e.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>

Like I said this is ambiguous.

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

The criterion measure can be applied to the above by referring to the
embedded copy of H at Ĥ.qx as embedded_H.

The input to embedded_H halts on its input
iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.

The input to embedded_H halts on its input
iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.

>> Richard could never understand this, he thinks that the second
>> embedded_H no longer has the same criterion measure as H.
>
> Richard has never claimed any such thing.
>
>>>> If the UTM simulation of the input to any embedded_H would never
>>>> stop running without being aborted by this embedded_H then this
>>>> embedded_H has met its non-halting criteria.
>>>
>>> This is nonsense. The conditions which you state above indicate that
>>> the final state is contingent on whether UTM(wM, w) halts. That
>>> condition makes no mention of things being aborted, and it certainly
>>> doesn't mention anything about replacing embedded_H with a UTM as you
>>> have claimed in a previous post.
>>>
>>> The bit that you're not getting is that since your "embedded_H" is
>>> exactly the same algorithm as H with a loop added after H.qy this
>>> means that either
>>>
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qy
>>>
>>> OR
>>>
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn
>>>
>>> In either case a contradiction arises.
>
> Why not actually address the above contradiction? It's the one you
> cannot get out of since it exists *no* *matter* *what* condition is used
> to determine the behaviour of H and Ĥ.
>
> André
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<zp5zJ.138896$Z0a.123466@fx17.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx17.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 208
Message-ID: <zp5zJ.138896$Z0a.123466@fx17.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 17:36:16 -0500
X-Received-Bytes: 9147
 by: Richard Damon - Wed, 29 Dec 2021 22:36 UTC

On 12/29/21 5:14 PM, olcott wrote:
> On 12/29/2021 2:48 PM, André G. Isaak wrote:
>> On 2021-12-29 13:13, olcott wrote:
>>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>>> On 2021-12-29 09:49, olcott wrote:
>>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> to Ĥ.qn on the basis of the behavior of the UTM simulation of these
>>>>> inputs.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> Those should be:
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>
>>>> Why do you insist on omitting the conditions in the above? They are
>>>> just as mandatory for Ĥ as they are for H.
>>>>
>>>
>>> When the conditions are applied to H it is every clear that H is
>>> determining whether or not its input halts. When they are applied to
>>> Ĥ it is ambiguous whether that apply to embedded_H or to the input to
>>> embedded_H.
>>
>> There is no ambiguity here, nor has there ever been any ambiguity. The
>> fact that you think there is simply demonstrates that you don't
>> understand the notation being used. And until you learn what the
>> notation means you really shouldn't be arguing about such things.
>>
>
> When Linz says
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> if Ĥ applied to ⟨Ĥ⟩ does not halt.
> He is wrong.
>

WHY?

It is a direct consequence of the definition of a Halt Decider:

H wM w -> H.Qy iff wM w Halts, and
H wm w -> H.Qn iff wm w never Halts

combined with the construction of H^.

Please point out which step he makes an incorrect logic step.

If you can't (which you can't) then you can't say his statement is
incorrect.

Remeber, ALL of this is based on the (tentative) assumption that an H
could exist that meets the requirements.

>>>>> *My criterion measure with Ben's notational conventions*
>>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>>
>>>>> We know that H would correctly decide the halt status of its input
>>>>> on the basis of correctly deciding the halt status of the UTM
>>>>> simulation of its input.
>>>>
>>>> Right. What that means in that H applied to wM w should transition
>>>> to H.qy in exactly those cases where the *independent* computation
>>>> UTM(wM, w) halts.
>>>>
>>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>>>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
>>>> halts.
>>>>
>>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>>
>>>
>>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>>
>> Based on *your* descriptions of how your H and Ĥ work.
>
> Not at all. When we are analysing whether or not embedded_H transitions
> to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.

But since embedded_H is identical to H, and has the same input, so
embedded_H MUST do exactly the same thing your H does.

Since you claim H gets the correct answer by going to H.Qn, that seems
to be a statement that H <H^> <H^? DOES go to H.Qn, and thus so does
embedded_H.

Remember, 'Get the right answer' is NOT a valid algorithm.

>
>> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
>> occasions.
>>
>>>>> We know this because a UTM simulation of the Turing machine
>>>>> description is computationally equivalent to the direct execution
>>>>> of this same Turing machine.
>>>>>
>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>
>>>> You are the only one who is stuck.
>>>>
>>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>>>> applies this same criterion measure to every instance of embedded_H
>>>>> to any recursive depth.
>>>>
>>>> This isn't even a coherent sentence.
>>>>
>>>
>>> When H is defined to base its halt status decision on the UTM
>>> simulation of its input then every embedded_H in Ĥ will do this same
>>> thing.
>>>
>>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating its
>>> own Turing machine description then this simulated embedded_H will
>>> also base its halt status decision on the UTM simulation of its input.
>>
>> The problem is that the criterion which you are using (to the extent
>> that it is interpretable) *isn't* the actual condition indicated in
>> the description given above, i.e.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>
>
> Like I said this is ambiguous.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> The criterion measure can be applied to the above by referring to the
> embedded copy of H at Ĥ.qx as embedded_H.
>
> The input to embedded_H halts on its input
> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>
> The input to embedded_H halts on its input
> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.
>
>

You still haven't said what you mean by "The input to embedded_H halts
on its input"

Inputs NEVER Halt, only machines.

But the first line is the needed result if UTM(<H^>,<H^>) would Halt,
and the second if it never halts.

But since H^ going to H^.qy -> ∞ means that the computation will never
halt, and if it goes to H^.qn in means that the computation will Halt,
and the UTM will do the same as the computation, we get That:

we get a non-halting computation only if we have a halting computation
and a halting computation only if we have a non-halting computation.

If you can come up with a non-halting halt computation (or a halting
non-halting computation), you might have something, but that is impossible.

This PROVES that H can not exist, as the existance of H creates a
contradiction.

You just don't seem to understand how a proof of non-existence by
contradiction works.

>>> Richard could never understand this, he thinks that the second
>>> embedded_H no longer has the same criterion measure as H.
>>
>> Richard has never claimed any such thing.
>>
>>>>> If the UTM simulation of the input to any embedded_H would never
>>>>> stop running without being aborted by this embedded_H then this
>>>>> embedded_H has met its non-halting criteria.
>>>>
>>>> This is nonsense. The conditions which you state above indicate that
>>>> the final state is contingent on whether UTM(wM, w) halts. That
>>>> condition makes no mention of things being aborted, and it certainly
>>>> doesn't mention anything about replacing embedded_H with a UTM as
>>>> you have claimed in a previous post.
>>>>
>>>> The bit that you're not getting is that since your "embedded_H" is
>>>> exactly the same algorithm as H with a loop added after H.qy this
>>>> means that either
>>>>
>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qy
>>>>
>>>> OR
>>>>
>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn AND Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn
>>>>
>>>> In either case a contradiction arises.
>>
>> Why not actually address the above contradiction? It's the one you
>> cannot get out of since it exists *no* *matter* *what* condition is
>> used to determine the behaviour of H and Ĥ.
>>
>> André
>>
>
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<sqio4l$m2k$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Date: Wed, 29 Dec 2021 15:40:19 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 146
Message-ID: <sqio4l$m2k$1@dont-email.me>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 29 Dec 2021 22:40:21 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="93859a21b83bba53cad11e036d0d03fd";
logging-data="22612"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+XuCn/bHQ8FM+Tx4yon2zU"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:/bJTypxu/Sz33VOvlenKQ8EFRW8=
In-Reply-To: <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Wed, 29 Dec 2021 22:40 UTC

On 2021-12-29 15:14, olcott wrote:
> On 12/29/2021 2:48 PM, André G. Isaak wrote:
>> On 2021-12-29 13:13, olcott wrote:
>>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>>> On 2021-12-29 09:49, olcott wrote:
>>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> to Ĥ.qn on the basis of the behavior of the UTM simulation of these
>>>>> inputs.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> Those should be:
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>
>>>> Why do you insist on omitting the conditions in the above? They are
>>>> just as mandatory for Ĥ as they are for H.
>>>>
>>>
>>> When the conditions are applied to H it is every clear that H is
>>> determining whether or not its input halts. When they are applied to
>>> Ĥ it is ambiguous whether that apply to embedded_H or to the input to
>>> embedded_H.
>>
>> There is no ambiguity here, nor has there ever been any ambiguity. The
>> fact that you think there is simply demonstrates that you don't
>> understand the notation being used. And until you learn what the
>> notation means you really shouldn't be arguing about such things.
>>
>
> When Linz says
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> if Ĥ applied to ⟨Ĥ⟩ does not halt.
> He is wrong.

No, he is not.

And the conditions stated above are identical to the ones which Ben
provided. So if you claim Linz is wrong, you're also claiming that the
criteria Ben supplied which you have adopted are also wrong.

>>>>> *My criterion measure with Ben's notational conventions*
>>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>>
>>>>> We know that H would correctly decide the halt status of its input
>>>>> on the basis of correctly deciding the halt status of the UTM
>>>>> simulation of its input.
>>>>
>>>> Right. What that means in that H applied to wM w should transition
>>>> to H.qy in exactly those cases where the *independent* computation
>>>> UTM(wM, w) halts.
>>>>
>>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>>>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
>>>> halts.
>>>>
>>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>>
>>>
>>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>>
>> Based on *your* descriptions of how your H and Ĥ work.
>
> Not at all. When we are analysing whether or not embedded_H transitions
> to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.

I'm not making any claims about what embedded_H transitions to. I am
stating what the correct answer is. H cannot give the correct answer.

>> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
>> occasions.
>>
>>>>> We know this because a UTM simulation of the Turing machine
>>>>> description is computationally equivalent to the direct execution
>>>>> of this same Turing machine.
>>>>>
>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>
>>>> You are the only one who is stuck.
>>>>
>>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>>>> applies this same criterion measure to every instance of embedded_H
>>>>> to any recursive depth.
>>>>
>>>> This isn't even a coherent sentence.
>>>>
>>>
>>> When H is defined to base its halt status decision on the UTM
>>> simulation of its input then every embedded_H in Ĥ will do this same
>>> thing.
>>>
>>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating its
>>> own Turing machine description then this simulated embedded_H will
>>> also base its halt status decision on the UTM simulation of its input.
>>
>> The problem is that the criterion which you are using (to the extent
>> that it is interpretable) *isn't* the actual condition indicated in
>> the description given above, i.e.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>
>
> Like I said this is ambiguous.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Assuming that 'this' refers to the above two lines, they are
*incomplete*. You need to include the conditions. I don't get why you
find this so difficult to get.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt

And there is absolutely *nothing* ambiguous about the above. What
possible ambiguity could there be?

> The criterion measure can be applied to the above by referring to the
> embedded copy of H at Ĥ.qx as embedded_H.
>
> The input to embedded_H halts on its input
> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>
> The input to embedded_H halts on its input
> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.

The above two statements are contradictory.

And I have no idea what 'UTM at Ĥ.qx' might mean. Ĥ.qx is a single
state. a UTM is a complete Turing Machine. How can there be a UTM at Ĥ.qx?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 16:53:13 -0600
Date: Wed, 29 Dec 2021 16: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.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sqio4l$m2k$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
Lines: 165
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Z76qf3Da1qUCWqtdlLOq+Dh9cJofuVdt0qTmGK9huZdXsMpwVZkwCPpVVEzR5zvK6qUdYBpls5A928+!EMk3g49jD2BdtY1g6UWNL14NnnKgUM7MZGzRbwcGAxd72ZvLc6vxTsJW0ix883lrzcoDQi8bVfpM!xQ==
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: 8043
 by: olcott - Wed, 29 Dec 2021 22:53 UTC

On 12/29/2021 4:40 PM, André G. Isaak wrote:
> On 2021-12-29 15:14, olcott wrote:
>> On 12/29/2021 2:48 PM, André G. Isaak wrote:
>>> On 2021-12-29 13:13, olcott wrote:
>>>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>>>> On 2021-12-29 09:49, olcott wrote:
>>>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> to Ĥ.qn on the basis of the behavior of the UTM simulation of
>>>>>> these inputs.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> Those should be:
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>>
>>>>> Why do you insist on omitting the conditions in the above? They are
>>>>> just as mandatory for Ĥ as they are for H.
>>>>>
>>>>
>>>> When the conditions are applied to H it is every clear that H is
>>>> determining whether or not its input halts. When they are applied to
>>>> Ĥ it is ambiguous whether that apply to embedded_H or to the input
>>>> to embedded_H.
>>>
>>> There is no ambiguity here, nor has there ever been any ambiguity.
>>> The fact that you think there is simply demonstrates that you don't
>>> understand the notation being used. And until you learn what the
>>> notation means you really shouldn't be arguing about such things.
>>>
>>
>> When Linz says
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>> He is wrong.
>
> No, he is not.
>

There is only one computation above that is actually Ĥ and that
computation includes embedded_H at Ĥ.qx.

⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.

> And the conditions stated above are identical to the ones which Ben
> provided. So if you claim Linz is wrong, you're also claiming that the
> criteria Ben supplied which you have adopted are also wrong.
>
>>>>>> *My criterion measure with Ben's notational conventions*
>>>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>>>
>>>>>> We know that H would correctly decide the halt status of its input
>>>>>> on the basis of correctly deciding the halt status of the UTM
>>>>>> simulation of its input.
>>>>>
>>>>> Right. What that means in that H applied to wM w should transition
>>>>> to H.qy in exactly those cases where the *independent* computation
>>>>> UTM(wM, w) halts.
>>>>>
>>>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>>>>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩
>>>>> ⟨Ĥ⟩) halts.
>>>>>
>>>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the

It is a only an assumption that the independent computation Ĥ ⟨Ĥ⟩ halts.

>>>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>>>
>>>>
>>>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>>>
>>> Based on *your* descriptions of how your H and Ĥ work.
>>
>> Not at all. When we are analysing whether or not embedded_H
>> transitions to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.
>
> I'm not making any claims about what embedded_H transitions to. I am
> stating what the correct answer is. H cannot give the correct answer.
>
>>> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
>>> occasions.
>>>
>>>>>> We know this because a UTM simulation of the Turing machine
>>>>>> description is computationally equivalent to the direct execution
>>>>>> of this same Turing machine.
>>>>>>
>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>
>>>>> You are the only one who is stuck.
>>>>>
>>>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>>>>> applies this same criterion measure to every instance of
>>>>>> embedded_H to any recursive depth.
>>>>>
>>>>> This isn't even a coherent sentence.
>>>>>
>>>>
>>>> When H is defined to base its halt status decision on the UTM
>>>> simulation of its input then every embedded_H in Ĥ will do this same
>>>> thing.
>>>>
>>>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating its
>>>> own Turing machine description then this simulated embedded_H will
>>>> also base its halt status decision on the UTM simulation of its input.
>>>
>>> The problem is that the criterion which you are using (to the extent
>>> that it is interpretable) *isn't* the actual condition indicated in
>>> the description given above, i.e.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>
>>
>> Like I said this is ambiguous.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Assuming that 'this' refers to the above two lines, they are
> *incomplete*. You need to include the conditions. I don't get why you
> find this so difficult to get.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>
> And there is absolutely *nothing* ambiguous about the above. What
> possible ambiguity could there be?
>
>> The criterion measure can be applied to the above by referring to the
>> embedded copy of H at Ĥ.qx as embedded_H.
>>
>> The input to embedded_H halts on its input
>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>>
>> The input to embedded_H halts on its input
>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.
>
> The above two statements are contradictory.

They are only contradictory it you assume that embedded_H is reporting
on whether or not itself halts.

>
> And I have no idea what 'UTM at Ĥ.qx' might mean. Ĥ.qx is a single
> state. a UTM is a complete Turing Machine. How can there be a UTM at Ĥ.qx?
>
> André
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<sqiqc6$4n5$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Date: Wed, 29 Dec 2021 16:18:29 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 175
Message-ID: <sqiqc6$4n5$1@dont-email.me>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 29 Dec 2021 23:18:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="281e34967abc652e32513cf7d24af717";
logging-data="4837"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1++3p7KuIULy0ilZtsKI2aA"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:bvlHzwFP21hHAOBlZOTnor0RkXs=
In-Reply-To: <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Wed, 29 Dec 2021 23:18 UTC

On 2021-12-29 15:53, olcott wrote:
> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>> On 2021-12-29 15:14, olcott wrote:
>>> On 12/29/2021 2:48 PM, André G. Isaak wrote:
>>>> On 2021-12-29 13:13, olcott wrote:
>>>>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>>>>> On 2021-12-29 09:49, olcott wrote:
>>>>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> to Ĥ.qn on the basis of the behavior of the UTM simulation of
>>>>>>> these inputs.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> Those should be:
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>>>
>>>>>> Why do you insist on omitting the conditions in the above? They
>>>>>> are just as mandatory for Ĥ as they are for H.
>>>>>>
>>>>>
>>>>> When the conditions are applied to H it is every clear that H is
>>>>> determining whether or not its input halts. When they are applied
>>>>> to Ĥ it is ambiguous whether that apply to embedded_H or to the
>>>>> input to embedded_H.
>>>>
>>>> There is no ambiguity here, nor has there ever been any ambiguity.
>>>> The fact that you think there is simply demonstrates that you don't
>>>> understand the notation being used. And until you learn what the
>>>> notation means you really shouldn't be arguing about such things.
>>>>
>>>
>>> When Linz says
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>> He is wrong.
>>
>> No, he is not.
>>
>
> There is only one computation above that is actually Ĥ and that
> computation includes embedded_H at Ĥ.qx.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.

Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself? He doesn't. Nothing in
the above even remotely implies that, so I have no clue what your
objection here actually is. You need to learn what this notation
actually *means*.

>> And the conditions stated above are identical to the ones which Ben
>> provided. So if you claim Linz is wrong, you're also claiming that the
>> criteria Ben supplied which you have adopted are also wrong.
>>
>>>>>>> *My criterion measure with Ben's notational conventions*
>>>>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>>>>
>>>>>>> We know that H would correctly decide the halt status of its
>>>>>>> input on the basis of correctly deciding the halt status of the
>>>>>>> UTM simulation of its input.
>>>>>>
>>>>>> Right. What that means in that H applied to wM w should transition
>>>>>> to H.qy in exactly those cases where the *independent* computation
>>>>>> UTM(wM, w) halts.
>>>>>>
>>>>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>>>>>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩
>>>>>> ⟨Ĥ⟩) halts.
>>>>>>
>>>>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>
> It is a only an assumption that the independent computation Ĥ ⟨Ĥ⟩ halts.

Then why have you acknowledged in the past that it does, in fact, halt?

>>>>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>>>>
>>>>>
>>>>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>>>>
>>>> Based on *your* descriptions of how your H and Ĥ work.
>>>
>>> Not at all. When we are analysing whether or not embedded_H
>>> transitions to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.
>>
>> I'm not making any claims about what embedded_H transitions to. I am
>> stating what the correct answer is. H cannot give the correct answer.
>>
>>>> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
>>>> occasions.
>>>>
>>>>>>> We know this because a UTM simulation of the Turing machine
>>>>>>> description is computationally equivalent to the direct execution
>>>>>>> of this same Turing machine.
>>>>>>>
>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>
>>>>>> You are the only one who is stuck.
>>>>>>
>>>>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>>>>>> applies this same criterion measure to every instance of
>>>>>>> embedded_H to any recursive depth.
>>>>>>
>>>>>> This isn't even a coherent sentence.
>>>>>>
>>>>>
>>>>> When H is defined to base its halt status decision on the UTM
>>>>> simulation of its input then every embedded_H in Ĥ will do this
>>>>> same thing.
>>>>>
>>>>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating
>>>>> its own Turing machine description then this simulated embedded_H
>>>>> will also base its halt status decision on the UTM simulation of
>>>>> its input.
>>>>
>>>> The problem is that the criterion which you are using (to the extent
>>>> that it is interpretable) *isn't* the actual condition indicated in
>>>> the description given above, i.e.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>
>>>
>>> Like I said this is ambiguous.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Assuming that 'this' refers to the above two lines, they are
>> *incomplete*. You need to include the conditions. I don't get why you
>> find this so difficult to get.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>
>> And there is absolutely *nothing* ambiguous about the above. What
>> possible ambiguity could there be?
>>
>>> The criterion measure can be applied to the above by referring to the
>>> embedded copy of H at Ĥ.qx as embedded_H.
>>>
>>> The input to embedded_H halts on its input
>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>>>
>>> The input to embedded_H halts on its input
>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.
>>
>> The above two statements are contradictory.
>
> They are only contradictory it you assume that embedded_H is reporting
> on whether or not itself halts.

Actually, I misspoke. They are not contradictory, but I assume they are
not what you actually meant to write since the above two statements
entail the following:

The input to embedded_H halts on its input regardless of what the pure
simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does.

And you still need to explain what it means for an input to halt on its
input (a meaningless phrase) or what 'a UTM at Ĥ.qx' means.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<Tn6zJ.207288$1d1.106346@fx99.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx99.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 204
Message-ID: <Tn6zJ.207288$1d1.106346@fx99.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 18:42:44 -0500
X-Received-Bytes: 9096
X-Original-Bytes: 8963
 by: Richard Damon - Wed, 29 Dec 2021 23:42 UTC

On 12/29/21 5:53 PM, olcott wrote:
> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>> On 2021-12-29 15:14, olcott wrote:
>>> On 12/29/2021 2:48 PM, André G. Isaak wrote:
>>>> On 2021-12-29 13:13, olcott wrote:
>>>>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>>>>> On 2021-12-29 09:49, olcott wrote:
>>>>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> to Ĥ.qn on the basis of the behavior of the UTM simulation of
>>>>>>> these inputs.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> Those should be:
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>>>
>>>>>> Why do you insist on omitting the conditions in the above? They
>>>>>> are just as mandatory for Ĥ as they are for H.
>>>>>>
>>>>>
>>>>> When the conditions are applied to H it is every clear that H is
>>>>> determining whether or not its input halts. When they are applied
>>>>> to Ĥ it is ambiguous whether that apply to embedded_H or to the
>>>>> input to embedded_H.
>>>>
>>>> There is no ambiguity here, nor has there ever been any ambiguity.
>>>> The fact that you think there is simply demonstrates that you don't
>>>> understand the notation being used. And until you learn what the
>>>> notation means you really shouldn't be arguing about such things.
>>>>
>>>
>>> When Linz says
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>> He is wrong.
>>
>> No, he is not.
>>
>
> There is only one computation above that is actually Ĥ and that
> computation includes embedded_H at Ĥ.qx.
>

Well it NEEDS to include an copy of H, so embedded_H needs to be just
like H for that to be correct.

> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.

No, it isn't, it is the representation of H^ applied to <H^>, so
UTM(<H^>, <H^>) needs to behave exactly like H^ applied to <H^>

>
>> And the conditions stated above are identical to the ones which Ben
>> provided. So if you claim Linz is wrong, you're also claiming that the
>> criteria Ben supplied which you have adopted are also wrong.
>>
>>>>>>> *My criterion measure with Ben's notational conventions*
>>>>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>>>>
>>>>>>> We know that H would correctly decide the halt status of its
>>>>>>> input on the basis of correctly deciding the halt status of the
>>>>>>> UTM simulation of its input.
>>>>>>
>>>>>> Right. What that means in that H applied to wM w should transition
>>>>>> to H.qy in exactly those cases where the *independent* computation
>>>>>> UTM(wM, w) halts.
>>>>>>
>>>>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>>>>>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩
>>>>>> ⟨Ĥ⟩) halts.
>>>>>>
>>>>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>
> It is a only an assumption that the independent computation Ĥ ⟨Ĥ⟩ halts.

Not an 'assumption' but a necessary result if H <H^> <H^> -> H.Qn by the
construction of H^.

Since you seem to be claiming that this happens, then this also needs to
happen.

>
>>>>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>>>>
>>>>>
>>>>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>>>>
>>>> Based on *your* descriptions of how your H and Ĥ work.
>>>
>>> Not at all. When we are analysing whether or not embedded_H
>>> transitions to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.
>>
>> I'm not making any claims about what embedded_H transitions to. I am
>> stating what the correct answer is. H cannot give the correct answer.
>>
>>>> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
>>>> occasions.
>>>>
>>>>>>> We know this because a UTM simulation of the Turing machine
>>>>>>> description is computationally equivalent to the direct execution
>>>>>>> of this same Turing machine.
>>>>>>>
>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>
>>>>>> You are the only one who is stuck.
>>>>>>
>>>>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>>>>>> applies this same criterion measure to every instance of
>>>>>>> embedded_H to any recursive depth.
>>>>>>
>>>>>> This isn't even a coherent sentence.
>>>>>>
>>>>>
>>>>> When H is defined to base its halt status decision on the UTM
>>>>> simulation of its input then every embedded_H in Ĥ will do this
>>>>> same thing.
>>>>>
>>>>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating
>>>>> its own Turing machine description then this simulated embedded_H
>>>>> will also base its halt status decision on the UTM simulation of
>>>>> its input.
>>>>
>>>> The problem is that the criterion which you are using (to the extent
>>>> that it is interpretable) *isn't* the actual condition indicated in
>>>> the description given above, i.e.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>
>>>
>>> Like I said this is ambiguous.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Assuming that 'this' refers to the above two lines, they are
>> *incomplete*. You need to include the conditions. I don't get why you
>> find this so difficult to get.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>
>> And there is absolutely *nothing* ambiguous about the above. What
>> possible ambiguity could there be?
>>
>>> The criterion measure can be applied to the above by referring to the
>>> embedded copy of H at Ĥ.qx as embedded_H.
>>>
>>> The input to embedded_H halts on its input
>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>>>
>>> The input to embedded_H halts on its input
>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.
>>
>> The above two statements are contradictory.
>
> They are only contradictory it you assume that embedded_H is reporting
> on whether or not itself halts.
>

embedded_H MUST BE a copy of H.

H MUST report on the behavior of the computation given to it.

Since the problem has H being given a computation based on a machine
that uses a copy of H, then YES, H needs to report on a computation that
depends on the answer H gives, and if H returns.

Unless you can point to an actual logical error in the derivation of the
statments you object to, you have no grounds to say that are incorrect.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<sqirr2$brd$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Date: Wed, 29 Dec 2021 16:43:28 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 60
Message-ID: <sqirr2$brd$1@dont-email.me>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 29 Dec 2021 23:43:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="281e34967abc652e32513cf7d24af717";
logging-data="12141"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188GFvmActOEnSaEy08MILY"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:b0QrqWhkaRFPyNGc0eHPPRICN50=
In-Reply-To: <sqiqc6$4n5$1@dont-email.me>
Content-Language: en-US
 by: André G. Isaak - Wed, 29 Dec 2021 23:43 UTC

On 2021-12-29 16:18, André G. Isaak wrote:
> On 2021-12-29 15:53, olcott wrote:
>> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>>> On 2021-12-29 15:14, olcott wrote:

>>>> When Linz says
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>> He is wrong.
>>>
>>> No, he is not.
>>>
>>
>> There is only one computation above that is actually Ĥ and that
>> computation includes embedded_H at Ĥ.qx.
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.
>
> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself? He doesn't. Nothing in
> the above even remotely implies that, so I have no clue what your
> objection here actually is. You need to learn what this notation
> actually *means*.

Just to clarify this, you need to understand what a condition actually
*means*.

When we say:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff Ĥ applied to ⟨Ĥ⟩ halts

the 'iff Ĥ applied to ⟨Ĥ⟩ halts' simply specifies what condition must be
met for Ĥ.q0 ⟨Ĥ⟩ to transition to Ĥ.qy ∞. It says nothing about how the
underlying algorithm works. In particular, it doesn't require that Ĥ
ever gets applied to ⟨Ĥ⟩ at some point in the computation.

Consider the following simple TM:

M.q0 w ⊢* M.qy iff 2 + 3 = 5.

That describes a TM which accepts *every* input string it is given
because the condition which has been given is always true.

This condition does *not* mean that an implementation of M has to
actually add numbers or compare two numbers. Said machine can simply
transition directly from its initial state to its final accepting state
without doing anything at all.

The condition simply states some fact which must be true for the machine
to transition to a particular state. The TM may or may not directly
reference the condition in its algorithm. The design just needs to
ensure that where it gets to is *consistent* with that condition.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 17:53:44 -0600
Date: Wed, 29 Dec 2021 17:53:43 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sqiqc6$4n5$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com>
Lines: 204
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5AIE2VU1PSHzfq8BYxptcbki8JJW0Ud7elvg70YkbbRAdavfY9kJKvb35g8UHkXcjv3cXQ6un8oTkwO!AG70SYdNxvklZKR5AayTeFaL8onWv3bpbb76DtOo+m38i4gsMdS3B+y+UEikgFg3cPYPMRYlF7Oi!Jw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 9918
 by: olcott - Wed, 29 Dec 2021 23:53 UTC

On 12/29/2021 5:18 PM, André G. Isaak wrote:
> On 2021-12-29 15:53, olcott wrote:
>> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>>> On 2021-12-29 15:14, olcott wrote:
>>>> On 12/29/2021 2:48 PM, André G. Isaak wrote:
>>>>> On 2021-12-29 13:13, olcott wrote:
>>>>>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>>>>>> On 2021-12-29 09:49, olcott wrote:
>>>>>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩
>>>>>>>> ⟨Ĥ⟩ to Ĥ.qn on the basis of the behavior of the UTM simulation
>>>>>>>> of these inputs.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> Those should be:
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>>>>
>>>>>>> Why do you insist on omitting the conditions in the above? They
>>>>>>> are just as mandatory for Ĥ as they are for H.
>>>>>>>
>>>>>>
>>>>>> When the conditions are applied to H it is every clear that H is
>>>>>> determining whether or not its input halts. When they are applied
>>>>>> to Ĥ it is ambiguous whether that apply to embedded_H or to the
>>>>>> input to embedded_H.
>>>>>
>>>>> There is no ambiguity here, nor has there ever been any ambiguity.
>>>>> The fact that you think there is simply demonstrates that you don't
>>>>> understand the notation being used. And until you learn what the
>>>>> notation means you really shouldn't be arguing about such things.
>>>>>
>>>>
>>>> When Linz says
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>> He is wrong.
>>>
>>> No, he is not.
>>>
>>
>> There is only one computation above that is actually Ĥ and that
>> computation includes embedded_H at Ĥ.qx.
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.
>
> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself?

if Ĥ applied to ⟨Ĥ⟩ does not halt is referring to Ĥ.q0 ⟨Ĥ⟩, this is the
[ persistent misconception ]

It does not take a genius to see strcmp("Ĥ", "⟨Ĥ⟩") != 0

> He doesn't. Nothing in
> the above even remotely implies that, so I have no clue what your
> objection here actually is. You need to learn what this notation
> actually *means*.
>
>>> And the conditions stated above are identical to the ones which Ben
>>> provided. So if you claim Linz is wrong, you're also claiming that
>>> the criteria Ben supplied which you have adopted are also wrong.
>>>
>>>>>>>> *My criterion measure with Ben's notational conventions*
>>>>>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>>>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>>>>>
>>>>>>>> We know that H would correctly decide the halt status of its
>>>>>>>> input on the basis of correctly deciding the halt status of the
>>>>>>>> UTM simulation of its input.
>>>>>>>
>>>>>>> Right. What that means in that H applied to wM w should
>>>>>>> transition to H.qy in exactly those cases where the *independent*
>>>>>>> computation UTM(wM, w) halts.
>>>>>>>
>>>>>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy in
>>>>>>> exactly those cases where the *independent* computation UTM(⟨Ĥ⟩
>>>>>>> ⟨Ĥ⟩) halts.
>>>>>>>
>>>>>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>>
>> It is a only an assumption that the independent computation Ĥ ⟨Ĥ⟩ halts.
>
> Then why have you acknowledged in the past that it does, in fact, halt?
>
>>>>>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>>>>>
>>>>>>
>>>>>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>>>>>
>>>>> Based on *your* descriptions of how your H and Ĥ work.
>>>>
>>>> Not at all. When we are analysing whether or not embedded_H
>>>> transitions to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.
>>>
>>> I'm not making any claims about what embedded_H transitions to. I am
>>> stating what the correct answer is. H cannot give the correct answer.
>>>
>>>>> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on numerous
>>>>> occasions.
>>>>>
>>>>>>>> We know this because a UTM simulation of the Turing machine
>>>>>>>> description is computationally equivalent to the direct
>>>>>>>> execution of this same Turing machine.
>>>>>>>>
>>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>>
>>>>>>> You are the only one who is stuck.
>>>>>>>
>>>>>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA embedded_H)
>>>>>>>> applies this same criterion measure to every instance of
>>>>>>>> embedded_H to any recursive depth.
>>>>>>>
>>>>>>> This isn't even a coherent sentence.
>>>>>>>
>>>>>>
>>>>>> When H is defined to base its halt status decision on the UTM
>>>>>> simulation of its input then every embedded_H in Ĥ will do this
>>>>>> same thing.
>>>>>>
>>>>>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating
>>>>>> its own Turing machine description then this simulated embedded_H
>>>>>> will also base its halt status decision on the UTM simulation of
>>>>>> its input.
>>>>>
>>>>> The problem is that the criterion which you are using (to the
>>>>> extent that it is interpretable) *isn't* the actual condition
>>>>> indicated in the description given above, i.e.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>>
>>>>
>>>> Like I said this is ambiguous.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> Assuming that 'this' refers to the above two lines, they are
>>> *incomplete*. You need to include the conditions. I don't get why you
>>> find this so difficult to get.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>
>>> And there is absolutely *nothing* ambiguous about the above. What
>>> possible ambiguity could there be?
>>>
>>>> The criterion measure can be applied to the above by referring to
>>>> the embedded copy of H at Ĥ.qx as embedded_H.
>>>>
>>>> The input to embedded_H halts on its input
>>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>>>>
>>>> The input to embedded_H halts on its input
>>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.
>>>
>>> The above two statements are contradictory.
>>
>> They are only contradictory it you assume that embedded_H is reporting
>> on whether or not itself halts.
>
> Actually, I misspoke. They are not contradictory, but I assume they are
> not what you actually meant to write since the above two statements
> entail the following:
>
> The input to embedded_H halts on its input regardless of what the pure
> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does.
>
> And you still need to explain what it means for an input to halt on its
> input (a meaningless phrase) or what 'a UTM at Ĥ.qx' means.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<z5OdneTRlcI4alH8nZ2dnUU7-IfNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 18:04:53 -0600
Date: Wed, 29 Dec 2021 18:04:52 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me> <sqirr2$brd$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sqirr2$brd$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <z5OdneTRlcI4alH8nZ2dnUU7-IfNnZ2d@giganews.com>
Lines: 81
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-wjAhkwKhftZBW31cT3M/+soz6lTO0tx1qyH8RfOZkUzovVV9hLlyM2fNcupQJTj4HebCQDKus/6LQAw!LnpzZIQsU9GE57Z65qQoacd2IJ4v9++cm+upZiOvi7ZW3EPhalNwXqI3asSinZxW+lLaYZOJWEk8!1g==
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: 4669
 by: olcott - Thu, 30 Dec 2021 00:04 UTC

On 12/29/2021 5:43 PM, André G. Isaak wrote:
> On 2021-12-29 16:18, André G. Isaak wrote:
>> On 2021-12-29 15:53, olcott wrote:
>>> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>>>> On 2021-12-29 15:14, olcott wrote:
>
>>>>> When Linz says
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>> He is wrong.
>>>>
>>>> No, he is not.
>>>>
>>>
>>> There is only one computation above that is actually Ĥ and that
>>> computation includes embedded_H at Ĥ.qx.
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.
>>
>> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself? He doesn't. Nothing in
>> the above even remotely implies that, so I have no clue what your
>> objection here actually is. You need to learn what this notation
>> actually *means*.
>
> Just to clarify this, you need to understand what a condition actually
> *means*.
>
> When we say:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff Ĥ applied to ⟨Ĥ⟩ halts
>
> the 'iff Ĥ applied to ⟨Ĥ⟩ halts' simply specifies what condition must be
> met for Ĥ.q0 ⟨Ĥ⟩ to transition to Ĥ.qy ∞. It says nothing about how the
> underlying algorithm works. In particular, it doesn't require that Ĥ
> ever gets applied to ⟨Ĥ⟩ at some point in the computation.
>
> Consider the following simple TM:
>
> M.q0 w ⊢* M.qy iff 2 + 3 = 5.
>
> That describes a TM which accepts *every* input string it is given
> because the condition which has been given is always true.
>
> This condition does *not* mean that an implementation of M has to
> actually add numbers or compare two numbers. Said machine can simply
> transition directly from its initial state to its final accepting state
> without doing anything at all.
>
> The condition simply states some fact which must be true for the machine
> to transition to a particular state. The TM may or may not directly
> reference the condition in its algorithm. The design just needs to
> ensure that where it gets to is *consistent* with that condition.
>
> André
>

That pulls the focus of attention away from the point where is needs to
be thus making what I am saying impossible to understand.

The actual criterion measure is that embedded_H correctly transitions to
Ĥ.qn iff any recursive instance of the simulating halt decider of
embedded_H ever needs abort the simulation of its input to prevent the
infinite execution of Ĥ applied to ⟨Ĥ⟩

This is the same thing as saying embedded_H correctly transitions to
Ĥ.qn iff replacing embedded_H at Ĥ.qx with a UTM would cause Ĥ applied
to ⟨Ĥ⟩ to never halt.

This is the same thing as correctly applying the meaning of Ben's
notational conventions of the halt status criterion measure of H to
embedded_H of Ĥ.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<2P6zJ.67663$cW6.43497@fx08.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx08.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me> <sqirr2$brd$1@dont-email.me>
<z5OdneTRlcI4alH8nZ2dnUU7-IfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <z5OdneTRlcI4alH8nZ2dnUU7-IfNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 100
Message-ID: <2P6zJ.67663$cW6.43497@fx08.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 19:11:42 -0500
X-Received-Bytes: 5093
 by: Richard Damon - Thu, 30 Dec 2021 00:11 UTC

On 12/29/21 7:04 PM, olcott wrote:
> On 12/29/2021 5:43 PM, André G. Isaak wrote:
>> On 2021-12-29 16:18, André G. Isaak wrote:
>>> On 2021-12-29 15:53, olcott wrote:
>>>> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>>>>> On 2021-12-29 15:14, olcott wrote:
>>
>>>>>> When Linz says
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>> He is wrong.
>>>>>
>>>>> No, he is not.
>>>>>
>>>>
>>>> There is only one computation above that is actually Ĥ and that
>>>> computation includes embedded_H at Ĥ.qx.
>>>>
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.
>>>
>>> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself? He doesn't. Nothing
>>> in the above even remotely implies that, so I have no clue what your
>>> objection here actually is. You need to learn what this notation
>>> actually *means*.
>>
>> Just to clarify this, you need to understand what a condition actually
>> *means*.
>>
>> When we say:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff Ĥ applied to ⟨Ĥ⟩ halts
>>
>> the 'iff Ĥ applied to ⟨Ĥ⟩ halts' simply specifies what condition must
>> be met for Ĥ.q0 ⟨Ĥ⟩ to transition to Ĥ.qy ∞. It says nothing about how
>> the underlying algorithm works. In particular, it doesn't require that
>> Ĥ ever gets applied to ⟨Ĥ⟩ at some point in the computation.
>>
>> Consider the following simple TM:
>>
>> M.q0 w ⊢* M.qy iff 2 + 3 = 5.
>>
>> That describes a TM which accepts *every* input string it is given
>> because the condition which has been given is always true.
>>
>> This condition does *not* mean that an implementation of M has to
>> actually add numbers or compare two numbers. Said machine can simply
>> transition directly from its initial state to its final accepting
>> state without doing anything at all.
>>
>> The condition simply states some fact which must be true for the
>> machine to transition to a particular state. The TM may or may not
>> directly reference the condition in its algorithm. The design just
>> needs to ensure that where it gets to is *consistent* with that
>> condition.
>>
>> André
>>
>
> That pulls the focus of attention away from the point where is needs to
> be thus making what I am saying impossible to understand.
>
> The actual criterion measure is that embedded_H correctly transitions to
> Ĥ.qn iff any recursive instance of the simulating halt decider of
> embedded_H ever needs abort the simulation of its input to prevent the
> infinite execution of Ĥ applied to ⟨Ĥ⟩

which ISN'T the criteria for Halt Deciding, so you are just back to
talking POOP.

FAIL.

>
> This is the same thing as saying embedded_H correctly transitions to
> Ĥ.qn iff replacing embedded_H at Ĥ.qx with a UTM would cause Ĥ applied
> to ⟨Ĥ⟩ to never halt.

No. The UTM will halt, and thus indicate that the computation halts,
even if some embeded simulation needs to be halted.

If fact, in this case it is BECAUSE the embedded_H inside H^ aborts its
simulation and returns Non-Halting that H^(<H^>) is Halting.

This is the CORRECT answer for the UTM, and the answer that H SHOULD
have given, but didn't.

(Now, change H to give this, means we have a different H^, and the
correct answer might change).

>
> This is the same thing as correctly applying the meaning of Ben's
> notational conventions of the halt status criterion measure of H to
> embedded_H of Ĥ.
>

No, it isn't, you obvious stil don't understand what a UTM is.

Back to class.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<sqith1$kpq$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Date: Wed, 29 Dec 2021 17:12:15 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 49
Message-ID: <sqith1$kpq$1@dont-email.me>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me> <IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 30 Dec 2021 00:12:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="281e34967abc652e32513cf7d24af717";
logging-data="21306"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/sk4FTnZVAYEppnxLIfcVu"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:BtJ5vKlQLsHNe5iA84HHjnscf6w=
In-Reply-To: <IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 30 Dec 2021 00:12 UTC

On 2021-12-29 16:53, olcott wrote:
> On 12/29/2021 5:18 PM, André G. Isaak wrote:

>> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself?
>
> if Ĥ applied to ⟨Ĥ⟩ does not halt is referring to Ĥ.q0 ⟨Ĥ⟩, this is the
> [ persistent misconception ]

No one other than you has ever entertained that interpretation. Ĥ
applied to ⟨Ĥ⟩ refers to the *independent* computation Ĥ applied to ⟨Ĥ⟩

>> And you still need to explain what it means for an input to halt on
>> its input (a meaningless phrase) or what 'a UTM at Ĥ.qx' means.
>
> Do you understand that Ĥ.qx is an internal state of Ĥ?
> Do you know what a UTM is?

Yes and yes. How does that remotely address my question? How can a TM be
"at" a single internal state of a TM?

> H bases its halt status decision on the behavior of the UTM simulation
> of its input.
>
> embedded_H bases its halt status decision on the behavior of the UTM
> simulation of its input when this UTM simulation occurs at the same
> point in the execution trace where embedded_H is. embedded_H is at Ĥ.qx.
> embedded_H is not at Ĥ.q0.

What you call embedded_H is not "at" Ĥ.qx.

embedded_H refers to *everything* in the box below (requires monospaced
font)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Ĥ.q0 ⟨Ĥ⟩ ⊢* + Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩,⟨Ĥ⟩) halts +
Ĥ.q0 ⟨Ĥ⟩ ⊢* + Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

And a 'UTM simulation' doesn't occur "at" some point in Ĥ since Ĥ is
*not* a UTM, nor does it contain a UTM.

The UTM mentioned in the conditions is *not* part of the algorithm of Ĥ.
It simply specifies the conditions under which Ĥ reaches its final states.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<sqitub$mqc$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Date: Wed, 29 Dec 2021 17:19:22 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 93
Message-ID: <sqitub$mqc$1@dont-email.me>
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me> <sqirr2$brd$1@dont-email.me>
<z5OdneTRlcI4alH8nZ2dnUU7-IfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 30 Dec 2021 00:19:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="281e34967abc652e32513cf7d24af717";
logging-data="23372"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19DRoTZHH0IaVYQrcux97lk"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:G8TPUDmwEqk11Iw5clVptyFL1n8=
In-Reply-To: <z5OdneTRlcI4alH8nZ2dnUU7-IfNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 30 Dec 2021 00:19 UTC

On 2021-12-29 17:04, olcott wrote:
> On 12/29/2021 5:43 PM, André G. Isaak wrote:
>> On 2021-12-29 16:18, André G. Isaak wrote:
>>> On 2021-12-29 15:53, olcott wrote:
>>>> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>>>>> On 2021-12-29 15:14, olcott wrote:
>>
>>>>>> When Linz says
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>> He is wrong.
>>>>>
>>>>> No, he is not.
>>>>>
>>>>
>>>> There is only one computation above that is actually Ĥ and that
>>>> computation includes embedded_H at Ĥ.qx.
>>>>
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.
>>>
>>> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself? He doesn't. Nothing
>>> in the above even remotely implies that, so I have no clue what your
>>> objection here actually is. You need to learn what this notation
>>> actually *means*.
>>
>> Just to clarify this, you need to understand what a condition actually
>> *means*.
>>
>> When we say:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff Ĥ applied to ⟨Ĥ⟩ halts
>>
>> the 'iff Ĥ applied to ⟨Ĥ⟩ halts' simply specifies what condition must
>> be met for Ĥ.q0 ⟨Ĥ⟩ to transition to Ĥ.qy ∞. It says nothing about how
>> the underlying algorithm works. In particular, it doesn't require that
>> Ĥ ever gets applied to ⟨Ĥ⟩ at some point in the computation.
>>
>> Consider the following simple TM:
>>
>> M.q0 w ⊢* M.qy iff 2 + 3 = 5.
>>
>> That describes a TM which accepts *every* input string it is given
>> because the condition which has been given is always true.
>>
>> This condition does *not* mean that an implementation of M has to
>> actually add numbers or compare two numbers. Said machine can simply
>> transition directly from its initial state to its final accepting
>> state without doing anything at all.
>>
>> The condition simply states some fact which must be true for the
>> machine to transition to a particular state. The TM may or may not
>> directly reference the condition in its algorithm. The design just
>> needs to ensure that where it gets to is *consistent* with that
>> condition.
>>
>> André
>>
>
> That pulls the focus of attention away from the point where is needs to
> be thus making what I am saying impossible to understand.
>
> The actual criterion measure is that embedded_H correctly transitions to
> Ĥ.qn iff any recursive instance of the simulating halt decider of
> embedded_H ever needs abort the simulation of its input to prevent the
> infinite execution of Ĥ applied to ⟨Ĥ⟩
>
> This is the same thing as saying embedded_H correctly transitions to
> Ĥ.qn iff replacing embedded_H at Ĥ.qx with a UTM would cause Ĥ applied
> to ⟨Ĥ⟩ to never halt.

The conditions which Ben supplied don't even remotely resemble anything
you've written above.

His conditions makes no mention of 'replacing' embedded_H with a UTM. It
makes no mention of embedded_H needing to abort a simulation, let alone
'any recursive instance of embedded_H'.

You've invented an entirely new condition which bears no resemblance
whatsoever to the condition which defines a halt decider, and which is
too incoherently stated to even evaluate.

Linz's conditions are valid.
Ben's conditions are valid (though the addition of a UTM is pointless).
Your conditions are completely invalid.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<M37zJ.121132$IB7.78580@fx02.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder3.usenet.farm!feeder2.usenet.farm!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me> <IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 278
Message-ID: <M37zJ.121132$IB7.78580@fx02.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 19:29:32 -0500
X-Received-Bytes: 12461
 by: Richard Damon - Thu, 30 Dec 2021 00:29 UTC

On 12/29/21 6:53 PM, olcott wrote:
> On 12/29/2021 5:18 PM, André G. Isaak wrote:
>> On 2021-12-29 15:53, olcott wrote:
>>> On 12/29/2021 4:40 PM, André G. Isaak wrote:
>>>> On 2021-12-29 15:14, olcott wrote:
>>>>> On 12/29/2021 2:48 PM, André G. Isaak wrote:
>>>>>> On 2021-12-29 13:13, olcott wrote:
>>>>>>> On 12/29/2021 12:09 PM, André G. Isaak wrote:
>>>>>>>> On 2021-12-29 09:49, olcott wrote:
>>>>>>>>> Proving that embedded_H at Ĥ.qx correctly maps its inputs ⟨Ĥ⟩
>>>>>>>>> ⟨Ĥ⟩ to Ĥ.qn on the basis of the behavior of the UTM simulation
>>>>>>>>> of these inputs.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢*  ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> Those should be:
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>>>>>
>>>>>>>> Why do you insist on omitting the conditions in the above? They
>>>>>>>> are just as mandatory for Ĥ as they are for H.
>>>>>>>>
>>>>>>>
>>>>>>> When the conditions are applied to H it is every clear that H is
>>>>>>> determining whether or not its input halts. When they are applied
>>>>>>> to Ĥ it is ambiguous whether that apply to embedded_H or to the
>>>>>>> input to embedded_H.
>>>>>>
>>>>>> There is no ambiguity here, nor has there ever been any ambiguity.
>>>>>> The fact that you think there is simply demonstrates that you
>>>>>> don't understand the notation being used. And until you learn what
>>>>>> the notation means you really shouldn't be arguing about such things.
>>>>>>
>>>>>
>>>>> When Linz says
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>> He is wrong.
>>>>
>>>> No, he is not.
>>>>
>>>
>>> There is only one computation above that is actually Ĥ and that
>>> computation includes embedded_H at Ĥ.qx.
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is is not Ĥ itself.
>>
>> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself?
>
> if Ĥ applied to ⟨Ĥ⟩ does not halt is referring to Ĥ.q0 ⟨Ĥ⟩, this is the
> [ persistent misconception ]

WHY?

>
> It does not take a genius to see strcmp("Ĥ", "⟨Ĥ⟩") != 0

Which just means that you have not read the REQUIREMENTS for the problem.

Remember, the ORIGINAL specifiation is:

H wM w -> H.Qy iff M w Halts and
H wM w -> H.Qn iff M w Never Halts.

When we let M = H^, that means that wM is <H^> by definition, and then
we set w to a copy of that.

Thus the requriement is:

H <H^> <H^> -> H.Qy iff H^ <H^> Halts, and
H <H^> <H^> -> H.Qn iff H^ <H^> Never Halts.

See <H^> <H^> on the left and H^ <H^> on the right
Thats why H is given <H^> but is responsible for the behavior of H^,
even though that isn't the exact thing given, only its representation.

Yes we can change the M w or H^ <H^> to UTM wM w or UTM <H^> <H^> so it
becomes:

H <^> <H^> -> H.Qy iff UTM <H^> <H^> Halts, and
H <^> <H^> -> H.Qn iff UTM <H^> <H^> Never Halts

But since UTM <H^< <H^> behaves the same (Halts/Non-Halts) as H^ <H^> so
it isn't really saying anything new.

Note, the iff UTM <H^> <H^> does NOT mean that H needs to use a UTM, and
in fact, H can't use a pure UTM, but needs to modify it, as H is
required to answer its question in finite time, while the UTM will not
be bounded in execution time to show Non-Halting.

In order to use a UTM and then figure out if it will halt or not, you
need a working Halt Decider to do this, so you don't get any progress to
solving the problem.

You CAN perhaps solve a limited subset of non-halting computation with a
finite set of non-halting patterns, but it IMPOSSIBLE to come up with
one to handle H^ <H^> as any pattern you see and can thus detect, and
then abort and return Qn, turns out, by construction, to be a Halting
Pattern, as if H does detect it and return non-Halting, H^ will halt.

FAIL.

>
>> He doesn't. Nothing in the above even remotely implies that, so I have
>> no clue what your objection here actually is. You need to learn what
>> this notation actually *means*.
>>
>>>> And the conditions stated above are identical to the ones which Ben
>>>> provided. So if you claim Linz is wrong, you're also claiming that
>>>> the criteria Ben supplied which you have adopted are also wrong.
>>>>
>>>>>>>>> *My criterion measure with Ben's notational conventions*
>>>>>>>>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>>>>>>>>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>>>>>>>>
>>>>>>>>> We know that H would correctly decide the halt status of its
>>>>>>>>> input on the basis of correctly deciding the halt status of the
>>>>>>>>> UTM simulation of its input.
>>>>>>>>
>>>>>>>> Right. What that means in that H applied to wM w should
>>>>>>>> transition to H.qy in exactly those cases where the
>>>>>>>> *independent* computation UTM(wM, w) halts.
>>>>>>>>
>>>>>>>> That means that H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy
>>>>>>>> in exactly those cases where the *independent* computation
>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.
>>>>>>>>
>>>>>>>> And since the independent computation Ĥ ⟨Ĥ⟩ halts, we know that the
>>>
>>> It is a only an assumption that the independent computation Ĥ ⟨Ĥ⟩ halts.
>>
>> Then why have you acknowledged in the past that it does, in fact, halt?
>>
>>>>>>>> independent computation UTM ⟨Ĥ⟩ ⟨Ĥ⟩ also halts.
>>>>>>>>
>>>>>>>
>>>>>>> You don't know that Ĥ ⟨Ĥ⟩ halts you are only assuming this.
>>>>>>
>>>>>> Based on *your* descriptions of how your H and Ĥ work.
>>>>>
>>>>> Not at all. When we are analysing whether or not embedded_H
>>>>> transitions to Ĥ.qy or Ĥ.qn we cannot correctly assume either one.
>>>>
>>>> I'm not making any claims about what embedded_H transitions to. I am
>>>> stating what the correct answer is. H cannot give the correct answer.
>>>>
>>>>>> And you've already *acknowledged* that your Ĥ ⟨Ĥ⟩ halts on
>>>>>> numerous occasions.
>>>>>>
>>>>>>>>> We know this because a UTM simulation of the Turing machine
>>>>>>>>> description is computationally equivalent to the direct
>>>>>>>>> execution of this same Turing machine.
>>>>>>>>>
>>>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>>>> HERE IS WHERE PEOPLE GET STUCK
>>>>>>>>
>>>>>>>> You are the only one who is stuck.
>>>>>>>>
>>>>>>>>> We know that the copy of H is at Ĥ ⟨Ĥ⟩ halts.qx (AKA
>>>>>>>>> embedded_H) applies this same criterion measure to every
>>>>>>>>> instance of embedded_H to any recursive depth.
>>>>>>>>
>>>>>>>> This isn't even a coherent sentence.
>>>>>>>>
>>>>>>>
>>>>>>> When H is defined to base its halt status decision on the UTM
>>>>>>> simulation of its input then every embedded_H in Ĥ will do this
>>>>>>> same thing.
>>>>>>>
>>>>>>> If embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ results in embedded_H simulating
>>>>>>> its own Turing machine description then this simulated embedded_H
>>>>>>> will also base its halt status decision on the UTM simulation of
>>>>>>> its input.
>>>>>>
>>>>>> The problem is that the criterion which you are using (to the
>>>>>> extent that it is interpretable) *isn't* the actual condition
>>>>>> indicated in the description given above, i.e.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>>>
>>>>>
>>>>> Like I said this is ambiguous.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> Assuming that 'this' refers to the above two lines, they are
>>>> *incomplete*. You need to include the conditions. I don't get why
>>>> you find this so difficult to get.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt
>>>>
>>>> And there is absolutely *nothing* ambiguous about the above. What
>>>> possible ambiguity could there be?
>>>>
>>>>> The criterion measure can be applied to the above by referring to
>>>>> the embedded copy of H at Ĥ.qx as embedded_H.
>>>>>
>>>>> The input to embedded_H halts on its input
>>>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx would halt.
>>>>>
>>>>> The input to embedded_H halts on its input
>>>>> iff the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does not halt.
>>>>
>>>> The above two statements are contradictory.
>>>
>>> They are only contradictory it you assume that embedded_H is
>>> reporting on whether or not itself halts.
>>
>> Actually, I misspoke. They are not contradictory, but I assume they
>> are not what you actually meant to write since the above two
>> statements entail the following:
>>
>> The input to embedded_H halts on its input regardless of what the pure
>> simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by a UTM at Ĥ.qx does.
>>
>> And you still need to explain what it means for an input to halt on
>> its input (a meaningless phrase) or what 'a UTM at Ĥ.qx' means.
>
> Do you understand that Ĥ.qx is an internal state of Ĥ?
> Do you know what a UTM is?


Click here to read the complete article
Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<gaidnTntEIa_YlH8nZ2dnUU7-aHNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 29 Dec 2021 18:36:50 -0600
Date: Wed, 29 Dec 2021 18:36:50 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com> <sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com> <sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com> <sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com> <sqiqc6$4n5$1@dont-email.me> <IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com> <sqith1$kpq$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sqith1$kpq$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <gaidnTntEIa_YlH8nZ2dnUU7-aHNnZ2d@giganews.com>
Lines: 72
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-u0Xyj/JV4IcXlrlnXOmiKa2ZqFybn4dz0L1+4leo86CAbORHk18UICQNnd1nbkEPxiT256Tss8rnsP5!kdiO6/+TUFVL1LzLXpp1Rb5JzCDE1hHfPb034hLCD4FYJSwKXgCCZgVS5mBUHHBRaZCdbGchFvte!qw==
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: 4380
 by: olcott - Thu, 30 Dec 2021 00:36 UTC

On 12/29/2021 6:12 PM, André G. Isaak wrote:
> On 2021-12-29 16:53, olcott wrote:
>> On 12/29/2021 5:18 PM, André G. Isaak wrote:
>
>>> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself?
>>
>> if Ĥ applied to ⟨Ĥ⟩ does not halt is referring to Ĥ.q0 ⟨Ĥ⟩, this is the
>> [ persistent misconception ]
>
> No one other than you has ever entertained that interpretation. Ĥ
> applied to ⟨Ĥ⟩ refers to the *independent* computation Ĥ applied to ⟨Ĥ⟩
>
>>> And you still need to explain what it means for an input to halt on
>>> its input (a meaningless phrase) or what 'a UTM at Ĥ.qx' means.
>>
>> Do you understand that Ĥ.qx is an internal state of Ĥ?
>> Do you know what a UTM is?
>
> Yes and yes. How does that remotely address my question? How can a TM be
> "at" a single internal state of a TM?
>
>> H bases its halt status decision on the behavior of the UTM simulation
>> of its input.
>>
>> embedded_H bases its halt status decision on the behavior of the UTM
>> simulation of its input when this UTM simulation occurs at the same
>> point in the execution trace where embedded_H is. embedded_H is at
>> Ĥ.qx. embedded_H is not at Ĥ.q0.
>
> What you call embedded_H is not "at" Ĥ.qx.
>

embedded_H is exactly a copy of Linz H at Ĥ.qx. Everything else about
embedded_H come indirectly from the definition of H.

> embedded_H refers to *everything* in the box below (requires monospaced
> font)
>
>             ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Ĥ.q0 ⟨Ĥ⟩ ⊢* + Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩,⟨Ĥ⟩) halts        +
> Ĥ.q0 ⟨Ĥ⟩ ⊢* + Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt +
>             ++++++++++++++++++++++++++++++++++++++++++++++++++++++++

That is vague it could mean:
(a) The simulation of Ĥ applied to ⟨Ĥ⟩
(b) The simulation of the input ⟨Ĥ⟩ ⟨Ĥ⟩ embedded_H at 0 levels of nested
simulation
(c) The simulation of the input ⟨Ĥ⟩ ⟨Ĥ⟩ embedded_H at N levels of nested
simulation
(d) The simulation of the input ⟨Ĥ⟩ ⟨Ĥ⟩ embedded_H at ∞ levels of nested
simulation

> And a 'UTM simulation' doesn't occur "at" some point in Ĥ since Ĥ is
> *not* a UTM, nor does it contain a UTM.
>

THE CRITERION MEASURE OF H MEANS THE BEHAVIOR OF
Ĥ applied to ⟨Ĥ⟩ when embedded_H is replaced by a UTM.

> The UTM mentioned in the conditions is *not* part of the algorithm of Ĥ.
> It simply specifies the conditions under which Ĥ reaches its final states.
>
> André
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs V42 [where people get stuck]

<9h7zJ.87775$L_2.76665@fx04.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer03.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx04.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [where people
get stuck]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sqi88u$ai9$1@dont-email.me> <lYWdnVzlccb6XFH8nZ2dnUU7-ePNnZ2d@giganews.com>
<sqihk3$e5u$1@dont-email.me> <qpSdneigrPdXQFH8nZ2dnUU7-TGdnZ2d@giganews.com>
<sqio4l$m2k$1@dont-email.me> <hLydnR3Op_pEe1H8nZ2dnUU7-YfNnZ2d@giganews.com>
<sqiqc6$4n5$1@dont-email.me> <IfCdnadmi_OVaFH8nZ2dnUU7-c3NnZ2d@giganews.com>
<sqith1$kpq$1@dont-email.me> <gaidnTntEIa_YlH8nZ2dnUU7-aHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <gaidnTntEIa_YlH8nZ2dnUU7-aHNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 103
Message-ID: <9h7zJ.87775$L_2.76665@fx04.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 29 Dec 2021 19:43:48 -0500
X-Received-Bytes: 5015
 by: Richard Damon - Thu, 30 Dec 2021 00:43 UTC

On 12/29/21 7:36 PM, olcott wrote:
> On 12/29/2021 6:12 PM, André G. Isaak wrote:
>> On 2021-12-29 16:53, olcott wrote:
>>> On 12/29/2021 5:18 PM, André G. Isaak wrote:
>>
>>>> Where does Linz claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is Ĥ itself?
>>>
>>> if Ĥ applied to ⟨Ĥ⟩ does not halt is referring to Ĥ.q0 ⟨Ĥ⟩, this is the
>>> [ persistent misconception ]
>>
>> No one other than you has ever entertained that interpretation. Ĥ
>> applied to ⟨Ĥ⟩ refers to the *independent* computation Ĥ applied to ⟨Ĥ⟩
>>
>>>> And you still need to explain what it means for an input to halt on
>>>> its input (a meaningless phrase) or what 'a UTM at Ĥ.qx' means.
>>>
>>> Do you understand that Ĥ.qx is an internal state of Ĥ?
>>> Do you know what a UTM is?
>>
>> Yes and yes. How does that remotely address my question? How can a TM
>> be "at" a single internal state of a TM?
>>
>>> H bases its halt status decision on the behavior of the UTM
>>> simulation of its input.
>>>
>>> embedded_H bases its halt status decision on the behavior of the UTM
>>> simulation of its input when this UTM simulation occurs at the same
>>> point in the execution trace where embedded_H is. embedded_H is at
>>> Ĥ.qx. embedded_H is not at Ĥ.q0.
>>
>> What you call embedded_H is not "at" Ĥ.qx.
>>
>
> embedded_H is exactly a copy of Linz H at Ĥ.qx. Everything else about
> embedded_H come indirectly from the definition of H.

GOOD, why does it need a new name then?

You are normally bad in the other direction, having things that are
different be given the same name.
>
>> embedded_H refers to *everything* in the box below (requires
>> monospaced font)
>>
>>              ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* + Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ iff UTM(⟨Ĥ⟩,⟨Ĥ⟩) halts        +
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* + Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn iff UTM(⟨Ĥ⟩, ⟨Ĥ⟩) does not halt +
>>              ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> That is vague it could mean:
> (a) The simulation of Ĥ applied to ⟨Ĥ⟩
> (b) The simulation of the input ⟨Ĥ⟩ ⟨Ĥ⟩ embedded_H at 0 levels of nested
> simulation
> (c) The simulation of the input ⟨Ĥ⟩ ⟨Ĥ⟩ embedded_H at N levels of nested
> simulation
> (d) The simulation of the input ⟨Ĥ⟩ ⟨Ĥ⟩ embedded_H at ∞ levels of nested
> simulation

Since those are ALL the same computation, why does it matter?

>
>> And a 'UTM simulation' doesn't occur "at" some point in Ĥ since Ĥ is
>> *not* a UTM, nor does it contain a UTM.
>>
>
> THE CRITERION MEASURE OF H MEANS THE BEHAVIOR OF
> Ĥ applied to ⟨Ĥ⟩ when embedded_H is replaced by a UTM.

Nope, NEVER WAS.

Read the requirements, where does is say 'replace'.

FAIL, you LIAR.

The requirements are actually based on the ACTUAL behavior of the
represented machine,

The 'UTM' version is only allowed by the definition that the bahavior of
the computation its input is a representation of.

If you wanted to replace H with a UTM, you would need to use:

UTM <H> <H^> <H^> not UTM <H^> <H^>

Your replacing H with a UTM is effectively saying that your H is just a
pure UTM, which we know fails.

Either you LIE, or you are just a pitiful failure. (not that these are
exclusive, you actually do both).

>
>> The UTM mentioned in the conditions is *not* part of the algorithm of
>> Ĥ. It simply specifies the conditions under which Ĥ reaches its final
>> states.
>>
>> André
>>
>
>

Pages:123456
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor