Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

All constants are variables.


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?

<a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 16 Aug 2021 21:33:31 -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>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<iTCSI.65035$EF2.32920@fx47.iad>
<YPSdnaZYl6wunIb8nZ2dnUU7-VnNnZ2d@giganews.com>
<MSDSI.24014$6p.13563@fx36.iad>
<BqydnTi77c5Olob8nZ2dnUU7-TfNnZ2d@giganews.com>
<qdESI.53526$M14.34426@fx11.iad>
<N9OdnZVmheHKhob8nZ2dnUU7-RudnZ2d@giganews.com>
<s0FSI.19521$lK.19067@fx41.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 16 Aug 2021 21:33:30 -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: <s0FSI.19521$lK.19067@fx41.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@giganews.com>
Lines: 34
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-n9VbQjenVmhhehdccADr7zkJYHzY6EdBBY8rTsMF6ykHMsiELBngdbY/LsAWqKGvBMriRQ1aGuDrwIp!rHlUFLeD+HvYk3tiI+vskPJO3M6Va1u/YQMEkOI1cNunJW3fwvNHHB+sTt3Ftjfax+gZQBmaSwOk!wJc=
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: 3077
 by: olcott - Tue, 17 Aug 2021 02:33 UTC

On 8/16/2021 9:19 PM, Richard Damon wrote:
> On 8/16/21 10:13 PM, olcott wrote:
>> On 8/16/2021 8:24 PM, Richard Damon wrote:
>>>
>>> Please read the definitions again.
>>>
>>> A Pure simulator NEVER aborts its simulation.
>>
>> Like I said you probably have to reread what I say a few hundred more
>> times before you will understand it. I can no longer tolerate people
>> that continually glace at a few words before forming their rebuttal.
>>
>
> Ok, so you just admit that you aren't using the real definition.
>

If you reread it a few hundred more times you will see that I did not
use the term incorrectly.

> Please show ANY reliable reference that matches what you are saying.
>
> ANY.
>
> You logic is unsound
>
> YOU are UNSOUND.
>

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

<88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:622a:138c:: with SMTP id o12mr1509048qtk.346.1629178503747;
Mon, 16 Aug 2021 22:35:03 -0700 (PDT)
X-Received: by 2002:a25:bb8b:: with SMTP id y11mr2249155ybg.384.1629178503464;
Mon, 16 Aug 2021 22:35:03 -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, 16 Aug 2021 22:35:03 -0700 (PDT)
In-Reply-To: <NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=58.115.187.102; posting-account=QJ9iEwoAAACyjkKjQAWQOwSEULNvZZkc
NNTP-Posting-Host: 58.115.187.102
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com> <vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com> <kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com> <v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com> <BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com> <KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com> <NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com>
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
From: wyni...@gmail.com (wij)
Injection-Date: Tue, 17 Aug 2021 05:35:03 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: wij - Tue, 17 Aug 2021 05:35 UTC

On Tuesday, 17 August 2021 at 06:58:05 UTC+8, olcott wrote:
> On 8/16/2021 1:27 AM, wij wrote:
> > On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
> >> On 8/15/2021 9:45 AM, wij wrote:
> >>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
> >>>> On 8/15/2021 2:50 AM, wij wrote:
> >>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
> >>>>>> On 8/14/2021 1:09 PM, wij wrote:
> >>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
> >>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
> >>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
> >>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
> >>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
> >>>>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
> >>>>>>>>>>>> how it is called including this example:
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> P((u32)P);
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>> Because the halting problem only requires that the (at least partial)
> >>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
> >>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
> >>>>>>>>>>>> to the halting problem.
> >>>>>>>>>>>
> >>>>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
> >>>>>>>>>>> problem means a program H decides whether P(input) will halt or not.
> >>>>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
> >>>>>>>>>>> Submit message to the authors.
> >>>>>>>>>>>
> >>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
> >>>>>>>>>> only correctly decide the halt status of its input. Computations that
> >>>>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
> >>>>>>>>>
> >>>>>>>>> Obviously the quoted text means differently to you and almost all programmers in
> >>>>>>>>> the world. You are addressing your own interpretation. This is OK, but the
> >>>>>>>>> interpretation is meaningless.
> >>>>>>>> "the description of a Turing machine M" does not mean Turing machine M.
> >>>>>>>> If people interpret this to mean Turing machine M they are wrong..
> >>>>>>>
> >>>>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
> >>>>>>>
> >>>>>>> If both authors are also wrong, replying the rest message is meaningless.
> >>>>>>> You need to submit your interpretation to Linz and the author of the wiki.
> >>>>>>>
> >>>>>> I think that the problem is that your English is not so good.
> >>>>>> The Linz text and the Wiki text are correct.
> >>>>>> Linz retired many years ago.
> >>>>>
> >>>>> In your recent post somewhere, you said:
> >>>>> "I made my refutation of Linz a little more clear by changing all of the
> >>>>> subscripts to be numeric. My refutation of Linz cannot be properly
> >>>>> understood until after my refutation of simplified Linz / Strachey is
> >>>>> first understood..."
> >>>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
> >>>>>
> >>>> This text right here is correct:
> >>>> 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
> >>>> All of the rest of the text that "proves" the halting problem cannot be
> >>>> solved it incorrect.
> >>>
> >>> Which one did you mean:
> >>> 1. All of the rest of the text that "proves" the halting problem cannot be
> >>> solved incorrect. (still ambiguous)
> >>> 2. All of the rest of the text that "proves" the halting problem cannot
> >>> solve incorrect. (ambiguous)
> >>> 3. All of the rest of the text that "proves" the halting problem cannot be
> >>> solved, it is incorrect.
> >>>
> >>
> >> All of the rest of the text that "proves" the halting problem cannot be
> >> solved <IS> incorrect.
> >>>>> There are much more inconsistent statements in your posts, like "H is a total
> >>>>> function",...,etc. (I do not have time to re-find them).
> >>>>>
> >>>> H is a pure function of its inputs in that all of the nested simulations
> >>>> are simply data derived entirely on the basis of this inputs.
> >>>
> >>> From your description:
> >>> "The x86utm operating system uses a single contiguous block of RAM to
> >>> most precisely map to the concept of a single contiguous Turing machine
> >>> tape. All of the code and data of the virtual machines that it executes
> >>> are contained in this single contiguous block. There is no virtual
> >>> memory paging in the x86utm operating system."
> >>>
> >>> I believe your H is a 'pure function', you are actually dealing with two "C"
> >>> function calls. H is not really a simulator as you keeps calling it so.
> >>> Show me how H(P,P) takes its input P as 'simple data'.
> >>>
> >> The x86utm operating system is build from an x86 emulator capable of
> >> emulating all of the 80386 instructions using 4 GB of RAM.
> >
> > Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
> > Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
> > I do not believe you can build a machine or software capable of emulating ALL of
> > the 80386 instructions. Therefore, I assume all you have is a simulating
> > application.
> >
> >> The following x86utm operating system function calls the x86 emulator to
> >> emulate exactly one instruction of the slave process and then return to
> >> the calling process. It also decodes the slave instruction that was
> >> emulated so that it can be stored in the execution trace.
> >>
> >> u32 DebugStep(Registers* master_state,
> >> Registers* slave_state,
> >> Decoded_Line_Of_Code* decoded) {}
> >
> > The question how H(P,P) treats its argument P,P as data is still not answered.
> The details need not be specified to understand that all the simulations
> of the executed simulator are data belonging to the executed H. Details
> merely provide the means for endless digression away from the key point.
> > E.g. does H contain a call to DebugStep to decode P pointed byte string data?
> > Actually, there are many implementing problems for your simulator H and P to
> > be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
> > the simulation is not necessary for the proof.
> >
> The code does what it specifies that it does that alone is complete
> proof. We can know for sure that H does perform a pure simulation of P
> because the x86 code specified by P is exactly exactly as this code
> specifies.


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

<489d5771-694f-4934-b561-d27f5092c081n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:7f01:: with SMTP id f1mr2251888qtk.362.1629193253336;
Tue, 17 Aug 2021 02:40:53 -0700 (PDT)
X-Received: by 2002:a25:c752:: with SMTP id w79mr3462265ybe.348.1629193253181;
Tue, 17 Aug 2021 02:40:53 -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: Tue, 17 Aug 2021 02:40:52 -0700 (PDT)
In-Reply-To: <RImdnQbhabACk4b8nZ2dnUU7-emdnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:e87e:bd37:71a2:b4b;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:e87e:bd37:71a2:b4b
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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> <sXDSI.18813$wO4.1746@fx40.iad>
<RImdnQbhabACk4b8nZ2dnUU7-emdnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <489d5771-694f-4934-b561-d27f5092c081n@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: Tue, 17 Aug 2021 09:40:53 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Malcolm McLean - Tue, 17 Aug 2021 09:40 UTC

On Tuesday, 17 August 2021 at 02:19:34 UTC+1, olcott wrote:
>
> >
> > The question is what does P(P) do based on the definition of H that is
> > being used.
> >
> The question is whether or not the input to H halts and H answers this
> question correctly. That is all that is required by the halting problem.
>
Exactly. And H get the "pathological" Linz input wrong, as it must do.

But what exactly is going wrong? The "execution trace" might show what looks
like infinite recursion. But if H_Hat <H_Hat> halts, it can't really be infinite.
So there must either be something wrong with the execution trace, or there
must be something wrong with the way it is being interpreted.

Without actually seeing H, it hard to be sure, but based on your description of
how H works, it's possible to make an informed guess. This is that the "outer H"
detects what it thinks is infinite recursion and terminates, ignoring that fact
that the "inner H" would have terminated itself if run for a few more steps.

This has been explained many times now. The only way forward I can see is to
post a link to the source of H. Someone might have time to wade through it
and confirm exactly what is happening.

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

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

 copy mid

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

 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: Tue, 17 Aug 2021 11:09:21 +0100
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <87bl5wv0vi.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
<sXDSI.18813$wO4.1746@fx40.iad>
<RImdnQbhabACk4b8nZ2dnUU7-emdnZ2d@giganews.com>
<489d5771-694f-4934-b561-d27f5092c081n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="a7cea22e639917a9faf9270d06f26763";
logging-data="17104"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Z9QBH1sDrs+MuB32obC/xW0ZYPSIUIzc="
Cancel-Lock: sha1:CG/6JL9fDOe2u5RNGuwu2q5IvSY=
sha1:pz0Dxh3e0t4GXngVN00GkQZiBko=
X-BSB-Auth: 1.ad05640205a4bb787ceb.20210817110921BST.87bl5wv0vi.fsf@bsb.me.uk
 by: Ben Bacarisse - Tue, 17 Aug 2021 10:09 UTC

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Tuesday, 17 August 2021 at 02:19:34 UTC+1, olcott wrote:
>>
>> >
>> > The question is what does P(P) do based on the definition of H that is
>> > being used.
>> >
>> The question is whether or not the input to H halts and H answers this
>> question correctly. That is all that is required by the halting problem.
>>
> Exactly. And H get the "pathological" Linz input wrong, as it must do.

Why are you agreeing? PO is trying to say he's right because "the input
to H" is not the same as P(P). The fact that P(P) halts is, according
to PO's definition of halting, irrelevant. As it happens, there's no
reasonable interpretation of "the input to H" other than a
representation of P(P) but that's not going to stop PO using is as an
escape hatch.It's all part of his possibly deliberate confusion over
representations.

This is why he abandoned the threads about TMs. When using TMs, the
representation is explicit and he was stuck stating flat-out incorrect
things like his claim that a tape containing the pair <H^> <H^>
represents a non-halting computation. (I much prefer making the
encoding of a pair explicit in the notation because there is a subtle
point about self-delimiting representations, but he's stubbornly rejects
any such notation.)

Curiously, it makes no difference in the grand scheme of things because
rejecting the definition does not make it go away. There is no function
that does what *we* wants even if his H does what he wants. There are
still undecidable sets.

The trick he has to pull off (and he's tried a few times now) is to
change the definition and then say it's the same.

> This has been explained many times now. The only way forward I can see is to
> post a link to the source of H.

Never going to happen. PO does not want anyone to see what H is doing
because he knows it's silly.

--
Ben.

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

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

 copy mid

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

 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: Tue, 17 Aug 2021 11:23:11 +0100
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <875yw4v08g.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="a7cea22e639917a9faf9270d06f26763";
logging-data="17104"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Mv2hNNvriZ41eNLWCzXaJAPB4hy9nxsg="
Cancel-Lock: sha1:pGbhMOSlcv+2CiOciCOTVR/gSlc=
sha1:ToHSMDYvBeIGk32+BKvRzrVIB9M=
X-BSB-Auth: 1.63a42b67bf3d49f9a154.20210817112311BST.875yw4v08g.fsf@bsb.me.uk
 by: Ben Bacarisse - Tue, 17 Aug 2021 10:23 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>
>>>>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>>>>
>>>>> In other words your knowledge of infinite recursive invocation is on
>>>>> par with your knowledge of operating system context switching?
>>>> P(P) halts.
>>>>
>>>>>> Imagine if you'd been honest about this two and half years ago? "I have
>>>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>>>>> one would care.
>>>>>
>>>>> I finally have this one untangled:
>>>>> int main() { P(P); } is computationally equivalent to
>>>>> int main() { Simulate(P,P); }
>>>>>
>>>>> Because they are computationally equivalent they have the same halting
>>>>> behavior, however:
>>>>>
>>>>> Neither of them is computationally equivalent to the H(P,P) called
>>>>> from P because the different placement in the execution trace changes
>>>>> the halting behavior of P(P).
>>>>
>>>> H(M, I) is supposed to report the halting or otherwise of M(I). You
>>>> don't claim that your H can do this in all cases, but you boasted (you
>>>> like boasting) that it did for the "hat" version of H, AKA P above. It
>>>> does not. P(P) halts but H(P, P) == 0. Boring.
>>>
>>> That you don't bother to pay attention to the details or are unable to
>>> understand the x86 language well enough to understand the details in
>>> no way negates the fact that H(P,P) does correctly decide that its
>>> input never halts.
>> The details don't change whether H(P,P) is right or wrong. H(P,P)
>> should report the halting or otherwise of P(P). It's that simple.
>>
>
> int main() { H(P,P); } does correctly decide that its input never halts.
> Unless the H of main() aborts its simulation of P(P), this input never
> halts.

By insisting that H(P,P) == 0 is correct despite P(P) halting you are,
in effect, agreeing that you can't write a function B such that B(M, I)
is true, if and only if, M(I) halts. Your H won't do because you assure
us that P(P) halts and H(P, P) is false.

You can crow about H all you like, and you can stamp your feet and
*insist* that H(P,P) == 0 is correct, but there are a still uncomputable
functions. I just specified one -- B above.

If you want to take up this challenge, I can specify it more precisely,
but I advise you to ignore it.

--
Ben.

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

<a21d038a-044b-47a8-88d5-badf341cb52an@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ad4:58cc:: with SMTP id dh12mr2535275qvb.32.1629196061882; Tue, 17 Aug 2021 03:27:41 -0700 (PDT)
X-Received: by 2002:a25:becd:: with SMTP id k13mr3551067ybm.198.1629196061692; Tue, 17 Aug 2021 03:27:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Tue, 17 Aug 2021 03:27:41 -0700 (PDT)
In-Reply-To: <87bl5wv0vi.fsf@bsb.me.uk>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:1139:ac3e:66c4:d130; posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:1139:ac3e:66c4:d130
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk> <D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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> <sXDSI.18813$wO4.1746@fx40.iad> <RImdnQbhabACk4b8nZ2dnUU7-emdnZ2d@giganews.com> <489d5771-694f-4934-b561-d27f5092c081n@googlegroups.com> <87bl5wv0vi.fsf@bsb.me.uk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a21d038a-044b-47a8-88d5-badf341cb52an@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: Tue, 17 Aug 2021 10:27:41 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 19
 by: Malcolm McLean - Tue, 17 Aug 2021 10:27 UTC

On Tuesday, 17 August 2021 at 11:09:24 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Tuesday, 17 August 2021 at 02:19:34 UTC+1, olcott wrote:
> >>
> >> >
> >> > The question is what does P(P) do based on the definition of H that is
> >> > being used.
> >> >
> >> The question is whether or not the input to H halts and H answers this
> >> question correctly. That is all that is required by the halting problem.
> >>
> > Exactly. And H get the "pathological" Linz input wrong, as it must do.
> Why are you agreeing? PO is trying to say he's right because "the input
> to H" is not the same as P(P).
>
I forgot that. Yes, it's pedantically "The machine and input tape represented
by the input to H." But most people would accept "does the input to H halt?".
Unless someone is messing around trying to say that "The input doesn't
halt even if the machine does." Which seems to be what PO has said elsethread.

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

<ToMSI.25497$Thb4.14112@fx35.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.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?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<iTCSI.65035$EF2.32920@fx47.iad>
<YPSdnaZYl6wunIb8nZ2dnUU7-VnNnZ2d@giganews.com>
<MSDSI.24014$6p.13563@fx36.iad>
<BqydnTi77c5Olob8nZ2dnUU7-TfNnZ2d@giganews.com>
<qdESI.53526$M14.34426@fx11.iad>
<N9OdnZVmheHKhob8nZ2dnUU7-RudnZ2d@giganews.com>
<s0FSI.19521$lK.19067@fx41.iad>
<a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@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: <a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Lines: 57
Message-ID: <ToMSI.25497$Thb4.14112@fx35.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: Tue, 17 Aug 2021 06:42:59 -0400
X-Received-Bytes: 3388
 by: Richard Damon - Tue, 17 Aug 2021 10:42 UTC

On 8/16/21 10:33 PM, olcott wrote:
> On 8/16/2021 9:19 PM, Richard Damon wrote:
>> On 8/16/21 10:13 PM, olcott wrote:
>>> On 8/16/2021 8:24 PM, Richard Damon wrote:
>>>>
>>>> Please read the definitions again.
>>>>
>>>> A Pure simulator NEVER aborts its simulation.
>>>
>>> Like I said you probably have to reread what I say a few hundred more
>>> times before you will understand it. I can no longer tolerate people
>>> that continually glace at a few words before forming their rebuttal.
>>>
>>
>> Ok, so you just admit that you aren't using the real definition.
>>
>
> If you reread it a few hundred more times you will see that I did not
> use the term incorrectly.

Then please provide a reliable source that shows the term being used in
that manner.

FAIL.

A Pure simulator is one that its simulation exactly matches that of the
machine it is simulating.

That means that the pure simulation of a machine that has infinite
execution takes infinite time.

IF a 'pure until' machine aborts its simulation of an infinite execution
then it takes some finite time.

This is only the same if infinite execution is the same as finite
execution, which it isn't.

FAIL.

>
>> Please show ANY reliable reference that matches what you are saying.
>>
>> ANY.
>>
>> You logic is unsound
>>
>> YOU are UNSOUND.
>>

You have effectively proved mu point.

You seem to have NO idea what a proof is, or even what it means for
something to be true.

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

<2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@giganews.com>

 copy mid

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

 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!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: Tue, 17 Aug 2021 10:39:52 -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> <vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com> <75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com> <kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com> <ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com> <v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com> <d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com> <BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com> <407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com> <KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com> <06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com> <NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com> <iTCSI.65035$EF2.32920@fx47.iad> <YPSdnaZYl6wunIb8nZ2dnUU7-VnNnZ2d@giganews.com> <MSDSI.24014$6p.13563@fx36.iad> <BqydnTi77c5Olob8nZ2dnUU7-TfNnZ2d@giganews.com> <qdESI.53526$M14.34426@fx11.iad> <N9OdnZVmheHKhob8nZ2dnUU7-RudnZ2d@giganews.com> <s0FSI.19521$lK.19067@fx41.iad> <a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@giganews.com> <ToMSI.25497$Thb4.14112@fx35.iad>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 10:39:50 -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: <ToMSI.25497$Thb4.14112@fx35.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@giganews.com>
Lines: 88
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-EZbScXOU5PmGNwf8bZEulf6BJ2K2cWAKUQzKoMcnxmm65uI4B5XLLPdVjUs8blURLuCf0UxUB3rUw4j!ZmY2QWq2xLphDFoyHCadld5JGtaESLuBOYfMQDLkJYfAv8eSQZRCfK/N0av9vhCfuaVORtkDiGxM!kN4=
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: 4994
 by: olcott - Tue, 17 Aug 2021 15:39 UTC

On 8/17/2021 5:42 AM, Richard Damon wrote:
> On 8/16/21 10:33 PM, olcott wrote:
>> On 8/16/2021 9:19 PM, Richard Damon wrote:
>>> On 8/16/21 10:13 PM, olcott wrote:
>>>> On 8/16/2021 8:24 PM, Richard Damon wrote:
>>>>>
>>>>> Please read the definitions again.
>>>>>
>>>>> A Pure simulator NEVER aborts its simulation.
>>>>
>>>> Like I said you probably have to reread what I say a few hundred more
>>>> times before you will understand it. I can no longer tolerate people
>>>> that continually glace at a few words before forming their rebuttal.
>>>>
>>>
>>> Ok, so you just admit that you aren't using the real definition.
>>>
>>
>> If you reread it a few hundred more times you will see that I did not
>> use the term incorrectly.
>
> Then please provide a reliable source that shows the term being used in
> that manner.
>

It is self-evident that the term is being used correctly.

Your evaluation that the term is not being used correctly is entirely
based on the fact that you are simply skipping over and ignoring some of
the words that I said. If you are very careful to make sure that you
read and understand every single word then you will see that I am using
the term "simulation" correctly.

By making sure to erase the words that I said it would seem to be easier
to get away with intentional misinterpretation.

Intentional misinterpretation is a form of lying. The fact that you keep
erasing these words seems to be evidence that you are lying:

-Because H only acts as a pure simulator of its input until after its
-halt status decision has been made it has no behavior that can possibly
-effect the behavior of its input. Because of this H screens out its own
-address range in every execution trace that it examines. This is why we
-never see any instructions of H in any execution trace after an input
-calls H.

> FAIL.
>
> A Pure simulator is one that its simulation exactly matches that of the
> machine it is simulating.
>
> That means that the pure simulation of a machine that has infinite
> execution takes infinite time.
>
> IF a 'pure until' machine aborts its simulation of an infinite execution
> then it takes some finite time.
>
> This is only the same if infinite execution is the same as finite
> execution, which it isn't.
>
> FAIL.
>
>
>>
>>> Please show ANY reliable reference that matches what you are saying.
>>>
>>> ANY.
>>>
>>> You logic is unsound
>>>
>>> YOU are UNSOUND.
>>>
>
>
> You have effectively proved mu point.
>
> You seem to have NO idea what a proof is, or even what it means for
> something to be true.
>
>

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

<eNednfQicdjovoH8nZ2dnUU7-K2dnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc3.netnews.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 16:00:37 -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> <cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com> <vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com> <75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com> <kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com> <ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com> <v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com> <d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com> <BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com> <407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com> <KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com> <06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com> <NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com> <88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 16:00:35 -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: <88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <eNednfQicdjovoH8nZ2dnUU7-K2dnZ2d@giganews.com>
Lines: 483
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-o99QsvZJtNA8mKtO9O85R+0FEsey3xhki4saQaZ5mx1meQBAR/oDqAYYQYL8KmHRK+Qz7Lkoeiv2ASi!ob3V95I9KfiTSxT+rguGbm5vmqxngxIO9Cbb6BOZEVWKI8+FYir0yvlzo2JV1lBB+ZlXPzpDZTmA!Ym4=
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: 25625
 by: olcott - Tue, 17 Aug 2021 21:00 UTC

On 8/17/2021 12:35 AM, wij wrote:
> On Tuesday, 17 August 2021 at 06:58:05 UTC+8, olcott wrote:
>> On 8/16/2021 1:27 AM, wij wrote:
>>> On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
>>>> On 8/15/2021 9:45 AM, wij wrote:
>>>>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
>>>>>> On 8/15/2021 2:50 AM, wij wrote:
>>>>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
>>>>>>>> On 8/14/2021 1:09 PM, wij wrote:
>>>>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
>>>>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
>>>>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>>>>>>>>>>>> how it is called including this example:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> P((u32)P);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>>>>>>>>>> to the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
>>>>>>>>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
>>>>>>>>>>>>> Submit message to the authors.
>>>>>>>>>>>>>
>>>>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>>>>>>>>>> only correctly decide the halt status of its input. Computations that
>>>>>>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
>>>>>>>>>>>
>>>>>>>>>>> Obviously the quoted text means differently to you and almost all programmers in
>>>>>>>>>>> the world. You are addressing your own interpretation. This is OK, but the
>>>>>>>>>>> interpretation is meaningless.
>>>>>>>>>> "the description of a Turing machine M" does not mean Turing machine M.
>>>>>>>>>> If people interpret this to mean Turing machine M they are wrong.
>>>>>>>>>
>>>>>>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
>>>>>>>>>
>>>>>>>>> If both authors are also wrong, replying the rest message is meaningless.
>>>>>>>>> You need to submit your interpretation to Linz and the author of the wiki.
>>>>>>>>>
>>>>>>>> I think that the problem is that your English is not so good.
>>>>>>>> The Linz text and the Wiki text are correct.
>>>>>>>> Linz retired many years ago.
>>>>>>>
>>>>>>> In your recent post somewhere, you said:
>>>>>>> "I made my refutation of Linz a little more clear by changing all of the
>>>>>>> subscripts to be numeric. My refutation of Linz cannot be properly
>>>>>>> understood until after my refutation of simplified Linz / Strachey is
>>>>>>> first understood..."
>>>>>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
>>>>>>>
>>>>>> This text right here is correct:
>>>>>> 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
>>>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>>>> solved it incorrect.
>>>>>
>>>>> Which one did you mean:
>>>>> 1. All of the rest of the text that "proves" the halting problem cannot be
>>>>> solved incorrect. (still ambiguous)
>>>>> 2. All of the rest of the text that "proves" the halting problem cannot
>>>>> solve incorrect. (ambiguous)
>>>>> 3. All of the rest of the text that "proves" the halting problem cannot be
>>>>> solved, it is incorrect.
>>>>>
>>>>
>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>> solved <IS> incorrect.
>>>>>>> There are much more inconsistent statements in your posts, like "H is a total
>>>>>>> function",...,etc. (I do not have time to re-find them).
>>>>>>>
>>>>>> H is a pure function of its inputs in that all of the nested simulations
>>>>>> are simply data derived entirely on the basis of this inputs.
>>>>>
>>>>> From your description:
>>>>> "The x86utm operating system uses a single contiguous block of RAM to
>>>>> most precisely map to the concept of a single contiguous Turing machine
>>>>> tape. All of the code and data of the virtual machines that it executes
>>>>> are contained in this single contiguous block. There is no virtual
>>>>> memory paging in the x86utm operating system."
>>>>>
>>>>> I believe your H is a 'pure function', you are actually dealing with two "C"
>>>>> function calls. H is not really a simulator as you keeps calling it so.
>>>>> Show me how H(P,P) takes its input P as 'simple data'.
>>>>>
>>>> The x86utm operating system is build from an x86 emulator capable of
>>>> emulating all of the 80386 instructions using 4 GB of RAM.
>>>
>>> Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
>>> Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
>>> I do not believe you can build a machine or software capable of emulating ALL of
>>> the 80386 instructions. Therefore, I assume all you have is a simulating
>>> application.
>>>
>>>> The following x86utm operating system function calls the x86 emulator to
>>>> emulate exactly one instruction of the slave process and then return to
>>>> the calling process. It also decodes the slave instruction that was
>>>> emulated so that it can be stored in the execution trace.
>>>>
>>>> u32 DebugStep(Registers* master_state,
>>>> Registers* slave_state,
>>>> Decoded_Line_Of_Code* decoded) {}
>>>
>>> The question how H(P,P) treats its argument P,P as data is still not answered.
>> The details need not be specified to understand that all the simulations
>> of the executed simulator are data belonging to the executed H. Details
>> merely provide the means for endless digression away from the key point.
>>> E.g. does H contain a call to DebugStep to decode P pointed byte string data?
>>> Actually, there are many implementing problems for your simulator H and P to
>>> be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
>>> the simulation is not necessary for the proof.
>>>
>> The code does what it specifies that it does that alone is complete
>> proof. We can know for sure that H does perform a pure simulation of P
>> because the x86 code specified by P is exactly exactly as this code
>> specifies.
>
> What is the 'proof'? What is exactly the 'code'?
>
> 1. You are not capable of creating a "x86utm operating system".
> 2. You are not capable of understanding all 80386 instructions (no even 80186,80286).
> 3. You do not even understand C function and TM language properly.
> 4. You do not know logic.
> 5. You do not have a real H and P.
> 6. What you have are brainless talk and lies.
>
> Tell everyone, which one of the above is false.


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

<oKidneSwW_eMuIH8nZ2dnUU7-enNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 16:07: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
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk> <D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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> <sXDSI.18813$wO4.1746@fx40.iad> <RImdnQbhabACk4b8nZ2dnUU7-emdnZ2d@giganews.com> <489d5771-694f-4934-b561-d27f5092c081n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 16:07: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: <489d5771-694f-4934-b561-d27f5092c081n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <oKidneSwW_eMuIH8nZ2dnUU7-enNnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-iQM9lSSzS4FI4gKS2x4qp+xPgP7/t9sr2WkyCX67kUoAWVL6y7st63jg3pnKbCj17vcfVzvz+mdjyND!6wZGmcoNKR/GCREZseJO96N2jYSI31DluOXe18lLCRTiU0TPhBtHkvVTy53spqAH4qOGSgEG/NW2!mXw=
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: 5749
 by: olcott - Tue, 17 Aug 2021 21:07 UTC

On 8/17/2021 4:40 AM, Malcolm McLean wrote:
> On Tuesday, 17 August 2021 at 02:19:34 UTC+1, olcott wrote:
>>
>>>
>>> The question is what does P(P) do based on the definition of H that is
>>> being used.
>>>
>> The question is whether or not the input to H halts and H answers this
>> question correctly. That is all that is required by the halting problem.
>>
> Exactly. And H get the "pathological" Linz input wrong, as it must do.
>

You can only say this without lying if you make sure to not pay
attention to the proof that I provided. Making to to not pay attention
to the proof that IO provided is another form of deception.

[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The above conclusively proves that P will never stop running while H
remains in pure simulation mode, if you know the x86 language
sufficiently well then failing to acknowledge this is a sufficient
indication that you are not interested in an honest dialogue.

The above also proves that the input to H(P,P) never stops running
because the execution trace of the simulation of P is verified as
correct and specifies that it never stops running while H remains in
pure simulation mode and all inputs that never stop running while H is
in pure simulation mode are inputs that never halt (this is an axiom).

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

> But what exactly is going wrong? The "execution trace" might show what looks
> like infinite recursion. But if H_Hat <H_Hat> halts, it can't really be infinite.
> So there must either be something wrong with the execution trace, or there
> must be something wrong with the way it is being interpreted.
>
> Without actually seeing H, it hard to be sure, but based on your description of
> how H works, it's possible to make an informed guess. This is that the "outer H"
> detects what it thinks is infinite recursion and terminates, ignoring that fact
> that the "inner H" would have terminated itself if run for a few more steps.
>
> This has been explained many times now. The only way forward I can see is to
> post a link to the source of H. Someone might have time to wade through it
> and confirm exactly what is happening.
>

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

<oKidneewW_e6u4H8nZ2dnUU7-emdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 16:12:07 -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>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
<sXDSI.18813$wO4.1746@fx40.iad>
<RImdnQbhabACk4b8nZ2dnUU7-emdnZ2d@giganews.com>
<489d5771-694f-4934-b561-d27f5092c081n@googlegroups.com>
<87bl5wv0vi.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 16:12:06 -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: <87bl5wv0vi.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <oKidneewW_e6u4H8nZ2dnUU7-emdnZ2d@giganews.com>
Lines: 81
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-pu9h328HIOtwMm+ez+ql77GRZHSxAuPehq8C2FO5pc7qvIVqOwgoVEQfDC/050fma4iiP3q68vedrF/!0XPuw3khoq/a5Q1CMNtsRPP9rIw7GKgjE4NaB/x/4D9HmGoey62oFfd25IPbakTlTd7EMFgp6nbx!ppc=
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: 5525
 by: olcott - Tue, 17 Aug 2021 21:12 UTC

On 8/17/2021 5:09 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Tuesday, 17 August 2021 at 02:19:34 UTC+1, olcott wrote:
>>>
>>>>
>>>> The question is what does P(P) do based on the definition of H that is
>>>> being used.
>>>>
>>> The question is whether or not the input to H halts and H answers this
>>> question correctly. That is all that is required by the halting problem.
>>>
>> Exactly. And H get the "pathological" Linz input wrong, as it must do.
>
> Why are you agreeing? PO is trying to say he's right because "the input
> to H" is not the same as P(P). The fact that P(P) halts is, according
> to PO's definition of halting, irrelevant. As it happens, there's no
> reasonable interpretation of "the input to H" other than a
> representation of P(P) but that's not going to stop PO using is as an
> escape hatch.It's all part of his possibly deliberate confusion over
> representations.
>
> This is why he abandoned the threads about TMs. When using TMs, the
> representation is explicit and he was stuck stating flat-out incorrect
> things like his claim that a tape containing the pair <H^> <H^>
> represents a non-halting computation. (I much prefer making the
> encoding of a pair explicit in the notation because there is a subtle
> point about self-delimiting representations, but he's stubbornly rejects
> any such notation.)
>
> Curiously, it makes no difference in the grand scheme of things because
> rejecting the definition does not make it go away. There is no function
> that does what *we* wants even if his H does what he wants. There are
> still undecidable sets.
>
> The trick he has to pull off (and he's tried a few times now) is to
> change the definition and then say it's the same.
>
>> This has been explained many times now. The only way forward I can see is to
>> post a link to the source of H.
>
> Never going to happen. PO does not want anyone to see what H is doing
> because he knows it's silly.
>

You apparently don't know the x86 language well enough to properly
critique my claims. The following proves my point and if you rebut it
knowing that you don't understand what I am saying this would be an act
of overt dishonesty.

[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The above conclusively proves that P will never stop running while H
remains in pure simulation mode.

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

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

<oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 16:14:51 -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>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 16:14:49 -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: <875yw4v08g.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
Lines: 116
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-2HJObU1KzXIz656HTUzaetQMd+3eOsYaSVaha4HsXmoZNbGEPvEDlMAB25vjSgAGpzlhxLba2vwGSpN!PXSnbLxe6/h4im5arH6XRNQc3MSFcVU+UtlpNsnrFTkWEZq0T51+6kK59hRaNWWY752+oZMtlitX!FCE=
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: 6676
 by: olcott - Tue, 17 Aug 2021 21:14 UTC

On 8/17/2021 5:23 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>>
>>>>>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>>>>>
>>>>>> In other words your knowledge of infinite recursive invocation is on
>>>>>> par with your knowledge of operating system context switching?
>>>>> P(P) halts.
>>>>>
>>>>>>> Imagine if you'd been honest about this two and half years ago? "I have
>>>>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>>>>>> one would care.
>>>>>>
>>>>>> I finally have this one untangled:
>>>>>> int main() { P(P); } is computationally equivalent to
>>>>>> int main() { Simulate(P,P); }
>>>>>>
>>>>>> Because they are computationally equivalent they have the same halting
>>>>>> behavior, however:
>>>>>>
>>>>>> Neither of them is computationally equivalent to the H(P,P) called
>>>>>> from P because the different placement in the execution trace changes
>>>>>> the halting behavior of P(P).
>>>>>
>>>>> H(M, I) is supposed to report the halting or otherwise of M(I). You
>>>>> don't claim that your H can do this in all cases, but you boasted (you
>>>>> like boasting) that it did for the "hat" version of H, AKA P above. It
>>>>> does not. P(P) halts but H(P, P) == 0. Boring.
>>>>
>>>> That you don't bother to pay attention to the details or are unable to
>>>> understand the x86 language well enough to understand the details in
>>>> no way negates the fact that H(P,P) does correctly decide that its
>>>> input never halts.
>>> The details don't change whether H(P,P) is right or wrong. H(P,P)
>>> should report the halting or otherwise of P(P). It's that simple.
>>>
>>
>> int main() { H(P,P); } does correctly decide that its input never halts.
>> Unless the H of main() aborts its simulation of P(P), this input never
>> halts.
>
> By insisting that H(P,P) == 0 is correct despite P(P) halting you are,
> in effect, agreeing that

There is a key paradox that no one besides me is bothering to examine
because everyone here is too damn sure of their own damn opinion to give
my work a fair and accurate evaluation.

[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The above conclusively proves that P will never stop running while H
remains in pure simulation mode, if you know the x86 language
sufficiently well then failing to acknowledge this is a sufficient
indication that you are not interested in an honest dialogue.

The above also proves that the input to H(P,P) never stops running
because the execution trace of the simulation of P is verified as
correct and specifies that it never stops running while H remains in
pure simulation mode and all inputs that never stop running while H is
in pure simulation mode are inputs that never halt (this is an axiom).

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

> you can't write a function B such that B(M, I)
> is true, if and only if, M(I) halts. Your H won't do because you assure
> us that P(P) halts and H(P, P) is false.
>
> You can crow about H all you like, and you can stamp your feet and
> *insist* that H(P,P) == 0 is correct, but there are a still uncomputable
> functions. I just specified one -- B above.
>
> If you want to take up this challenge, I can specify it more precisely,
> but I advise you to ignore it.
>

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

<oKidneGwW_f2uoH8nZ2dnUU7-emdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 16:17:31 -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>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
<sXDSI.18813$wO4.1746@fx40.iad>
<RImdnQbhabACk4b8nZ2dnUU7-emdnZ2d@giganews.com>
<489d5771-694f-4934-b561-d27f5092c081n@googlegroups.com>
<87bl5wv0vi.fsf@bsb.me.uk>
<a21d038a-044b-47a8-88d5-badf341cb52an@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 16:17:29 -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: <a21d038a-044b-47a8-88d5-badf341cb52an@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <oKidneGwW_f2uoH8nZ2dnUU7-emdnZ2d@giganews.com>
Lines: 79
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-mIdvpLg1qKnU2w7uTncDiexfCPurlvRXqZDUx5wx+/pG5Amxf0qOcOAABGJ9PP5xfDWa8PI5u5O7Fqh!1JDWCEoyCmtBf9sTKVT4T7rfaf/XByxWonruowKlGd6HpxR1I5nFOWLCHJUZD5ckl9w80qdvGbPr!u7c=
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: 5481
 by: olcott - Tue, 17 Aug 2021 21:17 UTC

On 8/17/2021 5:27 AM, Malcolm McLean wrote:
> On Tuesday, 17 August 2021 at 11:09:24 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Tuesday, 17 August 2021 at 02:19:34 UTC+1, olcott wrote:
>>>>
>>>>>
>>>>> The question is what does P(P) do based on the definition of H that is
>>>>> being used.
>>>>>
>>>> The question is whether or not the input to H halts and H answers this
>>>> question correctly. That is all that is required by the halting problem.
>>>>
>>> Exactly. And H get the "pathological" Linz input wrong, as it must do.
>> Why are you agreeing? PO is trying to say he's right because "the input
>> to H" is not the same as P(P).
>>
> I forgot that. Yes, it's pedantically "The machine and input tape represented
> by the input to H." But most people would accept "does the input to H halt?".
> Unless someone is messing around trying to say that "The input doesn't
> halt even if the machine does." Which seems to be what PO has said elsethread.
>

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The above conclusively proves that P will never stop running while H
remains in pure simulation mode, if you know the x86 language
sufficiently well then failing to acknowledge this is a sufficient
indication that you are not interested in an honest dialogue.

The above also proves that the input to H(P,P) never stops running
because the execution trace of the simulation of P is verified as
correct and specifies that it never stops running while H remains in
pure simulation mode and all inputs that never stop running while H is
in pure simulation mode are inputs that never halt (this is an axiom).

all inputs that never stop running while H is in pure simulation mode
are inputs that never halt (this is an axiom).

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

<8735r7u3ab.fsf@bsb.me.uk>

 copy mid

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

 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: Tue, 17 Aug 2021 23:14:52 +0100
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <8735r7u3ab.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="e21ab49ec019735fe1837fbff80e73bc";
logging-data="23306"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+c3CrUWKkQArkr6iIc1WKy6vNIZzw7I/c="
Cancel-Lock: sha1:vj5eaCt1e5+r6ONpnNzEKQMFVGE=
sha1:/WJPjuX6PRsQ+4nM3Xg4/6/XFIc=
X-BSB-Auth: 1.4f8ab585312ea7b48e80.20210817231452BST.8735r7u3ab.fsf@bsb.me.uk
 by: Ben Bacarisse - Tue, 17 Aug 2021 22:14 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/17/2021 5:23 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>>>>>>
>>>>>>> In other words your knowledge of infinite recursive invocation is on
>>>>>>> par with your knowledge of operating system context switching?
>>>>>> P(P) halts.
>>>>>>
>>>>>>>> Imagine if you'd been honest about this two and half years ago? "I have
>>>>>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>>>>>>> one would care.
>>>>>>>
>>>>>>> I finally have this one untangled:
>>>>>>> int main() { P(P); } is computationally equivalent to
>>>>>>> int main() { Simulate(P,P); }
>>>>>>>
>>>>>>> Because they are computationally equivalent they have the same halting
>>>>>>> behavior, however:
>>>>>>>
>>>>>>> Neither of them is computationally equivalent to the H(P,P) called
>>>>>>> from P because the different placement in the execution trace changes
>>>>>>> the halting behavior of P(P).
>>>>>>
>>>>>> H(M, I) is supposed to report the halting or otherwise of M(I). You
>>>>>> don't claim that your H can do this in all cases, but you boasted (you
>>>>>> like boasting) that it did for the "hat" version of H, AKA P above. It
>>>>>> does not. P(P) halts but H(P, P) == 0. Boring.
>>>>>
>>>>> That you don't bother to pay attention to the details or are unable to
>>>>> understand the x86 language well enough to understand the details in
>>>>> no way negates the fact that H(P,P) does correctly decide that its
>>>>> input never halts.
>>>> The details don't change whether H(P,P) is right or wrong. H(P,P)
>>>> should report the halting or otherwise of P(P). It's that simple.
>>>>
>>>
>>> int main() { H(P,P); } does correctly decide that its input never halts.
>>> Unless the H of main() aborts its simulation of P(P), this input never
>>> halts.
>>
>> By insisting that H(P,P) == 0 is correct despite P(P) halting you
>>are, in effect, agreeing that
>
> There is a key paradox that no one besides me is bothering to examine
> because everyone here is too damn sure of their own damn opinion to
> give my work a fair and accurate evaluation.

The facts come from you. They are not a matter of opinion. P(P) halts.
H(P,P) == 0.

You are happy with that answer, but I can specify a function you can't
write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
You don't get to choose what the "correct" answer is, so your only
option if to ignore the challenge.

>> you can't write a function B such that B(M, I)
>> is true, if and only if, M(I) halts. Your H won't do because you assure
>> us that P(P) halts and H(P, P) is false.
>> You can crow about H all you like, and you can stamp your feet and
>> *insist* that H(P,P) == 0 is correct, but there are a still uncomputable
>> functions. I just specified one -- B above.
>> If you want to take up this challenge, I can specify it more precisely,
>> but I advise you to ignore it.

As expected.

--
Ben.

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

<91782879-aa4b-4db8-a5fc-327dbfd3b9c9n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a37:7141:: with SMTP id m62mr6416166qkc.496.1629241279524;
Tue, 17 Aug 2021 16:01:19 -0700 (PDT)
X-Received: by 2002:a25:becd:: with SMTP id k13mr7547739ybm.198.1629241279281;
Tue, 17 Aug 2021 16:01:19 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Tue, 17 Aug 2021 16:01:19 -0700 (PDT)
In-Reply-To: <eNednfQicdjovoH8nZ2dnUU7-K2dnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=58.115.187.102; posting-account=QJ9iEwoAAACyjkKjQAWQOwSEULNvZZkc
NNTP-Posting-Host: 58.115.187.102
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com> <vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com> <kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com> <v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com> <BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com> <KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com> <NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com> <eNednfQicdjovoH8nZ2dnUU7-K2dnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <91782879-aa4b-4db8-a5fc-327dbfd3b9c9n@googlegroups.com>
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
From: wyni...@gmail.com (wij)
Injection-Date: Tue, 17 Aug 2021 23:01:19 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 250
 by: wij - Tue, 17 Aug 2021 23:01 UTC

On Wednesday, 18 August 2021 at 05:00:44 UTC+8, olcott wrote:
> On 8/17/2021 12:35 AM, wij wrote:
> > On Tuesday, 17 August 2021 at 06:58:05 UTC+8, olcott wrote:
> >> On 8/16/2021 1:27 AM, wij wrote:
> >>> On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
> >>>> On 8/15/2021 9:45 AM, wij wrote:
> >>>>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
> >>>>>> On 8/15/2021 2:50 AM, wij wrote:
> >>>>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
> >>>>>>>> On 8/14/2021 1:09 PM, wij wrote:
> >>>>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
> >>>>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
> >>>>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
> >>>>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
> >>>>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
> >>>>>>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
> >>>>>>>>>>>>>> how it is called including this example:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> P((u32)P);
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Because the halting problem only requires that the (at least partial)
> >>>>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
> >>>>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
> >>>>>>>>>>>>>> to the halting problem.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
> >>>>>>>>>>>>> problem means a program H decides whether P(input) will halt or not.
> >>>>>>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
> >>>>>>>>>>>>> Submit message to the authors.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
> >>>>>>>>>>>> only correctly decide the halt status of its input. Computations that
> >>>>>>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
> >>>>>>>>>>>
> >>>>>>>>>>> Obviously the quoted text means differently to you and almost all programmers in
> >>>>>>>>>>> the world. You are addressing your own interpretation. This is OK, but the
> >>>>>>>>>>> interpretation is meaningless.
> >>>>>>>>>> "the description of a Turing machine M" does not mean Turing machine M.
> >>>>>>>>>> If people interpret this to mean Turing machine M they are wrong.
> >>>>>>>>>
> >>>>>>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
> >>>>>>>>>
> >>>>>>>>> If both authors are also wrong, replying the rest message is meaningless.
> >>>>>>>>> You need to submit your interpretation to Linz and the author of the wiki.
> >>>>>>>>>
> >>>>>>>> I think that the problem is that your English is not so good.
> >>>>>>>> The Linz text and the Wiki text are correct.
> >>>>>>>> Linz retired many years ago.
> >>>>>>>
> >>>>>>> In your recent post somewhere, you said:
> >>>>>>> "I made my refutation of Linz a little more clear by changing all of the
> >>>>>>> subscripts to be numeric. My refutation of Linz cannot be properly
> >>>>>>> understood until after my refutation of simplified Linz / Strachey is
> >>>>>>> first understood..."
> >>>>>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
> >>>>>>>
> >>>>>> This text right here is correct:
> >>>>>> 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
> >>>>>> All of the rest of the text that "proves" the halting problem cannot be
> >>>>>> solved it incorrect.
> >>>>>
> >>>>> Which one did you mean:
> >>>>> 1. All of the rest of the text that "proves" the halting problem cannot be
> >>>>> solved incorrect. (still ambiguous)
> >>>>> 2. All of the rest of the text that "proves" the halting problem cannot
> >>>>> solve incorrect. (ambiguous)
> >>>>> 3. All of the rest of the text that "proves" the halting problem cannot be
> >>>>> solved, it is incorrect.
> >>>>>
> >>>>
> >>>> All of the rest of the text that "proves" the halting problem cannot be
> >>>> solved <IS> incorrect.
> >>>>>>> There are much more inconsistent statements in your posts, like "H is a total
> >>>>>>> function",...,etc. (I do not have time to re-find them).
> >>>>>>>
> >>>>>> H is a pure function of its inputs in that all of the nested simulations
> >>>>>> are simply data derived entirely on the basis of this inputs.
> >>>>>
> >>>>> From your description:
> >>>>> "The x86utm operating system uses a single contiguous block of RAM to
> >>>>> most precisely map to the concept of a single contiguous Turing machine
> >>>>> tape. All of the code and data of the virtual machines that it executes
> >>>>> are contained in this single contiguous block. There is no virtual
> >>>>> memory paging in the x86utm operating system."
> >>>>>
> >>>>> I believe your H is a 'pure function', you are actually dealing with two "C"
> >>>>> function calls. H is not really a simulator as you keeps calling it so.
> >>>>> Show me how H(P,P) takes its input P as 'simple data'.
> >>>>>
> >>>> The x86utm operating system is build from an x86 emulator capable of
> >>>> emulating all of the 80386 instructions using 4 GB of RAM.
> >>>
> >>> Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
> >>> Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
> >>> I do not believe you can build a machine or software capable of emulating ALL of
> >>> the 80386 instructions. Therefore, I assume all you have is a simulating
> >>> application.
> >>>
> >>>> The following x86utm operating system function calls the x86 emulator to
> >>>> emulate exactly one instruction of the slave process and then return to
> >>>> the calling process. It also decodes the slave instruction that was
> >>>> emulated so that it can be stored in the execution trace.
> >>>>
> >>>> u32 DebugStep(Registers* master_state,
> >>>> Registers* slave_state,
> >>>> Decoded_Line_Of_Code* decoded) {}
> >>>
> >>> The question how H(P,P) treats its argument P,P as data is still not answered.
> >> The details need not be specified to understand that all the simulations
> >> of the executed simulator are data belonging to the executed H. Details
> >> merely provide the means for endless digression away from the key point.
> >>> E.g. does H contain a call to DebugStep to decode P pointed byte string data?
> >>> Actually, there are many implementing problems for your simulator H and P to
> >>> be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
> >>> the simulation is not necessary for the proof.
> >>>
> >> The code does what it specifies that it does that alone is complete
> >> proof. We can know for sure that H does perform a pure simulation of P
> >> because the x86 code specified by P is exactly exactly as this code
> >> specifies.
> >
> > What is the 'proof'? What is exactly the 'code'?
> >
> > 1. You are not capable of creating a "x86utm operating system".
> > 2. You are not capable of understanding all 80386 instructions (no even 80186,80286).
> > 3. You do not even understand C function and TM language properly.
> > 4. You do not know logic.
> > 5. You do not have a real H and P.
> > 6. What you have are brainless talk and lies.
> >
> > Tell everyone, which one of the above is false.
> I take the above as your indication that you intend to only act like a
> troll and thing else..


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

<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 18:04:50 -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>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 18:04:48 -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: <8735r7u3ab.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
Lines: 115
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Y9se2d/rR805j7wnNfDKMTA5xMszmYlJR3heFXg6BPnw5zU95RzJn1oFoZfTTyxPHQCuz10JpYEPllY!Vpj8CPmDXeoJ/01WVjJiCH5vS6+vjsX8mWgxDu7J9MMmvj0NK9aJ9AhuqLCKhjCF4to//myNsjrw!MO0=
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: 6592
 by: olcott - Tue, 17 Aug 2021 23:04 UTC

On 8/17/2021 5:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/17/2021 5:23 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>>>>>>>
>>>>>>>> In other words your knowledge of infinite recursive invocation is on
>>>>>>>> par with your knowledge of operating system context switching?
>>>>>>> P(P) halts.
>>>>>>>
>>>>>>>>> Imagine if you'd been honest about this two and half years ago? "I have
>>>>>>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>>>>>>>> one would care.
>>>>>>>>
>>>>>>>> I finally have this one untangled:
>>>>>>>> int main() { P(P); } is computationally equivalent to
>>>>>>>> int main() { Simulate(P,P); }
>>>>>>>>
>>>>>>>> Because they are computationally equivalent they have the same halting
>>>>>>>> behavior, however:
>>>>>>>>
>>>>>>>> Neither of them is computationally equivalent to the H(P,P) called
>>>>>>>> from P because the different placement in the execution trace changes
>>>>>>>> the halting behavior of P(P).
>>>>>>>
>>>>>>> H(M, I) is supposed to report the halting or otherwise of M(I). You
>>>>>>> don't claim that your H can do this in all cases, but you boasted (you
>>>>>>> like boasting) that it did for the "hat" version of H, AKA P above. It
>>>>>>> does not. P(P) halts but H(P, P) == 0. Boring.
>>>>>>
>>>>>> That you don't bother to pay attention to the details or are unable to
>>>>>> understand the x86 language well enough to understand the details in
>>>>>> no way negates the fact that H(P,P) does correctly decide that its
>>>>>> input never halts.
>>>>> The details don't change whether H(P,P) is right or wrong. H(P,P)
>>>>> should report the halting or otherwise of P(P). It's that simple.
>>>>>
>>>>
>>>> int main() { H(P,P); } does correctly decide that its input never halts.
>>>> Unless the H of main() aborts its simulation of P(P), this input never
>>>> halts.
>>>
>>> By insisting that H(P,P) == 0 is correct despite P(P) halting you
>>> are, in effect, agreeing that
>>
>> There is a key paradox that no one besides me is bothering to examine
>> because everyone here is too damn sure of their own damn opinion to
>> give my work a fair and accurate evaluation.
>
> The facts come from you. They are not a matter of opinion. P(P) halts.
> H(P,P) == 0.
>

Which appears to be a direct contradiction proving that H is wrong until
you carefully examine the basis that H uses for its halt status decision
and directly see that this basis is correct thus the decision must be
correct.

Either no one wants to be bothered by looking at this after their mind
is already made up or they don't understand the x86 language well enough
to verify that H does correctly decide that its input never halts. In
the long run this won't matter because I will resolve the paradox too.

> You are happy with that answer, but I can specify a function you can't
> write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
> You don't get to choose what the "correct" answer is, so your only
> option if to ignore the challenge.
>

At this point I expect and require that those seeking an actual honest
dialogue use the basis that I provided to verify that H does decide the
halt status of its inputs correctly. Everyone else is written off as
dishonest.

If H(P,P) really did decide its input incorrectly then there must be
some flaw in the basis that it uses. If there is no flaw in the basis
that it uses then H(P,P) does decide its input correctly. That people do
not want to even discuss the basis that H uses sufficiently proves that
they are not honest.

>>> you can't write a function B such that B(M, I)
>>> is true, if and only if, M(I) halts. Your H won't do because you assure
>>> us that P(P) halts and H(P, P) is false.
>>> You can crow about H all you like, and you can stamp your feet and
>>> *insist* that H(P,P) == 0 is correct, but there are a still uncomputable
>>> functions. I just specified one -- B above.
>>> If you want to take up this challenge, I can specify it more precisely,
>>> but I advise you to ignore it.
>
> As expected.
>

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

<w9WdnXCnjMoi3IH8nZ2dnUU7-YfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 18:09:51 -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>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com>
<eNednfQicdjovoH8nZ2dnUU7-K2dnZ2d@giganews.com>
<91782879-aa4b-4db8-a5fc-327dbfd3b9c9n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 18:09:49 -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: <91782879-aa4b-4db8-a5fc-327dbfd3b9c9n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <w9WdnXCnjMoi3IH8nZ2dnUU7-YfNnZ2d@giganews.com>
Lines: 202
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-L6tkadvtPnnBgV52LWjxq5g+1jZmiGvt1RJgvrZd9XejUqRWNWfJ4RN5yfLfSbERKujue9L5ewAUZa5!ifL47DzMDTmIf4kYHzPaWD4v1S85paKqiDrHHNFZvC/8mkhUx/gAv9VTvhPLAWca+QPOawuj2CKv!Bek=
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: 12732
 by: olcott - Tue, 17 Aug 2021 23:09 UTC

On 8/17/2021 6:01 PM, wij wrote:
> On Wednesday, 18 August 2021 at 05:00:44 UTC+8, olcott wrote:
>> On 8/17/2021 12:35 AM, wij wrote:
>>> On Tuesday, 17 August 2021 at 06:58:05 UTC+8, olcott wrote:
>>>> On 8/16/2021 1:27 AM, wij wrote:
>>>>> On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
>>>>>> On 8/15/2021 9:45 AM, wij wrote:
>>>>>>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
>>>>>>>> On 8/15/2021 2:50 AM, wij wrote:
>>>>>>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
>>>>>>>>>> On 8/14/2021 1:09 PM, wij wrote:
>>>>>>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
>>>>>>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
>>>>>>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>>>>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>>>>>>>>>>>>>> how it is called including this example:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> P((u32)P);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>>>>>>>>>>>> to the halting problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
>>>>>>>>>>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>>>>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
>>>>>>>>>>>>>>> Submit message to the authors.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>>>>>>>>>>>> only correctly decide the halt status of its input. Computations that
>>>>>>>>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously the quoted text means differently to you and almost all programmers in
>>>>>>>>>>>>> the world. You are addressing your own interpretation. This is OK, but the
>>>>>>>>>>>>> interpretation is meaningless.
>>>>>>>>>>>> "the description of a Turing machine M" does not mean Turing machine M.
>>>>>>>>>>>> If people interpret this to mean Turing machine M they are wrong.
>>>>>>>>>>>
>>>>>>>>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
>>>>>>>>>>>
>>>>>>>>>>> If both authors are also wrong, replying the rest message is meaningless.
>>>>>>>>>>> You need to submit your interpretation to Linz and the author of the wiki.
>>>>>>>>>>>
>>>>>>>>>> I think that the problem is that your English is not so good.
>>>>>>>>>> The Linz text and the Wiki text are correct.
>>>>>>>>>> Linz retired many years ago.
>>>>>>>>>
>>>>>>>>> In your recent post somewhere, you said:
>>>>>>>>> "I made my refutation of Linz a little more clear by changing all of the
>>>>>>>>> subscripts to be numeric. My refutation of Linz cannot be properly
>>>>>>>>> understood until after my refutation of simplified Linz / Strachey is
>>>>>>>>> first understood..."
>>>>>>>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
>>>>>>>>>
>>>>>>>> This text right here is correct:
>>>>>>>> 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
>>>>>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>>>>>> solved it incorrect.
>>>>>>>
>>>>>>> Which one did you mean:
>>>>>>> 1. All of the rest of the text that "proves" the halting problem cannot be
>>>>>>> solved incorrect. (still ambiguous)
>>>>>>> 2. All of the rest of the text that "proves" the halting problem cannot
>>>>>>> solve incorrect. (ambiguous)
>>>>>>> 3. All of the rest of the text that "proves" the halting problem cannot be
>>>>>>> solved, it is incorrect.
>>>>>>>
>>>>>>
>>>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>>>> solved <IS> incorrect.
>>>>>>>>> There are much more inconsistent statements in your posts, like "H is a total
>>>>>>>>> function",...,etc. (I do not have time to re-find them).
>>>>>>>>>
>>>>>>>> H is a pure function of its inputs in that all of the nested simulations
>>>>>>>> are simply data derived entirely on the basis of this inputs.
>>>>>>>
>>>>>>> From your description:
>>>>>>> "The x86utm operating system uses a single contiguous block of RAM to
>>>>>>> most precisely map to the concept of a single contiguous Turing machine
>>>>>>> tape. All of the code and data of the virtual machines that it executes
>>>>>>> are contained in this single contiguous block. There is no virtual
>>>>>>> memory paging in the x86utm operating system."
>>>>>>>
>>>>>>> I believe your H is a 'pure function', you are actually dealing with two "C"
>>>>>>> function calls. H is not really a simulator as you keeps calling it so.
>>>>>>> Show me how H(P,P) takes its input P as 'simple data'.
>>>>>>>
>>>>>> The x86utm operating system is build from an x86 emulator capable of
>>>>>> emulating all of the 80386 instructions using 4 GB of RAM.
>>>>>
>>>>> Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
>>>>> Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
>>>>> I do not believe you can build a machine or software capable of emulating ALL of
>>>>> the 80386 instructions. Therefore, I assume all you have is a simulating
>>>>> application.
>>>>>
>>>>>> The following x86utm operating system function calls the x86 emulator to
>>>>>> emulate exactly one instruction of the slave process and then return to
>>>>>> the calling process. It also decodes the slave instruction that was
>>>>>> emulated so that it can be stored in the execution trace.
>>>>>>
>>>>>> u32 DebugStep(Registers* master_state,
>>>>>> Registers* slave_state,
>>>>>> Decoded_Line_Of_Code* decoded) {}
>>>>>
>>>>> The question how H(P,P) treats its argument P,P as data is still not answered.
>>>> The details need not be specified to understand that all the simulations
>>>> of the executed simulator are data belonging to the executed H. Details
>>>> merely provide the means for endless digression away from the key point.
>>>>> E.g. does H contain a call to DebugStep to decode P pointed byte string data?
>>>>> Actually, there are many implementing problems for your simulator H and P to
>>>>> be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
>>>>> the simulation is not necessary for the proof.
>>>>>
>>>> The code does what it specifies that it does that alone is complete
>>>> proof. We can know for sure that H does perform a pure simulation of P
>>>> because the x86 code specified by P is exactly exactly as this code
>>>> specifies.
>>>
>>> What is the 'proof'? What is exactly the 'code'?
>>>
>>> 1. You are not capable of creating a "x86utm operating system".
>>> 2. You are not capable of understanding all 80386 instructions (no even 80186,80286).
>>> 3. You do not even understand C function and TM language properly.
>>> 4. You do not know logic.
>>> 5. You do not have a real H and P.
>>> 6. What you have are brainless talk and lies.
>>>
>>> Tell everyone, which one of the above is false.
>> I take the above as your indication that you intend to only act like a
>> troll and thing else..
>
> I intended to point you to the true thing that you keep blocking yourself.
> So, I put them again in more suspicious/polite way. One reason is that you are
> too cunning in argument.
>
> 1. Did you actually created a "x86utm operating system"? An OS means the software
>  BIOS passes to immediately after power on.


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

<sfhg3i$1l3g$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!ux6ld97kLXxG8kVFFLnoWg.user.46.165.242.75.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Tue, 17 Aug 2021 16:18:10 -0700
Organization: Aioe.org NNTP Server
Message-ID: <sfhg3i$1l3g$1@gioia.aioe.org>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com>
<eNednfQicdjovoH8nZ2dnUU7-K2dnZ2d@giganews.com>
<91782879-aa4b-4db8-a5fc-327dbfd3b9c9n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="54384"; posting-host="ux6ld97kLXxG8kVFFLnoWg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
 by: Chris M. Thomasson - Tue, 17 Aug 2021 23:18 UTC

On 8/17/2021 4:01 PM, wij wrote:
> On Wednesday, 18 August 2021 at 05:00:44 UTC+8, olcott wrote:
>> On 8/17/2021 12:35 AM, wij wrote:
>>> On Tuesday, 17 August 2021 at 06:58:05 UTC+8, olcott wrote:
>>>> On 8/16/2021 1:27 AM, wij wrote:
>>>>> On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
>>>>>> On 8/15/2021 9:45 AM, wij wrote:
>>>>>>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
>>>>>>>> On 8/15/2021 2:50 AM, wij wrote:
>>>>>>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
>>>>>>>>>> On 8/14/2021 1:09 PM, wij wrote:
>>>>>>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
>>>>>>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
>>>>>>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>>>>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>>>>>>>>>>>>>> how it is called including this example:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> P((u32)P);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>>>>>>>>>>>> to the halting problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
>>>>>>>>>>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>>>>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
>>>>>>>>>>>>>>> Submit message to the authors.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>>>>>>>>>>>> only correctly decide the halt status of its input. Computations that
>>>>>>>>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously the quoted text means differently to you and almost all programmers in
>>>>>>>>>>>>> the world. You are addressing your own interpretation. This is OK, but the
>>>>>>>>>>>>> interpretation is meaningless.
>>>>>>>>>>>> "the description of a Turing machine M" does not mean Turing machine M.
>>>>>>>>>>>> If people interpret this to mean Turing machine M they are wrong.
>>>>>>>>>>>
>>>>>>>>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
>>>>>>>>>>>
>>>>>>>>>>> If both authors are also wrong, replying the rest message is meaningless.
>>>>>>>>>>> You need to submit your interpretation to Linz and the author of the wiki.
>>>>>>>>>>>
>>>>>>>>>> I think that the problem is that your English is not so good.
>>>>>>>>>> The Linz text and the Wiki text are correct.
>>>>>>>>>> Linz retired many years ago.
>>>>>>>>>
>>>>>>>>> In your recent post somewhere, you said:
>>>>>>>>> "I made my refutation of Linz a little more clear by changing all of the
>>>>>>>>> subscripts to be numeric. My refutation of Linz cannot be properly
>>>>>>>>> understood until after my refutation of simplified Linz / Strachey is
>>>>>>>>> first understood..."
>>>>>>>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
>>>>>>>>>
>>>>>>>> This text right here is correct:
>>>>>>>> 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
>>>>>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>>>>>> solved it incorrect.
>>>>>>>
>>>>>>> Which one did you mean:
>>>>>>> 1. All of the rest of the text that "proves" the halting problem cannot be
>>>>>>> solved incorrect. (still ambiguous)
>>>>>>> 2. All of the rest of the text that "proves" the halting problem cannot
>>>>>>> solve incorrect. (ambiguous)
>>>>>>> 3. All of the rest of the text that "proves" the halting problem cannot be
>>>>>>> solved, it is incorrect.
>>>>>>>
>>>>>>
>>>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>>>> solved <IS> incorrect.
>>>>>>>>> There are much more inconsistent statements in your posts, like "H is a total
>>>>>>>>> function",...,etc. (I do not have time to re-find them).
>>>>>>>>>
>>>>>>>> H is a pure function of its inputs in that all of the nested simulations
>>>>>>>> are simply data derived entirely on the basis of this inputs.
>>>>>>>
>>>>>>> From your description:
>>>>>>> "The x86utm operating system uses a single contiguous block of RAM to
>>>>>>> most precisely map to the concept of a single contiguous Turing machine
>>>>>>> tape. All of the code and data of the virtual machines that it executes
>>>>>>> are contained in this single contiguous block. There is no virtual
>>>>>>> memory paging in the x86utm operating system."
>>>>>>>
>>>>>>> I believe your H is a 'pure function', you are actually dealing with two "C"
>>>>>>> function calls. H is not really a simulator as you keeps calling it so.
>>>>>>> Show me how H(P,P) takes its input P as 'simple data'.
>>>>>>>
>>>>>> The x86utm operating system is build from an x86 emulator capable of
>>>>>> emulating all of the 80386 instructions using 4 GB of RAM.
>>>>>
>>>>> Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
>>>>> Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
>>>>> I do not believe you can build a machine or software capable of emulating ALL of
>>>>> the 80386 instructions. Therefore, I assume all you have is a simulating
>>>>> application.
>>>>>
>>>>>> The following x86utm operating system function calls the x86 emulator to
>>>>>> emulate exactly one instruction of the slave process and then return to
>>>>>> the calling process. It also decodes the slave instruction that was
>>>>>> emulated so that it can be stored in the execution trace.
>>>>>>
>>>>>> u32 DebugStep(Registers* master_state,
>>>>>> Registers* slave_state,
>>>>>> Decoded_Line_Of_Code* decoded) {}
>>>>>
>>>>> The question how H(P,P) treats its argument P,P as data is still not answered.
>>>> The details need not be specified to understand that all the simulations
>>>> of the executed simulator are data belonging to the executed H. Details
>>>> merely provide the means for endless digression away from the key point.
>>>>> E.g. does H contain a call to DebugStep to decode P pointed byte string data?
>>>>> Actually, there are many implementing problems for your simulator H and P to
>>>>> be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
>>>>> the simulation is not necessary for the proof.
>>>>>
>>>> The code does what it specifies that it does that alone is complete
>>>> proof. We can know for sure that H does perform a pure simulation of P
>>>> because the x86 code specified by P is exactly exactly as this code
>>>> specifies.
>>>
>>> What is the 'proof'? What is exactly the 'code'?
>>>
>>> 1. You are not capable of creating a "x86utm operating system".
>>> 2. You are not capable of understanding all 80386 instructions (no even 80186,80286).
>>> 3. You do not even understand C function and TM language properly.
>>> 4. You do not know logic.
>>> 5. You do not have a real H and P.
>>> 6. What you have are brainless talk and lies.
>>>
>>> Tell everyone, which one of the above is false.
>> I take the above as your indication that you intend to only act like a
>> troll and thing else..
>
> I intended to point you to the true thing that you keep blocking yourself.
> So, I put them again in more suspicious/polite way. One reason is that you are
> too cunning in argument.
>
> 1. Did you actually created a "x86utm operating system"? An OS means the software
>  BIOS passes to immediately after power on.
> 2. Do you really understand all 80386 instructions? I remember you said you
> have 'emulated' them. I am sure you are not capable of doing this, but you keep
> questioning people do not understand x86 assembly, thus do not understand your
> proof. Actually, I do not believe you can emulate any of the less powerful x86
> assembly 80286,80186,8086,8088,8048...
> 3. You do not seem to understand C function and TM language properly.
> 4. You do not seem to know the basic Logic.
> 5. You do not have a real H and P that match your description
> 6. What you have are brainless talk and lies. (This is actually your accusation
>   to others.)
>
> Tell everyone, WHICH ONE of the above is false.
> --
> Another hint you missed:
>>> Can God create a stone He cannot lift?
>>> https://en.wikipedia.org/wiki/Omnipotence_paradox
>>>
>> Yes and then after that he can no longer lift this stone.
>
> But you think you can. Do you see the relevance?
>


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

<LtXSI.32$tv2.30@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.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?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<iTCSI.65035$EF2.32920@fx47.iad>
<YPSdnaZYl6wunIb8nZ2dnUU7-VnNnZ2d@giganews.com>
<MSDSI.24014$6p.13563@fx36.iad>
<BqydnTi77c5Olob8nZ2dnUU7-TfNnZ2d@giganews.com>
<qdESI.53526$M14.34426@fx11.iad>
<N9OdnZVmheHKhob8nZ2dnUU7-RudnZ2d@giganews.com>
<s0FSI.19521$lK.19067@fx41.iad>
<a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@giganews.com>
<ToMSI.25497$Thb4.14112@fx35.iad>
<2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@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: <2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Lines: 109
Message-ID: <LtXSI.32$tv2.30@fx45.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: Tue, 17 Aug 2021 19:19:07 -0400
X-Received-Bytes: 6266
 by: Richard Damon - Tue, 17 Aug 2021 23:19 UTC

On 8/17/21 11:39 AM, olcott wrote:
> On 8/17/2021 5:42 AM, Richard Damon wrote:
>> On 8/16/21 10:33 PM, olcott wrote:
>>> On 8/16/2021 9:19 PM, Richard Damon wrote:
>>>> On 8/16/21 10:13 PM, olcott wrote:
>>>>> On 8/16/2021 8:24 PM, Richard Damon wrote:
>>>>>>
>>>>>> Please read the definitions again.
>>>>>>
>>>>>> A Pure simulator NEVER aborts its simulation.
>>>>>
>>>>> Like I said you probably have to reread what I say a few hundred more
>>>>> times before you will understand it. I can no longer tolerate people
>>>>> that continually glace at a few words before forming their rebuttal.
>>>>>
>>>>
>>>> Ok, so you just admit that you aren't using the real definition.
>>>>
>>>
>>> If you reread it a few hundred more times you will see that I did not
>>> use the term incorrectly.
>>
>> Then please provide a reliable source that shows the term being used in
>> that manner.
>>
>
> It is self-evident that the term is being used correctly.

Maybe to someone who is pathologically wrong and admits to not having
studied the theory.

It is WRONG, thoroughly W-R-O-N-G

WW WW RRRRRRRR OOOOOOOOOO NN NN GGGGGG
WW WW RR RR OO OO NNNN NN GG GG
WW WW WW RR RR OO OO NN NN NN GG
WW WW WW RRRRRRRR OO OO NN NN NN GG GGGGGG
WW WW WW RR RR OO OO NN NN NN GG GG
WW WW WW RR RR OO OO NN NNNN GG GG
WWWWWWWWWW RR RR OOOOOOOOOO NN NN GGGGGG

Maybe you should look at what I said, and try to find anyone else (with
a positive reputation) that agrees with you.

Note, the operative feature that a pure simulator has is that it
produces the exact same result as the machine it is simulating would.
Your claimed pure simulator doesn't, as you claim that its input is
non-halting but the simulator is halting.

At BEST you have a claim of some 'new use' of the term but then you need
to actually prove that your transformation is valid for this sort of
machine.

Please TRY to find someone who shows ANY evidence that it is valid to
replace the simulation of this sort of machine you are calling a 'pure
simulator' (one that eventually abort its simulation) with a simulation
of the machine it is simulation.

THAT is where you fully hit the wall of UNSOUND logic.

Your 'logic' is totally unsound, as is your instance on it. It as truly
reached the point where it has just devolved into a blatant lie.

>
> Your evaluation that the term is not being used correctly is entirely
> based on the fact that you are simply skipping over and ignoring some of
> the words that I said. If you are very careful to make sure that you
> read and understand every single word then you will see that I am using
> the term "simulation" correctly.

WRONG. I go by the DEFINITION of the word. Note, it isn't 'simulator'
that I disagree with. Your machine is definitely a partial simulator. It
just isn't a 'Pure' simulator that simulates to the 'end' of the machine
it is simulating, which is what is needed to use the transformation you
want to use.

You machine is most definitely a PARTIAL Simulator, for which you have
no grounds to use that transformation.

You just are so ignorant of the field, that you don't understand the
difference, and so ignorant of the rules of logic to realize that you
really do need to try to prove your assertions.

>
> By making sure to erase the words that I said it would seem to be easier
> to get away with intentional misinterpretation.

Why do I need to erase them (like you seem to like to). It is CLEAR to
anyone with a sane mind how wrong your logic is, so I feel no need to
hide the words I am refuting.

YOU are the one who reveal your heart by the way you dishonestly trim
messages, removing important content that you just don't want to deal with.

It is obvious to everyone how badly you are handling this. YOU are the
one stuck in unsound logic due to an unsound mindset.

>
> Intentional misinterpretation is a form of lying. The fact that you keep
> erasing these words seems to be evidence that you are lying:

Yes, YOU seem to INTENTIONALLY misuse words, which as you say is LYING.

I hope you are prepared to meet your maker with this sin deeply in your
heart.

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

<HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!tncsrv06.tnetconsulting.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 18:25:47 -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>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<iTCSI.65035$EF2.32920@fx47.iad>
<YPSdnaZYl6wunIb8nZ2dnUU7-VnNnZ2d@giganews.com>
<MSDSI.24014$6p.13563@fx36.iad>
<BqydnTi77c5Olob8nZ2dnUU7-TfNnZ2d@giganews.com>
<qdESI.53526$M14.34426@fx11.iad>
<N9OdnZVmheHKhob8nZ2dnUU7-RudnZ2d@giganews.com>
<s0FSI.19521$lK.19067@fx41.iad>
<a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@giganews.com>
<ToMSI.25497$Thb4.14112@fx35.iad>
<2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@giganews.com> <LtXSI.32$tv2.30@fx45.iad>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 18:25:44 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <LtXSI.32$tv2.30@fx45.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com>
Lines: 127
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-EFRy2Ib50hGhMTpjOL29jyHyeM/8yjzp/Ud1COM9bCP7hlOOICbDxPtTVR64AFtEuJoi57DmjSedR1o!h/2O0sfA+wqXLSLoRuS0H1D7eu3fw/W1apQNZlIyIWOjDgSlhobAI/2oO7QS20z4Vq85zzN1zIRY!4aA=
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: 7377
 by: olcott - Tue, 17 Aug 2021 23:25 UTC

On 8/17/2021 6:19 PM, Richard Damon wrote:
> On 8/17/21 11:39 AM, olcott wrote:
>> On 8/17/2021 5:42 AM, Richard Damon wrote:
>>> On 8/16/21 10:33 PM, olcott wrote:
>>>> On 8/16/2021 9:19 PM, Richard Damon wrote:
>>>>> On 8/16/21 10:13 PM, olcott wrote:
>>>>>> On 8/16/2021 8:24 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> Please read the definitions again.
>>>>>>>
>>>>>>> A Pure simulator NEVER aborts its simulation.
>>>>>>
>>>>>> Like I said you probably have to reread what I say a few hundred more
>>>>>> times before you will understand it. I can no longer tolerate people
>>>>>> that continually glace at a few words before forming their rebuttal.
>>>>>>
>>>>>
>>>>> Ok, so you just admit that you aren't using the real definition.
>>>>>
>>>>
>>>> If you reread it a few hundred more times you will see that I did not
>>>> use the term incorrectly.
>>>
>>> Then please provide a reliable source that shows the term being used in
>>> that manner.
>>>
>>
>> It is self-evident that the term is being used correctly.
>
> Maybe to someone who is pathologically wrong and admits to not having
> studied the theory.
>
> It is WRONG, thoroughly W-R-O-N-G
>
>
> WW WW RRRRRRRR OOOOOOOOOO NN NN GGGGGG
> WW WW RR RR OO OO NNNN NN GG GG
> WW WW WW RR RR OO OO NN NN NN GG
> WW WW WW RRRRRRRR OO OO NN NN NN GG GGGGGG
> WW WW WW RR RR OO OO NN NN NN GG GG
> WW WW WW RR RR OO OO NN NNNN GG GG
> WWWWWWWWWW RR RR OOOOOOOOOO NN NN GGGGGG
>
> Maybe you should look at what I said, and try to find anyone else (with
> a positive reputation) that agrees with you.
>
> Note, the operative feature that a pure simulator has is that it
> produces the exact same result as the machine it is simulating would.
> Your claimed pure simulator doesn't, as you claim that its input is
> non-halting but the simulator is halting.
>
> At BEST you have a claim of some 'new use' of the term but then you need
> to actually prove that your transformation is valid for this sort of
> machine.
>
> Please TRY to find someone who shows ANY evidence that it is valid to
> replace the simulation of this sort of machine you are calling a 'pure
> simulator' (one that eventually abort its simulation) with a simulation
> of the machine it is simulation.
>
> THAT is where you fully hit the wall of UNSOUND logic.
>
> Your 'logic' is totally unsound, as is your instance on it. It as truly
> reached the point where it has just devolved into a blatant lie.
>
>>
>> Your evaluation that the term is not being used correctly is entirely
>> based on the fact that you are simply skipping over and ignoring some of
>> the words that I said. If you are very careful to make sure that you
>> read and understand every single word then you will see that I am using
>> the term "simulation" correctly.
>
> WRONG. I go by the DEFINITION of the word. Note, it isn't 'simulator'
> that I disagree with. Your machine is definitely a partial simulator. It
> just isn't a 'Pure' simulator that simulates to the 'end' of the machine
> it is simulating, which is what is needed to use the transformation you
> want to use.
>
> You machine is most definitely a PARTIAL Simulator, for which you have
> no grounds to use that transformation.
>
> You just are so ignorant of the field, that you don't understand the
> difference, and so ignorant of the rules of logic to realize that you
> really do need to try to prove your assertions.
>
>
>>
>> By making sure to erase the words that I said it would seem to be easier
>> to get away with intentional misinterpretation.
>
> Why do I need to erase them (like you seem to like to). It is CLEAR to
> anyone with a sane mind how wrong your logic is, so I feel no need to
> hide the words I am refuting.
>
> YOU are the one who reveal your heart by the way you dishonestly trim
> messages, removing important content that you just don't want to deal with.
>
> It is obvious to everyone how badly you are handling this. YOU are the
> one stuck in unsound logic due to an unsound mindset.
>
>>
>> Intentional misinterpretation is a form of lying. The fact that you keep
>> erasing these words seems to be evidence that you are lying:
>
> Yes, YOU seem to INTENTIONALLY misuse words, which as you say is LYING.
>
> I hope you are prepared to meet your maker with this sin deeply in your
> heart.
>
>

That you keep erasing these words rather than carefully critqueing each
one of them sufficiently proves that you are dishonest:

--Because H only acts as a pure simulator of its input
--until after its halt status decision has been made it
--has no behavior that can possibly effect the behavior
--of its input. Because of this H screens out its own
--address range in every execution trace that it examines.
--This is why we never see any instructions of H in any
--execution trace after an input calls H.

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

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

 copy mid

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

 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: Wed, 18 Aug 2021 01:02:34 +0100
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <87wnojsjqd.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="e21ab49ec019735fe1837fbff80e73bc";
logging-data="8066"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PCRY+TuV6xo7InecmVcn0TIqApVsG0tQ="
Cancel-Lock: sha1:7nLd76mO6sk/4eDGsg4ZNBdWRqI=
sha1:eD1bIn1yJVJhvVrsuw8iLIkgHp4=
X-BSB-Auth: 1.811e51c5fa0ae92ad48c.20210818010234BST.87wnojsjqd.fsf@bsb.me.uk
 by: Ben Bacarisse - Wed, 18 Aug 2021 00:02 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/17/2021 5:14 PM, Ben Bacarisse wrote:

>> The facts come from you. They are not a matter of opinion. P(P) halts.
>> H(P,P) == 0.
....
>> You are happy with that answer, but I can specify a function you can't
>> write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
>> You don't get to choose what the "correct" answer is, so your only
>> option if to ignore the challenge.
>
> At this point I expect and require that those seeking an actual honest
> dialogue use the basis that I provided to verify that H does decide
> the halt status of its inputs correctly. Everyone else is written off
> as dishonest.

That's up to you. I can't stop you wasting time on a function no one
cares about, but you know you can't write the function I specified, so
you are back where you started 17 years ago. There are still
undecidable sets.

What's more, the computation that will defeat any attempt you make at
meeting this challenge is the very one you thought you'd got round.

>>>> you can't write a function B such that B(M, I)
>>>> is true, if and only if, M(I) halts. Your H won't do because you assure
>>>> us that P(P) halts and H(P, P) is false.
>>>> You can crow about H all you like, and you can stamp your feet and
>>>> *insist* that H(P,P) == 0 is correct, but there are a still uncomputable
>>>> functions. I just specified one -- B above.
>>>> If you want to take up this challenge, I can specify it more precisely,
>>>> but I advise you to ignore it.
>>
>> As expected.

--
Ben.

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

<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Aug 2021 19:40:40 -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> <87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk> <D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 17 Aug 2021 19:40:38 -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: <87wnojsjqd.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
Lines: 79
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SmR6kB1phOFCD7Jj+/0GnfXRgeVz7xirkkzoWgfsYhFoIQ7LrgLp5iBStkGD+3zVFH/oJcsvCNTJUPk!iyU3F6AUDP4Z7RdMFEIOvK6INkjMd4XsbQ/diG9EJzXeKs/8YBFynRQybU/jpDJ2Sfd83TlHHyXa!6vg=
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: 5021
 by: olcott - Wed, 18 Aug 2021 00:40 UTC

On 8/17/2021 7:02 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/17/2021 5:14 PM, Ben Bacarisse wrote:
>
>>> The facts come from you. They are not a matter of opinion. P(P) halts.
>>> H(P,P) == 0.
> ...
>>> You are happy with that answer, but I can specify a function you can't
>>> write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
>>> You don't get to choose what the "correct" answer is, so your only
>>> option if to ignore the challenge.
>>
>> At this point I expect and require that those seeking an actual honest
>> dialogue use the basis that I provided to verify that H does decide
>> the halt status of its inputs correctly. Everyone else is written off
>> as dishonest.
>
> That's up to you. I can't stop you wasting time on a function no one
> cares about, but you know you can't write the function I specified, so
> you are back where you started 17 years ago. There are still
> undecidable sets.
>

The function does meet the spec and you either refuse to confirm this or
are technically unqualified to evaluate the x86 code proof of this. I
was very surprised how little you understood about operating system
context switching.

I certainly won't make any denigrating remarks about this. I simply over
estimated your ability, my mistake. Your technical ability regarding the
theory of computation may be still quite high.

Let's get back to something that you seem to know well:

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

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

Can you understand that Ĥ applied to ⟨Ĥ⟩ would never stop running if the
machine at Ĥ.qx was a UTM? (Your lack of understanding of this would not
be my mistake).

> What's more, the computation that will defeat any attempt you make at
> meeting this challenge is the very one you thought you'd got round.
>

I did get around this H(P,P) does correctly decide that its input never
halts thus perfectly meeting the requirements of the actual halting
problem. Also the embedded halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does
correctly decide that its input never halts.

I only have to resolve the paradox and there will be nothing that even
seems to show that my proof is incorrect.

That I was able to correctly resolve the Liar Paradox having been an
open logic issue for 2000 years sufficiently proves that I can resolve
paradoxes. Russell's paradox suffered the same fate.

>>>>> you can't write a function B such that B(M, I)
>>>>> is true, if and only if, M(I) halts. Your H won't do because you assure
>>>>> us that P(P) halts and H(P, P) is false.
>>>>> You can crow about H all you like, and you can stamp your feet and
>>>>> *insist* that H(P,P) == 0 is correct, but there are a still uncomputable
>>>>> functions. I just specified one -- B above.
>>>>> If you want to take up this challenge, I can specify it more precisely,
>>>>> but I advise you to ignore it.
>>>
>>> As expected.
>

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

<ZMYSI.11$Oz2.8@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!npeer.as286.net!npeer-ng0.as286.net!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.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?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<iTCSI.65035$EF2.32920@fx47.iad>
<YPSdnaZYl6wunIb8nZ2dnUU7-VnNnZ2d@giganews.com>
<MSDSI.24014$6p.13563@fx36.iad>
<BqydnTi77c5Olob8nZ2dnUU7-TfNnZ2d@giganews.com>
<qdESI.53526$M14.34426@fx11.iad>
<N9OdnZVmheHKhob8nZ2dnUU7-RudnZ2d@giganews.com>
<s0FSI.19521$lK.19067@fx41.iad>
<a7idnTYs7dNmgob8nZ2dnUU7-WHNnZ2d@giganews.com>
<ToMSI.25497$Thb4.14112@fx35.iad>
<2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@giganews.com> <LtXSI.32$tv2.30@fx45.iad>
<HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@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: <HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 164
Message-ID: <ZMYSI.11$Oz2.8@fx47.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: Tue, 17 Aug 2021 20:47:53 -0400
X-Received-Bytes: 8905
 by: Richard Damon - Wed, 18 Aug 2021 00:47 UTC

On 8/17/21 7:25 PM, olcott wrote:
> On 8/17/2021 6:19 PM, Richard Damon wrote:
>> On 8/17/21 11:39 AM, olcott wrote:
>>> On 8/17/2021 5:42 AM, Richard Damon wrote:
>>>> On 8/16/21 10:33 PM, olcott wrote:
>>>>> On 8/16/2021 9:19 PM, Richard Damon wrote:
>>>>>> On 8/16/21 10:13 PM, olcott wrote:
>>>>>>> On 8/16/2021 8:24 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> Please read the definitions again.
>>>>>>>>
>>>>>>>> A Pure simulator NEVER aborts its simulation.
>>>>>>>
>>>>>>> Like I said you probably have to reread what I say a few hundred
>>>>>>> more
>>>>>>> times before you will understand it. I can no longer tolerate people
>>>>>>> that continually glace at a few words before forming their rebuttal.
>>>>>>>
>>>>>>
>>>>>> Ok, so you just admit that you aren't using the real definition.
>>>>>>
>>>>>
>>>>> If you reread it a few hundred more times you will see that I did not
>>>>> use the term incorrectly.
>>>>
>>>> Then please provide a reliable source that shows the term being used in
>>>> that manner.
>>>>
>>>
>>> It is self-evident that the term is being used correctly.
>>
>> Maybe to someone who is pathologically wrong and admits to not having
>> studied the theory.
>>
>> It is WRONG, thoroughly W-R-O-N-G
>>
>>
>> WW      WW  RRRRRRRR    OOOOOOOOOO  NN      NN    GGGGGG
>> WW      WW  RR      RR  OO      OO  NNNN    NN  GG      GG
>> WW  WW  WW  RR      RR  OO      OO  NN  NN  NN  GG
>> WW  WW  WW  RRRRRRRR    OO      OO  NN  NN  NN  GG  GGGGGG
>> WW  WW  WW  RR  RR      OO      OO  NN  NN  NN  GG      GG
>> WW  WW  WW  RR    RR    OO      OO  NN    NNNN  GG      GG
>> WWWWWWWWWW  RR      RR  OOOOOOOOOO  NN      NN    GGGGGG
>>
>> Maybe you should look at what I said, and try to find anyone else (with
>> a positive reputation) that agrees with you.
>>
>> Note, the operative feature that a pure simulator has is that it
>> produces the exact same result as the machine it is simulating would.
>> Your claimed pure simulator doesn't, as you claim that its input is
>> non-halting but the simulator is halting.
>>
>> At BEST you have a claim of some 'new use' of the term but then you need
>> to actually prove that your transformation is valid for this sort of
>> machine.
>>
>> Please TRY to find someone who shows ANY evidence that it is valid to
>> replace the simulation of this sort of machine you are calling a 'pure
>> simulator' (one that eventually abort its simulation) with a simulation
>> of the machine it is simulation.
>>
>> THAT is where you fully hit the wall of UNSOUND logic.
>>
>> Your 'logic' is totally unsound, as is your instance on it. It as truly
>> reached the point where it has just devolved into a blatant lie.
>>
>>>
>>> Your evaluation that the term is not being used correctly is entirely
>>> based on the fact that you are simply skipping over and ignoring some of
>>> the words that I said. If you are very careful to make sure that you
>>> read and understand every single word then you will see that I am using
>>> the term "simulation" correctly.
>>
>> WRONG. I go by the DEFINITION of the word. Note, it isn't 'simulator'
>> that I disagree with. Your machine is definitely a partial simulator. It
>> just isn't a 'Pure' simulator that simulates to the 'end' of the machine
>> it is simulating, which is what is needed to use the transformation you
>> want to use.
>>
>> You machine is most definitely a PARTIAL Simulator, for which you have
>> no grounds to use that transformation.
>>
>> You just are so ignorant of the field, that you don't understand the
>> difference, and so ignorant of the rules of logic to realize that you
>> really do need to try to prove your assertions.
>>
>>
>>>
>>> By making sure to erase the words that I said it would seem to be easier
>>> to get away with intentional misinterpretation.
>>
>> Why do I need to erase them (like you seem to like to). It is CLEAR to
>> anyone with a sane mind how wrong your logic is, so I feel no need to
>> hide the words I am refuting.
>>
>> YOU are the one who reveal your heart by the way you dishonestly trim
>> messages, removing important content that you just don't want to deal
>> with.
>>
>> It is obvious to everyone how badly you are handling this. YOU are the
>> one stuck in unsound logic due to an unsound mindset.
>>
>>>
>>> Intentional misinterpretation is a form of lying. The fact that you keep
>>> erasing these words seems to be evidence that you are lying:
>>
>> Yes, YOU seem to INTENTIONALLY misuse words, which as you say is LYING.
>>
>> I hope you are prepared to meet your maker with this sin deeply in your
>> heart.
>>
>>
>
> That you keep erasing these words rather than carefully critqueing each
> one of them sufficiently proves that you are dishonest:
>
> --Because H only acts as a pure simulator of its input
> --until after its halt status decision has been made it
> --has no behavior that can possibly effect the behavior
> --of its input. Because of this H screens out its own
> --address range in every execution trace that it examines.
> --This is why we never see any instructions of H in any
> --execution trace after an input calls H.
>

Pure simulator *until*, Then it isn't because it terminates its simulation.

Thus, it ISN'T a pure simulator, since a REAL pure simulator (UTM) NEVER
stops its simulation until the machine it is simulating reaches its end.

THEREFORE, when H simulates the cop[y of H within P, it needs to take
this behavior into account, or it is WRONG. Your H assumes INCORRECTLY
that H will NEVER abort its simulation, when it is a fact that it will.

UNSOUND logic.

You seem to be to ignorant of this basic detail shows you are unfit to
make these claims.

You live till you die, does that mean that you are immortal?

Machines are classified by how they act for their WHOLE execution. Thus
to really be a pure simulator, it needs to make it all the way to the
end, your H is a quitter, it gives up and doesn't finish, therefore it
FAILS to be a real UTM.

A Halting machine is one that AT THE END, has reached a halting state.

A Non-Halting machine is one that NEVER reaches such a state, even when
we keep running it for an unbounded number of steps.

The '27' (or what ever number you want to use for H) isn't unbounded,
and is less than the finite number that you elsewhere have show that the
machien P(P) will reach its finish at.

This is basically like a runner starting a race and giving up half way
through and saying it is impossible, you can't reach the end, I've done
a few laps and I seem to keep on getting to the same place.

BAD LOGIC, the smart runner knows there is just a few more laps to go,
so he will finish.

YOU have decided to go for the DNF result, but claim it to be right.

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

<xPYSI.12$Oz2.10@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.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?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<cdd186c7-7d3a-45f6-b4e8-3bfe85ef6075n@googlegroups.com>
<vM-dnYCGBvPRcYr8nZ2dnUU7-WXNnZ2d@giganews.com>
<75407d56-1578-44f6-bd82-8428fa402e2fn@googlegroups.com>
<kNWdnaLxE7QhZor8nZ2dnUU7-I_NnZ2d@giganews.com>
<ea3afea5-0188-4dbc-b3a4-af2ee2436228n@googlegroups.com>
<v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@giganews.com>
<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
<06f505d8-e93c-4549-a017-af4eb3c70cedn@googlegroups.com>
<NoedncYda_jrcIf8nZ2dnUU7-T_NnZ2d@giganews.com>
<88890477-e0c7-4a32-92f3-d3999fa790a6n@googlegroups.com>
<eNednfQicdjovoH8nZ2dnUU7-K2dnZ2d@giganews.com>
<91782879-aa4b-4db8-a5fc-327dbfd3b9c9n@googlegroups.com>
<sfhg3i$1l3g$1@gioia.aioe.org>
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: <sfhg3i$1l3g$1@gioia.aioe.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Lines: 10
Message-ID: <xPYSI.12$Oz2.10@fx47.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: Tue, 17 Aug 2021 20:50:36 -0400
X-Received-Bytes: 2094
 by: Richard Damon - Wed, 18 Aug 2021 00:50 UTC

On 8/17/21 7:18 PM, Chris M. Thomasson wrote:

>
> Can he emulate lock cmpxchg?

It is very possible to emulate ANY instruction. Some require a bit more
care than others.

Since is emulator is really only emulating a single thread of execution,
so things like locks are really not that important.

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

<MSYSI.10$Fu2.0@fx16.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.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?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@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>
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: <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 145
Message-ID: <MSYSI.10$Fu2.0@fx16.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: Tue, 17 Aug 2021 20:54:02 -0400
X-Received-Bytes: 7052
 by: Richard Damon - Wed, 18 Aug 2021 00:54 UTC

On 8/17/21 7:04 PM, olcott wrote:
> On 8/17/2021 5:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/17/2021 5:23 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>>        if (H(x, x))
>>>>>>>>>>>          HERE: goto HERE;
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> If H(P, P) does not give the halting status of P(P) it is
>>>>>>>>>> useless.
>>>>>>>>>
>>>>>>>>> In other words your knowledge of infinite recursive invocation
>>>>>>>>> is on
>>>>>>>>> par with your knowledge of operating system context switching?
>>>>>>>> P(P) halts.
>>>>>>>>
>>>>>>>>>> Imagine if you'd been honest about this two and half years
>>>>>>>>>> ago?  "I have
>>>>>>>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat)
>>>>>>>>>> halts."  No
>>>>>>>>>> one would care.
>>>>>>>>>
>>>>>>>>> I finally have this one untangled:
>>>>>>>>> int main() { P(P); } is computationally equivalent to
>>>>>>>>> int main() { Simulate(P,P); }
>>>>>>>>>
>>>>>>>>> Because they are computationally equivalent they have the same
>>>>>>>>> halting
>>>>>>>>> behavior, however:
>>>>>>>>>
>>>>>>>>> Neither of them is computationally equivalent to the H(P,P) called
>>>>>>>>> from P because the different placement in the execution trace
>>>>>>>>> changes
>>>>>>>>> the halting behavior of P(P).
>>>>>>>>
>>>>>>>> H(M, I) is supposed to report the halting or otherwise of M(I). 
>>>>>>>> You
>>>>>>>> don't claim that your H can do this in all cases, but you
>>>>>>>> boasted (you
>>>>>>>> like boasting) that it did for the "hat" version of H, AKA P
>>>>>>>> above.  It
>>>>>>>> does not.  P(P) halts but H(P, P) == 0.  Boring.
>>>>>>>
>>>>>>> That you don't bother to pay attention to the details or are
>>>>>>> unable to
>>>>>>> understand the x86 language well enough to understand the details in
>>>>>>> no way negates the fact that H(P,P) does correctly decide that its
>>>>>>> input never halts.
>>>>>> The details don't change whether H(P,P) is right or wrong.  H(P,P)
>>>>>> should report the halting or otherwise of P(P).  It's that simple.
>>>>>>
>>>>>
>>>>> int main() { H(P,P); } does correctly decide that its input never
>>>>> halts.
>>>>> Unless the H of main() aborts its simulation of P(P), this input never
>>>>> halts.
>>>>
>>>> By insisting that H(P,P) == 0 is correct despite P(P) halting you
>>>> are, in effect, agreeing that
>>>
>>> There is a key paradox that no one besides me is bothering to examine
>>> because everyone here is too damn sure of their own damn opinion to
>>> give my work a fair and accurate evaluation.
>>
>> The facts come from you.  They are not a matter of opinion.  P(P) halts.
>> H(P,P) == 0.
>>
>
> Which appears to be a direct contradiction proving that H is wrong until
> you carefully examine the basis that H uses for its halt status decision
> and directly see that this basis is correct thus the decision must be
> correct.
>

UNSOUND, DISPROVEN

> Either no one wants to be bothered by looking at this after their mind
> is already made up or they don't understand the x86 language well enough
> to verify that H does correctly decide that its input never halts. In
> the long run this won't matter because I will resolve the paradox too.
>

WRONG. YOUR logic is UNSOUND and DISPROVEN.

>> You are happy with that answer, but I can specify a function you can't
>> write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
>> You don't get to choose what the "correct" answer is, so your only
>> option if to ignore the challenge.
>>
>
> At this point I expect and require that those seeking an actual honest
> dialogue use the basis that I provided to verify that H does decide the
> halt status of its inputs correctly. Everyone else is written off as
> dishonest.

YOU need to take an Honest look at what people hav said and present a
REAL counter argument.

>
> If H(P,P) really did decide its input incorrectly then there must be
> some flaw in the basis that it uses. If there is no flaw in the basis
> that it uses then H(P,P) does decide its input correctly. That people do
> not want to even discuss the basis that H uses sufficiently proves that
> they are not honest.

Yep, H assume the emulated H will NEVER abort, even if its emulation was
carried on to the completion, since the emulate H WILL abort, just like
the H that is doing the emulation, the emulating H has used UNSOUND
logic and get the wrong answer.

"Will Abort" is not the same as "Will Never Abort".

Thus, UNSOUND LOGIC.

>
>>>>   you can't write a function B such that B(M, I)
>>>> is true, if and only if, M(I) halts.  Your H won't do because you
>>>> assure
>>>> us that P(P) halts and H(P, P) is false.
>>>> You can crow about H all you like, and you can stamp your feet and
>>>> *insist* that H(P,P) == 0 is correct, but there are a still
>>>> uncomputable
>>>> functions.  I just specified one -- B above.
>>>> If you want to take up this challenge, I can specify it more precisely,
>>>> but I advise you to ignore it.
>>
>> As expected.
>>
>
>

Pages:12345678910111213141516171819
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor