Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Just Say No." - Nancy Reagan "No." - Ronald Reagan


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?

<iq6dnWLRzMfSoYX8nZ2dnUU7-QfNnZ2d@giganews.com>

 copy mid

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

 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: Sat, 14 Aug 2021 16:57:35 -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> <sf8te8$dek$1@dont-email.me>
<j6adne7DWZT5kYX8nZ2dnUU7-QPNnZ2d@giganews.com>
<CSVRI.10013$cd2.558@fx02.iad>
<mOmdnayK5blhsYX8nZ2dnUU7-cHNnZ2d@giganews.com> <9fWRI.8857$Mc.3781@fx34.iad>
<qomdnZdgV6iBrIX8nZ2dnUU7-aednZ2d@giganews.com>
<FSWRI.26881$NQ1.361@fx48.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 16:57:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <FSWRI.26881$NQ1.361@fx48.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <iq6dnWLRzMfSoYX8nZ2dnUU7-QfNnZ2d@giganews.com>
Lines: 154
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-8iTKR0JDScYG6oiEvMJxDM//W+koBFt+a8OtG9JPc1ykoljHPl8e0Aa0lWHrI/oTzFFFkmAQplLjGB3!1L7aGmWitoEIRoiU8cZY3G456GS+tpGV0b8tyxDSgPNDyycm45+GxjAPLiS5ZtcETiXAx863EA==
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: 7976
 by: olcott - Sat, 14 Aug 2021 21:57 UTC

On 8/14/2021 4:48 PM, Richard Damon wrote:
> On 8/14/21 5:09 PM, olcott wrote:
>> On 8/14/2021 4:06 PM, Richard Damon wrote:
>>> On 8/14/21 4:52 PM, olcott wrote:
>>>> On 8/14/2021 3:39 PM, Richard Damon wrote:
>>>>> On 8/14/21 2:33 PM, olcott wrote:
>>>>>> On 8/14/2021 12:10 PM, Richard Damon wrote:
>>>>>>> On 8/14/21 12:16 PM, 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.
>>>>>>>>
>>>>>>>
>>>>>>> This is the point where you use of English is incorrect, and you
>>>>>>> need to
>>>>>>> restudy English so you understand what you are saying.
>>>>>>>
>>>>>>> *Inputs* are NEVER *Computations* in and of themselves, but are
>>>>>>> merely
>>>>>>> the string representations of the ACTUAL Computations.
>>>>>>>
>>>>>>> As such, 'inputs' don't halt or be non-halting, only the machines
>>>>>>> they
>>>>>>> represent.
>>>>>> The input "description of an arbitrary computer program" is the basis
>>>>>> for the halt status decision.
>>>>>>
>>>>>>
>>>>>
>>>>> The input is what the program uses to make its decision, the right
>>>>> answer is what the actual machine does.
>>>>>
>>>>
>>>> Because the input to H(P,P) is at a different point int the execution
>>>> trace than the P of int main(){ P(P); } it is a different computation
>>>> having different behavior than the input to H(P,P).
>>>
>>> What 'point'. The question is will the computation finish or not.
>>>
>> When trying to prove that I do not own a white cat, proof that I do not
>> own a black dog does not count.
>>
>> The two distinctly different computations have different halting behavior.
>>
>
> Right, so we want to know what the Turing Machine that the input is a
> representation of does, i.e., what does the ACTUAL machine H^(<H^>)
> does, which is Halt.
>

That you can't even keep track of which code is being discussed is why I
hardly ever talk to you.

> It doesn't matter that the partial simulation that H did of the machine
> never reached its final halting state because H stop simulating it
> before it gets there.
>

[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

While H remains in pure simulation mode simulating the input to H(P,P)
this simulated input never stops running thus conclusively proving that
when H decides this input never halts it is correct.

The other reason is that I have to explain things to you hundreds of
times before you bother to ever notice what I actually said.

> YOU are the one looking at the black dog when the question is about the
> white cat.
>
> The decider H is asked what will the machine H^(<H^>) will do, as
> specified by its input <H^> <H^>.
>
> We know that the actual machine H^(<H^>) Halts, so the right answer is Halt.
>
> We know that H will reply non-halting
>
> Thus we know that it is wrong.
>
> We know it is wrong because it is based on unsound logic presuming that
> H is a pure simulator, when it is a simulator that will decide to abort,
> and thus its logic has a false premise as an input.
>
> The fact that H only partially simulates its simulation of <H^> <H^>
> doesn't actually prove anything, except that it didn't simulate to the
> point of actually proving anything, and thus it had to just guess, and
> it guesses wrong.
>

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

<edXRI.972$SX.76@fx03.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.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> <sf8te8$dek$1@dont-email.me>
<j6adne7DWZT5kYX8nZ2dnUU7-QPNnZ2d@giganews.com>
<CSVRI.10013$cd2.558@fx02.iad>
<mOmdnayK5blhsYX8nZ2dnUU7-cHNnZ2d@giganews.com> <9fWRI.8857$Mc.3781@fx34.iad>
<qomdnZdgV6iBrIX8nZ2dnUU7-aednZ2d@giganews.com>
<FSWRI.26881$NQ1.361@fx48.iad>
<iq6dnWLRzMfSoYX8nZ2dnUU7-QfNnZ2d@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: <iq6dnWLRzMfSoYX8nZ2dnUU7-QfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 190
Message-ID: <edXRI.972$SX.76@fx03.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: Sat, 14 Aug 2021 18:12:25 -0400
X-Received-Bytes: 9610
 by: Richard Damon - Sat, 14 Aug 2021 22:12 UTC

On 8/14/21 5:57 PM, olcott wrote:
> On 8/14/2021 4:48 PM, Richard Damon wrote:
>> On 8/14/21 5:09 PM, olcott wrote:
>>> On 8/14/2021 4:06 PM, Richard Damon wrote:
>>>> On 8/14/21 4:52 PM, olcott wrote:
>>>>> On 8/14/2021 3:39 PM, Richard Damon wrote:
>>>>>> On 8/14/21 2:33 PM, olcott wrote:
>>>>>>> On 8/14/2021 12:10 PM, Richard Damon wrote:
>>>>>>>> On 8/14/21 12:16 PM, 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is the point where you use of English is incorrect, and you
>>>>>>>> need to
>>>>>>>> restudy English so you understand what you are saying.
>>>>>>>>
>>>>>>>> *Inputs* are NEVER *Computations* in and of themselves, but are
>>>>>>>> merely
>>>>>>>> the string representations of the ACTUAL Computations.
>>>>>>>>
>>>>>>>> As such, 'inputs' don't halt or be non-halting, only the machines
>>>>>>>> they
>>>>>>>> represent.
>>>>>>> The input "description of an arbitrary computer program" is the
>>>>>>> basis
>>>>>>> for the halt status decision.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The input is what the program uses to make its decision, the right
>>>>>> answer is what the actual machine does.
>>>>>>
>>>>>
>>>>> Because the input to H(P,P) is at a different point int the execution
>>>>> trace than the P of int main(){ P(P); } it is a different computation
>>>>> having different behavior than the input to H(P,P).
>>>>
>>>> What 'point'. The question is will the computation finish or not.
>>>>
>>> When trying to prove that I do not own a white cat, proof that I do not
>>> own a black dog does not count.
>>>
>>> The two distinctly different computations have different halting
>>> behavior.
>>>
>>
>> Right, so we want to know what the Turing Machine that the input is a
>> representation of does, i.e., what does the ACTUAL machine H^(<H^>)
>> does, which is Halt.
>>
>
> That you can't even keep track of which code is being discussed is why I
>  hardly ever talk to you.
>
>> It doesn't matter that the partial simulation that H did of the machine
>> never reached its final halting state because H stop simulating it
>> before it gets there.
>>
>
> [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
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never stops running thus conclusively proving that
> when H decides this input never halts it is correct.

If you H nevers stops running, then it never answers.

Remember, H MUST have a defined algorithm. You keep on changing what
your H is, which means the problem keeps reseting. Every time you change
H, you change H^ so ANYTHING you have determened about the pervious H^
needs to be thown out.

If H doesn't abort the simulation, then H(H^,H^) will never return, and
thus H fails. ANYTIME you propose such an H, that will be the result,

If H DOES abort the simulation, so it can answer H(H^,H^) then it must
take into account that the copy of the algorithm of H inside H^ will
also abort its simulation. It will be a fact that the outer simulation
will abort its simulation before the simulated simulation will reach its
final halting state, because the outer simulator is farther in its
simulation than the inner simulator. That doesn't mean that the inner
simulation is non-halting, just that you can't get there with a simple
fixed termination rule.

You logic is just unsound. A simulator that doesn't halt until condition
x is not a pure simulator, PERIOD. Basic DEFINITION.

>
> The other reason is that I have to explain things to you hundreds of
> times before you bother to ever notice what I actually said.

Maybe if you look at the question you are actually answering you will
give real answers. I do see what you are saying, and the problem is you
fill your arguement with false statements which you don't seem to recognize.


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?

<878s13y6s1.fsf@bsb.me.uk>

 copy mid

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

 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: Sat, 14 Aug 2021 23:56:46 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <878s13y6s1.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="b8e7185cffc9369e6eef8297be9be5a9";
logging-data="12405"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19uM6GLYqDNglDZ+dLfcmfFGV9OxLNWqGQ="
Cancel-Lock: sha1:d5gs80PBgj2qXcd96X7Qa3b1oJw=
sha1:LriQ8MUTnh/DEPWdfGhw7WL3om0=
X-BSB-Auth: 1.f139b750005c3ae00d09.20210814235646BST.878s13y6s1.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 14 Aug 2021 22:56 UTC

Jeff Barnett <jbb@notatt.com> writes:

> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The P(P) of main() only halts because...
>> As you say, P(P) halts.
>>
>>> *Halting computation* is any computation that eventually reaches its
>>> own final state. This criteria divides computations that halt from
>>> those that merely stop running because their simulation was aborted.
>> No. There is no "special kind of halting". The computation M(I) either
>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>> does not halt.
>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>> Why are you still hiding H? Is it because you have still not figured
>> out how to nest a call to the simulator you are using? Fortunately "we"
>> (i.e. everyone but you) can see that H is wrong without even seeing the
>> code. Who is included in the "we" of the subject line? Have you found
>> someone else who thinks that false is the correct return from a partial
>> halt decider called with arguments that represent a halting computation?
>
> I have questions about the PO simulator I hope someone can answer. It
> perhaps concerns memory mapping: First - is every instance of a use at
> different levels in its own address space? Second - if not, is there
> any way to know when an address is reported, which simulator instance
> is being reported on? When the dumb bunny (PO expression) notes that
> the same address is reached a second time without a conditional branch
> being executed, is there any assurance that the addresses are noted
> from the same instance of the simulation? And finally, how can one
> determine if it's the same address twice without doing some sort of
> compare and branch? Thanks in advance for any sort of enlightenment.

You won't get a straight answer from PO, but I don't think there is any
nested simulation happening at all. PO "knows" it's that same a
recursion, so he just has recursive calls traced from "outside". I may
be wrong, of course, but this is one reason I think H is being kept
hidden -- it does not do what says.

--
Ben.

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

<JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 18:10:48 -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> <878s13y6s1.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 18:10:46 -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: <878s13y6s1.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
Lines: 74
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Zdjiq6Rx1FRJWzvbix1QZionqaMao87HZKCRvKaWe/mTCyOj1sZWJF4UljEmjqe3AlaY1Wi9DcDVk6a!YBxNpFUq66J6ZHIFF0o0jtZoEOefFUQf2B6bC3iRdvpmOOWtrh+9FBAsKBuEhB/HCknw8AMsVA==
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: 4754
 by: olcott - Sat, 14 Aug 2021 23:10 UTC

On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
> Jeff Barnett <jbb@notatt.com> writes:
>
>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The P(P) of main() only halts because...
>>> As you say, P(P) halts.
>>>
>>>> *Halting computation* is any computation that eventually reaches its
>>>> own final state. This criteria divides computations that halt from
>>>> those that merely stop running because their simulation was aborted.
>>> No. There is no "special kind of halting". The computation M(I) either
>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>> does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>> Why are you still hiding H? Is it because you have still not figured
>>> out how to nest a call to the simulator you are using? Fortunately "we"
>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>> code. Who is included in the "we" of the subject line? Have you found
>>> someone else who thinks that false is the correct return from a partial
>>> halt decider called with arguments that represent a halting computation?
>>
>> I have questions about the PO simulator I hope someone can answer. It
>> perhaps concerns memory mapping: First - is every instance of a use at
>> different levels in its own address space? Second - if not, is there
>> any way to know when an address is reported, which simulator instance
>> is being reported on? When the dumb bunny (PO expression) notes that
>> the same address is reached a second time without a conditional branch
>> being executed, is there any assurance that the addresses are noted
>> from the same instance of the simulation? And finally, how can one
>> determine if it's the same address twice without doing some sort of
>> compare and branch? Thanks in advance for any sort of enlightenment.
>
> You won't get a straight answer from PO, but I don't think there is any
> nested simulation happening at all. PO "knows" it's that same a
> recursion,

Because context switching is required so that one function can resume
simulating the middle of another function with DebugStep() and then
return back to the same point in the middle of the current function this
requires that each context have its own set of registers.

This makes using ordinary recursion for nested x86 emulation infeasible
because one process would clobber the stack of the other processes.

The stack registers of ESP and EBP are included in this set of saved and
restored registers. So we also have to have separate stack space or one
process would clobber the stack space of the other process.

Since no one here could begin to understand even seven lines of simple
x86 code, I did not bring up these other details to avoid confusing my
audience much more than they were already confused.

Not being able to understand seven simple lines of x86 code in many
months is a horribly terrible degree of comprehension.

> so he just has recursive calls traced from "outside". I may
> be wrong, of course, but this is one reason I think H is being kept
> hidden -- it does not do what says.
>

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

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

 copy mid

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

 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: Sun, 15 Aug 2021 00:25:33 +0100
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <87wnonwqvm.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk>
<qomdnZRgV6jDrYX8nZ2dnUU7-afNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="b8e7185cffc9369e6eef8297be9be5a9";
logging-data="20877"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187M6fgT/Tw04qhMjpac5q4hayp8WsX+rc="
Cancel-Lock: sha1:mf0+w3UIJ1CKHIXgoEe/SzZNW9o=
sha1:NOhScsuRupj7lyzdkdctevgcsuA=
X-BSB-Auth: 1.79a3631b35306a9cfaf6.20210815002533BST.87wnonwqvm.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 14 Aug 2021 23:25 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/14/2021 3:43 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The P(P) of main() only halts because...
>> As you say, P(P) halts.
>>
>>> *Halting computation* is any computation that eventually reaches its
>>> own final state. This criteria divides computations that halt from
>>> those that merely stop running because their simulation was aborted.
>>
>> No. There is no "special kind of halting". The computation M(I) either
>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>> does not halt.
>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>
>
> Because the input to H(P,P) is at a different point in the execution
> trace than the P of int main(){ P(P); } it is a different computation
> having different behavior than the input to H(P,P).

Why should anyone care about an H such that H(M,I) does not give the
halting of M(I)?

You once claimed to have something that the world considered impossible.
Having spent years walking back that claim, you now have something no
one cares about because it's so obviously possible.

>> Why are you still hiding H? Is it because you have still not figured
>> out how to nest a call to the simulator you are using?
>
> That part alone took me three months after all the rest of the x86utm
> operating system was complete.

You should have posted the "actual Turing machine" that was "exactly and
precisely as in Linz" which you had "fully encoded" more than two and a
half years go. Ah, but you never did have such a thing, so the last two
and half years have just been all about the smoke and mirrors needed to
make people forget what you originally claimed.

Care to remind us of the claim you used to hook people in? It was not
"I now have an H and H^ pair of actual Turing machines, quite unlike
Linz's H and H^, because H rejects <H^><H^> even though H^(H^) halts".
That would not have raised even a "huh?" in response.

> All they really need to know is that infinitely nested simulation has
> computationally equivalent halting behavior to infinite recursion.

P(P) halts so there is no infinitely nested simulation nor any infinite
recursion in that computation.

--
Ben.

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

<zjYRI.13727$fI7.7888@fx33.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx33.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>
<878s13y6s1.fsf@bsb.me.uk>
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: <878s13y6s1.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Lines: 95
Message-ID: <zjYRI.13727$fI7.7888@fx33.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: Sat, 14 Aug 2021 19:27:26 -0400
X-Received-Bytes: 5880
 by: Richard Damon - Sat, 14 Aug 2021 23:27 UTC

On 8/14/21 6:56 PM, Ben Bacarisse wrote:
> Jeff Barnett <jbb@notatt.com> writes:
>
>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The P(P) of main() only halts because...
>>> As you say, P(P) halts.
>>>
>>>> *Halting computation* is any computation that eventually reaches its
>>>> own final state. This criteria divides computations that halt from
>>>> those that merely stop running because their simulation was aborted.
>>> No. There is no "special kind of halting". The computation M(I) either
>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>> does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>> Why are you still hiding H? Is it because you have still not figured
>>> out how to nest a call to the simulator you are using? Fortunately "we"
>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>> code. Who is included in the "we" of the subject line? Have you found
>>> someone else who thinks that false is the correct return from a partial
>>> halt decider called with arguments that represent a halting computation?
>>
>> I have questions about the PO simulator I hope someone can answer. It
>> perhaps concerns memory mapping: First - is every instance of a use at
>> different levels in its own address space? Second - if not, is there
>> any way to know when an address is reported, which simulator instance
>> is being reported on? When the dumb bunny (PO expression) notes that
>> the same address is reached a second time without a conditional branch
>> being executed, is there any assurance that the addresses are noted
>> from the same instance of the simulation? And finally, how can one
>> determine if it's the same address twice without doing some sort of
>> compare and branch? Thanks in advance for any sort of enlightenment.
>
> You won't get a straight answer from PO, but I don't think there is any
> nested simulation happening at all. PO "knows" it's that same a
> recursion, so he just has recursive calls traced from "outside". I may
> be wrong, of course, but this is one reason I think H is being kept
> hidden -- it does not do what says.
>

He actually has leaked a fair amount about how the system works. H isn't
actually a simulator, but an 'API Entry' into the x86utm system that has
the real simulator, and calls into H as supposed to setup a new 'nested'
level of simulation.

It sounds like these nested simulations are given their own stacks and
'user' code isn't supposed to be able to store data anywhere but on the
stack, so that is supposed to be enough for a new environment, since he
erroneously puts everything inside one code segment. (This means that H
isn't a 'Universal' Halt Decider, as its input isn't an arbitrary machine.

This would be one reason you can't 'copy' H, is that H isn't really the
code but just an API (and if he allowed copying, his nesting detection
breaks).

One side effect of this is that I am not sure if his system can actually
really handle finitely but multi-level simulations as at least some of
the leaked implementations made H not really a computation as it used
static memory to communicate between H and the OS.

I also wonder if a computation built on P1 using H to decide on P2 which
used H to decide on P3 could return the answer from P3 to P2.

This structure could be used to solve the twins prime conjecture if the
Halt decider actually worked. P1 would ask P2 to find the highest twin
prime. If it is non-halting there is no highest twin prime.

P2 would iterate through the twin primes starting at say 3,5 and ask P3
to find the next one. If it find one, then it updates to that point and
uses it again to find the next highest. If P2 is at the highest, then P3
would be non-halting, and P2 would get the non-halting answer and could
tell P1 what is the highest twin prime.

P3 just takes its input and searches to find the next highest twin prime
from there. If there isn't one it will just be non-halting.

The problem is that just because P3 becomes non-halting isn't grounds to
call P1 or P2 non-halting, as P3 becoming non-halting is the halting
condition of P2. It is only if for every problem that P2 gives P3 that
it always finds an answer that P2 becomes non-halting, and P1 then knows
that the answer to the question is that there is no highest twin prime.
(P1 halts in all cases).

The slight problem is that his current definition of H doesn't seem to
allow the caller of H to get the 'answer' from the machine it is
running, so you have to do everything twice, first determine that it
WOULD halt, then just call it to get the answer.

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

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

 copy mid

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

 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: Sun, 15 Aug 2021 00:30:59 +0100
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <87r1evwqmk.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<878s13y6s1.fsf@bsb.me.uk>
<JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="b8e7185cffc9369e6eef8297be9be5a9";
logging-data="20877"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+OUKG9aKmLFtSkRslz5R+QnPEwoT0ljp8="
Cancel-Lock: sha1:KhGt6ohYy+5iEHNKKKz76X/aKyo=
sha1:nJcGlX8IMJFFsi9zG3eEEds2dec=
X-BSB-Auth: 1.1af6c6b1d991af76b33a.20210815003059BST.87r1evwqmk.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 14 Aug 2021 23:30 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>> Jeff Barnett <jbb@notatt.com> writes:
>>
>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The P(P) of main() only halts because...
>>>> As you say, P(P) halts.
>>>>
>>>>> *Halting computation* is any computation that eventually reaches its
>>>>> own final state. This criteria divides computations that halt from
>>>>> those that merely stop running because their simulation was aborted.
>>>>
>>>> No. There is no "special kind of halting". The computation M(I) either
>>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>>> does not halt.
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>
>>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>>> Why are you still hiding H? Is it because you have still not figured
>>>> out how to nest a call to the simulator you are using? Fortunately "we"
>>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>>> code. Who is included in the "we" of the subject line? Have you found
>>>> someone else who thinks that false is the correct return from a partial
>>>> halt decider called with arguments that represent a halting computation?
>>>
>>> I have questions about the PO simulator I hope someone can answer. It
>>> perhaps concerns memory mapping: First - is every instance of a use at
>>> different levels in its own address space? Second - if not, is there
>>> any way to know when an address is reported, which simulator instance
>>> is being reported on? When the dumb bunny (PO expression) notes that
>>> the same address is reached a second time without a conditional branch
>>> being executed, is there any assurance that the addresses are noted
>>> from the same instance of the simulation? And finally, how can one
>>> determine if it's the same address twice without doing some sort of
>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>
>> You won't get a straight answer from PO, but I don't think there is any
>> nested simulation happening at all. PO "knows" it's that same a
>> recursion,
>
> Because context switching is required so that one function can resume
> simulating the middle of another function with DebugStep() and then
> return back to the same point in the middle of the current function
> this requires that each context have its own set of registers.
>
> This makes using ordinary recursion for nested x86 emulation
> infeasible because one process would clobber the stack of the other
> processes.

That's a "yes" isn't it? I thought so! No wonder you are hiding H.

--
Ben.

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

<sf9o6l$a6t$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jbb...@notatt.com (Jeff Barnett)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Sat, 14 Aug 2021 18:47:11 -0600
Organization: A noiseless patient Spider
Lines: 113
Message-ID: <sf9o6l$a6t$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<878s13y6s1.fsf@bsb.me.uk> <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 15 Aug 2021 00:47:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="49e1d2be8628775cdc3623dd27b35b90";
logging-data="10461"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19jt8kKUN0ovsbY2PFpIWnYwUpihwTWMfw="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:3y3vqdi7ELopUTm1veLulEuyN+s=
In-Reply-To: <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
Content-Language: en-US
 by: Jeff Barnett - Sun, 15 Aug 2021 00:47 UTC

On 8/14/2021 5:10 PM, olcott wrote:
> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>> Jeff Barnett <jbb@notatt.com> writes:
>>
>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The P(P) of main() only halts because...
>>>> As you say, P(P) halts.
>>>>
>>>>> *Halting computation* is any computation that eventually reaches its
>>>>> own final state. This criteria divides computations that halt from
>>>>> those that merely stop running because their simulation was aborted.
>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>> either
>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>> does not halt.
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>> Why are you still hiding H?  Is it because you have still not figured
>>>> out how to nest a call to the simulator you are using?  Fortunately
>>>> "we"
>>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>>> code.  Who is included in the "we" of the subject line?  Have you found
>>>> someone else who thinks that false is the correct return from a partial
>>>> halt decider called with arguments that represent a halting
>>>> computation?
>>>
>>> I have questions about the PO simulator I hope someone can answer. It
>>> perhaps concerns memory mapping: First - is every instance of a use at
>>> different levels in its own address space? Second - if not, is there
>>> any way to know when an address is reported, which simulator instance
>>> is being reported on? When the dumb bunny (PO expression) notes that
>>> the same address is reached a second time without a conditional branch
>>> being executed, is there any assurance that the addresses are noted
>>> from the same instance of the simulation? And finally, how can one
>>> determine if it's the same address twice without doing some sort of
>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>
>> You won't get a straight answer from PO, but I don't think there is any
>> nested simulation happening at all.  PO "knows" it's that same a
>> recursion,
>
> Because context switching is required so that one function can resume
> simulating the middle of another function with DebugStep() and then
> return back to the same point in the middle of the current function this
> requires that each context have its own set of registers.
>
> This makes using ordinary recursion for nested x86 emulation infeasible
> because one process would clobber the stack of the other processes.

So we have clearly established that you do not do how to code, program,
or design software. Same for mathematics and common sense. Instead of
your incessant nasty criticism of others' software prowess, lets you
concentrate on your own inadequacies.

I think that the quality of your software is on a par with your
inability to properly describe it. I, and most of the others here,
believe that your code quality is so low that it would cause you
embarrassment (humiliation?) to expose it. All the bravado in the world
will not remove the stench of those miswritten and totally misdescribed
poems you tout.

I'm sure this is on track: remember that you once posted your worthless
patent and some description of the code you wrote. It was laughable; on
a par with this mess. I think you decided to never make the mistake of
allowing someone else to see one of your beauties again lest you also
expose your disabilities.

Is it your illness that so side tracks you into this nonsense? If so
take your meds and seek help. We are all rooting for you.

> The stack registers of ESP and EBP are included in this set of saved and
> restored registers. So we also have to have separate stack space or one
> process would clobber the stack space of the other process.
>
> Since no one here could begin to understand even seven lines of simple
> x86 code, I did not bring up these other details to avoid confusing my
> audience much more than they were already confused.
>
> Not being able to understand seven simple lines of x86 code in many
> months is a horribly terrible degree of comprehension.
>
>> so he just has recursive calls traced from "outside".  I may
>> be wrong, of course, but this is one reason I think H is being kept
>> hidden -- it does not do what says.--
Jeff Barnett

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

<Lq_RI.3641$Y%.3193@fx29.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!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!fx29.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>
<878s13y6s1.fsf@bsb.me.uk> <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@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: <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 106
Message-ID: <Lq_RI.3641$Y%.3193@fx29.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: Sat, 14 Aug 2021 21:51:38 -0400
X-Received-Bytes: 5944
 by: Richard Damon - Sun, 15 Aug 2021 01:51 UTC

On 8/14/21 7:10 PM, olcott wrote:
> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>> Jeff Barnett <jbb@notatt.com> writes:
>>
>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The P(P) of main() only halts because...
>>>> As you say, P(P) halts.
>>>>
>>>>> *Halting computation* is any computation that eventually reaches its
>>>>> own final state. This criteria divides computations that halt from
>>>>> those that merely stop running because their simulation was aborted.
>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>> either
>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>> does not halt.
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>> Why are you still hiding H?  Is it because you have still not figured
>>>> out how to nest a call to the simulator you are using?  Fortunately
>>>> "we"
>>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>>> code.  Who is included in the "we" of the subject line?  Have you found
>>>> someone else who thinks that false is the correct return from a partial
>>>> halt decider called with arguments that represent a halting
>>>> computation?
>>>
>>> I have questions about the PO simulator I hope someone can answer. It
>>> perhaps concerns memory mapping: First - is every instance of a use at
>>> different levels in its own address space? Second - if not, is there
>>> any way to know when an address is reported, which simulator instance
>>> is being reported on? When the dumb bunny (PO expression) notes that
>>> the same address is reached a second time without a conditional branch
>>> being executed, is there any assurance that the addresses are noted
>>> from the same instance of the simulation? And finally, how can one
>>> determine if it's the same address twice without doing some sort of
>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>
>> You won't get a straight answer from PO, but I don't think there is any
>> nested simulation happening at all.  PO "knows" it's that same a
>> recursion,
>
> Because context switching is required so that one function can resume
> simulating the middle of another function with DebugStep() and then
> return back to the same point in the middle of the current function this
> requires that each context have its own set of registers.

I suppose this just shows that the 'simulator' isn't really a simulator
(or you are misusing the term context switch). A real simulator like
this would have DebugStep taking an argument for a machine configuration
which has the current register and memory contents, and takes the PC
address from the register structure, then fetches that instruction from
the memory contents array, simulates what it is doing, the writes back
the results. This is all just normal user mode programming.
>
> This makes using ordinary recursion for nested x86 emulation infeasible
> because one process would clobber the stack of the other processes.

This makes it sounds more like you are 'simulating' by using something
like v86 mode.

>
> The stack registers of ESP and EBP are included in this set of saved and
> restored registers. So we also have to have separate stack space or one
> process would clobber the stack space of the other process.

As I have said, you REALLY need fully seperate memory spaces, but that
cheat isn't a big enough issue to need to push it to hard. After all,
even with this, you STILL have to get the wrong answer, as H^ can still
act contrary to H so Hhas no answer it can give to be right, so H is
still wrong.

It just gives you more wiggle room to try to hide non-computations to
try to cheat the problem (like you 'global' decider).

>
> Since no one here could begin to understand even seven lines of simple
> x86 code, I did not bring up these other details to avoid confusing my
> audience much more than they were already confused.

Maybe you underestimate what people can understand. I think we all fully
understand what those instructions will do, and the fact that your trace
doesn't show it doing that, since it doesn't process the call
instruction right.

>
> Not being able to understand seven simple lines of x86 code in many
> months is a horribly terrible degree of comprehension.

Yes, you do seem to have a horrible comprehension. You still don't
understand what a CALL instruction is supposed to do.

>
>> so he just has recursive calls traced from "outside".  I may
>> be wrong, of course, but this is one reason I think H is being kept
>> hidden -- it does not do what says.
>>
>
>

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

<sfa3u2$pq1$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jbb...@notatt.com (Jeff Barnett)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Sat, 14 Aug 2021 22:07:23 -0600
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <sfa3u2$pq1$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<878s13y6s1.fsf@bsb.me.uk> <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 15 Aug 2021 04:07:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="49e1d2be8628775cdc3623dd27b35b90";
logging-data="26433"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Ohi57b0HqT0w8G0vySxdCGWQuRiBbaek="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:MIYDee1M5eS0HrVWf41E+sFhoVk=
In-Reply-To: <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
Content-Language: en-US
 by: Jeff Barnett - Sun, 15 Aug 2021 04:07 UTC

On 8/14/2021 5:10 PM, olcott wrote:
> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>> Jeff Barnett <jbb@notatt.com> writes:
>>
>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The P(P) of main() only halts because...
>>>> As you say, P(P) halts.
>>>>
>>>>> *Halting computation* is any computation that eventually reaches its
>>>>> own final state. This criteria divides computations that halt from
>>>>> those that merely stop running because their simulation was aborted.
>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>> either
>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>> does not halt.
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>> Why are you still hiding H?  Is it because you have still not figured
>>>> out how to nest a call to the simulator you are using?  Fortunately
>>>> "we"
>>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>>> code.  Who is included in the "we" of the subject line?  Have you found
>>>> someone else who thinks that false is the correct return from a partial
>>>> halt decider called with arguments that represent a halting
>>>> computation?
>>>
>>> I have questions about the PO simulator I hope someone can answer. It
>>> perhaps concerns memory mapping: First - is every instance of a use at
>>> different levels in its own address space? Second - if not, is there
>>> any way to know when an address is reported, which simulator instance
>>> is being reported on? When the dumb bunny (PO expression) notes that
>>> the same address is reached a second time without a conditional branch
>>> being executed, is there any assurance that the addresses are noted
>>> from the same instance of the simulation? And finally, how can one
>>> determine if it's the same address twice without doing some sort of
>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>
>> You won't get a straight answer from PO, but I don't think there is any
>> nested simulation happening at all.  PO "knows" it's that same a
>> recursion,
>
> Because context switching is required so that one function can resume
> simulating the middle of another function with DebugStep() and then
> return back to the same point in the middle of the current function this
> requires that each context have its own set of registers.
>
> This makes using ordinary recursion for nested x86 emulation infeasible
> because one process would clobber the stack of the other processes.
>
> The stack registers of ESP and EBP are included in this set of saved and
> restored registers. So we also have to have separate stack space or one
> process would clobber the stack space of the other process.
>
> Since no one here could begin to understand even seven lines of simple
> x86 code, I did not bring up these other details to avoid confusing my
> audience much more than they were already confused.

Our comprehension is just fine; that's not the problem here. The actual
issue is that you neither understand nor are capable of learning about
address mapping (that little thigamajig the page hardware implements).
Context switches may need to save and restore registers, etc. Those are
the kinds of things an OS does from day one of its inception. I think
you need to return to high School (see your other thread) and ask a
teacher to hold your hand and bring you up to date; at least to the mid
1960s. I know that would be rushing things for you. But tiny steps
first. Maybe you'll understand these things better in a few years. Hell,
while you are at it you might retake some of those pesky HS math classes
that so confused you.

Remember: ask for help that you need; follow instructions; take your
meds. Best of luck.

BTW At your age, whatever it is, you might need special recommendations
to reenter high school. I'm sure all of us here would be willing to
write a letter of recommendation that will state that remedial high
school classes will be perfect for you. Perhaps this time around, you
will be able to pick up all those tidbits that went over your head the
first time.

> Not being able to understand seven simple lines of x86 code in many
> months is a horribly terrible degree of comprehension.
>
>> so he just has recursive calls traced from "outside".  I may
>> be wrong, of course, but this is one reason I think H is being kept
>> hidden -- it does not do what says.--
Jeff Barnett

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

<X7CdnT1zg-76B4X8nZ2dnUU7-KvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr3.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: Sat, 14 Aug 2021 23:39:03 -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> <878s13y6s1.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 23:39:03 -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: <878s13y6s1.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <X7CdnT1zg-76B4X8nZ2dnUU7-KvNnZ2d@giganews.com>
Lines: 66
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FqP95PxaJpWVO3X6H+p8/Zlob7yIFxRIa2gApOkmCvBb3FVvztryC0WN7DitH1HYy86KKKGt2crLSCm!6ZKDfXKhexRjk6dkTSFW6VbYzIzfcmydZxlFSPnzMvFwMcUzpzi4e6ZF9bLVw21zR7Kd0uEvCz+w!leA=
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: 4358
 by: olcott - Sun, 15 Aug 2021 04:39 UTC

On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
> Jeff Barnett <jbb@notatt.com> writes:
>
>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The P(P) of main() only halts because...
>>> As you say, P(P) halts.
>>>
>>>> *Halting computation* is any computation that eventually reaches its
>>>> own final state. This criteria divides computations that halt from
>>>> those that merely stop running because their simulation was aborted.
>>> No. There is no "special kind of halting". The computation M(I) either
>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>> does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>> Why are you still hiding H? Is it because you have still not figured
>>> out how to nest a call to the simulator you are using? Fortunately "we"
>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>> code. Who is included in the "we" of the subject line? Have you found
>>> someone else who thinks that false is the correct return from a partial
>>> halt decider called with arguments that represent a halting computation?
>>
>> I have questions about the PO simulator I hope someone can answer. It
>> perhaps concerns memory mapping: First - is every instance of a use at
>> different levels in its own address space? Second - if not, is there
>> any way to know when an address is reported, which simulator instance
>> is being reported on? When the dumb bunny (PO expression) notes that
>> the same address is reached a second time without a conditional branch
>> being executed, is there any assurance that the addresses are noted
>> from the same instance of the simulation? And finally, how can one
>> determine if it's the same address twice without doing some sort of
>> compare and branch? Thanks in advance for any sort of enlightenment.
>
> You won't get a straight answer from PO, but I don't think there is any
> nested simulation happening at all. PO "knows" it's that same a
> recursion, so he just has recursive calls traced from "outside". I may

No this is not possible. There is no possible way to use ordinary
recursion to implement nested x86 emulation without memory corruption of
the stack. I explained all of the technical details of context
switching: Here is a link that does a better job:

https://en.wikipedia.org/wiki/Context_switch

Each virtual machine has its own registers, stack and RAM. Once the
virtual machine environment is set up, allocating the stack and RAM and
other house keeping functions a context switch only requires saving and
restoring all the machine registers.

> be wrong, of course, but this is one reason I think H is being kept
> hidden -- it does not do what says.
>

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

<fOOdnYos7-IxAYX8nZ2dnUU7-cHNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 Aug 2021 23:48:44 -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> <878s13y6s1.fsf@bsb.me.uk> <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com> <sfa3u2$pq1$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 14 Aug 2021 23:48:45 -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: <sfa3u2$pq1$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <fOOdnYos7-IxAYX8nZ2dnUU7-cHNnZ2d@giganews.com>
Lines: 113
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-3AV+JJwg/1ZBKLleRZVF1Tbag6ZKJjdXbyHYTu8gxzOCyfzR9ke+kUxXiOCfOKPDJYfECF91jaDUbhb!+hyeKwYPVsyVpTQUpgB9RdmL1+nTE0TLpTH+LKj0Ij5wWCbdPDR1r5JiHz4+7FyjsqPwU0gTnxoy!JQA=
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: 6764
 by: olcott - Sun, 15 Aug 2021 04:48 UTC

On 8/14/2021 11:07 PM, Jeff Barnett wrote:
> On 8/14/2021 5:10 PM, olcott wrote:
>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>> Jeff Barnett <jbb@notatt.com> writes:
>>>
>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The P(P) of main() only halts because...
>>>>> As you say, P(P) halts.
>>>>>
>>>>>> *Halting computation* is any computation that eventually reaches its
>>>>>> own final state. This criteria divides computations that halt from
>>>>>> those that merely stop running because their simulation was aborted.
>>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>>> either
>>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>>> does not halt.
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>     if (H(x, x))
>>>>>>       HERE: goto HERE;
>>>>>> }
>>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>>> Why are you still hiding H?  Is it because you have still not figured
>>>>> out how to nest a call to the simulator you are using?  Fortunately
>>>>> "we"
>>>>> (i.e. everyone but you) can see that H is wrong without even seeing
>>>>> the
>>>>> code.  Who is included in the "we" of the subject line?  Have you
>>>>> found
>>>>> someone else who thinks that false is the correct return from a
>>>>> partial
>>>>> halt decider called with arguments that represent a halting
>>>>> computation?
>>>>
>>>> I have questions about the PO simulator I hope someone can answer. It
>>>> perhaps concerns memory mapping: First - is every instance of a use at
>>>> different levels in its own address space? Second - if not, is there
>>>> any way to know when an address is reported, which simulator instance
>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>> the same address is reached a second time without a conditional branch
>>>> being executed, is there any assurance that the addresses are noted
>>>> from the same instance of the simulation? And finally, how can one
>>>> determine if it's the same address twice without doing some sort of
>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>
>>> You won't get a straight answer from PO, but I don't think there is any
>>> nested simulation happening at all.  PO "knows" it's that same a
>>> recursion,
>>
>> Because context switching is required so that one function can resume
>> simulating the middle of another function with DebugStep() and then
>> return back to the same point in the middle of the current function
>> this requires that each context have its own set of registers.
>>
>> This makes using ordinary recursion for nested x86 emulation
>> infeasible because one process would clobber the stack of the other
>> processes.
>>
>> The stack registers of ESP and EBP are included in this set of saved
>> and restored registers. So we also have to have separate stack space
>> or one process would clobber the stack space of the other process.
>>
>> Since no one here could begin to understand even seven lines of simple
>> x86 code, I did not bring up these other details to avoid confusing my
>> audience much more than they were already confused.
>
> Our comprehension is just fine; that's not the problem here. The actual
> issue is that you neither understand nor are capable of learning about
> address mapping (that little thigamajig the page hardware implements).

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.

> Context switches may need to save and restore registers, etc. Those are
> the kinds of things an OS does from day one of its inception. I think
> you need to return to high School (see your other thread) and ask a
> teacher to hold your hand and bring you up to date; at least to the mid
> 1960s. I know that would be rushing things for you. But tiny steps
> first. Maybe you'll understand these things better in a few years. Hell,
> while you are at it you might retake some of those pesky HS math classes
> that so confused you.
>
> Remember: ask for help that you need; follow instructions; take your
> meds. Best of luck.
>
> BTW At your age, whatever it is, you might need special recommendations
> to reenter high school. I'm sure all of us here would be willing to
> write a letter of recommendation that will state that remedial high
> school classes will be perfect for you. Perhaps this time around, you
> will be able to pick up all those tidbits that went over your head the
> first time.
>
>> Not being able to understand seven simple lines of x86 code in many
>> months is a horribly terrible degree of comprehension.
>>
>>> so he just has recursive calls traced from "outside".  I may
>>> be wrong, of course, but this is one reason I think H is being kept
>>> hidden -- it does not do what says.--
> Jeff Barnett
>

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

<d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a37:b686:: with SMTP id g128mr10397951qkf.68.1629013810453;
Sun, 15 Aug 2021 00:50:10 -0700 (PDT)
X-Received: by 2002:a25:420b:: with SMTP id p11mr13783578yba.377.1629013810163;
Sun, 15 Aug 2021 00:50:10 -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: Sun, 15 Aug 2021 00:50:09 -0700 (PDT)
In-Reply-To: <v8OdnTdARYH-l4X8nZ2dnUU7-X2dnZ2d@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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@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: Sun, 15 Aug 2021 07:50:10 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: wij - Sun, 15 Aug 2021 07:50 UTC

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

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

What does your bible say about a liar? Does it matter? Surely, it does matter
if it applies to others, not you (you can restate it in your flavor).
Then, what else evil you cannot do, none.

子曰:人而無信不知其可
Confucius says: If a man does not keep his word, what is he good for?

> >>>>> If the direct invocation of P(P) is not relevant to the halting problem, then
> >>>>> H can do whatever you like, therefore, meaningless if not garbage.
> >>>>>
> >>>> The halting problem is only concerned with an at least partial halt
> >>>> decider correctly deciding whether or not its input halts, thus it can
> >>>> do whatever its wants as long as it does decide the correct halt status
> >>>> of its input.
> >>>>
> >>>
> >>> int H2(Prog P) {
> >>> return 0;
> >>> }
> >>> What is the difference of your H with H2?
> >>> H2 can also correctly (at least partial) answer the halting problem, and can
> >>> be verified.
> >>>
> >> My H has intelligence and can be verified to derive a halt status that
> >> corresponds to every halting computation and can be verified to derive a
> >> halt status that corresponds to that halt status of every input that it
> >> determines never halts.
> >>
> >> H is always correct for all:
> >> (a) halting computations.
> >> (b) computations that it decides never halt.
> >>>> In every configuration H does correctly decide that its input (P,P)
> >>>> never halts. This can be verified beyond all possible doubt by the x86
> >>>> execution trace of the simulation of P(P) shown below.
> >>>>>> The P(P) of main() only halts because H(P,P) correctly decides that its
> >>>>>> input never halts. This cause-and-effect relationship between the
> >>>>>> simulated P and the executed P proves that the simulated P and the
> >>>>>> executed P are distinctly different computations.
> >>>>>>
> >>>>>> Because they are different computations the fact that the executed P
> >>>>>> halts does not contradict the fact that the simulated P never halts.
> >>>>>>
> >>>>>> While H remains in pure simulation mode simulating the input to H(P,P)
> >>>>>> this simulated input never halts thus conclusively proving that H
> >>>>>> decides this input correctly.
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> *Halting computation* is any computation that eventually reaches its own
> >>>>>> final state. This criteria divides computations that halt from those
> >>>>>> that merely stop running because their simulation was aborted.
> >>>>>>
> >>>>>> A Turing machine is said to halt whenever it reaches a configuration
> >>>>>> for which δ is not defined; this is possible because δ is a partial
> >>>>>> function. In fact, we will assume that no transitions are defined for
> >>>>>> any final state, so the Turing machine will halt whenever it enters a
> >>>>>> final state. (Linz:1990:234)
> >>>>>>
> >>>>>> // Simplified Linz Ĥ (Linz:1990:319)
> >>>>>> // Strachey(1965) CPL translated to C
> >>>>>> void P(u32 x)
> >>>>>> {
> >>>>>> if (H(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>> }
> >>>>>>
> >>>>>> _P()
> >>>>>> [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]
> >>>>>>
> >>>>>> _main()
> >>>>>> [00000c56](01) 55 push ebp
> >>>>>> [00000c57](02) 8bec mov ebp,esp
> >>>>>> [00000c59](05) 68360c0000 push 00000c36 // push P
> >>>>>> [00000c5e](05) 68360c0000 push 00000c36 // push P
> >>>>>> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
> >>>>>> [00000c68](03) 83c408 add esp,+08
> >>>>>> [00000c6b](01) 50 push eax
> >>>>>> [00000c6c](05) 6857030000 push 00000357
> >>>>>> [00000c71](05) e810f7ffff call 00000386
> >>>>>> [00000c76](03) 83c408 add esp,+08
> >>>>>> [00000c79](02) 33c0 xor eax,eax
> >>>>>> [00000c7b](01) 5d pop ebp
> >>>>>> [00000c7c](01) c3 ret
> >>>>>> Size in bytes:(0039) [00000c7c]
> >>>>>>
> >>>>>> machine stack stack machine assembly
> >>>>>> address address data code language
> >>>>>> ======== ======== ======== ========= =============
> >>>>>> [00000c56][0010172a][00000000] 55 push ebp
> >>>>>> [00000c57][0010172a][00000000] 8bec mov ebp,esp
> >>>>>> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
> >>>>>> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
> >>>>>> [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)
> >>>>>>
> >>>>>> We can see that the first seven lines of P repeat. P calls H(P,P) that
> >>>>>> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
> >>>>>> stops simulating its input. When H does stop simulating its input P
> >>>>>> never reaches its final state of [00000c50] therefore never halts even
> >>>>>> though it stops running.
> >>>>>>
> >>>>>> [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
> >>>>>>
> >>>>>> [00000c68][0010172a][00000000] 83c408 add esp,+08
> >>>>>> [00000c6b][00101726][00000000] 50 push eax
> >>>>>> [00000c6c][00101722][00000357] 6857030000 push 00000357
> >>>>>> [00000c71][00101722][00000357] e810f7ffff call 00000386
> >>>>>> Input_Halts = 0
> >>>>>> [00000c76][0010172a][00000000] 83c408 add esp,+08
> >>>>>> [00000c79][0010172a][00000000] 33c0 xor eax,eax
> >>>>>> [00000c7b][0010172e][00100000] 5d pop ebp
> >>>>>> [00000c7c][00101732][00000068] c3 ret
> >>>>>> Number_of_User_Instructions(27)
> >>>>>> Number of Instructions Executed(23721)
> >>>>>>
> >>>>>> *Strachey, C 1965* An impossible program The Computer Journal, Volume
> >>>>>> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
> >>>>>>
> >>>>>> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
> >>>>>> Lexington/Toronto: D. C. Heath and Company.
> >>>>>>
> >>>>>> --
> >>>>>> Copyright 2021 Pete Olcott
> >>>>>>
> >>>>>> "Great spirits have always encountered violent opposition from mediocre
> >>>>>> minds." Einstein
> >>>>
> >>>>
> >>>> --
> >>>> Copyright 2021 Pete Olcott
> >>>>
> >>>> "Great spirits have always encountered violent opposition from mediocre
> >>>> minds." Einstein
> >>
> >>
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> "Great spirits have always encountered violent opposition from mediocre
> >> minds." Einstein
>
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein


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?

<8a5e61e9-cea5-4447-8da6-688e30795ee2n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:5ad5:: with SMTP id d21mr9212772qtd.200.1629020360857;
Sun, 15 Aug 2021 02:39:20 -0700 (PDT)
X-Received: by 2002:a25:ce01:: with SMTP id x1mr12867549ybe.360.1629020360684;
Sun, 15 Aug 2021 02:39:20 -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: Sun, 15 Aug 2021 02:39:20 -0700 (PDT)
In-Reply-To: <X7CdnT1zg-76B4X8nZ2dnUU7-KvNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:c54:a512:8747:857e;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:c54:a512:8747:857e
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <878s13y6s1.fsf@bsb.me.uk>
<X7CdnT1zg-76B4X8nZ2dnUU7-KvNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8a5e61e9-cea5-4447-8da6-688e30795ee2n@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: Sun, 15 Aug 2021 09:39:20 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 72
 by: Malcolm McLean - Sun, 15 Aug 2021 09:39 UTC

On Sunday, 15 August 2021 at 05:39:10 UTC+1, olcott wrote:
> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
> > Jeff Barnett <j...@notatt.com> writes:
> >
> >> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> The P(P) of main() only halts because...
> >>> As you say, P(P) halts.
> >>>
> >>>> *Halting computation* is any computation that eventually reaches its
> >>>> own final state. This criteria divides computations that halt from
> >>>> those that merely stop running because their simulation was aborted.
> >>> No. There is no "special kind of halting". The computation M(I) either
> >>> halts or it does not. H(M, I) should be false if, and only if, M(I)
> >>> does not halt.
> >>>
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> }
> >>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
> >>> Why are you still hiding H? Is it because you have still not figured
> >>> out how to nest a call to the simulator you are using? Fortunately "we"
> >>> (i.e. everyone but you) can see that H is wrong without even seeing the
> >>> code. Who is included in the "we" of the subject line? Have you found
> >>> someone else who thinks that false is the correct return from a partial
> >>> halt decider called with arguments that represent a halting computation?
> >>
> >> I have questions about the PO simulator I hope someone can answer. It
> >> perhaps concerns memory mapping: First - is every instance of a use at
> >> different levels in its own address space? Second - if not, is there
> >> any way to know when an address is reported, which simulator instance
> >> is being reported on? When the dumb bunny (PO expression) notes that
> >> the same address is reached a second time without a conditional branch
> >> being executed, is there any assurance that the addresses are noted
> >> from the same instance of the simulation? And finally, how can one
> >> determine if it's the same address twice without doing some sort of
> >> compare and branch? Thanks in advance for any sort of enlightenment.
> >
> > You won't get a straight answer from PO, but I don't think there is any
> > nested simulation happening at all. PO "knows" it's that same a
> > recursion, so he just has recursive calls traced from "outside". I may
> No this is not possible. There is no possible way to use ordinary
> recursion to implement nested x86 emulation without memory corruption of
> the stack. I explained all of the technical details of context
> switching: Here is a link that does a better job:
>
> https://en.wikipedia.org/wiki/Context_switch
>
> Each virtual machine has its own registers, stack and RAM. Once the
> virtual machine environment is set up, allocating the stack and RAM and
> other house keeping functions a context switch only requires saving and
> restoring all the machine registers.
>
We can write a ZX81 emulator on a modern machine. A ZX81 has 4K ROM
and 1K RAM. So our first line can be a "virualmem = malloc(1024 * 5). We then
set up everything else in that memory space.
However the ZX81 emulator cannot emulate another ZX81, since it has only
1K RAM to play with, and the virtual machine needs 5K.
You'll get this problem whenever you try to allow nested emulation on a
random-access memory model machine.

Turing machines don't have this problem. Write a UTM, and a "Hello world"
program, and
UTM<Hello> with output "Hello world" on the tape.
UTM<UTM><Hello> will also output "Hello world" on the tape. You can stack up
as many UTMs as you like without any reprogramming. It might get very slow,
but it will eventually finish.

What you can do is treat memory allocation as a special function. Then you
can nest simulations.

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

<5-SdnZxO38vdhYT8nZ2dnUU7-cXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 08:36:00 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <878s13y6s1.fsf@bsb.me.uk> <X7CdnT1zg-76B4X8nZ2dnUU7-KvNnZ2d@giganews.com> <8a5e61e9-cea5-4447-8da6-688e30795ee2n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 08:36:00 -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: <8a5e61e9-cea5-4447-8da6-688e30795ee2n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <5-SdnZxO38vdhYT8nZ2dnUU7-cXNnZ2d@giganews.com>
Lines: 130
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-VTkvo1xv76Kk225ZX0nPVtJwKSMfphb5ddmZYIywfijfgKKghKf28vLl3O1vOgGSwxITKnXuEHjnhe+!324VjX9ju6X0XfH5otEH+SJ70vkJcGsAEn1F4C//SbxUaXjOlVslMmpIihviGlO8xDZX2aOsqmig!tE0=
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: 7725
X-Received-Bytes: 7946
 by: olcott - Sun, 15 Aug 2021 13:36 UTC

On 8/15/2021 4:39 AM, Malcolm McLean wrote:
> On Sunday, 15 August 2021 at 05:39:10 UTC+1, olcott wrote:
>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>> Jeff Barnett <j...@notatt.com> writes:
>>>
>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> The P(P) of main() only halts because...
>>>>> As you say, P(P) halts.
>>>>>
>>>>>> *Halting computation* is any computation that eventually reaches its
>>>>>> own final state. This criteria divides computations that halt from
>>>>>> those that merely stop running because their simulation was aborted.
>>>>> No. There is no "special kind of halting". The computation M(I) either
>>>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>>>> does not halt.
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>>>> Why are you still hiding H? Is it because you have still not figured
>>>>> out how to nest a call to the simulator you are using? Fortunately "we"
>>>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>>>> code. Who is included in the "we" of the subject line? Have you found
>>>>> someone else who thinks that false is the correct return from a partial
>>>>> halt decider called with arguments that represent a halting computation?
>>>>
>>>> I have questions about the PO simulator I hope someone can answer. It
>>>> perhaps concerns memory mapping: First - is every instance of a use at
>>>> different levels in its own address space? Second - if not, is there
>>>> any way to know when an address is reported, which simulator instance
>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>> the same address is reached a second time without a conditional branch
>>>> being executed, is there any assurance that the addresses are noted
>>>> from the same instance of the simulation? And finally, how can one
>>>> determine if it's the same address twice without doing some sort of
>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>
>>> You won't get a straight answer from PO, but I don't think there is any
>>> nested simulation happening at all. PO "knows" it's that same a
>>> recursion, so he just has recursive calls traced from "outside". I may
>> No this is not possible. There is no possible way to use ordinary
>> recursion to implement nested x86 emulation without memory corruption of
>> the stack. I explained all of the technical details of context
>> switching: Here is a link that does a better job:
>>
>> https://en.wikipedia.org/wiki/Context_switch
>>
>> Each virtual machine has its own registers, stack and RAM. Once the
>> virtual machine environment is set up, allocating the stack and RAM and
>> other house keeping functions a context switch only requires saving and
>> restoring all the machine registers.
>>
> We can write a ZX81 emulator on a modern machine. A ZX81 has 4K ROM
> and 1K RAM. So our first line can be a "virualmem = malloc(1024 * 5). We then
> set up everything else in that memory space.
> However the ZX81 emulator cannot emulate another ZX81, since it has only
> 1K RAM to play with, and the virtual machine needs 5K.
> You'll get this problem whenever you try to allow nested emulation on a
> random-access memory model machine.
>
> Turing machines don't have this problem. Write a UTM, and a "Hello world"
> program, and
> UTM<Hello> with output "Hello world" on the tape.
> UTM<UTM><Hello> will also output "Hello world" on the tape. You can stack up
> as many UTMs as you like without any reprogramming. It might get very slow,
> but it will eventually finish.
>
> What you can do is treat memory allocation as a special function. Then you
> can nest simulations.
>

Yes I do that.
It does not require knowing any of those details to see how totally
blatantly obvious it is that:

While H remains in pure simulation mode simulating the input to H(P,P)
this simulated input never stops running thus conclusively proving that
when H decides this input never halts it is correct.

_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]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[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

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

<BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 08:45:02 -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>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 08:45:02 -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: <d5bbf5b0-8f01-4370-9ac9-cf38e2e1d0c9n@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@giganews.com>
Lines: 277
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7pZvZ8Y08V9DoSKWDIrmjmXNZpffchNMrwmzTO82T3q70FBA0wh4y12gYBvVArjXAo/zFzwY3ldN9uE!dhHmdQ0oN0eYQ+WO7rQa2RueP2S9rdtiOnUKYQZfOPuZvWpV30qvtlF+FEJxZisFBNIUUJlOudpl!csM=
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: 14472
X-Received-Bytes: 14654
 by: olcott - Sun, 15 Aug 2021 13:45 UTC

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.

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

> What does your bible say about a liar? Does it matter? Surely, it does matter
> if it applies to others, not you (you can restate it in your flavor).
> Then, what else evil you cannot do, none.
>
> 子曰:人而無信不知其可
> Confucius says: If a man does not keep his word, what is he good for?
>
>>>>>>> If the direct invocation of P(P) is not relevant to the halting problem, then
>>>>>>> H can do whatever you like, therefore, meaningless if not garbage.
>>>>>>>
>>>>>> The halting problem is only concerned with an at least partial halt
>>>>>> decider correctly deciding whether or not its input halts, thus it can
>>>>>> do whatever its wants as long as it does decide the correct halt status
>>>>>> of its input.
>>>>>>
>>>>>
>>>>> int H2(Prog P) {
>>>>> return 0;
>>>>> }
>>>>> What is the difference of your H with H2?
>>>>> H2 can also correctly (at least partial) answer the halting problem, and can
>>>>> be verified.
>>>>>
>>>> My H has intelligence and can be verified to derive a halt status that
>>>> corresponds to every halting computation and can be verified to derive a
>>>> halt status that corresponds to that halt status of every input that it
>>>> determines never halts.
>>>>
>>>> H is always correct for all:
>>>> (a) halting computations.
>>>> (b) computations that it decides never halt.
>>>>>> In every configuration H does correctly decide that its input (P,P)
>>>>>> never halts. This can be verified beyond all possible doubt by the x86
>>>>>> execution trace of the simulation of P(P) shown below.
>>>>>>>> The P(P) of main() only halts because H(P,P) correctly decides that its
>>>>>>>> input never halts. This cause-and-effect relationship between the
>>>>>>>> simulated P and the executed P proves that the simulated P and the
>>>>>>>> executed P are distinctly different computations.
>>>>>>>>
>>>>>>>> Because they are different computations the fact that the executed P
>>>>>>>> halts does not contradict the fact that the simulated P never halts.
>>>>>>>>
>>>>>>>> While H remains in pure simulation mode simulating the input to H(P,P)
>>>>>>>> this simulated input never halts thus conclusively proving that H
>>>>>>>> decides this input correctly.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> *Halting computation* is any computation that eventually reaches its own
>>>>>>>> final state. This criteria divides computations that halt from those
>>>>>>>> that merely stop running because their simulation was aborted.
>>>>>>>>
>>>>>>>> A Turing machine is said to halt whenever it reaches a configuration
>>>>>>>> for which δ is not defined; this is possible because δ is a partial
>>>>>>>> function. In fact, we will assume that no transitions are defined for
>>>>>>>> any final state, so the Turing machine will halt whenever it enters a
>>>>>>>> final state. (Linz:1990:234)
>>>>>>>>
>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [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]
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [00000c56](01) 55 push ebp
>>>>>>>> [00000c57](02) 8bec mov ebp,esp
>>>>>>>> [00000c59](05) 68360c0000 push 00000c36 // push P
>>>>>>>> [00000c5e](05) 68360c0000 push 00000c36 // push P
>>>>>>>> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
>>>>>>>> [00000c68](03) 83c408 add esp,+08
>>>>>>>> [00000c6b](01) 50 push eax
>>>>>>>> [00000c6c](05) 6857030000 push 00000357
>>>>>>>> [00000c71](05) e810f7ffff call 00000386
>>>>>>>> [00000c76](03) 83c408 add esp,+08
>>>>>>>> [00000c79](02) 33c0 xor eax,eax
>>>>>>>> [00000c7b](01) 5d pop ebp
>>>>>>>> [00000c7c](01) c3 ret
>>>>>>>> Size in bytes:(0039) [00000c7c]
>>>>>>>>
>>>>>>>> machine stack stack machine assembly
>>>>>>>> address address data code language
>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>> [00000c56][0010172a][00000000] 55 push ebp
>>>>>>>> [00000c57][0010172a][00000000] 8bec mov ebp,esp
>>>>>>>> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
>>>>>>>> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
>>>>>>>> [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)
>>>>>>>>
>>>>>>>> We can see that the first seven lines of P repeat. P calls H(P,P) that
>>>>>>>> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
>>>>>>>> stops simulating its input. When H does stop simulating its input P
>>>>>>>> never reaches its final state of [00000c50] therefore never halts even
>>>>>>>> though it stops running.
>>>>>>>>
>>>>>>>> [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
>>>>>>>>
>>>>>>>> [00000c68][0010172a][00000000] 83c408 add esp,+08
>>>>>>>> [00000c6b][00101726][00000000] 50 push eax
>>>>>>>> [00000c6c][00101722][00000357] 6857030000 push 00000357
>>>>>>>> [00000c71][00101722][00000357] e810f7ffff call 00000386
>>>>>>>> Input_Halts = 0
>>>>>>>> [00000c76][0010172a][00000000] 83c408 add esp,+08
>>>>>>>> [00000c79][0010172a][00000000] 33c0 xor eax,eax
>>>>>>>> [00000c7b][0010172e][00100000] 5d pop ebp
>>>>>>>> [00000c7c][00101732][00000068] c3 ret
>>>>>>>> Number_of_User_Instructions(27)
>>>>>>>> Number of Instructions Executed(23721)
>>>>>>>>
>>>>>>>> *Strachey, C 1965* An impossible program The Computer Journal, Volume
>>>>>>>> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>>>>>>>>
>>>>>>>> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Copyright 2021 Pete Olcott
>>>>>>>>
>>>>>>>> "Great spirits have always encountered violent opposition from mediocre
>>>>>>>> minds." Einstein
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Copyright 2021 Pete Olcott
>>>>>>
>>>>>> "Great spirits have always encountered violent opposition from mediocre
>>>>>> minds." Einstein
>>>>
>>>>
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>>
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein


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?

<407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:5019:: with SMTP id jo25mr11740899qvb.23.1629038726881;
Sun, 15 Aug 2021 07:45:26 -0700 (PDT)
X-Received: by 2002:a25:404f:: with SMTP id n76mr15185680yba.494.1629038726654;
Sun, 15 Aug 2021 07:45:26 -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: Sun, 15 Aug 2021 07:45:26 -0700 (PDT)
In-Reply-To: <BZadnRNgE4LDh4T8nZ2dnUU7-fXNnZ2d@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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <407a228c-2484-4d5f-8e18-c0e47e9483adn@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: Sun, 15 Aug 2021 14:45:26 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: wij - Sun, 15 Aug 2021 14:45 UTC

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.

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

I hate to say that your programming level is very low because this has noting
to do with the HP proof. I think many others know x86 and C languages and
programming skills better than you do. No need to repeat posting the compiled
assembly code fragment and pretend you know better and others cannot see it..

> > What does your bible say about a liar? Does it matter? Surely, it does matter
> > if it applies to others, not you (you can restate it in your flavor).
> > Then, what else evil you cannot do, none.
> >
> > 子曰:人而無信不知其可
> > Confucius says: If a man does not keep his word, what is he good for?
> >
> >>>>>>> If the direct invocation of P(P) is not relevant to the halting problem, then
> >>>>>>> H can do whatever you like, therefore, meaningless if not garbage..
> >>>>>>>
> >>>>>> The halting problem is only concerned with an at least partial halt
> >>>>>> decider correctly deciding whether or not its input halts, thus it can
> >>>>>> do whatever its wants as long as it does decide the correct halt status
> >>>>>> of its input.
> >>>>>>
> >>>>>
> >>>>> int H2(Prog P) {
> >>>>> return 0;
> >>>>> }
> >>>>> What is the difference of your H with H2?
> >>>>> H2 can also correctly (at least partial) answer the halting problem, and can
> >>>>> be verified.
> >>>>>
> >>>> My H has intelligence and can be verified to derive a halt status that
> >>>> corresponds to every halting computation and can be verified to derive a
> >>>> halt status that corresponds to that halt status of every input that it
> >>>> determines never halts.
> >>>>
> >>>> H is always correct for all:
> >>>> (a) halting computations.
> >>>> (b) computations that it decides never halt.
> >>>>>> In every configuration H does correctly decide that its input (P,P)
> >>>>>> never halts. This can be verified beyond all possible doubt by the x86
> >>>>>> execution trace of the simulation of P(P) shown below.
> >>>>>>>> The P(P) of main() only halts because H(P,P) correctly decides that its
> >>>>>>>> input never halts. This cause-and-effect relationship between the
> >>>>>>>> simulated P and the executed P proves that the simulated P and the
> >>>>>>>> executed P are distinctly different computations.
> >>>>>>>>
> >>>>>>>> Because they are different computations the fact that the executed P
> >>>>>>>> halts does not contradict the fact that the simulated P never halts.
> >>>>>>>>
> >>>>>>>> While H remains in pure simulation mode simulating the input to H(P,P)
> >>>>>>>> this simulated input never halts thus conclusively proving that H
> >>>>>>>> decides this input correctly.
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> *Halting computation* is any computation that eventually reaches its own
> >>>>>>>> final state. This criteria divides computations that halt from those
> >>>>>>>> that merely stop running because their simulation was aborted.
> >>>>>>>>
> >>>>>>>> A Turing machine is said to halt whenever it reaches a configuration
> >>>>>>>> for which δ is not defined; this is possible because δ is a partial
> >>>>>>>> function. In fact, we will assume that no transitions are defined for
> >>>>>>>> any final state, so the Turing machine will halt whenever it enters a
> >>>>>>>> final state. (Linz:1990:234)
> >>>>>>>>
> >>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
> >>>>>>>> // Strachey(1965) CPL translated to C
> >>>>>>>> void P(u32 x)
> >>>>>>>> {
> >>>>>>>> if (H(x, x))
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> _P()
> >>>>>>>> [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]
> >>>>>>>>
> >>>>>>>> _main()
> >>>>>>>> [00000c56](01) 55 push ebp
> >>>>>>>> [00000c57](02) 8bec mov ebp,esp
> >>>>>>>> [00000c59](05) 68360c0000 push 00000c36 // push P
> >>>>>>>> [00000c5e](05) 68360c0000 push 00000c36 // push P
> >>>>>>>> [00000c63](05) e8fefcffff call 00000966 // call H(P,P)
> >>>>>>>> [00000c68](03) 83c408 add esp,+08
> >>>>>>>> [00000c6b](01) 50 push eax
> >>>>>>>> [00000c6c](05) 6857030000 push 00000357
> >>>>>>>> [00000c71](05) e810f7ffff call 00000386
> >>>>>>>> [00000c76](03) 83c408 add esp,+08
> >>>>>>>> [00000c79](02) 33c0 xor eax,eax
> >>>>>>>> [00000c7b](01) 5d pop ebp
> >>>>>>>> [00000c7c](01) c3 ret
> >>>>>>>> Size in bytes:(0039) [00000c7c]
> >>>>>>>>
> >>>>>>>> machine stack stack machine assembly
> >>>>>>>> address address data code language
> >>>>>>>> ======== ======== ======== ========= =============
> >>>>>>>> [00000c56][0010172a][00000000] 55 push ebp
> >>>>>>>> [00000c57][0010172a][00000000] 8bec mov ebp,esp
> >>>>>>>> [00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
> >>>>>>>> [00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
> >>>>>>>> [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)
> >>>>>>>>
> >>>>>>>> We can see that the first seven lines of P repeat. P calls H(P,P) that
> >>>>>>>> simulates P(P) that calls H(P,P) in a cycle the never stops unless H
> >>>>>>>> stops simulating its input. When H does stop simulating its input P
> >>>>>>>> never reaches its final state of [00000c50] therefore never halts even
> >>>>>>>> though it stops running.
> >>>>>>>>
> >>>>>>>> [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
> >>>>>>>>
> >>>>>>>> [00000c68][0010172a][00000000] 83c408 add esp,+08
> >>>>>>>> [00000c6b][00101726][00000000] 50 push eax
> >>>>>>>> [00000c6c][00101722][00000357] 6857030000 push 00000357
> >>>>>>>> [00000c71][00101722][00000357] e810f7ffff call 00000386
> >>>>>>>> Input_Halts = 0
> >>>>>>>> [00000c76][0010172a][00000000] 83c408 add esp,+08
> >>>>>>>> [00000c79][0010172a][00000000] 33c0 xor eax,eax
> >>>>>>>> [00000c7b][0010172e][00100000] 5d pop ebp
> >>>>>>>> [00000c7c][00101732][00000068] c3 ret
> >>>>>>>> Number_of_User_Instructions(27)
> >>>>>>>> Number of Instructions Executed(23721)
> >>>>>>>>
> >>>>>>>> *Strachey, C 1965* An impossible program The Computer Journal, Volume
> >>>>>>>> 7, Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
> >>>>>>>>
> >>>>>>>> *Linz, Peter 1990* An Introduction to Formal Languages and Automata.
> >>>>>>>> Lexington/Toronto: D. C. Heath and Company.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Copyright 2021 Pete Olcott
> >>>>>>>>
> >>>>>>>> "Great spirits have always encountered violent opposition from mediocre
> >>>>>>>> minds." Einstein
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Copyright 2021 Pete Olcott
> >>>>>>
> >>>>>> "Great spirits have always encountered violent opposition from mediocre
> >>>>>> minds." Einstein
> >>>>
> >>>>
> >>>> --
> >>>> Copyright 2021 Pete Olcott
> >>>>
> >>>> "Great spirits have always encountered violent opposition from mediocre
> >>>> minds." Einstein
> >>
> >>
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> "Great spirits have always encountered violent opposition from mediocre
> >> minds." Einstein
>
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein


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?

<wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>

 copy mid

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

 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!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!buffer1.nntp.ams1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 09:46:34 -0500
From: news.dea...@darjeeling.plus.com (Mike Terry)
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>
X-Mozilla-News-Host: news://news.plus.net
Date: Sun, 15 Aug 2021 15:46:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.7.1
MIME-Version: 1.0
In-Reply-To: <sf9c3k$7un$1@dont-email.me>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
Lines: 122
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SZxWhQ1x6EdkMZNWMTpAV1Uc8B7wHCMRDCconbMgcAWpDYLAU7mCUTjq3WeenRl6dYS9ogM3LWns9rh!JWbaYEOS2f0JYCptayKRpPv+cLWC4EnuWH9N4wqPOJhzdP+GQ2ETA9O1faadQfYodxJKoReYjiNf!+hY2/evT2YrNdA4JocCsLL14vg==
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: 7339
 by: Mike Terry - Sun, 15 Aug 2021 14:46 UTC

On 14/08/2021 22:20, Jeff Barnett wrote:
> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The P(P) of main() only halts because...
>>
>> As you say, P(P) halts.
>>
>>> *Halting computation* is any computation that eventually reaches its
>>> own final state. This criteria divides computations that halt from
>>> those that merely stop running because their simulation was aborted.
>>
>> No.  There is no "special kind of halting".  The computation M(I) either
>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>> does not halt.
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>
>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>
>> Why are you still hiding H?  Is it because you have still not figured
>> out how to nest a call to the simulator you are using?  Fortunately "we"
>> (i.e. everyone but you) can see that H is wrong without even seeing the
>> code.  Who is included in the "we" of the subject line?  Have you found
>> someone else who thinks that false is the correct return from a partial
>> halt decider called with arguments that represent a halting computation?
>
> I have questions about the PO simulator I hope someone can answer. It
> perhaps concerns memory mapping:

> First - is every instance of a use at
> different levels in its own address space?

I've tried to get PO to clarify that, and it always /seems/ that he is
suggesting yes [while avoiding any direct answer] but I have no
confidence whatsoever that he understands what everybody else would
understand by "its own address space".

He has definitely said that each simulation has its own stack and
registers, but my bet would be that they are more like your typical OS
threads, running in the same address space. (We could probably find out
by quizzing him on sharing of globals etc. and giving him concrete
examples which he could understand. But it might take a lot of work,
and for what at the end? Or more reasonably, if he published all his
source code as he maintained he would for around two years, we could
answer these sorts of questions for ourselves...)

> Second - if not, is there any
> way to know when an address is reported, which simulator instance is
> being reported on?

I suggested he needed to provide that last year. And at one point he
DID change his trace to show the emulation level, so it's not like
there's any coding difficulty! But then it was perfectly clear that he
was correlating trace entries together from completely separate
emulation levels, so the illusion that it was a "loop" in the normal
(single) processor-trace sense was lessened. He subsequently removed
the column, claiming as excuse that it confused people.

I'd say this is PO misunderstanding the difference between
call-recursion and emulation-recursion. The former can /only/ be broken
by code at the deepest recursion level which then percolates up to the
top level, like when we calculate n factorial recursively.
Emulation-recursion /can/ also break out this way, but with emulation
there is a second possibility - the break can be from the /top/ level
which simply decides not to emulate any more. The fact that the deepest
inner emulations appear to be repeating doesn't mean that they will go
on forever, because an outer level can always just give up emulating and
get on with whatever is next.

I suppose without an emulation-id column we can probably work stuff out
based on the overall flow of the trace together with knowledge about the
program and what H is doing and so on. (But why should this be required
when it's an essential part of the meaning of a trace entry?)

> When the dumb bunny (PO expression) notes that the
> same address is reached a second time without a conditional branch being
> executed, is there any assurance that the addresses are noted from the
> same instance of the simulation?

I can give you an assurance of exactly the opposite - they are
definitely from /different/ emulation levels! (I think you know that,
right?) PO tries to present them to look as much as possible like a
pattern of behaviour for a /single/ processor, because then he would
have "call recursion" which can only break inner-to-outer, and his
"processor trace" could provide some level of evidence that that won't
happen. (Also I'm remebering his recent remarks about the processor
"[..having no way to escape from the recursion..]" which might be
explained as PO not understanding the call/recursion distinction...)

In the past PO has said his rule applies equally for call-recursion and
emulation-recursion, no difference, while repeating something about
"equivalent computation", but he has no real /understanding/ of that
phrase and certainly no /proof/ of soundness even for the simple
call-recursion case, so it's just the usual unsupported claims. (And
there is no prospect of ever going further than this - PO is simply not
capable of "proving" anything and I doubt he understands what that even
means.)

> And finally, how can one determine if
> it's the same address twice without doing some sort of compare and
> branch?

OK, for PO's H, there are obviously hidden conditional branch
instructions within H, which is why PO has to come up with some wording
to convince himself that H can be totally ignored for whatever reason.
But drilling down on this seems overkill when PO hasn't even presented
any plausible argument (let alone proof!) that the detection rule being
used is sound. What would we be trying to disprove and why? :) PO has
agreed that H^(H^) halts, and that H(H^,H^) returns not-halting, so
that's it.

At least in the end it must be PO's responsibility to present /proofs/
of anything he claims, but now we've gone like 100 miles beyond his
capabilities - a complete non-starter...

Mike.

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

<QZydnaAum4OdrYT8nZ2dnUU78K3NnZ2d@brightview.co.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!buffer1.nntp.ams1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 10:17:20 -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>
<878s13y6s1.fsf@bsb.me.uk> <zjYRI.13727$fI7.7888@fx33.iad>
From: news.dea...@darjeeling.plus.com (Mike Terry)
Date: Sun, 15 Aug 2021 16:17:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.7.1
MIME-Version: 1.0
In-Reply-To: <zjYRI.13727$fI7.7888@fx33.iad>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <QZydnaAum4OdrYT8nZ2dnUU78K3NnZ2d@brightview.co.uk>
Lines: 115
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FS5q3Ze/tarfem/yMP7elkSsw6W1ez8QkObjWxVXQho6W6TvdD6MRfuwQmskt3GabhysYu1GsFK1o/R!xW0hf4nR+5zRxCj2LFFntAc+pkoQZnkSyScPkBttE9xQzxSe+V32mtGgeCjMMdPKC5AEDM9ssNyG!ntHqmyDx+K0xm1cf2iRVyUXwEg==
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: 7254
 by: Mike Terry - Sun, 15 Aug 2021 15:17 UTC

On 15/08/2021 00:27, Richard Damon wrote:
> On 8/14/21 6:56 PM, Ben Bacarisse wrote:
>> Jeff Barnett <jbb@notatt.com> writes:
>>
>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The P(P) of main() only halts because...
>>>> As you say, P(P) halts.
>>>>
>>>>> *Halting computation* is any computation that eventually reaches its
>>>>> own final state. This criteria divides computations that halt from
>>>>> those that merely stop running because their simulation was aborted.
>>>> No. There is no "special kind of halting". The computation M(I) either
>>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>>> does not halt.
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>>> Why are you still hiding H? Is it because you have still not figured
>>>> out how to nest a call to the simulator you are using? Fortunately "we"
>>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>>> code. Who is included in the "we" of the subject line? Have you found
>>>> someone else who thinks that false is the correct return from a partial
>>>> halt decider called with arguments that represent a halting computation?
>>>
>>> I have questions about the PO simulator I hope someone can answer. It
>>> perhaps concerns memory mapping: First - is every instance of a use at
>>> different levels in its own address space? Second - if not, is there
>>> any way to know when an address is reported, which simulator instance
>>> is being reported on? When the dumb bunny (PO expression) notes that
>>> the same address is reached a second time without a conditional branch
>>> being executed, is there any assurance that the addresses are noted
>>> from the same instance of the simulation? And finally, how can one
>>> determine if it's the same address twice without doing some sort of
>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>
>> You won't get a straight answer from PO, but I don't think there is any
>> nested simulation happening at all. PO "knows" it's that same a
>> recursion, so he just has recursive calls traced from "outside". I may
>> be wrong, of course, but this is one reason I think H is being kept
>> hidden -- it does not do what says.
>>
>
> He actually has leaked a fair amount about how the system works. H isn't
> actually a simulator, but an 'API Entry' into the x86utm system that has
> the real simulator, and calls into H as supposed to setup a new 'nested'
> level of simulation.

My impression is that H is part of the application code rather than an
OS call, but within H there are calls to PO's simulation primitives
which are trapped by x86utm.exe and implemented within x86utm. H would
still have the task of inspecting the (nested) emulation trace entries
to detect what it decides to be non-halting behaviour. (But then PO has
talked about a "global decider" which is part of the OS, so maybe my
impression is completely wrong! To be relevent to Linz, the deciding
logic at least must be in the application rather than in x86utm.)

>
> It sounds like these nested simulations are given their own stacks and
> 'user' code isn't supposed to be able to store data anywhere but on the
> stack, so that is supposed to be enough for a new environment, since he
> erroneously puts everything inside one code segment. (This means that H
> isn't a 'Universal' Halt Decider, as its input isn't an arbitrary machine.
>
> This would be one reason you can't 'copy' H, is that H isn't really the
> code but just an API (and if he allowed copying, his nesting detection
> breaks).
>
> One side effect of this is that I am not sure if his system can actually
> really handle finitely but multi-level simulations as at least some of
> the leaked implementations made H not really a computation as it used
> static memory to communicate between H and the OS.
>
>
> I also wonder if a computation built on P1 using H to decide on P2 which
> used H to decide on P3 could return the answer from P3 to P2.
>
> This structure could be used to solve the twins prime conjecture if the
> Halt decider actually worked. P1 would ask P2 to find the highest twin
> prime. If it is non-halting there is no highest twin prime.
>
> P2 would iterate through the twin primes starting at say 3,5 and ask P3
> to find the next one. If it find one, then it updates to that point and
> uses it again to find the next highest. If P2 is at the highest, then P3
> would be non-halting, and P2 would get the non-halting answer and could
> tell P1 what is the highest twin prime.
>
> P3 just takes its input and searches to find the next highest twin prime
> from there. If there isn't one it will just be non-halting.
>
> The problem is that just because P3 becomes non-halting isn't grounds to
> call P1 or P2 non-halting, as P3 becoming non-halting is the halting
> condition of P2. It is only if for every problem that P2 gives P3 that
> it always finds an answer that P2 becomes non-halting, and P1 then knows
> that the answer to the question is that there is no highest twin prime.
> (P1 halts in all cases).
>
> The slight problem is that his current definition of H doesn't seem to
> allow the caller of H to get the 'answer' from the machine it is
> running, so you have to do everything twice, first determine that it
> WOULD halt, then just call it to get the answer.
>

Maybe, but the emulating user code has access to the trace of the
emulated program, so in principle it should be able to work out what
that program returned. E.g. it can track that it finished by loading RAX
with (say) 1 then returned (terminated), meaning that it returned 1.

Mike.

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

<LvbSI.14100$fI7.1219@fx33.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.roellig-ltd.de!open-news-network.org!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx33.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>
<878s13y6s1.fsf@bsb.me.uk> <X7CdnT1zg-76B4X8nZ2dnUU7-KvNnZ2d@giganews.com>
<8a5e61e9-cea5-4447-8da6-688e30795ee2n@googlegroups.com>
<5-SdnZxO38vdhYT8nZ2dnUU7-cXNnZ2d@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: <5-SdnZxO38vdhYT8nZ2dnUU7-cXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 169
Message-ID: <LvbSI.14100$fI7.1219@fx33.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: Sun, 15 Aug 2021 12:44:27 -0400
X-Received-Bytes: 9238
 by: Richard Damon - Sun, 15 Aug 2021 16:44 UTC

On 8/15/21 9:36 AM, olcott wrote:
> On 8/15/2021 4:39 AM, Malcolm McLean wrote:
>> On Sunday, 15 August 2021 at 05:39:10 UTC+1, olcott wrote:
>>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>>> Jeff Barnett <j...@notatt.com> writes:
>>>>
>>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> The P(P) of main() only halts because...
>>>>>> As you say, P(P) halts.
>>>>>>
>>>>>>> *Halting computation* is any computation that eventually reaches its
>>>>>>> own final state. This criteria divides computations that halt from
>>>>>>> those that merely stop running because their simulation was aborted.
>>>>>> No. There is no "special kind of halting". The computation M(I)
>>>>>> either
>>>>>> halts or it does not. H(M, I) should be false if, and only if, M(I)
>>>>>> does not halt.
>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>> P(P) halts, yet H(P, P) is false. That's the wrong answer.
>>>>>> Why are you still hiding H? Is it because you have still not figured
>>>>>> out how to nest a call to the simulator you are using? Fortunately
>>>>>> "we"
>>>>>> (i.e. everyone but you) can see that H is wrong without even
>>>>>> seeing the
>>>>>> code. Who is included in the "we" of the subject line? Have you found
>>>>>> someone else who thinks that false is the correct return from a
>>>>>> partial
>>>>>> halt decider called with arguments that represent a halting
>>>>>> computation?
>>>>>
>>>>> I have questions about the PO simulator I hope someone can answer. It
>>>>> perhaps concerns memory mapping: First - is every instance of a use at
>>>>> different levels in its own address space? Second - if not, is there
>>>>> any way to know when an address is reported, which simulator instance
>>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>>> the same address is reached a second time without a conditional branch
>>>>> being executed, is there any assurance that the addresses are noted
>>>>> from the same instance of the simulation? And finally, how can one
>>>>> determine if it's the same address twice without doing some sort of
>>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>>
>>>> You won't get a straight answer from PO, but I don't think there is any
>>>> nested simulation happening at all. PO "knows" it's that same a
>>>> recursion, so he just has recursive calls traced from "outside". I may
>>> No this is not possible. There is no possible way to use ordinary
>>> recursion to implement nested x86 emulation without memory corruption of
>>> the stack. I explained all of the technical details of context
>>> switching: Here is a link that does a better job:
>>>
>>> https://en.wikipedia.org/wiki/Context_switch
>>>
>>> Each virtual machine has its own registers, stack and RAM. Once the
>>> virtual machine environment is set up, allocating the stack and RAM and
>>> other house keeping functions a context switch only requires saving and
>>> restoring all the machine registers.
>>>
>> We can write a ZX81 emulator on a modern machine. A ZX81 has 4K ROM
>> and 1K RAM. So our first line can be a "virualmem = malloc(1024 * 5).
>> We then
>> set up everything else in that memory space.
>> However the ZX81 emulator cannot emulate another ZX81, since it has only
>> 1K RAM to play with, and the virtual machine needs 5K.
>> You'll get this problem whenever you try to allow nested emulation on a
>> random-access  memory model machine.
>>
>> Turing machines don't have this problem. Write a UTM, and a "Hello world"
>> program, and
>> UTM<Hello> with output "Hello world" on the tape.
>> UTM<UTM><Hello> will also output "Hello world" on the tape. You can
>> stack up
>> as many UTMs as you like without any reprogramming. It might get very
>> slow,
>> but it will eventually finish.
>>
>> What you can do is treat memory allocation as a special function. Then
>> you
>> can nest simulations.
>>
>
> Yes I do that.
> It does not require knowing any of those details to see how totally
> blatantly obvious it is that:
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never stops running thus conclusively proving that
> when H decides this input never halts it is correct.
>

Except that since H doesn't stay as a Pure Simulator, the transformation
of tracing the simulator doing the simulation to the tracing of the
machine it is simulating is not valid.

If you wish to claim otherwise, please provide a proof that your
transform is actually valid.

That Tranceform only applies to a machine that is ALWAYS a pure
simulation, not one that simulates until some condition.

Thus your analysis that P is infinitely executing is unsound and gives
the wrong answer.

The fact that an aborted simulation doesn't reach the halting point of
the machine it is simulating actually proves nothing.

It IS a fact, that when P is run as the actual machine, or its
represention run by an ACTUAL pure simulator, it does reach a halting state.

So, we can show that H was wrong, as its input when PROPERLY simulated
will halt, H just errors in stopping it too soon due to using UNSOUND logic.

H just stops about 2/3s of the way to the final ending of P. Of course,
P is built on the H that is programed to do it that way. If you change
the H that P is built on, you need to totally restart your analysis.

You analysis that P is non-halting is ONLY sound if H is a ACTUAL pure
simulator, and your problem there is that if that is H, then H never
answers the question H(<P>,<P>) so it doesn't really matter that P(<P>)
is non-halting, H was 'wrong' anyway since it didn't answer.

> _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]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [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
>
>
>


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?

<KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 11:44:35 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<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>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 11:44: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: <407a228c-2484-4d5f-8e18-c0e47e9483adn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <KtednRM4wpvu2YT8nZ2dnUU7-e_NnZ2d@giganews.com>
Lines: 413
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-UwbHOWQGUCYOE/uKoi1fIYV80xTbIO59EJNG6yJe5fOWdHyPsQQaDpspVqlWhM/4guFdlsWGvqOfnoG!tY5mPGaxbBgz5ZJD0E1+MtvKZL4USuyODm3qhdL33U07kDEcglDtvXHLHEO/h4pm5KjzVqV6aCiE!jAE=
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: 20939
X-Received-Bytes: 21121
 by: olcott - Sun, 15 Aug 2021 16:44 UTC

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.

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) {}

> I hate to say that your programming level is very low because this has noting
> to do with the HP proof. I think many others know x86 and C languages and
> programming skills better than you do. No need to repeat posting the compiled
> assembly code fragment and pretend you know better and others cannot see it.
>

It is ridiculously foolish to claim that P on input P has nothing to do
with the halting problem proofs:

Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)

It remains ridiculously foolish for people claiming to fully understand
the x86 language to disagree with the following statement:

While H remains in pure simulation mode simulating the input to H(P,P)
this simulated input never stops running thus conclusively proving that
when H decides this input never halts it is correct.

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

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

_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]


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?

<6AbSI.14973$6h1.7779@fx39.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.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>
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: <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 134
Message-ID: <6AbSI.14973$6h1.7779@fx39.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: Sun, 15 Aug 2021 12:49:04 -0400
X-Received-Bytes: 7711
 by: Richard Damon - Sun, 15 Aug 2021 16:49 UTC

On 8/15/21 10:46 AM, Mike Terry wrote:
> On 14/08/2021 22:20, Jeff Barnett wrote:
>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The P(P) of main() only halts because...
>>>
>>> As you say, P(P) halts.
>>>
>>>> *Halting computation* is any computation that eventually reaches its
>>>> own final state. This criteria divides computations that halt from
>>>> those that merely stop running because their simulation was aborted.
>>>
>>> No.  There is no "special kind of halting".  The computation M(I) either
>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>> does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>
>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>
>>> Why are you still hiding H?  Is it because you have still not figured
>>> out how to nest a call to the simulator you are using?  Fortunately "we"
>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>> code.  Who is included in the "we" of the subject line?  Have you found
>>> someone else who thinks that false is the correct return from a partial
>>> halt decider called with arguments that represent a halting computation?
>>
>> I have questions about the PO simulator I hope someone can answer. It
>> perhaps concerns memory mapping:
>
>> First - is every instance of a use at different levels in its own
>> address space?
>
> I've tried to get PO to clarify that, and it always /seems/ that he is
> suggesting yes [while avoiding any direct answer] but I have no
> confidence whatsoever that he understands what everybody else would
> understand by "its own address space".

To me, he has actually made it pretty clear that there is just one
'address space' within the execution of a single instance of x86utm. It
isn't really an 'OS' in that sense.

Note, the parameters to H are always specified in the current machines
address space, and there is no indication that he makes actual copies of it.

>
> He has definitely said that each simulation has its own stack and
> registers, but my bet would be that they are more like your typical OS
> threads, running in the same address space.  (We could probably find out
> by quizzing him on sharing of globals etc. and giving him concrete
> examples which he could understand.  But it might take a lot of work,
> and for what at the end?  Or more reasonably, if he published all his
> source code as he maintained he would for around two years, we could
> answer these sorts of questions for ourselves...)
>
>> Second - if not, is there any way to know when an address is reported,
>> which simulator instance is being reported on?
>
> I suggested he needed to provide that last year.  And at one point he
> DID change his trace to show the emulation level, so it's not like
> there's any coding difficulty!  But then it was perfectly clear that he
> was correlating trace entries together from completely separate
> emulation levels, so the illusion that it was a "loop" in the normal
> (single) processor-trace sense was lessened.  He subsequently removed
> the column, claiming as excuse that it confused people.
>
> I'd say this is PO misunderstanding the difference between
> call-recursion and emulation-recursion.  The former can /only/ be broken
> by code at the deepest recursion level which then percolates up to the
> top level, like when we calculate n factorial recursively.
> Emulation-recursion /can/ also break out this way, but with emulation
> there is a second possibility - the break can be from the /top/ level
> which simply decides not to emulate any more.  The fact that the deepest
> inner emulations appear to be repeating doesn't mean that they will go
> on forever, because an outer level can always just give up emulating and
> get on with whatever is next.

Yes. It is basically the confusion of a 'Pure Simulator Until' with a
'Pure Simulator'.

>
> I suppose without an emulation-id column we can probably work stuff out
> based on the overall flow of the trace together with knowledge about the
> program and what H is doing and so on.  (But why should this be required
> when it's an essential part of the meaning of a trace entry?)
>
>> When the dumb bunny (PO expression) notes that the same address is
>> reached a second time without a conditional branch being executed, is
>> there any assurance that the addresses are noted from the same
>> instance of the simulation?
>
> I can give you an assurance of exactly the opposite - they are
> definitely from /different/ emulation levels!  (I think you know that,
> right?) PO tries to present them to look as much as possible like a
> pattern of behaviour for a /single/ processor, because then he would
> have "call recursion" which can only break inner-to-outer, and his
> "processor trace" could provide some level of evidence that that won't
> happen. (Also I'm remebering his recent remarks about the processor
> "[..having no way to escape from the recursion..]" which might be
> explained as PO not understanding the call/recursion distinction...)
>
> In the past PO has said his rule applies equally for call-recursion and
> emulation-recursion, no difference, while repeating something about
> "equivalent computation", but he has no real /understanding/ of that
> phrase and certainly no /proof/ of soundness even for the simple
> call-recursion case, so it's just the usual unsupported claims.  (And
> there is no prospect of ever going further than this - PO is simply not
> capable of "proving" anything and I doubt he understands what that even
> means.)
>
>> And finally, how can one determine if it's the same address twice
>> without doing some sort of compare and branch?
>
> OK, for PO's H, there are obviously hidden conditional branch
> instructions within H, which is why PO has to come up with some wording
> to convince himself that H can be totally ignored for whatever reason.
> But drilling down on this seems overkill when PO hasn't even presented
> any plausible argument (let alone proof!) that the detection rule being
> used is sound.  What would we be trying to disprove and why? :)  PO has
> agreed that H^(H^) halts, and that H(H^,H^) returns not-halting, so
> that's it.
>
> At least in the end it must be PO's responsibility to present /proofs/
> of anything he claims, but now we've gone like 100 miles beyond his
> capabilities - a complete non-starter...
>
> Mike.
>

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

<D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.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: Sun, 15 Aug 2021 12:16:56 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me> <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 12:16:55 -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: <wpidnVhzXtFXtYT8nZ2dnUU78YHNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <D6WdnQ0Hy92V0YT8nZ2dnUU7-Q3NnZ2d@giganews.com>
Lines: 319
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Aftzpk3LNVlEKzn0clllSNs764lolm7WwtlVycOQCEl78QOHv1FvTfM5xwcsLnnDM8DBGEN/c+SR4z8!82zTthl+9QuYZXsxp8tPvrllUA7NDC5ieOcQknn94C5anYhSmtZpdshl/4YfRqr+9ehc7eKNsgk0!F/A=
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: 15643
X-Received-Bytes: 15869
 by: olcott - Sun, 15 Aug 2021 17:16 UTC

On 8/15/2021 9:46 AM, Mike Terry wrote:
> On 14/08/2021 22:20, Jeff Barnett wrote:
>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The P(P) of main() only halts because...
>>>
>>> As you say, P(P) halts.
>>>
>>>> *Halting computation* is any computation that eventually reaches its
>>>> own final state. This criteria divides computations that halt from
>>>> those that merely stop running because their simulation was aborted.
>>>
>>> No.  There is no "special kind of halting".  The computation M(I) either
>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>> does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>
>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>
>>> Why are you still hiding H?  Is it because you have still not figured
>>> out how to nest a call to the simulator you are using?  Fortunately "we"
>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>> code.  Who is included in the "we" of the subject line?  Have you found
>>> someone else who thinks that false is the correct return from a partial
>>> halt decider called with arguments that represent a halting computation?
>>
>> I have questions about the PO simulator I hope someone can answer. It
>> perhaps concerns memory mapping:
>
>> First - is every instance of a use at different levels in its own
>> address space?
>
> I've tried to get PO to clarify that, and it always /seems/ that he is
> suggesting yes [while avoiding any direct answer] but I have no
> confidence whatsoever that he understands what everybody else would
> understand by "its own address space".
>

There is a single contiguous block of RAM that is used by all of the
virtual machine and the halt decider. Whenever H is called it creates a
separate context having its own Registers, RAM and stack space. It
performs its x86 emulation on its input virtual machine in the separate
process context. Just like recursion the executable code of every
instance of P and H are at the same fixed machine address.

> He has definitely said that each simulation has its own stack and
> registers, but my bet would be that they are more like your typical OS
> threads, running in the same address space.  (We could probably find out
> by quizzing him on sharing of globals etc. and giving him concrete
> examples which he could understand.  But it might take a lot of work,
> and for what at the end?  Or more reasonably, if he published all his
> source code as he maintained he would for around two years, we could
> answer these sorts of questions for ourselves...)
>

Until people quit refuting this very obvious truth they consistently
prove that they are far too disingenuous to deserve any additional
details that would only give them an excuse to make sure that they
always go off on tangents and dodge the key relevant points:

While H remains in pure simulation mode simulating the input to H(P,P)
this simulated input never stops running thus conclusively proving that
when H decides this input never halts it is correct.

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

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

_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]

_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36 // push P
[00000c5e](05) 68360c0000 push 00000c36 // push P
[00000c63](05) e8fefcffff call 00000966 // call H(P,P)
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[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

>> Second - if not, is there any way to know when an address is reported,
>> which simulator instance is being reported on?
>
> I suggested he needed to provide that last year.  And at one point he
> DID change his trace to show the emulation level, so it's not like
> there's any coding difficulty!  But then it was perfectly clear that he
> was correlating trace entries together from completely separate
> emulation levels, so the illusion that it was a "loop" in the normal
> (single) processor-trace sense was lessened.  He subsequently removed
> the column, claiming as excuse that it confused people.
>
> I'd say this is PO misunderstanding the difference between
> call-recursion and emulation-recursion.  The former can /only/ be broken
> by code at the deepest recursion level which then percolates up to the
> top level, like when we calculate n factorial recursively.
> Emulation-recursion /can/ also break out this way, but with emulation
> there is a second possibility - the break can be from the /top/ level
> which simply decides not to emulate any more.  The fact that the deepest
> inner emulations appear to be repeating doesn't mean that they will go
> on forever, because an outer level can always just give up emulating and
> get on with whatever is next.
>

If I did not understand this then I would have not explained it this
same way many dozens of times.

> I suppose without an emulation-id column we can probably work stuff out
> based on the overall flow of the trace together with knowledge about the
> program and what H is doing and so on.  (But why should this be required
> when it's an essential part of the meaning of a trace entry?)
>
>> When the dumb bunny (PO expression) notes that the same address is
>> reached a second time without a conditional branch being executed, is
>> there any assurance that the addresses are noted from the same
>> instance of the simulation?
>
> I can give you an assurance of exactly the opposite - they are
> definitely from /different/ emulation levels!  (I think you know that,
> right?) PO tries to present them to look as much as possible like a
> pattern of behaviour for a /single/ processor, because then he would
> have "call recursion" which can only break inner-to-outer, and his
> "processor trace" could provide some level of evidence that that won't
> happen. (Also I'm remebering his recent remarks about the processor
> "[..having no way to escape from the recursion..]" which might be
> explained as PO not understanding the call/recursion distinction...)
>


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?

<trGdnbVVHclt0IT8nZ2dnUU7-QXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 15 Aug 2021 12:25:04 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<878s13y6s1.fsf@bsb.me.uk> <zjYRI.13727$fI7.7888@fx33.iad>
<QZydnaAum4OdrYT8nZ2dnUU78K3NnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 15 Aug 2021 12:25:01 -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: <QZydnaAum4OdrYT8nZ2dnUU78K3NnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <trGdnbVVHclt0IT8nZ2dnUU7-QXNnZ2d@giganews.com>
Lines: 150
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jDC6qfLFsxuRMBEPXgy2L55R4fhRlWbzjk8XbYq2DWUd8nxvznqSTHkGJn4nZH66tkIWxRlWngcPW97!di7wSZs/KPZvWtvJjNVSie2uH9DKq16NdZibLZCnXlN/3k1WKTFwms5rWsWvEpHZjjB2HzW3F1Sp!eOc=
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: 8323
 by: olcott - Sun, 15 Aug 2021 17:25 UTC

On 8/15/2021 10:17 AM, Mike Terry wrote:
> On 15/08/2021 00:27, Richard Damon wrote:
>> On 8/14/21 6:56 PM, Ben Bacarisse wrote:
>>> Jeff Barnett <jbb@notatt.com> writes:
>>>
>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The P(P) of main() only halts because...
>>>>> As you say, P(P) halts.
>>>>>
>>>>>> *Halting computation* is any computation that eventually reaches its
>>>>>> own final state. This criteria divides computations that halt from
>>>>>> those that merely stop running because their simulation was aborted.
>>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>>> either
>>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>>> does not halt.
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>     if (H(x, x))
>>>>>>       HERE: goto HERE;
>>>>>> }
>>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>>> Why are you still hiding H?  Is it because you have still not figured
>>>>> out how to nest a call to the simulator you are using?  Fortunately
>>>>> "we"
>>>>> (i.e. everyone but you) can see that H is wrong without even seeing
>>>>> the
>>>>> code.  Who is included in the "we" of the subject line?  Have you
>>>>> found
>>>>> someone else who thinks that false is the correct return from a
>>>>> partial
>>>>> halt decider called with arguments that represent a halting
>>>>> computation?
>>>>
>>>> I have questions about the PO simulator I hope someone can answer. It
>>>> perhaps concerns memory mapping: First - is every instance of a use at
>>>> different levels in its own address space? Second - if not, is there
>>>> any way to know when an address is reported, which simulator instance
>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>> the same address is reached a second time without a conditional branch
>>>> being executed, is there any assurance that the addresses are noted
>>>> from the same instance of the simulation? And finally, how can one
>>>> determine if it's the same address twice without doing some sort of
>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>
>>> You won't get a straight answer from PO, but I don't think there is any
>>> nested simulation happening at all.  PO "knows" it's that same a
>>> recursion, so he just has recursive calls traced from "outside".  I may
>>> be wrong, of course, but this is one reason I think H is being kept
>>> hidden -- it does not do what says.
>>>
>>
>> He actually has leaked a fair amount about how the system works. H isn't
>> actually a simulator, but an 'API Entry' into the x86utm system that has
>> the real simulator, and calls into H as supposed to setup a new 'nested'
>> level of simulation.
>
> My impression is that H is part of the application code rather than an
> OS call, but within H there are calls to PO's simulation primitives
> which are trapped by x86utm.exe and implemented within x86utm.  H would
> still have the task of inspecting the (nested) emulation trace entries
> to detect what it decides to be non-halting behaviour.  (But then PO has
> talked about a "global decider" which is part of the OS, so maybe my
> impression is completely wrong!  To be relevent to Linz, the deciding
> logic at least must be in the application rather than in x86utm.)
>

Now that I created

int Simulate(u32 P, u32 I)
{ ((int(*)(int))P)(I);
return 1;
}

The global halt decider is fully obsolete.

I am (of course) aware that the above function directly executes rather
that emulates its input, none-the-less it provides a very simple way
that is very easy to understand to provide the computational equivalent
of simulation.

>>
>> It sounds like these nested simulations are given their own stacks and
>> 'user' code isn't supposed to be able to store data anywhere but on the
>> stack, so that is supposed to be enough for a new environment, since he
>> erroneously puts everything inside one code segment. (This means that H
>> isn't a 'Universal' Halt Decider, as its input isn't an arbitrary
>> machine.
>>
>> This would be one reason you can't 'copy' H, is that H isn't really the
>> code but just an API (and if he allowed copying, his nesting detection
>> breaks).
>>
>> One side effect of this is that I am not sure if his system can actually
>> really handle finitely but multi-level simulations as at least some of
>> the leaked implementations made H not really a computation as it used
>> static memory to communicate between H and the OS.
>>
>>
>> I also wonder if a computation built on P1 using H to decide on P2 which
>> used H to decide on P3 could return the answer from P3 to P2.
>>
>> This structure could be used to solve the twins prime conjecture if the
>> Halt decider actually worked. P1 would ask P2 to find the highest twin
>> prime. If it is non-halting there is no highest twin prime.
>>
>> P2 would iterate through the twin primes starting at say 3,5 and ask P3
>> to find the next one. If it find one, then it updates to that point and
>> uses it again to find the next highest. If P2 is at the highest, then P3
>> would be non-halting, and P2 would get the non-halting answer and could
>> tell P1 what is the highest twin prime.
>>
>> P3 just takes its input and searches to find the next highest twin prime
>> from there. If there isn't one it will just be non-halting.
>>
>> The problem is that just because P3 becomes non-halting isn't grounds to
>> call P1 or P2 non-halting, as P3 becoming non-halting is the halting
>> condition of P2. It is only if for every problem that P2 gives P3 that
>> it always finds an answer that P2 becomes non-halting, and P1 then knows
>> that the answer to the question is that there is no highest twin prime.
>> (P1 halts in all cases).
>>
>> The slight problem is that his current definition of H doesn't seem to
>> allow the caller of H to get the 'answer' from the machine it is
>> running, so you have to do everything twice, first determine that it
>> WOULD halt, then just call it to get the answer.
>>
>
> Maybe, but the emulating user code has access to the trace of the
> emulated program, so in principle it should be able to work out what
> that program returned. E.g. it can track that it finished by loading RAX
> with (say) 1 then returned (terminated), meaning that it returned 1.
>
> Mike.
>

The executed (rather than simulated) instance of H has every relevant
detail of all of its nested emulations as its own data that is derived
as a pure function of its inputs.

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

<sfbinq$h8$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jbb...@notatt.com (Jeff Barnett)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Sun, 15 Aug 2021 11:26:12 -0600
Organization: A noiseless patient Spider
Lines: 148
Message-ID: <sfbinq$h8$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87eeavycxg.fsf@bsb.me.uk> <sf9c3k$7un$1@dont-email.me>
<878s13y6s1.fsf@bsb.me.uk> <JaWdnf6KtPnl0IX8nZ2dnUU7-enNnZ2d@giganews.com>
<sfa3u2$pq1$1@dont-email.me> <fOOdnYos7-IxAYX8nZ2dnUU7-cHNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 15 Aug 2021 17:26:18 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="49e1d2be8628775cdc3623dd27b35b90";
logging-data="552"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18xDRCYtcJe6Wz2HlsajHkwapogItjQlwM="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:imsfbQ5Y5zrDnBVj1qEKxUuI02g=
In-Reply-To: <fOOdnYos7-IxAYX8nZ2dnUU7-cHNnZ2d@giganews.com>
Content-Language: en-US
 by: Jeff Barnett - Sun, 15 Aug 2021 17:26 UTC

On 8/14/2021 10:48 PM, olcott wrote:
> On 8/14/2021 11:07 PM, Jeff Barnett wrote:
>> On 8/14/2021 5:10 PM, olcott wrote:
>>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>
>>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The P(P) of main() only halts because...
>>>>>> As you say, P(P) halts.
>>>>>>
>>>>>>> *Halting computation* is any computation that eventually reaches its
>>>>>>> own final state. This criteria divides computations that halt from
>>>>>>> those that merely stop running because their simulation was aborted.
>>>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>>>> either
>>>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>>>> does not halt.
>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>     if (H(x, x))
>>>>>>>       HERE: goto HERE;
>>>>>>> }
>>>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>>>> Why are you still hiding H?  Is it because you have still not figured
>>>>>> out how to nest a call to the simulator you are using?
>>>>>> Fortunately "we"
>>>>>> (i.e. everyone but you) can see that H is wrong without even
>>>>>> seeing the
>>>>>> code.  Who is included in the "we" of the subject line?  Have you
>>>>>> found
>>>>>> someone else who thinks that false is the correct return from a
>>>>>> partial
>>>>>> halt decider called with arguments that represent a halting
>>>>>> computation?
>>>>>
>>>>> I have questions about the PO simulator I hope someone can answer. It
>>>>> perhaps concerns memory mapping: First - is every instance of a use at
>>>>> different levels in its own address space? Second - if not, is there
>>>>> any way to know when an address is reported, which simulator instance
>>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>>> the same address is reached a second time without a conditional branch
>>>>> being executed, is there any assurance that the addresses are noted
>>>>> from the same instance of the simulation? And finally, how can one
>>>>> determine if it's the same address twice without doing some sort of
>>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>>
>>>> You won't get a straight answer from PO, but I don't think there is any
>>>> nested simulation happening at all.  PO "knows" it's that same a
>>>> recursion,
>>>
>>> Because context switching is required so that one function can resume
>>> simulating the middle of another function with DebugStep() and then
>>> return back to the same point in the middle of the current function
>>> this requires that each context have its own set of registers.
>>>
>>> This makes using ordinary recursion for nested x86 emulation
>>> infeasible because one process would clobber the stack of the other
>>> processes.
>>>
>>> The stack registers of ESP and EBP are included in this set of saved
>>> and restored registers. So we also have to have separate stack space
>>> or one process would clobber the stack space of the other process.
>>>
>>> Since no one here could begin to understand even seven lines of
>>> simple x86 code, I did not bring up these other details to avoid
>>> confusing my audience much more than they were already confused.
>>
>> Our comprehension is just fine; that's not the problem here. The
>> actual issue is that you neither understand nor are capable of
>> learning about address mapping (that little thigamajig the page
>> hardware implements).
>
> 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'm not suggesting you page. I'm suggesting that a simulator map the
address spaces of the simulated so it levels and addresses used are kept
straight. It doesn't seem to now. So your simulator either can't or
doesn't fully simulate the X86 hardware it seems. Also from your
response, I'd guess you don't understand the architecture very well either.

As always: seek advise, take your meds, and godspeed.

>> Context switches may need to save and restore registers, etc. Those
>> are the kinds of things an OS does from day one of its inception. I
>> think you need to return to high School (see your other thread) and
>> ask a teacher to hold your hand and bring you up to date; at least to
>> the mid 1960s. I know that would be rushing things for you. But tiny
>> steps first. Maybe you'll understand these things better in a few
>> years. Hell, while you are at it you might retake some of those pesky
>> HS math classes that so confused you.
>>
>> Remember: ask for help that you need; follow instructions; take your
>> meds. Best of luck.
>>
>> BTW At your age, whatever it is, you might need special
>> recommendations to reenter high school. I'm sure all of us here would
>> be willing to write a letter of recommendation that will state that
>> remedial high school classes will be perfect for you. Perhaps this
>> time around, you will be able to pick up all those tidbits that went
>> over your head the first time.
>>
>>> Not being able to understand seven simple lines of x86 code in many
>>> months is a horribly terrible degree of comprehension.
>>>
>>>> so he just has recursive calls traced from "outside".  I may
>>>> be wrong, of course, but this is one reason I think H is being kept
>>>> hidden -- it does not do what says.--
>> Jeff Barnett
--
Jeff Barnett

Pages:12345678910111213141516171819
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor