Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Excessive login or logout messages are a sure sign of senility.


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?

<X8ednQJLG4oW6oP8nZ2dnUU7-X3NnZ2d@giganews.com>

 copy mid

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

 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!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 10:23:55 -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> <HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com> <ZMYSI.11$Oz2.8@fx47.iad> <TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com> <EcZSI.233$kr4.37@fx48.iad> <XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad> <B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com> <8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com> <1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com> <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com> <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <ed49e1ee-ea07-4227-9eaa-d0e22449cb3an@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 10:23:54 -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: <ed49e1ee-ea07-4227-9eaa-d0e22449cb3an@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <X8ednQJLG4oW6oP8nZ2dnUU7-X3NnZ2d@giganews.com>
Lines: 146
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-KdThdfK1UhvnFusfsjpGqSNwdoWrMZUT9JMIAEvoIjL+S9LtuvdbMwWN4EmCsRg+Zq+jzs6XOx1Oh/X!H0uxkuA3HuSqNlGE+tuxXlpqNrCpr47XPgRf9I8P27Yj5ZGh4STRIdYtqk6MC6pxquRzPitQJHQq!yYc=
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: 7702
 by: olcott - Thu, 19 Aug 2021 15:23 UTC

On 8/19/2021 9:39 AM, Malcolm McLean wrote:
> On Thursday, 19 August 2021 at 15:14:11 UTC+1, olcott wrote:
>> On 8/19/2021 5:26 AM, Malcolm McLean wrote:
>>> On Wednesday, 18 August 2021 at 16:44:44 UTC+1, olcott wrote:
>>>> On 8/18/2021 10:28 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 18 August 2021 at 14:57:10 UTC+1, olcott wrote:
>>>>>>
>>>>>> H has no effect on the machine that it simulates until after its halt
>>>>>> status decision has been made. This conclusively proves that H can
>>>>>> ignore its in execution trace during its halt status analysis.
>>>>>>
>>>>>> Anyone disagreeing with this is either not intelligent or knowledgeable
>>>>>> enough to understand it, or a liar.
>>>>>>
>>>>>> That H does effect the behavior or its input at some other point is
>>>>>> utterly irrelevant to this analysis. We are only answering the single
>>>>>> question: Is it correct for H to ignore its own execution trace during
>>>>>> its halt status analysis?
>>>>>>
>>>>> If H is analysing H, it can't ignore the behaviour of H. That's why your results
>>>>> are wrong despite the execution trace seeming to show a non-halting
>>>>> behaviour.
>>>>>
>>>> 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.
>>>>
>>>> The above proves itself true entirely on the basis of the meaning
>>>> of its words. There is no possible correct rebuttal there is only
>>>> a failure to comprehend. If you believe that there is a correct
>>>> rebuttal please provide it and I will point out your error.
>>>>
>>> You're wrong here. When H is being called on a program which includes
>>> a call to H, the nested call to H needs to be analysed like any other
>>> call. It can and in fact does affect the halting behaviour of the input.
>> You are doing as bad of a job analyzing this as Robert. You are making
>> sure to simply ignore key words that I have said.
>>
>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
>> ITS INPUT.
>>
>> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY EFFECT
>> ON THE BEHAVIOR OF ITS INPUT.
>>
>> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
>> NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>>
>> Try and find a specific flaw in that, there are one.
>>
> Let's forget LInz and take this simple function
>
> void loopforever(U32 dummy)
> {
> while(1);
> }
>
> Now loopforever(dummy) doesn't halt, agreed?
> this function
>
> int H1(U32 dummy)
> {
> return H(loopforever, dummy);
> }
>
> halts and returns 0 (non-halting). Agreed?
>
> Now consider this function
>
> int H2(u32 dummy)
> {
> return H(H1, dummy);
> }
>
> What does that do?
>

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00000ea2](01) 55 push ebp
[00000ea3](02) 8bec mov ebp,esp
[00000ea5](02) ebfe jmp 00000ea5
[00000ea7](01) 5d pop ebp
[00000ea8](01) c3 ret
Size in bytes:(0007) [00000ea8]

_main()
[00000f02](01) 55 push ebp
[00000f03](02) 8bec mov ebp,esp
[00000f05](05) 68a20e0000 push 00000ea2
[00000f0a](05) e8e3fcffff call 00000bf2
[00000f0f](03) 83c404 add esp,+04
[00000f12](01) 50 push eax
[00000f13](05) 6823030000 push 00000323
[00000f18](05) e835f4ffff call 00000352
[00000f1d](03) 83c408 add esp,+08
[00000f20](02) 33c0 xor eax,eax
[00000f22](01) 5d pop ebp
[00000f23](01) c3 ret
Size in bytes:(0034) [00000f23]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000f02][00101b56][00000000] 55 push ebp
....[00000f03][00101b56][00000000] 8bec mov ebp,esp
....[00000f05][00101b52][00000ea2] 68a20e0000 push 00000ea2
....[00000f0a][00101b4e][00000f0f] e8e3fcffff call 00000bf2

Begin Local Halt Decider Simulation at Machine Address:ea2
....[00000ea2][00211bfa][00211bfe] 55 push ebp
....[00000ea3][00211bfa][00211bfe] 8bec mov ebp,esp
....[00000ea5][00211bfa][00211bfe] ebfe jmp 00000ea5
....[00000ea5][00211bfa][00211bfe] ebfe jmp 00000ea5
Local Halt Decider: Infinite Loop Detected Simulation Stopped

....[00000f0f][00101b56][00000000] 83c404 add esp,+04
....[00000f12][00101b52][00000000] 50 push eax
....[00000f13][00101b4e][00000323] 6823030000 push 00000323
---[00000f18][00101b4e][00000323] e835f4ffff call 00000352
Input_Halts = 0
....[00000f1d][00101b56][00000000] 83c408 add esp,+08
....[00000f20][00101b56][00000000] 33c0 xor eax,eax
....[00000f22][00101b5a][00100000] 5d pop ebp
....[00000f23][00101b5e][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(627)

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

<sflteh$enl$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!rocksolid2!news.neodome.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 09:30:24 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 104
Message-ID: <sflteh$enl$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<2rSdnfB8eLnVRYb8nZ2dnUU7-b_NnZ2d@giganews.com> <LtXSI.32$tv2.30@fx45.iad>
<HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com> <ZMYSI.11$Oz2.8@fx47.iad>
<TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com> <EcZSI.233$kr4.37@fx48.iad>
<XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad>
<B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad>
<s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad>
<8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad>
<QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad>
<1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad>
<Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Aug 2021 15:30:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="34f895952f8e95c031c9a45fb317058b";
logging-data="15093"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cm6gFqakSJpXY919K7uZ9"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:il1/5hcpY9h6YklUmYOA3VjE8j8=
In-Reply-To: <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 19 Aug 2021 15:30 UTC

On 2021-08-19 08:14, olcott wrote:
> On 8/19/2021 5:26 AM, Malcolm McLean wrote:
>> On Wednesday, 18 August 2021 at 16:44:44 UTC+1, olcott wrote:
>>> On 8/18/2021 10:28 AM, Malcolm McLean wrote:
>>>> On Wednesday, 18 August 2021 at 14:57:10 UTC+1, olcott wrote:
>>>>>
>>>>> H has no effect on the machine that it simulates until after its halt
>>>>> status decision has been made. This conclusively proves that H can
>>>>> ignore its in execution trace during its halt status analysis.
>>>>>
>>>>> Anyone disagreeing with this is either not intelligent or
>>>>> knowledgeable
>>>>> enough to understand it, or a liar.
>>>>>
>>>>> That H does effect the behavior or its input at some other point is
>>>>> utterly irrelevant to this analysis. We are only answering the single
>>>>> question: Is it correct for H to ignore its own execution trace during
>>>>> its halt status analysis?
>>>>>
>>>> If H is analysing H, it can't ignore the behaviour of H. That's why
>>>> your results
>>>> are wrong despite the execution trace seeming to show a non-halting
>>>> behaviour.
>>>>
>>> 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.
>>>
>>> The above proves itself true entirely on the basis of the meaning
>>> of its words. There is no possible correct rebuttal there is only
>>> a failure to comprehend. If you believe that there is a correct
>>> rebuttal please provide it and I will point out your error.
>>>
>> You're wrong here. When H is being called on a program which includes
>> a call to H, the nested call to H needs to be analysed like any other
>> call. It can and in fact does affect the halting behaviour of the input.
>
> You are doing as bad of a job analyzing this as Robert. You are making
> sure to simply ignore key words that I have said.
>
> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
> ITS INPUT.
>
> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY EFFECT
> ON THE BEHAVIOR OF ITS INPUT.
>
> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
> NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>
> Try and find a specific flaw in that, there are one.

No one is 'ignoring key words'. What you state above is simply wrong.

First, your H *never* acts as a pure simulator. A pure simulator would
behave as follows:

(1) fetch an opcode
(2) emulate that opcode on the operands which follow
(4) advance to the next opcode and go back to step (1)

Your H behaves as follows:

(1) fetch an opcode
(2) emulate that opcode on the operands which follow
(3) decide whether to continue the simulation or not

(4a) if we decide not to continue, abort the simulation.
(4b) if we decide to continue, advance to the next opcode and go back
to step (1)

A pure simulator doesn't contain step (3). And step (3) means that after
*every* instruction there is a potential for the decider to have an
effect on the simulation of its input.

When the input to H contains another call to H (call it H2), that begins
a *new* simulation and every single step of that simulation includes
step (3) which has the potential to abort the simulation.

We can say that your H 'sort of' acts like a pure simulator at each step
where, in step (3), it decides to continue with the simulation. But when
your H *ignores* the instructions in H2, it never sees those decisions
about whether to continue with the simulation or not.

This is exactly why your H(P, P) generates the wrong answer.

When we execute P(P) it halts. Why? Because at some point in the
simulation of P within P(P) step (3) of the simulation decides to abort
the simulation.

H(P, P) claims that P(P) doesn't halt because it *ignores* that crucial
decision made by P to abort the simulation.

Its perfectly legitimate for H to ignore its *own* code. After all, its
own code isn't part of the input which it is analyzing. But it cannot
ignore H2 since that *is* part of the input which it is analyzing.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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

<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!rocksolid2!i2pn.org!usenet.goja.nl.eu.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 10:40:53 -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> <LtXSI.32$tv2.30@fx45.iad> <HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com> <ZMYSI.11$Oz2.8@fx47.iad> <TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com> <EcZSI.233$kr4.37@fx48.iad> <XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad> <B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com> <8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com> <1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com> <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com> <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 10:40:52 -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: <sflteh$enl$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com>
Lines: 117
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jm4F1vquMguMc9qSlN2EKnAhulYkB9yFGDZoNZsuN1tAgjURmrBC0ajtBBp/pFryN0LHSCVVC039gJy!HgqZ8FwUCownybqJ/WmaAoeDHdv7fwvs+1LdMAc9scdgUJdM5IxvTt/Rk0t7Ol/L4uPLdL95xs0e!o3c=
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: 7166
 by: olcott - Thu, 19 Aug 2021 15:40 UTC

On 8/19/2021 10:30 AM, André G. Isaak wrote:
> On 2021-08-19 08:14, olcott wrote:
>> On 8/19/2021 5:26 AM, Malcolm McLean wrote:
>>> On Wednesday, 18 August 2021 at 16:44:44 UTC+1, olcott wrote:
>>>> On 8/18/2021 10:28 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 18 August 2021 at 14:57:10 UTC+1, olcott wrote:
>>>>>>
>>>>>> H has no effect on the machine that it simulates until after its halt
>>>>>> status decision has been made. This conclusively proves that H can
>>>>>> ignore its in execution trace during its halt status analysis.
>>>>>>
>>>>>> Anyone disagreeing with this is either not intelligent or
>>>>>> knowledgeable
>>>>>> enough to understand it, or a liar.
>>>>>>
>>>>>> That H does effect the behavior or its input at some other point is
>>>>>> utterly irrelevant to this analysis. We are only answering the single
>>>>>> question: Is it correct for H to ignore its own execution trace
>>>>>> during
>>>>>> its halt status analysis?
>>>>>>
>>>>> If H is analysing H, it can't ignore the behaviour of H. That's why
>>>>> your results
>>>>> are wrong despite the execution trace seeming to show a non-halting
>>>>> behaviour.
>>>>>
>>>> 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.
>>>>
>>>> The above proves itself true entirely on the basis of the meaning
>>>> of its words. There is no possible correct rebuttal there is only
>>>> a failure to comprehend. If you believe that there is a correct
>>>> rebuttal please provide it and I will point out your error.
>>>>
>>> You're wrong here. When H is being called on a program which includes
>>> a call to H, the nested call to H needs to be analysed like any other
>>> call. It can and in fact does affect the halting behaviour of the input.
>>
>> You are doing as bad of a job analyzing this as Robert. You are making
>> sure to simply ignore key words that I have said.
>>
>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
>> ITS INPUT.
>>
>> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY
>> EFFECT ON THE BEHAVIOR OF ITS INPUT.
>>
>> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
>> NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>>
>> Try and find a specific flaw in that, there are one.
>
> No one is 'ignoring key words'. What you state above is simply wrong.
>
> First, your H *never* acts as a pure simulator. A pure simulator would
> behave as follows:
>

The behavior of H while H is in pure simulation mode is computationally
equivalent to the behavior of a pure simulator in that while H is in
pure simulation mode it has no effect what-so-ever on the behavior of
its input.

> (1) fetch an opcode
> (2) emulate that opcode on the operands which follow
> (4) advance to the next opcode and go back to step (1)
>
> Your H behaves as follows:
>
> (1) fetch an opcode
> (2) emulate that opcode on the operands which follow
> (3) decide whether to continue the simulation or not
>
>    (4a) if we decide not to continue, abort the simulation.
>    (4b) if we decide to continue, advance to the next opcode and go back
>         to step (1)
>
> A pure simulator doesn't contain step (3). And step (3) means that after
> *every* instruction there is a potential for the decider to have an
> effect on the simulation of its input.
>
> When the input to H contains another call to H (call it H2), that begins
> a *new* simulation and every single step of that simulation includes
> step (3) which has the potential to abort the simulation.
>
> We can say that your H 'sort of' acts like a pure simulator at each step
> where, in step (3), it decides to continue with the simulation. But when
> your H *ignores* the instructions in H2, it never sees those decisions
> about whether to continue with the simulation or not.
>
> This is exactly why your H(P, P) generates the wrong answer.
>
> When we execute P(P) it halts. Why? Because at some point in the
> simulation of P within P(P) step (3) of the simulation decides to abort
> the simulation.
>
> H(P, P) claims that P(P) doesn't halt because it *ignores* that crucial
> decision made by P to abort the simulation.
>
> Its perfectly legitimate for H to ignore its *own* code. After all, its
> own code isn't part of the input which it is analyzing. But it cannot
> ignore H2 since that *is* part of the input which it is analyzing.
>
> André
>

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

<sfm1qb$f4u$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 10:44:59 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 70
Message-ID: <sfm1qb$f4u$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<HMCdnaohdr_m2IH8nZ2dnUU7-d3NnZ2d@giganews.com> <ZMYSI.11$Oz2.8@fx47.iad>
<TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com> <EcZSI.233$kr4.37@fx48.iad>
<XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad>
<B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad>
<s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad>
<8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad>
<QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad>
<1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad>
<Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Aug 2021 16:44:59 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="34f895952f8e95c031c9a45fb317058b";
logging-data="15518"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18d3E5n7beSJ9zN+eITOl2W"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:r0lAMg/kGtmVGm8436A7iUha3/U=
In-Reply-To: <m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 19 Aug 2021 16:44 UTC

On 2021-08-19 09:40, olcott wrote:
> On 8/19/2021 10:30 AM, André G. Isaak wrote:

>> No one is 'ignoring key words'. What you state above is simply wrong.
>>
>> First, your H *never* acts as a pure simulator. A pure simulator would
>> behave as follows:
>>
>
> The behavior of H while H is in pure simulation mode is computationally
> equivalent to the behavior of a pure simulator in that while H is in
> pure simulation mode it has no effect what-so-ever on the behavior of
> its input.

So first you complain about people 'ignoring your words', and then you
completely ignore all of the points I make below and simply repeat your
assertion?

>
>> (1) fetch an opcode
>> (2) emulate that opcode on the operands which follow
>> (4) advance to the next opcode and go back to step (1)
>>
>> Your H behaves as follows:
>>
>> (1) fetch an opcode
>> (2) emulate that opcode on the operands which follow
>> (3) decide whether to continue the simulation or not
>>
>>     (4a) if we decide not to continue, abort the simulation.
>>     (4b) if we decide to continue, advance to the next opcode and go back
>>          to step (1)

Do you not see the crucial difference between the above two?

>> A pure simulator doesn't contain step (3). And step (3) means that
>> after *every* instruction there is a potential for the decider to have
>> an effect on the simulation of its input.
>>
>> When the input to H contains another call to H (call it H2), that
>> begins a *new* simulation and every single step of that simulation
>> includes step (3) which has the potential to abort the simulation.
>>
>> We can say that your H 'sort of' acts like a pure simulator at each
>> step where, in step (3), it decides to continue with the simulation.
>> But when your H *ignores* the instructions in H2, it never sees those
>> decisions about whether to continue with the simulation or not.
>>
>> This is exactly why your H(P, P) generates the wrong answer.
>>
>> When we execute P(P) it halts. Why? Because at some point in the
>> simulation of P within P(P) step (3) of the simulation decides to
>> abort the simulation.
>>
>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>> crucial decision made by P to abort the simulation.
>>
>> Its perfectly legitimate for H to ignore its *own* code. After all,
>> its own code isn't part of the input which it is analyzing. But it
>> cannot ignore H2 since that *is* part of the input which it is analyzing.
>>
>> André
>>
>
>

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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

<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com>

 copy mid

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

 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: Thu, 19 Aug 2021 11:52:25 -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>
<ZMYSI.11$Oz2.8@fx47.iad> <TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com>
<EcZSI.233$kr4.37@fx48.iad> <XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com>
<utZSI.8$LV.5@fx05.iad> <B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com>
<mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com>
<Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com>
<MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 11:52:24 -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: <sfm1qb$f4u$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com>
Lines: 91
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-dCaTS2B93q7C4hcQeOwOdwRWazSCNdRwyQbYs6s+PTc6UAviQyEe7Kg7l0IX3J2HIrIZkQK2P13cLKD!4p7YNpav2x0POl//xVAn0l2KyA8nH3G7Wq1xVfjKFk5q0hakI16ImMvfvAfnhvGcG1emM297bj56!D/M=
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: 5496
 by: olcott - Thu, 19 Aug 2021 16:52 UTC

On 8/19/2021 11:44 AM, André G. Isaak wrote:
> On 2021-08-19 09:40, olcott wrote:
>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>
>>> No one is 'ignoring key words'. What you state above is simply wrong.
>>>
>>> First, your H *never* acts as a pure simulator. A pure simulator
>>> would behave as follows:
>>>
>>
>> The behavior of H while H is in pure simulation mode is
>> computationally equivalent to the behavior of a pure simulator in that
>> while H is in pure simulation mode it has no effect what-so-ever on
>> the behavior of its input.
>
> So first you complain about people 'ignoring your words', and then you
> completely ignore all of the points I make below and simply repeat your
> assertion?
>

Do you understand what the term: "computationally equivalent" means?

Do you understand that the behavior of H while H is in pure simulation
mode is not the same as the behavior of H while H is NOT in pure
simulation mode?

You are very obviously merely glancing at my words before artficially
contriving a rebuttal that does not carefully take into account every
meaning of every word that I said.

I count this carelessness as dishonesty and no mere honest mistake.

>>
>>> (1) fetch an opcode
>>> (2) emulate that opcode on the operands which follow
>>> (4) advance to the next opcode and go back to step (1)
>>>
>>> Your H behaves as follows:
>>>
>>> (1) fetch an opcode
>>> (2) emulate that opcode on the operands which follow
>>> (3) decide whether to continue the simulation or not
>>>
>>>     (4a) if we decide not to continue, abort the simulation.
>>>     (4b) if we decide to continue, advance to the next opcode and go
>>> back
>>>          to step (1)
>
> Do you not see the crucial difference between the above two?
>
>>> A pure simulator doesn't contain step (3). And step (3) means that
>>> after *every* instruction there is a potential for the decider to
>>> have an effect on the simulation of its input.
>>>
>>> When the input to H contains another call to H (call it H2), that
>>> begins a *new* simulation and every single step of that simulation
>>> includes step (3) which has the potential to abort the simulation.
>>>
>>> We can say that your H 'sort of' acts like a pure simulator at each
>>> step where, in step (3), it decides to continue with the simulation.
>>> But when your H *ignores* the instructions in H2, it never sees those
>>> decisions about whether to continue with the simulation or not.
>>>
>>> This is exactly why your H(P, P) generates the wrong answer.
>>>
>>> When we execute P(P) it halts. Why? Because at some point in the
>>> simulation of P within P(P) step (3) of the simulation decides to
>>> abort the simulation.
>>>
>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>> crucial decision made by P to abort the simulation.
>>>
>>> Its perfectly legitimate for H to ignore its *own* code. After all,
>>> its own code isn't part of the input which it is analyzing. But it
>>> cannot ignore H2 since that *is* part of the input which it is
>>> analyzing.
>>>
>>> André
>>>
>>
>>
>
>

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

<sfm2ve$p5b$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 11:04:45 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 114
Message-ID: <sfm2ve$p5b$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<TdqdnUhYw5KvwYH8nZ2dnUU7-ffNnZ2d@giganews.com> <EcZSI.233$kr4.37@fx48.iad>
<XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad>
<B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad>
<s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad>
<8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad>
<QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad>
<1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad>
<Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Aug 2021 17:04:47 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="34f895952f8e95c031c9a45fb317058b";
logging-data="25771"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18HIXVXlYPQ7qsjEiff/BYA"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:YSxQSxEnOIt+UvdvfoywmBtmL5A=
In-Reply-To: <S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 19 Aug 2021 17:04 UTC

On 2021-08-19 10:52, olcott wrote:
> On 8/19/2021 11:44 AM, André G. Isaak wrote:
>> On 2021-08-19 09:40, olcott wrote:
>>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>>
>>>> No one is 'ignoring key words'. What you state above is simply wrong.
>>>>
>>>> First, your H *never* acts as a pure simulator. A pure simulator
>>>> would behave as follows:
>>>>
>>>
>>> The behavior of H while H is in pure simulation mode is
>>> computationally equivalent to the behavior of a pure simulator in
>>> that while H is in pure simulation mode it has no effect what-so-ever
>>> on the behavior of its input.
>>
>> So first you complain about people 'ignoring your words', and then you
>> completely ignore all of the points I make below and simply repeat
>> your assertion?
>>
>
> Do you understand what the term: "computationally equivalent" means?
>
> Do you understand that the behavior of H while H is in pure simulation
> mode is not the same as the behavior of H while H is NOT in pure
> simulation mode?

Maybe you should reread my original post. The points below were all in
response to your claim that:

"WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
ITS INPUT. "

There's no mention in the above of H acting in 'pure simulation mode'. H
is clearly acting as a halt decider in the above case.

And you need to clarify what you mean by 'mode'. You keep talking about
your H running in different 'modes' without clarifying how you tell H
what 'mode' to operate in. I am assuming your 'pure simulator mode' is
simply H with the halt decision code commented out. What happens in this
'mode' has no bearing on what happens in 'halt decider mode', which is
the only thing we are actually concerned with.

It's fine to change the OUTERMOST H to 'pure simulator mode' to test the
results of H, but if you also change the H inside P to 'pure simulator
mode', then you are simulating an entirely different computation from
the one which H is being asked about which renders the results of that
test entirely meaningless.

> You are very obviously merely glancing at my words before artficially
> contriving a rebuttal that does not carefully take into account every
> meaning of every word that I said.
>
> I count this carelessness as dishonesty and no mere honest mistake.
>
>
>>>
>>>> (1) fetch an opcode
>>>> (2) emulate that opcode on the operands which follow
>>>> (4) advance to the next opcode and go back to step (1)
>>>>
>>>> Your H behaves as follows:
>>>>
>>>> (1) fetch an opcode
>>>> (2) emulate that opcode on the operands which follow
>>>> (3) decide whether to continue the simulation or not
>>>>
>>>>     (4a) if we decide not to continue, abort the simulation.
>>>>     (4b) if we decide to continue, advance to the next opcode and go
>>>> back
>>>>          to step (1)
>>
>> Do you not see the crucial difference between the above two?
>>
>>>> A pure simulator doesn't contain step (3). And step (3) means that
>>>> after *every* instruction there is a potential for the decider to
>>>> have an effect on the simulation of its input.
>>>>
>>>> When the input to H contains another call to H (call it H2), that
>>>> begins a *new* simulation and every single step of that simulation
>>>> includes step (3) which has the potential to abort the simulation.
>>>>
>>>> We can say that your H 'sort of' acts like a pure simulator at each
>>>> step where, in step (3), it decides to continue with the simulation.
>>>> But when your H *ignores* the instructions in H2, it never sees
>>>> those decisions about whether to continue with the simulation or not.
>>>>
>>>> This is exactly why your H(P, P) generates the wrong answer.
>>>>
>>>> When we execute P(P) it halts. Why? Because at some point in the
>>>> simulation of P within P(P) step (3) of the simulation decides to
>>>> abort the simulation.
>>>>
>>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>>> crucial decision made by P to abort the simulation.
>>>>
>>>> Its perfectly legitimate for H to ignore its *own* code. After all,
>>>> its own code isn't part of the input which it is analyzing. But it
>>>> cannot ignore H2 since that *is* part of the input which it is
>>>> analyzing.
>>>>
>>>> André
>>>>
>>>
>>>
>>
>>
>
>

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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

<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 12:13:36 -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> <EcZSI.233$kr4.37@fx48.iad> <XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad> <B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com> <8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com> <1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com> <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com> <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me> <m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me> <S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 12:13:36 -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: <sfm2ve$p5b$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com>
Lines: 137
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-mbZHi2PWS5HixkVqcr4eCduolVCuXqtzAx+Cm19MxlCmF6U8l/JVRPIediTfim4ME6gflnCIgNBEido!0w5DS/ipgIHJoA0MmyCvxF/vW9eRslO1jfg9MNBHu3ciTO7fiJG36L+hhRiGwaWqg22mziLQ0loc!3NQ=
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: 7402
 by: olcott - Thu, 19 Aug 2021 17:13 UTC

On 8/19/2021 12:04 PM, André G. Isaak wrote:
> On 2021-08-19 10:52, olcott wrote:
>> On 8/19/2021 11:44 AM, André G. Isaak wrote:
>>> On 2021-08-19 09:40, olcott wrote:
>>>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>>>
>>>>> No one is 'ignoring key words'. What you state above is simply wrong.
>>>>>
>>>>> First, your H *never* acts as a pure simulator. A pure simulator
>>>>> would behave as follows:
>>>>>
>>>>
>>>> The behavior of H while H is in pure simulation mode is
>>>> computationally equivalent to the behavior of a pure simulator in
>>>> that while H is in pure simulation mode it has no effect
>>>> what-so-ever on the behavior of its input.
>>>
>>> So first you complain about people 'ignoring your words', and then
>>> you completely ignore all of the points I make below and simply
>>> repeat your assertion?
>>>
>>
>> Do you understand what the term: "computationally equivalent" means?
>>
>> Do you understand that the behavior of H while H is in pure simulation
>> mode is not the same as the behavior of H while H is NOT in pure
>> simulation mode?
>
> Maybe you should reread my original post. The points below were all in
> response to your claim that:
>
> "WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
> ITS INPUT. "
>
> There's no mention in the above of H acting in 'pure simulation mode'. H
> is clearly acting as a halt decider in the above case.

WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
ITS INPUT.

WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY EFFECT
ON THE BEHAVIOR OF ITS INPUT.

WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.

Try and find a specific flaw in that, there are one.

Changing the subject to a different subject is also an act of dishonesty
that I call a dishonest dodge.

>
> And you need to clarify what you mean by 'mode'. You keep talking about
> your H running in different 'modes' without clarifying how you tell H
> what 'mode' to operate in. I am assuming your 'pure simulator mode' is
> simply H with the halt decision code commented out. What happens in this
> 'mode' has no bearing on what happens in 'halt decider mode', which is
> the only thing we are actually concerned with.
>
> It's fine to change the OUTERMOST H to 'pure simulator mode' to test the
> results of H, but if you also change the H inside P to 'pure simulator
> mode', then you are simulating an entirely different computation from
> the one which H is being asked about which renders the results of that
> test entirely meaningless.
>
>> You are very obviously merely glancing at my words before artficially
>> contriving a rebuttal that does not carefully take into account every
>> meaning of every word that I said.
>>
>> I count this carelessness as dishonesty and no mere honest mistake.
>>
>>
>>>>
>>>>> (1) fetch an opcode
>>>>> (2) emulate that opcode on the operands which follow
>>>>> (4) advance to the next opcode and go back to step (1)
>>>>>
>>>>> Your H behaves as follows:
>>>>>
>>>>> (1) fetch an opcode
>>>>> (2) emulate that opcode on the operands which follow
>>>>> (3) decide whether to continue the simulation or not
>>>>>
>>>>>     (4a) if we decide not to continue, abort the simulation.
>>>>>     (4b) if we decide to continue, advance to the next opcode and
>>>>> go back
>>>>>          to step (1)
>>>
>>> Do you not see the crucial difference between the above two?
>>>
>>>>> A pure simulator doesn't contain step (3). And step (3) means that
>>>>> after *every* instruction there is a potential for the decider to
>>>>> have an effect on the simulation of its input.
>>>>>
>>>>> When the input to H contains another call to H (call it H2), that
>>>>> begins a *new* simulation and every single step of that simulation
>>>>> includes step (3) which has the potential to abort the simulation.
>>>>>
>>>>> We can say that your H 'sort of' acts like a pure simulator at each
>>>>> step where, in step (3), it decides to continue with the
>>>>> simulation. But when your H *ignores* the instructions in H2, it
>>>>> never sees those decisions about whether to continue with the
>>>>> simulation or not.
>>>>>
>>>>> This is exactly why your H(P, P) generates the wrong answer.
>>>>>
>>>>> When we execute P(P) it halts. Why? Because at some point in the
>>>>> simulation of P within P(P) step (3) of the simulation decides to
>>>>> abort the simulation.
>>>>>
>>>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>>>> crucial decision made by P to abort the simulation.
>>>>>
>>>>> Its perfectly legitimate for H to ignore its *own* code. After all,
>>>>> its own code isn't part of the input which it is analyzing. But it
>>>>> cannot ignore H2 since that *is* part of the input which it is
>>>>> analyzing.
>>>>>
>>>>> André
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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

<sfm406$1c3$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 11:22:12 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 155
Message-ID: <sfm406$1c3$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<XNudnXSIDcuj_IH8nZ2dnUU7-efNnZ2d@giganews.com> <utZSI.8$LV.5@fx05.iad>
<B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com> <mGZSI.5$S25.3@fx11.iad>
<s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com> <Fm_SI.15$Oz2.13@fx47.iad>
<8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad>
<QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad>
<1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad>
<Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Aug 2021 17:22:14 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="34f895952f8e95c031c9a45fb317058b";
logging-data="1411"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PpltXmisRInaxQ+72D/QR"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:RuTiochc7qcc6IDePU9CieQHYX4=
In-Reply-To: <rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 19 Aug 2021 17:22 UTC

On 2021-08-19 11:13, olcott wrote:
> On 8/19/2021 12:04 PM, André G. Isaak wrote:
>> On 2021-08-19 10:52, olcott wrote:
>>> On 8/19/2021 11:44 AM, André G. Isaak wrote:
>>>> On 2021-08-19 09:40, olcott wrote:
>>>>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>>>>
>>>>>> No one is 'ignoring key words'. What you state above is simply wrong.
>>>>>>
>>>>>> First, your H *never* acts as a pure simulator. A pure simulator
>>>>>> would behave as follows:
>>>>>>
>>>>>
>>>>> The behavior of H while H is in pure simulation mode is
>>>>> computationally equivalent to the behavior of a pure simulator in
>>>>> that while H is in pure simulation mode it has no effect
>>>>> what-so-ever on the behavior of its input.
>>>>
>>>> So first you complain about people 'ignoring your words', and then
>>>> you completely ignore all of the points I make below and simply
>>>> repeat your assertion?
>>>>
>>>
>>> Do you understand what the term: "computationally equivalent" means?
>>>
>>> Do you understand that the behavior of H while H is in pure
>>> simulation mode is not the same as the behavior of H while H is NOT
>>> in pure simulation mode?
>>
>> Maybe you should reread my original post. The points below were all in
>> response to your claim that:
>>
>> "WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>> OF ITS INPUT. "
>>
>> There's no mention in the above of H acting in 'pure simulation mode'.
>> H is clearly acting as a halt decider in the above case.
>
>
> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
> ITS INPUT.

Which is false, as I explain in the points below which you continue to
ignore.

> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY EFFECT
> ON THE BEHAVIOR OF ITS INPUT.

Since it isn't acting as a pure simulator, this is also false. See the
explanation in the points below which you continue to ignore.

> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
> NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.

Which, again, is false. See the explanation in the points below which
you continue to ignore.

> Try and find a specific flaw in that, there are one.
>
> Changing the subject to a different subject is also an act of dishonesty
> that I call a dishonest dodge.

Since the points made below all *specifically* address the points you
made above, how is that 'changing the subject'? *You* changed the
subject by talking about 'pure simulator mode'

>
>>
>> And you need to clarify what you mean by 'mode'. You keep talking
>> about your H running in different 'modes' without clarifying how you
>> tell H what 'mode' to operate in. I am assuming your 'pure simulator
>> mode' is simply H with the halt decision code commented out. What
>> happens in this 'mode' has no bearing on what happens in 'halt decider
>> mode', which is the only thing we are actually concerned with.

And you still need to address the above question.

André

>> It's fine to change the OUTERMOST H to 'pure simulator mode' to test
>> the results of H, but if you also change the H inside P to 'pure
>> simulator mode', then you are simulating an entirely different
>> computation from the one which H is being asked about which renders
>> the results of that test entirely meaningless.
>>
>>> You are very obviously merely glancing at my words before artficially
>>> contriving a rebuttal that does not carefully take into account every
>>> meaning of every word that I said.
>>>
>>> I count this carelessness as dishonesty and no mere honest mistake.
>>>
>>>
>>>>>
>>>>>> (1) fetch an opcode
>>>>>> (2) emulate that opcode on the operands which follow
>>>>>> (4) advance to the next opcode and go back to step (1)
>>>>>>
>>>>>> Your H behaves as follows:
>>>>>>
>>>>>> (1) fetch an opcode
>>>>>> (2) emulate that opcode on the operands which follow
>>>>>> (3) decide whether to continue the simulation or not
>>>>>>
>>>>>>     (4a) if we decide not to continue, abort the simulation.
>>>>>>     (4b) if we decide to continue, advance to the next opcode and
>>>>>> go back
>>>>>>          to step (1)
>>>>
>>>> Do you not see the crucial difference between the above two?
>>>>
>>>>>> A pure simulator doesn't contain step (3). And step (3) means that
>>>>>> after *every* instruction there is a potential for the decider to
>>>>>> have an effect on the simulation of its input.
>>>>>>
>>>>>> When the input to H contains another call to H (call it H2), that
>>>>>> begins a *new* simulation and every single step of that simulation
>>>>>> includes step (3) which has the potential to abort the simulation.
>>>>>>
>>>>>> We can say that your H 'sort of' acts like a pure simulator at
>>>>>> each step where, in step (3), it decides to continue with the
>>>>>> simulation. But when your H *ignores* the instructions in H2, it
>>>>>> never sees those decisions about whether to continue with the
>>>>>> simulation or not.
>>>>>>
>>>>>> This is exactly why your H(P, P) generates the wrong answer.
>>>>>>
>>>>>> When we execute P(P) it halts. Why? Because at some point in the
>>>>>> simulation of P within P(P) step (3) of the simulation decides to
>>>>>> abort the simulation.
>>>>>>
>>>>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>>>>> crucial decision made by P to abort the simulation.
>>>>>>
>>>>>> Its perfectly legitimate for H to ignore its *own* code. After
>>>>>> all, its own code isn't part of the input which it is analyzing.
>>>>>> But it cannot ignore H2 since that *is* part of the input which it
>>>>>> is analyzing.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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

<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 13:35:32 -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>
<utZSI.8$LV.5@fx05.iad> <B_udnbM9Dd6R-IH8nZ2dnUU7-R-dnZ2d@giganews.com>
<mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com>
<Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com>
<MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 13:35:31 -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: <sfm406$1c3$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com>
Lines: 170
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-248q1i4i02ppUcttUclmKAdvluXb6bApMQKxnbwYrGkaxTW3o2I5nOJS9qIuOvcrgkmjfunSr/NtJg8!EKe9oucJHAy8pNQbiqGunezTNUOY/k4U+ItDorqafQMMrHmPpl8kkJ+mbXlky0zwY+9TXdLbrKBq!mBI=
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: 8707
 by: olcott - Thu, 19 Aug 2021 18:35 UTC

On 8/19/2021 12:22 PM, André G. Isaak wrote:
> On 2021-08-19 11:13, olcott wrote:
>> On 8/19/2021 12:04 PM, André G. Isaak wrote:
>>> On 2021-08-19 10:52, olcott wrote:
>>>> On 8/19/2021 11:44 AM, André G. Isaak wrote:
>>>>> On 2021-08-19 09:40, olcott wrote:
>>>>>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>>>>>
>>>>>>> No one is 'ignoring key words'. What you state above is simply
>>>>>>> wrong.
>>>>>>>
>>>>>>> First, your H *never* acts as a pure simulator. A pure simulator
>>>>>>> would behave as follows:
>>>>>>>
>>>>>>
>>>>>> The behavior of H while H is in pure simulation mode is
>>>>>> computationally equivalent to the behavior of a pure simulator in
>>>>>> that while H is in pure simulation mode it has no effect
>>>>>> what-so-ever on the behavior of its input.
>>>>>
>>>>> So first you complain about people 'ignoring your words', and then
>>>>> you completely ignore all of the points I make below and simply
>>>>> repeat your assertion?
>>>>>
>>>>
>>>> Do you understand what the term: "computationally equivalent" means?
>>>>
>>>> Do you understand that the behavior of H while H is in pure
>>>> simulation mode is not the same as the behavior of H while H is NOT
>>>> in pure simulation mode?
>>>
>>> Maybe you should reread my original post. The points below were all
>>> in response to your claim that:
>>>
>>> "WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>> OF ITS INPUT. "
>>>
>>> There's no mention in the above of H acting in 'pure simulation
>>> mode'. H is clearly acting as a halt decider in the above case.
>>
>>
>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
>> ITS INPUT.
>
> Which is false, as I explain in the points below which you continue to
> ignore.
>

WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
ITS INPUT (before it switches to halt decider mode) its act of merely
examining the behavior of its input cannot possibly have any effect
what-so-ever on the behavior of this input.

Has this exceeded your capacity to understand?

>> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY
>> EFFECT ON THE BEHAVIOR OF ITS INPUT.
>
> Since it isn't acting as a pure simulator, this is also false. See the
> explanation in the points below which you continue to ignore.
>
>> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT H
>> NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>
> Which, again, is false. See the explanation in the points below which
> you continue to ignore.
>
>> Try and find a specific flaw in that, there are one.
>>
>> Changing the subject to a different subject is also an act of
>> dishonesty that I call a dishonest dodge.
>
> Since the points made below all *specifically* address the points you
> made above, how is that 'changing the subject'? *You* changed the
> subject by talking about 'pure simulator mode'
>
>>
>>>
>>> And you need to clarify what you mean by 'mode'. You keep talking
>>> about your H running in different 'modes' without clarifying how you
>>> tell H what 'mode' to operate in. I am assuming your 'pure simulator
>>> mode' is simply H with the halt decision code commented out. What
>>> happens in this 'mode' has no bearing on what happens in 'halt
>>> decider mode', which is the only thing we are actually concerned with.
>
> And you still need to address the above question.
>
> André
>
>>> It's fine to change the OUTERMOST H to 'pure simulator mode' to test
>>> the results of H, but if you also change the H inside P to 'pure
>>> simulator mode', then you are simulating an entirely different
>>> computation from the one which H is being asked about which renders
>>> the results of that test entirely meaningless.
>>>
>>>> You are very obviously merely glancing at my words before
>>>> artficially contriving a rebuttal that does not carefully take into
>>>> account every meaning of every word that I said.
>>>>
>>>> I count this carelessness as dishonesty and no mere honest mistake.
>>>>
>>>>
>>>>>>
>>>>>>> (1) fetch an opcode
>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>> (4) advance to the next opcode and go back to step (1)
>>>>>>>
>>>>>>> Your H behaves as follows:
>>>>>>>
>>>>>>> (1) fetch an opcode
>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>> (3) decide whether to continue the simulation or not
>>>>>>>
>>>>>>>     (4a) if we decide not to continue, abort the simulation.
>>>>>>>     (4b) if we decide to continue, advance to the next opcode and
>>>>>>> go back
>>>>>>>          to step (1)
>>>>>
>>>>> Do you not see the crucial difference between the above two?
>>>>>
>>>>>>> A pure simulator doesn't contain step (3). And step (3) means
>>>>>>> that after *every* instruction there is a potential for the
>>>>>>> decider to have an effect on the simulation of its input.
>>>>>>>
>>>>>>> When the input to H contains another call to H (call it H2), that
>>>>>>> begins a *new* simulation and every single step of that
>>>>>>> simulation includes step (3) which has the potential to abort the
>>>>>>> simulation.
>>>>>>>
>>>>>>> We can say that your H 'sort of' acts like a pure simulator at
>>>>>>> each step where, in step (3), it decides to continue with the
>>>>>>> simulation. But when your H *ignores* the instructions in H2, it
>>>>>>> never sees those decisions about whether to continue with the
>>>>>>> simulation or not.
>>>>>>>
>>>>>>> This is exactly why your H(P, P) generates the wrong answer.
>>>>>>>
>>>>>>> When we execute P(P) it halts. Why? Because at some point in the
>>>>>>> simulation of P within P(P) step (3) of the simulation decides to
>>>>>>> abort the simulation.
>>>>>>>
>>>>>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>>>>>> crucial decision made by P to abort the simulation.
>>>>>>>
>>>>>>> Its perfectly legitimate for H to ignore its *own* code. After
>>>>>>> all, its own code isn't part of the input which it is analyzing.
>>>>>>> But it cannot ignore H2 since that *is* part of the input which
>>>>>>> it is analyzing.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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

<sfm90e$6rr$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 12:47:40 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 187
Message-ID: <sfm90e$6rr$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com>
<Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com>
<MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Aug 2021 18:47:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="34f895952f8e95c031c9a45fb317058b";
logging-data="7035"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+s94wScVZlFMbRQckkNTwM"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:rvi7XeSdxq2tznXaN3zdM5DG1gs=
In-Reply-To: <crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 19 Aug 2021 18:47 UTC

On 2021-08-19 12:35, olcott wrote:
> On 8/19/2021 12:22 PM, André G. Isaak wrote:
>> On 2021-08-19 11:13, olcott wrote:
>>> On 8/19/2021 12:04 PM, André G. Isaak wrote:
>>>> On 2021-08-19 10:52, olcott wrote:
>>>>> On 8/19/2021 11:44 AM, André G. Isaak wrote:
>>>>>> On 2021-08-19 09:40, olcott wrote:
>>>>>>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>>>>>>
>>>>>>>> No one is 'ignoring key words'. What you state above is simply
>>>>>>>> wrong.
>>>>>>>>
>>>>>>>> First, your H *never* acts as a pure simulator. A pure simulator
>>>>>>>> would behave as follows:
>>>>>>>>
>>>>>>>
>>>>>>> The behavior of H while H is in pure simulation mode is
>>>>>>> computationally equivalent to the behavior of a pure simulator in
>>>>>>> that while H is in pure simulation mode it has no effect
>>>>>>> what-so-ever on the behavior of its input.
>>>>>>
>>>>>> So first you complain about people 'ignoring your words', and then
>>>>>> you completely ignore all of the points I make below and simply
>>>>>> repeat your assertion?
>>>>>>
>>>>>
>>>>> Do you understand what the term: "computationally equivalent" means?
>>>>>
>>>>> Do you understand that the behavior of H while H is in pure
>>>>> simulation mode is not the same as the behavior of H while H is NOT
>>>>> in pure simulation mode?
>>>>
>>>> Maybe you should reread my original post. The points below were all
>>>> in response to your claim that:
>>>>
>>>> "WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>>> OF ITS INPUT. "
>>>>
>>>> There's no mention in the above of H acting in 'pure simulation
>>>> mode'. H is clearly acting as a halt decider in the above case.
>>>
>>>
>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>> OF ITS INPUT.
>>
>> Which is false, as I explain in the points below which you continue to
>> ignore.
>>
>
> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
> ITS INPUT (before it switches to halt decider mode) its act of merely
> examining the behavior of its input cannot possibly have any effect
> what-so-ever on the behavior of this input.

And, once again, you simply reiterate your position without actually
addressing the points I make below.

Most importantly, you need to answer my question about what you mean by
'mode'. Previously, you seemed to be suggesting your H had two separate
modes in which it runs in either one or the other.

Now you seem to be suggesting it can switch modes mid-execution.

If by 'switches to halt decider mode' you simply mean 'decides to
abort', then ALL of the objections I make below still stand and you need
to address them.

If you mean something else, you really need to explain what it means to
'switch modes' and what causes H to switch from one mode to another.

> Has this exceeded your capacity to understand?
>
>>> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY
>>> EFFECT ON THE BEHAVIOR OF ITS INPUT.
>>
>> Since it isn't acting as a pure simulator, this is also false. See the
>> explanation in the points below which you continue to ignore.
>>
>>> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT
>>> H NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>>
>> Which, again, is false. See the explanation in the points below which
>> you continue to ignore.
>>
>>> Try and find a specific flaw in that, there are one.
>>>
>>> Changing the subject to a different subject is also an act of
>>> dishonesty that I call a dishonest dodge.
>>
>> Since the points made below all *specifically* address the points you
>> made above, how is that 'changing the subject'? *You* changed the
>> subject by talking about 'pure simulator mode'
>>
>>>
>>>>
>>>> And you need to clarify what you mean by 'mode'. You keep talking
>>>> about your H running in different 'modes' without clarifying how you
>>>> tell H what 'mode' to operate in. I am assuming your 'pure simulator
>>>> mode' is simply H with the halt decision code commented out. What
>>>> happens in this 'mode' has no bearing on what happens in 'halt
>>>> decider mode', which is the only thing we are actually concerned with.
>>
>> And you still need to address the above question.
>>
>> André
>>
>>>> It's fine to change the OUTERMOST H to 'pure simulator mode' to test
>>>> the results of H, but if you also change the H inside P to 'pure
>>>> simulator mode', then you are simulating an entirely different
>>>> computation from the one which H is being asked about which renders
>>>> the results of that test entirely meaningless.
>>>>
>>>>> You are very obviously merely glancing at my words before
>>>>> artficially contriving a rebuttal that does not carefully take into
>>>>> account every meaning of every word that I said.
>>>>>
>>>>> I count this carelessness as dishonesty and no mere honest mistake.
>>>>>
>>>>>
>>>>>>>
>>>>>>>> (1) fetch an opcode
>>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>>> (4) advance to the next opcode and go back to step (1)
>>>>>>>>
>>>>>>>> Your H behaves as follows:
>>>>>>>>
>>>>>>>> (1) fetch an opcode
>>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>>> (3) decide whether to continue the simulation or not
>>>>>>>>
>>>>>>>>     (4a) if we decide not to continue, abort the simulation.
>>>>>>>>     (4b) if we decide to continue, advance to the next opcode
>>>>>>>> and go back
>>>>>>>>          to step (1)
>>>>>>
>>>>>> Do you not see the crucial difference between the above two?
>>>>>>
>>>>>>>> A pure simulator doesn't contain step (3). And step (3) means
>>>>>>>> that after *every* instruction there is a potential for the
>>>>>>>> decider to have an effect on the simulation of its input.
>>>>>>>>
>>>>>>>> When the input to H contains another call to H (call it H2),
>>>>>>>> that begins a *new* simulation and every single step of that
>>>>>>>> simulation includes step (3) which has the potential to abort
>>>>>>>> the simulation.
>>>>>>>>
>>>>>>>> We can say that your H 'sort of' acts like a pure simulator at
>>>>>>>> each step where, in step (3), it decides to continue with the
>>>>>>>> simulation. But when your H *ignores* the instructions in H2, it
>>>>>>>> never sees those decisions about whether to continue with the
>>>>>>>> simulation or not.
>>>>>>>>
>>>>>>>> This is exactly why your H(P, P) generates the wrong answer.
>>>>>>>>
>>>>>>>> When we execute P(P) it halts. Why? Because at some point in the
>>>>>>>> simulation of P within P(P) step (3) of the simulation decides
>>>>>>>> to abort the simulation.
>>>>>>>>
>>>>>>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>>>>>>> crucial decision made by P to abort the simulation.
>>>>>>>>
>>>>>>>> Its perfectly legitimate for H to ignore its *own* code. After
>>>>>>>> all, its own code isn't part of the input which it is analyzing.
>>>>>>>> But it cannot ignore H2 since that *is* part of the input which
>>>>>>>> it is analyzing.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


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?

<6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 13:55:07 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<mGZSI.5$S25.3@fx11.iad> <s8GdnVpbercE94H8nZ2dnUU7-d3NnZ2d@giganews.com>
<Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com>
<MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 13:55:06 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <sfm90e$6rr$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com>
Lines: 203
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MkRqJ16b9Inag+mZqmSPf+qU6l+0xesAnoBmN/mcv7NyfrZx1Ckntlc6Qfy+aoFXqP1ZKnhYfatpooj!X4spQGhOINTAyn8qk8RB4zcMMN0PrPhBMximXoPiL8pnEB/pI36fNhzUrupG3f9xfVQj4aYM3F8f!/Ik=
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: 10171
 by: olcott - Thu, 19 Aug 2021 18:55 UTC

On 8/19/2021 1:47 PM, André G. Isaak wrote:
> On 2021-08-19 12:35, olcott wrote:
>> On 8/19/2021 12:22 PM, André G. Isaak wrote:
>>> On 2021-08-19 11:13, olcott wrote:
>>>> On 8/19/2021 12:04 PM, André G. Isaak wrote:
>>>>> On 2021-08-19 10:52, olcott wrote:
>>>>>> On 8/19/2021 11:44 AM, André G. Isaak wrote:
>>>>>>> On 2021-08-19 09:40, olcott wrote:
>>>>>>>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>>>>>>>
>>>>>>>>> No one is 'ignoring key words'. What you state above is simply
>>>>>>>>> wrong.
>>>>>>>>>
>>>>>>>>> First, your H *never* acts as a pure simulator. A pure
>>>>>>>>> simulator would behave as follows:
>>>>>>>>>
>>>>>>>>
>>>>>>>> The behavior of H while H is in pure simulation mode is
>>>>>>>> computationally equivalent to the behavior of a pure simulator
>>>>>>>> in that while H is in pure simulation mode it has no effect
>>>>>>>> what-so-ever on the behavior of its input.
>>>>>>>
>>>>>>> So first you complain about people 'ignoring your words', and
>>>>>>> then you completely ignore all of the points I make below and
>>>>>>> simply repeat your assertion?
>>>>>>>
>>>>>>
>>>>>> Do you understand what the term: "computationally equivalent" means?
>>>>>>
>>>>>> Do you understand that the behavior of H while H is in pure
>>>>>> simulation mode is not the same as the behavior of H while H is
>>>>>> NOT in pure simulation mode?
>>>>>
>>>>> Maybe you should reread my original post. The points below were all
>>>>> in response to your claim that:
>>>>>
>>>>> "WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE
>>>>> SIMULATOR OF ITS INPUT. "
>>>>>
>>>>> There's no mention in the above of H acting in 'pure simulation
>>>>> mode'. H is clearly acting as a halt decider in the above case.
>>>>
>>>>
>>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>>> OF ITS INPUT.
>>>
>>> Which is false, as I explain in the points below which you continue
>>> to ignore.
>>>
>>
>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
>> ITS INPUT (before it switches to halt decider mode) its act of merely
>> examining the behavior of its input cannot possibly have any effect
>> what-so-ever on the behavior of this input.
>
> And, once again, you simply reiterate your position without actually
> addressing the points I make below.
>

I just proved that your points are totally irrelevant.

> Most importantly, you need to answer my question about what you mean by
> 'mode'. Previously, you seemed to be suggesting your H had two separate
> modes in which it runs in either one or the other.
>
> Now you seem to be suggesting it can switch modes mid-execution.
>
> If by 'switches to halt decider mode' you simply mean 'decides to
> abort', then ALL of the objections I make below still stand and you need
> to address them.
>
> If you mean something else, you really need to explain what it means to
> 'switch modes' and what causes H to switch from one mode to another.
>

H has no effect on the behavior of its input until after it has made its
halt status decision therefore H need not examine its own behavior in
this halt status decision.

It is not that hard, I can't believe that you don't understand this.

>> Has this exceeded your capacity to understand?
>>
>>>> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY
>>>> EFFECT ON THE BEHAVIOR OF ITS INPUT.
>>>
>>> Since it isn't acting as a pure simulator, this is also false. See
>>> the explanation in the points below which you continue to ignore.
>>>
>>>> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT
>>>> H NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>>>
>>> Which, again, is false. See the explanation in the points below which
>>> you continue to ignore.
>>>
>>>> Try and find a specific flaw in that, there are one.
>>>>
>>>> Changing the subject to a different subject is also an act of
>>>> dishonesty that I call a dishonest dodge.
>>>
>>> Since the points made below all *specifically* address the points you
>>> made above, how is that 'changing the subject'? *You* changed the
>>> subject by talking about 'pure simulator mode'
>>>
>>>>
>>>>>
>>>>> And you need to clarify what you mean by 'mode'. You keep talking
>>>>> about your H running in different 'modes' without clarifying how
>>>>> you tell H what 'mode' to operate in. I am assuming your 'pure
>>>>> simulator mode' is simply H with the halt decision code commented
>>>>> out. What happens in this 'mode' has no bearing on what happens in
>>>>> 'halt decider mode', which is the only thing we are actually
>>>>> concerned with.
>>>
>>> And you still need to address the above question.
>>>
>>> André
>>>
>>>>> It's fine to change the OUTERMOST H to 'pure simulator mode' to
>>>>> test the results of H, but if you also change the H inside P to
>>>>> 'pure simulator mode', then you are simulating an entirely
>>>>> different computation from the one which H is being asked about
>>>>> which renders the results of that test entirely meaningless.
>>>>>
>>>>>> You are very obviously merely glancing at my words before
>>>>>> artficially contriving a rebuttal that does not carefully take
>>>>>> into account every meaning of every word that I said.
>>>>>>
>>>>>> I count this carelessness as dishonesty and no mere honest mistake.
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> (1) fetch an opcode
>>>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>>>> (4) advance to the next opcode and go back to step (1)
>>>>>>>>>
>>>>>>>>> Your H behaves as follows:
>>>>>>>>>
>>>>>>>>> (1) fetch an opcode
>>>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>>>> (3) decide whether to continue the simulation or not
>>>>>>>>>
>>>>>>>>>     (4a) if we decide not to continue, abort the simulation.
>>>>>>>>>     (4b) if we decide to continue, advance to the next opcode
>>>>>>>>> and go back
>>>>>>>>>          to step (1)
>>>>>>>
>>>>>>> Do you not see the crucial difference between the above two?
>>>>>>>
>>>>>>>>> A pure simulator doesn't contain step (3). And step (3) means
>>>>>>>>> that after *every* instruction there is a potential for the
>>>>>>>>> decider to have an effect on the simulation of its input.
>>>>>>>>>
>>>>>>>>> When the input to H contains another call to H (call it H2),
>>>>>>>>> that begins a *new* simulation and every single step of that
>>>>>>>>> simulation includes step (3) which has the potential to abort
>>>>>>>>> the simulation.
>>>>>>>>>
>>>>>>>>> We can say that your H 'sort of' acts like a pure simulator at
>>>>>>>>> each step where, in step (3), it decides to continue with the
>>>>>>>>> simulation. But when your H *ignores* the instructions in H2,
>>>>>>>>> it never sees those decisions about whether to continue with
>>>>>>>>> the simulation or not.
>>>>>>>>>
>>>>>>>>> This is exactly why your H(P, P) generates the wrong answer.
>>>>>>>>>
>>>>>>>>> When we execute P(P) it halts. Why? Because at some point in
>>>>>>>>> the simulation of P within P(P) step (3) of the simulation
>>>>>>>>> decides to abort the simulation.
>>>>>>>>>
>>>>>>>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>>>>>>>> crucial decision made by P to abort the simulation.
>>>>>>>>>
>>>>>>>>> Its perfectly legitimate for H to ignore its *own* code. After
>>>>>>>>> all, its own code isn't part of the input which it is
>>>>>>>>> analyzing. But it cannot ignore H2 since that *is* part of the
>>>>>>>>> input which it is analyzing.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


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?

<871r6pp8hn.fsf@bsb.me.uk>

 copy mid

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

 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: Thu, 19 Aug 2021 19:58:12 +0100
Organization: A noiseless patient Spider
Lines: 258
Message-ID: <871r6pp8hn.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<874kbqw62q.fsf@bsb.me.uk>
<W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com>
<87h7fpuf5v.fsf@bsb.me.uk>
<AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk>
<oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87o89usfll.fsf@bsb.me.uk>
<uqadnd39oqwW-ID8nZ2dnUU7-amdnZ2d@giganews.com>
<87sfz6qpk9.fsf@bsb.me.uk>
<PeqdnehLhMapOYD8nZ2dnUU7-YXNnZ2d@giganews.com>
<87k0kiqlmm.fsf@bsb.me.uk>
<GPidnScbL8UfLoD8nZ2dnUU7-ROdnZ2d@giganews.com>
<875yw2qkfb.fsf@bsb.me.uk>
<2q6dnZ-dGIzeIYD8nZ2dnUU7-ffNnZ2d@giganews.com>
<87r1eppoe5.fsf@bsb.me.uk>
<CbSdnazsjJLf6IP8nZ2dnUU7-KfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="392fe0f5b5dd5175e6c48d474637b868";
logging-data="32063"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/k59DYpmOiWoY1oN3J0MtKkeG5v0TEbxY="
Cancel-Lock: sha1:HT1LGYNvM7O9jajuyGSMj7nKTu0=
sha1:ei83mT9rjisvU68g1z1OZY5ioRM=
X-BSB-Auth: 1.fff81e91846d04b6c4d4.20210819195812BST.871r6pp8hn.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 19 Aug 2021 18:58 UTC

olcott <NoOne@NoWhere.com> writes:

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

Hmm... Not sure why I should care about that. Do claim to have a
C function that meets this spec? If so post it (or a linkable object
module) so we can test it.

If not, do you claim you will be able to write such a function?

> Good job on the use of C. My own use of unsigned integers as function
> pointers is unconventional and not as portable. I did this on purpose
> so that x86utm would have a single standard tape element type.
>
> #include <stdint.h>
> #include <stdio.h>
>
> typedef uintptr_t data;
> typedef void (*function)(data);
>
> extern _Bool B(function, data);
>
> void B_hat(data x) { if (H((u32)x, (u32)x)) while (1); }
>
> int main2()
> {
> OutputHex(H((u32)B_hat, (u32)B_hat));
> B_hat((u32)B_hat);
> OutputString("returned");
> }

This shows no function B. And it's not even valid C. How does it help
meet the challenge?

> _B_hat()
> [00000efc](01) 55 push ebp
> [00000efd](02) 8bec mov ebp,esp
> [00000eff](03) 8b4508 mov eax,[ebp+08]
> [00000f02](01) 50 push eax
> [00000f03](03) 8b4d08 mov ecx,[ebp+08]
> [00000f06](01) 51 push ecx
> [00000f07](05) e850feffff call 00000d5c
> [00000f0c](03) 83c408 add esp,+08
> [00000f0f](02) 85c0 test eax,eax
> [00000f11](02) 740b jz 00000f1e
> [00000f13](05) ba01000000 mov edx,00000001
> [00000f18](02) 85d2 test edx,edx
> [00000f1a](02) 7402 jz 00000f1e
> [00000f1c](02) ebf5 jmp 00000f13
> [00000f1e](01) 5d pop ebp
> [00000f1f](01) c3 ret
> Size in bytes:(0036) [00000f1f]
>
> _main2()
> [00000f2c](01) 55 push ebp
> [00000f2d](02) 8bec mov ebp,esp
> [00000f2f](05) 68fc0e0000 push 00000efc
> [00000f34](05) 68fc0e0000 push 00000efc
> [00000f39](05) e81efeffff call 00000d5c
> [00000f3e](03) 83c408 add esp,+08
> [00000f41](01) 50 push eax
> [00000f42](05) e8e5f3ffff call 0000032c
> [00000f47](03) 83c404 add esp,+04
> [00000f4a](05) 68fc0e0000 push 00000efc
> [00000f4f](05) e8a8ffffff call 00000efc
> [00000f54](03) 83c404 add esp,+04
> [00000f57](05) 6823030000 push 00000323
> [00000f5c](05) e8dbf3ffff call 0000033c
> [00000f61](03) 83c404 add esp,+04
> [00000f64](01) 5d pop ebp
> [00000f65](01) c3 ret
> Size in bytes:(0058) [00000f65]
>
> _main()
> [00000f6c](01) 55 push ebp
> [00000f6d](02) 8bec mov ebp,esp
> [00000f6f](05) e8b8ffffff call 00000f2c
> [00000f74](02) 33c0 xor eax,eax
> [00000f76](01) 5d pop ebp
> [00000f77](01) c3 ret
> Size in bytes:(0012) [00000f77]

I can compile the code I posted. What I can't do is write the function
you are not showing the code for. This partial listing does not advance
your case one bit.

> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> ...[00000f6c][00101c0a][00000000] 55 push ebp
> ...[00000f6d][00101c0a][00000000] 8bec mov ebp,esp
> ...[00000f6f][00101c06][00000f74] e8b8ffffff call 00000f2c
> ...[00000f2c][00101c02][00101c0a] 55 push ebp
> ...[00000f2d][00101c02][00101c0a] 8bec mov ebp,esp
> ...[00000f2f][00101bfe][00000efc] 68fc0e0000 push 00000efc
> ...[00000f34][00101bfa][00000efc] 68fc0e0000 push 00000efc
> ...[00000f39][00101bf6][00000f3e] e81efeffff call 00000d5c
>
> Begin Local Halt Decider Simulation at Machine Address:efc
> ...[00000efc][00211caa][00211cae] 55 push ebp
> ...[00000efd][00211caa][00211cae] 8bec mov ebp,esp
> ...[00000eff][00211caa][00211cae] 8b4508 mov eax,[ebp+08]
> ...[00000f02][00211ca6][00000efc] 50 push eax
> ...[00000f03][00211ca6][00000efc] 8b4d08 mov ecx,[ebp+08]
> ...[00000f06][00211ca2][00000efc] 51 push ecx
> ...[00000f07][00211c9e][00000f0c] e850feffff call 00000d5c
> ...[00000efc][0025c6d2][0025c6d6] 55 push ebp
> ...[00000efd][0025c6d2][0025c6d6] 8bec mov ebp,esp
> ...[00000eff][0025c6d2][0025c6d6] 8b4508 mov eax,[ebp+08]
> ...[00000f02][0025c6ce][00000efc] 50 push eax
> ...[00000f03][0025c6ce][00000efc] 8b4d08 mov ecx,[ebp+08]
> ...[00000f06][0025c6ca][00000efc] 51 push ecx
> ...[00000f07][0025c6c6][00000f0c] e850feffff call 00000d5c
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> ...[00000f3e][00101c02][00101c0a] 83c408 add esp,+08
> ...[00000f41][00101bfe][00000000] 50 push eax
> ---[00000f42][00101bfe][00000000] e8e5f3ffff call 0000032c
> 0
> ...[00000f47][00101c02][00101c0a] 83c404 add esp,+04
> ...[00000f4a][00101bfe][00000efc] 68fc0e0000 push 00000efc
> ...[00000f4f][00101bfa][00000f54] e8a8ffffff call 00000efc
> ...[00000efc][00101bf6][00101c02] 55 push ebp
> ...[00000efd][00101bf6][00101c02] 8bec mov ebp,esp
> ...[00000eff][00101bf6][00101c02] 8b4508 mov eax,[ebp+08]
> ...[00000f02][00101bf2][00000efc] 50 push eax
> ...[00000f03][00101bf2][00000efc] 8b4d08 mov ecx,[ebp+08]
> ...[00000f06][00101bee][00000efc] 51 push ecx
> ...[00000f07][00101bea][00000f0c] e850feffff call 00000d5c
>
> Begin Local Halt Decider Simulation at Machine Address:efc
> ...[00000efc][0026c772][0026c776] 55 push ebp
> ...[00000efd][0026c772][0026c776] 8bec mov ebp,esp
> ...[00000eff][0026c772][0026c776] 8b4508 mov eax,[ebp+08]
> ...[00000f02][0026c76e][00000efc] 50 push eax
> ...[00000f03][0026c76e][00000efc] 8b4d08 mov ecx,[ebp+08]
> ...[00000f06][0026c76a][00000efc] 51 push ecx
> ...[00000f07][0026c766][00000f0c] e850feffff call 00000d5c
> ...[00000efc][002b719a][002b719e] 55 push ebp
> ...[00000efd][002b719a][002b719e] 8bec mov ebp,esp
> ...[00000eff][002b719a][002b719e] 8b4508 mov eax,[ebp+08]
> ...[00000f02][002b7196][00000efc] 50 push eax
> ...[00000f03][002b7196][00000efc] 8b4d08 mov ecx,[ebp+08]
> ...[00000f06][002b7192][00000efc] 51 push ecx
> ...[00000f07][002b718e][00000f0c] e850feffff call 00000d5c
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> ...[00000f0c][00101bf6][00101c02] 83c408 add esp,+08
> ...[00000f0f][00101bf6][00101c02] 85c0 test eax,eax
> ...[00000f11][00101bf6][00101c02] 740b jz 00000f1e
> ...[00000f1e][00101bfa][00000f54] 5d pop ebp
> ...[00000f1f][00101bfe][00000efc] c3 ret
> ...[00000f54][00101c02][00101c0a] 83c404 add esp,+04
> ...[00000f57][00101bfe][00000323] 6823030000 push 00000323
> ---[00000f5c][00101bfe][00000323] e8dbf3ffff call 0000033c
> returned
> ...[00000f61][00101c02][00101c0a] 83c404 add esp,+04
> ...[00000f64][00101c06][00000f74] 5d pop ebp
> ...[00000f65][00101c0a][00000000] c3 ret
> ...[00000f74][00101c0a][00000000] 33c0 xor eax,eax
> ...[00000f76][00101c0e][00100000] 5d pop ebp
> ...[00000f77][00101c12][00000008] c3 ret
> Number_of_User_Instructions(2)
> Number of Instructions Executed(47451)


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?

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

 copy mid

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

 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: Thu, 19 Aug 2021 20:01:15 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <87v941nts4.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<874kbqw62q.fsf@bsb.me.uk>
<W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com>
<87h7fpuf5v.fsf@bsb.me.uk>
<AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk>
<oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk>
<U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk>
<W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="392fe0f5b5dd5175e6c48d474637b868";
logging-data="32063"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+iDBD8wtFdIZtH4pkoVYAUqfog51qTZZ8="
Cancel-Lock: sha1:mDSR1FP8/B5vLeRvy6Nobiiph3E=
sha1:5mFSj2UcFpl0+Hzb6B68y7qtr4w=
X-BSB-Auth: 1.cb8fac61773bef84fc5f.20210819200115BST.87v941nts4.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 19 Aug 2021 19:01 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/19/2021 8:29 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/18/2021 9:01 PM, Ben Bacarisse wrote:
>>
>>>> We won't get anywhere if you keep ducking this question. You made a
>>>> false statement in the old thread about this and you won't say if you
>>>> stand by that false statement.
>>>>
>>>> You track record in understanding people is poor. But if you think I
>>>> agreed, so what? I don't agree now regardless of what you think I've
>>>> said in the past. I am allowed to re-state, as clearly as possible, the
>>>> facts of the matter and the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting
>>>> computation. All I am asking is that you be as clear as I am being. Do
>>>> you disagree that the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation?
>>>
>>> I already totally explained all that.
>> I was not asking for an explanation. I said so explicitly. I was
>> asking for an answer to a simple question. Your determined avoidance is
>> very suspicious.
>>
>>> When-so-ever any input to a simulating halt decider would never halt
>>> unless its simulating halt decider stopped simulating it then this
>>> input is correctly decided as never halting.
>>>
>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>> decider stops simulating it.
>>>
>>> Can you figure out whether or not this is a yes or no answer to your
>>> question?
>>
>> No, I can't. As recently as 12th Aug you incorrectly said
>>
>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
> decider stops simulating it, thus conclusively proving that the input
> to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. You were
wrong to say otherwise. The waffle about what would happen unless
something that does happen happens is just so much flannel.

--
Ben.

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

<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>

 copy mid

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

 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: Thu, 19 Aug 2021 14:37:29 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<874kbqw62q.fsf@bsb.me.uk> <W7udnRlZduvgdof8nZ2dnUU7-IPNnZ2d@giganews.com>
<87h7fpuf5v.fsf@bsb.me.uk> <AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk> <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 14:37:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87v941nts4.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
Lines: 76
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-eshD2j4TGKjziaZuOx5b1ZNaY3R4x/jAMUlFQL1dg3SNP7meLXWlxX+fa+wH5kzDpymHMNTbfw67kjy!C9gje8NU1LWXHAzit6FPrVXrRY4/kPwbgYTDzSDvO44OWnCLNG8gRwzUxI/JIKKXHvQipv9FasIg!qG4=
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: 5116
 by: olcott - Thu, 19 Aug 2021 19:37 UTC

On 8/19/2021 2:01 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/19/2021 8:29 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/18/2021 9:01 PM, Ben Bacarisse wrote:
>>>
>>>>> We won't get anywhere if you keep ducking this question. You made a
>>>>> false statement in the old thread about this and you won't say if you
>>>>> stand by that false statement.
>>>>>
>>>>> You track record in understanding people is poor. But if you think I
>>>>> agreed, so what? I don't agree now regardless of what you think I've
>>>>> said in the past. I am allowed to re-state, as clearly as possible, the
>>>>> facts of the matter and the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting
>>>>> computation. All I am asking is that you be as clear as I am being. Do
>>>>> you disagree that the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation?
>>>>
>>>> I already totally explained all that.
>>> I was not asking for an explanation. I said so explicitly. I was
>>> asking for an answer to a simple question. Your determined avoidance is
>>> very suspicious.
>>>
>>>> When-so-ever any input to a simulating halt decider would never halt
>>>> unless its simulating halt decider stopped simulating it then this
>>>> input is correctly decided as never halting.
>>>>
>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>> decider stops simulating it.
>>>>
>>>> Can you figure out whether or not this is a yes or no answer to your
>>>> question?
>>>
>>> No, I can't. As recently as 12th Aug you incorrectly said
>>>
>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>
>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>> decider stops simulating it, thus conclusively proving that the input
>> to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. You were
> wrong to say otherwise. The waffle about what would happen unless
> something that does happen happens is just so much flannel.
>

It is the different placement of H in the execution trace
that causes the first computation to have different behavior
than the second computation.

int main(){ P(P); } is not the same computation as
int main(){ H(P,P); }

This different placement of H makes the two computations
distinctly different thus the fact that the first computation
halts does not contradict the halt status decision of H.

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

This same reasoning applies to Linz:
Because of differing placement in the execution trace

int main(){ P(P); } halts and int main(){ H(P,P); }
correctly decides that its input never halts.

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

--
Copyright 2021 Pete Olcott

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

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

<sfmc5u$t3v$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 13:41:48 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 48
Message-ID: <sfmc5u$t3v$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com>
<MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me>
<6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Aug 2021 19:41:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="34f895952f8e95c031c9a45fb317058b";
logging-data="29823"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0jYZxB+IDSOzsZxP6/NGS"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:eiGa4rKTqYDZUlW6Ulj4qMX8Amg=
In-Reply-To: <6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 19 Aug 2021 19:41 UTC

On 2021-08-19 12:55, olcott wrote:
> On 8/19/2021 1:47 PM, André G. Isaak wrote:
>> On 2021-08-19 12:35, olcott wrote:

>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>> OF ITS INPUT (before it switches to halt decider mode) its act of
>>> merely examining the behavior of its input cannot possibly have any
>>> effect what-so-ever on the behavior of this input.
>>
>> And, once again, you simply reiterate your position without actually
>> addressing the points I make below.
>>
>
> I just proved that your points are totally irrelevant.

You proved no such thing. You once again just repeated yourself without
addressing the points I made (which I am not bothering to quote again --
you can go back and reread them). And you still haven't defined 'mode'.

Examining the behaviour of the input after each instruction is emulated
is what allows the halt decider to make a decision to abort. Thus, after
every single instruction the halt decider has the potential to abort its
input. A pure simulator doesn't have such a potential. So your H is
never acting as a pure simulator.

If your outermost H ignores the code to H called from inside P(P), then
it fails to take into account every single one of the decisions made by
that H to either continue with the simulation or to abort the
simulation. Which means it overlooks the fact that P(P) does *not*
actually complete its simulation. Instead it aborts, returns to the
outer P, and *HALTS*.

Your H(P, P) claims that it doesn't halt precisely because it ignores
all of those conditional branches inside the H inside P, one of which
causes the simulation to be aborted.

All your strange attempts to somehow justify your claim that H(P, P) ==
0 is actually correct are simply flawed, and the error is explained above.

P(P) halts. Therefore H(P, P) *must* return true if it is actually a
halt decider.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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

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

 copy mid

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

 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: Thu, 19 Aug 2021 21:01:53 +0100
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <87mtpdnqz2.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87h7fpuf5v.fsf@bsb.me.uk>
<AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk>
<oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk>
<U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk>
<W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="392fe0f5b5dd5175e6c48d474637b868";
logging-data="31857"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ETLVTLa29/OrjhqXo86MYPscq0sqPDz0="
Cancel-Lock: sha1:nC+xCJydLDH/IRqY3T/W71BF/Io=
sha1:ahvsFTwr5QHoR8ozVds7xJOm+DQ=
X-BSB-Auth: 1.f552427050e827b0a995.20210819210153BST.87mtpdnqz2.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 19 Aug 2021 20:01 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/19/2021 2:01 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/19/2021 8:29 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/18/2021 9:01 PM, Ben Bacarisse wrote:
>>>>
>>>>>> We won't get anywhere if you keep ducking this question. You made a
>>>>>> false statement in the old thread about this and you won't say if you
>>>>>> stand by that false statement.
>>>>>>
>>>>>> You track record in understanding people is poor. But if you think I
>>>>>> agreed, so what? I don't agree now regardless of what you think I've
>>>>>> said in the past. I am allowed to re-state, as clearly as possible, the
>>>>>> facts of the matter and the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting
>>>>>> computation. All I am asking is that you be as clear as I am being. Do
>>>>>> you disagree that the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation?
>>>>>
>>>>> I already totally explained all that.
>>>> I was not asking for an explanation. I said so explicitly. I was
>>>> asking for an answer to a simple question. Your determined avoidance is
>>>> very suspicious.
>>>>
>>>>> When-so-ever any input to a simulating halt decider would never halt
>>>>> unless its simulating halt decider stopped simulating it then this
>>>>> input is correctly decided as never halting.
>>>>>
>>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>>> decider stops simulating it.
>>>>>
>>>>> Can you figure out whether or not this is a yes or no answer to your
>>>>> question?
>>>>
>>>> No, I can't. As recently as 12th Aug you incorrectly said
>>>>
>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>
>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>> decider stops simulating it, thus conclusively proving that the input
>>> to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. You were
>> wrong to say otherwise. The waffle about what would happen unless
>> something that does happen happens is just so much flannel.
>
> It is the different placement of H in the execution trace
> that causes the first computation to have different behavior
> than the second computation.

No. ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.
"Placement" has nothing to do with it. It may be the reason your H is
wrong, but it has nothing to with what computation the string ⟨Ĥ⟩ ⟨Ĥ⟩
represents.

> int main(){ P(P); } is not the same computation as
> int main(){ H(P,P); }

⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. The two
different computations above, retrofitted into the Turing machine model
would, of course, be represented by different strings. You might be
able to give the string representing the first, but I bet you'd struggle
to give the string representing the second.

Anyway, in case that distracted you from the main point, just remember
that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.

> This different placement of H makes the two computations
> distinctly different thus the fact that the first computation
> halts does not contradict the halt status decision of H.

⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. It always
represents exactly one computation. A halting one.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Meaningless without the surrounding text, as I have said until I am
blue in the face.

> This same reasoning applies to Linz:
> Because of differing placement in the execution trace
>
> int main(){ P(P); } halts and int main(){ H(P,P); }
> correctly decides that its input never halts.
>
> Ĥ.q0 ⟨Ĥ⟩ halts and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
> correctly decides that its input never halts.

⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. You kept
showing us the line that states this fact, though you have not yet done
so in this thread.

--
Ben.

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

<xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com>

 copy mid

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

 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: Thu, 19 Aug 2021 15:37:30 -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>
<Fm_SI.15$Oz2.13@fx47.iad> <8sGdndqWyfAU6IH8nZ2dnUU7-dPNnZ2d@giganews.com>
<MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me>
<6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com> <sfmc5u$t3v$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 15:37:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <sfmc5u$t3v$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com>
Lines: 58
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-EJfpRsUbZhWJeNbfeY8eKZ8HIdRlfDQdAw/e9iM8ru2PWp0BD9rYmn4QaoPabzr2Fsnn79f3Fxn7BEJ!LIxg2GaH4iDcQNCGbeVxVqPygSi7A78VRqY9uA/w9SgfrJQ0v8T2gmPsNnjMnR1B2gVMaiqNODrI!9UQ=
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: 4632
 by: olcott - Thu, 19 Aug 2021 20:37 UTC

On 8/19/2021 2:41 PM, André G. Isaak wrote:
> On 2021-08-19 12:55, olcott wrote:
>> On 8/19/2021 1:47 PM, André G. Isaak wrote:
>>> On 2021-08-19 12:35, olcott wrote:
>
>>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>>> OF ITS INPUT (before it switches to halt decider mode) its act of
>>>> merely examining the behavior of its input cannot possibly have any
>>>> effect what-so-ever on the behavior of this input.
>>>
>>> And, once again, you simply reiterate your position without actually
>>> addressing the points I make below.
>>>
>>
>> I just proved that your points are totally irrelevant.
>
> You proved no such thing. You once again just repeated yourself without
> addressing the points I made (which I am not bothering to quote again --
> you can go back and reread them). And you still haven't defined 'mode'.
>
> Examining the behaviour of the input after each instruction is emulated
> is what allows the halt decider to make a decision to abort. Thus, after
> every single instruction the halt decider has the potential to abort its
> input. A pure simulator doesn't have such a potential. So your H is
> never acting as a pure simulator.
>
> If your outermost H ignores the code to H called from inside P(P), then
> it fails to take into account every single one of the decisions made by
> that H to either continue with the simulation or to abort the
> simulation. Which means it overlooks the fact that P(P) does *not*
> actually complete its simulation. Instead it aborts, returns to the
> outer P, and *HALTS*.
>
> Your H(P, P) claims that it doesn't halt precisely because it ignores
> all of those conditional branches inside the H inside P, one of which
> causes the simulation to be aborted.
>
> All your strange attempts to somehow justify your claim that H(P, P) ==
> 0 is actually correct are simply flawed, and the error is explained above.
>
> P(P) halts. Therefore H(P, P) *must* return true if it is actually a
> halt decider.
>
> André
>
>

H has no effect on the behavior of its input until after it has made its
halt status decision therefore H need not examine its own behavior in
this halt status decision.

It is not that hard, I can't believe that you don't understand this.

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

<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 15:43: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> <87h7fpuf5v.fsf@bsb.me.uk> <AsSdnUXVrYJ5nYb8nZ2dnUU7-VnNnZ2d@giganews.com> <875yw4v08g.fsf@bsb.me.uk> <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com> <8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com> <87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com> <87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 15:43: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: <87mtpdnqz2.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
Lines: 99
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-O7LNPXItC00bqnRQYPdwtWYrjAE9C56rj58Lp/PIrOBZmX2txOrM/23uD0lyUy6TDj90CHyGnMt9W5Z!/ytRFqoN9yAuzuAapfdqvz5CjwhQ/5HDqCC4Rk9EisiDGToeytpXprPxhZvChe1/QXVNfti7Z4Xt!FRA=
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: 6387
 by: olcott - Thu, 19 Aug 2021 20:43 UTC

On 8/19/2021 3:01 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/19/2021 2:01 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/19/2021 8:29 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/18/2021 9:01 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> We won't get anywhere if you keep ducking this question. You made a
>>>>>>> false statement in the old thread about this and you won't say if you
>>>>>>> stand by that false statement.
>>>>>>>
>>>>>>> You track record in understanding people is poor. But if you think I
>>>>>>> agreed, so what? I don't agree now regardless of what you think I've
>>>>>>> said in the past. I am allowed to re-state, as clearly as possible, the
>>>>>>> facts of the matter and the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting
>>>>>>> computation. All I am asking is that you be as clear as I am being. Do
>>>>>>> you disagree that the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation?
>>>>>>
>>>>>> I already totally explained all that.
>>>>> I was not asking for an explanation. I said so explicitly. I was
>>>>> asking for an answer to a simple question. Your determined avoidance is
>>>>> very suspicious.
>>>>>
>>>>>> When-so-ever any input to a simulating halt decider would never halt
>>>>>> unless its simulating halt decider stopped simulating it then this
>>>>>> input is correctly decided as never halting.
>>>>>>
>>>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>>>> decider stops simulating it.
>>>>>>
>>>>>> Can you figure out whether or not this is a yes or no answer to your
>>>>>> question?
>>>>>
>>>>> No, I can't. As recently as 12th Aug you incorrectly said
>>>>>
>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>
>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>> decider stops simulating it, thus conclusively proving that the input
>>>> to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. You were
>>> wrong to say otherwise. The waffle about what would happen unless
>>> something that does happen happens is just so much flannel.
>>
>> It is the different placement of H in the execution trace
>> that causes the first computation to have different behavior
>> than the second computation.
>
> No. ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.
> "Placement" has nothing to do with it. It may be the reason your H is
> wrong, but it has nothing to with what computation the string ⟨Ĥ⟩ ⟨Ĥ⟩
> represents.
>
>> int main(){ P(P); } is not the same computation as
>> int main(){ H(P,P); }
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. The two
> different computations above, retrofitted into the Turing machine model
> would, of course, be represented by different strings. You might be
> able to give the string representing the first, but I bet you'd struggle
> to give the string representing the second.
>
> Anyway, in case that distracted you from the main point, just remember
> that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.
>
>> This different placement of H makes the two computations
>> distinctly different thus the fact that the first computation
>> halts does not contradict the halt status decision of H.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. It always
> represents exactly one computation. A halting one.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Meaningless without the surrounding text, as I have said until I am
> blue in the face.
Ĥ.q0 halts
Ĥ.qx halts
the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts while Ĥ.qx remains in pure
simulation mode.

the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ only stops running because Ĥ.qx aborts its
simulation of this input.

You can dance all around this with deceptive misdirection.
You can't use any reasoning to show that it is not true.

--
Copyright 2021 Pete Olcott

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

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

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

 copy mid

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

 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: Thu, 19 Aug 2021 22:06:53 +0100
Organization: A noiseless patient Spider
Lines: 122
Message-ID: <87h7flnnyq.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk>
<oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk>
<U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk>
<W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="392fe0f5b5dd5175e6c48d474637b868";
logging-data="24448"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1923Ot8o5o2tS/mXYGQQy6OeNZKJepvQNg="
Cancel-Lock: sha1:gJI5vedqc7G0fNSOB6E5x0OCTA4=
sha1:tNf19A2h1SQE19WE6fXaOtsikBg=
X-BSB-Auth: 1.6b9d1815954e78b5e8c6.20210819220653BST.87h7flnnyq.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 19 Aug 2021 21:06 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/19/2021 3:01 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/19/2021 2:01 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/19/2021 8:29 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/18/2021 9:01 PM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>> We won't get anywhere if you keep ducking this question. You made a
>>>>>>>> false statement in the old thread about this and you won't say if you
>>>>>>>> stand by that false statement.
>>>>>>>>
>>>>>>>> You track record in understanding people is poor. But if you think I
>>>>>>>> agreed, so what? I don't agree now regardless of what you think I've
>>>>>>>> said in the past. I am allowed to re-state, as clearly as possible, the
>>>>>>>> facts of the matter and the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting
>>>>>>>> computation. All I am asking is that you be as clear as I am being. Do
>>>>>>>> you disagree that the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation?
>>>>>>>
>>>>>>> I already totally explained all that.
>>>>>> I was not asking for an explanation. I said so explicitly. I was
>>>>>> asking for an answer to a simple question. Your determined avoidance is
>>>>>> very suspicious.
>>>>>>
>>>>>>> When-so-ever any input to a simulating halt decider would never halt
>>>>>>> unless its simulating halt decider stopped simulating it then this
>>>>>>> input is correctly decided as never halting.
>>>>>>>
>>>>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>>>>> decider stops simulating it.
>>>>>>>
>>>>>>> Can you figure out whether or not this is a yes or no answer to your
>>>>>>> question?
>>>>>>
>>>>>> No, I can't. As recently as 12th Aug you incorrectly said
>>>>>>
>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>
>>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>>> decider stops simulating it, thus conclusively proving that the input
>>>>> to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>>
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. You were
>>>> wrong to say otherwise. The waffle about what would happen unless
>>>> something that does happen happens is just so much flannel.
>>>
>>> It is the different placement of H in the execution trace
>>> that causes the first computation to have different behavior
>>> than the second computation.
>>
>> No. ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.
>> "Placement" has nothing to do with it. It may be the reason your H is
>> wrong, but it has nothing to with what computation the string ⟨Ĥ⟩ ⟨Ĥ⟩
>> represents.
>>
>>> int main(){ P(P); } is not the same computation as
>>> int main(){ H(P,P); }
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. The two
>> different computations above, retrofitted into the Turing machine model
>> would, of course, be represented by different strings. You might be
>> able to give the string representing the first, but I bet you'd struggle
>> to give the string representing the second.

Dis you even try?

>> Anyway, in case that distracted you from the main point, just remember
>> that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.
>>
>>> This different placement of H makes the two computations
>>> distinctly different thus the fact that the first computation
>>> halts does not contradict the halt status decision of H.
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. It always
>> represents exactly one computation. A halting one.
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Meaningless without the surrounding text, as I have said until I am
>> blue in the face.
>
> Ĥ.q0 halts

Nonsense. Ĥ.q0 is just a state. The computation Ĥ.q0 ⟨Ĥ⟩ halts
(according to other statements you have made that I have no reason to
doubt).

> Ĥ.qx halts

Ĥ.qx is a state. It does not halt or not halt. The (different)
computation Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ also halts (according to other statements you
have made that I have no reason to doubt).

> the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts while Ĥ.qx remains in pure
> simulation mode.

And yet the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation.

> the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ only stops running because Ĥ.qx aborts its
> simulation of this input.

The string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation. This is not a
matter for debate or reasoning but of you acknowledging your own stated
facts. You have told us, time and time again, that the computation it
represents is a halting one. Until you admit the truth of what you
yourself have been telling us, you will just look like a fool.

> You can dance all around this with deceptive misdirection.
> You can't use any reasoning to show that it is not true.

I can't see any way to be more direct. You are wrong about what the
string ⟨Ĥ⟩ ⟨Ĥ⟩ represents because of what you have already told us. You
need to acknowledge that and move on to deal with the consequences.

--
Ben.

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

<sfmj2q$dmj$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 15:39:38 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 66
Message-ID: <sfmj2q$dmj$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me>
<6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com> <sfmc5u$t3v$1@dont-email.me>
<xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Aug 2021 21:39:38 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="1d2f32f8fab0aecd89ffc20807b7d6c6";
logging-data="14035"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18E5AzemBMLRDm1GjaVSzTx"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:Q0JJnLYCKRWZvE18DT59nNA99M0=
In-Reply-To: <xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Thu, 19 Aug 2021 21:39 UTC

On 2021-08-19 14:37, olcott wrote:
> On 8/19/2021 2:41 PM, André G. Isaak wrote:
>> On 2021-08-19 12:55, olcott wrote:
>>> On 8/19/2021 1:47 PM, André G. Isaak wrote:
>>>> On 2021-08-19 12:35, olcott wrote:
>>
>>>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>>>> OF ITS INPUT (before it switches to halt decider mode) its act of
>>>>> merely examining the behavior of its input cannot possibly have any
>>>>> effect what-so-ever on the behavior of this input.
>>>>
>>>> And, once again, you simply reiterate your position without actually
>>>> addressing the points I make below.
>>>>
>>>
>>> I just proved that your points are totally irrelevant.
>>
>> You proved no such thing. You once again just repeated yourself
>> without addressing the points I made (which I am not bothering to
>> quote again -- you can go back and reread them). And you still haven't
>> defined 'mode'.
>>
>> Examining the behaviour of the input after each instruction is
>> emulated is what allows the halt decider to make a decision to abort.
>> Thus, after every single instruction the halt decider has the
>> potential to abort its input. A pure simulator doesn't have such a
>> potential. So your H is never acting as a pure simulator.
>>
>> If your outermost H ignores the code to H called from inside P(P),
>> then it fails to take into account every single one of the decisions
>> made by that H to either continue with the simulation or to abort the
>> simulation. Which means it overlooks the fact that P(P) does *not*
>> actually complete its simulation. Instead it aborts, returns to the
>> outer P, and *HALTS*.
>>
>> Your H(P, P) claims that it doesn't halt precisely because it ignores
>> all of those conditional branches inside the H inside P, one of which
>> causes the simulation to be aborted.
>>
>> All your strange attempts to somehow justify your claim that H(P, P)
>> == 0 is actually correct are simply flawed, and the error is explained
>> above.
>>
>> P(P) halts. Therefore H(P, P) *must* return true if it is actually a
>> halt decider.
>>
>> André
>>
>>
>
> H has no effect on the behavior of its input until after it has made its
> halt status decision therefore H need not examine its own behavior in
> this halt status decision.

This claim is simply false. Repeating it won't change that fact. I
provided arguments in my previous post along with the summary offered
above which demonstrate that this is false. If you think there is some
flaw in my reasoning, you need to actually point it out and provide a
coherent argument. Just repeating your position ad nauseam does not
accomplish this.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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

<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>

 copy mid

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

 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: Thu, 19 Aug 2021 16:58: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
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<875yw4v08g.fsf@bsb.me.uk> <oKidneawW_dWu4H8nZ2dnUU7-emdnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 16:58: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: <87h7flnnyq.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
Lines: 154
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jIoouQiDh6dZHNUIGave7rXt2UC/vf746QvjcYp8ODsAv8xS6MUqacFfhvc6mrhPijLk12k+hsL52KM!vKuIuEGOp/sLopdTb2UKK5OGSfWjqO/r/Uzjhrp9R/IdmMXGPexo4J3qL53GPtj89iBDMz03zmcm!370=
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: 8954
 by: olcott - Thu, 19 Aug 2021 21:58 UTC

On 8/19/2021 4:06 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/19/2021 3:01 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/19/2021 2:01 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/19/2021 8:29 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/18/2021 9:01 PM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>>>> We won't get anywhere if you keep ducking this question. You made a
>>>>>>>>> false statement in the old thread about this and you won't say if you
>>>>>>>>> stand by that false statement.
>>>>>>>>>
>>>>>>>>> You track record in understanding people is poor. But if you think I
>>>>>>>>> agreed, so what? I don't agree now regardless of what you think I've
>>>>>>>>> said in the past. I am allowed to re-state, as clearly as possible, the
>>>>>>>>> facts of the matter and the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting
>>>>>>>>> computation. All I am asking is that you be as clear as I am being. Do
>>>>>>>>> you disagree that the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation?
>>>>>>>>
>>>>>>>> I already totally explained all that.
>>>>>>> I was not asking for an explanation. I said so explicitly. I was
>>>>>>> asking for an answer to a simple question. Your determined avoidance is
>>>>>>> very suspicious.
>>>>>>>
>>>>>>>> When-so-ever any input to a simulating halt decider would never halt
>>>>>>>> unless its simulating halt decider stopped simulating it then this
>>>>>>>> input is correctly decided as never halting.
>>>>>>>>
>>>>>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>>>>>> decider stops simulating it.
>>>>>>>>
>>>>>>>> Can you figure out whether or not this is a yes or no answer to your
>>>>>>>> question?
>>>>>>>
>>>>>>> No, I can't. As recently as 12th Aug you incorrectly said
>>>>>>>
>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>>
>>>>>> The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts unless its simulating halt
>>>>>> decider stops simulating it, thus conclusively proving that the input
>>>>>> to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>>>
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. You were
>>>>> wrong to say otherwise. The waffle about what would happen unless
>>>>> something that does happen happens is just so much flannel.
>>>>
>>>> It is the different placement of H in the execution trace
>>>> that causes the first computation to have different behavior
>>>> than the second computation.
>>>
>>> No. ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.
>>> "Placement" has nothing to do with it. It may be the reason your H is
>>> wrong, but it has nothing to with what computation the string ⟨Ĥ⟩ ⟨Ĥ⟩
>>> represents.
>>>
>>>> int main(){ P(P); } is not the same computation as
>>>> int main(){ H(P,P); }
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. The two
>>> different computations above, retrofitted into the Turing machine model
>>> would, of course, be represented by different strings. You might be
>>> able to give the string representing the first, but I bet you'd struggle
>>> to give the string representing the second.
>
> Dis you even try?
>
>>> Anyway, in case that distracted you from the main point, just remember
>>> that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation.
>>>
>>>> This different placement of H makes the two computations
>>>> distinctly different thus the fact that the first computation
>>>> halts does not contradict the halt status decision of H.
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that represents a halting computation. It always
>>> represents exactly one computation. A halting one.
>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> Meaningless without the surrounding text, as I have said until I am
>>> blue in the face.
>>
>> Ĥ.q0 halts
>
> Nonsense. Ĥ.q0 is just a state. The computation Ĥ.q0 ⟨Ĥ⟩ halts
> (according to other statements you have made that I have no reason to
> doubt).
>
>> Ĥ.qx halts
>
> Ĥ.qx is a state. It does not halt or not halt. The (different)
> computation Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ also halts (according to other statements you
> have made that I have no reason to doubt).
>
>> the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts while Ĥ.qx remains in pure
>> simulation mode.
>
> And yet the string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation.
>
>> the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ only stops running because Ĥ.qx aborts its
>> simulation of this input.
>
> The string ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation. This is not a

Ĥ applied to ⟨Ĥ⟩ halts.

The halt decider that Linz stipulates is embedded at the state following
the state of Ĥ copying its input at the bottom of page 319
https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
that I refer to as Ĥ.qx halts when applied to its input ⟨Ĥ⟩ ⟨Ĥ⟩.

When this halt decider at Ĥ.qx is a simulating halt decider then its
input never stops running unless it aborts the simulation of its input.

You can dance all around this with deceptive misdirection.
You can't use any CORRECT reasoning to show that it is not true.

> matter for debate or reasoning but of you acknowledging your own stated
> facts. You have told us, time and time again, that the computation it
> represents is a halting one. Until you admit the truth of what you
> yourself have been telling us, you will just look like a fool.
>
>> You can dance all around this with deceptive misdirection.
>> You can't use any reasoning to show that it is not true.
>
> I can't see any way to be more direct. You are wrong about what the
> string ⟨Ĥ⟩ ⟨Ĥ⟩ represents because of what you have already told us. You
> need to acknowledge that and move on to deal with the consequences.
>

I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
You are saying that Ĥ applied to ⟨Ĥ⟩ halts.

The fact that Ĥ applied to ⟨Ĥ⟩ halts is irrelevant to the fact that the
input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts. They are distinctly different
computations.

This is the exact same issue as the fact the int main(){ P(P); } halts
seems to contradict that int main(){ H(P,P); } decides that its input
never halts. The difference in this case is that we can easily see that
these are two distinctly different computations that can have opposite
behavior without contradiction.

--
Copyright 2021 Pete Olcott

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

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

<QuGdnWRYWdHGSIP8nZ2dnUU7-dnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 17:04:11 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <MS_SI.222$Nc1.145@fx34.iad> <QrOdnYXCAMdJ5oH8nZ2dnUU7-W3NnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com> <8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com> <1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com> <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com> <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me> <m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me> <S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me> <rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me> <crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me> <6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com> <sfmc5u$t3v$1@dont-email.me> <xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com> <sfmj2q$dmj$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 17:04:10 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <sfmj2q$dmj$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <QuGdnWRYWdHGSIP8nZ2dnUU7-dnNnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-c0DLrX/eBHalWOH9gDwWgbsY3eHCiLbrdoLply6W1pxLz6qkllv9QNoLyVBWf20vnsCwn1iiCjBJa7c!ugGi6Pj1lTdFlWt88azjnn+486W+VofsEy3HPPWs1uLzzmamGfc8I7hz0ZL/q4CTtu7LzIRKpqTW!TK4=
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: 5538
 by: olcott - Thu, 19 Aug 2021 22:04 UTC

On 8/19/2021 4:39 PM, André G. Isaak wrote:
> On 2021-08-19 14:37, olcott wrote:
>> On 8/19/2021 2:41 PM, André G. Isaak wrote:
>>> On 2021-08-19 12:55, olcott wrote:
>>>> On 8/19/2021 1:47 PM, André G. Isaak wrote:
>>>>> On 2021-08-19 12:35, olcott wrote:
>>>
>>>>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE
>>>>>> SIMULATOR OF ITS INPUT (before it switches to halt decider mode)
>>>>>> its act of merely examining the behavior of its input cannot
>>>>>> possibly have any effect what-so-ever on the behavior of this input.
>>>>>
>>>>> And, once again, you simply reiterate your position without
>>>>> actually addressing the points I make below.
>>>>>
>>>>
>>>> I just proved that your points are totally irrelevant.
>>>
>>> You proved no such thing. You once again just repeated yourself
>>> without addressing the points I made (which I am not bothering to
>>> quote again -- you can go back and reread them). And you still
>>> haven't defined 'mode'.
>>>
>>> Examining the behaviour of the input after each instruction is
>>> emulated is what allows the halt decider to make a decision to abort.
>>> Thus, after every single instruction the halt decider has the
>>> potential to abort its input. A pure simulator doesn't have such a
>>> potential. So your H is never acting as a pure simulator.
>>>
>>> If your outermost H ignores the code to H called from inside P(P),
>>> then it fails to take into account every single one of the decisions
>>> made by that H to either continue with the simulation or to abort the
>>> simulation. Which means it overlooks the fact that P(P) does *not*
>>> actually complete its simulation. Instead it aborts, returns to the
>>> outer P, and *HALTS*.
>>>
>>> Your H(P, P) claims that it doesn't halt precisely because it ignores
>>> all of those conditional branches inside the H inside P, one of which
>>> causes the simulation to be aborted.
>>>
>>> All your strange attempts to somehow justify your claim that H(P, P)
>>> == 0 is actually correct are simply flawed, and the error is
>>> explained above.
>>>
>>> P(P) halts. Therefore H(P, P) *must* return true if it is actually a
>>> halt decider.
>>>
>>> André
>>>
>>>
>>
>> H has no effect on the behavior of its input until after it has made
>> its halt status decision therefore H need not examine its own behavior
>> in this halt status decision.
>
> This claim is simply false.

It is a verifiable fact.

> Repeating it won't change that fact. I
> provided arguments in my previous post along with the summary offered
> above which demonstrate that this is false.

You provided arguments that deflect rather than address the key points.

By freaking definition a simulating freaking halt decider does not
freaking have any freaking effect on its input while it freaking merely
simulates this freaking input and freaking examines the execution
freaking trace of this freaking input, nitwit.

> If you think there is some
> flaw in my reasoning, you need to actually point it out and provide a
> coherent argument. Just repeating your position ad nauseam does not
> accomplish this.
>
> André
>

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

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

 copy mid

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

 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: Fri, 20 Aug 2021 00:14:38 +0100
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <87bl5tni1t.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk>
<ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk>
<U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk>
<W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="20827"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19BWASqw3U1ZrLpxo03ZZf1r/An4/GCur8="
Cancel-Lock: sha1:izG+YU0kLDutHIrW+tYdb+HlW8E=
sha1:8aRwClccgdOwi2sOXHROiW4cKuw=
X-BSB-Auth: 1.b317db0ef73b5f548818.20210820001438BST.87bl5tni1t.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 19 Aug 2021 23:14 UTC

olcott <NoOne@NoWhere.com> writes:

> Ĥ applied to ⟨Ĥ⟩ halts.

Yes.

And on the 12th Aug you said, and I quote

"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."

This is incorrect. You need to correct that statement so you can go on
to investigate the consequences. It's not a trivial error. It's
absolutely central to the case under investigation.

> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.

We are both saying that -- you said it above and of course I agree. The
point of disagreement is that you said

"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."

which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
computation.

> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
string that encodes a halting computation" (I think its does mean the
same, just poorly worded), but obviously I want to correct the clear and
unambiguously wrong version from Aug 12th. So long as you refuse to
accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
discussion is pointless.

