Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

"Besides, I think [Slackware] sounds better than 'Microsoft,' don't you?" (By Patrick Volkerding)


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

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 Holcott
|+* 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 Holcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
+- Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
+* Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
|`* 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 Holcott
+- 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 Holcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
+* 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 Holcott
|+* 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 Holcott
|| `* Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
||  +- Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
||  `* Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
||   `* Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
||    `* 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 Holcott
|`- Re: How do we know H(P,P)==0 is the correct halt status for the input to Holcott
`- Re: How do we know H(P,P)==0 is the correct halt status for the inputolcott

Pages:12
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 23 Aug 2021 18:32 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
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
View all headers
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


Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 23 Aug 2021 19:51 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
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
View all headers
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


Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 24 Aug 2021 03:52 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
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
View all headers
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.

The first line of main() decides that its input never halts. Because it is the only halt decider it must abort the simulation of its input or its input never halts.

The second line of main() uses an exact copy H1 of H and reports that its input halts. It can see that another halt decider will abort its input.

The third lines of main() halts.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  (via Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩)

and

    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

and how that can be true of computations that are not "computationally
equivalent".  (You don't give the final state of the tape but it will be
the same in both cases.)  Let me be clear: the reasoning is silly (how
you go from one assertion to the next) and the conclusion is wrong.
This is not "failing to understand" it is "knowing more about the
subject than you do".

Your understanding of TM computations is woefully inadequate to discuss
these matters.  Almost everything you say contains errors, many of them
huge errors that render your arguments null and void.  Even so, nothing
you say addresses the reason why your H is not a halt decider.  Your H
(not Linz's H) rejects a string that encodes a halting computation.
It's as simple as that.


TM's always leave most of their behavior to the imagination.
The C code that I referenced is fully operational and shows every step.

Click here to read the complete article
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 24 Aug 2021 15:49 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
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
View all headers
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.


Do you think that the Linz H might possibly do what Linz specified or do you think that maybe I mean for it to go to the store and buy some groceries? It is a very disingenuous question. Beside that I am freaking applying the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩, not ⟨Ĥ⟩ ⟨Ĥ⟩.

If you want to see the result of applying a halt decider to a machine with its own halt decider look at:

// 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 = ", H1((u32)P, (u32)P));
}

H1 is an exact copy of H and in the above configuration decides that P halts.

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.

That won't help you say what Linz's H specified to do when applied to
/your/ ⟨Ĥ⟩ ⟨Ĥ⟩.  Note: to your ⟨Ĥ⟩ ⟨Ĥ⟩.


The question is off-topic.
I am only applying Ĥ to ⟨Ĥ⟩ or H to ⟨Ĵ⟩.

Because of my recent empirical analysis with H1/P it would seem that H applied to ⟨Ĥ⟩ would transition to its final state of H.qy. Prior to this empirical analysis I had no way to verify what would happen.

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

Which is not what I was asking about.

I just answered that.


    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.

Click here to read the complete article
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Sat, 28 Aug 2021 14:36 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
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
View all headers
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
rocksolid light 0.7.2
clearneti2ptor