Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

<<<<< EVACUATION ROUTE <<<<<


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 ]

<YE9UI.29582$LV.6996@fx05.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx05.iad.POSTED!not-for-mail
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>
<RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 226
Message-ID: <YE9UI.29582$LV.6996@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: Sat, 21 Aug 2021 12:15:50 -0400
X-Received-Bytes: 11107
 by: Richard Damon - Sat, 21 Aug 2021 16:15 UTC

PPPPPPPP OOOOOO OOOOOO PPPPPPPP
PP PP OO OO OO OO PP PP
PP PP OO OO OO OO PP PP
PPPPPPPP OO OO OO OO PPPPPPPP
PP OO OO OO OO PP
PP OO OO OO OO PP
PP OOOOOO OOOOOO PP

Peter Olcott's Other Problem

On 8/21/21 12:04 PM, olcott wrote:
> 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.

YOu DENY that you have made the assertion that the fact that a simulator
aborts a simulation does not affect the halting status of the input?

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

But by looking at the trace of UTM <H^1><H^2> we see that it WILL Halt,
it just is a fact that for your current definion of H it aborts its
simulation too soon.

Remmber, H is NOT a variable in a given run.

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

WRONG.

The fact that H^ starts in a mode you (incorrectly) call 'pure
simulation mode' does not mean that you get to ignore in its simulation
of the copy of itself that that machine will leave this mode and thus
show that it NEVER WAS a PURE SIMULATOR.

That you just can't understand that just shows where you mind is. It is
stuck in a world of fantasy and inconsistency and is really just full of

PPPPPPPP OOOOOO OOOOOO PPPPPPPP
PP PP OO OO OO OO PP PP
PP PP OO OO OO OO PP PP
PPPPPPPP OO OO OO OO PPPPPPPP
PP OO OO OO OO PP
PP OO OO OO OO PP
PP OOOOOO OOOOOO PP

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

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.81
clearnet tor