Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1


computers / comp.theory / Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]

<RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 21 Aug 2021 11:04:28 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com> <87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <2j9UI.27154$VkD6.8027@fx01.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 21 Aug 2021 11:04:25 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <2j9UI.27154$VkD6.8027@fx01.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@giganews.com>
Lines: 179
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-dKXpIZstOo3Uo+EriMgTlvIhsApKNTH8IlPfCqlZ98/A6Ozu1/CFIMGbRyFMDtyFZSnJGtGJjWYAa+p!E2waHMtTERLFn+ghq4bxY25bubgeV5RFJX7IRVOd41ETZ8fUKxnaSESgX2wVmxben66A4a8y08EU!E5c=
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: 9742
 by: olcott - Sat, 21 Aug 2021 16:04 UTC

On 8/21/2021 10:52 AM, Richard Damon wrote:
> On 8/21/21 9:26 AM, olcott wrote:
>> On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/20/2021 3:40 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> I am not going to bother to answer all of this so that you
>>>>>>>>>>>> can stay
>>>>>>>>>>>> focused on one key point:
>>>>>>>>>
>>>>>>>>>>> You are not going to stay focused on the most serious error
>>>>>>>>>>> you have yet
>>>>>>>>>>> posted?
>>>>>>>>>>
>>>>>>>>>> You have to go though the following reasoning and point out the
>>>>>>>>>> specific error.
>>>>>>>>>
>>>>>>>>> The specific error is that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the
>>>>>>>>> computation of
>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ which, everyone agrees, is a halting
>>>>>>>>> computation.  Your
>>>>>>>>> statement of Aug 12th that
>>>>>>>>>
>>>>>>>>>       "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>>>>>
>>>>>>>>> is simply wrong in the simplest factual way.  I don't have to look
>>>>>>>>> anywhere else to point out the specific error.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you
>>>>>>> refuse
>>>>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>>>>> computation everything you say from here on is nonsense.
>>>>>>>
>>>>>>>> The executed Ĥ in the above expression only halts because of its
>>>>>>>> computational dependence on the halt status decision of the
>>>>>>>> simulating
>>>>>>>> halt decider on its input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do
>>>>>>> you
>>>>>>> still refuse to acknowledge that basic error?
>>>>>>>
>>>>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>>>>> dependence on the executed Ĥ.
>>>>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and the 2
>>>>>>> might help you explain when and how the encoded computation halts,
>>>>>>> but
>>>>>>> they don't alter the fact that identical strings encode identical
>>>>>>> computations.  In this case, halting ones.
>>>>>>
>>>>>> THIS SEEMS OVER YOUR HEAD:
>>>>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>>>>>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>>>>
>>>>> You need to correct the basic error before you can be taken seriously.
>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
>>>>> computation.
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>
>>> You don't say which is the case for you Ĥ.  Have you changed you mind?
>>> If not, there's not much point in giving both lines as only one will
>>> apply to your actual Ĥ.
>>>
>>> Of course the math poem is silly.  The simulation of an encoded TM
>>> behaves exactly the same (in terms of halting) as the TM itself.  And
>>> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
>>>
>>>>> Sadly, I suspect that this:
>>>>> a.  ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
>>>>>       strings that encode exactly the same computation.
>>>>
>>>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>>>> never halts.
>>>
>>> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
>>> it.  What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>>>
>>>> (2) From this you should be able to know that the simulating halt
>>>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>>>> its input.
>>>
>>> So what?  The "unless" applies: your H (embedded in Ĥ at qx) does halt
>>> (or stop as you disingenuously put it).  That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
>>> encodes a halting computation.
>>>
>>
>> The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never halts.
>
> WRONG.
>
> H^ <H^> Halts, so it is Halting.
>
> The PARTIALLY simulated <H^> <H^> was not simulated to its Halting
> state, but if this input is given to to a real pure simulator, it will Halt.
>
> Since, as you have said, the aborting of a simulation can not affect the
> halting status of that input,

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

I did not say that. I said the the decision to abort or not to abort is
based on whether or not the input to the simulating halt decider would
ever stop running while the simulating halt decider remains in
simulation mode.

As we can see by the following analysis the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩
never halts while the simulating halt decider at Ĥ.qx remains in
simulation mode.

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts. There is an infinite cycle from Ĵ.qx to Ĵ.q0.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the
⟨Ĵ2⟩ copy then
Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the
⟨Ĵ3⟩ copy then
Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
⟨Ĵ4⟩ copy then ...

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.

> the fact that the actual pure simulation
> of <H^> <H^> does go to a halt says that input is a Halting Input, and
> the status that H saw was't 'never halts' but 'hasn't halted yet'
>
>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that is exactly the same thing
>> as saying that because "This sentences is not true" that makes it true.
>
> WRONG. <H^> on <H^> is exactly Halting as that is what a real simulator
> says, and, as even you have stated, an aborted simulation doesn't affect
> the halting status of that input, so the fact that it didn't see the
> halting state does NOT imply that the input is non-halting.
>
>>
>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that requires Ĥ.qx to transition
>> to Ĥ.qy ∞ which makes it never halt.
>
>
> UNSOUDN
>
>>
>> So simply saying that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts is incorrect.
>> I understand that these things can be intellectually overwhelming.
>>
>
> UNSOUND.
>
> Yes, YOU have been intellectually overwhelmed by this logic.
>

--
Copyright 2021 Pete Olcott

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

SubjectRepliesAuthor
o How do we know H(P,P)==0 is the correct halt status for the input to

By: olcott on Sat, 14 Aug 2021

470olcott
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor