Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Seed me, Seymour" -- a random number generator meets the big green mother from outer space


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

SubjectAuthor
* How do we know H(P,P)==0 is the correct halt status for the input toolcott
+- How do we know H(P,P)==0 is the correct halt status for the inputolcott
+* How do we know H(P,P)==0 is the correct halt status for the inputwij
|`* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| +* How do we know H(P,P)==0 is the correct halt status for the inputwij
| |`* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | +* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |`* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | | `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |   `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |    `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |     +- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |     `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |      `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       +* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |`* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       | `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |  `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |   `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |    `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |     `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |      `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |       `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |        `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |         `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |          `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |           `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |            `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |             `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |              `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |               `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                 `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                   `* How do we know H(P,P)==0 is the correct halt status for the input to H?Richard Damon
| | |       |                    `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                     `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                      `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                       `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                        `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         +* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                         |+* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         ||`* How do we know H(P,P)==0 is the correct halt status for the input to H?Richard Damon
| | |       |                         || `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         ||  `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                         |`* How do we know H(P,P)==0 is the correct halt status for the inputMalcolm McLean
| | |       |                         | +- How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         | `* How do we know H(P,P)==0 is the correct halt status for the inputMalcolm McLean
| | |       |                         |  +* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |`* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  | `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |  `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |   `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |    `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |     `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |      `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |       `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |        `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |         `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |          `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |           `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |            `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |             `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |              `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |               `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |                `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                         |  `* How do we know H(P,P)==0 is the correct halt status for the inputMalcolm McLean
| | |       |                         |   `- How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                          +* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                          |`* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                          | `* How do we know H(P,P)==0 is the correct halt status for the input to H? [ key axolcott
| | |       |                          |  `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                          `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |       |                           `- How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |        `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |         `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |          +* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |`* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |          | +- How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          | `* How do we know H(P,P)==0 is the correct halt status for the inputdklei...@gmail.com
| | |          |  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |   `* How do we know H(P,P)==0 is the correct halt status for the input to H?Richard Damon
| | |          |    `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |     `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |          |      `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |       `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |          `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |           `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |            `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |             `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |              `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |               `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |                `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |                 `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |                  `- How do we know H(P,P)==0 is the correct halt status for the input to H?Ben Bacarisse
| | `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| |  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| |   `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
+- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
`* How do we know H(P,P)==0 is the correct halt status for the input to H?Ben Bacarisse

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

<f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Aug 2021 08:13:11 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com> <8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 08:13:10 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <871r6kfo1a.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
Lines: 91
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-x3qWIL2bRhgmdGRQc/u4tBy+VYiMqaxOBKHiKR6LsvJ/XfLRTB/xlaUNzF9dSCZ/043VeRIyJ9UxZZN!NBN3oKWgtMa3VyBMf/hUgFdBdlvvQJOknZ5QzqB1FgOO0LD17/Mvm+WDqCWMhHOfggId9QXEn0BF!U2Q=
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: 5672
 by: olcott - Mon, 23 Aug 2021 13:13 UTC

On 8/23/2021 5:33 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>
>>>>> To wrap up this sub-thread, let's just say that you currently can't see
>>>>> how to meet my specification.
>>>>
>>>> Let's just say that it is not cost effective for me to untangle any
>>>> more convoluted paraphrase of the exact same things that I have
>>>> already been saying without a specific high level overview of material
>>>> differences that seem to be non-existent.
>>>
>>> I wondered why you posted a trace showing the wrong behaviour,
>>
>> It is the actual behavior that the code specifies.
>
> A rather obvious thing to say. Code does what it does. It's the
> behaviour I specified that's impossible. No algorithm can determine
> that a function call will return just as no algorithm can determine if a
> program will halt.
>

I show a program that does this in the "impossible" case.
The key thing that I have most recently done is show that the fact that
int main() {P(P); } halts does not contradict that fact that int main()
{ H(P,P); } correctly decides that its input never halts.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
I have also shown that the fact that Ĥ.qx transitions to its final state
of Ĥ.qn and halts does not contradict the fact that Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ does
correctly decide that its input never halts.

This is explained by the fact that the execution of Ĥ is not under the
dominion of Ĥ.qx whereas the simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩ is under the
dominion of Ĥ.qx.

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

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

It is the same case with the above.
The execution of P(P) is not under the dominion of H yet the input to
the simulation of H(P,P) is under the dominion of H.

This makes these two pairs of computations distinctly different from
each other. Distinctly different computations can have different
behavior without contradiction.

the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

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

In order to show that the above two definitions have been satisfied we
only have to show that (an at least partial) halt decider H does
correctly decide whether or not its input description of a Turing
machine or computer program would halt on its input.

It does not matter that the execution of this input seems to contradict
the halt decider because I have shown that the execution of this input
is a distinctly different computation thus not contradicting the halt
decider.

In both cases there is also a one-way dependency of the execution of the
input on the simulation of the input that further proves that the two
computations are distinctly different.

--
Copyright 2021 Pete Olcott

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

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

<87k0kce1yk.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Followup-To: comp.theory
Date: Mon, 23 Aug 2021 14:16:03 +0100
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <87k0kce1yk.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87ilzzuh9o.fsf@bsb.me.uk>
<9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>
<87pmu6topr.fsf@bsb.me.uk>
<-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com>
<87eeamtmoh.fsf@bsb.me.uk>
<z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com>
<87eeamjmkl.fsf@bsb.me.uk>
<y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com>
<8735r1k0p0.fsf@bsb.me.uk>
<TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com>
<87r1elihh9.fsf@bsb.me.uk>
<c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>
<87czq5i9u0.fsf@bsb.me.uk>
<srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com>
<87y28tgt3w.fsf@bsb.me.uk>
<xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com>
<87h7fhgpjm.fsf@bsb.me.uk>
<cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com>
<87o89pf5zi.fsf@bsb.me.uk>
<R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="26167"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+00uJ96lAXud0obk5JPfvjZNsw4xWb/zU="
Cancel-Lock: sha1:w+ZcGuqSdwL9PBlbjnEoLe3lz9k=
sha1:gwe/InQIXoLQKmgKW2JmfF7wdRg=
X-BSB-Auth: 1.218975bddece43dc3ca9.20210823141603BST.87k0kce1yk.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 13:16 UTC

olcott <NoOne@NoWhere.com> writes:

> When a computation is forced to stop running this is an entirely
> different thing than a computation that stops running because it is
> has completed all of its steps. If we allow this ambiguity to remain
> then disingenuous double talk seems more plausible.

How is a TM "forced" to do anything? It's just a silly metaphor that
keeps the door open for different kinds of halting. A TM computation
that halts, for whatever reason, is a halting TM. It's a word game.

This is, despite the absurdity, a serious question. If I gave you a TM
and an input, how could you tell the difference between it simply
halting ("completing all of its steps") and being "forced to stop
running"? If you can't do that (and I know you can't), you should be
able to show me two TM computations, one which just halts and one which
is forced to stop.

And for anyone else, here's why you are wrong about your H in two
sentences. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
applied to ⟨Ĥ⟩. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
fact, accept it.

--
Ben.

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

<87eeake1fm.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Followup-To: comp.theory
Date: Mon, 23 Aug 2021 14:27:25 +0100
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <87eeake1fm.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87o89usfll.fsf@bsb.me.uk>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>
<871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk>
<nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com>
<87bl5pgm5f.fsf@bsb.me.uk>
<3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com>
<871r6kfo1a.fsf@bsb.me.uk>
<f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="26167"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vkgCpWSkVL1VKueYTXBDyacLDrVPv3Uo="
Cancel-Lock: sha1:ofLzr91m7iaglMt/s9tmJlg7rS4=
sha1:HBJFvsYs3dEVX3X2Pph5ZIq4TkQ=
X-BSB-Auth: 1.a295e056950ead7ee20d.20210823142725BST.87eeake1fm.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 13:27 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 5:33 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>>
>>>>>> To wrap up this sub-thread, let's just say that you currently can't see
>>>>>> how to meet my specification.
>>>>>
>>>>> Let's just say that it is not cost effective for me to untangle any
>>>>> more convoluted paraphrase of the exact same things that I have
>>>>> already been saying without a specific high level overview of material
>>>>> differences that seem to be non-existent.
>>>>
>>>> I wondered why you posted a trace showing the wrong behaviour,
>>>
>>> It is the actual behavior that the code specifies.
>> A rather obvious thing to say. Code does what it does. It's the
>> behaviour I specified that's impossible. No algorithm can determine
>> that a function call will return just as no algorithm can determine if a
>> program will halt.
>
> I show a program that does this in the "impossible" case.

You pretended to be able to meet my challenge by, rather oddly, posting
a trace that showed the wrong behaviour.

You could score big here without any need for waffle or ambiguity by
simply posting a function that does what I specified. The test code is
ready -- just link your function to the translation unit I provided and
you can prove, beyond a doubt that you've have a candidate. Would that
not be wonderful? No more arguments, just C code that does what was
asked of it and that I say is impossible?

(I say candidate because it's trivial to produce the right output simply
by cheating. The specification requires another check -- the "equal
arguments" check. But I'll grant you this: you have shown not desire to
produce a cheating "solution".)

--
Ben.

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

<LKKdneHYQIlyNb78nZ2dnUU7-S3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Aug 2021 08:55:59 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations *]
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com> <WKmdnbc68LLPBb_8nZ2dnUU7-LHNnZ2d@giganews.com> <87fsv1i9zb.fsf@bsb.me.uk> <ANidndCeG5zIP7_8nZ2dnUU7-XHNnZ2d@giganews.com> <874kbhi7x8.fsf@bsb.me.uk> <G5qdnU8msK8IMb_8nZ2dnUU7-a_NnZ2d@giganews.com> <87mtp9gqb4.fsf@bsb.me.uk> <mradndjlVfjrIL_8nZ2dnUU7-UHNnZ2d@giganews.com> <87tujhf6bm.fsf@bsb.me.uk> <1padnRmxceeimL78nZ2dnUU7-SfNnZ2d@giganews.com> <87pmu4e2kx.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 08:55:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87pmu4e2kx.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <LKKdneHYQIlyNb78nZ2dnUU7-S3NnZ2d@giganews.com>
Lines: 132
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-baGcnNhllSVC1zQKTMueAehMhHPPPDeOaPyotkZytUwne3lZ3Liuy4ilm9ZaGnyBG2D8xpR+iQS3puf!ubb8bIdKMmLVYomC7yv8zKeJ8PzOVtS9FSiFwYdBJYpcdVh93Vbs/5esVOO8iY9y3rOJmB53sz2d!mlc=
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: 7146
 by: olcott - Mon, 23 Aug 2021 13:55 UTC

On 8/23/2021 8:02 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 5:44 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/22/2021 3:47 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> The executed instances of H(P,P) are distinctly different
>>>>>>>>>> computations...
>>>>>>>>> More deflection. Here's why you are wrong:
>>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>
>>>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to the executed Ĥ on input ⟨Ĥ⟩ it halts.
>>>>
>>>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to ⟨Ĥ1⟩ ⟨Ĥ2⟩ simulated by simulating halt
>>>> decider at Ĥ.qx it never halts.
>>>
>>> This suggests that you think a string can encode two different
>>> computations. I am reluctant to think that is really what you mean
>>> because it's beyond daft.
>>
>> The first Ĥ is essentially a recursive invocation at the outermost
>> level of recursion depth of 0. The simulation at Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is
>> essentially the next level of recursion depth of 1.
>
> Glossing over the metaphorical use of "recursion", yes.
>
>> Although it may be difficult to understand that these essentially
>> specify two different recursion depths you do understand that the
>> recursive invocation of the same function does have a different state
>> at two different recursion depths, don't you?
>
> I started to answer, with a detailed explanation of TM configurations,
> but then got fed up with your patronising tone.
>
> How is the computation of Ĥ applied to ⟨Ĥ⟩ encoded as a string so that
> it can given on the tape to a halt decider?
>
> Correct answer: ⟨Ĥ⟩ ⟨Ĥ⟩.
> PO-answer: ?
>
> Can the string ⟨Ĥ⟩ ⟨Ĥ⟩ encode any other computation?
>
> Correct answer: no.
> PO-answer: ?
>
> Are the all the strings ⟨Ĥi⟩ identical to ⟨Ĥ⟩?
>
> Correct answer: yes.
> PO-answer: ?
>
> Can the string ⟨Ĥ⟩ ⟨Ĥ⟩ (or ⟨Ĥ1⟩ ⟨Ĥ2⟩ or ⟨Ĥ17⟩ ⟨Ĥ23⟩ for that matter)
> encode anything other than the halting computation Ĥ applied to ⟨Ĥ⟩?
>
> Correct answer: no.
> PO-answer: ?
>
> Should a halt decide accept or reject the string ⟨Ĥ⟩ ⟨Ĥ⟩?
>

So the correct answer is that the halt decider decides that ⟨Ĥ⟩ ⟨Ĥ⟩
halts and then ⟨Ĥ⟩ ⟨Ĥ⟩ loops proving that this is not the correct
answer, and proving that you are wrong.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞

This is the kind of huge mistakes that you make when you glance at a few
of my words before forming your rebuttal.

> Correct answer: it should accept it.
> PO-answer: it should reject it.
>
> Is PO's H a halt decider, at least as far as this one case is concerned?
>
> Correct answer: no, it's wrong about the instance ⟨Ĥ⟩ ⟨Ĥ⟩.
> PO-Answer: yes, because Ĥ applied to ⟨Ĥ⟩ only halts for reasons I
> consider to be very special.
>

It is the case that unless Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ aborts the simulation of its
input that its input never stops running.

It is the case that every simulating halt decider that must abort its
simulation of its input to prevent the infinite execution of this input
does correctly decide that this input never halts.

---
The same function executed with the same input must derive the same result.

The simulation of a function on its input is computationally equivalent
to the direct execution of this input.

The simulation of a function on its input is computationally equivalent
to the direct execution of this input by a simulating halt decider while
this simulating halt decider remains in pure simulation mode.

The simulation of a function on its input is NOT computationally
equivalent to the direct execution of this function on its input by a
simulating halt decider when this simulating halt decider aborts its
simulation of this input.
---
The simulation of a machine description of a machine on its input by a
simulating halt decider is not computationally equivalent to the direct
execution of this machine in its input in the case where the simulating
halt decider must abort the simulation of its input to prevent the
infinite execution of its input.

This proves that the execution of Ĥ is a distinctly different
computation than the simulation of the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩, thus
allowing Ĥ to halt and Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ to correctly decide that its input
never halts, without contradiction.

--
Copyright 2021 Pete Olcott

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

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

<edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!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, 23 Aug 2021 09:04:27 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com> <87czq5i9u0.fsf@bsb.me.uk> <srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com> <87y28tgt3w.fsf@bsb.me.uk> <xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com> <87h7fhgpjm.fsf@bsb.me.uk> <cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com> <87o89pf5zi.fsf@bsb.me.uk> <R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com> <87k0kce1yk.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 09:04:26 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87k0kce1yk.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com>
Lines: 61
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ccqEGTgAupBWtQkyuIjD4mZAREDh1DM/oqa65GDX/nwtqToFyRPzfoEYg6VoeDqBez5BdVS+Le9KRRQ!DqiLfoFVhLRE8zJJBTSDOz44ljcmkSd9c6LgjtUtxFbF9VEkuVVU7V2c8YQ0tvNqahit2K8vNatT!vxE=
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: 4466
 by: olcott - Mon, 23 Aug 2021 14:04 UTC

On 8/23/2021 8:16 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> When a computation is forced to stop running this is an entirely
>> different thing than a computation that stops running because it is
>> has completed all of its steps. If we allow this ambiguity to remain
>> then disingenuous double talk seems more plausible.
>
> How is a TM "forced" to do anything?

You aready know this, you are merely being tediously nit picky about my
choice of words. When a TM has had its simulation aborted it stops
running. Some people that are not very smart could misconstrue this as
normal termination.

> It's just a silly metaphor that
> keeps the door open for different kinds of halting. A TM computation
> that halts, for whatever reason, is a halting TM. It's a word game.
>

No this is not the case and you know it.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

You must be an atheist because a Christian knows the penalty for lying.

> This is, despite the absurdity, a serious question. If I gave you a TM
> and an input, how could you tell the difference between it simply
> halting ("completing all of its steps") and being "forced to stop
> running"? If you can't do that (and I know you can't), you should be
> able to show me two TM computations, one which just halts and one which
> is forced to stop.
When any x86/TM machine description never stops running unless its
simulation is aborted then the simulating halt decider has correctly
decided that its input never halts.

> And for anyone else, here's why you are wrong about your H in two
> sentences. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
> applied to ⟨Ĥ⟩. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
> fact, accept it.
>

That is a ridiculously foolish thing to say:
Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞

By accepting the ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does halt) the input
never halts.

--
Copyright 2021 Pete Olcott

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

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

<edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!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, 23 Aug 2021 09:08:27 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 09:08:26 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87eeake1fm.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
Lines: 81
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-hPZPXgEN3JczPMvV/AHn/feU3nZrrgdMVJ9bMjnzyprb0DulHZAZsMeHPKtsUEQ8e8orIaGJnn1Yk2i!y9+BGayNTYugbNkJA2tMtZ0dkBJ9BHwSHf4sYCk/7ejJp8176qC3HJrs6G5hoK/JWkaI7F4jTR3n!h08=
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: 4967
 by: olcott - Mon, 23 Aug 2021 14:08 UTC

On 8/23/2021 8:27 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 5:33 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>>>
>>>>>>> To wrap up this sub-thread, let's just say that you currently can't see
>>>>>>> how to meet my specification.
>>>>>>
>>>>>> Let's just say that it is not cost effective for me to untangle any
>>>>>> more convoluted paraphrase of the exact same things that I have
>>>>>> already been saying without a specific high level overview of material
>>>>>> differences that seem to be non-existent.
>>>>>
>>>>> I wondered why you posted a trace showing the wrong behaviour,
>>>>
>>>> It is the actual behavior that the code specifies.
>>> A rather obvious thing to say. Code does what it does. It's the
>>> behaviour I specified that's impossible. No algorithm can determine
>>> that a function call will return just as no algorithm can determine if a
>>> program will halt.
>>
>> I show a program that does this in the "impossible" case.
>
> You pretended to be able to meet my challenge by, rather oddly, posting
> a trace that showed the wrong behaviour.
>

That you fail to comprhend that it is the correct behavior provides zero
evidence that it is the wrong behavior.

> You could score big here without any need for waffle or ambiguity by
> simply posting a function that does what I specified. The test code is
> ready -- just link your function to the translation unit I provided and
> you can prove, beyond a doubt that you've have a candidate. Would that
> not be wonderful? No more arguments, just C code that does what was
> asked of it and that I say is impossible?
>

I have already proved that I am correct with a much simpler example.
Unless you can find fault with my example my proof stands.

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

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

It is the same case with the above.
The execution of P(P) is not under the dominion of H yet the input to
the simulation of H(P,P) is under the dominion of H.

This makes these two pairs of computations distinctly different from
each other. Distinctly different computations can have different
behavior without contradiction.

> (I say candidate because it's trivial to produce the right output simply
> by cheating. The specification requires another check -- the "equal
> arguments" check. But I'll grant you this: you have shown not desire to
> produce a cheating "solution".)
>

--
Copyright 2021 Pete Olcott

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

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

<i-mdneKgL54_L778nZ2dnUU7-fPNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder5.feed.usenet.farm!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!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Aug 2021 09:37:21 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87im06wiup.fsf@bsb.me.uk> <DJGdncQOXNbfHYT8nZ2dnUU7-dPNnZ2d@giganews.com> <874kbqw62q.fsf@bsb.me.uk> <W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com> <87h7fpuf5v.fsf@bsb.me.uk> <AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com> <875yw4v08g.fsf@bsb.me.uk> <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com> <8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 09:37:20 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87r1eppoe5.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <i-mdneKgL54_L778nZ2dnUU7-fPNnZ2d@giganews.com>
Lines: 118
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-cAeODw0WVb/iLd+6/QZsspkpFrxEc+tdW19EKjW1xpc94KHzn8sBRw1pvThc/tncCtTYCb2LdPRIFzV!kvmIVCZtXBNK3oNFQZ5fgY/1Zv2RDTGKXHS9DsD902QGCx4EGwZjbpdv1WtRHW0aesTeXw8oS4Wj!YGA=
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: 5486
 by: olcott - Mon, 23 Aug 2021 14:37 UTC

On 8/19/2021 8:14 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/18/2021 8:42 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/18/2021 8:16 PM, Ben Bacarisse wrote:
>
>>>>> Yes. I cut them because they are not the specification of the function
>>>>> that I will challenge you to write.
>>>>
>>>> That is out-of-scope and you know it.
>>>
>>> Not in my opinion, no. A function that that shows there are undecidable
>>> sets should worry you, but for some reason you prefer to stick with
>>> talking about your H that does something entirely unsurprising and
>>> uninteresting.
>>
>> So when I correctly refute the halting problem proofs you say no I did
>> not refute every proof in the universe and the halting problem proof
>> is one of these proofs therefore I did not refute the halting problem
>> proof.
>
> No, I'm not saying that.
>
> Anyway, in case you are interested, here is the specification of the
> function you can't write:
>
> The computational model is C code with no memory restrictions. Of
> course, if you don't actually hit the memory limits of a C
> implementation it's just actual C code. I'd be happy to say more about
> this model of computation if you think the details will matter to your
> solution.
>
> The problem is that of deciding if a function would return if called
> from main. A "return decider" (in this model) is a C function returning
> _Bool that always returns a value to the expression in which it was
> called. A return decider always returns the same value for any
> arguments that represnet the same function call expression.
>
> Your mission, should you chose to accept it, is to write a return
> decider B with this prototype
>
> typedef uintptr_t data;
> typedef void (*function)(data);
>
> extern _Bool B(function, data);
>
> such that B(f, d) returns true if and only if a call of f from main with
> argument d returns to main. The two arguments, f and d, are said to
> represenet the call expression f(d).
>
> If, rather than just thinking you can do this, you have actual C code,
> you should provide either source or a compiled translation unit that can
> be linked with this one:
>
> #include <stdint.h>
> #include <stdio.h>
>
> typedef uintptr_t data;
> typedef void (*function)(data);
>
> extern _Bool B(function, data);
>
> void B_hat(data x) { if (B((function)x, x)) while (1); }
>

All that you did was
(a) Change the names,
(b) Use different syntax and
(c) Add some C function calls that have no effect of the halt deciding
semantics.

This is computationally equivalent:

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

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

> int main(void)
> {
> printf("%d\n", B(B_hat, (data)B_hat));
> fflush(stdout);
> B_hat((data)B_hat);
> puts("returned");
> }
>
> The output should be either
>
> 1
> returned
>
> or
>
> 0
>
> with no further output. Of course you could always just agree that no
> such function B can be written.
>

--
Copyright 2021 Pete Olcott

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

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

<9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:2298:: with SMTP id o24mr21302639qkh.235.1629729823792;
Mon, 23 Aug 2021 07:43:43 -0700 (PDT)
X-Received: by 2002:a25:e6d2:: with SMTP id d201mr14490392ybh.396.1629729823601;
Mon, 23 Aug 2021 07:43:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Mon, 23 Aug 2021 07:43:43 -0700 (PDT)
In-Reply-To: <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:5c43:4a05:bc6e:a623;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:5c43:4a05:bc6e:a623
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk>
<87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com>
<87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com>
<871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
<87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com>
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Mon, 23 Aug 2021 14:43:43 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Malcolm McLean - Mon, 23 Aug 2021 14:43 UTC

On Monday, 23 August 2021 at 15:08:34 UTC+1, olcott wrote:
> On 8/23/2021 8:27 AM, Ben Bacarisse wrote:
>
> > You could score big here without any need for waffle or ambiguity by
> > simply posting a function that does what I specified. The test code is
> > ready -- just link your function to the translation unit I provided and
> > you can prove, beyond a doubt that you've have a candidate. Would that
> > not be wonderful? No more arguments, just C code that does what was
> > asked of it and that I say is impossible?
> >
> I have already proved that I am correct with a much simpler example.
> Unless you can find fault with my example my proof stands.
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> P((u32)P);
> }
>
> It is the same case with the above.
> The execution of P(P) is not under the dominion of H yet the input to
> the simulation of H(P,P) is under the dominion of H.
>
> This makes these two pairs of computations distinctly different from
> each other. Distinctly different computations can have different
> behavior without contradiction.
>
So that's the crux of it. If you say that the behaviour of the function (C usage)
can change based on its execution environment, you are no longer in the world of
so-called "pure" mathematical functions.

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

<uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!rocksolid2!i2pn.org!aioe.org!news.uzoreto.com!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: Mon, 23 Aug 2021 10:01:15 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com> <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 10:01:14 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com>
Lines: 60
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-gZ4v1syV82jHknQNIZGcWiLqBZ9IktJvFtajza4V4KUZMx8l6i5kdXmj7zO8XAfYNS3ofhpUWUB3sWY!De7sMQ55cCd6CFMcnh+7/Y5cXp4sTw8ci3HyDyq7Tju48E2jHxldCSiw6o6nbxdwSQIND1G+4ZAw!vfE=
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: 4363
 by: olcott - Mon, 23 Aug 2021 15:01 UTC

On 8/23/2021 9:43 AM, Malcolm McLean wrote:
> On Monday, 23 August 2021 at 15:08:34 UTC+1, olcott wrote:
>> On 8/23/2021 8:27 AM, Ben Bacarisse wrote:
>>
>>> You could score big here without any need for waffle or ambiguity by
>>> simply posting a function that does what I specified. The test code is
>>> ready -- just link your function to the translation unit I provided and
>>> you can prove, beyond a doubt that you've have a candidate. Would that
>>> not be wonderful? No more arguments, just C code that does what was
>>> asked of it and that I say is impossible?
>>>
>> I have already proved that I am correct with a much simpler example.
>> Unless you can find fault with my example my proof stands.
>> // Simplified Linz Ĥ (Linz:1990:319)
>> // Strachey(1965) CPL translated to C
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> P((u32)P);
>> }
>>
>> It is the same case with the above.
>> The execution of P(P) is not under the dominion of H yet the input to
>> the simulation of H(P,P) is under the dominion of H.
>>
>> This makes these two pairs of computations distinctly different from
>> each other. Distinctly different computations can have different
>> behavior without contradiction.
>>
> So that's the crux of it. If you say that the behaviour of the function (C usage)
> can change based on its execution environment, you are no longer in the world of
> so-called "pure" mathematical functions.
>

It might superficially seem that way only because the concept of a
simulating halt decider is new and has not been extensively studied.

void Infinite_Loop()
{ HERE: goto HERE;
}

It is very obvious that the behavior the direct execution of the above
computation must be different than the behavior of the simulation of
this same computation under the dominion of a simulating halt decider.

It is also quite obvious that the simulating halt decider does correctly
decide that Infinite_Loop() never halts.

--
Copyright 2021 Pete Olcott

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

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

<875yvwdual.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Followup-To: comp.theory
Date: Mon, 23 Aug 2021 17:01:38 +0100
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <875yvwdual.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87o89usfll.fsf@bsb.me.uk>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>
<871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk>
<nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com>
<87bl5pgm5f.fsf@bsb.me.uk>
<3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com>
<871r6kfo1a.fsf@bsb.me.uk>
<f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
<87eeake1fm.fsf@bsb.me.uk>
<edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="20839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/oEU5clnitSfpOJNCo/4ZvBKBCBTG2sj8="
Cancel-Lock: sha1:bR2Y2epAgDhPynzRtFB9CCfM9qM=
sha1:7Y2vQvvjuab2FGcXfA7zGtBammw=
X-BSB-Auth: 1.24b40752f7cca5a3b87c.20210823170138BST.875yvwdual.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 16:01 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 8:27 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 5:33 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>>>>
>>>>>>>> To wrap up this sub-thread, let's just say that you currently can't see
>>>>>>>> how to meet my specification.
>>>>>>>
>>>>>>> Let's just say that it is not cost effective for me to untangle any
>>>>>>> more convoluted paraphrase of the exact same things that I have
>>>>>>> already been saying without a specific high level overview of material
>>>>>>> differences that seem to be non-existent.
>>>>>>
>>>>>> I wondered why you posted a trace showing the wrong behaviour,
>>>>>
>>>>> It is the actual behavior that the code specifies.
>>>> A rather obvious thing to say. Code does what it does. It's the
>>>> behaviour I specified that's impossible. No algorithm can determine
>>>> that a function call will return just as no algorithm can determine if a
>>>> program will halt.
>>>
>>> I show a program that does this in the "impossible" case.
>> You pretended to be able to meet my challenge by, rather oddly, posting
>> a trace that showed the wrong behaviour.
>
> That you fail to comprhend that it is the correct behavior provides
> zero evidence that it is the wrong behavior.

I specified the function and showed the two permitted outputs from the
test program. Your example generated different output. I thought one
of your skills was software engineering. Do you declare a program
correct and demand payment even when it does not meet the client's
specification?

>> You could score big here without any need for waffle or ambiguity by
>> simply posting a function that does what I specified. The test code is
>> ready -- just link your function to the translation unit I provided and
>> you can prove, beyond a doubt that you've have a candidate. Would that
>> not be wonderful? No more arguments, just C code that does what was
>> asked of it and that I say is impossible?
>
> I have already proved that I am correct with a much simpler example.

Ah but your functions (both B and H) are boring. A function that is
"correct" despite returning false for some halting computations (or, in
the case of B, for some returning function calls) is trivial to write.

You want a big win -- to show you have something that would make me (and
others) really sit up and take notice, something I would consider
impossible until you came along. So that's what I am offering. And the
initial proof is just two lines of output that can't be argues with.
However, it involves meeting my specification, not yours. Yours is way
too easy to meet.

--
Ben.

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

<87zgt8cfhb.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Date: Mon, 23 Aug 2021 17:06:56 +0100
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <87zgt8cfhb.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>
<871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk>
<nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com>
<87bl5pgm5f.fsf@bsb.me.uk>
<3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com>
<871r6kfo1a.fsf@bsb.me.uk>
<f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
<87eeake1fm.fsf@bsb.me.uk>
<edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
<9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com>
<uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="20839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/XDRUg5+GOwCWxXJxnq4u0Gdtf9cnHG8A="
Cancel-Lock: sha1:bA9ANdm9h29xNwjjMrHS5fWCcVE=
sha1:pPvaxy/2B245iSqyY6yRysJDR2Y=
X-BSB-Auth: 1.abe35591b005c5fa66cb.20210823170656BST.87zgt8cfhb.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 16:06 UTC

olcott <NoOne@NoWhere.com> writes:

> It might superficially seem that way only because the concept of a
> simulating halt decider is new and has not been extensively studied.

You do make me laugh sometimes! Someone who appears not have read even
a single book about a topic is claiming to know what's new! I have a
degree in CS and I taught this material at a university for several
years. To write those lectures I read many books and papers on the
subject, but even I would not claim to know what is (or even was then)
"new" in the field as it was not my speciality.

--
Ben.

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

<87tujgcf8i.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Followup-To: comp.theory
Date: Mon, 23 Aug 2021 17:12:13 +0100
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <87tujgcf8i.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<874kbqw62q.fsf@bsb.me.uk>
<W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com>
<87h7fpuf5v.fsf@bsb.me.uk>
<AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk>
<oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87o89usfll.fsf@bsb.me.uk>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<i-mdneKgL54_L778nZ2dnUU7-fPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="20839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+RFcjNMDRzgwMnfqtiJCxo0nxudxoagHE="
Cancel-Lock: sha1:7rGdpbTo0fhL2Z4fHzBL4WPYEHQ=
sha1:1ZTyW6eRQctO0ssKYhv4paS4dFY=
X-BSB-Auth: 1.36d20a476eb0cc5cd17b.20210823171213BST.87tujgcf8i.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 16:12 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/19/2021 8:14 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/18/2021 8:42 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/18/2021 8:16 PM, Ben Bacarisse wrote:
>>
>>>>>> Yes. I cut them because they are not the specification of the function
>>>>>> that I will challenge you to write.
>>>>>
>>>>> That is out-of-scope and you know it.
>>>>
>>>> Not in my opinion, no. A function that that shows there are undecidable
>>>> sets should worry you, but for some reason you prefer to stick with
>>>> talking about your H that does something entirely unsurprising and
>>>> uninteresting.
>>>
>>> So when I correctly refute the halting problem proofs you say no I did
>>> not refute every proof in the universe and the halting problem proof
>>> is one of these proofs therefore I did not refute the halting problem
>>> proof.
>> No, I'm not saying that.
>> Anyway, in case you are interested, here is the specification of the
>> function you can't write:
>> The computational model is C code with no memory restrictions. Of
>> course, if you don't actually hit the memory limits of a C
>> implementation it's just actual C code. I'd be happy to say more about
>> this model of computation if you think the details will matter to your
>> solution.
>> The problem is that of deciding if a function would return if called
>> from main. A "return decider" (in this model) is a C function returning
>> _Bool that always returns a value to the expression in which it was
>> called. A return decider always returns the same value for any
>> arguments that represnet the same function call expression.
>> Your mission, should you chose to accept it, is to write a return
>> decider B with this prototype
>> typedef uintptr_t data;
>> typedef void (*function)(data);
>> extern _Bool B(function, data);
>> such that B(f, d) returns true if and only if a call of f from main with
>> argument d returns to main. The two arguments, f and d, are said to
>> represenet the call expression f(d).
>> If, rather than just thinking you can do this, you have actual C code,
>> you should provide either source or a compiled translation unit that can
>> be linked with this one:
>> #include <stdint.h>
>> #include <stdio.h>
>> typedef uintptr_t data;
>> typedef void (*function)(data);
>> extern _Bool B(function, data);
>> void B_hat(data x) { if (B((function)x, x)) while (1); }
>>
>
> All that you did was
> (a) Change the names,
> (b) Use different syntax and
> (c) Add some C function calls that have no effect of the halt deciding
> semantics.

No. I changed the specification, provided a test program and gave the
two permitted outputs. If there is anything you don't understand I am
happy to give more detail.

> This is computationally equivalent:
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> P((u32)P);
> }

From your execution trace you appear to accept as "correct" output that
I deem to be erroneous. You are implementing some other specification.

>> int main(void)
>> {
>> printf("%d\n", B(B_hat, (data)B_hat));
>> fflush(stdout);
>> B_hat((data)B_hat);
>> puts("returned");
>> }
>> The output should be either
>> 1
>> returned
>> or
>> 0
>> with no further output. Of course you could always just agree that no
>> such function B can be written.

Your trace shows the output to be

0
returned

--
Ben.

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

<MqqdnfyQ6PwPU778nZ2dnUU7-KnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!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, 23 Aug 2021 11:36:34 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com> <875yvwdual.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 11:36:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <875yvwdual.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <MqqdnfyQ6PwPU778nZ2dnUU7-KnNnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-tG4NqgIKgPzUFMmBm8T6mCqv8m4ouCITMfrz+3pkEKzCh4SxGikJY5qxEzMuhAiskuKnbfm156h4qmT!/mJcE4L6jW+0ue5lX+0FxDLd/OkrXJtFHATovO/uKQPlvLyLPkOYxVEV1ap0hd7p6kMaTzV4JEOT!O90=
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: 5693
 by: olcott - Mon, 23 Aug 2021 16:36 UTC

On 8/23/2021 11:01 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 8:27 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 5:33 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>>>> To wrap up this sub-thread, let's just say that you currently can't see
>>>>>>>>> how to meet my specification.
>>>>>>>>
>>>>>>>> Let's just say that it is not cost effective for me to untangle any
>>>>>>>> more convoluted paraphrase of the exact same things that I have
>>>>>>>> already been saying without a specific high level overview of material
>>>>>>>> differences that seem to be non-existent.
>>>>>>>
>>>>>>> I wondered why you posted a trace showing the wrong behaviour,
>>>>>>
>>>>>> It is the actual behavior that the code specifies.
>>>>> A rather obvious thing to say. Code does what it does. It's the
>>>>> behaviour I specified that's impossible. No algorithm can determine
>>>>> that a function call will return just as no algorithm can determine if a
>>>>> program will halt.
>>>>
>>>> I show a program that does this in the "impossible" case.
>>> You pretended to be able to meet my challenge by, rather oddly, posting
>>> a trace that showed the wrong behaviour.
>>
>> That you fail to comprehend that it is the correct behavior provides
>> zero evidence that it is the wrong behavior.
>
> I specified the function and showed the two permitted outputs from the
> test program. Your example generated different output. I thought one
> of your skills was software engineering. Do you declare a program
> correct and demand payment even when it does not meet the client's
> specification?
>

Your program is computationally equivalent to mine and you are simply
wrong about what the outputs should be.

>>> You could score big here without any need for waffle or ambiguity by
>>> simply posting a function that does what I specified. The test code is
>>> ready -- just link your function to the translation unit I provided and
>>> you can prove, beyond a doubt that you've have a candidate. Would that
>>> not be wonderful? No more arguments, just C code that does what was
>>> asked of it and that I say is impossible?
>>
>> I have already proved that I am correct with a much simpler example.
>
> Ah but your functions (both B and H) are boring. A function that is
> "correct" despite returning false for some halting computations (or, in
> the case of B, for some returning function calls) is trivial to write.
>
> You want a big win -- to show you have something that would make me (and
> others) really sit up and take notice, something I would consider
> impossible until you came along. So that's what I am offering. And the
> initial proof is just two lines of output that can't be argues with.
> However, it involves meeting my specification, not yours. Yours is way
> too easy to meet.
>

Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.

The above correctly decides:
(a) Conventional halting computations
(b) Conventional computations that never halt
(c) Computations having pathological self-reference

--
Copyright 2021 Pete Olcott

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

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

<JamdnXUt-7AvUr78nZ2dnUU7-TfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!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: Mon, 23 Aug 2021 11:41:22 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com> <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com> <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com> <87zgt8cfhb.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 11:41:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87zgt8cfhb.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <JamdnXUt-7AvUr78nZ2dnUU7-TfNnZ2d@giganews.com>
Lines: 30
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-PMZe07vczIpnauorx1/L6POh5SzGJrI9lYQi7rl+EuHVpYdhht9KjaG/wj6MI4J3sXjdqClzfNhhJtg!kWl54g5w2Mp6S9T49oeXuBXpaXBxryD1vJZIrZwn7rxayV3fpA1jnubCk9fPxPDnGVv1/BDSSjZy!KZw=
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: 3285
 by: olcott - Mon, 23 Aug 2021 16:41 UTC

On 8/23/2021 11:06 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> It might superficially seem that way only because the concept of a
>> simulating halt decider is new and has not been extensively studied.
>
> You do make me laugh sometimes! Someone who appears not have read even
> a single book about a topic is claiming to know what's new! I have a
> degree in CS

Do you mean an associate degree in data processing?
Your total lack of knowledge of operating systems context switching
would tend to indicate that you never had a course on the internal
design of operating systems. This is typically required for any actual
computer science (as opposed to data processing) degree.

> and I taught this material at a university for several
> years. To write those lectures I read many books and papers on the
> subject, but even I would not claim to know what is (or even was then)
> "new" in the field as it was not my speciality.

Yet the lack of a reference to any in depth study of simulating halt
deciders makes your "rebuttal" totally vacuous.

--
Copyright 2021 Pete Olcott

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

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

<8rednchN8_dETb78nZ2dnUU7-YnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!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: Mon, 23 Aug 2021 11:46:16 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <874kbqw62q.fsf@bsb.me.uk> <W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com> <87h7fpuf5v.fsf@bsb.me.uk> <AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com> <875yw4v08g.fsf@bsb.me.uk> <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com> <8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <i-mdneKgL54_L778nZ2dnUU7-fPNnZ2d@giganews.com> <87tujgcf8i.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 11:46:15 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87tujgcf8i.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <8rednchN8_dETb78nZ2dnUU7-YnNnZ2d@giganews.com>
Lines: 126
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-O0L0aSxSH7Ym6hPNcuIsqSaNSPNaIiBc9Cwd/WfMeXkbCmBlXt1MCL0V/V1W1p6i7RxdrlFklkoyvAF!ARzbAfSCm+BjGtBpv4+RJoME1A6hYV7r833O7O44EkdAxp7wITk5rDcseMwixwJY7T+FN10LAjMR!nM4=
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: 6566
 by: olcott - Mon, 23 Aug 2021 16:46 UTC

On 8/23/2021 11:12 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/19/2021 8:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/18/2021 8:42 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/18/2021 8:16 PM, Ben Bacarisse wrote:
>>>
>>>>>>> Yes. I cut them because they are not the specification of the function
>>>>>>> that I will challenge you to write.
>>>>>>
>>>>>> That is out-of-scope and you know it.
>>>>>
>>>>> Not in my opinion, no. A function that that shows there are undecidable
>>>>> sets should worry you, but for some reason you prefer to stick with
>>>>> talking about your H that does something entirely unsurprising and
>>>>> uninteresting.
>>>>
>>>> So when I correctly refute the halting problem proofs you say no I did
>>>> not refute every proof in the universe and the halting problem proof
>>>> is one of these proofs therefore I did not refute the halting problem
>>>> proof.
>>> No, I'm not saying that.
>>> Anyway, in case you are interested, here is the specification of the
>>> function you can't write:
>>> The computational model is C code with no memory restrictions. Of
>>> course, if you don't actually hit the memory limits of a C
>>> implementation it's just actual C code. I'd be happy to say more about
>>> this model of computation if you think the details will matter to your
>>> solution.
>>> The problem is that of deciding if a function would return if called
>>> from main. A "return decider" (in this model) is a C function returning
>>> _Bool that always returns a value to the expression in which it was
>>> called. A return decider always returns the same value for any
>>> arguments that represnet the same function call expression.
>>> Your mission, should you chose to accept it, is to write a return
>>> decider B with this prototype
>>> typedef uintptr_t data;
>>> typedef void (*function)(data);
>>> extern _Bool B(function, data);
>>> such that B(f, d) returns true if and only if a call of f from main with
>>> argument d returns to main. The two arguments, f and d, are said to
>>> represenet the call expression f(d).
>>> If, rather than just thinking you can do this, you have actual C code,
>>> you should provide either source or a compiled translation unit that can
>>> be linked with this one:
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> typedef uintptr_t data;
>>> typedef void (*function)(data);
>>> extern _Bool B(function, data);
>>> void B_hat(data x) { if (B((function)x, x)) while (1); }
>>>
>>
>> All that you did was
>> (a) Change the names,
>> (b) Use different syntax and
>> (c) Add some C function calls that have no effect of the halt deciding
>> semantics.
>
> No. I changed the specification, provided a test program and gave the
> two permitted outputs. If there is anything you don't understand I am
> happy to give more detail.
>

The specification had no material changes. You merely stated your
incorrect opinion about what the output should be.

>> This is computationally equivalent:
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> // Strachey(1965) CPL translated to C
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> P((u32)P);
>> }
>
> From your execution trace you appear to accept as "correct" output that
> I deem to be erroneous. You are implementing some other specification.

You are simply wrong about deeming it to be erroneous.This merely shows
that my proof that it is not erroneous was too difficult for you to
understand.

The way that outside observers can tell that your rebuttals are
erroneous is that they always sidestep rather than directly address the
points that I make.

>
>>> int main(void)
>>> {
>>> printf("%d\n", B(B_hat, (data)B_hat));
>>> fflush(stdout);
>>> B_hat((data)B_hat);
>>> puts("returned");
>>> }
>>> The output should be either
>>> 1
>>> returned
>>> or
>>> 0
>>> with no further output. Of course you could always just agree that no
>>> such function B can be written.
>
> Your trace shows the output to be
>
> 0
> returned
>

--
Copyright 2021 Pete Olcott

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

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

<368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a37:607:: with SMTP id 7mr22957111qkg.0.1629741530077;
Mon, 23 Aug 2021 10:58:50 -0700 (PDT)
X-Received: by 2002:a25:9a87:: with SMTP id s7mr23903843ybo.360.1629741529842;
Mon, 23 Aug 2021 10:58:49 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Mon, 23 Aug 2021 10:58:49 -0700 (PDT)
In-Reply-To: <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:5c43:4a05:bc6e:a623;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:5c43:4a05:bc6e:a623
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk>
<87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com>
<87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com>
<871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
<87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
<9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com> <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Mon, 23 Aug 2021 17:58:50 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Malcolm McLean - Mon, 23 Aug 2021 17:58 UTC

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

So that's a good basis to work from.

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

<BM6dnWtg9_n8e778nZ2dnUU7-Y3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!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: Mon, 23 Aug 2021 13:18:09 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com> <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com> <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com> <368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 13:18:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <BM6dnWtg9_n8e778nZ2dnUU7-Y3NnZ2d@giganews.com>
Lines: 67
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FPpTm1pCkfvD4esaxhQU+8hQY50kNqMBhi/vB7DHZhm6feync4sDuL5CSbqvs3kEss1BWfEnZgNN1gs!iBSR+RR/23D4eZaFzVrMdu1D1kC5pNIOxDlCQyVG5b2uM3/cJEBlbsSZYQxQ4Nbc2upeaot7OWL1!V2g=
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: 4899
 by: olcott - Mon, 23 Aug 2021 18:18 UTC

On 8/23/2021 12:58 PM, Malcolm McLean wrote:
> On Monday, 23 August 2021 at 16:01:23 UTC+1, olcott wrote:
>> On 8/23/2021 9:43 AM, Malcolm McLean wrote:
>>
>>> So that's the crux of it. If you say that the behaviour of the function (C usage)
>>> can change based on its execution environment, you are no longer in the world of
>>> so-called "pure" mathematical functions.
>>>
>> It might superficially seem that way only because the concept of a
>> simulating halt decider is new and has not been extensively studied.
>>
> No one serious is interested in halt deciders for the same reason that no-one serious
> is interested in perpetual motion machines. If it is known that something cannot be
> achieved, you don't waste time on things that might look superficially as if they
> are getting there.

Yes because like with many things once the fallible human mind is made
up and closed it is welded shut and no amount of facts to the contrary
will open it. Thus the value of the refuting of the halting theorem
moves from computer science to psychology for many (thankfully not all)
people.

>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> It is very obvious that the behavior the direct execution of the above
>> computation must be different than the behavior of the simulation of
>> this same computation under the dominion of a simulating halt decider.
>>
>> It is also quite obvious that the simulating halt decider does correctly
>> decide that Infinite_Loop() never halts.
>>
> So we agree that Infinite_Loop() is a computation, and never halts.

Computation theory intentionally restricts the expressiveness of its own
technical terms.

Computations are defined as always halting such that a sequence of
automated steps that never halt is not allowed to be called a computation.

A computation that never halts must be referred to in the same weird way
that https://en.wikipedia.org/wiki/Prince_(musician) had to be referred
to after he changed his name to an unpronounceable symbol:
The musical artist formally known as "Prince".

An infinite loop is a sequence of automated steps that would specify a
computation if these steps ever halted.

> H(Infinite_Loop), with whatever twiddles we need for the unused arguments,

I have defined H0 as an exact copy of H except that it takes zero
arguments. I also have a corresponding H1 (exact copy of H), and H2.

> is also a computation. It halts and returns false.
>
> So that's a good basis to work from.
>

--
Copyright 2021 Pete Olcott

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

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

<feKdnXlevI0gdL78nZ2dnUU7-N_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Aug 2021 13:32:29 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87o89usfll.fsf@bsb.me.uk> <uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com> <87sfz6qpk9.fsf@bsb.me.uk> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com> <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com> <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com> <368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 13:32:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <368606ac-2944-481e-b4d1-87b9adcf8ee1n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <feKdnXlevI0gdL78nZ2dnUU7-N_NnZ2d@giganews.com>
Lines: 52
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-O6QTzrB+Y8BPlJeniA9rl6/KzeGDizB51sBxkjvwL58XkYmQeM6TtRTxBxwufwxrQr1uF+CrXGgX8J2!ATsPTLSmztqCDC6Rhhspv6yXr3eVEKQ9akP26b+o8DFI/Cr2WEdRHslqtBiMKxI/c0Y86uWOX3Cz!VjY=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4511
 by: olcott - Mon, 23 Aug 2021 18:32 UTC

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

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

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

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

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

--
Copyright 2021 Pete Olcott

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

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

<87k0kcc882.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Date: Mon, 23 Aug 2021 19:43:41 +0100
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <87k0kcc882.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>
<871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk>
<nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com>
<87bl5pgm5f.fsf@bsb.me.uk>
<3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com>
<871r6kfo1a.fsf@bsb.me.uk>
<f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
<87eeake1fm.fsf@bsb.me.uk>
<edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
<9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com>
<uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com>
<87zgt8cfhb.fsf@bsb.me.uk>
<JamdnXUt-7AvUr78nZ2dnUU7-TfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="25904"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/q8tgBqv1IaxWNSDGWd8YYyDOtc9ipb/Q="
Cancel-Lock: sha1:fCeIqXQjwdGSVyvzwidhVq+n9tM=
sha1:a+KkhFvybft/XwGM/8gbbTfMYeo=
X-BSB-Auth: 1.89439774e84f79fb1957.20210823194341BST.87k0kcc882.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 18:43 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 11:06 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> It might superficially seem that way only because the concept of a
>>> simulating halt decider is new and has not been extensively studied.
>> You do make me laugh sometimes! Someone who appears not have read even
>> a single book about a topic is claiming to know what's new! I have a
>> degree in CS
>
> Do you mean an associate degree in data processing?

What's that? Is it some sort of business degree?

> Your total lack of knowledge of operating systems context switching
> would tend to indicate that you never had a course on the internal
> design of operating systems. This is typically required for any actual
> computer science (as opposed to data processing) degree.

Funny!

>> and I taught this material at a university for several
>> years. To write those lectures I read many books and papers on the
>> subject, but even I would not claim to know what is (or even was then)
>> "new" in the field as it was not my speciality.
>
> Yet the lack of a reference to any in depth study of simulating halt
> deciders makes your "rebuttal" totally vacuous.

Your logic is flawed. I'm not rebutting anything. I'm just noting that
I find you statement amusing. In fact you may well be correct. The
amusing part is that there is no way you can know you are correct yet
you assert it with absolute confidence.

--
Ben.

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

<JdydnSS_8p3hcr78nZ2dnUU7-cfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Aug 2021 13:57:00 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com> <87k0kiqlmm.fsf@bsb.me.uk> <GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com> <875yw2qkfb.fsf@bsb.me.uk> <2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com> <87r1eppoe5.fsf@bsb.me.uk> <CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com> <871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk> <nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com> <87bl5pgm5f.fsf@bsb.me.uk> <3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com> <871r6kfo1a.fsf@bsb.me.uk> <f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com> <87eeake1fm.fsf@bsb.me.uk> <edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com> <9e208977-059b-40ee-96b8-7a077ccf242dn@googlegroups.com> <uOudnfrrlJ-mJb78nZ2dnUU7-YvNnZ2d@giganews.com> <87zgt8cfhb.fsf@bsb.me.uk> <JamdnXUt-7AvUr78nZ2dnUU7-TfNnZ2d@giganews.com> <87k0kcc882.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 13:56:59 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87k0kcc882.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <JdydnSS_8p3hcr78nZ2dnUU7-cfNnZ2d@giganews.com>
Lines: 55
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-EbXwbbKjIp2c/9NEnLfPJZ5KEEDsQKZh3tfYP+PnAM1URCW3KOGrhrC4Bli4/fNmL9ovaZp552LRVZ7!pg8UF4TIc0GWAAxYteOheDtDTUvFRQfI3KVgTAJFKTZwPewybvkjHaTo4rdiZc83FmapDp2zo1Ub!OeU=
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: 4391
 by: olcott - Mon, 23 Aug 2021 18:56 UTC

On 8/23/2021 1:43 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 11:06 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> It might superficially seem that way only because the concept of a
>>>> simulating halt decider is new and has not been extensively studied.
>>> You do make me laugh sometimes! Someone who appears not have read even
>>> a single book about a topic is claiming to know what's new! I have a
>>> degree in CS
>>
>> Do you mean an associate degree in data processing?
>
> What's that? Is it some sort of business degree?
>
>> Your total lack of knowledge of operating systems context switching
>> would tend to indicate that you never had a course on the internal
>> design of operating systems. This is typically required for any actual
>> computer science (as opposed to data processing) degree.
>
> Funny!

None-the-less true. Even if someone forgets 99% of the material of a
course on operating system internal design they would not forget one of
its most basic elements: process context switching.

>>> and I taught this material at a university for several
>>> years. To write those lectures I read many books and papers on the
>>> subject, but even I would not claim to know what is (or even was then)
>>> "new" in the field as it was not my speciality.
>>
>> Yet the lack of a reference to any in depth study of simulating halt
>> deciders makes your "rebuttal" totally vacuous.
>
> Your logic is flawed. I'm not rebutting anything. I'm just noting that
> I find you statement amusing. In fact you may well be correct. The
> amusing part is that there is no way you can know you are correct yet
> you assert it with absolute confidence.
>

What is the actual depth of your understanding of computer science?
Do you have the actual equivalent of a BS in comuter science or is it
only a two year degree based on less technical material?

I still remember the look-ahead carry-generator circuit from 38 years
ago. Much of the course material from many of the courses has been
directly applied for decades as a software engineer thus keeping in
fresher in my mind.

--
Copyright 2021 Pete Olcott

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

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

<87bl5oc62l.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Followup-To: comp.theory
Date: Mon, 23 Aug 2021 20:30:10 +0100
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <87bl5oc62l.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87pmu6topr.fsf@bsb.me.uk>
<-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com>
<87eeamtmoh.fsf@bsb.me.uk>
<z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com>
<87eeamjmkl.fsf@bsb.me.uk>
<y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com>
<8735r1k0p0.fsf@bsb.me.uk>
<TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com>
<87r1elihh9.fsf@bsb.me.uk>
<c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>
<87czq5i9u0.fsf@bsb.me.uk>
<srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com>
<87y28tgt3w.fsf@bsb.me.uk>
<xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com>
<87h7fhgpjm.fsf@bsb.me.uk>
<cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com>
<87o89pf5zi.fsf@bsb.me.uk>
<R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com>
<87k0kce1yk.fsf@bsb.me.uk>
<edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="21873"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eJogeNRWrdXrzEN9JdOhXkDymdy7oXEg="
Cancel-Lock: sha1:SqFKHM+aiqlvETc/SqWax01f9Xg=
sha1:VMhMqLbhDgNDveOUwDsexgAXg0Y=
X-BSB-Auth: 1.5bd04d0c007acbddba6d.20210823203010BST.87bl5oc62l.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 19:30 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 8:16 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> When a computation is forced to stop running this is an entirely
>>> different thing than a computation that stops running because it is
>>> has completed all of its steps. If we allow this ambiguity to remain
>>> then disingenuous double talk seems more plausible.
>> How is a TM "forced" to do anything?
>
> You aready know this,

Nope. I have no idea. TM's halt or they don't and they are never
forced to do anything. You don't really know what it means either or
you would have addressed the question of what it means seriously.

> you are merely being tediously nit picky about my choice of words.

As any journal editor or article reviewer would be. Be assured that I
am being very generous is the errors I /don't/ pick up on. Your vague
and undefined words will be absolutely shredded by anyone who has to
read a paper should you ever think you can write one.

> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Truism:
>>> Every simulation that would never stop unless Halts() stops
>>> it at some point specifies infinite execution.
>>
>> Any algorithm that implements this truism is, of course, a halting
>> decider.
>
> You must be an atheist because a Christian knows the penalty for
> lying.

You still won't answer my question will you? Avoid, avoid, avoid! You
quote me approvingly -- does that mean you have changed your mind and
you are now claiming to have an algorithm that decides halting (in
general)? You have studiously avoided making that claim so far.

>> This is, despite the absurdity, a serious question. If I gave you a TM
>> and an input, how could you tell the difference between it simply
>> halting ("completing all of its steps") and being "forced to stop
>> running"? If you can't do that (and I know you can't), you should be
>> able to show me two TM computations, one which just halts and one which
>> is forced to stop.

> When any x86/TM machine...

We are talking about TMs. You probably don't know what your words games
mean anymore than I do which is why you avoided the question. (Avoid,
avoid, avoid!)

>> And for anyone else, here's why you are wrong about your H in two
>> sentences. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
>> applied to ⟨Ĥ⟩. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
>> fact, accept it.
>
> That is a ridiculously foolish thing to say:
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>
> By accepting the ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does halt) the input
> never halts.

By Jove, I think you've got it!! If I can stomach using your
non-technical terms for once the converse also holds: By rejecting the
⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does not halt) the input halts.

The only question is in which way your Ĥ (and thus your H) is wrong, and
you've told us enough times: it's wrong because it rejects ⟨Ĥ⟩ ⟨Ĥ⟩. But
⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation precisely because H rejects ⟨Ĥ⟩
⟨Ĥ⟩.

But thanks (seriously) for pointing out my own bad wording. You are not
wrong because H should accept the string ⟨Ĥ⟩ ⟨Ĥ⟩, you are wrong because
your H rejects it. I'll try to be more careful in future.

--
Ben.

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

<875yvwc5hw.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Date: Mon, 23 Aug 2021 20:42:35 +0100
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <875yvwc5hw.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>
<871r6pp8hn.fsf@bsb.me.uk> <87sfz1gs25.fsf@bsb.me.uk>
<nuGdnScd6YToL7_8nZ2dnUU7-UvNnZ2d@giganews.com>
<87bl5pgm5f.fsf@bsb.me.uk>
<3didnV4dlqi-nr78nZ2dnUU7-XednZ2d@giganews.com>
<871r6kfo1a.fsf@bsb.me.uk>
<f5WdnS1tuOp6A778nZ2dnUU7-VfNnZ2d@giganews.com>
<87eeake1fm.fsf@bsb.me.uk>
<edCdnTE_IvBGNr78nZ2dnUU7-WudnZ2d@giganews.com>
<875yvwdual.fsf@bsb.me.uk>
<MqqdnfyQ6PwPU778nZ2dnUU7-KnNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="21873"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/scUX4Qx3i457MRuTtp1+KK8wrZ7dp4hM="
Cancel-Lock: sha1:iDe1Cqw9d80RgdhqqE2VXzBjIGk=
sha1:FW7550A+p+nV/8hvDbJSC/N7Dzo=
X-BSB-Auth: 1.9c13a3382523f3391054.20210823204235BST.875yvwc5hw.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 19:42 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 11:01 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 8:27 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/23/2021 5:33 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>>>> To wrap up this sub-thread, let's just say that you currently can't see
>>>>>>>>>> how to meet my specification.
>>>>>>>>>
>>>>>>>>> Let's just say that it is not cost effective for me to untangle any
>>>>>>>>> more convoluted paraphrase of the exact same things that I have
>>>>>>>>> already been saying without a specific high level overview of material
>>>>>>>>> differences that seem to be non-existent.
>>>>>>>>
>>>>>>>> I wondered why you posted a trace showing the wrong behaviour,
>>>>>>>
>>>>>>> It is the actual behavior that the code specifies.
>>>>>> A rather obvious thing to say. Code does what it does. It's the
>>>>>> behaviour I specified that's impossible. No algorithm can determine
>>>>>> that a function call will return just as no algorithm can determine if a
>>>>>> program will halt.
>>>>>
>>>>> I show a program that does this in the "impossible" case.
>>>> You pretended to be able to meet my challenge by, rather oddly, posting
>>>> a trace that showed the wrong behaviour.
>>>
>>> That you fail to comprehend that it is the correct behavior provides
>>> zero evidence that it is the wrong behavior.
>>
>> I specified the function and showed the two permitted outputs from the
>> test program. Your example generated different output. I thought one
>> of your skills was software engineering. Do you declare a program
>> correct and demand payment even when it does not meet the client's
>> specification?
>
> Your program is computationally equivalent to mine

Absurd. I presented no code for B (though I did have test functions I
linked in) so you can have no way of knowing. What's more, my code
produces different output to yours (not the trace, the requested output)
so you must have your own PO-definition of computationally equivalent.

> and you are simply wrong about what the outputs should be.

So you can't meet the specification. When you couldn't implement what a
client wanted did you tell them that they were wrong about what the
outputs should be? That may explain why you have time on your hands.

--
Ben.

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

<87zgt8aqou.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Date: Mon, 23 Aug 2021 20:47:45 +0100
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <87zgt8aqou.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87h7fpuf5v.fsf@bsb.me.uk>
<AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk>
<oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87o89usfll.fsf@bsb.me.uk>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<i-mdneKgL54_L778nZ2dnUU7-fPNnZ2d@giganews.com>
<87tujgcf8i.fsf@bsb.me.uk>
<8rednchN8_dETb78nZ2dnUU7-YnNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8aef41fd7b2ba0ab89d7d98c572143e5";
logging-data="21873"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195xO5OqceWHllrYk8VAby/SikSEgoYdY4="
Cancel-Lock: sha1:i5ADq+VQMbHHx7oW/M2Sf6DvnkI=
sha1:8gFb8PlllUnpxIqJ1MIlfYdyIFM=
X-BSB-Auth: 1.91fa5733e5d7a3253b8a.20210823204745BST.87zgt8aqou.fsf@bsb.me.uk
 by: Ben Bacarisse - Mon, 23 Aug 2021 19:47 UTC

olcott <NoOne@NoWhere.com> writes:

> The specification had no material changes. You merely stated your
> incorrect opinion about what the output should be.

Totally bonkers. I think you are losing the plot. You don't get to
decide what the output should be. That's not how a specification works!

--
Ben.

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

<INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Aug 2021 14:51:52 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ distinct computations ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com> <87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com> <87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com> <8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com> <87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com> <87czq5i9u0.fsf@bsb.me.uk> <srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com> <87y28tgt3w.fsf@bsb.me.uk> <xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com> <87h7fhgpjm.fsf@bsb.me.uk> <cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com> <87o89pf5zi.fsf@bsb.me.uk> <R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com> <87k0kce1yk.fsf@bsb.me.uk> <edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com> <87bl5oc62l.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Aug 2021 14:51:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87bl5oc62l.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com>
Lines: 123
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-oCZlz/LEXByDNAvuMIAskh/4ylAarka9JDztFTLHy05/b0eauZdYADh7eQxxRUPiH5JCtwEXtNxwlGN!4CS6yeBV7ZMO6msrBJQ2e4KKYluaFLLjVUChpWgyFB7CpcSbQRpr9/wqPbOYhjkbvt3wJv8Yqhhz!paw=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7205
 by: olcott - Mon, 23 Aug 2021 19:51 UTC

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

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

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

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

I ignore dishonest dodges away from the point at hand.

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

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

Which causes it to never halts thus your:

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

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

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

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

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

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

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

--
Copyright 2021 Pete Olcott

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

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

<bMVUI.9435$6I6.2259@fx09.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? [ distinct computations ]
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com>
<87eeamtmoh.fsf@bsb.me.uk> <z--dnWg_LPquF7z8nZ2dnUU7-LvNnZ2d@giganews.com>
<87eeamjmkl.fsf@bsb.me.uk> <y9WdnbWVT-m0Ubz8nZ2dnUU7-UfNnZ2d@giganews.com>
<8735r1k0p0.fsf@bsb.me.uk> <TIidnUnAVPdb9L_8nZ2dnUU7-RPNnZ2d@giganews.com>
<87r1elihh9.fsf@bsb.me.uk> <c9ydnS0MB5tqG7_8nZ2dnUU7-R_NnZ2d@giganews.com>
<87czq5i9u0.fsf@bsb.me.uk> <srednU_7RdGxPr_8nZ2dnUU7-eHNnZ2d@giganews.com>
<87y28tgt3w.fsf@bsb.me.uk> <xamdnei4F5CzM7_8nZ2dnUU7-KPNnZ2d@giganews.com>
<87h7fhgpjm.fsf@bsb.me.uk> <cradndCzBKW6Ir_8nZ2dnUU7-XWdnZ2d@giganews.com>
<87o89pf5zi.fsf@bsb.me.uk> <R_WdnWjO0dnDlb78nZ2dnUU7-bvNnZ2d@giganews.com>
<87k0kce1yk.fsf@bsb.me.uk> <edCdnTY_IvB2N778nZ2dnUU7-WvNnZ2d@giganews.com>
<87bl5oc62l.fsf@bsb.me.uk> <INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <INadnSiJbfTFYb78nZ2dnUU7-LPNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 125
Message-ID: <bMVUI.9435$6I6.2259@fx09.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 23 Aug 2021 19:00:22 -0400
X-Received-Bytes: 7090
 by: Richard Damon - Mon, 23 Aug 2021 23:00 UTC

On 8/23/21 3:51 PM, olcott wrote:
> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 8:16 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> When a computation is forced to stop running this is an entirely
>>>>> different thing than a computation that stops running because it is
>>>>> has completed all of its steps. If we allow this ambiguity to remain
>>>>> then disingenuous double talk seems more plausible.
>>>> How is a TM "forced" to do anything?
>>>
>>> You aready know this,
>>
>> Nope.  I have no idea.  TM's halt or they don't and they are never
>> forced to do anything.  You don't really know what it means either or
>> you would have addressed the question of what it means seriously.
>>
>>> you are merely being tediously nit picky about my choice of words.
>>
>> As any journal editor or article reviewer would be.  Be assured that I
>> am being very generous is the errors I /don't/ pick up on.  Your vague
>> and undefined words will be absolutely shredded by anyone who has to
>> read a paper should you ever think you can write one.
>>
>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Truism:
>>>>> Every simulation that would never stop unless Halts() stops
>>>>> it at some point specifies infinite execution.
>>>>
>>>> Any algorithm that implements this truism is, of course, a halting
>>>> decider.
>>>
>>> You must be an atheist because a Christian knows the penalty for
>>> lying.
>>
>> You still won't answer my question will you?  Avoid, avoid, avoid!  You
>> quote me approvingly -- does that mean you have changed your mind and
>> you are now claiming to have an algorithm that decides halting (in
>> general)?  You have studiously avoided making that claim so far.
>>
>
> Whether or not I have an algorithm that correctly decides halting for
> all inputs is a dishonest dodge away from the point at hand.
>
> The point at hand is that when the above criteria is used by a partial
> halt decider to decide the conventional halting problem counter-examples
> then it does correctly decide that these counter-examples never halt.
>
>>>> This is, despite the absurdity, a serious question.  If I gave you a TM
>>>> and an input, how could you tell the difference between it simply
>>>> halting ("completing all of its steps") and being "forced to stop
>>>> running"?  If you can't do that (and I know you can't), you should be
>>>> able to show me two TM computations, one which just halts and one which
>>>> is forced to stop.
>>
>>> When any x86/TM machine...
>>
>> We are talking about TMs.  You probably don't know what your words games
>> mean anymore than I do which is why you avoided the question.  (Avoid,
>> avoid, avoid!)
>>
>
> I ignore dishonest dodges away from the point at hand.
>
>>>> And for anyone else, here's why you are wrong about your H in two
>>>> sentences.  The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
>>>> applied to ⟨Ĥ⟩.  Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
>>>> fact, accept it.
>>>
>>> That is a ridiculously foolish thing to say:
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>
>>> By accepting the ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does halt) the input
>>> never halts.
>>
>> By Jove, I think you've got it!!  If I can stomach using your
>> non-technical terms for once the converse also holds: By rejecting the
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ (indicating the input does not halt) the input halts.
>
>
>>>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the halting computation of Ĥ
>>>> applied to ⟨Ĥ⟩.  Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in
>>>> fact, accept it.
>
> Which causes it to never halts thus your:

WRONG. SINCE H INCORRECTLY rejects the string, the machine the string
represents does Halt.

>
>>>> Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should, in fact, accept it.
> Is very stupidly incorrect.
>
>> The only question is in which way your Ĥ (and thus your H) is wrong, and
>> you've told us enough times: it's wrong because it rejects ⟨Ĥ⟩ ⟨Ĥ⟩.  But
>> ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation precisely because H rejects ⟨Ĥ⟩
>> ⟨Ĥ⟩.
>>
>> But thanks (seriously) for pointing out my own bad wording.  You are not
>> wrong because H should accept the string ⟨Ĥ⟩ ⟨Ĥ⟩, you are wrong because
>> your H rejects it.  I'll try to be more careful in future.
>
> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
> instead of a simulating halt decider then we can see that Ĵ applied to
> ⟨Ĵ⟩ never halts. There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>
> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
> state of H.qn
>
> Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩
> ⟨Ĵ⟩ ?
>
>
>
>

Pages:12345678910111213141516171819
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor