Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"When the going gets tough, the tough get empirical." -- Jon Carroll


computers / comp.theory / Re: Concise refutation of halting problem proofs V42 [honest dialogue]

Re: Concise refutation of halting problem proofs V42 [honest dialogue]

<h1oAJ.2248$jW.383@fx05.iad>

  copy mid

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

  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 [honest
dialogue]
Content-Language: en-US
Newsgroups: comp.theory
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<84CdnTM0Q4S5SlD8nZ2dnUU7-dudnZ2d@giganews.com>
<1TkzJ.169794$SW5.45468@fx45.iad>
<C-CdnTurLLHXeVD8nZ2dnUU7-RXNnZ2d@giganews.com> <sqktb6$thq$1@dont-email.me>
<qLidnVby_aDjlFP8nZ2dnUU7-UHNnZ2d@giganews.com> <sql4qd$dre$1@dont-email.me>
<W8OdnXzQIutMhlP8nZ2dnUU7-Q3NnZ2d@giganews.com> <sql6he$khm$1@dont-email.me>
<Y_mdnZp_XMbuvFP8nZ2dnUU7-dPNnZ2d@giganews.com> <sqnutn$lbd$1@dont-email.me>
<s_2dnY4DMJt2FlL8nZ2dnUU7-eednZ2d@giganews.com> <sqo3vg$lun$1@dont-email.me>
<FeydnXVBhLMqB1L8nZ2dnUU7-cvNnZ2d@giganews.com> <sqo9o5$hh6$1@dont-email.me>
<coadnR-r2Yc4NlL8nZ2dnUU7-S2dnZ2d@giganews.com> <sqob91$nom$1@dont-email.me>
<sqsikv$6f8$1@dont-email.me> <kDlAJ.59526$Ak2.20707@fx20.iad>
<kdCdnfylmorRdkz8nZ2dnUU7-XnNnZ2d@giganews.com>
<M9mAJ.101961$hm7.80744@fx07.iad> <sqstrv$u15$1@dont-email.me>
<PanAJ.134221$SR4.1629@fx43.iad> <sqsvcm$9ds$1@dont-email.me>
<mwnAJ.82826$b%.13705@fx24.iad>
<DLGdnclJXJOalE_8nZ2dnUU7-bHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <DLGdnclJXJOalE_8nZ2dnUU7-bHNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 164
Message-ID: <h1oAJ.2248$jW.383@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: Sun, 2 Jan 2022 15:36:33 -0500
X-Received-Bytes: 9117
 by: Richard Damon - Sun, 2 Jan 2022 20:36 UTC

On 1/2/22 3:20 PM, olcott wrote:
> On 1/2/2022 2:01 PM, Richard Damon wrote:
>> On 1/2/22 2:45 PM, olcott wrote:
>>> On 1/2/2022 1:38 PM, Richard Damon wrote:
>>>> On 1/2/22 2:19 PM, olcott wrote:
>>>>> On 1/2/2022 12:29 PM, Richard Damon wrote:
>>>>>> On 1/2/22 1:13 PM, olcott wrote:
>>>>>>> On 1/2/2022 11:52 AM, Richard Damon wrote:
>>>>>>>> On 1/2/22 11:07 AM, olcott wrote:
>>>>>>>>> On 12/31/2021 7:37 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-12-31 18:17, olcott wrote:
>>>>>>>>>>> On 12/31/2021 7:11 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-12-31 17:05, olcott wrote:
>>>>>>>>>>>>> On 12/31/2021 5:33 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-12-31 16:02, olcott wrote:
>>>>>>>>>>>>>>> On 12/31/2021 4:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An actual computer scientist will understand that
>>>>>>>>>>>>>>> embedded_H does compute the mapping from these inputs
>>>>>>>>>>>>>>> finite strings ⟨Ĥ⟩ ⟨Ĥ⟩ to this final state Ĥ.qn on the
>>>>>>>>>>>>>>> basis that the actual input would never halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You're not really in a position to state what an actual
>>>>>>>>>>>>>> computer scientist would understand. Only an actual
>>>>>>>>>>>>>> computer scientist can do that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is a self-evident truth that:
>>>>>>>>>>>>> (a) The pure simulation of the Turing machine description
>>>>>>>>>>>>> of a machine is computationally equivalent to the direct
>>>>>>>>>>>>> execution of this machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b) The pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>> never halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (c) If the pure simulation of the input to a halt decider
>>>>>>>>>>>>> would never halt then the halt decider correctly decides
>>>>>>>>>>>>> that this input does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A computer scientist would understand these things.
>>>>>>>>>>>>
>>>>>>>>>>>> It would appear that you ignored (and cut) all the actual
>>>>>>>>>>>> points in my post.
>>>>>>>>>>>>
>>>>>>>>>>>> Why don't we simplify things a bit. When Ĥ ⟨Ĥ⟩ is called,
>>>>>>>>>>>> how does Ĥ determine that its input describes itself? You
>>>>>>>>>>>> claim this is done by string comparisons, but which strings
>>>>>>>>>>>> are being compared? The only string Ĥ has access to its
>>>>>>>>>>>> input string. What does it compare this string with?
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So far I have not gotten to any point of closure on anything
>>>>>>>>>>> that I have said. I must insist on points of closure for
>>>>>>>>>>> continued dialogue.
>>>>>>>>>>>
>>>>>>>>>>> Do you agree that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by
>>>>>>>>>>> embedded_H would never halt?
>>>>>>>>>>
>>>>>>>>>> Of course I don't, since that claim is simply false.
>>>>>>>>>>
>>>>>>>>>> Now why don't you actually answer the question I asked?
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For simplicity we will refer to the copy of Linz H at Ĥ.qx
>>>>>>>>> embedded_H.
>>>>>>>>>
>>>>>>>>> Simplified syntax adapted from bottom of page 319:
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> If embedded_H would never stop simulating its input ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> this input would never reach a final state and stop running.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right, so Hn generates an H^n that never halts when computing
>>>>>>>> Hn^ <Hn^>
>>>>>>>>
>>>>>>>> But Hn <Hn^> <Hn^> doesn't answer, so it doesn't get the right
>>>>>>>> answer.
>>>>>>>>
>>>>>>>
>>>>>>> If the simulation of the input would never reach its final state
>>>>>>> if embedded_H would never stop its simulation then embedded_H can
>>>>>>> stop its simulation at any point and report that its input meets
>>>>>>> the Linz definition of not halting.
>>>>>>
>>>>>> No, it can't, because you made a change to the code in H^ when you
>>>>>> did that, thus invalidating your previous determination.
>>>>>>
>>>>>
>>>>> Not at all. The code remains the same. In the same way that a halt
>>>>> decider need not actually eternally simulate an infinite loop to
>>>>> determine that this simulation would never reach any final state
>>>>> the halt decider determines that infinitely nested simulations
>>>>> would never reach their final state.
>>>>
>>>> Impossible. Please prove this assertion.
>>>>
>>>
>>> An algorithm can correctly predict the future behavior of a computation.
>>
>> No, it can't, at least not universally correctly.
>>
>> It is PROVEN that some programs can not be predicted without running
>> them to their end, and that might take an infinite number of steps.
>>
>
> Simplified syntax adapted from bottom of page 319:
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> If embedded_H would never stop simulating its input ⟨Ĥ⟩ ⟨Ĥ⟩
> this input would never reach a final state and stop running.
>
> These steps would keep repeating:
> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
>
> Since it is obvious that the pure simulation of the input to embedded_H
> never reaches its final state then it is obvious that when embedded_H
> transitions to Ĥ.qn it is correct.

But if embedded_H never stops its simulation, it can never actually GO
to H.qn.

If embedded_H was able to abort its simulation, then it never was the
UTM needed to be the arbiter of Halting, that is reserved for a real UTM.

The problem is that you are applying the wrong logic to the problem.

You are imagining TWO DIFFERENT Hs which lead to TWO DIFFERENT H^s, the
behavior of one does not imply the same behavior of the other. This is
why your logic is UNSOUND.

Instead, you need to imagine what would happen if JUST the top H was
replaced with a UTM, but the input keeps its exact same coding which has
the original H encoded in it. If this never halts, and H answered
non-halting, then H was right, or it it halts and H answered Halting,
then H was also right. The problem is that if H answer Non-Halting, then
H^ will Halt, so H is WRONG.

The test is the test specified by the DEFINITION of the Halt Decider:

H wM w -> Qy iff M w Halts and H wM w -> Qn iff M w Never Halts.
which is equivalent to:

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

Note, it doesn't say change any copys of H that happen to be in the
representation of M or w, only apply the input EXACTLY as given to H to
the UTM and see what it does. This is also ONLY a TEST of the behavior,
since H needs to give its answer in finite time and UTM the UTM never
stops for the Non-Halting case, you can't just use a UTM for the actual
decider.

I have also show you the proof that there is no finite list of finite
patterns that H can use to decide to abort a UTM like simulation to make
the decision.

FAIL.

SubjectRepliesAuthor
o Concise refutation of halting problem proofs V42 [where people get

By: olcott on Wed, 29 Dec 2021

126olcott
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor