Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Variables don't; constants aren't.


computers / comp.ai.philosophy / Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]

SubjectAuthor
* Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 isolcott
`* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
 +* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 |`* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 | +- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
 | `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
 |  `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
 |   +- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 |   `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
 |    +- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 |    `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
 |     `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 |      `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 |       `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 |        `- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
 `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
  `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
   `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
    `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
     +- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
     +* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
     |`* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
     | `- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
     +- Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn [ succinolcott
     +- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
     `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
      `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
       +* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
       |`* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
       | `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
       |  `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
       |   `- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
       `* Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
        +- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.olcott
        +- Re: _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
        `* Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn isolcott
         `* Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn isolcott
          +* Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn isolcott
          |`- Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn isolcott
          +- Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn isolcott
          `- Re: Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn isolcott

Pages:12
Subject: Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is correct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 26 Jul 2021 14:38 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, 26 Jul 2021 09:38:00 -0500
Subject: Re: Black box halt decider is NOT a partial decider [ H(P,P)==0 is
correct ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc>
<uMGJI.28030$qk6.2244@fx36.iad> <sd7een$js8$1@gioia.aioe.org>
<zyHJI.20655$7H7.13829@fx42.iad> <sd8bim$1set$1@gioia.aioe.org>
<87eebrlv2m.fsf@bsb.me.uk> <sdckqo$cm8$1@gioia.aioe.org>
<87a6mehx5q.fsf@bsb.me.uk> <sdfbv2$14bi$2@gioia.aioe.org>
<875yx0he2s.fsf@bsb.me.uk> <sdffqm$jsh$1@gioia.aioe.org>
<87zgucfux4.fsf@bsb.me.uk> <sdi9vb$r9b$1@dont-email.me>
<87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 26 Jul 2021 09:38:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <877dhec8wh.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
Lines: 77
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-o874WO9S97OhP9E/zvtouneYxcXri5QZz4i6MlXzUkhfS6vwENZWLQPeNUZ0m4ocfyi3CnlVsNknCuM!6xxOxylt5t8isTHWwjmqxup8X1bIj88AJq3gRUWZ0whFFVUgnRXeol9jev89GV8w2nNkV6QHiA==
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: 6558
View all headers
On 7/25/2021 5:42 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

On 25/07/2021 21:28, Mike Terry wrote:
Pressed Send too soon. :(
On 25/07/2021 18:40, Malcolm McLean wrote:
On Sunday, 25 July 2021 at 17:14:20 UTC+1, Mike Terry wrote:

I think this is all a bit like Malcolm suggesting that PO is raising
"interesting ideas" that might be useful with more study, or that some
basic idea of PO's is "really quite clever...". It is NOT. PO has no
incling of those possibilities and really no interest in them. He is
simply saying things he naively thinks are true, without any logical
reasoning going on. No cleverness at all. He is not "performing a
magic trick", where he will pull a rabit out of a hat - he genuinely
believes he is refuting the Linz proof, no tricks. Pretending otherwise
may be being nice to PO, making him feel better, but is ultimately
unhelpful IMO. I'd say it seems like "dishonest niceness" to me. (But
maybe Malcolm really thinks PO is producing worthwhile results, or is on
the path to that, in which case it's just being "actually nice"!)

I've always been very clear that I haven't yet seen from PO anything that
constitutes a refutation of Linz. However when we have, for example, the
"H is the operating system" ruse, I do tend to say "that's a clever cheat"
rather than "how could you make such a simple and obvious error?".
Largely because it's a nicer way of conveying essentially the same
information.

I did say recently that PO had constructed his own paradox. It's this. If
H is  simulating halt decider, and is called on H, it creates a series of
nested recursions. If it doesn't detect the situation, it never halts. If
it does detect the situation and terminates the simulations, it halts.
However if it halts, the nested recursions were not infinite.
Right, that's a bit like something I pointed out to PO last year.  Such
an emulation-based (putative) decider may have a number of tests in its stepping loop.  Some may be /sound/, like a properly implemented
tight-loop test, or a test might be unsound in that it incorrectly decides halting for a non-halting input or vice-versa.  The sound tests
might match and make correct decisions when examining particular inputs, BUT it's sort of weird that the when H examines (P,P), the /sound/ tests
"mysteriously" never ever match!  The only tests that will ever match are those that are unsound...  If there are /only/ sound tests in the
loop, none of them will match and H(P,P) will never make its decision and halt!  Of course that would disqualify H as a decider.
This applies for PO and his "detecting infinite recursions" test,
however much he believes his test to be sound...  I've told him that a reviewer will

...expect to see a /proof/ of the soundness of any test in his loop,
if he's going to expect them to take matching of the test as
/evidence/ of halting status.  (Of course PO can't deliver such a
proof.)

Right.  And very well put.  But he's abandoned almost all pretence at
dealing with halting.  What makes a sound test has been defined to be
what H does.  This is the "adapted" criterion for halting.  Not halting,
but whatever it is he chooses to put into H.  When he says that its
"impossibly incorrect" (if that's the term, I try to forget such things)
this is what he means.


While the input to H(P,P) is simulated in pure simulation mode it cannot possibly ever reach a final state thus conclusively proving that this input never halts.

Anyone bothering to carefully examine these things must necessarily conclude that the pure simulation of the input to H(P,P) cannot possibly reach its final state. Anyone not bothering to carefully examine these things is a liar and a cheat.

When H recognizes this infinite behavior pattern and stops simulating its input, this input still never reaches its final state, thus never halts.

Many thanks to André G. Isaak for pointing out the proper and best definition of halting we no longer have the ambiguity between halting (reaching its final state) and stopping running (simulation aborted).


--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Wed, 28 Jul 2021 22:08 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!tr1.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: Wed, 28 Jul 2021 17:08:35 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <zyHJI.20655$7H7.13829@fx42.iad> <sd8bim$1set$1@gioia.aioe.org> <87eebrlv2m.fsf@bsb.me.uk> <sdckqo$cm8$1@gioia.aioe.org> <87a6mehx5q.fsf@bsb.me.uk> <sdfbv2$14bi$2@gioia.aioe.org> <875yx0he2s.fsf@bsb.me.uk> <sdffqm$jsh$1@gioia.aioe.org> <87zgucfux4.fsf@bsb.me.uk> <sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk> <19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk> <87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org> <eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk> <4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Wed, 28 Jul 2021 17:08:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87pmv4ab6r.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
Lines: 74
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-RRGwGav8FITnPnkOEt+Tx09XR5J6Vav7hK8G2r+d5QbtfjBFv4e9+4OyskMNEJbMUOtaewr/yXP1gHh!Df3NMEjzN4Xeohclhv8uoBudJoo6Z5/2HZCwLpHPzaa3WnFROM+kc2AR4BH4JRYSjW2bpj1anQ==
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: 4817
View all headers
On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

While the input to H(P,P) is simulated in pure simulation mode it
cannot possibly ever reach a final state thus conclusively proving
that this input never halts.

Who cares?  H(P,P) == 0 and P(P) halts so H is not a halt decider.  You
once claimed something "interesting" i.e. that you had

   "encoded all of the ... Linz Turing machine H that correctly decides
   halting for its fully encoded input pair: (Ĥ, Ĥ)"

and you insisted that

   "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
   specs does not exist. I now have a fully encoded pair of Turing
   Machines H / Ĥ proving them wrong."

Does that "Linz Turing machine H" accept or reject the "fully encoded
input pair (H^, H^)", and what is the halting status if H^ when given H^
(encoded)?  If, as now, H rejects (H^, H^) but H^ halts when given H^
then there was never anything interesting about what you were claiming,
but it was at least about Turing machines and the proof you have fixated
on.

But you also said your TMs H and H^ are "exactly and precisely as in
Linz", so really either

   (1) H rejects (H^, H^) and H^ does not halt on input H^, or
   (2) H accepts (H^, H^) and H^ halts on input H^

should be the case.  So, come clean.  Which was the case back then:

   (1) H rejects (H^, H^) and H^ does not halt in input H^, or
   (2) H accepts (H^, H^) and H^ halts on input H^, or
   (3) H rejects (H^, H^) and H^ halts on input H^.

Without the comfort blanket of your huge pile of junk x86 code, I
suspect you won't dare say.


Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

When we apply Ĥ to its own TM description ⟨Ĥ⟩

While the simulating halt decider at Ĥ.qx remains in pure simulator mode it specifies a never ending cycle from qx to q0.

As you already (generically) agreed:

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.

Therefore: when the simulation of the input to Ĥ.qx must be aborted to prevent the infinite execution of Ĥ applied to ⟨Ĥ⟩ this proves that the input to Ĥ.qx never halts.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Fri, 30 Jul 2021 02:05 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!feeder8.news.weretis.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!buffer1.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 21:05:05 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <875yx0he2s.fsf@bsb.me.uk>
<sdffqm$jsh$1@gioia.aioe.org> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
<87mtq438ge.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 21:05:04 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87mtq438ge.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>
Lines: 63
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-F4JgAUYWlFbZP0XSuEvLTPJ4D35hG54uW/7Fkhq/b4jyPyUFrKA38Qr4yvfPLGE/1xQQ6DtoYQ9xPH+!ck9zbvck/34o3A7lOp1LCXa3XVgNMRd6KHFoJw8DsoQiOOa4T9fyweOpUdUecM2S2paYI+ZylA==
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: 4589
View all headers
On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

(I answered your other belligerent reply before I read this.)

I would prefer to move away from division and animosity to achieve an
honest dialogue striving for mutual agreement, are you game?

Sure.  Here are some other things about which I would like to seek
mutual agreement:

(1) A TM, M, halts on input s if the sequence of machine configurations
     generated by M's state transition function, along with the input s,
     is finite. 

I like André's reaches one of its own finite states better.
Is this OK with you?

M is said to accept s if the final state is an accepting
     state.  Otherwise M is said to reject the input s.

Yes

(2) A halt decider is a TM, D, that accepts only and all inputs of the
     form <m,s> where m encodes a TM that halts on input s.  D rejects
     all others inputs.
Yes with André's definition of halting.
Is this OK with you?


(3) Did you have, back in Dec 2018, a Turing machine (as the term is
     defined in any of the usual textbooks) that you called H to which
     Linz's "hat" constriction could be applied to get another TM, H^?

I never had a Turing machine. I had what I still consider to be computationally equivalent to the key partial halt deciding aspect of the Linz H correctly deciding the the simplest possible single example of the Linz Ĥ (no copying of the input) as never halting. The 2018 version was encoded to correctly recognize one instance of infinitely nested simulation. It was encoded in nearly complete C.


(4) Using [X] to denote the string that encodes TM X, did your Dec 2018
     H^ halt on input [H^]?

(5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?

Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.

Either way you should post what you had in Dec 2018.  Your conflicting
claims about what it was are one of the biggest obstacles to honest
dialogue.  With what you had out in the open, we could get some
agreement on modified versions of (4) and (5).


It is on a single piece of hand-written paper. I don't think that I ever scanned it.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Fri, 30 Jul 2021 02:28 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!tr2.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: Thu, 29 Jul 2021 21:28:49 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk> <sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk> <19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk> <87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org> <eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk> <4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 21:28:48 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <875yws36vt.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
Lines: 118
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WtCIbyBoC8BEmgsMxYleNI2IjTpUG1yLpNFhUQFz4GQiV/vBRqTmLk08MlhhhUttNwkLFOprdk2KY6E!gLpebWfT566N/wNyIOz7oO9duTThr2VGbPk8PDG9tO7oYZB40lHKbycizsGpdYcj8/8FqQkhQw==
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: 7745
View all headers
On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

While the input to H(P,P) is simulated in pure simulation mode it
cannot possibly ever reach a final state thus conclusively proving
that this input never halts.
Who cares?  H(P,P) == 0 and P(P) halts so H is not a halt decider.  You
once claimed something "interesting" i.e. that you had
       "encoded all of the ... Linz Turing machine H that correctly decides
       halting for its fully encoded input pair: (Ĥ, Ĥ)"
and you insisted that
       "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
       specs does not exist. I now have a fully encoded pair of Turing
       Machines H / Ĥ proving them wrong."
Does that "Linz Turing machine H" accept or reject the "fully encoded
input pair (H^, H^)", and what is the halting status if H^ when given H^
(encoded)?  If, as now, H rejects (H^, H^) but H^ halts when given H^
then there was never anything interesting about what you were claiming,
but it was at least about Turing machines and the proof you have fixated
on.
But you also said your TMs H and H^ are "exactly and precisely as in
Linz", so really either
       (1) H rejects (H^, H^) and H^ does not halt on input H^, or
       (2) H accepts (H^, H^) and H^ halts on input H^
should be the case.  So, come clean.  Which was the case back then:
       (1) H rejects (H^, H^) and H^ does not halt in input H^, or
       (2) H accepts (H^, H^) and H^ halts on input H^, or
       (3) H rejects (H^, H^) and H^ halts on input H^.
Without the comfort blanket of your huge pile of junk x86 code, I
suspect you won't dare say.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

When we apply Ĥ to its own TM description ⟨Ĥ⟩
If you didn't understand the question, I might be able to explain it
some other way.  If you are just avoiding answering it, then just say so
and I'll stop asking.

I totally ignored the convoluted mess of your question...
Would you like to know what I was asking, or do you just want to keep
posting stuff for your entertainment?  It's simpler for me if you are
not interested in knowing what I was asking, and I think it helps other
readers form an opinion as well.

It was just another one of your endless dishonest dodges as can be
seen above This quote proves you are clueless: "H rejects (H^, H^)"
You don't want to answer the question it seems.  OK.

Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
some point.
But you will answer part of it.  You are saying that case (1) does not
apply.

None of the cases apply because you are not following the last step of
the proof where no H is involved.

Can we start talking about the last step of the actual proof?

I am trying to.  The last step is what Ĥ(⟨Ĥ⟩) does:

   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...

As you can see, that depends on the answer to my question.  The
configurations that follow that last ⊢* are those determined by what
that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).

So does the ... lead to Ĥ.qn or Ĥ.qy?  If you don't like my wording
using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
or Ĥ.qy?


Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time that Ĥ.qx remains a pure simulator of its input.

This is the same criteria that both you and André agreed to:
Every simulation that would never stop unless its simulating halt decider stops it at some point specifies infinite execution. This remains true for: Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at some point.

This is very difficult and totally counter-intuitive yet:
This is very difficult and totally counter-intuitive yet:
This is very difficult and totally counter-intuitive yet:
This is very difficult and totally counter-intuitive yet:

The above really seems to prove that the halt decider at Ĥ.qx does correctly decide that its input never halts even when its input contradicts this by transitioning to Ĥ.qn and halting.

It really really seems to be a contradiction and wrong, yet when we really really carefully study it, it really really seems to not be wrong.

When the halt decider correctly decides that its input never halts and then this input halts we have a paradox and not an actual contradiction.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Fri, 30 Jul 2021 14:35 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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jul 2021 09:35:29 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
<87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>
<87tukc12yh.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 30 Jul 2021 09:35:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87tukc12yh.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com>
Lines: 175
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Qf4bBXqlbSEAvCxuFADcJjvKXLC/EbPb6T0G80QJgnHgOGu/jbUYRTpwf/o+sTn8L3UF6wVoFVSiU4+!cJ4L9mviWrGnYrG5z7I/J1O1pEqaI4+i5vDc126pGKkhLsxL/Mjwbiw3HxvdeKfepd5L4TQ6QA==
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: 8627
View all headers
On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
(I answered your other belligerent reply before I read this.)

I would prefer to move away from division and animosity to achieve an
honest dialogue striving for mutual agreement, are you game?
Sure.  Here are some other things about which I would like to seek
mutual agreement:
(1) A TM, M, halts on input s if the sequence of machine configurations
      generated by M's state transition function, along with the input s,
      is finite.

I like André's reaches one of its own finite states better.
Is this OK with you?

What you say here is too vague.  If you can write it clearly and
formally, I'm sure we could agree on it, but I suspect you can't.  In
the spirit of reaching an agreement, is there anything you object to in
my definition?


Your definition seems to be ambiguous when the simulation of a computation has been aborted, André's definition is not ambiguous in this case.

The input to H(P,P) cannot possibly ever reach its final state whether or not its simulation is aborted.

M is said to accept s if the final state is an accepting
      state.  Otherwise M is said to reject the input s.

Yes

(2) A halt decider is a TM, D, that accepts only and all inputs of the
      form <m,s> where m encodes a TM that halts on input s.  D rejects
      all others inputs.

Yes with André's definition of halting.
Is this OK with you?

Not unless you can write it clearly, no.
We can work on this.

The input to my partial halt decider is always a complete function compiled from C and complete functions always have the explicit final state of their last address.

(3) Did you have, back in Dec 2018, a Turing machine (as the term is
      defined in any of the usual textbooks) that you called H to which
      Linz's "hat" constriction could be applied to get another TM, H^?

I never had a Turing machine.

OK, thanks.  That's clear.

It was encoded in nearly complete C.

This raises lots of questions:

(3a) What are "the exact TMD instructions of the Linz Turing machine H"
      that you had encoded by Dec 14th in relation to this C code?


Like I said I did not have a Turing Machine.

(3b) What does "I provide the exact ⊢* wildcard states after the Linz
      H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
      correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?


the proof ...is so short and simple that
it may be of interest to casual readers.
The version below uses CPL...

   rec routine P
     §L:if T[P] go to L
       Return §

Strachey, C 1965.  An impossible program The Computer Journal, Volume 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

In the same way that Strachey claims that his little CPL program sums up the entire proof my premise is that this C code sums up the entire proof.

void P(u32 x)
{
   if (H(x, x))
     HERE: goto HERE;
}

What I had in 2018 was a crude way that code determined that the above does specify infinitely nested simulation.
"the exact ⊢* wildcard states" refers to this code.

Given that you had C code, the "UTM in C++" that you were writing that
would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
interpreter.


It was not a C interpreter. It is an x86 emulator.

(3c) Did you really think you could write a C interpreter in "a week or
      two"?


What I thought that I could do in a week or two was write a very simple virtual machine language lacking all high level control flow structure.
Since I have done this before in two weeks I new that I could do it again.

(3d) Why write an interpreter when C code is better compiled and a
      debugger can then be used to give any required level of detail
      about the execution?


I never wrote a C interpreter. I never intended to write a C interpreter. The initial idea was to write a compiler for a tiny subset of C that is compiled into a very simple virtual machine language.

In the spirit of mutual understanding, I hope you can see that these
mysterious quotes will have led everyone away from the truth (that you
had C code) while re-forcing the mistaken impression that you had what
you had said you had: an actual Turing machine.

(4) Using [X] to denote the string that encodes TM X, did your Dec 2018
      H^ halt on input [H^]?
(5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
Either way you should post what you had in Dec 2018.  Your conflicting
claims about what it was are one of the biggest obstacles to honest
dialogue.  With what you had out in the open, we could get some
agreement on modified versions of (4) and (5).

These become

(4) Did your Dec 2018 C code for H^ halt on H^?


void P(u32 x)
{
   if (H(x, x))
     HERE: goto HERE;
}

What I had in 2018 was a crude way that code determined that the above does specify infinitely nested simulation. I was only concerned with H(P,P) where P is always aborted and can't ever possibly halt.

(5) You said you had "an H that decides (Ĥ, Ĥ)".  What decision did your
     Dec 2018 code come to about "(Ĥ, Ĥ)"?


The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that H(P,P)==0 now except that the never halting criteria is much more elaborate. The initial criteria was very crude.

It is on a single piece of hand-written paper. I don't think that I
ever scanned it.

Unless you post it, we can't reach a mutual understanding about your
claim to have something that everyone else says is impossible.  Maybe
you just had some C that does something entirely possible and
unsurprising.  That is certainly the case now.


It is what I have now that counts. What I had years ago has been superseded by newer technology.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Fri, 30 Jul 2021 14:54 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!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.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: Fri, 30 Jul 2021 09:54:15 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
<87im0s0ydp.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 30 Jul 2021 09:54:14 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87im0s0ydp.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com>
Lines: 145
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-QNvTEk2DHRfIvgeWpaqlvUjmXnmyNW8GHVBNJWV8lWE9vFjztPSkVEg/8t/d2lx6Q6O9F7r8bvZjaMy!ukOZP6FzpVZuc+KCmEPh03KB/Igm7LSSN57VfvWPqhnGpkRDqYzXM9q5rSHZJFqpOUsl0keJhg==
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: 9021
X-Received-Bytes: 9231
View all headers
On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

While the input to H(P,P) is simulated in pure simulation mode it
cannot possibly ever reach a final state thus conclusively proving
that this input never halts.
Who cares?  H(P,P) == 0 and P(P) halts so H is not a halt decider.  You
once claimed something "interesting" i.e. that you had
        "encoded all of the ... Linz Turing machine H that correctly decides
        halting for its fully encoded input pair: (Ĥ, Ĥ)"
and you insisted that
        "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
        specs does not exist. I now have a fully encoded pair of Turing
        Machines H / Ĥ proving them wrong."
Does that "Linz Turing machine H" accept or reject the "fully encoded
input pair (H^, H^)", and what is the halting status if H^ when given H^
(encoded)?  If, as now, H rejects (H^, H^) but H^ halts when given H^
then there was never anything interesting about what you were claiming,
but it was at least about Turing machines and the proof you have fixated
on.
But you also said your TMs H and H^ are "exactly and precisely as in
Linz", so really either
        (1) H rejects (H^, H^) and H^ does not halt on input H^, or
        (2) H accepts (H^, H^) and H^ halts on input H^
should be the case.  So, come clean.  Which was the case back then:
        (1) H rejects (H^, H^) and H^ does not halt in input H^, or
        (2) H accepts (H^, H^) and H^ halts on input H^, or
        (3) H rejects (H^, H^) and H^ halts on input H^.
Without the comfort blanket of your huge pile of junk x86 code, I
suspect you won't dare say.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

When we apply Ĥ to its own TM description ⟨Ĥ⟩
If you didn't understand the question, I might be able to explain it
some other way.  If you are just avoiding answering it, then just say so
and I'll stop asking.

I totally ignored the convoluted mess of your question...
Would you like to know what I was asking, or do you just want to keep
posting stuff for your entertainment?  It's simpler for me if you are
not interested in knowing what I was asking, and I think it helps other
readers form an opinion as well.

It was just another one of your endless dishonest dodges as can be
seen above This quote proves you are clueless: "H rejects (H^, H^)"
You don't want to answer the question it seems.  OK.

Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
some point.
But you will answer part of it.  You are saying that case (1) does not
apply.

None of the cases apply because you are not following the last step of
the proof where no H is involved.

Can we start talking about the last step of the actual proof?
I am trying to.  The last step is what Ĥ(⟨Ĥ⟩) does:
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...
As you can see, that depends on the answer to my question.  The
configurations that follow that last ⊢* are those determined by what
that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).

So does the ... lead to Ĥ.qn or Ĥ.qy?  If you don't like my wording
using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
or Ĥ.qy?

Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time
that Ĥ.qx remains a pure simulator of its input.

Again, you state something trivial and avoid the question.  As far as I
know, H is not a pure simulator (in your confusing wording it's a
simulator for a while and then it isn't).


When it is stipulated that all the sides of a triangle have the same length then it is logically entailed that this triangle is an equilateral triangle. There is no leeway allowed to disagree with the premise in stipulative definitions or geometric "givens".

When it is stipulated that Ĥ.qx is a UTM then it is logically entailed that Ĥ( ⟨Ĥ⟩ ) never halts.

This logical entailment derives another one Ĥ( ⟨Ĥ⟩ ) cannot possibly ever reach its final state unless Ĥ.qx( ⟨Ĥ⟩, ⟨Ĥ⟩ ) aborts at least one of its simulations of its input.

As you (just retracted) and André has already agreed:
Every input to a simulating halt decider that only stops running when its simulation is aborted unequivocally specifies a computation that never halts.

Therefore when Ĥ.qx( ⟨Ĥ⟩, ⟨Ĥ⟩ ) aborts the simulation of its input it is necessarily correct.

This is the same criteria that both you and André agreed to:
Every simulation that would never stop unless its simulating halt
decider stops it at some point specifies infinite execution.

I retract all agreements you may think I've made.  That's simpler than
trying to explain myself.  If you claim, henceforth, that I agree with
anything other than my own, or a published textbook definition of
halting, you will be arguing in bad faith.


Then try and explain how the input to H(P,P) or Ĥ.qx( ⟨Ĥ⟩, ⟨Ĥ⟩ ) can possibly reach its final state.

Any chance you will now say if

  Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

transitions to Ĥ.qn or Ĥ.qy?  If you find this question difficult,
please ask for some help in understanding it.


Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn on the basis that its input cannot possibly ever reach its final state, and indeed its input never does reach its final state.


--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Sat, 31 Jul 2021 01:16 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!paganini.bofh.team!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.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: Fri, 30 Jul 2021 20:16:08 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org> <eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk> <4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com> <87im0s0ydp.fsf@bsb.me.uk> <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com> <87tukblgjy.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 30 Jul 2021 20:16:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87tukblgjy.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com>
Lines: 59
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-QRVBEX2/Kk7bekxqne2/MmrOdE6nUnXDneZLmR3bbteo4t46d0GYySogTY1YvPO9kOeyadCMbjFZ60+!G9nvM9pVPkI0Vnc2CnFg7noGlerIHm6b/iB/bT0Nl8+6uILaCm/EEsofHtIA1DZw8I27x0nuKQ==
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: 4188
View all headers
On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/30/2021 7:39 AM, Ben Bacarisse wrote:

Any chance you will now say if

   Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

transitions to Ĥ.qn or Ĥ.qy?  If you find this question difficult,
please ask for some help in understanding it.

Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn

An answer.  Thank you.

   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause
that applies to your H and Ĥ:


There is no H in the relevant last paragraph of the Linz proof that forms the basis for the Linz conclusion.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
that it does.  That is what this full (but abbreviated) state transition
sequence means:

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

Which is it?


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

The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly ever reach its final state. Then it transitions to Ĥ0.qn causing the outermost Ĥ0 to halt.

Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly ever reach its final state there is no contradiction or paradox and it decided correctly.


--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Sun, 1 Aug 2021 02:20 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!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 31 Jul 2021 21:20:56 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct
]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
<87im0s0ydp.fsf@bsb.me.uk> <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com>
<87tukblgjy.fsf@bsb.me.uk> <qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com>
<871r7ekugt.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 31 Jul 2021 21:20:55 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <871r7ekugt.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com>
Lines: 143
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-yQQ+R1T3eOVebVjfrVLiQAaUUxHF/wF4jn7hxEzsi9atIiCTWS53gUZn5+n+QcyHcXKaMqtDTgc5dz1!n5Zt/1Fz9K0Bv1CwIl4+1lm0HwkwXXB/eSWU5Xg0+lHp3XmbLt4f30ngW4qxFR61bxGuymNp7Q==
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: 8007
View all headers
On 7/31/2021 5:08 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/30/2021 7:39 AM, Ben Bacarisse wrote:

Any chance you will now say if

    Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

transitions to Ĥ.qn or Ĥ.qy?  If you find this question difficult,
please ask for some help in understanding it.

Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn

An answer.  Thank you.

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

For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause
that applies to your H and Ĥ:

There is no H in the relevant last paragraph of the Linz proof that
forms the basis for the Linz conclusion.

Distraction.  Everything you ignore below is about the proof and refers
only to Ĥ.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
that it does.  That is what this full (but abbreviated) state transition
sequence means:

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

Which is it?

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

This is an abuse of the notation (but I know what you mean).  There is
no Ĥ1 or Ĥ2.  If you think it helps to show which copy of ⟨Ĥ⟩ your
simulating "decider" is either running and/or currently looking at, you
need to come up with a notation that does that. 

A better notation is what I have in my PDF actual subscripts but people here tel me that their newsreader makes sure to totally ignore posts with HTML so that do even see the post at all.

At least I know what
this "math poem" means, because you've been saying this "it's a
simulator until" stuff for years.

The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)
can't possibly ever reach its final state. Then it transitions to
Ĥ0.qn causing the outermost Ĥ0 to halt.

Apart from the bad notation, yes.  All those copies and tests and
eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of

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

Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt
and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly
ever reach its final state there is no contradiction or paradox and it
decided correctly.

You are free to define "decide correctly" in any way you like provided
you are honest about it.  But you hooked people in by saying that your Ĥ
is "exactly and precisely as in Linz", and you quoted, even now, what
Linz has to say about such TMs:

   Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
   if M applied to wM does not halt

This is your quote.  You brought it up.  You claimed your Ĥ was as Linz
states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not
halt.  Linz makes no exceptions based on why the transitions from Ĥ.q0
wM to Ĥ.qn occur.  Linz does not say

   Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
   if M applied to wM does not halt or if M applied wM only halts
   because...

Are you now saying that your TM was not "as in Linz"?  (You should,
because you've admitted that elsewhere.)


Ĥ[0] is to be interpreted to mean Ĥ<sub>0</sub>
  [0] Means the actual Turing machine and not a TM description.
  [1] Means the first TM description parameter
  [2] Means a copy of the the first TM description parameter

Now I am saying that when the actual unmodified Linz Ĥ is understood to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input never halts therefore we know that a state transition from Ĥ[0].qx to Ĥ0.qn is necessarily correct.

This is not a case of the halt decider deciding that Ĥ never halts and then Ĥ halts. There are three different instances of Ĥ involved. It is only their differing placement in the execution trace that makes the result vary.

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

--------
You have real trouble with this notation so I don't think you will know
what I'm saying above, but for anyone else, here is a summary:

If we have a TM "as in Linz" then this applies:

   Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
   if M applied to wM does not halt

When asked what Ĥ does when given ⟨Ĥ⟩ PO says that it (eventually)
transitions to Ĥ.qn, so the above clause applies with M = Ĥ and wM =
⟨Ĥ⟩:

   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   if Ĥ applied to ⟨Ĥ⟩ does not halt

The first line says that Ĥ applied to ⟨Ĥ⟩ halts -- the final halting
state is right there (Ĥ.qn) -- but the second line says that this should
happen if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.  This is why
PO's Ĥ is not "as in Linz".



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy
Date: Sun, 1 Aug 2021 02:47 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
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.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: Sat, 31 Jul 2021 21:47:52 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
Newsgroups: comp.theory,comp.ai.philosophy
References: <20210719214640.00000dfc@reddwarf.jmc> <87eebnfc8c.fsf@bsb.me.uk> <19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk> <87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org> <eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk> <4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> <87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk> <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk> <GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <se4k92$fg4$1@gioia.aioe.org>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 31 Jul 2021 21:47:52 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <se4k92$fg4$1@gioia.aioe.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <P_KdnXA9MfrFlpv8nZ2dnUU7-fPNnZ2d@giganews.com>
Lines: 49
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Y7UhX7FalssoM7zygX3a9RgYBXfQu3Pb0PyE2b/6kxodKAQsZ+GC1ryaCinKVh6oxPZkdKATki5Yo9p!ko+5harNNzqofMiO04Vg3XDDjjsOqzPzigpI/7woNyCy6nZlrxADIYv3nlD+PEqJ3ox8qGLXPw==
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: 4483
View all headers
On 7/31/2021 5:53 PM, Andy Walker wrote:
On 31/07/2021 01:42, olcott wrote:
[...] At the end of 2018 I had only heard of TM complete and I knew
that this required unlimited memory.

     Which every computer with the capability of reading from and
writing to a suitable external medium [eg USB stick, CD, floppy, mag
tape, paper tape or punched cards] and obeying a relatively small
program has.  That's pretty-much everything that we would normally
have called a computer from the 1950s onwards.

[...]
C is equivalent to a TM for the subset of computations where it has
all the memory that it needs. I don't think that anyone else beside
me says this.

     If you mean merely that C programs can be used to emulate a
finite-state machine, then that has "always" been known, and I guess
that few research papers have thought it worth saying;

Through RASP machines we know that all computations (having enough memory) performed in C are equivalent to TM computations.
https://en.wikipedia.org/wiki/Random-access_stored-program_machine

Thus a C program that correctly decides the TM counter-examples that "prove" that halting is undecidable directly maps to a TM that can do the same thing, thus refuting the original theorem.

 OTOH, it
would have been a normal thing to say for the past 40+ years when
explaining to students what a FSM is and giving examples.  It would
also have been normal for the past 50+ years to explain that then-
current HLLs were overkill;  you can build a UTM out of anything
that can do a few simple operations on [cf the above] an unbounded
storage medium.  Everything else is an efficiency hack.


More generally my x86utm operating system implements x86 virtual machines based on C functions that are computationally equivalent to UTMs. This allows studying theory of computation problems using the high level language of C.

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:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.philosophy
Date: Sun, 1 Aug 2021 14:45 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
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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 01 Aug 2021 09:45:04 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct
]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.philosophy
References: <20210719214640.00000dfc@reddwarf.jmc>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
<87im0s0ydp.fsf@bsb.me.uk> <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com>
<87tukblgjy.fsf@bsb.me.uk> <qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com>
<871r7ekugt.fsf@bsb.me.uk> <K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com>
<87czqxa0zk.fsf@bsb.me.uk>
<53d47ab9-818c-4f40-8e72-bdb76fa416een@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 1 Aug 2021 09:45:03 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <53d47ab9-818c-4f40-8e72-bdb76fa416een@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <XoKdnQJb0dztLpv8nZ2dnUU7-WXNnZ2d@giganews.com>
Lines: 59
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-qR7ZuAuAbJULSgAxY4UVb7r95JSKDHWMb6vkDwXy0WCmBv4OQdTv6O6ghdtTub56nLWODcxNPxhxVor!QCZQY0ycXPheIt+Rehjqg7lVp5umX5xBuI3n1LttghkG3gBbOrDYBgSf7dHIfvgEf1hwnYIo2Q==
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: 4659
View all headers
On 8/1/2021 7:12 AM, Malcolm McLean wrote:
On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:

Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
behaviour "correct". You can call it anything you like. But it's not
"as in Linz". It does not say anything about Linz's proof. It does not
do anything people would call impossible or even interesting.

It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
theorems are refuted. Which you would expect. If results were consistent
it would have to be some cheap trick.

Since both answers are correct:

(a) The input to H(P,P) really is a non-halting computation:
It can't possibly ever reach its final state whether or not H aborts its simulation.

(b) The P of int main(){ P(); } does reach its final state.

Therefore (b) does not prove that H(P,P)==0 is incorrect.

These are two different instances of P at two different points in the execution trace and the first P would never halt unless the second P was aborted thus proving that int main(){ P(); } does specify the first element of an infinite chain of function calls. P was only allowed to halt only because it was not an input to the halt decider. This is like a guy that gets away with a crime only because no one is watching.

// H and H2 are partial halt deciders
u32 PSR_Decider(u32 P, u32 I)
{
   u32 Input_Halts1 = H((u32)P, (u32)I);
   u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
   Output("Input_Halts1 = ", Input_Halts1);
   Output("Input_Halts2 = ", Input_Halts2);
   if (Input_Halts1 != Input_Halts2)
     return 1;
   return 0;
}

Since u32 PSR_Decider(u32 P, u32 I) recognizes all and only these cases Rice is refuted.

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

However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
nothing to do with the invert step of Linz' proof. This is maybe interesting,
but in a small way, it's not a revolutionary result which will turn computer
science upside down. But it's maybe worth mentioning.



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ][ GIGO ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.philosophy
Date: Sun, 1 Aug 2021 15:02 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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 01 Aug 2021 10:02:40 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct
][ GIGO ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.philosophy
References: <20210719214640.00000dfc@reddwarf.jmc> <877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk>
<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk>
<j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com> <87im0s0ydp.fsf@bsb.me.uk>
<Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com> <87tukblgjy.fsf@bsb.me.uk>
<qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com> <871r7ekugt.fsf@bsb.me.uk>
<K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com> <87czqxa0zk.fsf@bsb.me.uk>
<53d47ab9-818c-4f40-8e72-bdb76fa416een@googlegroups.com>
<87y29l8hhp.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 1 Aug 2021 10:02:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87y29l8hhp.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <LZOdnR5aLooNKpv8nZ2dnUU7-SnNnZ2d@giganews.com>
Lines: 92
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-0pBrnReWiAnjoNt456WqZEVu3t4aycZdFrxqzpON+gYX2cdRFEit0PZKup+WAQuaYH2PQ49q6CMXgT0!iGfFhS3/uB9OlPSMohXfCraMM8flsKs/oefUs9258mi0vg094Qr6DGhe1xNGvEP1Zu7yh3sFcQ==
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: 5958
View all headers
On 8/1/2021 7:41 AM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:

Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
behaviour "correct". You can call it anything you like. But it's not
"as in Linz". It does not say anything about Linz's proof. It does not
do anything people would call impossible or even interesting.

It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
theorems are refuted. Which you would expect. If results were consistent
it would have to be some cheap trick.

I case there is some confusion, I mean that PO's Ĥ is not an Ĥ as
specified in Linz.  Yes, everything is in accordance with the truth as
laid out in Linz and, indeed, in any textbook.

I point this out to PO because he brings it up.  He keeps posting the
specification of what an Ĥ, as Linz specifies it, would do:

   Ĥ.q0 wM ⊢* Ĥ.qx wM wM  ⊢* Ĥ.qn
   if (and only if) M applied to wM does not halt.

He claims (or used to claim) that his Ĥ meets this specification for at
least the one case where wM == ⟨Ĥ⟩:

   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩  ⊢* Ĥ.qn
   if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.

To remain relevant, he /must/ keep insisting that his Ĥ meets the
requirements laid out in Linz, if only for this one key input.


Ĥ[0].q0 is taken to mean Ĥ<sub>0</sub>.q0 which is the Turing machine.

Ĥ[1].q0 is taken to mean Ĥ<sub>1</sub>.q0 which is the Turing machine description input to Ĥ[0].q0

Ĥ[2].q0 is taken to mean Ĥ<sub>2</sub>.q0 which is first copy of the Turing machine description input to Ĥ[0].q0

Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩  ⊢* Ĥ[0].qn

It is neither a contradiction nor a paradox because there are three different instances of Ĥ.

Because the only reason that the first instance halts is that Ĥ[0].qx correctly determines that its input cannot possibly ever reach its final state of Ĥ[1].qn or Ĥ[1].qy whether or not the simulating halt decider aborts its simulation of this input, we know with 100% perfectly justified logical certainty that the input to Ĥ[0].qx never halts.

However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
nothing to do with the invert step of Linz' proof. This is maybe interesting,
but in a small way, it's not a revolutionary result which will turn computer
science upside down. But it's maybe worth mentioning.

I don't follow.  H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 making
that result the wrong one.  If H(H_Hat, H_Hat) returned non-zero,
H_Hat(H_Hat) would not halt, making that the wrong result.  Whilst I
don't like this sort of language, H fails on H_Hat(H_Hat) precisely
because of how H_Hat is constructed from H.


Garbage in derives garbage out that this garbage collector** recognizes and rejects:

** Pathological self-reference(Olcott 2004) decider

// H and H2 are partial halt deciders
u32 PSR_Decider(u32 P, u32 I)
{
   u32 Input_Halts1 = H((u32)P, (u32)I);
   u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
   Output("Input_Halts1 = ", Input_Halts1);
   Output("Input_Halts2 = ", Input_Halts2);
   if (Input_Halts1 != Input_Halts2)
     return 1;
   return 0;
}


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: Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn [ succinct_]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.philosophy
Date: Sun, 1 Aug 2021 16:02 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
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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 01 Aug 2021 11:02:38 -0500
Subject: Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn [ succin
ct_]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.philosophy
References: <20210719214640.00000dfc@reddwarf.jmc> <877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk>
<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk>
<j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com> <87im0s0ydp.fsf@bsb.me.uk>
<Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com> <87tukblgjy.fsf@bsb.me.uk>
<qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com> <871r7ekugt.fsf@bsb.me.uk>
<K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com> <87czqxa0zk.fsf@bsb.me.uk>
<53d47ab9-818c-4f40-8e72-bdb76fa416een@googlegroups.com>
<87y29l8hhp.fsf@bsb.me.uk>
<99b46f6e-6017-48ec-bbd6-04dbcbd60e1an@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 1 Aug 2021 11:02:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <99b46f6e-6017-48ec-bbd6-04dbcbd60e1an@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <TsidnfC9_pIDWJv8nZ2dnUU7-anNnZ2d@giganews.com>
Lines: 105
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-z21d90qVzHhsYTQ0lhOVjPQRcZDIbvoFej4Dd6692F+r22juCtDvdbx9DbYin3dkWKjTX2YqYNXchc5!57Q1qE/1EtsjkOj6RWzSS+lRaIQk9M7NHs2+7BfbCM+GQhlo+mEeO0PLHEMg/3J7ZOsImR4LLA==
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: 5892
View all headers
On 8/1/2021 9:25 AM, Malcolm McLean wrote:
On Sunday, 1 August 2021 at 13:41:25 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:

However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
nothing to do with the invert step of Linz' proof. This is maybe interesting,
but in a small way, it's not a revolutionary result which will turn computer
science upside down. But it's maybe worth mentioning.
I don't follow. H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 making
that result the wrong one. If H(H_Hat, H_Hat) returned non-zero,
H_Hat(H_Hat) would not halt, making that the wrong result. Whilst I
don't like this sort of language, H fails on H_Hat(H_Hat) precisely
because of how H_Hat is constructed from H.

Consider this. H_Cap (similar to H_Hat but missing the invert step);

H_Cap(I)
{
    return H(I, I):
}

Now if H is a "simulating halt decider" it must get this wrong. H is (skeleton
code)

H(I, I)
{
    while(true)
    {
        Step(I, I);
        if (tightloopdetected())
            return Non_Halting;
        else if (haltsofitsownaccord)
            return  Halting;
    }
}

The question is how we write the function tightloopdetected(). If it returns
true then H(H_Cap, H_Cap) the H(H_Cap, H_Cap) will terminate. If
it returns false, it wlll not. So H can never make the right decision for H_Cap(H_Cap).


Some errors were corrected and the rest was adapted to x86utm.

u32 HH(I, I)
{
HERE:
   {
     if (H(I, I) == 0)
       return 0;
     else
       return 1;
    }
   goto HERE;
}

u32 H_Cap(I)
{
   return HH(I, I);
}

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

Begin Local Halt Decider Simulation at Machine Address:d02
....[00000d02][00211915][00211919] 55          push ebp
....[00000d03][00211915][00211919] 8bec        mov ebp,esp
....[00000d05][00211915][00211919] 8b4508      mov eax,[ebp+08]
....[00000d08][00211911][00000d02] 50          push eax
....[00000d09][00211911][00000d02] 8b4d08      mov ecx,[ebp+08]
....[00000d0c][0021190d][00000d02] 51          push ecx
....[00000d0d][00211909][00000d12] e8c0ffffff  call 00000cd2
....[00000cd2][00211905][00211915] 55          push ebp
....[00000cd3][00211905][00211915] 8bec        mov ebp,esp
....[00000cd5][00211905][00211915] 8b4508      mov eax,[ebp+08]
....[00000cd8][00211901][00000d02] 50          push eax
....[00000cd9][00211901][00000d02] 8b4d08      mov ecx,[ebp+08]
....[00000cdc][002118fd][00000d02] 51          push ecx
....[00000cdd][002118f9][00000ce2] e8e0fdffff  call 00000ac2
....[00000d02][0025c33d][0025c341] 55          push ebp
....[00000d03][0025c33d][0025c341] 8bec        mov ebp,esp
....[00000d05][0025c33d][0025c341] 8b4508      mov eax,[ebp+08]
....[00000d08][0025c339][00000d02] 50          push eax
....[00000d09][0025c339][00000d02] 8b4d08      mov ecx,[ebp+08]
....[00000d0c][0025c335][00000d02] 51          push ecx
....[00000d0d][0025c331][00000d12] e8c0ffffff  call 00000cd2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Input_Halts = 0

Proving that the above code is decided correctly.

We've elimiated the "invert the result" step from Linz's proof. We have to
insist that H is a "simulating halt decider" to achieve this. But that seems
to be a reasonable condition. We know there are many properties of Turing
machines that cannot be determined other than by stepping them.



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Sun, 1 Aug 2021 19:45 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
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.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: Sun, 01 Aug 2021 14:45:57 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com> <87im0s0ydp.fsf@bsb.me.uk> <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com> <87tukblgjy.fsf@bsb.me.uk> <qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com> <871r7ekugt.fsf@bsb.me.uk> <K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com> <87czqxa0zk.fsf@bsb.me.uk> <53d47ab9-818c-4f40-8e72-bdb76fa416een@googlegroups.com> <87y29l8hhp.fsf@bsb.me.uk> <99b46f6e-6017-48ec-bbd6-04dbcbd60e1an@googlegroups.com> <87mtq189ng.fsf@bsb.me.uk> <50dfd889-9418-48d0-a20d-1d1f2c029c42n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 1 Aug 2021 14:45:57 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <50dfd889-9418-48d0-a20d-1d1f2c029c42n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <cPadnTZbe-5oZJv8nZ2dnUU7-bednZ2d@giganews.com>
Lines: 96
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Mr1rXn/vUIkGKSrx0ik9oE7nKemy8di9lUvodoMGAv/vJyzZ39mPnIiEIK4++Ti3UbLln/UTu4/JhsS!AbM9y4OlYPUcKzTHnvkV3osS9Oby7ydDkNMKWZVBa8ehYfpAU2fmTDbXQQ8PSeA0401+yvzMkQ==
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: 6038
View all headers
On 8/1/2021 1:41 PM, Malcolm McLean wrote:
On Sunday, 1 August 2021 at 16:30:46 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:

We've elimiated the "invert the result" step from Linz's proof. We
have to insist that H is a "simulating halt decider" to achieve this.
The proof is still there, with all the same steps in it. I think you
mean there is a /different/ proof, without that step, that shows that
some naive "deciders" gets other cases wrong. I don't see why you find
that interesting, but I think that's the bottom line: you find some
things interesting that I don't.

Sure, there's a different proof, inspired by Linz's, but with the "invert
the result" step removed. It only applies to naive simulating deciders.
So to make it into a proof of general interest, we've got to show that
a naive simulating decider can't be bettered by any other type of
decider.

But that seems to be a reasonable condition. We know there are
many properties of Turing machines that cannot be determined other
than by stepping them.
And again I'm lost. Can you name an "interesting" property of a TM
computation that /can/ be determined by stepping it?

Take its busy beaver score, for example. You might object that even a
stepping scorer can't always detect when a machine won't halt. So just
add a limit, which grows with then number of states  to keep the set
infinite. Busy beaver score before either a halt or m * N states steps.

My guess (you'll have to confirm) is that you mean there are many
properties that we can't always determine by stepping, but stepping the
computation is the "best we can do". If so, we've had this discussion
before, and I still disagree.

Yes, that's a reasonable summary.


 >

Some errors were corrected and the rest was adapted to x86utm.

u32 HH(I, I)
{
HERE:
   {
     if (H(I, I) == 0)
       return 0;
     else
       return 1;
    }
   goto HERE;
}

u32 H_Cap(I)
{
   return HH(I, I);
}

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

Begin Local Halt Decider Simulation at Machine Address:d02
....[00000d02][00211915][00211919] 55          push ebp
....[00000d03][00211915][00211919] 8bec        mov ebp,esp
....[00000d05][00211915][00211919] 8b4508      mov eax,[ebp+08]
....[00000d08][00211911][00000d02] 50          push eax
....[00000d09][00211911][00000d02] 8b4d08      mov ecx,[ebp+08]
....[00000d0c][0021190d][00000d02] 51          push ecx
....[00000d0d][00211909][00000d12] e8c0ffffff  call 00000cd2
....[00000cd2][00211905][00211915] 55          push ebp
....[00000cd3][00211905][00211915] 8bec        mov ebp,esp
....[00000cd5][00211905][00211915] 8b4508      mov eax,[ebp+08]
....[00000cd8][00211901][00000d02] 50          push eax
....[00000cd9][00211901][00000d02] 8b4d08      mov ecx,[ebp+08]
....[00000cdc][002118fd][00000d02] 51          push ecx
....[00000cdd][002118f9][00000ce2] e8e0fdffff  call 00000ac2
....[00000d02][0025c33d][0025c341] 55          push ebp
....[00000d03][0025c33d][0025c341] 8bec        mov ebp,esp
....[00000d05][0025c33d][0025c341] 8b4508      mov eax,[ebp+08]
....[00000d08][0025c339][00000d02] 50          push eax
....[00000d09][0025c339][00000d02] 8b4d08      mov ecx,[ebp+08]
....[00000d0c][0025c335][00000d02] 51          push ecx
....[00000d0d][0025c331][00000d12] e8c0ffffff  call 00000cd2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Input_Halts = 0

Proving that the above code is decided correctly.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 2 Aug 2021 03:17 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!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.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: Sun, 01 Aug 2021 22:17:36 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk> <4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> <87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk> <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk> <GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <874kcakv3d.fsf@bsb.me.uk> <-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> <87im0pa1pp.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 1 Aug 2021 22:17:35 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87im0pa1pp.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com>
Lines: 70
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fiPzqI5zZXvR5yXvYUycENupvkAaW0nzpXdgIMzU/upLOcSnxj73WuHRq4z3cHeY36j9ndXk0Z8wM4t!IR5/jAEtpphjoU0MkjtfNGw/CLMEwwW1n7LVMZSXiA8kMKwcxnsy69cLqluZEITDD2kOuPhTWQ==
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: 5255
View all headers
On 8/1/2021 5:39 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

It matters not what I had.
Because you can't justify it the honest debate you claim to want.

It only matters what I have.
I.e. nothing of any interest.  You make it plain in a previous reply
that you've had nothing of interest going right back to the original
deceptive claim.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.
And yet you skipped the big picture part:

(5) You said you had "an H that decides (Ĥ, Ĥ)".  What decision did your
      Dec 2018 code come to about "(Ĥ, Ĥ)"?

The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
H(P,P)==0 now except that the never halting criteria is much more
elaborate. The initial criteria was very crude.

Ah, so you never had H and H_Hat that do anything that anyone would say
is impossible.  Had you said, back in Dec 2018, "I have C code such that
H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
interested.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.

Ah, an honest dialogue requires me to ignore your past deception?  Well,
I can accommodate that: you /currently/ don't have anything that anyone
would consider to be impossible or even interesting.  An H/H_Hat pair
such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no interest
to anyone.  Is that better?


When H is a simulating partial halt decider and the halt decider embedded in Ĥ at Ĥ.qx is a simulating halt decider then:

It is the case that the input to H(P,P) and the input to Ĥ(⟨Ĥ⟩) cannot possibly ever reach their final state and must have their simulation aborted to prevent the infinite execution of P and Ĥ.

Let's have an honest dialogue about that.

I think you owe everyone an apology.  Even if there was no indent to
deceive, your words back then did everything possible to suggest some
impossible Turing machine.  And you wouldn't say, until recently, even
when explicitly asked, what decision H came to.  It was fishy from the
start.

You still owe everyone an apology.  Neither Turing machines nor C code
are obsolete technology.  If you really had what you falsely claimed to
have had, posting it at any time in the last 30 months would have
settled the matter.  It still would, but you either never had anything
at all or you are too embarrassed to post what it was.


The technology that I had in 2018 is obsolete and not relevant to an honest dialogue about the technology that I currently have.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 2 Aug 2021 03:45 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!eternal-september.org!reader02.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!buffer1.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 01 Aug 2021 22:45:10 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct
]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
<87im0s0ydp.fsf@bsb.me.uk> <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com>
<87tukblgjy.fsf@bsb.me.uk> <qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com>
<871r7ekugt.fsf@bsb.me.uk> <K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com>
<87czqxa0zk.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 1 Aug 2021 22:45:09 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87czqxa0zk.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <woudnXWBxPba95r8nZ2dnUU78ffNnZ2d@giganews.com>
Lines: 173
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MIkUcNVx0tzNwByDWcRVjKi5vAxP9IERetoHRmZp5qSI/jvS659s8VHISS7B9/oa81RumkEyhuaOF6i!zbTqHiCCBh+gVHUHxOx8B6nAdipIGx25G6i/LoGil+inkQRv2IkVpQmmT6Z5S0VlGOHLOEPSsg==
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: 9570
View all headers
On 8/1/2021 5:54 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/31/2021 5:08 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/30/2021 7:39 AM, Ben Bacarisse wrote:

Any chance you will now say if

     Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

transitions to Ĥ.qn or Ĥ.qy?  If you find this question difficult,
please ask for some help in understanding it.

Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn

An answer.  Thank you.

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

For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause
that applies to your H and Ĥ:

There is no H in the relevant last paragraph of the Linz proof that
forms the basis for the Linz conclusion.
Distraction.  Everything you ignore below is about the proof and refers
only to Ĥ.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
that it does.  That is what this full (but abbreviated) state transition
sequence means:

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

Which is it?

Ĥ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 ...
This is an abuse of the notation (but I know what you mean).  There is
no Ĥ1 or Ĥ2.  If you think it helps to show which copy of ⟨Ĥ⟩ your
simulating "decider" is either running and/or currently looking at, you
need to come up with a notation that does that.

A better notation is what I have in my PDF actual subscripts but
people here tel me that their newsreader makes sure to totally ignore
posts with HTML so that do even see the post at all.

I am happy you have a notation you like.  Are you prepared to address
that fact that your H^ is not "as in Linz"?


My Ĥ is exactly the Linz Ĥ with the additional elaboration that the second wildcard state transition ⊢* is defined to be a simulating halt decider. The Linz ⊢* explicitly allows for this without diverging from the Linz template at all.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢*


At least I know what
this "math poem" means, because you've been saying this "it's a
simulator until" stuff for years.

The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)
can't possibly ever reach its final state. Then it transitions to
Ĥ0.qn causing the outermost Ĥ0 to halt.
Apart from the bad notation, yes.  All those copies and tests and
eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt
and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly
ever reach its final state there is no contradiction or paradox and it
decided correctly.
You are free to define "decide correctly" in any way you like provided
you are honest about it.  But you hooked people in by saying that your Ĥ
is "exactly and precisely as in Linz", and you quoted, even now, what
Linz has to say about such TMs:
    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt
This is your quote.  You brought it up.  You claimed your Ĥ was as Linz
states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not
halt.  Linz makes no exceptions based on why the transitions from Ĥ.q0
wM to Ĥ.qn occur.  Linz does not say
    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt or if M applied wM only halts
    because...
Are you now saying that your TM was not "as in Linz"?  (You should,
because you've admitted that elsewhere.)

Ĥ[0] is to be interpreted to mean Ĥ<sub>0</sub>
  [0] Means the actual Turing machine and not a TM description.
  [1] Means the first TM description parameter
  [2] Means a copy of the the first TM description parameter

Now I am saying that when the actual unmodified Linz Ĥ is understood
to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly
decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its
final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input
never halts therefore we know that a state transition from Ĥ[0].qx to
Ĥ0.qn is necessarily correct.

We all know you are declaring that to be correct.  Here's why your Ĥ is
not "as in Linz".  Linz requires that

   Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
   if M applied to wM does not halt

Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt.  But you've
given us a case where your Ĥ is not like this:

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


And when we eliminate the fallacy of equivocation error we have

Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn

The way that you do it when your twin bother commits a crime that makes you guilty.

Ĥ[0].q0 ⟨Ĥ[1]⟩ only halts because the simulation of the
the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted.

(a) The simulation of the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩
was aborted because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could
ever possibly reach their final states.

(b) Because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach
their final states we know that they never halt.

(c) Because they never halt we know that Ĥ[0].qx correctly decided
that its input never halts.

This is the same as: X > Y & Y > Z therefore X > Z
I do seem to have a correct chain of inference.
I do not think that you can point to any error in
this chain of inference.

In an honest dialogue when you would disagree that a
chain of inference derives a correct conclusion you
would point to a specific error in this chain of inference.

What is the error in (a)(b)(c) ?

Here we can see that Ĥ applied to ⟨Ĥ⟩ halts.  You can call your Ĥ's
behaviour "correct".  You can call it anything you like.  But it's not
"as in Linz".  It does not say anything about Linz's proof.  It does not
do anything people would call impossible or even interesting.

Presumably, you will simply explain, yet again, why you choose to call
it correct.  You might even, yet again, quote the symbols from Linz that
don't apply to your Ĥ in order to make you posts seem relevant.



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 2 Aug 2021 18:16 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!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.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, 02 Aug 2021 13:16:13 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> <87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk> <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk> <GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <874kcakv3d.fsf@bsb.me.uk> <-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> <87im0pa1pp.fsf@bsb.me.uk> <6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com> <87y29j6c5e.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 2 Aug 2021 13:16:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87y29j6c5e.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com>
Lines: 112
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-iYuV0xqbyWPsLppt8/BYUhLvrZ6WAyifEcJMdsXjj6s2MVTHnJzm2SaDlA1976Xj2fAF7GU6qKNLOz3!+3ldaYce7WdFGs2rT/ozWrBJYejZAGvXFrO061Fv215EnqH75eGsRjawgxeoqqN8jIYKhkGQeQ==
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: 7194
View all headers
On 8/2/2021 11:31 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/1/2021 5:39 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

It matters not what I had.
Because you can't justify it the honest debate you claim to want.

It only matters what I have.
I.e. nothing of any interest.  You make it plain in a previous reply
that you've had nothing of interest going right back to the original
deceptive claim.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.
And yet you skipped the big picture part:

(5) You said you had "an H that decides (Ĥ, Ĥ)".  What decision did your
       Dec 2018 code come to about "(Ĥ, Ĥ)"?

The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
H(P,P)==0 now except that the never halting criteria is much more
elaborate. The initial criteria was very crude.

Ah, so you never had H and H_Hat that do anything that anyone would say
is impossible.  Had you said, back in Dec 2018, "I have C code such that
H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
interested.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.

Ah, an honest dialogue requires me to ignore your past deception?  Well,
I can accommodate that: you /currently/ don't have anything that anyone
would consider to be impossible or even interesting.  An H/H_Hat pair
such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no interest
to anyone.  Is that better?

When H is a simulating partial halt decider and the halt decider
embedded in Ĥ at Ĥ.qx is a simulating halt decider then:

It is the case that the input to H(P,P) and the input to Ĥ(⟨Ĥ⟩) cannot
possibly ever reach their final state and must have their simulation
aborted to prevent the infinite execution of P and Ĥ.

Let's have an honest dialogue about that.

Yes, let's.  Here's how to say what happens without all those vague
(and, frankly, incorrect) words:

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

If you don't mean

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

can you say what you do mean formally?  Formally means using some
formal notation like Linz does.


As Linz already specifies yet does not encode in his notation there are at least three separate and distinct instances of Ĥ.

The first one of these instances is the actual Turing machine Ĥ.
The second one is the TM description ⟨Ĥ⟩ input to Ĥ.
The third one is the copy of the TM description ⟨Ĥ⟩ input to Ĥ.

If we do not keep track of these distinctions then it seems like Ĥ.qx decides that its input never halts and then its input immediately halts. This would be an actual contradiction.

When we do keep track of these distinctions then the input: ⟨Ĥ^1⟩ to Ĥ^0 can be understood to never reach its final states Ĥ^1.qy or Ĥ^1.qn thus proving that Ĥ^0.qx did correctly decide that its input ⟨Ĥ^1⟩ ⟨Ĥ^2⟩ never halts.

If what you want to say is all about what happens in that second ⊢*
(i.e. all the nested simulations and so on) then don't bother, because
what makes your Ĥ irrelevant is what state Ĥ applied to ⟨Ĥ⟩ gets to, not
how it gets there.

I think you owe everyone an apology.  Even if there was no indent to
deceive, your words back then did everything possible to suggest some
impossible Turing machine.  And you wouldn't say, until recently, even
when explicitly asked, what decision H came to.  It was fishy from the
start.
You still owe everyone an apology.  Neither Turing machines nor C code
are obsolete technology.  If you really had what you falsely claimed to
have had, posting it at any time in the last 30 months would have
settled the matter.  It still would, but you either never had anything
at all or you are too embarrassed to post what it was.

The technology that I had in 2018 is obsolete and not relevant to an
honest dialogue about the technology that I currently have.

You had C code.  C code is not obsolete.  It's also a good formalism.
You could say what you meant back then by posting the code.  But you
won't post it either because you never had it or you are embarrassed by
it.  An honest academic would simply say "this is what I had -- very
rough and ready, isn't it?  Here's the tidied up version...".



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 2 Aug 2021 18:25 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
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!buffer1.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 02 Aug 2021 13:25:14 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
<87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>
<87tukc12yh.fsf@bsb.me.uk> <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com>
<875ywrmwsr.fsf@bsb.me.uk> <GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com>
<874kcakv3d.fsf@bsb.me.uk> <-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com>
<87im0pa1pp.fsf@bsb.me.uk> <6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com>
<87y29j6c5e.fsf@bsb.me.uk> <p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 2 Aug 2021 13:25:13 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <DYednaixofwWpZX8nZ2dnUU78eHNnZ2d@giganews.com>
Lines: 130
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-eiCNN5SdcYvoYje3kennjNcl+2E56TMXhgb0m3dGo6l19UnYU8b9czwvuJR173AvXykx2+I+yaMFMuD!SEky/mW33bd6HocUyWrHzM8fEvWLow1wWG8UoiagsnKzg079m7oGYmaTMS82edCbR9Vp3qHioA==
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: 7801
View all headers
On 8/2/2021 1:16 PM, olcott wrote:
On 8/2/2021 11:31 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/1/2021 5:39 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

It matters not what I had.
Because you can't justify it the honest debate you claim to want.

It only matters what I have.
I.e. nothing of any interest.  You make it plain in a previous reply
that you've had nothing of interest going right back to the original
deceptive claim.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.
And yet you skipped the big picture part:

(5) You said you had "an H that decides (Ĥ, Ĥ)".  What decision did your
       Dec 2018 code come to about "(Ĥ, Ĥ)"?

The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
H(P,P)==0 now except that the never halting criteria is much more
elaborate. The initial criteria was very crude.

Ah, so you never had H and H_Hat that do anything that anyone would say
is impossible.  Had you said, back in Dec 2018, "I have C code such that
H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
interested.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.

Ah, an honest dialogue requires me to ignore your past deception?  Well,
I can accommodate that: you /currently/ don't have anything that anyone
would consider to be impossible or even interesting.  An H/H_Hat pair
such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no interest
to anyone.  Is that better?

When H is a simulating partial halt decider and the halt decider
embedded in Ĥ at Ĥ.qx is a simulating halt decider then:

It is the case that the input to H(P,P) and the input to Ĥ(⟨Ĥ⟩) cannot
possibly ever reach their final state and must have their simulation
aborted to prevent the infinite execution of P and Ĥ.

Let's have an honest dialogue about that.

Yes, let's.  Here's how to say what happens without all those vague
(and, frankly, incorrect) words:

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

If you don't mean

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

can you say what you do mean formally?  Formally means using some
formal notation like Linz does.


As Linz already specifies yet does not encode in his notation there are at least three separate and distinct instances of Ĥ.

The first one of these instances is the actual Turing machine Ĥ.
The second one is the TM description ⟨Ĥ⟩ input to Ĥ.
The third one is the copy of the TM description ⟨Ĥ⟩ input to Ĥ.

If we do not keep track of these distinctions then it seems like Ĥ.qx decides that its input never halts and then its input immediately halts. This would be an actual contradiction.

When we do keep track of these distinctions then the input: ⟨Ĥ^1⟩ to Ĥ^0 can be understood to never reach its final states Ĥ^1.qy or Ĥ^1.qn thus proving that Ĥ^0.qx did correctly decide that its input ⟨Ĥ^1⟩ ⟨Ĥ^2⟩ never halts.

H[0] means H<sub>0</sub>

When we do keep track of these distinctions then the input: ⟨Ĥ[1]⟩ to Ĥ[0] can be understood to never reach its final states Ĥ[1].qy or Ĥ[1].qn thus proving that Ĥ[0].qx did correctly decide that its input ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ never halts.


If what you want to say is all about what happens in that second ⊢*
(i.e. all the nested simulations and so on) then don't bother, because
what makes your Ĥ irrelevant is what state Ĥ applied to ⟨Ĥ⟩ gets to, not
how it gets there.

I think you owe everyone an apology.  Even if there was no indent to
deceive, your words back then did everything possible to suggest some
impossible Turing machine.  And you wouldn't say, until recently, even
when explicitly asked, what decision H came to.  It was fishy from the
start.
You still owe everyone an apology.  Neither Turing machines nor C code
are obsolete technology.  If you really had what you falsely claimed to
have had, posting it at any time in the last 30 months would have
settled the matter.  It still would, but you either never had anything
at all or you are too embarrassed to post what it was.

The technology that I had in 2018 is obsolete and not relevant to an
honest dialogue about the technology that I currently have.

You had C code.  C code is not obsolete.  It's also a good formalism.
You could say what you meant back then by posting the code.  But you
won't post it either because you never had it or you are embarrassed by
it.  An honest academic would simply say "this is what I had -- very
rough and ready, isn't it?  Here's the tidied up version...".





--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Mon, 2 Aug 2021 20:53 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, 02 Aug 2021 15:53:13 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct
]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk>
<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk>
<j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com> <87im0s0ydp.fsf@bsb.me.uk>
<Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com> <87tukblgjy.fsf@bsb.me.uk>
<qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com> <871r7ekugt.fsf@bsb.me.uk>
<K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com> <87czqxa0zk.fsf@bsb.me.uk>
<woudnXWBxPba95r8nZ2dnUU78ffNnZ2d@giganews.com> <87mtpz64sq.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 2 Aug 2021 15:53:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87mtpz64sq.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <w5edne8d06OkxpX8nZ2dnUU7-b_NnZ2d@giganews.com>
Lines: 135
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rs2JhJpHIy7aV7s4zDZorOPB1VZypPfdzyubWvS4VbToNkpILRikRw2HqOxsu4yNmUHjtwxehYIFBDN!VTg6oi+9wlJui1jpQBzhiIhELJ3pOqnHFJWaf48vGTK2LQF3P+CFDiUpcaxyZRCH8EmG9ZOkjQ==
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: 7662
View all headers
On 8/2/2021 2:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/1/2021 5:54 AM, Ben Bacarisse wrote:

I am happy you have a notation you like.  Are you prepared to address
that fact that your H^ is not "as in Linz"?

My Ĥ is exactly the Linz Ĥ with the additional elaboration that the
second wildcard state transition ⊢* is defined to be a simulating halt
decider.

No.  I've explained many times now why your Ĥ is not at all "the Linz
Ĥ".  Do you see any point in my doing so again?

We all know you are declaring that to be correct.  Here's why your Ĥ is
not "as in Linz".  Linz requires that

    Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
    if M applied to wM does not halt

Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt.  But you've
given us a case where your Ĥ is not like this:

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

And when we eliminate the fallacy of equivocation error we have

Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn

The only thing I think you are equivocating on is pretending that Ĥ[0]
is not Ĥ, and it doesn't look as if you've removed that error.  I think
you /should/ remove it so that you can be saying something of value
about Ĥ.


It is clear from the text that Linz does specify at least three different instances of Ĥ, The TM the TMD input ⟨Ĥ⟩ and a copy of this TMD input.

Failing to keep track of which is which when the simulated execution is analyzed simply ignores a key salient detail.

The way that you do it when your twin bother commits a crime that
makes you guilty.

Ĥ[0].q0 ⟨Ĥ[1]⟩ only halts because the simulation of the
the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ was aborted.

(a) The simulation of the input to Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩
was aborted because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could
ever possibly reach their final states.

(b) Because neither ⟨Ĥ[1]⟩ nor ⟨Ĥ[2]⟩ could ever possibly reach
their final states we know that they never halt.

(c) Because they never halt we know that Ĥ[0].qx correctly decided
that its input never halts.

This is the same as: X > Y & Y > Z therefore X > Z
I do seem to have a correct chain of inference.
I do not think that you can point to any error in
this chain of inference.

In an honest dialogue when you would disagree that a
chain of inference derives a correct conclusion you
would point to a specific error in this chain of inference.

What is the error in (a)(b)(c) ?

Far too many to go into all of them (if you are not inclined to correct
anything, just jump to number 7) but ere are some:

(1) Unless Ĥ[0] is just another name for Ĥ you are not saying anything I
     care about.  What matters is what Ĥ applied to ⟨Ĥ⟩ does.

(2) TMs don't "abort".  The sequence of configurations ends.


This seems to diverge from an honest dialogue in that it seems like you are saying that the concept of a simulating halt decider cannot possibly exist.

Do you agree that a simulating halt decider can abort its simulation of its input? If not please provide all of the details of why you disagree.

(3) Stop talking about what "could possibly" happen.  TMs do what they
     do.  There are no "possibilities".


When the simulating halt decider at Ĥ.qx examines the behavior of its pure simulation its input ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ it determines that this input never reaches its final state.

(4) ⟨Ĥ[1]⟩ and ⟨Ĥ[2]⟩ are strings.  A string does not "reach" anything.
     Strings don't even have states that can be reached.  I can unravel
     this, but why must your readers work hard to unpick your metaphors?


The Simulation of ⟨Ĥ[1]⟩ on input ⟨Ĥ[2]⟩ is computationally equivalent to the execution of Ĥ[1] on input ⟨Ĥ[2]⟩ thus the Simulation of ⟨Ĥ[1]⟩ either reaches or fails to reach a final state.

(5) Ĥ[0].qx is a state.  It does not decide anything.  (Again, I can
     guess what you mean but you asked for help.)


Ĥ[0].qx is stipulated to be the halt decider named H.
In the erroneous Linz notation it is at the second start state of Ĥ.

(6) States don't have input.  Whilst I could guess that you mean "the
     tape" at the point the state is entered", states in a TM may be
     entered many times so there is no obvious single "input".


Linz refers to it as: "The input to H" thus making your "correction" within the context of Linz, incorrect.

(7) The correct behaviour of Ĥ is not based on (a) and (b) but on what
     Linz says about Ĥ applied to ⟨Ĥ⟩.  Your Ĥ does not behave as Linz's
     Ĥ should, even in the one case you care about.

You slightly changed the subject. We are not talking about the behavior of Ĥ. We are talking about what the future behavior of the input to the simulating halt decider at Ĥ.qx would be.

When we stay 100% perfectly focused on exactly this we can see that the future behavior of the input to Ĥ.qx never reaches its final state.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.math.symbolic, comp.software-eng
Date: Tue, 3 Aug 2021 00:55 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!feeder8.news.weretis.net!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.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, 02 Aug 2021 19:55:38 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
Newsgroups: comp.theory,comp.ai.philosophy,sci.math.symbolic,comp.software-eng
References: <20210719214640.00000dfc@reddwarf.jmc> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com> <87im0s0ydp.fsf@bsb.me.uk> <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com> <87tukblgjy.fsf@bsb.me.uk> <qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com> <871r7ekugt.fsf@bsb.me.uk> <K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com> <87czqxa0zk.fsf@bsb.me.uk> <woudnXWBxPba95r8nZ2dnUU78ffNnZ2d@giganews.com> <87mtpz64sq.fsf@bsb.me.uk> <w5edne8d06OkxpX8nZ2dnUU7-b_NnZ2d@giganews.com> <87bl6f5qvy.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 2 Aug 2021 19:55:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87bl6f5qvy.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <xLednaPs_ZSXCZX8nZ2dnUU7-YnNnZ2d@giganews.com>
Lines: 112
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-gBd5mi8CdLbspcVOiomxbzfc5n2juVNqPSVxGw/A2huHcZNxvBEIYm/9miecpoc8NRebmryz6r6SdjG!EqDNoEN71uHLUorm4HjR9kn8yh+gqTLR8WHr9nqgC+/pdTi3gPkMhLn7/+Ehc942sUKmwOxoIQ==
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: 6655
View all headers
On 8/2/2021 7:11 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/2/2021 2:10 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/1/2021 5:54 AM, Ben Bacarisse wrote:

I am happy you have a notation you like.  Are you prepared to address
that fact that your H^ is not "as in Linz"?

My Ĥ is exactly the Linz Ĥ with the additional elaboration that the
second wildcard state transition ⊢* is defined to be a simulating halt
decider.
No.  I've explained many times now why your Ĥ is not at all "the Linz
Ĥ".  Do you see any point in my doing so again?

I suspect not.  You certainly have not asked a single question that
could help you to understand why your Ĥ is irrelevant.

We all know you are declaring that to be correct.  Here's why your Ĥ is
not "as in Linz".  Linz requires that

     Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
     if M applied to wM does not halt

Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt.  But you've
given us a case where your Ĥ is not like this:

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

And when we eliminate the fallacy of equivocation error we have

Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
The only thing I think you are equivocating on is pretending that Ĥ[0]
is not Ĥ, and it doesn't look as if you've removed that error.  I think
you /should/ remove it so that you can be saying something of value
about Ĥ.

It is clear from the text that Linz does specify at least three
different instances of Ĥ, The TM the TMD input ⟨Ĥ⟩ and a copy of this
TMD input.

Still equivocating.  Either Ĥ[0] = Ĥ or you are wasting everyone's time.


Ĥ[0] = Ĥ
Ĥ[1] != Ĥ
Ĥ[2] != Ĥ

(This is mathematical equality.  Ĥ is a tuple of sets.  If Ĥ[0] is not
exactly identical in every way to Ĥ then I don't care about it.  Note

The different instances of Ĥ are different in a crucial way and that is their placement in the execution trace.

that I'm not disputing your right, for ease of explanation, to give
identical things more than one name.  But the same permission allows me
to use any of the names because they name the same thing.)


Only because their differing placement in the execution trace do they have different halting behavior. This is a crucial distinction.

You are wrong because

   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn

where Linz requires that

  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
  if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.


Linz could require that all cats must be dogs, the verifiable fact is that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qx is correctly decided as never halting.

If you really do sincerely want an actual honest dialogue you would carefully work through all the steps to confirm that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qx never halts.

Once we have mutual agreement that Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts and Ĥ does halt, then we have the basis to go to the next step and resolve the actual paradox.

As long as it is simply dismissed out-of-hand as a contradiction the paradox remains unresolved.

Either you ask questions that might help you to understand what I'm
saying, or you can just repeat again, in ever greater detail, what
happens in that ⊢* as if the exact way in which you are wrong is the key
thing you want to tell the world.  It's up to you.

Please don't think I don't know what you are saying.  I understand all
the copying and levels and so on.  But the details don't make you right
because it's the outcome that makes you wrong.  No explanation of how
you get the wrong behaviour, no matter how detailed, makes the wrong
behaviour right.  Your Ĥ is just one of countless other TMs that do not
do what Linz says is impossible, even for this one input.

I'll leave it there.  If you really want my comments on your replies to
the errors you asked me to point it, I'll post again, but it it's all
noise compared to the big mistake.



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 3 Aug 2021 02:11 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, 02 Aug 2021 21:11:42 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] [ succinct
]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk>
<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk>
<j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com> <87im0s0ydp.fsf@bsb.me.uk>
<Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com> <87tukblgjy.fsf@bsb.me.uk>
<qtGdnfuXs4nFOZn8nZ2dnUU7-cnNnZ2d@giganews.com> <871r7ekugt.fsf@bsb.me.uk>
<K5-dndGZo_-VmJv8nZ2dnUU78QvNnZ2d@giganews.com> <87czqxa0zk.fsf@bsb.me.uk>
<woudnXWBxPba95r8nZ2dnUU78ffNnZ2d@giganews.com> <87mtpz64sq.fsf@bsb.me.uk>
<w5edne8d06OkxpX8nZ2dnUU7-b_NnZ2d@giganews.com> <87bl6f5qvy.fsf@bsb.me.uk>
<xLednaPs_ZSXCZX8nZ2dnUU7-YnNnZ2d@giganews.com> <87o8af47y0.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 2 Aug 2021 21:11:41 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87o8af47y0.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <NsudnY99rthDOJX8nZ2dnUU7-c_NnZ2d@giganews.com>
Lines: 52
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-gLMvEd4uUFe+Kc0LSP6oLaVjhpai56Q8fjajXZ2QGcEdbvPf4I2VoZyL8CVVSjmyRiBIaLiG1DIT9zP!svPKyruEZtNKdg8lhgQwW6z3/zu3oU7r/8mfn2Djl/fmtbi9BF1Z8/iFOoFcyaD6Tout9kxz5A==
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: 4305
View all headers
On 8/2/2021 8:45 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 8/2/2021 7:11 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:


(I'm going to ignore errors that I've already pointed out.)

If you really do sincerely want an actual honest dialogue you would
carefully work through all the steps to confirm that the input ⟨Ĥ⟩ ⟨Ĥ⟩
to Ĥ.qx never halts.

If you want me to comment on that, write it without the errors.  It has
two, both of which I've commented on before.  If you are sincere, you
will want to write clearly and without errors.

Once we have mutual agreement that Ĥ.qx correctly decides that its
input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts and Ĥ does halt, then we have the basis to
go to the next step and resolve the actual paradox.

There is no paradox.  That Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn when Ĥ applied to ⟨Ĥ⟩
clearly halts is not paradoxical.  It's just not the sort of TM the
proof is talking about.  And how could it be?  The "Linz Ĥ" is as
illogical as a cat that is a dog.

As long as it is simply dismissed out-of-hand as a contradiction the
paradox remains unresolved.

There is no contradiction or paradox.  You Ĥ is just the wrong sort of
TM.  The proof you want to "refute" is talking about this sort of Ĥ:

   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
   if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.


Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts

In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever https://en.wikipedia.org/wiki/Halting_problem


--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 3 Aug 2021 13:00 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
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.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, 03 Aug 2021 08:00:20 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> <87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk> <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk> <GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <874kcakv3d.fsf@bsb.me.uk> <-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> <87im0pa1pp.fsf@bsb.me.uk> <6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com> <87y29j6c5e.fsf@bsb.me.uk> <p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com> <875ywn5qfr.fsf@bsb.me.uk> <hJmdnSWv8-zPCJX8nZ2dnUU7-T_NnZ2d@giganews.com> <3df616af-1e70-413f-8534-fb4ca6204c28n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 3 Aug 2021 08:00:20 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <3df616af-1e70-413f-8534-fb4ca6204c28n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <_ZudnRCgbJV5oJT8nZ2dnUU7-VXNnZ2d@giganews.com>
Lines: 74
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rPd6kFmmQqL0bQzYh7aInTi0gXiLIVH2FJMwbrFfpGB5DOjqR44l4ymotseQXj/zE5Rp9jc7f2EPVUP!VrbElpXoHIQ+MvXUDHOBa/zFRn43JeV2hH82ZluDe/yPwgQK9W1wSM3owdnLRQPuFZjxnhW4qQ==
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: 5329
View all headers
On 8/3/2021 12:29 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 02:01:14 UTC+1, olcott wrote:
On 8/2/2021 7:20 PM, Ben Bacarisse wrote:

As long as you keep thinking of it as a resolved contradiction the
actual paradox remains unresolved.

I proved that Ĥ.qx does correctly decide that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts it is also equally proven that Ĥ halts thus a paradox and not a
contradiction is formed.

My current answer to this is GIGO self-contradictory input <IN>
contractory output <OUT>. There may be a better answer.

With your H, H_Hat <H_Hat> halts. That's common ground.
With your H H<H_Hat><H_Hat> returns false (non-halting). That's also
common ground.

So one positive in this is that you are clearly being honest about the
behaviour of your code.
But don't you see that this behaviour is exactly what Linz says would
happen? H_Hat<H_Hat> is a case that H cannot classify correctly.


On pages 4-6 I proves that H(P,P) does correctly decide that its input never halts.

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

Thus meeting this criteria:
In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever. https://en.wikipedia.org/wiki/Halting_problem

You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H.

No I have never been saying that. I am claiming that the input to H(P,P) never halts whether or not H terminates its simulation of this input.

No I have never been saying that. I am claiming that the input to H(P,P) never halts whether or not H terminates its simulation of this input.

No I have never been saying that. I am claiming that the input to H(P,P) never halts whether or not H terminates its simulation of this input.

No I have never been saying that. I am claiming that the input to H(P,P) never halts whether or not H terminates its simulation of this input.

This leads us down
a rabbit hole of talking of the "inner" and "outer" H or H1, H2 and so on.

None-the-less if this is where the actual truth is we can't simply dismiss it out-of-hand.

But what Linz is saying is that the internal details of H don't matter. It
can be a simulating halt decider, a control graph anlyser, or even just
a stub machine that returns a flag. However cleverly or simply it is
written, it classifies H_Hat<H_Hat> wrongly.


We can see that the input to H(P,P) never halts therefore H IS NOT WRONG.

I think it's high time to wind up these threads.


I think that it is high time that people actually pay complete attention.

--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 3 Aug 2021 15:21 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
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: Tue, 03 Aug 2021 10:21:30 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk>
<x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> <87mtq438ge.fsf@bsb.me.uk>
<PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk>
<e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk>
<GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <874kcakv3d.fsf@bsb.me.uk>
<-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> <87im0pa1pp.fsf@bsb.me.uk>
<6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com> <87y29j6c5e.fsf@bsb.me.uk>
<p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com> <875ywn5qfr.fsf@bsb.me.uk>
<hJmdnSWv8-zPCJX8nZ2dnUU7-T_NnZ2d@giganews.com>
<3df616af-1e70-413f-8534-fb4ca6204c28n@googlegroups.com>
<_ZudnRCgbJV5oJT8nZ2dnUU7-VXNnZ2d@giganews.com>
<f5026a04-cbe0-4809-82d9-27ecaf1fd1afn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 3 Aug 2021 10:21:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <f5026a04-cbe0-4809-82d9-27ecaf1fd1afn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <3IadnZ2CTqZnw5T8nZ2dnUU7-VudnZ2d@giganews.com>
Lines: 33
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FXU4L8rV1sCtV8yjVw58pt+P6kPq/n6YaGeLfB70SKG8HWkoHcpVL8/x/ngg9Qr+DJNQxiu2Q0Ccj3p!nQpta6ZpQD+kB7PXOYvD1zwlRiG49jwlI7vMcPh87BrZPI/yTyzjYT9BhuVLoftiE1YJJa/LZw==
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: 3480
View all headers
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:

You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H.
No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

We agree that P(P) halts.
So now you're drawing a distinction between P(P) and "the input to H(P,P)".
ThIs is nonsense..

Try and find any error in (a)(b)(c)(d) on page 6

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

We can see that the input to H(P,P) never halts therefore H IS NOT WRONG.
I think it's high time to wind up these threads.

I think that it is high time that people actually pay complete attention.

You can't complain about lack of attention.



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 3 Aug 2021 19:26 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
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.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, 03 Aug 2021 14:26:41 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> <87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk> <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk> <GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <874kcakv3d.fsf@bsb.me.uk> <-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> <87im0pa1pp.fsf@bsb.me.uk> <6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com> <87y29j6c5e.fsf@bsb.me.uk> <p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com> <875ywn5qfr.fsf@bsb.me.uk> <hJmdnSWv8-zPCJX8nZ2dnUU7-T_NnZ2d@giganews.com> <3df616af-1e70-413f-8534-fb4ca6204c28n@googlegroups.com> <_ZudnRCgbJV5oJT8nZ2dnUU7-VXNnZ2d@giganews.com> <f5026a04-cbe0-4809-82d9-27ecaf1fd1afn@googlegroups.com> <3IadnZ2CTqZnw5T8nZ2dnUU7-VudnZ2d@giganews.com> <sebtb9$plb$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 3 Aug 2021 14:26:40 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <sebtb9$plb$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <dPGdnfUV6vjsBZT8nZ2dnUU7-V3NnZ2d@giganews.com>
Lines: 60
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LJoUMcSdyUKYBOxtU24UQ9JZEUCa5uJyEYlrwEnt46F90m2y+ZH8j4EbgxzM2iiVS0Ehq0dIxrvUQql!HMen8g2KawuznSVEPINJRLNq3L88Z9UlP20G0wom43Nk4ATyuFIJH4z/+equrc7kDzyUOaJt6Q==
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: 4581
View all headers
On 8/3/2021 12:11 PM, André G. Isaak wrote:
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:

You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H.
No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

We agree that P(P) halts.
So now you're drawing a distinction between P(P) and "the input to H(P,P)".
ThIs is nonsense..

Try and find any error in (a)(b)(c)(d) on page 6

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



The error, which has been pointed out repeatedly, is in your (b).

You claim "there are no control flow instructions in the execution trace that would escape the infinite recursion", but there *are* flow control instructions. But your trace is incomplete and skips over the call to B82 where these flow control instructions reside.


Whether H aborts its simulation of P or not P never reaches its final state.

The conditional instructions are merely the aspect of H aborting its simulation of P.

Because P never reaches its final state whether H aborts its simulation of P or not we know that P never halts.

The code at B82 is *part* of the computation performed by P. It *must* be included in any trace of P which purports to be a complete and honest trace.

You don't seem to grasp the fact that *all* code executed by a particular computation from the moment the computation begins to the time it halts (assuming it halts) is part of that computation. It doesn't matter whether the code in question is shared by some other routine, or is operating system code or whatever. These are purely artificial distinctions which play no role in the theory of computation.

André



--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 3 Aug 2021 20:47 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
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 03 Aug 2021 15:47:42 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87k0la542c.fsf@bsb.me.uk>
<x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com> <87mtq438ge.fsf@bsb.me.uk>
<PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk>
<e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk>
<GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <874kcakv3d.fsf@bsb.me.uk>
<-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> <87im0pa1pp.fsf@bsb.me.uk>
<6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com> <87y29j6c5e.fsf@bsb.me.uk>
<p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com> <875ywn5qfr.fsf@bsb.me.uk>
<hJmdnSWv8-zPCJX8nZ2dnUU7-T_NnZ2d@giganews.com>
<3df616af-1e70-413f-8534-fb4ca6204c28n@googlegroups.com>
<_ZudnRCgbJV5oJT8nZ2dnUU7-VXNnZ2d@giganews.com>
<f5026a04-cbe0-4809-82d9-27ecaf1fd1afn@googlegroups.com>
<3IadnZ2CTqZnw5T8nZ2dnUU7-VudnZ2d@giganews.com> <sebtb9$plb$1@dont-email.me>
<dPGdnfUV6vjsBZT8nZ2dnUU7-V3NnZ2d@giganews.com> <sec7nt$333$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 3 Aug 2021 15:47:41 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <sec7nt$333$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Ea2dnYUpZJLzNpT8nZ2dnUU78LXNnZ2d@giganews.com>
Lines: 120
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-JxLAmOTjvQb3CIIMG3LgWHNUqKhmAaPuDQk5CIS3vfSBSXfii4Q9GsmrbkB81I+kovSICpbNcOPbnsJ!2poDjY8q/JEoWDeWsLtIvk3bAHPlp/N/80WpJSHoGvGXVnZUitgJJPQZzhjKjssv+6LMWloq1Q==
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: 7380
View all headers
On 8/3/2021 3:08 PM, André G. Isaak wrote:
On 2021-08-03 13:26, olcott wrote:
On 8/3/2021 12:11 PM, André G. Isaak wrote:
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:

You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H.
No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

We agree that P(P) halts.
So now you're drawing a distinction between P(P) and "the input to H(P,P)".
ThIs is nonsense..

Try and find any error in (a)(b)(c)(d) on page 6

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





The error, which has been pointed out repeatedly, is in your (b).

You claim "there are no control flow instructions in the execution trace that would escape the infinite recursion", but there *are* flow control instructions. But your trace is incomplete and skips over the call to B82 where these flow control instructions reside.


Whether H aborts its simulation of P or not P never reaches its final state.

But H's simulation of P is *not* a computation.


Sure it is.
The pure simulation of a computation on its input is computationally equivalent to the direct execution of this same computation on its input.

When we run H(P, P) the only computation being performed is H(P, P), and if H aborts its simulation of P(P), then control returns to H which then Halts.


The job of a halt decider is to correctly predict the future behavior of its input. Because the input to H(P,P) does not transition to its final state whether or not H aborts the simulation of this input we know that this input never halts.

In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever. https://en.wikipedia.org/wiki/Halting_problem

Because the P that halts is not: "a description of an arbitrary computer program" it is not in the scope of the Halting Problem. Only the input to P is in scope of the halting problem.

When we run P(P) as a computation, again, the only computation being performed is P(P). Any simulations performed by P are *not* computations, and when some simulation is aborted control returns to the outermost P which then halts. And the behaviour of the actual independent computation P determines the *only* correct answer to the question 'does P(P) halt?'.

The question which H(P, P) is supposed to answer *isn't* about some internal simulation. It's supposed to answer a question about an actual computation, P(P) and we know that that computation halts. What occurs in some internal simulation isn't relevant to the answer to this question.

The conditional instructions are merely the aspect of H aborting its simulation of P.

Which then allows the *actual* computation being performed to halt. The halting problem is *only* concerned with actual computations.

Because P never reaches its final state whether H aborts its simulation of P or not we know that P never halts.

Again, the question being asked isn't concerned with the simulation but with the actual computation. The simulation is *part* of that computation. The fact that the simulation gets aborted is *also* part of the computation, and that allows the *whole* computation to halt. The halting problem isn't interested in some part of a computation, only the computation as a whole.

The code at B82 is *part* of the computation performed by P. It *must* be included in any trace of P which purports to be a complete and honest trace.

Again, if you stopped omitting a portion of your traces, things would be clearer to you.

Remember that the halting problem is concerned with computations, not with subroutines. Since you insist on using C rather than actual Turing Machines, though, this minimally requires that your H and your P be *separate* programs. That means each one should have its own source file with its own main. Each should be compiled and linked separately. Your insistence on sticking everything into a single source file is a cheat which you need to abandon.

H needs to take as input a complete *program*, not just some function which is part of the same source file as H.

André




--
Copyright 2021 Pete Olcott

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


Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game_?_)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng, sci.math.symbolic
Date: Tue, 3 Aug 2021 21:03 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
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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 03 Aug 2021 16:03:11 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87mtq438ge.fsf@bsb.me.uk>
<PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com> <87tukc12yh.fsf@bsb.me.uk>
<e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com> <875ywrmwsr.fsf@bsb.me.uk>
<GtmdnfBrysPrAZn8nZ2dnUU7-L_NnZ2d@giganews.com> <874kcakv3d.fsf@bsb.me.uk>
<-M-dnfsXl4WvWpj8nZ2dnUU7-IGdnZ2d@giganews.com> <87im0pa1pp.fsf@bsb.me.uk>
<6eOdnaoMUdZN_pr8nZ2dnUU7-cPNnZ2d@giganews.com> <87y29j6c5e.fsf@bsb.me.uk>
<p8SdnV8dJu3wq5X8nZ2dnUU7-a3NnZ2d@giganews.com> <875ywn5qfr.fsf@bsb.me.uk>
<hJmdnSWv8-zPCJX8nZ2dnUU7-T_NnZ2d@giganews.com>
<3df616af-1e70-413f-8534-fb4ca6204c28n@googlegroups.com>
<_ZudnRCgbJV5oJT8nZ2dnUU7-VXNnZ2d@giganews.com>
<f5026a04-cbe0-4809-82d9-27ecaf1fd1afn@googlegroups.com>
<3IadnZ2CTqZnw5T8nZ2dnUU7-VudnZ2d@giganews.com> <sebtb9$plb$1@dont-email.me>
<dPGdnfUV6vjsBZT8nZ2dnUU7-V3NnZ2d@giganews.com> <sec7nt$333$1@dont-email.me>
<Ea2dnYUpZJLzNpT8nZ2dnUU78LXNnZ2d@giganews.com> <secahd$l3q$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 3 Aug 2021 16:03:10 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <secahd$l3q$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <zqKdnXqSUdOSMpT8nZ2dnUU7-f_NnZ2d@giganews.com>
Lines: 106
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ygV6ngssuPL5uNp8nLSdpx4Lew+iCFcdRnioRnwGKWpSzNpaxz7HuiurWo0aUB38aGWnbJ2n9PaARzZ!zyU0K0QW8WuJJlAUzmogAqx7kal5JzfakJdAVTPmeZlul62b3NgBas1e7UOJfonABaES4V0oJQ==
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: 6416
View all headers
On 8/3/2021 3:56 PM, André G. Isaak wrote:
On 2021-08-03 14:47, olcott wrote:
On 8/3/2021 3:08 PM, André G. Isaak wrote:
On 2021-08-03 13:26, olcott wrote:
On 8/3/2021 12:11 PM, André G. Isaak wrote:
On 2021-08-03 09:21, olcott wrote:
On 8/3/2021 9:33 AM, Malcolm McLean wrote:
On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
On 8/3/2021 12:29 AM, Malcolm McLean wrote:

You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H.
No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

We agree that P(P) halts.
So now you're drawing a distinction between P(P) and "the input to H(P,P)".
ThIs is nonsense..

Try and find any error in (a)(b)(c)(d) on page 6

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







The error, which has been pointed out repeatedly, is in your (b).

You claim "there are no control flow instructions in the execution trace that would escape the infinite recursion", but there *are* flow control instructions. But your trace is incomplete and skips over the call to B82 where these flow control instructions reside.


Whether H aborts its simulation of P or not P never reaches its final state.

But H's simulation of P is *not* a computation.


Sure it is.
The pure simulation of a computation on its input is computationally equivalent to the direct execution of this same computation on its input.

No. It isn't. A computation is a free-standing, self-contained piece of code. When you run H(P, P) the computation P(P) isn't being computed. It's being evaluated. H(P, P) is the only computation being run in this case.


So you don't understand how UTMs work.

And your H *doesn't* perform a pure simulation of its input, so we can't even talk about the simulation as being 'computationally equivalent' to some computation.


The fact that the first seven instructions of P keep repeating while H is in pure simulation mode proves that H is doing pure simulation mode correctly.

When we run H(P, P) the only computation being performed is H(P, P), and if H aborts its simulation of P(P), then control returns to H which then Halts.


The job of a halt decider is to correctly predict the future behavior of its input. Because the input to H(P,P) does not transition to its final state whether or not H aborts the simulation of this input we know that this input never halts.

In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever. https://en.wikipedia.org/wiki/Halting_problem

Because the P that halts is not: "a description of an arbitrary computer program" it is not in the scope of the Halting Problem. Only the input to P is in scope of the halting problem.

Here you're very confused. The "P that halts" *is* the computation which the input to H describes. A halt decider takes a description of an arbitrary program and answers *about the program described by that description*. The "input to P" isn't a computation. It's a description of a computation. Halting applies to actual computations, not to descriptions.

André



The key point is that if it is not AN INPUT the it doesn't count.
The simulation of inputs is not forbidden.

--
Copyright 2021 Pete Olcott

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


Pages:12
rocksolid light 0.7.2
clearneti2ptor