--
Ben.

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

<gY2dnfwhF_7xcIP8nZ2dnUU7-QfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 18:46:52 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com> <87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com> <87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com> <87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com> <87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 18:46:52 -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: <87bl5tni1t.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <gY2dnfwhF_7xcIP8nZ2dnUU7-QfNnZ2d@giganews.com>
Lines: 54
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-nSQSErOwv5Jq+sjnAD2IxTU6SFoCLzxrF4VobEJRFZvD6gpdgdY/OYNzJ+JIICwXxzArrZQBv4Zs79b!gZduv43t+HRhvitp+H5BOKGaQsdx8/k5Gj+uuXuopEAxaFbiOk3Up5bQoSBvA8T/RmsDyONjKfui!HxQ=
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: 4129
 by: olcott - Thu, 19 Aug 2021 23:46 UTC

On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Ĥ applied to ⟨Ĥ⟩ halts.
>
> Yes.
>
> And on the 12th Aug you said, and I quote
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> This is incorrect. You need to correct that statement so you can go on
> to investigate the consequences. It's not a trivial error. It's
> absolutely central to the case under investigation.
>
>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>
> We are both saying that -- you said it above and of course I agree. The
> point of disagreement is that you said
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
> computation.
>
>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>
> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
> string that encodes a halting computation" (I think its does mean the
> same, just poorly worded), but obviously I want to correct the clear and
> unambiguously wrong version from Aug 12th. So long as you refuse to
> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
> discussion is pointless.
>

You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
halts yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
never halts.

Because of the pathological self-reference that Flibble objected to
exists whether or not ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation depends on
its placement in the execution trace.

If Ĥ is applied to ⟨Ĥ⟩ at the beginning of the execution trace then this
Ĥ halts because of its dependency on the other instances at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩.

The inputs to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ have no such dependency thus specify an
entirely different computation.

--
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? (possible duplicate)

<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>

 copy mid

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

 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!tncsrv06.tnetconsulting.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 18:50:32 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 18:50:31 -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: <87bl5tni1t.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
Lines: 55
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FwNfvHrbK/IBUiGprsyrxO/2+1hzempkn96TLZnvnLULhhBl5IHavestaJOLZCNUO4L9xFybasa1WvQ!ZxtjlSlsFGwA0hEFCk/QhaOTyzd/P59hHP7HPpEPedcNmOoL+sf59regDUF1hv3CJcgpUkEV/PBi!ZU0=
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: 4207
 by: olcott - Thu, 19 Aug 2021 23:50 UTC

On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Ĥ applied to ⟨Ĥ⟩ halts.
>
> Yes.
>
> And on the 12th Aug you said, and I quote
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> This is incorrect. You need to correct that statement so you can go on
> to investigate the consequences. It's not a trivial error. It's
> absolutely central to the case under investigation.
>
>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>
> We are both saying that -- you said it above and of course I agree. The
> point of disagreement is that you said
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
> computation.
>
>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>
> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
> string that encodes a halting computation" (I think its does mean the
> same, just poorly worded), but obviously I want to correct the clear and
> unambiguously wrong version from Aug 12th. So long as you refuse to
> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
> discussion is pointless.
>

You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
halts yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
never halts.

Because of the pathological self-reference that Flibble objected to
exists whether or not ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation depends on
its placement in the execution trace.

If Ĥ is applied to ⟨Ĥ⟩ at the beginning of the execution trace then this
Ĥ halts because of its dependency on the other instances at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩.

The inputs to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ have no such dependency thus specify an
entirely different computation.

--
Copyright 2021 Pete Olcott

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

Pages:12345678910111213141516171819
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor