Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

OK, enough hype. -- Larry Wall in the perl man page


devel / comp.theory / Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

SubjectAuthor
* Proof that H(P,P)==0 is correct [ refuting the halting problem proofsolcott
+- Proof that H(P,P)==0 is correct [ refuting the halting problemwij
+* Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]Ben
|+* Proof that H(P,P)==0 is correct [ refuting the halting problemolcott
||+- Proof that H(P,P)==0 is correct [ refuting the halting problemRichard Damon
||`* Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]Ben
|| `* Proof that H(P,P)==0 is correct [ refuting the halting problemolcott
||  +- Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]Ben
||  `- Proof that H(P,P)==0 is correct [ refuting the halting problemRichard Damon
|`* Proof that H(P,P)==0 is correct [ refuting the halting problemolcott
| `* Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]Ben
|  `* Proof that H(P,P)==0 is correct [ refuting the halting problemolcott
|   `* Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]Ben
|    `* Proof that H(P,P)==0 is correct [ refuting the halting problemolcott
|     +- Proof that H(P,P)==0 is correct [ refuting the halting problemRichard Damon
|     `* Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]Ben
|      `* Proof that H(P,P)==0 is correct [ refuting the halting problemolcott
|       +- Proof that H(P,P)==0 is correct [ refuting the halting problemRichard Damon
|       `- Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]( will keBen
`- Proof that H(P,P)==0 is correct [ refuting the halting problemwij

1
Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.lang.c comp.lang.c++
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!3.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 10 May 2022 07:26:26 -0500
Date: Tue, 10 May 2022 07:26:25 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.c,comp.lang.c++
Content-Language: en-US
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
Subject: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs
]
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 106
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7dlaBDR5AK+v7AjRldOkFe2mZukcWwggN7Z6rzhrjtSB3x9GYBYuUUtv1q8ghVErzBUeYhckvHHrY/D!MxB6mADoMWoypQgpcLECZ2SgA7x4vyvuHzVjCU7rnhDFOWsvHDx/aC25nEq+QiaQ5NGZkGGB24s=
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: 5658
 by: olcott - Tue, 10 May 2022 12:26 UTC

(a) Verify that the execution trace of P by H is correct by comparing
this execution trace to the ax86 source-code of P.

(b) Verify that this execution trace shows that P is stuck in infinitely
nested simulation (a non-halting behavior).

#include <stdint.h>
#define u32 uint32_t

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

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

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) lines = 237 pages

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<0b29712b-b0ef-44f9-a365-9eb37b24963dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:1d08:b0:45a:a692:3bb2 with SMTP id e8-20020a0562141d0800b0045aa6923bb2mr18275615qvd.24.1652194512068;
Tue, 10 May 2022 07:55:12 -0700 (PDT)
X-Received: by 2002:a05:6902:102a:b0:649:4564:5407 with SMTP id
x10-20020a056902102a00b0064945645407mr19648025ybt.565.1652194511904; Tue, 10
May 2022 07:55:11 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Tue, 10 May 2022 07:55:11 -0700 (PDT)
In-Reply-To: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=A1PyIwoAAACCahK0CVYFlDZG8JWzz_Go
NNTP-Posting-Host: 124.218.76.41
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0b29712b-b0ef-44f9-a365-9eb37b24963dn@googlegroups.com>
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
From: wynii...@gmail.com (wij)
Injection-Date: Tue, 10 May 2022 14:55:12 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 5846
 by: wij - Tue, 10 May 2022 14:55 UTC

On Tuesday, 10 May 2022 at 20:26:33 UTC+8, olcott wrote:
> (a) Verify that the execution trace of P by H is correct by comparing
> this execution trace to the ax86 source-code of P.
>
> (b) Verify that this execution trace shows that P is stuck in infinitely
> nested simulation (a non-halting behavior).
>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01) 55 push ebp
> [00001373](02) 8bec mov ebp,esp
> [00001375](05) 6852130000 push 00001352 // push P
> [0000137a](05) 6852130000 push 00001352 // push P
> [0000137f](05) e81efeffff call 000011a2 // call H
> [00001384](03) 83c408 add esp,+08
> [00001387](01) 50 push eax
> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
> [0000138d](05) e8e0f0ffff call 00000472 // call Output
> [00001392](03) 83c408 add esp,+08
> [00001395](02) 33c0 xor eax,eax
> [00001397](01) 5d pop ebp
> [00001398](01) c3 ret
> Size in bytes:(0039) [00001398]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> ...[00001372][0010229e][00000000] 55 push ebp
> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
> ...[00001352][0021233e][00212342] 55 push ebp // enter P
> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50 push eax // push P
> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51 push ecx // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50 push eax // push P
> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion (infinitely nested simulation) non-halting behavior pattern.
>
> ...[00001384][0010229e][00000000] 83c408 add esp,+08
> ...[00001387][0010229a][00000000] 50 push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408 add esp,+08
> ...[00001395][0010229e][00000000] 33c0 xor eax,eax
> ...[00001397][001022a2][00100000] 5d pop ebp
> ...[00001398][001022a6][00000004] c3 ret
> Number of Instructions Executed(15892) lines = 237 pages
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

Many problems. Pick the major one:
P is invalid, because your halting decider H is not shown to exist
(there is another reason). You can say H(..) comprises of several million
lines of source codes. But this does not matter because this is your
choice of the proof. The important thing is, as a proof, THE PROOF HAS TO BE
SHOWN existent, or it does not exist (you refuted something does not exist !!!)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
Date: Tue, 10 May 2022 16:50:29 +0100
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <87mtfpl73u.fsf@bsb.me.uk>
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@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="8f4b18f06fcc0bb5681d9a39c037aa43";
logging-data="25627"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TDawgo4wLNNby7lQgrfxMaJXZ2QewC7g="
Cancel-Lock: sha1:y7ZyawU3TxIJw9aizWPdPsL3woo=
sha1:G6nX+0aTuWZwCsZs3pQ7HQtYhJo=
X-BSB-Auth: 1.3cb5163aa4306b1b5ac6.20220510165029BST.87mtfpl73u.fsf@bsb.me.uk
 by: Ben - Tue, 10 May 2022 15:50 UTC

olcott <NoOne@NoWhere.com> writes:

> (a) Verify that the execution trace of P by H is correct by comparing
> this execution trace to the ax86 source-code of P.

P called with what argument? I assume P.

> (b) Verify that this execution trace shows that P is stuck in
> infinitely nested simulation (a non-halting behavior).

Something is wrong in your code if P(P), or a simulation of P(P), does
not halt, since you told us that it does. Post the code and someone
will help you find the bug.

> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }

Unless you are retracting any of the facts you have previously stated,
we know (because you've told us) that H(P,P) returns 0 and we know
(because you've told us) that P(P) halts. The trace of the execution
will either confirm this, or the trace is faulty. Nothing new can come
from looking at traces of mystery code.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 10 May 2022 23:47:07 -0500
Date: Tue, 10 May 2022 23:47:05 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87mtfpl73u.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 143
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-kVDSPvW0mzbqmutT2z1AD0LtDD+MzDS+UBJiDe0Bac74y+t/fFQkTIDWsQttCS+AfnCBZuFz2h7RMJe!i2cJJTmngARnH86fooU6CI913w/u6Ljf0YFa2Tglu88tWp8ySv5qVk8ekfbrZPKkFzZZWZmjqjs=
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: 6912
 by: olcott - Wed, 11 May 2022 04:47 UTC

On 5/10/2022 10:50 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> (a) Verify that the execution trace of P by H is correct by comparing
>> this execution trace to the ax86 source-code of P.
>
> P called with what argument? I assume P.
>
>> (b) Verify that this execution trace shows that P is stuck in
>> infinitely nested simulation (a non-halting behavior).
>
> Something is wrong in your code if P(P), or a simulation of P(P), does
> not halt, since you told us that it does. Post the code and someone
> will help you find the bug.
>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>
> Unless you are retracting any of the facts you have previously stated,
> we know (because you've told us) that H(P,P) returns 0 and we know
> (because you've told us) that P(P) halts. The trace of the execution
> will either confirm this, or the trace is faulty. Nothing new can come
> from looking at traces of mystery code.
>

(a) The trace is verifiably correct if one has the technical skill.
(b) The trace is proved non-halting if one has the technical skill.
You simply don't seem to have the technical skill.

I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU ERASED.

#include <stdint.h>
#define u32 uint32_t

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

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

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) lines = 237 pages

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<UVMeK.502$JSxf.250@fx11.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.roellig-ltd.de!open-news-network.org!peer03.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 164
Message-ID: <UVMeK.502$JSxf.250@fx11.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 11 May 2022 07:16:03 -0400
X-Received-Bytes: 8101
 by: Richard Damon - Wed, 11 May 2022 11:16 UTC

On 5/11/22 12:47 AM, olcott wrote:
> On 5/10/2022 10:50 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> (a) Verify that the execution trace of P by H is correct by comparing
>>> this execution trace to the ax86 source-code of P.
>>
>> P called with what argument?  I assume P.
>>
>>> (b) Verify that this execution trace shows that P is stuck in
>>> infinitely nested simulation (a non-halting behavior).
>>
>> Something is wrong in your code if P(P), or a simulation of P(P), does
>> not halt, since you told us that it does.  Post the code and someone
>> will help you find the bug.
>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>
>> Unless you are retracting any of the facts you have previously stated,
>> we know (because you've told us) that H(P,P) returns 0 and we know
>> (because you've told us) that P(P) halts.  The trace of the execution
>> will either confirm this, or the trace is faulty.  Nothing new can come
>> from looking at traces of mystery code.
>>
>
> (a) The trace is verifiably correct if one has the technical skill.

No, it is verifiably INCORRECT for one with even a tiny bit of skill.

> (b) The trace is proved non-halting if one has the technical skill.
> You simply don't seem to have the technical skill.
>

Nope, the trace proves you are LYING about actually simulating the input.

> I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU ERASED.
>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

Trace breaks here. A CORRECT Trace would now trace the operation of the
copy of H that P is using.

Also, the following never happens as code in the call to H unless H just
calls its input at which point it can't 'abort' this 'simuation'

> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>

Thus proving that H didn't just call its input (or the H being called by
P isn't the same as the H deciding on H(P,P) and thus you are lying
about build P correctly.

> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion (infinitely nested simulation) non-halting behavior pattern.

FALSE. YOU are forgetting that the H being called will (if it is the
same code as the H deciding) will also abort its simulation, thus
breaking the "infinite recursion", thus the proof is UNSOUND.

>
> ...[00001384][0010229e][00000000] 83c408     add esp,+08
> ...[00001387][0010229a][00000000] 50         push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408     add esp,+08
> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> ...[00001397][001022a2][00100000] 5d         pop ebp
> ...[00001398][001022a6][00000004] c3         ret
> Number of Instructions Executed(15892) lines = 237 pages
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
>

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

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

 copy mid

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

 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)
Newsgroups: comp.theory
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
Followup-To: comp.theory
Date: Wed, 11 May 2022 14:21:39 +0100
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <878rr88asc.fsf@bsb.me.uk>
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
<s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@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="0e1d4fd29744a738b604ac23bca2b355";
logging-data="29189"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+DWM7Ir1w5VMExWFNYgfNIv75jr0bLgMQ="
Cancel-Lock: sha1:974qHSmbg+/flvItAc5mj9CGugw=
sha1:6NWx4cVx60Ek7kWP5OHLyVhHHTg=
X-BSB-Auth: 1.60724a899afcb186b64c.20220511142139BST.878rr88asc.fsf@bsb.me.uk
 by: Ben - Wed, 11 May 2022 13:21 UTC

olcott <NoOne@NoWhere.com> writes:

> On 5/10/2022 10:50 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> (a) Verify that the execution trace of P by H is correct by comparing
>>> this execution trace to the ax86 source-code of P.
>>
>> P called with what argument? I assume P.

You won't even correct a trivial point.

>>> (b) Verify that this execution trace shows that P is stuck in
>>> infinitely nested simulation (a non-halting behavior).
>>
>> Something is wrong in your code if P(P), or a simulation of P(P), does
>> not halt, since you told us that it does. Post the code and someone
>> will help you find the bug.

Don't you want to know what's wrong with your code? Your trace shows
that you are not even nesting any simulations so that's one error right
there. But there are clearly others.

>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>
>> Unless you are retracting any of the facts you have previously stated,
>> we know (because you've told us) that H(P,P) returns 0 and we know
>> (because you've told us) that P(P) halts. The trace of the execution
>> will either confirm this, or the trace is faulty. Nothing new can come
>> from looking at traces of mystery code.

Are you retracting any of the facts you have previously stated? If not,
you are, as you no doubt know by now, wrong by definition.

> (a) The trace is verifiably correct if one has the technical skill.

A trace is neither correct not incorrect. It just shows a (partial)
program execution. It "correctly" shows that H is not doing what you
claim (it shows no nested simulation) so maybe that means it's
"incorrect"?

> (b) The trace is proved non-halting if one has the technical skill.
> You simply don't seem to have the technical skill.

The trace shows H not doing what you claim. The fact that don't address
this gross misdirection on your part make it more a lie than an error.

> I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU
> ERASED.

There's no point in repeatedly posting a trace that it at best the wrong
one and at worst a lie. The right trace to post (again) would be the
one showing P(P) halting.

Obviously, you'd like people to talk about something other than the bald
fact that you are wrong by definition: H(P,P) == false "even though P(P)
halts" (your words).

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!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: Wed, 11 May 2022 09:07:11 -0500
Date: Wed, 11 May 2022 09:07:09 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87mtfpl73u.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 52
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9V7tdTRrw0r8lLJTsBMXkppUpi1KxaGeDC0AaDeIgi5HqMnnOpCKqggOIR2kcxZRliGUN5WS1qljjHB!kr1ihCwmhzXIk3/auZ/AexPrBLN9jG9hp360xaScW7Pg8U3BH95M27JG0EZKY8ziHN5kngfTdqI=
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: 2863
 by: olcott - Wed, 11 May 2022 14:07 UTC

On 5/10/2022 10:50 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> (a) Verify that the execution trace of P by H is correct by comparing
>> this execution trace to the ax86 source-code of P.
>
> P called with what argument? I assume P.
>
>> (b) Verify that this execution trace shows that P is stuck in
>> infinitely nested simulation (a non-halting behavior).
>
> Something is wrong in your code if P(P), or a simulation of P(P), does
> not halt, since you told us that it does. Post the code and someone
> will help you find the bug.
>

If you had the technical skill you could verify that it is 100%
impossible for there to be anything wrong with the code on the basis of
that of the verifiably correct execution trace that it derives.

In other words you simply don't have the skill to see that the verified
facts supersede your incorrect opinions.

>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>
> Unless you are retracting any of the facts you have previously stated,
> we know (because you've told us) that H(P,P) returns 0 and we know
> (because you've told us) that P(P) halts. The trace of the execution
> will either confirm this, or the trace is faulty. Nothing new can come
> from looking at traces of mystery code.
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<6tSdnf7lqsyFWub_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 11 May 2022 09:24:24 -0500
Date: Wed, 11 May 2022 09:24:22 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@giganews.com>
<878rr88asc.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <878rr88asc.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <6tSdnf7lqsyFWub_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 180
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CU7mcakPOQbezLyYTuLP+E3qJd2262QW3J/bE2BP2mMbYd8ztuldyuKbfkMqRBKsBENYxB1RJOk+Anx!Ubt7mbWjEo2eCJtIRxeuGGJA3VZelKpiKoKbXG1Xo1o4d3qu6a+Vq1jifOMn+F3yOCKL0ixOIzQ=
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: 8425
 by: olcott - Wed, 11 May 2022 14:24 UTC

On 5/11/2022 8:21 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/10/2022 10:50 AM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>> this execution trace to the ax86 source-code of P.
>>>
>>> P called with what argument? I assume P.
>
> You won't even correct a trivial point.
>
>>>> (b) Verify that this execution trace shows that P is stuck in
>>>> infinitely nested simulation (a non-halting behavior).
>>>
>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>> not halt, since you told us that it does. Post the code and someone
>>> will help you find the bug.
>
> Don't you want to know what's wrong with your code? Your trace shows
> that you are not even nesting any simulations so that's one error right
> there. But there are clearly others.
>

Here is the same trace that also shows the recursive simulation memory
allocations. I erase them because they are distracting.

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352
[0000137a](05) 6852130000 push 00001352
[0000137f](05) e81efeffff call 000011a2
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423
[0000138d](05) e8e0f0ffff call 00000472
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352
....[0000137a][00102296][00001352] 6852130000 push 00001352
....[0000137f][00102292][00001384] e81efeffff call 000011a2
--Allocation[002022b2](00000018)
--Allocation[002022d2](00000034)
--Allocation[0020230e](00000034)
--Allocation[0020234a](00010000)
New slave_stack @20234a
--Allocation[00212352](0003a980)

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
H_Root:1
....[00001352][0021233e][00212342] 55 push ebp
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx
....[0000135d][00212332][00001362] e840feffff call 000011a2
--Allocation[0024ccda](00000018)
--Allocation[0024ccfa](00000034)
--Allocation[0024cd36](00000034)
--Allocation[0024cd72](00010000)
New slave_stack @24cd72
H_Root:0
....[00001352][0025cd66][0025cd6a] 55 push ebp
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892)

>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>
>>> Unless you are retracting any of the facts you have previously stated,
>>> we know (because you've told us) that H(P,P) returns 0 and we know
>>> (because you've told us) that P(P) halts. The trace of the execution
>>> will either confirm this, or the trace is faulty. Nothing new can come
>>> from looking at traces of mystery code.
>
> Are you retracting any of the facts you have previously stated? If not,
> you are, as you no doubt know by now, wrong by definition.
>
>> (a) The trace is verifiably correct if one has the technical skill.
>
> A trace is neither correct not incorrect.

That seems to be a weasel worded way to attempt to derive a fake
rebuttal. The trace of the repeated first seven instructions of the
simulated P corresponds to the behavior specified by these first seven
instructions in the x86 source code of P.

> It just shows a (partial)
> program execution. It "correctly" shows that H is not doing what you
> claim (it shows no nested simulation) so maybe that means it's
> "incorrect"?
>

I added the nested simulation memory allocation details.

>> (b) The trace is proved non-halting if one has the technical skill.
>> You simply don't seem to have the technical skill.
>
> The trace shows H not doing what you claim. The fact that don't address
> this gross misdirection on your part make it more a lie than an error.
>

The trace conclusively proves that H does correctly simulate two of the
nested simulations that the x86 source-code of P specifies.

>> I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU
>> ERASED.
>
> There's no point in repeatedly posting a trace that it at best the wrong
> one and at worst a lie.

That you say it is wrong or a lie without understanding it is itself
wholly dishonest. If you don't understand it then you have no basis to
say that it is wrong. The most that you can honestly say is that you
don't understand how it could be correct.

> The right trace to post (again) would be the
> one showing P(P) halting.
>
> Obviously, you'd like people to talk about something other than the bald
> fact that you are wrong by definition: H(P,P) == false "even though P(P)
> halts" (your words).
>

(a) The correct simulation of the input to H(P,P) never halts.
(b) The correct simulation of the input to H1(P,P) halts.
(c) The direct execution of P(P) halts.

(b) and (c) are computationally equivalent.
(a) and (b) are NOT computationally equivalent.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
Date: Wed, 11 May 2022 20:51:36 +0100
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <87mtfn7sqf.fsf@bsb.me.uk>
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
<s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@giganews.com>
<878rr88asc.fsf@bsb.me.uk>
<6tSdnf7lqsyFWub_nZ2dnUU7_83NnZ2d@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="0e1d4fd29744a738b604ac23bca2b355";
logging-data="26809"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+053AiVylzP6OajacK7snSn7MNhX69uf4="
Cancel-Lock: sha1:PXq0yJJXj5WJ9BjPgOm+w55QloM=
sha1:xgd5V26e739wq5774PBD0P8vLHQ=
X-BSB-Auth: 1.a3586d57fff10fefebd3.20220511205136BST.87mtfn7sqf.fsf@bsb.me.uk
 by: Ben - Wed, 11 May 2022 19:51 UTC

olcott <NoOne@NoWhere.com> writes:

> Here is the same trace that also shows the recursive simulation memory
> allocations. I erase them because they are distracting.

You are admitting you are posting edited traces? Who would have guessed
that! Are you still editing them? There's still no evidence of nested
simulation.

> (a) The correct simulation of the input to H(P,P) never halts.

The correct simulation of P(P) halts.

> (b) The correct simulation of the input to H1(P,P) halts.

No one cares about H1. It's H that's wrong.

> (c) The direct execution of P(P) halts.

And H(P,P) == false.

> (b) and (c) are computationally equivalent.

According to you, one halts and the other does not. They are clearly
not equivalent.

> (a) and (b) are NOT computationally equivalent.

No one cares about H1. It's H(P,P)==false even though P(P) halts that's
wrong.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
Date: Wed, 11 May 2022 20:54:24 +0100
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <87h75v7slr.fsf@bsb.me.uk>
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
<doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@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="0e1d4fd29744a738b604ac23bca2b355";
logging-data="26809"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19/Czc2wgp/H/UZGR9NCTTZKD9ZHwnfOs4="
Cancel-Lock: sha1:qpFzPeHcFLYegM7lGBRje8m4EDY=
sha1:DOM6sKRTLAncHaMKpLFwSmxVAT0=
X-BSB-Auth: 1.89b7700174f073cb77ad.20220511205424BST.87h75v7slr.fsf@bsb.me.uk
 by: Ben - Wed, 11 May 2022 19:54 UTC

olcott <NoOne@NoWhere.com> writes:

> On 5/10/2022 10:50 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> (a) Verify that the execution trace of P by H is correct by comparing
>>> this execution trace to the ax86 source-code of P.
>>
>> P called with what argument? I assume P.
>>
>>> (b) Verify that this execution trace shows that P is stuck in
>>> infinitely nested simulation (a non-halting behavior).
>>
>> Something is wrong in your code if P(P), or a simulation of P(P), does
>> not halt, since you told us that it does. Post the code and someone
>> will help you find the bug.
>
> If you had the technical skill you could verify that it is 100%
> impossible for there to be anything wrong with the code on the basis
> of that of the verifiably correct execution trace that it derives.

You trace clearly and accurately shows that what you call the
"simulation of the input" is wrong.

H(P,P) == false is wrong because P(P) halts. H is supposed to be able
to tell us which calls terminate and which ones won't. Your H is wrong
by definition.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 11 May 2022 16:35:16 -0500
Date: Wed, 11 May 2022 16:35:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <87h75v7slr.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 93
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-aAkLXI5/nkTT+DRqrW5U0xPRHQJXnWNKL6NR+U+ritJrAlirNisAWwBvZ+93Q1tx3fyst8G0sgsxp1d!qvbfJcaZa4Gdu9AtL/ngtoNqrsm5koEqhQSKtlcAoSHM/jN8CSHxlJL8/6mL5RnDcRGqHtWVlzs=
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: 5391
 by: olcott - Wed, 11 May 2022 21:35 UTC

On 5/11/2022 2:54 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/10/2022 10:50 AM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>> this execution trace to the ax86 source-code of P.
>>>
>>> P called with what argument? I assume P.
>>>
>>>> (b) Verify that this execution trace shows that P is stuck in
>>>> infinitely nested simulation (a non-halting behavior).
>>>
>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>> not halt, since you told us that it does. Post the code and someone
>>> will help you find the bug.
>>
>> If you had the technical skill you could verify that it is 100%
>> impossible for there to be anything wrong with the code on the basis
>> of that of the verifiably correct execution trace that it derives.
>
> You trace clearly and accurately shows that what you call the
> "simulation of the input" is wrong.
>

That is utter nonsense.
We can see that H(P,P) does execute a pure simulation of its input on
the basis of the execution trace of P (up to the point where P would
call H a second time from its same machine address with identical
parameters) provided by H and the x86 source code of P.

The first seven machine instructions of P from [00001352] to [0000135d]
are proven to be correctly simulated in sequence, until P calls H(P,P)
which repeats this process.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

Execution trace of the simulation of the input to H(P,P) by H
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

The new simulation gets a new stack giving it a new value for ESP
[00212332] of the prior simulation becomes [0025cd6a] in the new
simulation.

....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

For the last several weeks it has always been your provably incorrect
opinions against my provably verified facts.

> H(P,P) == false is wrong because P(P) halts. H is supposed to be able
> to tell us which calls terminate and which ones won't. Your H is wrong
> by definition.
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<eRXeK.53$C7G6.14@fx46.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!border1.nntp.dca1.giganews.com!nntp.giganews.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <s_mdnY6QA4NWoub_nZ2dnUU7_83NnZ2d@giganews.com>
<878rr88asc.fsf@bsb.me.uk> <6tSdnf7lqsyFWub_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <6tSdnf7lqsyFWub_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 224
Message-ID: <eRXeK.53$C7G6.14@fx46.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 11 May 2022 19:42:03 -0400
X-Received-Bytes: 9993
X-Original-Bytes: 9860
 by: Richard Damon - Wed, 11 May 2022 23:42 UTC

On 5/11/22 10:24 AM, olcott wrote:
> On 5/11/2022 8:21 AM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>> this execution trace to the ax86 source-code of P.
>>>>
>>>> P called with what argument?  I assume P.
>>
>> You won't even correct a trivial point.
>>
>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>> infinitely nested simulation (a non-halting behavior).
>>>>
>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>> not halt, since you told us that it does.  Post the code and someone
>>>> will help you find the bug.
>>
>> Don't you want to know what's wrong with your code?  Your trace shows
>> that you are not even nesting any simulations so that's one error right
>> there.  But there are clearly others.
>>
>
> Here is the same trace that also shows the recursive simulation memory
> allocations. I erase them because they are distracting.
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352
> [0000137a](05)  6852130000      push 00001352
> [0000137f](05)  e81efeffff      call 000011a2
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423
> [0000138d](05)  e8e0f0ffff      call 00000472
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55              push ebp
> ...[00001373][0010229e][00000000] 8bec            mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000      push 00001352
> ...[0000137a][00102296][00001352] 6852130000      push 00001352
> ...[0000137f][00102292][00001384] e81efeffff      call 000011a2
> --Allocation[002022b2](00000018)
> --Allocation[002022d2](00000034)
> --Allocation[0020230e](00000034)
> --Allocation[0020234a](00010000)
> New slave_stack @20234a
> --Allocation[00212352](0003a980)
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> H_Root:1
> ...[00001352][0021233e][00212342] 55              push ebp
> ...[00001353][0021233e][00212342] 8bec            mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508          mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50              push eax
> ...[00001359][0021233a][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51              push ecx
> ...[0000135d][00212332][00001362] e840feffff      call 000011a2
> --Allocation[0024ccda](00000018)
> --Allocation[0024ccfa](00000034)
> --Allocation[0024cd36](00000034)
> --Allocation[0024cd72](00010000)
> New slave_stack @24cd72

So, is the following execution now UNCONDITIONAL, or is there an implied
condition between each instruction as the simulator decides if it is
going to continue.

Note, that the operation of converting a trace of a simulation into a
trace of the simulated machine is only valid for UNCONDITIONAL
simulation. If the simulation is conditional, at a minimum you need to
mark the conditional or interprete with the implied conditionals.

> H_Root:0
> ...[00001352][0025cd66][0025cd6a] 55              push ebp
> ...[00001353][0025cd66][0025cd6a] 8bec            mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508          mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50              push eax
> ...[00001359][0025cd62][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51              push ecx
> ...[0000135d][0025cd5a][00001362] e840feffff      call 000011a2
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Which, is invalid since it is ignoring the implied conditionals between
all of the above instructions.

UNSOUND LOGIC.

> ...[00001384][0010229e][00000000] 83c408          add esp,+08
> ...[00001387][0010229a][00000000] 50              push eax
> ...[00001388][00102296][00000423] 6823040000      push 00000423
> ---[0000138d][00102296][00000423] e8e0f0ffff      call 00000472
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408          add esp,+08
> ...[00001395][0010229e][00000000] 33c0            xor eax,eax
> ...[00001397][001022a2][00100000] 5d              pop ebp
> ...[00001398][001022a6][00000004] c3              ret
> Number_of_User_Instructions(1)
> Number of Instructions Executed(15892)
>
>
>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>
>>>> Unless you are retracting any of the facts you have previously stated,
>>>> we know (because you've told us) that H(P,P) returns 0 and we know
>>>> (because you've told us) that P(P) halts.  The trace of the execution
>>>> will either confirm this, or the trace is faulty.  Nothing new can come
>>>> from looking at traces of mystery code.
>>
>> Are you retracting any of the facts you have previously stated?  If not,
>> you are, as you no doubt know by now, wrong by definition.
>>
>>> (a) The trace is verifiably correct if one has the technical skill.
>>
>> A trace is neither correct not incorrect.
>
> That seems to be a weasel worded way to attempt to derive a fake
> rebuttal. The trace of the repeated first seven instructions of the
> simulated P corresponds to the behavior specified by these first seven
> instructions in the x86 source code of P.

WRONG. You have an incorrect trace unless H UNCONDITIONAL executes the
input, but it can't since it is shown to abort,

Thus YOU LIE about the trace.

>
>>  It just shows a (partial)
>> program execution.  It "correctly" shows that H is not doing what you
>> claim (it shows no nested simulation) so maybe that means it's
>> "incorrect"?
>>
>
> I added the nested simulation memory allocation details.

But not the actual nested simulation details

You imply unconditional simulation, when it is conditional.

>
>>> (b) The trace is proved non-halting if one has the technical skill.
>>> You simply don't seem to have the technical skill.
>>
>> The trace shows H not doing what you claim.  The fact that don't address
>> this gross misdirection on your part make it more a lie than an error.
>>
>
> The trace conclusively proves that H does correctly simulate two of the
> nested simulations that the x86 source-code of P specifies.

Nope, it proves it INCORRECTLY simulates the nested simulation.

>
>>> I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU
>>> ERASED.
>>
>> There's no point in repeatedly posting a trace that it at best the wrong
>> one and at worst a lie.
>
> That you say it is wrong or a lie without understanding it is itself
> wholly dishonest. If you don't understand it then you have no basis to
> say that it is wrong. The most that you can honestly say is that you
> don't understand how it could be correct.

Nope, shows you don't understand how nested simulations actually works.

>
>>  The right trace to post (again) would be the
>> one showing P(P) halting.
>>
>> Obviously, you'd like people to talk about something other than the bald
>> fact that you are wrong by definition: H(P,P) == false "even though P(P)
>> halts" (your words).
>>
>
> (a) The correct simulation of the input to H(P,P) never halts.


Click here to read the complete article
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
Date: Thu, 12 May 2022 01:25:55 +0100
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <87wner61gs.fsf@bsb.me.uk>
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
<doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk>
<bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@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="b918120b717b1a0036d52ef1ce111b9c";
logging-data="7798"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/YwFK1V+lgb/mWm9/c/vgwqgD0hMQDIm8="
Cancel-Lock: sha1:fxdM3muu0xg54+3srLiTNmCr+M4=
sha1:7deu4tVqF93jegu66wsQJ+9xqN4=
X-BSB-Auth: 1.0da785166abfb476af94.20220512012555BST.87wner61gs.fsf@bsb.me.uk
 by: Ben - Thu, 12 May 2022 00:25 UTC

olcott <NoOne@NoWhere.com> writes:

> On 5/11/2022 2:54 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>> this execution trace to the ax86 source-code of P.
>>>>
>>>> P called with what argument? I assume P.
>>>>
>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>> infinitely nested simulation (a non-halting behavior).
>>>>
>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>> not halt, since you told us that it does. Post the code and someone
>>>> will help you find the bug.
>>>
>>> If you had the technical skill you could verify that it is 100%
>>> impossible for there to be anything wrong with the code on the basis
>>> of that of the verifiably correct execution trace that it derives.
>> You trace clearly and accurately shows that what you call the
>> "simulation of the input" is wrong.
>
> That is utter nonsense.

The whole exchange is ridiculous. You post traces you now admit are
edited. You won't post the code for H because you know it's wrong. All
the rest of your posts are just frantic attempts to take the focus away
from the facts you have already admitted: that H(P,P) == false even
though P(P) halts.

H is unable to do the job it is supposed to do: correctly determine the
halting or otherwise of certain function calls. There are no arguments
that can be passed to H so that H can tell us that the function call
P(P) halts.

You have used the same diversion again and again. When confronted with
a huge mistake, you post even more errors to try draw attention away
from the big mistake. All the errors in your recent posts are of no
significance compared to the fact that H does not do the job is it
supposed to do.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!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: Wed, 11 May 2022 19:38:04 -0500
Date: Wed, 11 May 2022 19:38:02 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk> <bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>
<87wner61gs.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87wner61gs.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 56
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-OmyB4PM0afOgjvmV19mfYiPvargxaD7VHbrXL4wrRyQPXFKVePuTxMrAVeOEiDKc6jPN5nNyTMD6RLy!e9Kulv3UI06yR9AAmNoJtEFveWrNi/sIVNahwtahsf0NT7azY+lI6Adym89FUBtN71XinztHMq8=
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: 3533
 by: olcott - Thu, 12 May 2022 00:38 UTC

On 5/11/2022 7:25 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/11/2022 2:54 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>>> this execution trace to the ax86 source-code of P.
>>>>>
>>>>> P called with what argument? I assume P.
>>>>>
>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>
>>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>>> not halt, since you told us that it does. Post the code and someone
>>>>> will help you find the bug.
>>>>
>>>> If you had the technical skill you could verify that it is 100%
>>>> impossible for there to be anything wrong with the code on the basis
>>>> of that of the verifiably correct execution trace that it derives.
>>> You trace clearly and accurately shows that what you call the
>>> "simulation of the input" is wrong.
>>
>> That is utter nonsense.
>
> The whole exchange is ridiculous. You post traces you now admit are
> edited.

I normally have that debug info disabled so it need not be edited.
You needed to see that it really is recursive simulation (because you
didn't believe me) so I left these details in.

> You won't post the code for H because you know it's wrong.

That is a ridiculously stupid thing to say when it is so dead obvious
that I proved that the code is correct on the basis of the 14 lines of
correct simulation that it produces.

It is also dead obvious and that and second function call from the same
machine address to the same function with the same parameters
conclusively proves infinite recursion.

These things have been DEAD OBVIOUS for six months and everyone here is
too stupid, dishonest or ignorant to acknowledge them.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<NZYeK.1832$6y5f.675@fx40.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx40.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
Content-Language: en-US
Newsgroups: comp.theory
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk> <bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>
<87wner61gs.fsf@bsb.me.uk> <pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 86
Message-ID: <NZYeK.1832$6y5f.675@fx40.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 11 May 2022 20:59:26 -0400
X-Received-Bytes: 4465
 by: Richard Damon - Thu, 12 May 2022 00:59 UTC

On 5/11/22 8:38 PM, olcott wrote:
> On 5/11/2022 7:25 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/11/2022 2:54 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> (a) Verify that the execution trace of P by H is correct by
>>>>>>> comparing
>>>>>>> this execution trace to the ax86 source-code of P.
>>>>>>
>>>>>> P called with what argument?  I assume P.
>>>>>>
>>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>>
>>>>>> Something is wrong in your code if P(P), or a simulation of P(P),
>>>>>> does
>>>>>> not halt, since you told us that it does.  Post the code and someone
>>>>>> will help you find the bug.
>>>>>
>>>>> If you had the technical skill you could verify that it is 100%
>>>>> impossible for there to be anything wrong with the code on the basis
>>>>> of that of the verifiably correct execution trace that it derives.
>>>> You trace clearly and accurately shows that what you call the
>>>> "simulation of the input" is wrong.
>>>
>>> That is utter nonsense.
>>
>> The whole exchange is ridiculous.  You post traces you now admit are
>> edited.
>
> I normally have that debug info disabled so it need not be edited.
> You needed to see that it really is recursive simulation (because you
> didn't believe me) so I left these details in.
>
>> You won't post the code for H because you know it's wrong.
>
> That is a ridiculously stupid thing to say when it is so dead obvious
> that I proved that the code is correct on the basis of the 14 lines of
> correct simulation that it produces.
>
> It is also dead obvious and that and second function call from the same
> machine address to the same function with the same parameters
> conclusively proves infinite recursion.
>
> These things have been DEAD OBVIOUS for six months and everyone here is
> too stupid, dishonest or ignorant to acknowledge them.
>
>

No, it is clear that the traces you are posting aren't corerct as P
calls H and then H simulates its input, but we NEVER see that simulation
happening, only another call to P.

You have presented ZERO proof that you actually HAVE a simulator.

You have just proved that YOU are the "stupid" one because you can't see
that a Halt Decider needs to decide of the Compuation asked about.

If H(P,P) isn't asking about P(P), and you won't say HOW to ask about
that, it just provides very convincing evidence that H isn't a Halting
Decider.

You also have a HISTORY of making out and out FALSE statements that you
later try to back off on, but were clearly incorrect from the beginning,
so you have PROVEN yourself to be a LIAR, so your word is worthless.

You don't understand Turing Machines.

You don't understand Computation Theory.

You don't seem to understand what Formal Logic is, as you seem incapable
of actually proving anything, but just jump out to irrelvent analogies
that don't actually prove anything.

I don't think you even really understand what Truth is, and seem to
confuse it with Knowledge.

In other words, you are just ignorant about all you claim to have grand
ideas on.

You FAIL.

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
Date: Thu, 12 May 2022 02:24:07 +0100
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <87a6bn5yrs.fsf@bsb.me.uk>
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
<doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk>
<bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>
<87wner61gs.fsf@bsb.me.uk>
<pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@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="b918120b717b1a0036d52ef1ce111b9c";
logging-data="24581"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/c3VGpwSZibxlJdM/ZVS6T6ewzwGSzTjA="
Cancel-Lock: sha1:rm6CIk6DCJo0daUWvDMq6G+4pzg=
sha1:hd7jq/Y8BWgalAHfIRc8929Ka+U=
X-BSB-Auth: 1.213f550073ffb32a3e61.20220512022407BST.87a6bn5yrs.fsf@bsb.me.uk
 by: Ben - Thu, 12 May 2022 01:24 UTC

olcott <NoOne@NoWhere.com> writes:

> On 5/11/2022 7:25 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/11/2022 2:54 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>>>> this execution trace to the ax86 source-code of P.
>>>>>>
>>>>>> P called with what argument? I assume P.
>>>>>>
>>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>>
>>>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>>>> not halt, since you told us that it does. Post the code and someone
>>>>>> will help you find the bug.
>>>>>
>>>>> If you had the technical skill you could verify that it is 100%
>>>>> impossible for there to be anything wrong with the code on the basis
>>>>> of that of the verifiably correct execution trace that it derives.
>>>> You trace clearly and accurately shows that what you call the
>>>> "simulation of the input" is wrong.
>>>
>>> That is utter nonsense.
>>
>> The whole exchange is ridiculous. You post traces you now admit are
>> edited.
>
> I normally have that debug info disabled so it need not be edited.
> You needed to see that it really is recursive simulation (because you
> didn't believe me) so I left these details in.

No, I said it is not a nested simulation -- i.e. a simulation of a
function that then simulates a simulation and so on. It clearly isn't.
The trace is not a trace of what you claim your H is doing. That's why
you are hiding H and why you will never publish it.

>> You won't post the code for H because you know it's wrong.
>
> That is a ridiculously stupid thing to say when it is so dead obvious
> that I proved that the code is correct on the basis of the 14 lines of
> correct simulation that it produces.

Yet you still hide the code! You know it's wrong. If you really
thought you had anything of value, you would have have published
everything. Keeping secrets is a dead give-away.

> These things have been DEAD OBVIOUS for six months and everyone here
> is too stupid, dishonest or ignorant to acknowledge them.

Yet you have published nothing! It is, according to you, obvious that
you are right, so why are you not published and famous? Is every
journal editor and CS professor (the people editors get to review
papers) also stupid and dishonest? And how could you possibly know?

The truth is you simply can't find a way to make H(P,P) == false even
though P(P) halts sound anything other than preposterous, so what could
you possibly publish? No one will take traces over the code and you
know that when you show the code the game is up.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]( will keep repeating until understood )

<2eOdnW_GpMxt6eH_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 11 May 2022 21:46:08 -0500
Date: Wed, 11 May 2022 21:46:05 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]( will keep repeating until understood )
Content-Language: en-US
Newsgroups: comp.theory
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk> <bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>
<87wner61gs.fsf@bsb.me.uk> <pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@giganews.com>
<87a6bn5yrs.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87a6bn5yrs.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <2eOdnW_GpMxt6eH_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 83
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-H8ppVxXoKW6gXUJ7PbW+mELNiLnbbxdvI9xc3lYBn27JbGZt1jF7S+Ounfleo+nhE1YTDFNDsiazFbO!LQ/PoSRNGYUQk069iL6MGHkT8X8FhQhpUtxOfm0Y3P+nUwS5KTXRTo2pVtw7v80l9YyKRgJqNG8=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4817
 by: olcott - Thu, 12 May 2022 02:46 UTC

On 5/11/2022 8:24 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/11/2022 7:25 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/11/2022 2:54 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>>>>> this execution trace to the ax86 source-code of P.
>>>>>>>
>>>>>>> P called with what argument? I assume P.
>>>>>>>
>>>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>>>
>>>>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>>>>> not halt, since you told us that it does. Post the code and someone
>>>>>>> will help you find the bug.
>>>>>>
>>>>>> If you had the technical skill you could verify that it is 100%
>>>>>> impossible for there to be anything wrong with the code on the basis
>>>>>> of that of the verifiably correct execution trace that it derives.
>>>>> You trace clearly and accurately shows that what you call the
>>>>> "simulation of the input" is wrong.
>>>>
>>>> That is utter nonsense.
>>>
>>> The whole exchange is ridiculous. You post traces you now admit are
>>> edited.
>>
>> I normally have that debug info disabled so it need not be edited.
>> You needed to see that it really is recursive simulation (because you
>> didn't believe me) so I left these details in.
>
> No, I said it is not a nested simulation -- i.e. a simulation of a
> function that then simulates a simulation and so on. It clearly isn't.

I wrote it and it was the very most difficult part to write and thus I
know for a fact that it is.

> The trace is not a trace of what you claim your H is doing. That's why
> you are hiding H and why you will never publish it.

The trace is the trace of the input to H(P,P) does not bother to display
of the 236 pages of execution trace of H performing a pure simulation on
P that calls H that performs a pure simulation of P that would call H
again.

While the two levels of H are performing a pure simulation of their
inputs they have no behavior what-so-ever that can possibly have any
effect on the behavior of either of the simulated (P,P) instances.

This allows their instructions to be safely ignored when outputting the
most relevant portion of the execution trace. Instead of 237 pages we
only need to look at 14 lines.

*Maybe we should go over this point again and again over and*
*over hundreds of times if needed until you understand it*

It is so dead obvious that I proved that the code is correct on the
basis of the 14 lines of correct simulation that it produces.

It is also dead obvious and that and second function call from the same
machine address to the same function with the same parameters
conclusively proves infinite recursion.

These things have been DEAD OBVIOUS for six months and everyone here is
too stupid, dishonest or ignorant to acknowledge them.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]( will keep repeating until understood )

<oU_eK.2472$cQO2.2436@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.9.0
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]( will keep repeating until understood )
Content-Language: en-US
Newsgroups: comp.theory
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk> <doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk> <bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>
<87wner61gs.fsf@bsb.me.uk> <pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@giganews.com>
<87a6bn5yrs.fsf@bsb.me.uk> <2eOdnW_GpMxt6eH_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <2eOdnW_GpMxt6eH_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 110
Message-ID: <oU_eK.2472$cQO2.2436@fx47.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 11 May 2022 23:10:13 -0400
X-Received-Bytes: 5527
 by: Richard Damon - Thu, 12 May 2022 03:10 UTC

On 5/11/22 10:46 PM, olcott wrote:
> On 5/11/2022 8:24 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/11/2022 7:25 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/11/2022 2:54 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> (a) Verify that the execution trace of P by H is correct by
>>>>>>>>> comparing
>>>>>>>>> this execution trace to the ax86 source-code of P.
>>>>>>>>
>>>>>>>> P called with what argument?  I assume P.
>>>>>>>>
>>>>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>>>>
>>>>>>>> Something is wrong in your code if P(P), or a simulation of
>>>>>>>> P(P), does
>>>>>>>> not halt, since you told us that it does.  Post the code and
>>>>>>>> someone
>>>>>>>> will help you find the bug.
>>>>>>>
>>>>>>> If you had the technical skill you could verify that it is 100%
>>>>>>> impossible for there to be anything wrong with the code on the basis
>>>>>>> of that of the verifiably correct execution trace that it derives.
>>>>>> You trace clearly and accurately shows that what you call the
>>>>>> "simulation of the input" is wrong.
>>>>>
>>>>> That is utter nonsense.
>>>>
>>>> The whole exchange is ridiculous.  You post traces you now admit are
>>>> edited.
>>>
>>> I normally have that debug info disabled so it need not be edited.
>>> You needed to see that it really is recursive simulation (because you
>>> didn't believe me) so I left these details in.
>>
>> No, I said it is not a nested simulation -- i.e. a simulation of a
>> function that then simulates a simulation and so on.  It clearly isn't.
>
> I wrote it and it was the very most difficult part to write and thus I
> know for a fact that it is.
>
>> The trace is not a trace of what you claim your H is doing.  That's why
>> you are hiding H and why you will never publish it.
>
> The trace is the trace of the input to H(P,P) does not bother to display
> of the 236 pages of execution trace of H performing a pure simulation on
> P that calls H that performs a pure simulation of P that would call H
> again.
>
> While the two levels of H are performing a pure simulation of their
> inputs they have no behavior what-so-ever that can possibly have any
> effect on the behavior of either of the simulated (P,P) instances.

Except they DO. There are conditional branches, that contain the
capability to break the "infinite loop", and in fact which WILL break
the infinite loop of the outer simulator does.

Thus, the "rule" that the outer simulator is using isn't actually satisfied.

>
> This allows their instructions to be safely ignored when outputting the
> most relevant portion of the execution trace. Instead of 237 pages we
> only need to look at 14 lines.
>

Nope.

> *Maybe we should go over this point again and again over and*
> *over hundreds of times if needed until you understand it*
>

YOU are stuck in the infinite loop, because you don't understand your
termination conditin.

>
> It is so dead obvious that I proved that the code is correct on the
> basis of the 14 lines of correct simulation that it produces.

Yes, it is dead obvious that H is wrong, and the trace is incorrrect.

And, from your reports,

>
> It is also dead obvious and that and second function call from the same
> machine address to the same function with the same parameters
> conclusively proves infinite recursion.
>

Nope.
> These things have been DEAD OBVIOUS for six months and everyone here is
> too stupid, dishonest or ignorant to acknowledge them.
>

If you claim it is dead obvious, why haven't you submitted the paper,
before YOU are dead.

I think it is because you know you haven't actually proved what you
need, and are trying to refine your lie to try and get something that
maybe someone will publish posthumously out of pity, and maybe people
will be kind to the dead. It won't work, as you ideas are just too bad.

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]( will keep repeating until understood )

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]( will keep repeating until understood )
Date: Thu, 12 May 2022 21:32:32 +0100
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <87zgjm331b.fsf@bsb.me.uk>
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mtfpl73u.fsf@bsb.me.uk>
<doSdnZX9dO2SXub_nZ2dnUU7_8zNnZ2d@giganews.com>
<87h75v7slr.fsf@bsb.me.uk>
<bfWdnfqTUoqJseH_nZ2dnUU7_83NnZ2d@giganews.com>
<87wner61gs.fsf@bsb.me.uk>
<pq-dnaM1atBxy-H_nZ2dnUU7_8zNnZ2d@giganews.com>
<87a6bn5yrs.fsf@bsb.me.uk>
<2eOdnW_GpMxt6eH_nZ2dnUU7_81g4p2d@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="b918120b717b1a0036d52ef1ce111b9c";
logging-data="27725"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dq0PhqyQTKOW0+nYumaNB7frsxEiQ6Xw="
Cancel-Lock: sha1:/xADOPqV/KITplmXt+Yf69Ea/E0=
sha1:xOt2wsvca6gZBHQICC9VxiuZZjM=
X-BSB-Auth: 1.fad6323c823df1682cfc.20220512213232BST.87zgjm331b.fsf@bsb.me.uk
 by: Ben - Thu, 12 May 2022 20:32 UTC

olcott <NoOne@NoWhere.com> writes:

> On 5/11/2022 8:24 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/11/2022 7:25 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 5/11/2022 2:54 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>>>>>> this execution trace to the ax86 source-code of P.
>>>>>>>>
>>>>>>>> P called with what argument? I assume P.
>>>>>>>>
>>>>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>>>>
>>>>>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>>>>>> not halt, since you told us that it does. Post the code and someone
>>>>>>>> will help you find the bug.
>>>>>>>
>>>>>>> If you had the technical skill you could verify that it is 100%
>>>>>>> impossible for there to be anything wrong with the code on the basis
>>>>>>> of that of the verifiably correct execution trace that it derives.
>>>>>> You trace clearly and accurately shows that what you call the
>>>>>> "simulation of the input" is wrong.
>>>>>
>>>>> That is utter nonsense.
>>>>
>>>> The whole exchange is ridiculous. You post traces you now admit are
>>>> edited.
>>>
>>> I normally have that debug info disabled so it need not be edited.
>>> You needed to see that it really is recursive simulation (because you
>>> didn't believe me) so I left these details in.
>> No, I said it is not a nested simulation -- i.e. a simulation of a
>> function that then simulates a simulation and so on. It clearly isn't.
>
> I wrote it and it was the very most difficult part to write and thus I
> know for a fact that it is.

And you are determined to prevent anyone else from knowing it by (a)
hiding the code, and (b) publishing traces that don't show it. Show the
code or it didn't happen.

> These things have been DEAD OBVIOUS for six months and everyone here
> is too stupid, dishonest or ignorant to acknowledge them.

Yet, as I said, you have not been published, and you remain unheard of.

Dead obvious things that overturn key theorems should be easy to
publish. Even if you can't write clearly enough on your own, you should
be able to find a professor to co-author a paper with you. Since it's
dead obvious, how hard could it be to write?

Or maybe you are just deluded and wrong? After all, H(P,P) == false
even though P(P) halts is wrong by definition. You might struggle to
get anyone to co-author such a paper.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

<584bbad6-6184-4a00-83e8-91c0b787d12dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:1d08:b0:45a:a692:3bb2 with SMTP id e8-20020a0562141d0800b0045aa6923bb2mr5995331qvd.24.1652470700896;
Fri, 13 May 2022 12:38:20 -0700 (PDT)
X-Received: by 2002:a25:8c87:0:b0:64a:870a:e29d with SMTP id
m7-20020a258c87000000b0064a870ae29dmr6350232ybl.596.1652470700740; Fri, 13
May 2022 12:38:20 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 13 May 2022 12:38:20 -0700 (PDT)
In-Reply-To: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=A1PyIwoAAACCahK0CVYFlDZG8JWzz_Go
NNTP-Posting-Host: 124.218.76.41
References: <xpmdnb7bu_9vxOf_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <584bbad6-6184-4a00-83e8-91c0b787d12dn@googlegroups.com>
Subject: Re: Proof that H(P,P)==0 is correct [ refuting the halting problem
proofs ]
From: wynii...@gmail.com (wij)
Injection-Date: Fri, 13 May 2022 19:38:20 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1887
 by: wij - Fri, 13 May 2022 19:38 UTC

On Tuesday, 10 May 2022 at 20:26:33 UTC+8, olcott wrote:
> (a) Verify that the execution trace of P by H is correct by comparing
> this execution trace to the ax86 source-code of P.
>
> (b) Verify that this execution trace shows that P is stuck in infinitely
> nested simulation (a non-halting behavior).
>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>

H does not exist !!!. Your POOH is incorrect, totally garbage, nonsense.

According to GUR https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
It is dead obvious that correct halting decider dose not exist.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor