Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

* UNIX is a Trademark of Bell Laboratories.


computers / comp.ai.philosophy / Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

SubjectAuthor
* How do we know H(P,P)==0 is the correct halt status for the input toolcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
|+* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||`- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
|`* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
| `* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|  `- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|+- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|+- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (posolcott
|+* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||`* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
|| +- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ doolcott
|| `* Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||  +- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||  `* Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||   `* Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
||    `* Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott
||     `- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ diolcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ coolcott
`- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott

Pages:12
Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<feKdnXlevI0gdL78nZ2dnUU7-N_NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7280&group=comp.ai.philosophy#7280

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.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: Mon, 23 Aug 2021 13:32:29 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com> <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com> <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com> <368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 13:32:28 -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: <368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <feKdnXlevI0gdL78nZ2dnUU7-N_NnZ2d@giganews.com>
Lines: 52
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-O6QTzrB+Y8BPlJeniA9rl6/KzeGDizB51sBxkjvwL58XkYmQeM6TtRTxBxwufwxrQr1uF+CrXGgX8J2!ATsPTLSmztqCDC6Rhhspv6yXr3eVEKQ9akP26b+o8DFI/Cr2WEdRHslqtBiMKxI/c0Y86uWOX3Cz!VjY=
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: 4511
 by: olcott - Mon, 23 Aug 2021 18:32 UTC

On 8/23/2021 12:58 PM, Malcolm McLean wrote:
> On Monday, 23 August 2021 at 16:01:23 UTC+1, olcott wrote:
>> On 8/23/2021 9:43 AM, Malcolm McLean wrote:
>>
>>> So that's the crux of it. If you say that the behaviour of the function (C usage)
>>> can change based on its execution environment, you are no longer in the world of
>>> so-called "pure" mathematical functions.
>>>
>> It might superficially seem that way only because the concept of a
>> simulating halt decider is new and has not been extensively studied.
>>
> No one serious is interested in halt deciders for the same reason that no-one serious
> is interested in perpetual motion machines. If it is known that something cannot be
> achieved, you don't waste time on things that might look superficially as if they
> are getting there.
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> It is very obvious that the behavior the direct execution of the above
>> computation must be different than the behavior of the simulation of
>> this same computation under the dominion of a simulating halt decider.
>>
>> It is also quite obvious that the simulating halt decider does correctly
>> decide that Infinite_Loop() never halts.
>>
> So we agree that Infinite_Loop() is a computation, and never halts.
> H(Infinite_Loop), with whatever twiddles we need for the unused arguments,
> is also a computation. It halts and returns false.
>
> So that's a good basis to work from.
>

This conclusively proves that the direct execution of a machine is not
computationally equivalent to the simulation of the machine description
of this machine by a simulating halt decider when this machine never halts.

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

From this we can conclude that the fact that Ĥ.qx transitions to its
final state of Ĥ.qn and halts does not contradict the fact that Ĥ.qx
⟨Ĥ1⟩ ⟨Ĥ2⟩ did correctly decide that its input never halts.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

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

<INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7281&group=comp.ai.philosophy#7281

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!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: Mon, 23 Aug 2021 14:51:52 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com> <87czq5i9u0.fsf@bsb.me.uk> <srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com> <87y28tgt3w.fsf@bsb.me.uk> <xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com> <87h7fhgpjm.fsf@bsb.me.uk> <cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com> <87o89pf5zi.fsf@bsb.me.uk> <R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com> <87k0kce1yk.fsf@bsb.me.uk> <edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com> <87bl5oc62l.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 14:51:51 -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: <87bl5oc62l.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com>
Lines: 123
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-oCZlz/LEXByDNAvuMIAskh/4ylAarka9JDztFTLHy05/b0eauZdYADh7eQxxRUPiH5JCtwEXtNxwlGN!4CS6yeBV7ZMO6msrBJQ2e4KKYluaFLLjVUChpWgyFB7CpcSbQRpr9/wqPbOYhjkbvt3wJv8Yqhhz!paw=
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: 7205
 by: olcott - Mon, 23 Aug 2021 19:51 UTC

On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 8:16 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> When a computation is forced to stop running this is an entirely
>>>> different thing than a computation that stops running because it is
>>>> has completed all of its steps. If we allow this ambiguity to remain
>>>> then disingenuous double talk seems more plausible.
>>> How is a TM "forced" to do anything?
>>
>> You aready know this,
>
> Nope. I have no idea. TM's halt or they don't and they are never
> forced to do anything. You don't really know what it means either or
> you would have addressed the question of what it means seriously.
>
>> you are merely being tediously nit picky about my choice of words.
>
> As any journal editor or article reviewer would be. Be assured that I
> am being very generous is the errors I /don't/ pick up on. Your vague
> and undefined words will be absolutely shredded by anyone who has to
> read a paper should you ever think you can write one.
>
>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Truism:
>>>> Every simulation that would never stop unless Halts() stops
>>>> it at some point specifies infinite execution.
>>>
>>> Any algorithm that implements this truism is, of course, a halting
>>> decider.
>>
>> You must be an atheist because a Christian knows the penalty for
>> lying.
>
> You still won't answer my question will you? Avoid, avoid, avoid! You
> quote me approvingly -- does that mean you have changed your mind and
> you are now claiming to have an algorithm that decides halting (in
> general)? You have studiously avoided making that claim so far.
>

Whether or not I have an algorithm that correctly decides halting for
all inputs is a dishonest dodge away from the point at hand.

The point at hand is that when the above criteria is used by a partial
halt decider to decide the conventional halting problem counter-examples
then it does correctly decide that these counter-examples never halt.

>>> This is, despite the absurdity, a serious question. If I gave you a TM
>>> and an input, how could you tell the difference between it simply
>>> halting ("completing all of its steps") and being "forced to stop
>>> running"? If you can't do that (and I know you can't), you should be
>>> able to show me two TM computations, one which just halts and one which
>>> is forced to stop.
>
>> When any x86/TM machine...
>
> We are talking about TMs. You probably don't know what your words games
> mean anymore than I do which is why you avoided the question. (Avoid,
> avoid, avoid!)
>

I ignore dishonest dodges away from the point at hand.

>>> And for anyone else, here's why you are wrong about your H in two
>>> sentences. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
>>> applied to ⟨Ĥ⟩. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
>>> fact, accept it.
>>
>> That is a ridiculously foolish thing to say:
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>
>> By accepting the ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does halt) the input
>> never halts.
>
> By Jove, I think you've got it!! If I can stomach using your
> non-technical terms for once the converse also holds: By rejecting the
> ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does not halt) the input halts.

>>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
>>> applied to ⟨Ĥ⟩. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
>>> fact, accept it.

Which causes it to never halts thus your:

>>> Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in fact, accept it.
Is very stupidly incorrect.

> The only question is in which way your Ĥ (and thus your H) is wrong, and
> you've told us enough times: it's wrong because it rejects ⟨Ĥ⟩ ⟨Ĥ⟩. But
> ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation precisely because H rejects ⟨Ĥ⟩
> ⟨Ĥ⟩.
>
> But thanks (seriously) for pointing out my own bad wording. You are not
> wrong because H should accept the string ⟨Ĥ⟩ ⟨Ĥ⟩, you are wrong because
> your H rejects it. I'll try to be more careful in future.

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

H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn

When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
state of H.qn

Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩ ?

--
Copyright 2021 Pete Olcott

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

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

<Mf2dnamm9d978bn8nZ2dnUU7-cHNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7284&group=comp.ai.philosophy#7284

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Aug 2021 22:52:06 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com>
<8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com>
<87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>
<87czq5i9u0.fsf@bsb.me.uk> <srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com>
<87y28tgt3w.fsf@bsb.me.uk> <xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com>
<87h7fhgpjm.fsf@bsb.me.uk> <cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com>
<87o89pf5zi.fsf@bsb.me.uk> <R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com>
<87k0kce1yk.fsf@bsb.me.uk> <edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com>
<87bl5oc62l.fsf@bsb.me.uk> <INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com>
<87tujfbv4y.fsf@bsb.me.uk> <5bidne_8HrBuqbn8nZ2dnUU7-dfNnZ2d@giganews.com>
<87lf4rbksk.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 22:52:04 -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: <87lf4rbksk.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Mf2dnamm9d978bn8nZ2dnUU7-cHNnZ2d@giganews.com>
Lines: 245
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-y18WS8hrOd0zB16OIpVMbb6Qzgkaea/y4GLR1y3owGQa/IWVuSiZtQwkLj0YShGl2OfNLtpIQEfmQxP!H12jLTsvxOc0ipRpHtAsRl1pXiE/br80TuoAGEmI/g37s74JNrj88loxOofJMTZ49SUFo8Z2Z9pl!9dU=
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: 11874
 by: olcott - Tue, 24 Aug 2021 03:52 UTC

On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I ignore dishonest dodges away from the point at hand.
>>> OK, let's do that:
>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>> error.
>>>
>>>> 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.
>>> The details are mess, but basically, yes. Detail errors (that would get
>>> your paper rejected out of hand) available if you ask really nicely.
>>
>> Which details do you think are incorrect?
>
> A UTM is not a decider so the hat construction can't be applied to it.
> And if we make a "UTM-decider" (a TM that is a pure simulator except
> that is accepts those computations whose simulations terminate) we still
> can't apply the hat construction because it won't have a rejecting
> state. Thus your use of "exactly like Ĥ except..." is, at best,
> disingenuous. The differences must be greater than the "except..."
> clause suggests.
>

My whole purpose was to simply show what happens when the simulating
halt decide at Ĥ.qx only simulates its input.

We can still have the same final states, except now that are unreachable
dead code.

>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>> No, but that's just because you've never written a UTM so you don't know
>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>
>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting. Do you know
>>> what this notation means?
>>> And you have another problem which shows how shallow your thinking is.
>>> What is the state qn supposed to mean when J is a UTM?
>>
>> Ĥ.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
>>
>> Is it really that difficult to understand that I merely swapped Ĵ for
>> Ĥ in the Ĥ template to create the Ĵ tempate?
>
> I understand that you think you can just say that, but I also understand
> the "template" better than you appear to.
>
>>> Presumably you
>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>> simulating halting computations. So what's qn doing there? (J must
>>> have a qn for Ĵ to have qn.)
>>
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
> halts?

I am not claiming that. I am making a single change to Ĥ that now has
some unreachable dead code states.

> You just claimed the opposite. I think you are just typing
> symbols because they look good.
>
>> Ĵ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 ...
>
> No. Totally wrong. Your understanding of how a UTM works is
> embarrassingly shallow and I simply don't have time to explain it to
> you. In addition, you appear resistant to learning, so it would also be
> pointless. I can only suggest you change you attitude to learning and
> then read a book, Linz for example.

If the Ĥ template stipulates that those actions occur then they occur
when Ĥ has the one single modification of changing the simulating halt
decider at Ĥ.qx to a UTM.

>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>>> Typo: H.qn not Ĥ.qn.
>>
>> Yes, typo.
>>
>>>> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
>>>> state of H.qn
>>> If you say so. I can't know because you are hiding H
>>
>> It is the Linz H.
>
> Since, against my repeated advice, you chose to use the same symbol for
> your actual TM as Linz does for his empty class of TMs you need to be
> more careful distinguishing them.

Apparently most all of the textbooks call this H.

> "The original H" is not clear and
> discussion of it should be phrased hypothetically. You should talk
> about what Linz's H is specified to do, not what it does.
>

Yes that makes sense.

> But since you brought up Linz's H, here's a question (get your avoidance
> waffle ready!). What is Linz's H specified to do when applied to your
> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
> after the ⊢* here:
>

I am breaking that analysis down to its simpler components. We take the
Linz Ĥ and change the simulating halt decider at Ĥ.qx to a UTM and
rename this new machine Ĵ. The new machine has come dead code staes that
are never reached.

Now we apply the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩ and H transitions to its final state
of H.qn indicating that Ĵ applied to ⟨Ĵ⟩ never halts.

> L.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ?
>
> I really expect an answer to this. If you can't answer, be honest and
> say you can't.

Maybe it is easier now.

>
>>> (well, you don't
>>> actually have a TM H we are just playing pretend here). For all I know,
>>> your H gets this case wrong as well, but I am prepared to accept what
>>> you say about it.
>>
>> It is the Linz H: Nitwit !!!
>
> You should give some thought to being more respectful.

I only call people a nitwit when they seem to being too disrespectful to
me. Richard disrespectfully fails to distinguish between the words
"before" and "after" so I gave up on him.

I cannot believe that he actually fails to understand what all grade
school kids understand, he is merely playing head games beyond my
tolerance threshold.

>
>>>> Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>>>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩
>>>> ⟨Ĵ⟩ ?
>>>
>>> I am not going to answer trivial, patronising questions.
>>
>> It it a mandatory prerequisite to the next step of my proof that you
>> are persistently (intentionally ?) failing to understand.
>
> Don't be daft. You can present your argument whether or not I answer
> your patronising questions. If you choose not to, that suits me better
> because there will be fewer errors to point out if you keep it to
> yourself.
>
>> If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩
>>
>> then you should be able to understand that
>>
>> the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally
>> equivalent to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> That is beyond absurd. I leave it to you spot the silly error in your
> reasoning (though you almost certainly won't be able to). And you will
> need to account for the fact that both
>

My only "error" is that you very persistently and thus disrespectfully
fail to bother to pay attention to my proof that this is correct.

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
Output("Input_Halts = ", H1((u32)P, (u32)P));
P((u32)P);
}

The fact that the first line of main() does produce different results
than the second line of main conclusively proves that these two
computations are computationally distinct different computations.


Click here to read the complete article
Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]

<__WdneskYvGLiLj8nZ2dnUU7-U3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7285&group=comp.ai.philosophy#7285

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!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: Tue, 24 Aug 2021 10:49:42 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com> <87czq5i9u0.fsf@bsb.me.uk> <srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com> <87y28tgt3w.fsf@bsb.me.uk> <xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com> <87h7fhgpjm.fsf@bsb.me.uk> <cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com> <87o89pf5zi.fsf@bsb.me.uk> <R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com> <87k0kce1yk.fsf@bsb.me.uk> <edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com> <87bl5oc62l.fsf@bsb.me.uk> <INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com> <87tujfbv4y.fsf@bsb.me.uk> <5bidne_8HrBuqbn8nZ2dnUU7-dfNnZ2d@giganews.com> <87lf4rbksk.fsf@bsb.me.uk> <Mf2dnamm9d978bn8nZ2dnUU7-cHNnZ2d@giganews.com> <87fsuzaq8t.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Aug 2021 10:49:40 -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: <87fsuzaq8t.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <__WdneskYvGLiLj8nZ2dnUU7-U3NnZ2d@giganews.com>
Lines: 465
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-trY0X0/vxGAhGOZ3PgvnAs7jClnoK6dAGBTkeIikazdxAyr9XYcgNRz0OWOTgG9qvXLav1uzELeYQk8!YBgUFHYjGft1KBxb9e2Y3zweIIvq7am/BnR328Siz/oT6pxnUycW2MZt2wMflme3+1gRN6FubSqU!Q4E=
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: 21726
 by: olcott - Tue, 24 Aug 2021 15:49 UTC

On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>> OK, let's do that:
>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>>>> error.
>>>>>
>>>>>> 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.
>>>>> The details are mess, but basically, yes. Detail errors (that would get
>>>>> your paper rejected out of hand) available if you ask really nicely.
>>>>
>>>> Which details do you think are incorrect?
>>>
>>> A UTM is not a decider so the hat construction can't be applied to it.
>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>> that is accepts those computations whose simulations terminate) we still
>>> can't apply the hat construction because it won't have a rejecting
>>> state. Thus your use of "exactly like Ĥ except..." is, at best,
>>> disingenuous. The differences must be greater than the "except..."
>>> clause suggests.
>>
>> My whole purpose was to simply show what happens when the simulating
>> halt decide at Ĥ.qx only simulates its input.
>
> I know, but you wanted to know what details you'd got wrong.
>

If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
and then rename this machine to Ĵ and I did swap swap the simulating
halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it is
a God damned lie that I got anything wrong.

>> We can still have the same final states, except now that are
>> unreachable dead code.
>
> Except you show below this unreachable state being reached:
>

No I do frigging not. The code is still there but the infinite cycle
from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.

> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
> Do you see why I don't think you know what you are saying?

The you imagine what I mean to say instead of examining what I actually
say is your mistake.

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

is transformed into this machine:
Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
infinitely nested simulation

>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>
>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>
>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>
> This needs to be addressed.

That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is flatly
wrong. The design of Ĥ as a simulating halt decider stipulates that
there is a cycle from Ĥ.qx to Ĥ.q0. Changing the simulating halt decider
at Ĥ.qx to a UTM at Ĵ.qx makes this cycle infinite.

>>>>> And you have another problem which shows how shallow your thinking is.
>>>>> What is the state qn supposed to mean when J is a UTM?
>>>>
>>>> Ĥ.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
>>>>
>>>> Is it really that difficult to understand that I merely swapped Ĵ for
>>>> Ĥ in the Ĥ template to create the Ĵ tempate?
>>> I understand that you think you can just say that, but I also understand
>>> the "template" better than you appear to.
>>>
>>>>> Presumably you
>>>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>>>> simulating halting computations. So what's qn doing there? (J must
>>>>> have a qn for Ĵ to have qn.)
>>>>
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>
>>> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
>>> halts?
>>
>> I am not claiming that.
>
> So why did you write Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn?

Because that <is> the Ĥ code with the single adaptation of swapping the
simulating halt decider at Ĥ.qx with a UTM at Ĵ.qx.

> You wrote a
> formal description of something that is impossible (qn is unreachable if
> it exists at all) and which even if it were possible is not what Ĵ
> applied to ⟨Ĵ⟩ does? No, you wrote something daft without thinking or
> maybe without know what it meant.

I wanted to make a single change to Ĥ so that I could show that the
input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ really does specify an infinite cycle that must
be aborted by its simulating halt decider. You seemed to be having an
impossibly difficult time understanding this.

>> I am making a single change to Ĥ that now has some unreachable dead
>> code states.
>
> Which state? Ĵ.qn? The one you show Ĵ.q0 ⟨Ĵ⟩ transitioning to? Yeah,
> sure.
>
>>>> Ĵ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 ...
>>> No. Totally wrong. Your understanding of how a UTM works is
>>> embarrassingly shallow and I simply don't have time to explain it to
>>> you. In addition, you appear resistant to learning, so it would also be
>>> pointless. I can only suggest you change you attitude to learning and
>>> then read a book, Linz for example.
>>
>> If the Ĥ template stipulates that those actions occur then they occur
>> when Ĥ has the one single modification of changing the simulating halt
>> decider at Ĥ.qx to a UTM.
>
> No. Give this up. You don't understand what a UTM is, and I can't
> possibly teach you. You have the result you want: the "other TM
> computation" is non-halting but it does not do that in the way you
> think, but if you keep giving details, I'll have to keep replying that
> you are wrong.
>
>>>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>>>>> Typo: H.qn not Ĥ.qn.
>>>>
>>>> Yes, typo.
> ...
>>>> It is the Linz H.
>>>
>>> Since, against my repeated advice, you chose to use the same symbol for
>>> your actual TM as Linz does for his empty class of TMs you need to be
>>> more careful distinguishing them.
>>
>> Apparently most all of the textbooks call this H.
>
> Which is further evidence that you should not. These books use H to
> refer to a hypothetical member of an empty class of TMs. Your H is
> real. It does stuff. It is not a member of an empty set. And gets at
> least one instance of the halting problem wrong because your H rejects
> the string ⟨Ĥ⟩ ⟨Ĥ⟩.
>

When I refer to the Linz H it is still hypothetical because I do not
show all of the steps.

>>> But since you brought up Linz's H, here's a question (get your avoidance
>>> waffle ready!). What is Linz's H specified to do when applied to your
>>> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
>>> after the ⊢* here:
>>>
>>
>> I am breaking that analysis down to its simpler components.
>
> So you are not going to answer. OK, it was a lot to expect -- a direct
> answer to a simple question.
>


Click here to read the complete article
Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]

<O-2dnRzfiOJg1Lf8nZ2dnUU7-V3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=7290&group=comp.ai.philosophy#7290

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!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: Sat, 28 Aug 2021 09:36:45 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<5L-dnYPQCYavN7r8nZ2dnUU7-eednZ2d@giganews.com>
<p8WdnTRK2qBPMbr8nZ2dnUU7-c3NnZ2d@giganews.com> <sg8fk0$v9f$1@dont-email.me>
<0vydnSb6TL2ZW7r8nZ2dnUU7-TfNnZ2d@giganews.com> <sg8l27$bb1$1@dont-email.me>
<CpudnZ-zNfqdRLr8nZ2dnUU7-S2dnZ2d@giganews.com>
<%dVVI.4471$o45.2514@fx46.iad>
<e5qdnexvgZsdvLX8nZ2dnUU7-WednZ2d@giganews.com> <HJWVI.42$dI3.12@fx10.iad>
<sg9do3$620$1@dont-email.me> <SLidnUazxu8Mz7X8nZ2dnUU7-WfNnZ2d@giganews.com>
<634WI.2231$tG6.308@fx39.iad> <-L-dnaA4AcGTb7X8nZ2dnUU7-VXNnZ2d@giganews.com>
<sgasok$ssl$1@dont-email.me> <Jc-dnWjkGtc3nbT8nZ2dnUU7-Y3NnZ2d@giganews.com>
<sgb20e$ojg$1@dont-email.me> <N_-dne9M3cTwjbT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sgb6d9$4qs$1@dont-email.me> <87fsuu8mkd.fsf@bsb.me.uk>
<b-ydnSYC0bYOKrT8nZ2dnUU7-V-dnZ2d@giganews.com> <87a6l19352.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 28 Aug 2021 09:36:44 -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: <87a6l19352.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <O-2dnRzfiOJg1Lf8nZ2dnUU7-V3NnZ2d@giganews.com>
Lines: 96
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1nkZ4calkgKaNDeT8EP5LEqZf3I4nOlissD7F4OP+8sLX++KtlRC2TibvUyyZZRiLESM8U4qFKhiIfU!Q3x5FZJGmzKEKwm4uN0nWvsvul8QOZMQzYBrp4RZy8x4o5e3QzZsZ1MxCvwUK1dA+twT7AkcCrqt!aZM=
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: 6601
 by: olcott - Sat, 28 Aug 2021 14:36 UTC

On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/27/2021 7:01 PM, Ben Bacarisse wrote:
>>> André G. Isaak <agisaak@gm.invalid> writes:
>>>
>>>> On 2021-08-27 10:18, olcott wrote:
>>>>> On 8/27/2021 10:57 AM, André G. Isaak wrote:
>>>
>>>>>> Ben never made any claims that it didn't perform some operation
>>>>>> which could be construed as the functional equivalent of copying a
>>>>>> string. He claimed that there was no *literal* copying involved
>>>>>> except in the first instance.
>>> Indeed. I see in my absence there's been a flurry of "Ben is wrong"
>>> posts from PO. Thanks, to you and RD, for stepping in.
>>>
>>>>> So in other words he said that my high level abstraction was wrong on
>>>>> the basis that it was a high level abstraction and did not delve into
>>>>> the tedious details of how this high level abstraction is
>>>>> implemented.
>>>>
>>>> No, he was claiming that your high level abstraction was *misleading*
>>>> and belied a lack of understanding of UTMs on your part.
>>> At the time I was actually calling out hard errors of fact, not just
>>> misleading abstractions. I was (dangerously) prepared to go along with
>>> the abstract view, as I (and others) have done for some time, because,
>>> whilst I agree it is potentially misleading, it's not actually wrong.
>>> But PO did not think he was talking about abstractions at the time I
>>> called him out on the mistake. He really did think that if you do the
>>> "hat" construction on a TM that is little more that a UTM, then it --
>>> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
>>> it to go from what he calls qx (the UTM's q0) back (via other states of
>>> course) to UTM^'s q0. And he thought that this loop is what wrote the
>>> endless literal copies. He used Linz's notation for TM configurations
>>> to show the strings right there on the tape next to each other, mid
>>> computation, with q0 being entered again and again.
>>
>> It does have literal endless copies and no one besides you has claimed
>> otherwise.
>
> (1) Of something, yes, but of what? Not of what you claimed.
>

When the TM copies a string the UTM must perform the functional
equivalent of copying a string. It could be as simple as a literal copy
of a string (with the additional overhead of simulation). From the
simulated TM's perspective it is a literal copy of a string.

> (2) Are you backing down from your claim about the loop in the state
> transition graph?
>

The loop in the state transition graph applies to the template as I
explicitly showed in the execution trace:

Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its
input ⟨Ĵ2⟩
which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with
its input ⟨Ĵ3⟩
which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with
its input ⟨Ĵ4⟩ ...

Ĵ copies Ĵ.qx simulates which essentially transitions to Ĵ1.q0.
This is not the conventional notion of a state transition within the
same machine. It is a more figurative use of the term so the gist of the
behavior can be understood. I changed my paper so that it no longer
refers to this cycle because the unconventional use of a term could be
more difficult to understand.

H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy

The bottom line of all of this is that H could recognize the infinitely
nested simulation of Ĵ applied to ⟨Ĵ⟩ and correctly decide that Ĵ
applied to ⟨Ĵ⟩ never halts.

> (3) You have it backwards. I only see posters agreeing with me on this
> topic.

They are careful to use double-talk that does not directly contradict
what you said. Since it is possible that the simulated Ĵ could perform a
literal string copy (having the additional overhead of simulation) your
statement that this is not what is occurring is flat out incorrect.

>>> Even if he now tries to suggest that he was using the notation in some
>>> sort of abstract way, the explicit cycle in the states gives a lie to
>>> that. He thought it was actual, literal, symbol by symbol copying every
>>> time, exactly as the extra states added by the hat construction do it.
>

--
Copyright 2021 Pete Olcott

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

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor