Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #50238 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2022-05-11 13:07 -0500 |
| Last post | 2022-05-13 12:21 -0700 |
| Articles | 20 on this page of 85 — 8 participants |
Back to article view | Back to comp.theory
Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 13:07 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-11 20:11 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 19:23 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 21:02 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 18:31 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 12:43 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 18:43 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 12:45 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 18:47 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 12:51 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 19:00 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 13:06 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 19:13 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 21:12 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 15:18 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 23:58 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 18:28 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-13 01:40 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 20:32 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 21:48 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-13 13:38 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 20:56 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 19:09 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 18:50 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 18:46 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 18:45 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 19:41 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 01:17 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 19:29 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 20:52 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 02:10 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-11 21:29 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-11 23:02 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-12 23:54 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 18:21 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 00:24 +0100
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) olcott <NoOne@NoWhere.com> - 2022-05-12 18:42 -0500
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Ben <ben.usenet@bsb.me.uk> - 2022-05-13 01:35 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-12 20:25 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-12 21:41 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 12:05 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 12:01 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 20:06 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 14:24 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 16:11 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 15:22 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Dennis Bush <dbush.mobile@gmail.com> - 2022-05-13 13:26 -0700
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 15:38 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 21:44 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] wij <wyniijj2@gmail.com> - 2022-05-13 13:27 -0700
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 17:22 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 16:48 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 18:04 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 17:06 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 19:07 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 18:09 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 19:20 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 18:26 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 20:04 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:20 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 20:41 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] André G. Isaak <agisaak@gm.invalid> - 2022-05-13 19:03 -0600
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 21:21 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 22:37 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-13 23:46 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 17:57 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 19:09 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 18:18 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Richard Damon <Richard@Damon-Family.org> - 2022-05-13 20:09 -0400
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:03 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:11 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:18 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 19:22 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Ben <ben.usenet@bsb.me.uk> - 2022-05-14 01:28 +0100
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-14 11:45 +0300
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-14 04:28 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-14 15:55 +0300
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-14 08:53 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-15 12:05 +0300
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-13 16:11 +0300
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] olcott <NoOne@NoWhere.com> - 2022-05-13 11:15 -0500
Re: Proof that H(P,P)==0 is correct [ foundation of truth itself ] Mikko <mikko.levanto@iki.fi> - 2022-05-14 11:26 +0300
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Richard Damon <Richard@Damon-Family.org> - 2022-05-12 21:03 -0400
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) Mikko <mikko.levanto@iki.fi> - 2022-05-13 16:02 +0300
Re: Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) wij <wyniijj2@gmail.com> - 2022-05-13 12:21 -0700
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-11 13:07 -0500 |
| Subject | Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ](V2) |
| Message-ID | <2pSdnR25lqHLZub_nZ2dnUU7_8zNnZ2d@giganews.com> |
Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]
The x86utm operating system was created so that every detail of the
conventional halting problem counter example could be fully specified in
C/x86.
In computability theory, the halting problem is the
problem of determining, from a description of an
arbitrary computer program and an input, whether the
program will finish running, or continue to run forever...
For any program f that might determine if programs halt,
a "pathological" program g, called with some input, can
pass its own source and its input to f and then specifically
do the opposite of what f predicts g will do. No f can exist
that handles this case. https://en.wikipedia.org/wiki/Halting_problem
This exact same relationship of f(g,g) was created as H(P,P), shown below.
This is the overview of the method for proving that this analysis is
correct:
(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).
This proof can only be understood only by those having sufficient
technical competence in:
(a) software engineering (recognizing infinite recursion in C and x86 code)
(b) the x86 programming language
(c) the C programming language and
(d) the details of how C is translated into x86 by the Microsoft C
compilers.
#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
[toc] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-11 20:11 +0100 |
| Message-ID | <20220511201154.00002147@reddwarf.jmc> |
| In reply to | #50238 |
On Wed, 11 May 2022 13:07:16 -0500
olcott <NoOne@NoWhere.com> wrote:
> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs
> ]
>
> The x86utm operating system was created so that every detail of the
> conventional halting problem counter example could be fully specified
> in C/x86.
>
> In computability theory, the halting problem is the
> problem of determining, from a description of an
> arbitrary computer program and an input, whether the
> program will finish running, or continue to run forever...
>
> For any program f that might determine if programs halt,
> a "pathological" program g, called with some input, can
> pass its own source and its input to f and then specifically
> do the opposite of what f predicts g will do. No f can exist
> that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> This exact same relationship of f(g,g) was created as H(P,P), shown
> below.
>
> This is the overview of the method for proving that this analysis is
> correct:
> (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).
>
> This proof can only be understood only by those having sufficient
> technical competence in:
> (a) software engineering (recognizing infinite recursion in C and x86
> code) (b) the x86 programming language
> (c) the C programming language and
> (d) the details of how C is translated into x86 by the Microsoft C
> compilers.
>
> #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
Your simulation approach is erroneous as there is no infinite
recursion; the key to understanding this is by realizing the
implication of the words "pass its own source" in the following:
For any program f that might determine if programs halt,
a "pathological" program g, called with some input, can
pass its own source and its input to f and then specifically
do the opposite of what f predicts g will do. No f can exist
that handles this case.
"pass its own source" is NOT the same as compiling and running its own
source as part of a simulation.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-11 19:23 -0500 |
| Message-ID | <lYydndd8nf4JzuH_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #50241 |
On 5/11/2022 2:11 PM, Mr Flibble wrote:
> On Wed, 11 May 2022 13:07:16 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs
>> ]
>>
>> The x86utm operating system was created so that every detail of the
>> conventional halting problem counter example could be fully specified
>> in C/x86.
>>
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an
>> arbitrary computer program and an input, whether the
>> program will finish running, or continue to run forever...
>>
>> For any program f that might determine if programs halt,
>> a "pathological" program g, called with some input, can
>> pass its own source and its input to f and then specifically
>> do the opposite of what f predicts g will do. No f can exist
>> that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> This exact same relationship of f(g,g) was created as H(P,P), shown
>> below.
>>
>> This is the overview of the method for proving that this analysis is
>> correct:
>> (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).
>>
>> This proof can only be understood only by those having sufficient
>> technical competence in:
>> (a) software engineering (recognizing infinite recursion in C and x86
>> code) (b) the x86 programming language
>> (c) the C programming language and
>> (d) the details of how C is translated into x86 by the Microsoft C
>> compilers.
>>
>> #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
>
> Your simulation approach is erroneous as there is no infinite
> recursion; the key to understanding this is by realizing the
> implication of the words "pass its own source" in the following:
YOU IGNORED THIS PART
This proof can only be understood only by those having sufficient
technical competence in:
(a) software engineering - recognizing infinite recursion in C/x86
(b) the x86 programming language
(c) the C programming language and
(d) the details of how C is translated into x86 by the Microsoft C
compilers.
> For any program f that might determine if programs halt,
> a "pathological" program g, called with some input, can
> pass its own source and its input to f and then specifically
> do the opposite of what f predicts g will do. No f can exist
> that handles this case.
>
> "pass its own source" is NOT the same as compiling and running its own
> source as part of a simulation.
Passing the finite string of its own machine code is equivalent to
passing its own source.
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-11 21:02 -0400 |
| Message-ID | <b0ZeK.1833$6y5f.1474@fx40.iad> |
| In reply to | #50257 |
On 5/11/22 8:23 PM, olcott wrote:
> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>> On Wed, 11 May 2022 13:07:16 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> Proof that H(P,P)==0 is correct [ refuting the halting problem proofs
>>> ]
>>>
>>> The x86utm operating system was created so that every detail of the
>>> conventional halting problem counter example could be fully specified
>>> in C/x86.
>>>
>>> In computability theory, the halting problem is the
>>> problem of determining, from a description of an
>>> arbitrary computer program and an input, whether the
>>> program will finish running, or continue to run forever...
>>>
>>> For any program f that might determine if programs halt,
>>> a "pathological" program g, called with some input, can
>>> pass its own source and its input to f and then specifically
>>> do the opposite of what f predicts g will do. No f can exist
>>> that handles this case.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> This exact same relationship of f(g,g) was created as H(P,P), shown
>>> below.
>>>
>>> This is the overview of the method for proving that this analysis is
>>> correct:
>>> (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).
>>>
>>> This proof can only be understood only by those having sufficient
>>> technical competence in:
>>> (a) software engineering (recognizing infinite recursion in C and x86
>>> code) (b) the x86 programming language
>>> (c) the C programming language and
>>> (d) the details of how C is translated into x86 by the Microsoft C
>>> compilers.
>>>
>>> #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
>>>
>>
>> Your simulation approach is erroneous as there is no infinite
>> recursion; the key to understanding this is by realizing the
>> implication of the words "pass its own source" in the following:
>
>
> YOU IGNORED THIS PART
>
> This proof can only be understood only by those having sufficient
> technical competence in:
> (a) software engineering - recognizing infinite recursion in C/x86
> (b) the x86 programming language
> (c) the C programming language and
> (d) the details of how C is translated into x86 by the Microsoft C
> compilers.
And those that are see it to be the lie that it is.
I really don't think YOU understand the material to the level you claim
is needed.
>
>> For any program f that might determine if programs halt,
>> a "pathological" program g, called with some input, can
>> pass its own source and its input to f and then specifically
>> do the opposite of what f predicts g will do. No f can exist
>> that handles this case.
>>
>> "pass its own source" is NOT the same as compiling and running its own
>> source as part of a simulation.
>
> Passing the finite string of its own machine code is equivalent to
> passing its own source.
Only key is that you confuse the PROGRAM P with the SUBROUTINE P.
The finite string is NOT a definition of the actual compuation being
asked about, so you fail at step one.
>
>>
>> /Flibble
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-12 18:31 +0100 |
| Message-ID | <20220512183107.00007721@reddwarf.jmc> |
| In reply to | #50257 |
On Wed, 11 May 2022 19:23:45 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/11/2022 2:11 PM, Mr Flibble wrote:
> > On Wed, 11 May 2022 13:07:16 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> Proof that H(P,P)==0 is correct [ refuting the halting problem
> >> proofs ]
> >>
> >> The x86utm operating system was created so that every detail of the
> >> conventional halting problem counter example could be fully
> >> specified in C/x86.
> >>
> >> In computability theory, the halting problem is the
> >> problem of determining, from a description of an
> >> arbitrary computer program and an input, whether the
> >> program will finish running, or continue to run forever...
> >>
> >> For any program f that might determine if programs halt,
> >> a "pathological" program g, called with some input, can
> >> pass its own source and its input to f and then specifically
> >> do the opposite of what f predicts g will do. No f can exist
> >> that handles this case.
> >> https://en.wikipedia.org/wiki/Halting_problem
> >>
> >> This exact same relationship of f(g,g) was created as H(P,P), shown
> >> below.
> >>
> >> This is the overview of the method for proving that this analysis
> >> is correct:
> >> (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).
> >>
> >> This proof can only be understood only by those having sufficient
> >> technical competence in:
> >> (a) software engineering (recognizing infinite recursion in C and
> >> x86 code) (b) the x86 programming language
> >> (c) the C programming language and
> >> (d) the details of how C is translated into x86 by the Microsoft C
> >> compilers.
> >>
> >> #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
> >>
> >
> > Your simulation approach is erroneous as there is no infinite
> > recursion; the key to understanding this is by realizing the
> > implication of the words "pass its own source" in the following:
>
>
> YOU IGNORED THIS PART
>
> This proof can only be understood only by those having sufficient
> technical competence in:
> (a) software engineering - recognizing infinite recursion in C/x86
> (b) the x86 programming language
> (c) the C programming language and
> (d) the details of how C is translated into x86 by the Microsoft C
> compilers.
>
> > For any program f that might determine if programs halt,
> > a "pathological" program g, called with some input, can
> > pass its own source and its input to f and then specifically
> > do the opposite of what f predicts g will do. No f can exist
> > that handles this case.
> >
> > "pass its own source" is NOT the same as compiling and running its
> > own source as part of a simulation.
>
> Passing the finite string of its own machine code is equivalent to
> passing its own source.
Indeed its own machine code is a representation of its own source code
so is valid to pass to a decider HOWEVER you ignored the second part
of my assertion:
"pass its own source" is NOT the same as compiling *AND RUNNING* its
own source as part of a simulation.
"AND RUNNING" means you cannot execute that machine code as part of a
simulation to correctly decide anything.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 12:43 -0500 |
| Message-ID | <YrydnRkeEcug2uD_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50283 |
On 5/12/2022 12:31 PM, Mr Flibble wrote:
> On Wed, 11 May 2022 19:23:45 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>>> On Wed, 11 May 2022 13:07:16 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>> proofs ]
>>>>
>>>> The x86utm operating system was created so that every detail of the
>>>> conventional halting problem counter example could be fully
>>>> specified in C/x86.
>>>>
>>>> In computability theory, the halting problem is the
>>>> problem of determining, from a description of an
>>>> arbitrary computer program and an input, whether the
>>>> program will finish running, or continue to run forever...
>>>>
>>>> For any program f that might determine if programs halt,
>>>> a "pathological" program g, called with some input, can
>>>> pass its own source and its input to f and then specifically
>>>> do the opposite of what f predicts g will do. No f can exist
>>>> that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> This exact same relationship of f(g,g) was created as H(P,P), shown
>>>> below.
>>>>
>>>> This is the overview of the method for proving that this analysis
>>>> is correct:
>>>> (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).
>>>>
>>>> This proof can only be understood only by those having sufficient
>>>> technical competence in:
>>>> (a) software engineering (recognizing infinite recursion in C and
>>>> x86 code) (b) the x86 programming language
>>>> (c) the C programming language and
>>>> (d) the details of how C is translated into x86 by the Microsoft C
>>>> compilers.
>>>>
>>>> #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
>>>>
>>>
>>> Your simulation approach is erroneous as there is no infinite
>>> recursion; the key to understanding this is by realizing the
>>> implication of the words "pass its own source" in the following:
>>
>>
>> YOU IGNORED THIS PART
>>
>> This proof can only be understood only by those having sufficient
>> technical competence in:
>> (a) software engineering - recognizing infinite recursion in C/x86
>> (b) the x86 programming language
>> (c) the C programming language and
>> (d) the details of how C is translated into x86 by the Microsoft C
>> compilers.
>>
>>> For any program f that might determine if programs halt,
>>> a "pathological" program g, called with some input, can
>>> pass its own source and its input to f and then specifically
>>> do the opposite of what f predicts g will do. No f can exist
>>> that handles this case.
>>>
>>> "pass its own source" is NOT the same as compiling and running its
>>> own source as part of a simulation.
>>
>> Passing the finite string of its own machine code is equivalent to
>> passing its own source.
>
> Indeed its own machine code is a representation of its own source code
> so is valid to pass to a decider HOWEVER you ignored the second part
> of my assertion:
>
> "pass its own source" is NOT the same as compiling *AND RUNNING* its
> own source as part of a simulation.
>
My x86utm operating system operates exclusively on a compiled Microsoft
COFF object rile that has already been compiled.
> "AND RUNNING" means you cannot execute that machine code as part of a
> simulation to correctly decide anything.
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-12 18:43 +0100 |
| Message-ID | <20220512184323.000078f7@reddwarf.jmc> |
| In reply to | #50257 |
On Wed, 11 May 2022 19:23:45 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/11/2022 2:11 PM, Mr Flibble wrote:
> > On Wed, 11 May 2022 13:07:16 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> Proof that H(P,P)==0 is correct [ refuting the halting problem
> >> proofs ]
> >>
> >> The x86utm operating system was created so that every detail of the
> >> conventional halting problem counter example could be fully
> >> specified in C/x86.
> >>
> >> In computability theory, the halting problem is the
> >> problem of determining, from a description of an
> >> arbitrary computer program and an input, whether the
> >> program will finish running, or continue to run forever...
> >>
> >> For any program f that might determine if programs halt,
> >> a "pathological" program g, called with some input, can
> >> pass its own source and its input to f and then specifically
> >> do the opposite of what f predicts g will do. No f can exist
> >> that handles this case.
> >> https://en.wikipedia.org/wiki/Halting_problem
> >>
> >> This exact same relationship of f(g,g) was created as H(P,P), shown
> >> below.
> >>
> >> This is the overview of the method for proving that this analysis
> >> is correct:
> >> (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).
> >>
> >> This proof can only be understood only by those having sufficient
> >> technical competence in:
> >> (a) software engineering (recognizing infinite recursion in C and
> >> x86 code) (b) the x86 programming language
> >> (c) the C programming language and
> >> (d) the details of how C is translated into x86 by the Microsoft C
> >> compilers.
> >>
> >> #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
> >>
> >
> > Your simulation approach is erroneous as there is no infinite
> > recursion; the key to understanding this is by realizing the
> > implication of the words "pass its own source" in the following:
>
>
> YOU IGNORED THIS PART
>
> This proof can only be understood only by those having sufficient
> technical competence in:
> (a) software engineering - recognizing infinite recursion in C/x86
> (b) the x86 programming language
> (c) the C programming language and
> (d) the details of how C is translated into x86 by the Microsoft C
> compilers.
(a) I have been a software developer/engineer since 1993 and am able to
recognize infinite recursion and additionally, and more importantly, a
lack of infinite recursion.
(b) I have been familiar with x86 assembly since before 1993
(c) I understand and have competence in both C and C++ (having used the
latter since 1993)
(d) I have written a compiler, have you?
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 12:45 -0500 |
| Message-ID | <YrydnRgeEcs22uD_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50284 |
On 5/12/2022 12:43 PM, Mr Flibble wrote:
> On Wed, 11 May 2022 19:23:45 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>>> On Wed, 11 May 2022 13:07:16 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>> proofs ]
>>>>
>>>> The x86utm operating system was created so that every detail of the
>>>> conventional halting problem counter example could be fully
>>>> specified in C/x86.
>>>>
>>>> In computability theory, the halting problem is the
>>>> problem of determining, from a description of an
>>>> arbitrary computer program and an input, whether the
>>>> program will finish running, or continue to run forever...
>>>>
>>>> For any program f that might determine if programs halt,
>>>> a "pathological" program g, called with some input, can
>>>> pass its own source and its input to f and then specifically
>>>> do the opposite of what f predicts g will do. No f can exist
>>>> that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> This exact same relationship of f(g,g) was created as H(P,P), shown
>>>> below.
>>>>
>>>> This is the overview of the method for proving that this analysis
>>>> is correct:
>>>> (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).
>>>>
>>>> This proof can only be understood only by those having sufficient
>>>> technical competence in:
>>>> (a) software engineering (recognizing infinite recursion in C and
>>>> x86 code) (b) the x86 programming language
>>>> (c) the C programming language and
>>>> (d) the details of how C is translated into x86 by the Microsoft C
>>>> compilers.
>>>>
>>>> #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
>>>>
>>>
>>> Your simulation approach is erroneous as there is no infinite
>>> recursion; the key to understanding this is by realizing the
>>> implication of the words "pass its own source" in the following:
>>
>>
>> YOU IGNORED THIS PART
>>
>> This proof can only be understood only by those having sufficient
>> technical competence in:
>> (a) software engineering - recognizing infinite recursion in C/x86
>> (b) the x86 programming language
>> (c) the C programming language and
>> (d) the details of how C is translated into x86 by the Microsoft C
>> compilers.
>
> (a) I have been a software developer/engineer since 1993 and am able to
> recognize infinite recursion and additionally, and more importantly, a
> lack of infinite recursion.
This has been disproven in that you did not see this:
>>>> 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.
> (b) I have been familiar with x86 assembly since before 1993
> (c) I understand and have competence in both C and C++ (having used the
> latter since 1993)
> (d) I have written a compiler, have you?
>
> /Flibble
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-12 18:47 +0100 |
| Message-ID | <20220512184716.00007086@reddwarf.jmc> |
| In reply to | #50286 |
On Thu, 12 May 2022 12:45:15 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/12/2022 12:43 PM, Mr Flibble wrote:
> > On Wed, 11 May 2022 19:23:45 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/11/2022 2:11 PM, Mr Flibble wrote:
> >>> On Wed, 11 May 2022 13:07:16 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
> >>>> proofs ]
> >>>>
> >>>> The x86utm operating system was created so that every detail of
> >>>> the conventional halting problem counter example could be fully
> >>>> specified in C/x86.
> >>>>
> >>>> In computability theory, the halting problem is the
> >>>> problem of determining, from a description of an
> >>>> arbitrary computer program and an input, whether the
> >>>> program will finish running, or continue to run forever...
> >>>>
> >>>> For any program f that might determine if programs halt,
> >>>> a "pathological" program g, called with some input, can
> >>>> pass its own source and its input to f and then
> >>>> specifically do the opposite of what f predicts g will do. No f
> >>>> can exist that handles this case.
> >>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>
> >>>> This exact same relationship of f(g,g) was created as H(P,P),
> >>>> shown below.
> >>>>
> >>>> This is the overview of the method for proving that this analysis
> >>>> is correct:
> >>>> (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).
> >>>>
> >>>> This proof can only be understood only by those having sufficient
> >>>> technical competence in:
> >>>> (a) software engineering (recognizing infinite recursion in C and
> >>>> x86 code) (b) the x86 programming language
> >>>> (c) the C programming language and
> >>>> (d) the details of how C is translated into x86 by the Microsoft
> >>>> C compilers.
> >>>>
> >>>> #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
> >>>>
> >>>
> >>> Your simulation approach is erroneous as there is no infinite
> >>> recursion; the key to understanding this is by realizing the
> >>> implication of the words "pass its own source" in the following:
> >>
> >>
> >> YOU IGNORED THIS PART
> >>
> >> This proof can only be understood only by those having sufficient
> >> technical competence in:
> >> (a) software engineering - recognizing infinite recursion in C/x86
> >> (b) the x86 programming language
> >> (c) the C programming language and
> >> (d) the details of how C is translated into x86 by the Microsoft C
> >> compilers.
> >
> > (a) I have been a software developer/engineer since 1993 and am
> > able to recognize infinite recursion and additionally, and more
> > importantly, a lack of infinite recursion.
>
> This has been disproven in that you did not see this:
>
> >>>> 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.
I am not talking about your braindead simulation, I am talking about
the halting problem proofs you are trying to refute: THEY DO NOT HAVE
AN INFINITE RECURSION.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 12:51 -0500 |
| Message-ID | <28Odnb4QI9a91OD_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #50287 |
On 5/12/2022 12:47 PM, Mr Flibble wrote:
> On Thu, 12 May 2022 12:45:15 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/12/2022 12:43 PM, Mr Flibble wrote:
>>> On Wed, 11 May 2022 19:23:45 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>>>>> On Wed, 11 May 2022 13:07:16 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>>>> proofs ]
>>>>>>
>>>>>> The x86utm operating system was created so that every detail of
>>>>>> the conventional halting problem counter example could be fully
>>>>>> specified in C/x86.
>>>>>>
>>>>>> In computability theory, the halting problem is the
>>>>>> problem of determining, from a description of an
>>>>>> arbitrary computer program and an input, whether the
>>>>>> program will finish running, or continue to run forever...
>>>>>>
>>>>>> For any program f that might determine if programs halt,
>>>>>> a "pathological" program g, called with some input, can
>>>>>> pass its own source and its input to f and then
>>>>>> specifically do the opposite of what f predicts g will do. No f
>>>>>> can exist that handles this case.
>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> This exact same relationship of f(g,g) was created as H(P,P),
>>>>>> shown below.
>>>>>>
>>>>>> This is the overview of the method for proving that this analysis
>>>>>> is correct:
>>>>>> (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).
>>>>>>
>>>>>> This proof can only be understood only by those having sufficient
>>>>>> technical competence in:
>>>>>> (a) software engineering (recognizing infinite recursion in C and
>>>>>> x86 code) (b) the x86 programming language
>>>>>> (c) the C programming language and
>>>>>> (d) the details of how C is translated into x86 by the Microsoft
>>>>>> C compilers.
>>>>>>
>>>>>> #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
>>>>>>
>>>>>
>>>>> Your simulation approach is erroneous as there is no infinite
>>>>> recursion; the key to understanding this is by realizing the
>>>>> implication of the words "pass its own source" in the following:
>>>>
>>>>
>>>> YOU IGNORED THIS PART
>>>>
>>>> This proof can only be understood only by those having sufficient
>>>> technical competence in:
>>>> (a) software engineering - recognizing infinite recursion in C/x86
>>>> (b) the x86 programming language
>>>> (c) the C programming language and
>>>> (d) the details of how C is translated into x86 by the Microsoft C
>>>> compilers.
>>>
>>> (a) I have been a software developer/engineer since 1993 and am
>>> able to recognize infinite recursion and additionally, and more
>>> importantly, a lack of infinite recursion.
>>
>> This has been disproven in that you did not see this:
>>
>> >>>> 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.
>
> I am not talking about your braindead simulation, I am talking about
> the halting problem proofs you are trying to refute: THEY DO NOT HAVE
> AN INFINITE RECURSION.
>
> /Flibble
>
My proofs prove that they do.
That you fail to comprehend this is no rebuttal at all.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-12 19:00 +0100 |
| Message-ID | <20220512190002.00001651@reddwarf.jmc> |
| In reply to | #50288 |
On Thu, 12 May 2022 12:51:27 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/12/2022 12:47 PM, Mr Flibble wrote:
> > On Thu, 12 May 2022 12:45:15 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/12/2022 12:43 PM, Mr Flibble wrote:
> >>> On Wed, 11 May 2022 19:23:45 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
> >>>>> On Wed, 11 May 2022 13:07:16 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
> >>>>>> proofs ]
> >>>>>>
> >>>>>> The x86utm operating system was created so that every detail of
> >>>>>> the conventional halting problem counter example could be fully
> >>>>>> specified in C/x86.
> >>>>>>
> >>>>>> In computability theory, the halting problem is the
> >>>>>> problem of determining, from a description of an
> >>>>>> arbitrary computer program and an input, whether the
> >>>>>> program will finish running, or continue to run
> >>>>>> forever...
> >>>>>>
> >>>>>> For any program f that might determine if programs halt,
> >>>>>> a "pathological" program g, called with some input, can
> >>>>>> pass its own source and its input to f and then
> >>>>>> specifically do the opposite of what f predicts g will do. No f
> >>>>>> can exist that handles this case.
> >>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>
> >>>>>> This exact same relationship of f(g,g) was created as H(P,P),
> >>>>>> shown below.
> >>>>>>
> >>>>>> This is the overview of the method for proving that this
> >>>>>> analysis is correct:
> >>>>>> (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).
> >>>>>>
> >>>>>> This proof can only be understood only by those having
> >>>>>> sufficient technical competence in:
> >>>>>> (a) software engineering (recognizing infinite recursion in C
> >>>>>> and x86 code) (b) the x86 programming language
> >>>>>> (c) the C programming language and
> >>>>>> (d) the details of how C is translated into x86 by the
> >>>>>> Microsoft C compilers.
> >>>>>>
> >>>>>> #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
> >>>>>>
> >>>>>
> >>>>> Your simulation approach is erroneous as there is no infinite
> >>>>> recursion; the key to understanding this is by realizing the
> >>>>> implication of the words "pass its own source" in the
> >>>>> following:
> >>>>
> >>>>
> >>>> YOU IGNORED THIS PART
> >>>>
> >>>> This proof can only be understood only by those having sufficient
> >>>> technical competence in:
> >>>> (a) software engineering - recognizing infinite recursion in
> >>>> C/x86 (b) the x86 programming language
> >>>> (c) the C programming language and
> >>>> (d) the details of how C is translated into x86 by the Microsoft
> >>>> C compilers.
> >>>
> >>> (a) I have been a software developer/engineer since 1993 and am
> >>> able to recognize infinite recursion and additionally, and more
> >>> importantly, a lack of infinite recursion.
> >>
> >> This has been disproven in that you did not see this:
> >>
> >> >>>> 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.
> >
> > I am not talking about your braindead simulation, I am talking about
> > the halting problem proofs you are trying to refute: THEY DO NOT
> > HAVE AN INFINITE RECURSION.
> >
> > /Flibble
> >
>
> My proofs prove that they do.
> That you fail to comprehend this is no rebuttal at all.
Only your simulation contains an infinite recursion due to a category
error ON YOUR PART. Your category error is proof that your
simulation-based proof is in error.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 13:06 -0500 |
| Message-ID | <nNSdnRSV0Zck0eD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #50289 |
On 5/12/2022 1:00 PM, Mr Flibble wrote:
> On Thu, 12 May 2022 12:51:27 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/12/2022 12:47 PM, Mr Flibble wrote:
>>> On Thu, 12 May 2022 12:45:15 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/12/2022 12:43 PM, Mr Flibble wrote:
>>>>> On Wed, 11 May 2022 19:23:45 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
>>>>>>> On Wed, 11 May 2022 13:07:16 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting problem
>>>>>>>> proofs ]
>>>>>>>>
>>>>>>>> The x86utm operating system was created so that every detail of
>>>>>>>> the conventional halting problem counter example could be fully
>>>>>>>> specified in C/x86.
>>>>>>>>
>>>>>>>> In computability theory, the halting problem is the
>>>>>>>> problem of determining, from a description of an
>>>>>>>> arbitrary computer program and an input, whether the
>>>>>>>> program will finish running, or continue to run
>>>>>>>> forever...
>>>>>>>>
>>>>>>>> For any program f that might determine if programs halt,
>>>>>>>> a "pathological" program g, called with some input, can
>>>>>>>> pass its own source and its input to f and then
>>>>>>>> specifically do the opposite of what f predicts g will do. No f
>>>>>>>> can exist that handles this case.
>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>> This exact same relationship of f(g,g) was created as H(P,P),
>>>>>>>> shown below.
>>>>>>>>
>>>>>>>> This is the overview of the method for proving that this
>>>>>>>> analysis is correct:
>>>>>>>> (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).
>>>>>>>>
>>>>>>>> This proof can only be understood only by those having
>>>>>>>> sufficient technical competence in:
>>>>>>>> (a) software engineering (recognizing infinite recursion in C
>>>>>>>> and x86 code) (b) the x86 programming language
>>>>>>>> (c) the C programming language and
>>>>>>>> (d) the details of how C is translated into x86 by the
>>>>>>>> Microsoft C compilers.
>>>>>>>>
>>>>>>>> #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
>>>>>>>>
>>>>>>>
>>>>>>> Your simulation approach is erroneous as there is no infinite
>>>>>>> recursion; the key to understanding this is by realizing the
>>>>>>> implication of the words "pass its own source" in the
>>>>>>> following:
>>>>>>
>>>>>>
>>>>>> YOU IGNORED THIS PART
>>>>>>
>>>>>> This proof can only be understood only by those having sufficient
>>>>>> technical competence in:
>>>>>> (a) software engineering - recognizing infinite recursion in
>>>>>> C/x86 (b) the x86 programming language
>>>>>> (c) the C programming language and
>>>>>> (d) the details of how C is translated into x86 by the Microsoft
>>>>>> C compilers.
>>>>>
>>>>> (a) I have been a software developer/engineer since 1993 and am
>>>>> able to recognize infinite recursion and additionally, and more
>>>>> importantly, a lack of infinite recursion.
>>>>
>>>> This has been disproven in that you did not see this:
>>>>
>>>> >>>> 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.
>>>
>>> I am not talking about your braindead simulation, I am talking about
>>> the halting problem proofs you are trying to refute: THEY DO NOT
>>> HAVE AN INFINITE RECURSION.
>>>
>>> /Flibble
>>>
>>
>> My proofs prove that they do.
>> That you fail to comprehend this is no rebuttal at all.
>
> Only your simulation contains an infinite recursion due to a category
> error ON YOUR PART. Your category error is proof that your
> simulation-based proof is in error.
>
> /Flibble
>
> PO's idea is to have a simulator with an infinite cycle detector.
> You would achieve this by modifying a UTM, so describing it as
> a "modified UTM", or "acts like a UTM until it detects an infinite
> cycle", is reasonable. And such a machine is a fairly powerful
> halt decider. Even if the infinite cycle detector isn't very
> sophisticated, it will still catch a large subset of non-halting
> machines.
The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ.
There is no need for the infinite loop after H.qy because it is never
reached. The halting criteria has been adapted so that it applies to a
simulating halt decider (SHD).
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating: (unless their simulation is aborted)
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
Since we can see that the simulated input: ⟨Ĥ0⟩ to H would never reach
its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is non-halting.
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-05-12 19:13 +0100 |
| Message-ID | <20220512191355.000050d4@reddwarf.jmc> |
| In reply to | #50291 |
On Thu, 12 May 2022 13:06:48 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 5/12/2022 1:00 PM, Mr Flibble wrote:
> > On Thu, 12 May 2022 12:51:27 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/12/2022 12:47 PM, Mr Flibble wrote:
> >>> On Thu, 12 May 2022 12:45:15 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/12/2022 12:43 PM, Mr Flibble wrote:
> >>>>> On Wed, 11 May 2022 19:23:45 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 5/11/2022 2:11 PM, Mr Flibble wrote:
> >>>>>>> On Wed, 11 May 2022 13:07:16 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> Proof that H(P,P)==0 is correct [ refuting the halting
> >>>>>>>> problem proofs ]
> >>>>>>>>
> >>>>>>>> The x86utm operating system was created so that every detail
> >>>>>>>> of the conventional halting problem counter example could be
> >>>>>>>> fully specified in C/x86.
> >>>>>>>>
> >>>>>>>> In computability theory, the halting problem is the
> >>>>>>>> problem of determining, from a description of an
> >>>>>>>> arbitrary computer program and an input, whether the
> >>>>>>>> program will finish running, or continue to run
> >>>>>>>> forever...
> >>>>>>>>
> >>>>>>>> For any program f that might determine if programs
> >>>>>>>> halt, a "pathological" program g, called with some input, can
> >>>>>>>> pass its own source and its input to f and then
> >>>>>>>> specifically do the opposite of what f predicts g will do.
> >>>>>>>> No f can exist that handles this case.
> >>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>
> >>>>>>>> This exact same relationship of f(g,g) was created as H(P,P),
> >>>>>>>> shown below.
> >>>>>>>>
> >>>>>>>> This is the overview of the method for proving that this
> >>>>>>>> analysis is correct:
> >>>>>>>> (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).
> >>>>>>>>
> >>>>>>>> This proof can only be understood only by those having
> >>>>>>>> sufficient technical competence in:
> >>>>>>>> (a) software engineering (recognizing infinite recursion in C
> >>>>>>>> and x86 code) (b) the x86 programming language
> >>>>>>>> (c) the C programming language and
> >>>>>>>> (d) the details of how C is translated into x86 by the
> >>>>>>>> Microsoft C compilers.
> >>>>>>>>
> >>>>>>>> #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
> >>>>>>>>
> >>>>>>>
> >>>>>>> Your simulation approach is erroneous as there is no infinite
> >>>>>>> recursion; the key to understanding this is by realizing the
> >>>>>>> implication of the words "pass its own source" in the
> >>>>>>> following:
> >>>>>>
> >>>>>>
> >>>>>> YOU IGNORED THIS PART
> >>>>>>
> >>>>>> This proof can only be understood only by those having
> >>>>>> sufficient technical competence in:
> >>>>>> (a) software engineering - recognizing infinite recursion in
> >>>>>> C/x86 (b) the x86 programming language
> >>>>>> (c) the C programming language and
> >>>>>> (d) the details of how C is translated into x86 by the
> >>>>>> Microsoft C compilers.
> >>>>>
> >>>>> (a) I have been a software developer/engineer since 1993 and am
> >>>>> able to recognize infinite recursion and additionally, and more
> >>>>> importantly, a lack of infinite recursion.
> >>>>
> >>>> This has been disproven in that you did not see this:
> >>>>
> >>>> >>>> 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.
> >>>
> >>> I am not talking about your braindead simulation, I am talking
> >>> about the halting problem proofs you are trying to refute: THEY
> >>> DO NOT HAVE AN INFINITE RECURSION.
> >>>
> >>> /Flibble
> >>>
> >>
> >> My proofs prove that they do.
> >> That you fail to comprehend this is no rebuttal at all.
> >
> > Only your simulation contains an infinite recursion due to a
> > category error ON YOUR PART. Your category error is proof that your
> > simulation-based proof is in error.
> >
> > /Flibble
> >
>
> > PO's idea is to have a simulator with an infinite cycle detector.
> > You would achieve this by modifying a UTM, so describing it as
> > a "modified UTM", or "acts like a UTM until it detects an infinite
> > cycle", is reasonable. And such a machine is a fairly powerful
> > halt decider. Even if the infinite cycle detector isn't very
> > sophisticated, it will still catch a large subset of non-halting
> > machines.
There is no point detecting infinite cycles as there is no infinite
recursion in the halting problem proofs you are trying to refute.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-12 21:12 +0100 |
| Message-ID | <87bkw24ij5.fsf@bsb.me.uk> |
| In reply to | #50291 |
olcott <NoOne@NoWhere.com> writes: > The halting criteria has been adapted so that H is no longer a halt decider. > it applies to a > simulating halt decider (SHD). > > Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy > If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own > final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩. This not Linz's Ĥ. Linz's H leads to a contradiction because of how H and the "hat" construction are defined. Using a different "hat" construction, and an "adapted" halt criterion, means you are not addressing Linz's (or anyone's) proof. Why do you think anyone will take any claims about your bogus seriously? > Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn > If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its > own final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩. A halt decider would have this simple behaviour: J ⟨M⟩ s ⊢* J.qy if M applied to s halts, and J ⟨M⟩ s ⊢* J.qn if M applied to s does not halt. (I've changed the name because you are abusing H and Ĥ to refer to TMs that do not meet Linz's specifications.) Which, with the correct "hat" construction applied, results in Ĵ.q0 ⟨Ĵ⟩ ⊢* J ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* J.qy ⊢* oo if J applied to ⟨Ĵ⟩ ⟨Ĵ⟩ halts, and Ĵ.q0 ⟨Ĵ⟩ ⊢* J ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* J.qn if J applied to ⟨Ĵ⟩ ⟨Ĵ⟩ does not halt which, as Linz says, is clearly nonsense. No TM can behave as Ĵ was assumed to behave. I bring this up only for the benefit of anyone who is still interested in how the proof works. You stopped talking about the halting problem and it's proofs some while ago, having failed to persuade anyone that the wrong answer is the right one. > Linz, Peter 1990. An Introduction to Formal Languages and > Automata. Lexington/Toronto: D. C. Heath and Company. (317-320) Bit of a nerve to cite Linz when you are ignoring his specification and his proof! -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 15:18 -0500 |
| Message-ID | <L-ydnag1-YUx9uD_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #50295 |
On 5/12/2022 3:12 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> The halting criteria has been adapted so that > > H is no longer a halt decider. > >> it applies to a >> simulating halt decider (SHD). >> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy >> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own >> final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩. > > This not Linz's Ĥ. Linz's H leads to a contradiction because of how H > and the "hat" construction are defined. Using a different "hat" > construction, and an "adapted" halt criterion, means you are not > addressing Linz's (or anyone's) proof. Why do you think anyone will > take any claims about your bogus seriously? > >> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn >> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its >> own final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩. > > A halt decider would have this simple behaviour: > > J ⟨M⟩ s ⊢* J.qy if M applied to s halts, and > J ⟨M⟩ s ⊢* J.qn if M applied to s does not halt. > > (I've changed the name because you are abusing H and Ĥ to refer to TMs > that do not meet Linz's specifications.) > > Which, with the correct "hat" construction applied, results in > > Ĵ.q0 ⟨Ĵ⟩ ⊢* J ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* J.qy ⊢* oo if J applied to ⟨Ĵ⟩ ⟨Ĵ⟩ halts, and > Ĵ.q0 ⟨Ĵ⟩ ⊢* J ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* J.qn if J applied to ⟨Ĵ⟩ ⟨Ĵ⟩ does not halt > > which, as Linz says, is clearly nonsense. No TM can behave as Ĵ was > assumed to behave. > > I bring this up only for the benefit of anyone who is still interested > in how the proof works. You stopped talking about the halting problem > and it's proofs some while ago, having failed to persuade anyone that > the wrong answer is the right one. > >> Linz, Peter 1990. An Introduction to Formal Languages and >> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320) > > Bit of a nerve to cite Linz when you are ignoring his specification and > his proof! > My only point is that the input to embedded_H does specifies infinitely nested simulation contradicting Flibble's claim that it does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-12 23:58 +0100 |
| Message-ID | <87bkw22w9v.fsf@bsb.me.uk> |
| In reply to | #50296 |
olcott <NoOne@NoWhere.com> writes: > On 5/12/2022 3:12 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> The halting criteria has been adapted so that >> >> H is no longer a halt decider. <cut various errors> > My only point is that the input to embedded_H does specifies > infinitely nested simulation contradicting Flibble's claim that it > does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. You made lots of point. Many of them wrong. I pointed out some of the errors. But since you are now unashamedly admitting to using an adapted criterion for halting, is there any point in carrying on? -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 18:28 -0500 |
| Message-ID | <14mdnf3FjKW4BeD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #50311 |
On 5/12/2022 5:58 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 5/12/2022 3:12 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> The halting criteria has been adapted so that >>> >>> H is no longer a halt decider. > > <cut various errors> > >> My only point is that the input to embedded_H does specifies >> infinitely nested simulation contradicting Flibble's claim that it >> does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. > > You made lots of point. Many of them wrong. I pointed out some of the > errors. > > But since you are now unashamedly admitting to using an adapted > criterion for halting, is there any point in carrying on? > I proved that the criteria for halting is objectively incorrect. It requires a decider to base its decision on a non-input thus directly contradicting the definition of a decider thus making the requirement itself incorrect. My H conclusively proves that it does correctly compute the mapping from its input finite strings to its own reject state on the basis of the actual behavior specified by these finite strings. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-05-13 01:40 +0100 |
| Message-ID | <87ee0y1czv.fsf@bsb.me.uk> |
| In reply to | #50321 |
olcott <NoOne@NoWhere.com> writes: > On 5/12/2022 5:58 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 5/12/2022 3:12 PM, Ben wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> The halting criteria has been adapted so that >>>> >>>> H is no longer a halt decider. >> <cut various errors> >> >>> My only point is that the input to embedded_H does specifies >>> infinitely nested simulation contradicting Flibble's claim that it >>> does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. >> You made lots of point. Many of them wrong. I pointed out some of the >> errors. >> But since you are now unashamedly admitting to using an adapted >> criterion for halting, is there any point in carrying on? > > I proved that the criteria for halting is objectively incorrect. It can't be incorrect. It's a definition. And it's based on the most natural notion: is the sequence of TM configurations finite or not. > It requires a decider to base its decision on a non-input thus > directly contradicting the definition of a decider thus making the > requirement itself incorrect. No, halting has to be based on the input. The input contains everything that specifies the sequence of configurations, yet no algorithm exists that can made the determination from the input alone. -- Ben. "le génie humain a des limites, quand la bêtise humaine n’en a pas" Alexandre Dumas (fils)
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-05-12 20:32 -0500 |
| Message-ID | <D7WdnSno4syOKOD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #50333 |
On 5/12/2022 7:40 PM, Ben wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 5/12/2022 5:58 PM, Ben wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> On 5/12/2022 3:12 PM, Ben wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> The halting criteria has been adapted so that >>>>> >>>>> H is no longer a halt decider. >>> <cut various errors> >>> >>>> My only point is that the input to embedded_H does specifies >>>> infinitely nested simulation contradicting Flibble's claim that it >>>> does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. >>> You made lots of point. Many of them wrong. I pointed out some of the >>> errors. >>> But since you are now unashamedly admitting to using an adapted >>> criterion for halting, is there any point in carrying on? >> >> I proved that the criteria for halting is objectively incorrect. > > It can't be incorrect. It's a definition. And it's based on the most > natural notion: is the sequence of TM configurations finite or not. It is an objectively verifiable fact that the sequence of configurations specified by the input to H(P,P) is not the same as the one specified by P(P). When you have two definitions in computer science that directly contradict each other what do you do? Toss out at least one of them. >> It requires a decider to base its decision on a non-input thus >> directly contradicting the definition of a decider thus making the >> requirement itself incorrect. > > No, halting has to be based on the input. The H(P,P)==0 is correct. > The input contains everything > that specifies the sequence of configurations, It is an objectively verifiable fact that the sequence of configurations specified by the input to H(P,P) is not the same as the one specified by P(P). > yet no algorithm exists > that can made the determination from the input alone. > H(P,P)==0 and H1(P,P)==1 are both provably correct. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-05-12 21:48 -0400 |
| Message-ID | <CNifK.1433$j0D5.227@fx09.iad> |
| In reply to | #50341 |
On 5/12/22 9:32 PM, olcott wrote: > On 5/12/2022 7:40 PM, Ben wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 5/12/2022 5:58 PM, Ben wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 5/12/2022 3:12 PM, Ben wrote: >>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>> >>>>>>> The halting criteria has been adapted so that >>>>>> >>>>>> H is no longer a halt decider. >>>> <cut various errors> >>>> >>>>> My only point is that the input to embedded_H does specifies >>>>> infinitely nested simulation contradicting Flibble's claim that it >>>>> does not, thus my H(P,P) is equivalent to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. >>>> You made lots of point. Many of them wrong. I pointed out some of the >>>> errors. >>>> But since you are now unashamedly admitting to using an adapted >>>> criterion for halting, is there any point in carrying on? >>> >>> I proved that the criteria for halting is objectively incorrect. >> >> It can't be incorrect. It's a definition. And it's based on the most >> natural notion: is the sequence of TM configurations finite or not. > > It is an objectively verifiable fact that the sequence of configurations > specified by the input to H(P,P) is not the same as the one specified by > P(P). > > When you have two definitions in computer science that directly > contradict each other what do you do? Toss out at least one of them. > >>> It requires a decider to base its decision on a non-input thus >>> directly contradicting the definition of a decider thus making the >>> requirement itself incorrect. >> >> No, halting has to be based on the input. > > The H(P,P)==0 is correct. > >> The input contains everything >> that specifies the sequence of configurations, > > It is an objectively verifiable fact that the sequence of configurations > specified by the input to H(P,P) is not the same as the one specified by > P(P). Then H is not implementing the Halting Mapping, so is NOT a Halt Decider. > >> yet no algorithm exists >> that can made the determination from the input alone. >> > > H(P,P)==0 and H1(P,P)==1 are both provably correct. > > Only if H and H1 are not Halt Deciders, which has been proven a long time ago.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.theory
csiph-web