On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting problem)
pathological relationship to each other:
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and
its input to
H and then specifically do the opposite of what H predicts P
will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does correctly
predict that its complete and correct x86 emulation of its input
would never reach the "ret" instruction of this input.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but it is obvious that Px should always halt if H is a valid halt decider that
always returns a decision to its caller (Px). Olcott's H does not
return a decision to its caller (Px) and is thus invalid.
/Flibble
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
For any program H that might determine if programs halt,
a "pathological"
program P, called with some input, can pass its own
source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does correctly
predict that its complete and correct x86 emulation of its input
would never reach the "ret" instruction of this input.
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push Px
[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to determine:
(a) Px is calling H with the same arguments that H was called with.
(b) No instructions in Px could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would
always halt; the infinite recursion is a manifestation of your
invalid simulation-based halting decider. There is no recursion in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating halt
decider even though I conclusively proved that it does correctly
determine the halt status of: (see my new paper)
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source
and its input to
H and then specifically do the opposite of what H predicts P
will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does correctly
predict that its complete and correct x86 emulation of its input
would never reach the "ret" instruction of this input.
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
Your false assumptions are directly contradicted by the semantics of
the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push Px
[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to determine:
(a) Px is calling H with the same arguments that H was called with.
(b) No instructions in Px could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would always
halt; the infinite recursion is a manifestation of your invalid simulation-based halting decider. There is no recursion in [Strachey
1965].
/Flibble
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
For any program H that might determine if programs halt,
a "pathological"
program P, called with some input, can pass its own
source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does correctly
predict that its complete and correct x86 emulation of its input
would never reach the "ret" instruction of this input.
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push Px
[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to determine:
(a) Px is calling H with the same arguments that H was called with.
(b) No instructions in Px could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would
always halt; the infinite recursion is a manifestation of your
invalid simulation-based halting decider. There is no recursion in
[Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating halt
decider even though I conclusively proved that it does correctly
determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the answer
wrong for Px() which is not a pathological input. Px() halts.
/Flibble
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
For any program H that might determine if programs
halt, a "pathological"
program P, called with some input, can pass its own
source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does
correctly predict that its complete and correct x86 emulation
of its input would never reach the "ret" instruction of this
input.
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt
but it is obvious that Px should always halt if H is a valid
halt decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push
Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push
Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly escape
this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would
always halt; the infinite recursion is a manifestation of your
invalid simulation-based halting decider. There is no recursion
in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating halt
decider even though I conclusively proved that it does correctly
determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the answer
wrong for Px() which is not a pathological input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its complete
and correct x86 emulation of its input would never reach the "ret"
instruction of this input because of the pathological relationship
between H and Px.
Wrong. Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite of
what H decides.
/Flibble
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
For any program H that might determine if programs
halt, a "pathological"
program P, called with some input, can pass its own
source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does
correctly predict that its complete and correct x86 emulation
of its input would never reach the "ret" instruction of this
input.
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt
but it is obvious that Px should always halt if H is a valid
halt decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push
Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push
Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly escape
this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would
always halt; the infinite recursion is a manifestation of your
invalid simulation-based halting decider. There is no recursion
in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating halt
decider even though I conclusively proved that it does correctly
determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the answer
wrong for Px() which is not a pathological input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its complete
and correct x86 emulation of its input would never reach the "ret" instruction of this input because of the pathological relationship
between H and Px.
On 7/2/2022 1:28 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts >>>>>>>> H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
For any program H that might determine if programs >>>>>>>> halt, a "pathological"
program P, called with some input, can pass its own >>>>>>>> source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does
correctly predict that its complete and correct x86 emulation >>>>>>>> of its input would never reach the "ret" instruction of this >>>>>>>> input.
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push
00000427 ---[000013f1][0010234f][00000427] e880f0ffff
call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt
but it is obvious that Px should always halt if H is a valid
halt decider that always returns a decision to its caller
(Px). Olcott's H does not return a decision to its caller
(Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push
Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push
Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly
escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would
always halt; the infinite recursion is a manifestation of your
invalid simulation-based halting decider. There is no recursion
in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating halt
decider even though I conclusively proved that it does correctly
determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the
answer wrong for Px() which is not a pathological input. Px()
halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its
complete and correct x86 emulation of its input would never reach
the "ret" instruction of this input because of the pathological
relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite of
what H decides.
/Flibble
Your lack of comprehension does not actually count as any rebuttal at[snip]
all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting problem) pathological relationship to each other:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the >>>>>>>>>>>> actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts >>>>>>>>>>>> H correctly determines that Infinite_Recursion() never >>>>>>>>>>>> halts H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting >>>>>>>>>>>> problem) pathological relationship to each other:
For any program H that might determine if
programs halt, a "pathological"
program P, called with some input, can pass its >>>>>>>>>>>> own source and its input to
H and then specifically do the opposite of what >>>>>>>>>>>> H predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does >>>>>>>>>>>> correctly predict that its complete and correct x86
emulation of its input would never reach the "ret"
instruction of this input.
*Halting problem proofs refuted on the basis of software >>>>>>>>>>>> engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add
esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000
push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>>>> call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add
esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not >>>>>>>>>>> halt but it is obvious that Px should always halt if H is a >>>>>>>>>>> valid halt decider that always returns a decision to its >>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its >>>>>>>>>>> caller (Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>> [000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08] >>>>>>>>>> [00001198][00112013][00001192] 50 push eax // >>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push >>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of Px (see above) >>>>>>>>>> to determine: (a) Px is calling H with the same arguments
that H was called with. (b) No instructions in Px could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of Px before its call >>>>>>>>>> to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would >>>>>>>>> always halt; the infinite recursion is a manifestation of your >>>>>>>>> invalid simulation-based halting decider. There is no
recursion in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating
halt decider even though I conclusively proved that it does
correctly determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the
answer wrong for Px() which is not a pathological input. Px()
halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its
complete and correct x86 emulation of its input would never reach
the "ret" instruction of this input because of the pathological
relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite
of what H decides.
/Flibble
Your lack of comprehension does not actually count as any rebuttal
at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the semantics of
the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push Px
[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to determine:
(a) Px is calling H with the same arguments that H was called with.
(b) No instructions in Px could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite of
what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the >>>>>>>>>> actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts >>>>>>>>>> H correctly determines that Infinite_Recursion() never
halts H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting >>>>>>>>>> problem) pathological relationship to each other:
For any program H that might determine if
programs halt, a "pathological"
program P, called with some input, can pass its >>>>>>>>>> own source and its input to
H and then specifically do the opposite of what >>>>>>>>>> H predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does
correctly predict that its complete and correct x86
emulation of its input would never reach the "ret"
instruction of this input.
*Halting problem proofs refuted on the basis of software >>>>>>>>>> engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add
esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000
push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>> call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add
esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not
halt but it is obvious that Px should always halt if H is a >>>>>>>>> valid halt decider that always returns a decision to its
caller (Px). Olcott's H does not return a decision to its
caller (Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>> [000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax //
push Px [00001199][00112013][00001192] 8b4d08 mov
ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push
ecx // push Px [0000119d][0011200b][000011a2]
e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of Px (see above)
to determine: (a) Px is calling H with the same arguments
that H was called with. (b) No instructions in Px could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of Px before its call
to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would >>>>>>> always halt; the infinite recursion is a manifestation of your >>>>>>> invalid simulation-based halting decider. There is no
recursion in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating
halt decider even though I conclusively proved that it does
correctly determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the
answer wrong for Px() which is not a pathological input. Px()
halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its
complete and correct x86 emulation of its input would never reach
the "ret" instruction of this input because of the pathological
relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite
of what H decides.
/Flibble
Your lack of comprehension does not actually count as any rebuttal
at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
Your false assumptions are directly contradicted by the semantics of
the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000011d2][00101f7f][00000000] 55 push ebp [000011d3][00101f7f][00000000] 8bec mov ebp,esp [000011d5][00101f7b][00001192] 6892110000 push 00001192 [000011da][00101f77][00001192] 6892110000 push 00001192 [000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp [00001193][00112017][0011201b] 8bec mov ebp,esp [00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08] [00001198][00112013][00001192] 50 push eax // push Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push ecx // push Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to determine:
(a) Px is calling H with the same arguments that H was called with.
(b) No instructions in Px could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08 [000011e7][00101f7b][00000000] 50 push eax [000011e8][00101f77][000004a3] 68a3040000 push 000004a3 [000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08 [000011f5][00101f7f][00000000] 33c0 xor eax,eax [000011f7][00101f83][00000018] 5d pop ebp [000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts >>>>>>>>>> H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting >>>>>>>>>> problem) pathological relationship to each other:
For any program H that might determine if programs >>>>>>>>>> halt, a "pathological"
program P, called with some input, can pass its own >>>>>>>>>> source and its input to
H and then specifically do the opposite of what H >>>>>>>>>> predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does
correctly predict that its complete and correct x86 emulation >>>>>>>>>> of its input would never reach the "ret" instruction of this >>>>>>>>>> input.
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push
00000427 ---[000013f1][0010234f][00000427] e880f0ffff
call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt >>>>>>>>> but it is obvious that Px should always halt if H is a valid >>>>>>>>> halt decider that always returns a decision to its caller
(Px). Olcott's H does not return a decision to its caller
(Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push >>>>>>>> Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push >>>>>>>> Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily >>>>>>>> examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly
escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() would
always halt; the infinite recursion is a manifestation of your
invalid simulation-based halting decider. There is no recursion >>>>>>> in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating halt
decider even though I conclusively proved that it does correctly
determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the
answer wrong for Px() which is not a pathological input. Px()
halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its
complete and correct x86 emulation of its input would never reach
the "ret" instruction of this input because of the pathological
relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite of
what H decides.
/Flibble
Your lack of comprehension does not actually count as any rebuttal at
all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting problem)
pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but it is obvious that Px should always halt if H is a valid halt decider that
always returns a decision to its caller (Px). Olcott's H does not
return a decision to its caller (Px) and is thus invalid.
/Flibble
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the >>>>>>>>>>>> actual execution of three fully operational examples. >>>>>>>>>>>>
H0 correctly determines that Infinite_Loop() never halts >>>>>>>>>>>> H correctly determines that Infinite_Recursion() never >>>>>>>>>>>> halts H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P)); >>>>>>>>>>>> }
As shown below the above P and H have the required
(halting problem) pathological relationship to each
other:
For any program H that might determine if >>>>>>>>>>>> programs halt, a "pathological"
program P, called with some input, can pass >>>>>>>>>>>> its own source and its input to
H and then specifically do the opposite of >>>>>>>>>>>> what H predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does >>>>>>>>>>>> correctly predict that its complete and correct x86
emulation of its input would never reach the "ret"
instruction of this input.
*Halting problem proofs refuted on the basis of software >>>>>>>>>>>> engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add
esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000
push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>>>> call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add
esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not >>>>>>>>>>> halt but it is obvious that Px should always halt if H is >>>>>>>>>>> a valid halt decider that always returns a decision to its >>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its >>>>>>>>>>> caller (Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly >>>>>>>>>> address address data code language >>>>>>>>>> ======== ======== ======== =========
============= [000011d2][00101f7f][00000000] 55
push ebp [000011d3][00101f7f][00000000] 8bec mov
ebp,esp [000011d5][00101f7b][00001192] 6892110000 push
00001192 [000011da][00101f77][00001192] 6892110000 push
00001192 [000011df][00101f73][000011e4] e88efdffff call
00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08] >>>>>>>>>> [00001198][00112013][00001192] 50 push eax // >>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push >>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can >>>>>>>>>> easily examine its stored execution_trace of Px (see above) >>>>>>>>>> to determine: (a) Px is calling H with the same arguments >>>>>>>>>> that H was called with. (b) No instructions in Px could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of Px before its call >>>>>>>>>> to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px()
would always halt; the infinite recursion is a
manifestation of your invalid simulation-based halting
decider. There is no recursion in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating >>>>>>>> halt decider even though I conclusively proved that it does
correctly determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the
answer wrong for Px() which is not a pathological input. Px()
halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its
complete and correct x86 emulation of its input would never
reach the "ret" instruction of this input because of the
pathological relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the
halting problem and [Strachey 1965] as it does not try to do
the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any
rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push Px
[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to determine:
(a) Px is calling H with the same arguments that H was called with.
(b) No instructions in Px could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite of
what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I posted
it again.
*This general principle refutes conventional halting problem proofs*
Every simulating halt decider that correctly simulates its input
until it correctly predicts that this simulated input would never
reach its final state, correctly rejects this input as non-halting.
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on the >>>>>>>>>>>>>> actual execution of three fully operational examples. >>>>>>>>>>>>>>
H0 correctly determines that Infinite_Loop() never halts >>>>>>>>>>>>>> H correctly determines that Infinite_Recursion() never >>>>>>>>>>>>>> halts H correctly determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P)); >>>>>>>>>>>>>> }
As shown below the above P and H have the required >>>>>>>>>>>>>> (halting problem) pathological relationship to each >>>>>>>>>>>>>> other:
For any program H that might determine if >>>>>>>>>>>>>> programs halt, a "pathological"
program P, called with some input, can pass >>>>>>>>>>>>>> its own source and its input to
H and then specifically do the opposite of >>>>>>>>>>>>>> what H predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does >>>>>>>>>>>>>> correctly predict that its complete and correct x86 >>>>>>>>>>>>>> emulation of its input would never reach the "ret" >>>>>>>>>>>>>> instruction of this input.
*Halting problem proofs refuted on the basis of software >>>>>>>>>>>>>> engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add >>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000 >>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>>>>>> call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add >>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not >>>>>>>>>>>>> halt but it is obvious that Px should always halt if H is >>>>>>>>>>>>> a valid halt decider that always returns a decision to its >>>>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its >>>>>>>>>>>>> caller (Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by the >>>>>>>>>>>> semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>> }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly >>>>>>>>>>>> address address data code language >>>>>>>>>>>> ======== ======== ======== =========
============= [000011d2][00101f7f][00000000] 55
push ebp [000011d3][00101f7f][00000000] 8bec mov >>>>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push >>>>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call >>>>>>>>>>>> 00000f72
H: Begin Simulation Execution Trace Stored at:11202b >>>>>>>>>>>> Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08] >>>>>>>>>>>> [00001198][00112013][00001192] 50 push eax // >>>>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push >>>>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely >>>>>>>>>>>> Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can >>>>>>>>>>>> easily examine its stored execution_trace of Px (see above) >>>>>>>>>>>> to determine: (a) Px is calling H with the same arguments >>>>>>>>>>>> that H was called with. (b) No instructions in Px could >>>>>>>>>>>> possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of Px before its call >>>>>>>>>>>> to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3 >>>>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2 >>>>>>>>>>>> Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() >>>>>>>>>>> would always halt; the infinite recursion is a
manifestation of your invalid simulation-based halting
decider. There is no recursion in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a simulating >>>>>>>>>> halt decider even though I conclusively proved that it does >>>>>>>>>> correctly determine the halt status of: (see my new paper)
No I am rejecting your simulating halt decider as it gets the >>>>>>>>> answer wrong for Px() which is not a pathological input. Px() >>>>>>>>> halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its
complete and correct x86 emulation of its input would never
reach the "ret" instruction of this input because of the
pathological relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the
halting problem and [Strachey 1965] as it does not try to do
the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any
rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push Px
[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call
H(Px,Px) H: Infinitely Recursive Simulation Detected Simulation
Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to determine:
(a) Px is calling H with the same arguments that H was called with.
(b) No instructions in Px could possibly escape this otherwise
infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite of
what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I posted
it again.
*This general principle refutes conventional halting problem proofs*
Every simulating halt decider that correctly simulates its input
until it correctly predicts that this simulated input would never
reach its final state, correctly rejects this input as non-halting.
Your H does not "correctly predict" that Px() does reach its final
state and so should accept the input as halting.
/Flibble
On Sun, 3 Jul 2022 09:57:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 9:27 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on >>>>>>>>>>>>>>>> the actual execution of three fully operational >>>>>>>>>>>>>>>> examples.
H0 correctly determines that Infinite_Loop() never >>>>>>>>>>>>>>>> halts H correctly determines that Infinite_Recursion() >>>>>>>>>>>>>>>> never halts H correctly determines that P() never halts >>>>>>>>>>>>>>>>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P)); >>>>>>>>>>>>>>>> }
As shown below the above P and H have the required >>>>>>>>>>>>>>>> (halting problem) pathological relationship to each >>>>>>>>>>>>>>>> other:
For any program H that might determine if >>>>>>>>>>>>>>>> programs halt, a "pathological"
program P, called with some input, can >>>>>>>>>>>>>>>> pass its own source and its input to
H and then specifically do the opposite of >>>>>>>>>>>>>>>> what H predicts P will do. No H
can exist that handles this case. >>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does >>>>>>>>>>>>>>>> correctly predict that its complete and correct x86 >>>>>>>>>>>>>>>> emulation of its input would never reach the "ret" >>>>>>>>>>>>>>>> instruction of this input.
*Halting problem proofs refuted on the basis of >>>>>>>>>>>>>>>> software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add >>>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000 >>>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427]
e880f0ffff call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add >>>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d >>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 >>>>>>>>>>>>>>> ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not >>>>>>>>>>>>>>> halt but it is obvious that Px should always halt if H >>>>>>>>>>>>>>> is a valid halt decider that always returns a decision >>>>>>>>>>>>>>> to its caller (Px). Olcott's H does not return a >>>>>>>>>>>>>>> decision to its caller (Px) and is thus invalid. >>>>>>>>>>>>>>>
/Flibble
Your false assumptions are directly contradicted by the >>>>>>>>>>>>>> semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/ >>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>>> }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly >>>>>>>>>>>>>> address address data code language >>>>>>>>>>>>>> ======== ======== ======== =========
============= [000011d2][00101f7f][00000000] 55
push ebp [000011d3][00101f7f][00000000] 8bec mov >>>>>>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push >>>>>>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call >>>>>>>>>>>>>> 00000f72
H: Begin Simulation Execution Trace Stored at:11202b >>>>>>>>>>>>>> Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp >>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp >>>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov
eax,[ebp+08] [00001198][00112013][00001192] 50
push eax // push Px [00001199][00112013][00001192] >>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx >>>>>>>>>>>>>> // push Px [0000119d][0011200b][000011a2] e8d0fdffff >>>>>>>>>>>>>> call 00000f72 // call H(Px,Px) H: Infinitely Recursive >>>>>>>>>>>>>> Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can >>>>>>>>>>>>>> easily examine its stored execution_trace of Px (see >>>>>>>>>>>>>> above) to determine: (a) Px is calling H with the same >>>>>>>>>>>>>> arguments that H was called with. (b) No instructions in >>>>>>>>>>>>>> Px could possibly escape this otherwise infinitely >>>>>>>>>>>>>> recursive emulation. (c) H aborts its emulation of Px >>>>>>>>>>>>>> before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax >>>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3 >>>>>>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2 >>>>>>>>>>>>>> Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() >>>>>>>>>>>>> would always halt; the infinite recursion is a
manifestation of your invalid simulation-based halting >>>>>>>>>>>>> decider. There is no recursion in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a
simulating halt decider even though I conclusively proved >>>>>>>>>>>> that it does correctly determine the halt status of: (see >>>>>>>>>>>> my new paper)
No I am rejecting your simulating halt decider as it gets >>>>>>>>>>> the answer wrong for Px() which is not a pathological
input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its >>>>>>>>>> complete and correct x86 emulation of its input would never >>>>>>>>>> reach the "ret" instruction of this input because of the
pathological relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the
halting problem and [Strachey 1965] as it does not try to do >>>>>>>>> the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any
rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt
but it is obvious that Px should always halt if H is a valid
halt decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push
Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push
Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly escape
this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite
of what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I posted
it again.
*This general principle refutes conventional halting problem
proofs* Every simulating halt decider that correctly simulates its
input until it correctly predicts that this simulated input would
never reach its final state, correctly rejects this input as
non-halting.
Your H does not "correctly predict" that Px() does reach its final
state and so should accept the input as halting.
/Flibble
(x86 Instruction Set Reference* https://c9x.me/x86/
The semantics of the x86 language conclusively proves that the above
code is correct. People that disagree with verified facts are either
incompetent or liars. Since you cannot even understand that the
return statement in Px is unreachable code, (to every simulating halt
decider H) you would be incompetent.
Not EVERY simulating halt decider, only YOURS gets the answer wrong.
Px() halts.
/Flibble
On 7/3/2022 9:27 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on >>>>>>>>>>>>>> the actual execution of three fully operational
examples.
H0 correctly determines that Infinite_Loop() never >>>>>>>>>>>>>> halts H correctly determines that Infinite_Recursion() >>>>>>>>>>>>>> never halts H correctly determines that P() never halts >>>>>>>>>>>>>>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P)); >>>>>>>>>>>>>> }
As shown below the above P and H have the required >>>>>>>>>>>>>> (halting problem) pathological relationship to each >>>>>>>>>>>>>> other:
For any program H that might determine if >>>>>>>>>>>>>> programs halt, a "pathological"
program P, called with some input, can >>>>>>>>>>>>>> pass its own source and its input to
H and then specifically do the opposite of >>>>>>>>>>>>>> what H predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
I really need software engineers to verify that H does >>>>>>>>>>>>>> correctly predict that its complete and correct x86 >>>>>>>>>>>>>> emulation of its input would never reach the "ret" >>>>>>>>>>>>>> instruction of this input.
*Halting problem proofs refuted on the basis of
software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add >>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000 >>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427]
e880f0ffff call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add >>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not >>>>>>>>>>>>> halt but it is obvious that Px should always halt if H >>>>>>>>>>>>> is a valid halt decider that always returns a decision >>>>>>>>>>>>> to its caller (Px). Olcott's H does not return a
decision to its caller (Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by the >>>>>>>>>>>> semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/ >>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>>> }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly >>>>>>>>>>>> address address data code language >>>>>>>>>>>> ======== ======== ======== =========
============= [000011d2][00101f7f][00000000] 55
push ebp [000011d3][00101f7f][00000000] 8bec mov >>>>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push >>>>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call >>>>>>>>>>>> 00000f72
H: Begin Simulation Execution Trace Stored at:11202b >>>>>>>>>>>> Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp >>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov
eax,[ebp+08] [00001198][00112013][00001192] 50
push eax // push Px [00001199][00112013][00001192] >>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx
// push Px [0000119d][0011200b][000011a2] e8d0fdffff >>>>>>>>>>>> call 00000f72 // call H(Px,Px) H: Infinitely Recursive >>>>>>>>>>>> Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can >>>>>>>>>>>> easily examine its stored execution_trace of Px (see >>>>>>>>>>>> above) to determine: (a) Px is calling H with the same >>>>>>>>>>>> arguments that H was called with. (b) No instructions in >>>>>>>>>>>> Px could possibly escape this otherwise infinitely
recursive emulation. (c) H aborts its emulation of Px >>>>>>>>>>>> before its call to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3 >>>>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2 >>>>>>>>>>>> Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax >>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() >>>>>>>>>>> would always halt; the infinite recursion is a
manifestation of your invalid simulation-based halting >>>>>>>>>>> decider. There is no recursion in [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a
simulating halt decider even though I conclusively proved >>>>>>>>>> that it does correctly determine the halt status of: (see >>>>>>>>>> my new paper)
No I am rejecting your simulating halt decider as it gets
the answer wrong for Px() which is not a pathological
input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its
complete and correct x86 emulation of its input would never
reach the "ret" instruction of this input because of the
pathological relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the
halting problem and [Strachey 1965] as it does not try to do
the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any
rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt
but it is obvious that Px should always halt if H is a valid
halt decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the semantics
of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push
Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push
Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly escape
this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the opposite
of what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I posted
it again.
*This general principle refutes conventional halting problem
proofs* Every simulating halt decider that correctly simulates its
input until it correctly predicts that this simulated input would
never reach its final state, correctly rejects this input as
non-halting.
Your H does not "correctly predict" that Px() does reach its final
state and so should accept the input as halting.
/Flibble
(x86 Instruction Set Reference* https://c9x.me/x86/
The semantics of the x86 language conclusively proves that the above
code is correct. People that disagree with verified facts are either incompetent or liars. Since you cannot even understand that the
return statement in Px is unreachable code, (to every simulating halt
decider H) you would be incompetent.
On 7/3/2022 10:21 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 09:57:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 9:27 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on >>>>>>>>>>>>>>>> the actual execution of three fully operational >>>>>>>>>>>>>>>> examples.
H0 correctly determines that Infinite_Loop() never >>>>>>>>>>>>>>>> halts H correctly determines that
Infinite_Recursion() never halts H correctly >>>>>>>>>>>>>>>> determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, >>>>>>>>>>>>>>>> (u32)P)); }
As shown below the above P and H have the required >>>>>>>>>>>>>>>> (halting problem) pathological relationship to each >>>>>>>>>>>>>>>> other:
For any program H that might determine >>>>>>>>>>>>>>>> if programs halt, a "pathological"
program P, called with some input, can >>>>>>>>>>>>>>>> pass its own source and its input to
H and then specifically do the >>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H
can exist that handles this case. >>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem >>>>>>>>>>>>>>>>
I really need software engineers to verify that H >>>>>>>>>>>>>>>> does correctly predict that its complete and correct >>>>>>>>>>>>>>>> x86 emulation of its input would never reach the >>>>>>>>>>>>>>>> "ret" instruction of this input.
*Halting problem proofs refuted on the basis of >>>>>>>>>>>>>>>> software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>> (u32)Px)); }
...[000013e8][00102357][00000000] 83c408 add >>>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000 >>>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] >>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add >>>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0 >>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d >>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 >>>>>>>>>>>>>>> ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does >>>>>>>>>>>>>>> not halt but it is obvious that Px should always halt >>>>>>>>>>>>>>> if H is a valid halt decider that always returns a >>>>>>>>>>>>>>> decision to its caller (Px). Olcott's H does not >>>>>>>>>>>>>>> return a decision to its caller (Px) and is thus >>>>>>>>>>>>>>> invalid.
/Flibble
Your false assumptions are directly contradicted by the >>>>>>>>>>>>>> semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/ >>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px,
(u32)Px)); }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine
assembly address address data code
language ======== ======== ======== ========= >>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55
push ebp [000011d3][00101f7f][00000000] 8bec mov >>>>>>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push >>>>>>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call >>>>>>>>>>>>>> 00000f72
H: Begin Simulation Execution Trace Stored at:11202b >>>>>>>>>>>>>> Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp >>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp >>>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov
eax,[ebp+08] [00001198][00112013][00001192] 50
push eax // push Px [00001199][00112013][00001192] >>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx >>>>>>>>>>>>>> // push Px [0000119d][0011200b][000011a2] e8d0fdffff >>>>>>>>>>>>>> call 00000f72 // call H(Px,Px) H: Infinitely Recursive >>>>>>>>>>>>>> Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it >>>>>>>>>>>>>> can easily examine its stored execution_trace of Px >>>>>>>>>>>>>> (see above) to determine: (a) Px is calling H with the >>>>>>>>>>>>>> same arguments that H was called with. (b) No
instructions in Px could possibly escape this
otherwise infinitely recursive emulation. (c) H aborts >>>>>>>>>>>>>> its emulation of Px before its call to H is emulated. >>>>>>>>>>>>>>
[000011e4][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax >>>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3 >>>>>>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2 >>>>>>>>>>>>>> Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp >>>>>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
If H wasn't a simulation-based halting decider then Px() >>>>>>>>>>>>> would always halt; the infinite recursion is a
manifestation of your invalid simulation-based halting >>>>>>>>>>>>> decider. There is no recursion in [Strachey 1965]. >>>>>>>>>>>>>
/Flibble
In other words you are rejecting the concept of a
simulating halt decider even though I conclusively proved >>>>>>>>>>>> that it does correctly determine the halt status of: (see >>>>>>>>>>>> my new paper)
No I am rejecting your simulating halt decider as it gets >>>>>>>>>>> the answer wrong for Px() which is not a pathological
input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its >>>>>>>>>> complete and correct x86 emulation of its input would never >>>>>>>>>> reach the "ret" instruction of this input because of the >>>>>>>>>> pathological relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the
halting problem and [Strachey 1965] as it does not try to do >>>>>>>>> the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any
rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting
problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push
00000427 ---[000013f1][0010234f][00000427] e880f0ffff
call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt
but it is obvious that Px should always halt if H is a valid
halt decider that always returns a decision to its caller
(Px). Olcott's H does not return a decision to its caller
(Px) and is thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push
Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push
Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily
examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly
escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the
opposite of what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I
posted it again.
*This general principle refutes conventional halting problem
proofs* Every simulating halt decider that correctly simulates
its input until it correctly predicts that this simulated input
would never reach its final state, correctly rejects this input
as non-halting.
Your H does not "correctly predict" that Px() does reach its final
state and so should accept the input as halting.
/Flibble
(x86 Instruction Set Reference* https://c9x.me/x86/
The semantics of the x86 language conclusively proves that the
above code is correct. People that disagree with verified facts
are either incompetent or liars. Since you cannot even understand
that the return statement in Px is unreachable code, (to every
simulating halt decider H) you would be incompetent.
Not EVERY simulating halt decider, only YOURS gets the answer wrong.
Px() halts.
/Flibble
Since you cannot even understand that the return statement in Px is unreachable code, (to *every simulating halt* decider H) you would be incompetent.
On Sun, 3 Jul 2022 10:30:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 10:21 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 09:57:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 9:27 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:If H wasn't a simulation-based halting decider then Px() >>>>>>>>>>>>>>> would always halt; the infinite recursion is a
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses on >>>>>>>>>>>>>>>>>> the actual execution of three fully operational >>>>>>>>>>>>>>>>>> examples.
H0 correctly determines that Infinite_Loop() never >>>>>>>>>>>>>>>>>> halts H correctly determines that
Infinite_Recursion() never halts H correctly >>>>>>>>>>>>>>>>>> determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, >>>>>>>>>>>>>>>>>> (u32)P)); }
As shown below the above P and H have the required >>>>>>>>>>>>>>>>>> (halting problem) pathological relationship to each >>>>>>>>>>>>>>>>>> other:
For any program H that might determine >>>>>>>>>>>>>>>>>> if programs halt, a "pathological"
program P, called with some input, can >>>>>>>>>>>>>>>>>> pass its own source and its input to
H and then specifically do the >>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H >>>>>>>>>>>>>>>>>> can exist that handles this case. >>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem >>>>>>>>>>>>>>>>>>
I really need software engineers to verify that H >>>>>>>>>>>>>>>>>> does correctly predict that its complete and correct >>>>>>>>>>>>>>>>>> x86 emulation of its input would never reach the >>>>>>>>>>>>>>>>>> "ret" instruction of this input.
*Halting problem proofs refuted on the basis of >>>>>>>>>>>>>>>>>> software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>>> (u32)Px)); }
...[000013e8][00102357][00000000] 83c408 add >>>>>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50 >>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] 6827040000 >>>>>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427] >>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add >>>>>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0 >>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d >>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 >>>>>>>>>>>>>>>>> ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does >>>>>>>>>>>>>>>>> not halt but it is obvious that Px should always halt >>>>>>>>>>>>>>>>> if H is a valid halt decider that always returns a >>>>>>>>>>>>>>>>> decision to its caller (Px). Olcott's H does not >>>>>>>>>>>>>>>>> return a decision to its caller (Px) and is thus >>>>>>>>>>>>>>>>> invalid.
/Flibble
Your false assumptions are directly contradicted by the >>>>>>>>>>>>>>>> semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/ >>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>> (u32)Px)); }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine >>>>>>>>>>>>>>>> assembly address address data code
language ======== ======== ======== ========= >>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55 >>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec mov >>>>>>>>>>>>>>>> ebp,esp [000011d5][00101f7b][00001192] 6892110000 push >>>>>>>>>>>>>>>> 00001192 [000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff call >>>>>>>>>>>>>>>> 00000f72
H: Begin Simulation Execution Trace Stored at:11202b >>>>>>>>>>>>>>>> Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp >>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp >>>>>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov
eax,[ebp+08] [00001198][00112013][00001192] 50 >>>>>>>>>>>>>>>> push eax // push Px [00001199][00112013][00001192] >>>>>>>>>>>>>>>> 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx >>>>>>>>>>>>>>>> // push Px [0000119d][0011200b][000011a2] e8d0fdffff >>>>>>>>>>>>>>>> call 00000f72 // call H(Px,Px) H: Infinitely Recursive >>>>>>>>>>>>>>>> Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it >>>>>>>>>>>>>>>> can easily examine its stored execution_trace of Px >>>>>>>>>>>>>>>> (see above) to determine: (a) Px is calling H with the >>>>>>>>>>>>>>>> same arguments that H was called with. (b) No
instructions in Px could possibly escape this
otherwise infinitely recursive emulation. (c) H aborts >>>>>>>>>>>>>>>> its emulation of Px before its call to H is emulated. >>>>>>>>>>>>>>>>
[000011e4][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax >>>>>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push 000004a3 >>>>>>>>>>>>>>>> [000011ed][00101f77][000004a3] e800f3ffff call 000004f2 >>>>>>>>>>>>>>>> Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp >>>>>>>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages >>>>>>>>>>>>>>>
manifestation of your invalid simulation-based halting >>>>>>>>>>>>>>> decider. There is no recursion in [Strachey 1965]. >>>>>>>>>>>>>>>
/Flibble
In other words you are rejecting the concept of a
simulating halt decider even though I conclusively proved >>>>>>>>>>>>>> that it does correctly determine the halt status of: (see >>>>>>>>>>>>>> my new paper)
No I am rejecting your simulating halt decider as it gets >>>>>>>>>>>>> the answer wrong for Px() which is not a pathological >>>>>>>>>>>>> input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that its >>>>>>>>>>>> complete and correct x86 emulation of its input would never >>>>>>>>>>>> reach the "ret" instruction of this input because of the >>>>>>>>>>>> pathological relationship between H and Px.
Wrong. Px() is not a pathological input as defined by the >>>>>>>>>>> halting problem and [Strachey 1965] as it does not try to do >>>>>>>>>>> the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any
rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting >>>>>>>>>> problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>>>>> ...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push
00000427 ---[000013f1][0010234f][00000427] e880f0ffff
call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt >>>>>>>>> but it is obvious that Px should always halt if H is a valid >>>>>>>>> halt decider that always returns a decision to its caller
(Px). Olcott's H does not return a decision to its caller
(Px) and is thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax // push >>>>>>>> Px [00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]
[0000119c][0011200f][00001192] 51 push ecx // push >>>>>>>> Px [0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 //
call H(Px,Px) H: Infinitely Recursive Simulation Detected
Simulation Stopped
H knows its own machine address and on this basis it can easily >>>>>>>> examine its stored execution_trace of Px (see above) to
determine: (a) Px is calling H with the same arguments that H
was called with. (b) No instructions in Px could possibly
escape this otherwise infinitely recursive emulation.
(c) H aborts its emulation of Px before its call to H is
emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the
opposite of what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I
posted it again.
*This general principle refutes conventional halting problem
proofs* Every simulating halt decider that correctly simulates
its input until it correctly predicts that this simulated input
would never reach its final state, correctly rejects this input
as non-halting.
Your H does not "correctly predict" that Px() does reach its final
state and so should accept the input as halting.
/Flibble
(x86 Instruction Set Reference* https://c9x.me/x86/
The semantics of the x86 language conclusively proves that the
above code is correct. People that disagree with verified facts
are either incompetent or liars. Since you cannot even understand
that the return statement in Px is unreachable code, (to every
simulating halt decider H) you would be incompetent.
Not EVERY simulating halt decider, only YOURS gets the answer wrong.
Px() halts.
/Flibble
Since you cannot even understand that the return statement in Px is
unreachable code, (to *every simulating halt* decider H) you would be
incompetent.
Not at all. If I was to design a simulating halt decider then rather
than aborting the simulation at the point where P()/Px() calls H I
would instead fork the simulation, returning 0 to one branch (the
non-halting branch) and 1 to the other branch (the halting branch) and
then continue to simulate both branches in parallel thereby getting rid
of the "infinite recursion".
/Flibble
On 7/3/2022 10:45 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 10:30:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 10:21 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 09:57:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 9:27 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:If H wasn't a simulation-based halting decider then >>>>>>>>>>>>>>> Px() would always halt; the infinite recursion is a >>>>>>>>>>>>>>> manifestation of your invalid simulation-based halting >>>>>>>>>>>>>>> decider. There is no recursion in [Strachey 1965]. >>>>>>>>>>>>>>>
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses >>>>>>>>>>>>>>>>>> on the actual execution of three fully operational >>>>>>>>>>>>>>>>>> examples.
H0 correctly determines that Infinite_Loop() never >>>>>>>>>>>>>>>>>> halts H correctly determines that
Infinite_Recursion() never halts H correctly >>>>>>>>>>>>>>>>>> determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, >>>>>>>>>>>>>>>>>> (u32)P)); }
As shown below the above P and H have the required >>>>>>>>>>>>>>>>>> (halting problem) pathological relationship to each >>>>>>>>>>>>>>>>>> other:
For any program H that might >>>>>>>>>>>>>>>>>> determine if programs halt, a "pathological" >>>>>>>>>>>>>>>>>> program P, called with some input, >>>>>>>>>>>>>>>>>> can pass its own source and its input to >>>>>>>>>>>>>>>>>> H and then specifically do the >>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H >>>>>>>>>>>>>>>>>> can exist that handles this case. >>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem >>>>>>>>>>>>>>>>>>
I really need software engineers to verify that H >>>>>>>>>>>>>>>>>> does correctly predict that its complete and >>>>>>>>>>>>>>>>>> correct x86 emulation of its input would never >>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input. >>>>>>>>>>>>>>>>>>
*Halting problem proofs refuted on the basis of >>>>>>>>>>>>>>>>>> software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>>> (u32)Px)); }
...[000013e8][00102357][00000000] 83c408
add esp,+08 ...[000013eb][00102353][00000000] 50 >>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] >>>>>>>>>>>>>>>>> 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call >>>>>>>>>>>>>>>>> 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408
add esp,+08 ...[000013f9][00102357][00000000] 33c0 >>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d >>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does >>>>>>>>>>>>>>>>> not halt but it is obvious that Px should always >>>>>>>>>>>>>>>>> halt if H is a valid halt decider that always >>>>>>>>>>>>>>>>> returns a decision to its caller (Px). Olcott's H >>>>>>>>>>>>>>>>> does not return a decision to its caller (Px) and >>>>>>>>>>>>>>>>> is thus invalid.
/Flibble
Your false assumptions are directly contradicted by >>>>>>>>>>>>>>>> the semantics of the x86 programming language. >>>>>>>>>>>>>>>>
*x86 Instruction Set Reference* https://c9x.me/x86/ >>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>> (u32)Px)); }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine >>>>>>>>>>>>>>>> assembly address address data code
language ======== ======== ======== ========= >>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55 >>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec >>>>>>>>>>>>>>>> mov ebp,esp [000011d5][00101f7b][00001192]
6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff >>>>>>>>>>>>>>>> call 00000f72
H: Begin Simulation Execution Trace Stored >>>>>>>>>>>>>>>> at:11202b Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp >>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp >>>>>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov >>>>>>>>>>>>>>>> eax,[ebp+08] [00001198][00112013][00001192] 50 >>>>>>>>>>>>>>>> push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov >>>>>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51 >>>>>>>>>>>>>>>> push ecx // push Px [0000119d][0011200b][000011a2] >>>>>>>>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H: >>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation >>>>>>>>>>>>>>>> Stopped
H knows its own machine address and on this basis it >>>>>>>>>>>>>>>> can easily examine its stored execution_trace of Px >>>>>>>>>>>>>>>> (see above) to determine: (a) Px is calling H with >>>>>>>>>>>>>>>> the same arguments that H was called with. (b) No >>>>>>>>>>>>>>>> instructions in Px could possibly escape this >>>>>>>>>>>>>>>> otherwise infinitely recursive emulation. (c) H >>>>>>>>>>>>>>>> aborts its emulation of Px before its call to H is >>>>>>>>>>>>>>>> emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax >>>>>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push >>>>>>>>>>>>>>>> 000004a3 [000011ed][00101f77][000004a3] e800f3ffff >>>>>>>>>>>>>>>> call 000004f2 Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp >>>>>>>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret >>>>>>>>>>>>>>>> Number of Instructions Executed(880) == 13 Pages >>>>>>>>>>>>>>>
/Flibble
In other words you are rejecting the concept of a >>>>>>>>>>>>>> simulating halt decider even though I conclusively >>>>>>>>>>>>>> proved that it does correctly determine the halt >>>>>>>>>>>>>> status of: (see my new paper)
No I am rejecting your simulating halt decider as it >>>>>>>>>>>>> gets the answer wrong for Px() which is not a
pathological input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that >>>>>>>>>>>> its complete and correct x86 emulation of its input
would never reach the "ret" instruction of this input >>>>>>>>>>>> because of the pathological relationship between H and >>>>>>>>>>>> Px.
Wrong. Px() is not a pathological input as defined by the >>>>>>>>>>> halting problem and [Strachey 1965] as it does not try to >>>>>>>>>>> do the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any >>>>>>>>>> rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting >>>>>>>>>> problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add
esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000
push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>> call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add
esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not
halt but it is obvious that Px should always halt if H is a >>>>>>>>> valid halt decider that always returns a decision to its
caller (Px). Olcott's H does not return a decision to its
caller (Px) and is thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>> [000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]
[00001198][00112013][00001192] 50 push eax //
push Px [00001199][00112013][00001192] 8b4d08 mov
ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push
ecx // push Px [0000119d][0011200b][000011a2]
e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of Px (see above)
to determine: (a) Px is calling H with the same arguments
that H was called with. (b) No instructions in Px could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of Px before its call
to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well.
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the
opposite of what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I
posted it again.
*This general principle refutes conventional halting problem
proofs* Every simulating halt decider that correctly simulates
its input until it correctly predicts that this simulated input
would never reach its final state, correctly rejects this input
as non-halting.
Your H does not "correctly predict" that Px() does reach its
final state and so should accept the input as halting.
/Flibble
(x86 Instruction Set Reference* https://c9x.me/x86/
The semantics of the x86 language conclusively proves that the
above code is correct. People that disagree with verified facts
are either incompetent or liars. Since you cannot even understand
that the return statement in Px is unreachable code, (to every
simulating halt decider H) you would be incompetent.
Not EVERY simulating halt decider, only YOURS gets the answer
wrong. Px() halts.
/Flibble
Since you cannot even understand that the return statement in Px is
unreachable code, (to *every simulating halt* decider H) you would
be incompetent.
Not at all. If I was to design a simulating halt decider then rather
than aborting the simulation at the point where P()/Px() calls H I
would instead fork the simulation, returning 0 to one branch (the non-halting branch) and 1 to the other branch (the halting branch)
and then continue to simulate both branches in parallel thereby
getting rid of the "infinite recursion".
/Flibble
Yet that is *not* what the actual code specifies. Every function
called in infinite recursion is not allowed to return to its caller.
On 7/3/2022 10:51 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 10:48:18 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 10:45 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 10:30:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 10:21 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 09:57:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 9:27 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>> On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper >>>>>>>>>>>>>>>>>>>> focuses on the actual execution of three fully >>>>>>>>>>>>>>>>>>>> operational examples.
H0 correctly determines that Infinite_Loop() >>>>>>>>>>>>>>>>>>>> never halts H correctly determines that >>>>>>>>>>>>>>>>>>>> Infinite_Recursion() never halts H correctly >>>>>>>>>>>>>>>>>>>> determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, >>>>>>>>>>>>>>>>>>>> (u32)P)); }
As shown below the above P and H have the >>>>>>>>>>>>>>>>>>>> required (halting problem) pathological >>>>>>>>>>>>>>>>>>>> relationship to each other:
For any program H that might >>>>>>>>>>>>>>>>>>>> determine if programs halt, a "pathological" >>>>>>>>>>>>>>>>>>>> program P, called with some >>>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to >>>>>>>>>>>>>>>>>>>> H and then specifically do the >>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H >>>>>>>>>>>>>>>>>>>> can exist that handles this case. >>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem >>>>>>>>>>>>>>>>>>>>
I really need software engineers to verify that H >>>>>>>>>>>>>>>>>>>> does correctly predict that its complete and >>>>>>>>>>>>>>>>>>>> correct x86 emulation of its input would never >>>>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input. >>>>>>>>>>>>>>>>>>>>
*Halting problem proofs refuted on the basis of >>>>>>>>>>>>>>>>>>>> software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>>>>> (u32)Px)); }
...[000013e8][00102357][00000000] 83c408 >>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013eb][00102353][00000000] 50 >>>>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] >>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call >>>>>>>>>>>>>>>>>>> 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 >>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013f9][00102357][00000000] 33c0 >>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d >>>>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120) >>>>>>>>>>>>>>>>>>>
As can be seen above Olcott's H decides that Px >>>>>>>>>>>>>>>>>>> does not halt but it is obvious that Px should >>>>>>>>>>>>>>>>>>> always halt if H is a valid halt decider that >>>>>>>>>>>>>>>>>>> always returns a decision to its caller (Px). >>>>>>>>>>>>>>>>>>> Olcott's H does not return a decision to its >>>>>>>>>>>>>>>>>>> caller (Px) and is thus invalid.
/Flibble
Your false assumptions are directly contradicted by >>>>>>>>>>>>>>>>>> the semantics of the x86 programming language. >>>>>>>>>>>>>>>>>>
*x86 Instruction Set Reference*
https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>>>> (u32)Px)); }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>> [00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>> [0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72 >>>>>>>>>>>>>>>>>> [000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192 >>>>>>>>>>>>>>>>>> [000011da](05) 6892110000 push 00001192 >>>>>>>>>>>>>>>>>> [000011df](05) e88efdffff call 00000f72 >>>>>>>>>>>>>>>>>> [000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3 >>>>>>>>>>>>>>>>>> [000011ed](05) e800f3ffff call 000004f2 >>>>>>>>>>>>>>>>>> [000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine >>>>>>>>>>>>>>>>>> assembly address address data code >>>>>>>>>>>>>>>>>> language ======== ======== ======== ========= >>>>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55 >>>>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec >>>>>>>>>>>>>>>>>> mov ebp,esp [000011d5][00101f7b][00001192] >>>>>>>>>>>>>>>>>> 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff >>>>>>>>>>>>>>>>>> call 00000f72
H: Begin Simulation Execution Trace Stored >>>>>>>>>>>>>>>>>> at:11202b Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp >>>>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov >>>>>>>>>>>>>>>>>> ebp,esp [00001195][00112017][0011201b] 8b4508 >>>>>>>>>>>>>>>>>> mov eax,[ebp+08] [00001198][00112013][00001192] 50 >>>>>>>>>>>>>>>>>> push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov >>>>>>>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51 >>>>>>>>>>>>>>>>>> push ecx // push Px
[0000119d][0011200b][000011a2] e8d0fdffff call >>>>>>>>>>>>>>>>>> 00000f72 // call H(Px,Px) H: Infinitely Recursive >>>>>>>>>>>>>>>>>> Simulation Detected Simulation Stopped
H knows its own machine address and on this basis >>>>>>>>>>>>>>>>>> it can easily examine its stored execution_trace >>>>>>>>>>>>>>>>>> of Px (see above) to determine: (a) Px is calling >>>>>>>>>>>>>>>>>> H with the same arguments that H was called with. >>>>>>>>>>>>>>>>>> (b) No instructions in Px could possibly escape >>>>>>>>>>>>>>>>>> this otherwise infinitely recursive emulation. (c) >>>>>>>>>>>>>>>>>> H aborts its emulation of Px before its call to H >>>>>>>>>>>>>>>>>> is emulated.
[000011e4][00101f7f][00000000] 83c408 add >>>>>>>>>>>>>>>>>> esp,+08 [000011e7][00101f7b][00000000] 50 >>>>>>>>>>>>>>>>>> push eax [000011e8][00101f77][000004a3] 68a3040000 >>>>>>>>>>>>>>>>>> push 000004a3 [000011ed][00101f77][000004a3] >>>>>>>>>>>>>>>>>> e800f3ffff call 000004f2 Input_Halts = 0 >>>>>>>>>>>>>>>>>> [000011f2][00101f7f][00000000] 83c408 add >>>>>>>>>>>>>>>>>> esp,+08 [000011f5][00101f7f][00000000] 33c0 >>>>>>>>>>>>>>>>>> xor eax,eax [000011f7][00101f83][00000018] 5d >>>>>>>>>>>>>>>>>> pop ebp [000011f8][00101f87][00000000] c3 >>>>>>>>>>>>>>>>>> ret Number of Instructions Executed(880) == 13 >>>>>>>>>>>>>>>>>> Pages
If H wasn't a simulation-based halting decider then >>>>>>>>>>>>>>>>> Px() would always halt; the infinite recursion is a >>>>>>>>>>>>>>>>> manifestation of your invalid simulation-based >>>>>>>>>>>>>>>>> halting decider. There is no recursion in >>>>>>>>>>>>>>>>> [Strachey 1965].
/Flibble
In other words you are rejecting the concept of a >>>>>>>>>>>>>>>> simulating halt decider even though I conclusively >>>>>>>>>>>>>>>> proved that it does correctly determine the halt >>>>>>>>>>>>>>>> status of: (see my new paper)
No I am rejecting your simulating halt decider as it >>>>>>>>>>>>>>> gets the answer wrong for Px() which is not a
pathological input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that >>>>>>>>>>>>>> its complete and correct x86 emulation of its input >>>>>>>>>>>>>> would never reach the "ret" instruction of this input >>>>>>>>>>>>>> because of the pathological relationship between H and >>>>>>>>>>>>>> Px.
Wrong. Px() is not a pathological input as defined by >>>>>>>>>>>>> the halting problem and [Strachey 1965] as it does not >>>>>>>>>>>>> try to do the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any >>>>>>>>>>>> rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P)); >>>>>>>>>>>> }
As shown below the above P and H have the required
(halting problem) pathological relationship to each
other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px)); >>>>>>>>>>> }
...[000013e8][00102357][00000000] 83c408 add
esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000
push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>>>> call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add
esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not >>>>>>>>>>> halt but it is obvious that Px should always halt if H is >>>>>>>>>>> a valid halt decider that always returns a decision to its >>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its >>>>>>>>>>> caller (Px) and is thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly >>>>>>>>>> address address data code language >>>>>>>>>> ======== ======== ======== =========
============= [000011d2][00101f7f][00000000] 55
push ebp [000011d3][00101f7f][00000000] 8bec mov
ebp,esp [000011d5][00101f7b][00001192] 6892110000 push
00001192 [000011da][00101f77][00001192] 6892110000 push
00001192 [000011df][00101f73][000011e4] e88efdffff call
00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08] >>>>>>>>>> [00001198][00112013][00001192] 50 push eax // >>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push >>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can >>>>>>>>>> easily examine its stored execution_trace of Px (see above) >>>>>>>>>> to determine: (a) Px is calling H with the same arguments >>>>>>>>>> that H was called with. (b) No instructions in Px could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of Px before its call >>>>>>>>>> to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well. >>>>>>>>>
Px() is not a pathological input as defined by the halting >>>>>>>>> problem and [Strachey 1965] as it does not try to do the
opposite of what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I >>>>>>>> posted it again.
*This general principle refutes conventional halting problem >>>>>>>> proofs* Every simulating halt decider that correctly
simulates its input until it correctly predicts that this
simulated input would never reach its final state, correctly >>>>>>>> rejects this input as non-halting.
Your H does not "correctly predict" that Px() does reach its
final state and so should accept the input as halting.
/Flibble
(x86 Instruction Set Reference* https://c9x.me/x86/
The semantics of the x86 language conclusively proves that the
above code is correct. People that disagree with verified facts
are either incompetent or liars. Since you cannot even
understand that the return statement in Px is unreachable
code, (to every simulating halt decider H) you would be
incompetent.
Not EVERY simulating halt decider, only YOURS gets the answer
wrong. Px() halts.
/Flibble
Since you cannot even understand that the return statement in Px
is unreachable code, (to *every simulating halt* decider H) you
would be incompetent.
Not at all. If I was to design a simulating halt decider then
rather than aborting the simulation at the point where P()/Px()
calls H I would instead fork the simulation, returning 0 to one
branch (the non-halting branch) and 1 to the other branch (the
halting branch) and then continue to simulate both branches in
parallel thereby getting rid of the "infinite recursion".
/Flibble
Yet that is *not* what the actual code specifies. Every function
called in infinite recursion is not allowed to return to its
caller.
The infinite recursion is an artifact of how YOU are trying to solve
the problem; there is no infinite recursion in [Strachey 1965] and associated proofs.
/Flibble
The halting problem expressly allows every algorithm in the universe
as long as it correctly predicts the behavior of the input.
On Sun, 3 Jul 2022 10:48:18 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 10:45 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 10:30:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 10:21 AM, Mr Flibble wrote:
On Sun, 3 Jul 2022 09:57:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/3/2022 9:27 AM, Mr Flibble wrote:
On Sat, 2 Jul 2022 17:13:01 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 5:05 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 16:26:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:44 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 13:41:14 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 1:28 PM, Mr Flibble wrote:[snip]
On Sat, 2 Jul 2022 12:30:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:26 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 12:15:58 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 12:10 PM, Mr Flibble wrote:
On Sat, 2 Jul 2022 11:42:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/2/2022 11:26 AM, Mr Flibble wrote:If H wasn't a simulation-based halting decider then >>>>>>>>>>>>>>>>> Px() would always halt; the infinite recursion is a >>>>>>>>>>>>>>>>> manifestation of your invalid simulation-based halting >>>>>>>>>>>>>>>>> decider. There is no recursion in [Strachey 1965]. >>>>>>>>>>>>>>>>>
On Sat, 2 Jul 2022 10:34:34 -0500
olcott <NoOne@NoWhere.com> wrote:
This much more concise version of my paper focuses >>>>>>>>>>>>>>>>>>>> on the actual execution of three fully operational >>>>>>>>>>>>>>>>>>>> examples.
H0 correctly determines that Infinite_Loop() never >>>>>>>>>>>>>>>>>>>> halts H correctly determines that
Infinite_Recursion() never halts H correctly >>>>>>>>>>>>>>>>>>>> determines that P() never halts
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, >>>>>>>>>>>>>>>>>>>> (u32)P)); }
As shown below the above P and H have the required >>>>>>>>>>>>>>>>>>>> (halting problem) pathological relationship to each >>>>>>>>>>>>>>>>>>>> other:
For any program H that might >>>>>>>>>>>>>>>>>>>> determine if programs halt, a "pathological" >>>>>>>>>>>>>>>>>>>> program P, called with some input, >>>>>>>>>>>>>>>>>>>> can pass its own source and its input to >>>>>>>>>>>>>>>>>>>> H and then specifically do the >>>>>>>>>>>>>>>>>>>> opposite of what H predicts P will do. No H >>>>>>>>>>>>>>>>>>>> can exist that handles this case. >>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem >>>>>>>>>>>>>>>>>>>>
I really need software engineers to verify that H >>>>>>>>>>>>>>>>>>>> does correctly predict that its complete and >>>>>>>>>>>>>>>>>>>> correct x86 emulation of its input would never >>>>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input. >>>>>>>>>>>>>>>>>>>>
*Halting problem proofs refuted on the basis of >>>>>>>>>>>>>>>>>>>> software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>>>>> (u32)Px)); }
...[000013e8][00102357][00000000] 83c408 >>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013eb][00102353][00000000] 50 >>>>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] >>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call >>>>>>>>>>>>>>>>>>> 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 >>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013f9][00102357][00000000] 33c0 >>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d >>>>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret >>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does >>>>>>>>>>>>>>>>>>> not halt but it is obvious that Px should always >>>>>>>>>>>>>>>>>>> halt if H is a valid halt decider that always >>>>>>>>>>>>>>>>>>> returns a decision to its caller (Px). Olcott's H >>>>>>>>>>>>>>>>>>> does not return a decision to its caller (Px) and >>>>>>>>>>>>>>>>>>> is thus invalid.
/Flibble
Your false assumptions are directly contradicted by >>>>>>>>>>>>>>>>>> the semantics of the x86 programming language. >>>>>>>>>>>>>>>>>>
*x86 Instruction Set Reference* https://c9x.me/x86/ >>>>>>>>>>>>>>>>>>
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, >>>>>>>>>>>>>>>>>> (u32)Px)); }
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>> [00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>> [0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine >>>>>>>>>>>>>>>>>> assembly address address data code >>>>>>>>>>>>>>>>>> language ======== ======== ======== ========= >>>>>>>>>>>>>>>>>> ============= [000011d2][00101f7f][00000000] 55 >>>>>>>>>>>>>>>>>> push ebp [000011d3][00101f7f][00000000] 8bec >>>>>>>>>>>>>>>>>> mov ebp,esp [000011d5][00101f7b][00001192] >>>>>>>>>>>>>>>>>> 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push >>>>>>>>>>>>>>>>>> 00001192 [000011df][00101f73][000011e4] e88efdffff >>>>>>>>>>>>>>>>>> call 00000f72
H: Begin Simulation Execution Trace Stored >>>>>>>>>>>>>>>>>> at:11202b Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp >>>>>>>>>>>>>>>>>> [00001193][00112017][0011201b] 8bec mov ebp,esp >>>>>>>>>>>>>>>>>> [00001195][00112017][0011201b] 8b4508 mov >>>>>>>>>>>>>>>>>> eax,[ebp+08] [00001198][00112013][00001192] 50 >>>>>>>>>>>>>>>>>> push eax // push Px
[00001199][00112013][00001192] 8b4d08 mov >>>>>>>>>>>>>>>>>> ecx,[ebp+08] [0000119c][0011200f][00001192] 51 >>>>>>>>>>>>>>>>>> push ecx // push Px [0000119d][0011200b][000011a2] >>>>>>>>>>>>>>>>>> e8d0fdffff call 00000f72 // call H(Px,Px) H: >>>>>>>>>>>>>>>>>> Infinitely Recursive Simulation Detected Simulation >>>>>>>>>>>>>>>>>> Stopped
H knows its own machine address and on this basis it >>>>>>>>>>>>>>>>>> can easily examine its stored execution_trace of Px >>>>>>>>>>>>>>>>>> (see above) to determine: (a) Px is calling H with >>>>>>>>>>>>>>>>>> the same arguments that H was called with. (b) No >>>>>>>>>>>>>>>>>> instructions in Px could possibly escape this >>>>>>>>>>>>>>>>>> otherwise infinitely recursive emulation. (c) H >>>>>>>>>>>>>>>>>> aborts its emulation of Px before its call to H is >>>>>>>>>>>>>>>>>> emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>> [000011e7][00101f7b][00000000] 50 push eax >>>>>>>>>>>>>>>>>> [000011e8][00101f77][000004a3] 68a3040000 push >>>>>>>>>>>>>>>>>> 000004a3 [000011ed][00101f77][000004a3] e800f3ffff >>>>>>>>>>>>>>>>>> call 000004f2 Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08 >>>>>>>>>>>>>>>>>> [000011f5][00101f7f][00000000] 33c0 xor eax,eax >>>>>>>>>>>>>>>>>> [000011f7][00101f83][00000018] 5d pop ebp >>>>>>>>>>>>>>>>>> [000011f8][00101f87][00000000] c3 ret >>>>>>>>>>>>>>>>>> Number of Instructions Executed(880) == 13 Pages >>>>>>>>>>>>>>>>>
/Flibble
In other words you are rejecting the concept of a >>>>>>>>>>>>>>>> simulating halt decider even though I conclusively >>>>>>>>>>>>>>>> proved that it does correctly determine the halt >>>>>>>>>>>>>>>> status of: (see my new paper)
No I am rejecting your simulating halt decider as it >>>>>>>>>>>>>>> gets the answer wrong for Px() which is not a
pathological input. Px() halts.
/Flibble
I just proved that H(Px,Px) does correctly predict that >>>>>>>>>>>>>> its complete and correct x86 emulation of its input >>>>>>>>>>>>>> would never reach the "ret" instruction of this input >>>>>>>>>>>>>> because of the pathological relationship between H and >>>>>>>>>>>>>> Px.
Wrong. Px() is not a pathological input as defined by the >>>>>>>>>>>>> halting problem and [Strachey 1965] as it does not try to >>>>>>>>>>>>> do the opposite of what H decides.
/Flibble
Your lack of comprehension does not actually count as any >>>>>>>>>>>> rebuttal at all.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
As shown below the above P and H have the required (halting >>>>>>>>>>>> problem) pathological relationship to each other:
P does but Px does not. I am talking about Px not P.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add
esp,+08 ...[000013eb][00102353][00000000] 50
push eax ...[000013ec][0010234f][00000427] 6827040000
push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff >>>>>>>>>>> call 00000476 Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add
esp,+08 ...[000013f9][00102357][00000000] 33c0
xor eax,eax ...[000013fb][0010235b][00100000] 5d
pop ebp ...[000013fc][0010235f][00000004] c3
ret Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not >>>>>>>>>>> halt but it is obvious that Px should always halt if H is a >>>>>>>>>>> valid halt decider that always returns a decision to its >>>>>>>>>>> caller (Px). Olcott's H does not return a decision to its >>>>>>>>>>> caller (Px) and is thus invalid.
/Flibble
>
Your false assumptions are directly contradicted by the
semantics of the x86 programming language.
*x86 Instruction Set Reference* https://c9x.me/x86/
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](03) 8b4508 mov eax,[ebp+08]
[00001198](01) 50 push eax
[00001199](03) 8b4d08 mov ecx,[ebp+08]
[0000119c](01) 51 push ecx
[0000119d](05) e8d0fdffff call 00000f72
[000011a2](03) 83c408 add esp,+08
[000011a5](01) 5d pop ebp
[000011a6](01) c3 ret
Size in bytes:(0021) [000011a6]
_main()
[000011d2](01) 55 push ebp
[000011d3](02) 8bec mov ebp,esp
[000011d5](05) 6892110000 push 00001192
[000011da](05) 6892110000 push 00001192
[000011df](05) e88efdffff call 00000f72
[000011e4](03) 83c408 add esp,+08
[000011e7](01) 50 push eax
[000011e8](05) 68a3040000 push 000004a3
[000011ed](05) e800f3ffff call 000004f2
[000011f2](03) 83c408 add esp,+08
[000011f5](02) 33c0 xor eax,eax
[000011f7](01) 5d pop ebp
[000011f8](01) c3 ret
Size in bytes:(0039) [000011f8]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= >>>>>>>>>> [000011d2][00101f7f][00000000] 55 push ebp
[000011d3][00101f7f][00000000] 8bec mov ebp,esp
[000011d5][00101f7b][00001192] 6892110000 push 00001192
[000011da][00101f77][00001192] 6892110000 push 00001192
[000011df][00101f73][000011e4] e88efdffff call 00000f72
H: Begin Simulation Execution Trace Stored at:11202b
Address_of_H:f72
[00001192][00112017][0011201b] 55 push ebp
[00001193][00112017][0011201b] 8bec mov ebp,esp
[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08] >>>>>>>>>> [00001198][00112013][00001192] 50 push eax // >>>>>>>>>> push Px [00001199][00112013][00001192] 8b4d08 mov
ecx,[ebp+08] [0000119c][0011200f][00001192] 51 push >>>>>>>>>> ecx // push Px [0000119d][0011200b][000011a2]
e8d0fdffff call 00000f72 // call H(Px,Px) H: Infinitely
Recursive Simulation Detected Simulation Stopped
H knows its own machine address and on this basis it can
easily examine its stored execution_trace of Px (see above) >>>>>>>>>> to determine: (a) Px is calling H with the same arguments
that H was called with. (b) No instructions in Px could
possibly escape this otherwise infinitely recursive
emulation. (c) H aborts its emulation of Px before its call >>>>>>>>>> to H is emulated.
[000011e4][00101f7f][00000000] 83c408 add esp,+08
[000011e7][00101f7b][00000000] 50 push eax
[000011e8][00101f77][000004a3] 68a3040000 push 000004a3
[000011ed][00101f77][000004a3] e800f3ffff call 000004f2
Input_Halts = 0
[000011f2][00101f7f][00000000] 83c408 add esp,+08
[000011f5][00101f7f][00000000] 33c0 xor eax,eax
[000011f7][00101f83][00000018] 5d pop ebp
[000011f8][00101f87][00000000] c3 ret
Number of Instructions Executed(880) == 13 Pages
I see you wish to pointlessly go around in circles. Oh well. >>>>>>>>>
Px() is not a pathological input as defined by the halting
problem and [Strachey 1965] as it does not try to do the
opposite of what H decides.
Px() always halts so your H gets the answer wrong.
/Flibble
I found that my reply did not make it to all the groups so I
posted it again.
*This general principle refutes conventional halting problem
proofs* Every simulating halt decider that correctly simulates >>>>>>>> its input until it correctly predicts that this simulated input >>>>>>>> would never reach its final state, correctly rejects this input >>>>>>>> as non-halting.
Your H does not "correctly predict" that Px() does reach its
final state and so should accept the input as halting.
/Flibble
(x86 Instruction Set Reference* https://c9x.me/x86/
The semantics of the x86 language conclusively proves that the
above code is correct. People that disagree with verified facts
are either incompetent or liars. Since you cannot even understand
that the return statement in Px is unreachable code, (to every
simulating halt decider H) you would be incompetent.
Not EVERY simulating halt decider, only YOURS gets the answer
wrong. Px() halts.
/Flibble
Since you cannot even understand that the return statement in Px is
unreachable code, (to *every simulating halt* decider H) you would
be incompetent.
Not at all. If I was to design a simulating halt decider then rather
than aborting the simulation at the point where P()/Px() calls H I
would instead fork the simulation, returning 0 to one branch (the
non-halting branch) and 1 to the other branch (the halting branch)
and then continue to simulate both branches in parallel thereby
getting rid of the "infinite recursion".
/Flibble
Yet that is *not* what the actual code specifies. Every function
called in infinite recursion is not allowed to return to its caller.
The infinite recursion is an artifact of how YOU are trying to solve
the problem; there is no infinite recursion in [Strachey 1965] and
associated proofs.
/Flibble
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other basis
than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no need for
a call to a simulation-based halting decider, H, from the input program
to be recursive; this is compatible with [Strachey 1965] and
associated proofs which are not recursive in nature. Your H is invalid
as it aborts the simulation to prevent infinite recursion rather than returning an answer to its caller which results in it giving the wrong
answer for a non-pathological input that calls H.
/Flibble
On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote:
On 7/3/2022 6:10 PM, dklei...@gmail.com wrote:Your paper is not acceptable as a proof of anything. But that is to
On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote:
On 7/3/2022 2:35 PM, dklei...@gmail.com wrote:It might if any such halt deciders existed. You need to prove such "halt >>> deciders" exist.
On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote:
This "general principle is" a trivial definition: A simulation of a
*This general principle refutes conventional halting problem proofs* >>>>>>
Every simulating halt decider that correctly simulates its input until >>>>>> it correctly predicts that this simulated input would never reach its >>>>>> final state, correctly rejects this input as non-halting.
called routine that stops when it can predict that the routine
will never return is called a halt decider.
In words of one syllable - so what?
It refutes conventional halting problem proofs
You can't keep ignoring my paper and claiming that I have not proved my
point.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
be expected because my standard is mathematical proof and
you don't even pretend to be doing mathematics.
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other basis
than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no need
for a call to a simulation-based halting decider, H, from the input
program to be recursive; this is compatible with [Strachey 1965] and
associated proofs which are not recursive in nature. Your H is
invalid as it aborts the simulation to prevent infinite recursion
rather than returning an answer to its caller which results in it
giving the wrong answer for a non-pathological input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input
would never reach the "ret" instruction (final state) of this input.
No it doesn't. What you have doesn't work.
/Flibble
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other basis
than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that is
actually specified by these inputs.
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no need
for a call to a simulation-based halting decider, H, from the input
program to be recursive; this is compatible with [Strachey 1965] and associated proofs which are not recursive in nature. Your H is
invalid as it aborts the simulation to prevent infinite recursion
rather than returning an answer to its caller which results in it
giving the wrong answer for a non-pathological input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input
would never reach the "ret" instruction (final state) of this input.
On 7/4/2022 12:25 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other basis
than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no need
for a call to a simulation-based halting decider, H, from the
input program to be recursive; this is compatible with [Strachey
1965] and associated proofs which are not recursive in nature.
Your H is invalid as it aborts the simulation to prevent infinite
recursion rather than returning an answer to its caller which
results in it giving the wrong answer for a non-pathological
input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input
would never reach the "ret" instruction (final state) of this
input.
No it doesn't. What you have doesn't work.
/Flibble
Try and prove how foolish you are by attempting to refute the above
statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software engineering* https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:25 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other basis
than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior that
is actually specified by these inputs.
This much more concise version of my paper focuses on the actual
execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no need
for a call to a simulation-based halting decider, H, from the
input program to be recursive; this is compatible with [Strachey
1965] and associated proofs which are not recursive in nature.
Your H is invalid as it aborts the simulation to prevent infinite
recursion rather than returning an answer to its caller which
results in it giving the wrong answer for a non-pathological
input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input
would never reach the "ret" instruction (final state) of this
input.
No it doesn't. What you have doesn't work.
/Flibble
Try and prove how foolish you are by attempting to refute the above
statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
I don't have to consider your "paper"; the evidence is here for all to
see:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but it is obvious that Px should always halt if H is a valid halt decider that
always returns a decision to its caller (Px). Olcott's H does not
return a decision to its caller (Px) and is thus invalid.
On 7/4/2022 12:39 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:25 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other
basis than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs to
an accept or reject state on the basis of the actual behavior
that is actually specified by these inputs.
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no
need for a call to a simulation-based halting decider, H, from
the input program to be recursive; this is compatible with
[Strachey 1965] and associated proofs which are not recursive
in nature. Your H is invalid as it aborts the simulation to
prevent infinite recursion rather than returning an answer to
its caller which results in it giving the wrong answer for a
non-pathological input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in
the semantics of the x86 language) it is proven that H(P,P)
correctly predicts that its correct and complete x86 emulation
of its input would never reach the "ret" instruction (final
state) of this input.
No it doesn't. What you have doesn't work.
/Flibble
Try and prove how foolish you are by attempting to refute the above
statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
I don't have to consider your "paper"; the evidence is here for all
to see:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
Your trace always deceitfully leaves out key details.
Input_Halts = 0
On Mon, 4 Jul 2022 12:51:24 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:39 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:25 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other
basis than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs to >>>>>>>> an accept or reject state on the basis of the actual behavior
that is actually specified by these inputs.
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts
H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no
need for a call to a simulation-based halting decider, H, from
the input program to be recursive; this is compatible with
[Strachey 1965] and associated proofs which are not recursive
in nature. Your H is invalid as it aborts the simulation to
prevent infinite recursion rather than returning an answer to
its caller which results in it giving the wrong answer for a
non-pathological input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in
the semantics of the x86 language) it is proven that H(P,P)
correctly predicts that its correct and complete x86 emulation
of its input would never reach the "ret" instruction (final
state) of this input.
No it doesn't. What you have doesn't work.
/Flibble
Try and prove how foolish you are by attempting to refute the above
statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
I don't have to consider your "paper"; the evidence is here for all
to see:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
Your trace always deceitfully leaves out key details.
My trace only includes the pertinent details: namely that it gets the
halting decision wrong:
Input_Halts = 0
/Flibble
On 7/4/2022 12:54 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:51:24 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:39 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:25 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other
basis than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs
to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts >>>>>>>> H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no
need for a call to a simulation-based halting decider, H, from >>>>>>> the input program to be recursive; this is compatible with
[Strachey 1965] and associated proofs which are not recursive
in nature. Your H is invalid as it aborts the simulation to
prevent infinite recursion rather than returning an answer to
its caller which results in it giving the wrong answer for a
non-pathological input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in
the semantics of the x86 language) it is proven that H(P,P)
correctly predicts that its correct and complete x86 emulation
of its input would never reach the "ret" instruction (final
state) of this input.
No it doesn't. What you have doesn't work.
/Flibble
Try and prove how foolish you are by attempting to refute the
above statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
I don't have to consider your "paper"; the evidence is here for
all to see:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
Your trace always deceitfully leaves out key details.
My trace only includes the pertinent details: namely that it gets
the halting decision wrong:
Input_Halts = 0
/Flibble
You continue under the false assumption that a function called in
infinite recursion must return to its caller. That you continue in
the false assumption after multiple corrections is a little nuts.
On 7/4/2022 1:38 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 13:00:21 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:54 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:51:24 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:39 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:25 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other >>>>>>>>>> basis than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs >>>>>>>>>> to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
This much more concise version of my paper focuses on the >>>>>>>>>> actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts >>>>>>>>>> H correctly determines that Infinite_Recursion() never
halts H(P,P) correctly determines that its input never
halts
As I have shown with my signaling halting decider there is >>>>>>>>> no need for a call to a simulation-based halting decider,
H, from the input program to be recursive; this is
compatible with [Strachey 1965] and associated proofs which >>>>>>>>> are not recursive in nature. Your H is invalid as it aborts >>>>>>>>> the simulation to prevent infinite recursion rather than
returning an answer to its caller which results in it
giving the wrong answer for a non-pathological input that
calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective
(anchored in the semantics of the x86 language) it is proven >>>>>>>> that H(P,P) correctly predicts that its correct and complete >>>>>>>> x86 emulation of its input would never reach the "ret"
instruction (final state) of this input.
No it doesn't. What you have doesn't work.
/Flibble
Try and prove how foolish you are by attempting to refute the
above statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
I don't have to consider your "paper"; the evidence is here for
all to see:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt
but it is obvious that Px should always halt if H is a valid
halt decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
Your trace always deceitfully leaves out key details.
My trace only includes the pertinent details: namely that it gets
the halting decision wrong:
Input_Halts = 0
/Flibble
You continue under the false assumption that a function called in
infinite recursion must return to its caller. That you continue in
the false assumption after multiple corrections is a little nuts.
There is no infinite recursion in [Strachey 1965] or associated
proofs
Only because no one bothered to ever fully examine applying a
simulating halt decider to the halting theorem counter-examples prior
to:
comp.theory: [Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
and I have shown that there need not be any recursion when using a simulation-based halting decider;
You have not shown this. One is not free to diverge from the
semantics specified by the C/x86 source-code. If infinite recursion
is specified in this source-code then infinite recursion must occur
in the execution trace until it is aborted.
if you have to abort your simulation
to avoid infinite recursion then that just goes to show that your
solution is wrong.
Actually it proves that my solution is correct. A simulating halt
decider must always abort its simulation of every non-halting input.
On Mon, 4 Jul 2022 13:00:21 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:54 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:51:24 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:39 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:25 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other >>>>>>>>>> basis than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs >>>>>>>>>> to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
This much more concise version of my paper focuses on the
actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts
H correctly determines that Infinite_Recursion() never halts >>>>>>>>>> H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no >>>>>>>>> need for a call to a simulation-based halting decider, H, from >>>>>>>>> the input program to be recursive; this is compatible with
[Strachey 1965] and associated proofs which are not recursive >>>>>>>>> in nature. Your H is invalid as it aborts the simulation to
prevent infinite recursion rather than returning an answer to >>>>>>>>> its caller which results in it giving the wrong answer for a >>>>>>>>> non-pathological input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in >>>>>>>> the semantics of the x86 language) it is proven that H(P,P)
correctly predicts that its correct and complete x86 emulation >>>>>>>> of its input would never reach the "ret" instruction (final
state) of this input.
No it doesn't. What you have doesn't work.
/Flibble
Try and prove how foolish you are by attempting to refute the
above statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
I don't have to consider your "paper"; the evidence is here for
all to see:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
Your trace always deceitfully leaves out key details.
My trace only includes the pertinent details: namely that it gets
the halting decision wrong:
Input_Halts = 0
/Flibble
You continue under the false assumption that a function called in
infinite recursion must return to its caller. That you continue in
the false assumption after multiple corrections is a little nuts.
There is no infinite recursion in [Strachey 1965] or associated proofs
and I have shown that there need not be any recursion when using a simulation-based halting decider;
if you have to abort your simulation
to avoid infinite recursion then that just goes to show that your
solution is wrong.
/Flibble
On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote:
On 7/4/2022 11:36 AM, dklei...@gmail.com wrote:There is a great deal more to a mathematical proof than a formal
On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote:
On 7/3/2022 6:10 PM, dklei...@gmail.com wrote:Your paper is not acceptable as a proof of anything. But that is to
On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote:
On 7/3/2022 2:35 PM, dklei...@gmail.com wrote:It might if any such halt deciders existed. You need to prove such "halt >>>>> deciders" exist.
On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote:
This "general principle is" a trivial definition: A simulation of a >>>>>>> called routine that stops when it can predict that the routine
*This general principle refutes conventional halting problem proofs* >>>>>>>>
Every simulating halt decider that correctly simulates its input until >>>>>>>> it correctly predicts that this simulated input would never reach its >>>>>>>> final state, correctly rejects this input as non-halting.
will never return is called a halt decider.
In words of one syllable - so what?
It refutes conventional halting problem proofs
You can't keep ignoring my paper and claiming that I have not proved my >>>> point.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
be expected because my standard is mathematical proof and
you don't even pretend to be doing mathematics.
When we construe the x86 language and its associated semantics as a
formal language with formal semantics then this becomes a formal proof:
language. I believe that you do not have training in mathematics and you
do show little sympathy for the concerns of the mathematical
community. What you call "software engineering" is essentially hostile to classical mathematics.
Moreover if you wish us to take you seriously you must do more than "construing". You must exhibit the x86 "language" as a formal system
and show how it is used in a formal proof.
On 7/4/2022 1:38 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 13:00:21 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:54 PM, Mr Flibble wrote:There is no infinite recursion in [Strachey 1965] or associated proofs
On Mon, 4 Jul 2022 12:51:24 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:39 PM, Mr Flibble wrote:
On Mon, 4 Jul 2022 12:33:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 12:25 PM, Mr Flibble wrote:I don't have to consider your "paper"; the evidence is here for
On Mon, 4 Jul 2022 11:54:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 7/4/2022 10:58 AM, Mr Flibble wrote:No it doesn't. What you have doesn't work.
On Mon, 4 Jul 2022 09:45:45 -0500
olcott <NoOne@NoWhere.com> wrote:
No one can provide any "rebuttal" of my paper on any other >>>>>>>>>>> basis than
(1) disagreeing with the semantics of the x86 language
*x86 Instruction Set Reference* https://c9x.me/x86/
*or disagreeing with this necessarily true principle*
(2) A halt decider must compute the mapping from its inputs >>>>>>>>>>> to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
This much more concise version of my paper focuses on the >>>>>>>>>>> actual execution of three fully operational examples.
H0 correctly determines that Infinite_Loop() never halts >>>>>>>>>>> H correctly determines that Infinite_Recursion() never halts >>>>>>>>>>> H(P,P) correctly determines that its input never halts
As I have shown with my signaling halting decider there is no >>>>>>>>>> need for a call to a simulation-based halting decider, H, from >>>>>>>>>> the input program to be recursive; this is compatible with >>>>>>>>>> [Strachey 1965] and associated proofs which are not recursive >>>>>>>>>> in nature. Your H is invalid as it aborts the simulation to >>>>>>>>>> prevent infinite recursion rather than returning an answer to >>>>>>>>>> its caller which results in it giving the wrong answer for a >>>>>>>>>> non-pathological input that calls H.
/Flibble
YOU KEEP DISAGREEING WITH VERIFIED FACTS:
From a purely software engineering perspective (anchored in >>>>>>>>> the semantics of the x86 language) it is proven that H(P,P)
correctly predicts that its correct and complete x86 emulation >>>>>>>>> of its input would never reach the "ret" instruction (final
state) of this input.
/Flibble
Try and prove how foolish you are by attempting to refute the
above statement on the basis is this paper:
*Halting problem proofs refuted on the basis of software
engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
all to see:
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
...[000013e8][00102357][00000000] 83c408 add esp,+08 >>>>>> ...[000013eb][00102353][00000000] 50 push eax >>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 >>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax >>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp >>>>>> ...[000013fc][0010235f][00000004] c3 ret >>>>>> Number of Instructions Executed(16120)
As can be seen above Olcott's H decides that Px does not halt but
it is obvious that Px should always halt if H is a valid halt
decider that always returns a decision to its caller (Px).
Olcott's H does not return a decision to its caller (Px) and is
thus invalid.
Your trace always deceitfully leaves out key details.
My trace only includes the pertinent details: namely that it gets
the halting decision wrong:
Input_Halts = 0
/Flibble
You continue under the false assumption that a function called in
infinite recursion must return to its caller. That you continue in
the false assumption after multiple corrections is a little nuts.
Only because no one bothered to ever fully examine applying a simulating
halt decider to the halting theorem counter-examples prior to:
comp.theory: [Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
and I have shown that there need not be any recursion when using a
simulation-based halting decider;
You have not shown this. One is not free to diverge from the semantics specified by the C/x86 source-code. If infinite recursion is specified
in this source-code then infinite recursion must occur in the execution
trace until it is aborted.
if you have to abort your simulation
to avoid infinite recursion then that just goes to show that your
solution is wrong.
Actually it proves that my solution is correct. A simulating halt
decider must always abort its simulation of every non-halting input.
/Flibble
On 7/4/2022 1:42 PM, dklei...@gmail.com wrote:
On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote:
On 7/4/2022 11:36 AM, dklei...@gmail.com wrote:There is a great deal more to a mathematical proof than a formal
On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote:
On 7/3/2022 6:10 PM, dklei...@gmail.com wrote:Your paper is not acceptable as a proof of anything. But that is to
On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote:
On 7/3/2022 2:35 PM, dklei...@gmail.com wrote:It might if any such halt deciders existed. You need to prove such >>>>>> "halt
On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote:
This "general principle is" a trivial definition: A simulation of a >>>>>>>> called routine that stops when it can predict that the routine >>>>>>>> will never return is called a halt decider.
*This general principle refutes conventional halting problem >>>>>>>>> proofs*
Every simulating halt decider that correctly simulates its
input until
it correctly predicts that this simulated input would never
reach its
final state, correctly rejects this input as non-halting.
In words of one syllable - so what?
It refutes conventional halting problem proofs
deciders" exist.
You can't keep ignoring my paper and claiming that I have not
proved my
point.
*Halting problem proofs refuted on the basis of software engineering* >>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
be expected because my standard is mathematical proof and
you don't even pretend to be doing mathematics.
When we construe the x86 language and its associated semantics as a
formal language with formal semantics then this becomes a formal proof:
language. I believe that you do not have training in mathematics and you
do show little sympathy for the concerns of the mathematical
community. What you call "software engineering" is essentially hostile to
classical mathematics.
Moreover if you wish us to take you seriously you must do more than
"construing". You must exhibit the x86 "language" as a formal system
and show how it is used in a formal proof.
What more is there to the essence of any formal proof besides applying
the formal semantics specified by a formal language as a sequence of
truth preserving steps?
Instead of premises a computation has an initial state.
Instead of a conclusion premises a computation has a final state.
*Curry–Howard correspondence*
In programming language theory and proof theory, the Curry–Howard correspondence (also known as the Curry–Howard isomorphism or
equivalence, or the proofs-as-programs and propositions- or
formulae-as-types interpretation) is the direct relationship between
computer programs and mathematical proofs.
https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
On 7/5/2022 3:53 AM, Mikko wrote:
On 2022-07-04 00:44:23 +0000, olcott said:
You can't keep ignoring my paper and claiming that I have not proved
my point.
In order to make your proof publishable, you should decrate every
sentence
in the proof with the numbers of that sentence or those two sentences
from
which the sentence is derived with truth preserving rules.
Mikko
The proof is (Curry/Howard Correspondence) between programs and proofs,
thus H has an initial state performs a sequence of state transitions and
ends in a final state rejecting its input as non-halting.
*Halting problem proofs refuted on the basis of software engineering* https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
On 2022-07-04 00:44:23 +0000, olcott said:
You can't keep ignoring my paper and claiming that I have not proved
my point.
In order to make your proof publishable, you should decrate every sentence
in the proof with the numbers of that sentence or those two sentences from which the sentence is derived with truth preserving rules.
Mikko
On 7/5/2022 3:53 AM, Mikko wrote:
On 2022-07-04 00:44:23 +0000, olcott said:
You can't keep ignoring my paper and claiming that I have not proved
my point.
In order to make your proof publishable, you should decrate every
sentence
in the proof with the numbers of that sentence or those two sentences
from
which the sentence is derived with truth preserving rules.
Mikko
The proof is (Curry/Howard Correspondence) between programs and proofs,
thus H has an initial state performs a sequence of state transitions and
ends in a final state rejecting its input as non-halting.
*Halting problem proofs refuted on the basis of software engineering* https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
On 7/9/2022 12:22 PM, dklei...@gmail.com wrote:
On Saturday, July 9, 2022 at 6:16:37 AM UTC-7, olcott wrote:
On 7/8/2022 5:48 PM, olcott wrote:
On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:
On Thursday, July 7, 2022 at 9:48:17 PM UTC-7, olcott wrote:
On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:
int Strachey_P(void) {
if (T(&Strachey_P)) return 1;
else return 0; }
int main() {
if (T(&Strachey_P)) Output("Halts");
else Output ("Does not halt");}
Without the definition of T this is just boiler plate.
Yours is incorrect:
How? I assume C89.
typedef void (*ptr)();
int Strachey_P2(void) {
if (T(&Strachey_P2)) return 1;
else return 0; }
int main()
{
if (T(Strachey_P2)) OutputString("Halts\n");
else OutputString("Does not halt\n");
}
_Strachey_P2()
[0000134e](01) 55 push ebp
[0000134f](02) 8bec mov ebp,esp
[00001351](05) 684e130000 push 0000134e
[00001356](05) e893fbffff call 00000eee
[0000135b](03) 83c404 add esp,+04
[0000135e](02) 85c0 test eax,eax
[00001360](02) 7409 jz 0000136b
[00001362](05) b801000000 mov eax,00000001
[00001367](02) eb04 jmp 0000136d
[00001369](02) eb02 jmp 0000136d
[0000136b](02) 33c0 xor eax,eax
[0000136d](01) 5d pop ebp
[0000136e](01) c3 ret
Size in bytes:(0033) [0000136e]
_main()
[0000137e](01) 55 push ebp
[0000137f](02) 8bec mov ebp,esp
[00001381](05) 684e130000 push 0000134e
[00001386](05) e863fbffff call 00000eee
[0000138b](03) 83c404 add esp,+04
[0000138e](02) 85c0 test eax,eax
[00001390](02) 740f jz 000013a1
[00001392](05) 6817050000 push 00000517
[00001397](05) e8c2f1ffff call 0000055e
[0000139c](03) 83c404 add esp,+04
[0000139f](02) eb0d jmp 000013ae
[000013a1](05) 681f050000 push 0000051f
[000013a6](05) e8b3f1ffff call 0000055e
[000013ab](03) 83c404 add esp,+04
[000013ae](02) 33c0 xor eax,eax
[000013b0](01) 5d pop ebp
[000013b1](01) c3 ret
Size in bytes:(0052) [000013b1]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000137e][001022be][00000000] 55 push ebp
[0000137f][001022be][00000000] 8bec mov ebp,esp
[00001381][001022ba][0000134e] 684e130000 push 0000134e
[00001386][001022b6][0000138b] e863fbffff call 00000eee
T: Begin Simulation Execution Trace Stored at:11236a
Address_of_T:eee
[0000134e][0011235a][0011235e] 55 push ebp
[0000134f][0011235a][0011235e] 8bec mov ebp,esp
[00001351][00112356][0000134e] 684e130000 push 0000134e
[00001356][00112352][0000135b] e893fbffff call 00000eee
T: Infinitely Recursive Simulation Detected Simulation Stopped
[0000138b][001022be][00000000] 83c404 add esp,+04
[0000138e][001022be][00000000] 85c0 test eax,eax
[00001390][001022be][00000000] 740f jz 000013a1
[000013a1][001022ba][0000051f] 681f050000 push 0000051f
[000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e
Does not halt
[000013ab][001022be][00000000] 83c404 add esp,+04
[000013ae][001022be][00000000] 33c0 xor eax,eax
[000013b0][001022c2][00000018] 5d pop ebp
[000013b1][001022c6][00000000] c3 ret
Number of Instructions Executed(539) == 8 Pages
As nearly as I can tell this is all what I called boilerplate.
Essentially
no substantial content.
If you have a computer program that shows what you claim show
your complete code and we can check its validity. No programmer
is competent to pass a definitive judgement baout his own work.
The above execution trace of simulating halt decider T(Strachey_P2)
proves that T correctly predicts that its correct and complete x86
emulation of its input would never reach the "ret" instruction of this
input. This allows T to correctly reject Strachey_P2 as non-halting.
Anyone having these required prerequisites can verify the above
paragraph without seeing the source-code.
To fully understand this paper a software engineer must be an expert in:
(a) The C programming language.
(b) The x86 programming language.
(c) Exactly how C translates into x86 (how C function calls are
implemented in x86).
(d) The ability to recognize infinite recursion at the x86 assembly
language level.
Anyone not having these required prerequisites will not be able to
verify the above paragraph even after seeing the source-code because
they will not be able to understand what the halt decider is doing
unless they know the x86 language quite well.
The code requires more refactoring before it is clean enough for
publication.
I updated the original x86 emulator so that
(1) It compiles under Windows as well as Linux. 16390 source-code lines.
(2) One of its original functions can disassemble or simulate its input depending on a boolean flag.
(3) The COFF output of the the Microsoft C compiler can be directly
executed. (contained in Read_COFF_Object.h). 924 source-code lines.
The x86utm operation system is in x86utm.cpp
2038 source-code lines.
The various halt deciders and their sample input is in Halt7.c
638 source-code lines.
On Saturday, July 9, 2022 at 6:16:37 AM UTC-7, olcott wrote:
On 7/8/2022 5:48 PM, olcott wrote:
On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:
On Thursday, July 7, 2022 at 9:48:17 PM UTC-7, olcott wrote:
On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:
int Strachey_P(void) {
if (T(&Strachey_P)) return 1;
else return 0; }
int main() {
if (T(&Strachey_P)) Output("Halts");
else Output ("Does not halt");}
Without the definition of T this is just boiler plate.
Yours is incorrect:
How? I assume C89.
typedef void (*ptr)();
int Strachey_P2(void) {
if (T(&Strachey_P2)) return 1;
else return 0; }
int main()
{
if (T(Strachey_P2)) OutputString("Halts\n");
else OutputString("Does not halt\n");
}
_Strachey_P2()
[0000134e](01) 55 push ebp
[0000134f](02) 8bec mov ebp,esp
[00001351](05) 684e130000 push 0000134e
[00001356](05) e893fbffff call 00000eee
[0000135b](03) 83c404 add esp,+04
[0000135e](02) 85c0 test eax,eax
[00001360](02) 7409 jz 0000136b
[00001362](05) b801000000 mov eax,00000001
[00001367](02) eb04 jmp 0000136d
[00001369](02) eb02 jmp 0000136d
[0000136b](02) 33c0 xor eax,eax
[0000136d](01) 5d pop ebp
[0000136e](01) c3 ret
Size in bytes:(0033) [0000136e]
_main()
[0000137e](01) 55 push ebp
[0000137f](02) 8bec mov ebp,esp
[00001381](05) 684e130000 push 0000134e
[00001386](05) e863fbffff call 00000eee
[0000138b](03) 83c404 add esp,+04
[0000138e](02) 85c0 test eax,eax
[00001390](02) 740f jz 000013a1
[00001392](05) 6817050000 push 00000517
[00001397](05) e8c2f1ffff call 0000055e
[0000139c](03) 83c404 add esp,+04
[0000139f](02) eb0d jmp 000013ae
[000013a1](05) 681f050000 push 0000051f
[000013a6](05) e8b3f1ffff call 0000055e
[000013ab](03) 83c404 add esp,+04
[000013ae](02) 33c0 xor eax,eax
[000013b0](01) 5d pop ebp
[000013b1](01) c3 ret
Size in bytes:(0052) [000013b1]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000137e][001022be][00000000] 55 push ebp
[0000137f][001022be][00000000] 8bec mov ebp,esp
[00001381][001022ba][0000134e] 684e130000 push 0000134e
[00001386][001022b6][0000138b] e863fbffff call 00000eee
T: Begin Simulation Execution Trace Stored at:11236a
Address_of_T:eee
[0000134e][0011235a][0011235e] 55 push ebp
[0000134f][0011235a][0011235e] 8bec mov ebp,esp
[00001351][00112356][0000134e] 684e130000 push 0000134e
[00001356][00112352][0000135b] e893fbffff call 00000eee
T: Infinitely Recursive Simulation Detected Simulation Stopped
[0000138b][001022be][00000000] 83c404 add esp,+04
[0000138e][001022be][00000000] 85c0 test eax,eax
[00001390][001022be][00000000] 740f jz 000013a1
[000013a1][001022ba][0000051f] 681f050000 push 0000051f
[000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e
Does not halt
[000013ab][001022be][00000000] 83c404 add esp,+04
[000013ae][001022be][00000000] 33c0 xor eax,eax
[000013b0][001022c2][00000018] 5d pop ebp
[000013b1][001022c6][00000000] c3 ret
Number of Instructions Executed(539) == 8 Pages
As nearly as I can tell this is all what I called boilerplate. Essentially
no substantial content.
If you have a computer program that shows what you claim show
your complete code and we can check its validity. No programmer
is competent to pass a definitive judgement baout his own work.
On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:you are very rude.
On 7/13/2022 10:02 AM, Paul N wrote:
Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument,
not simulate correctly.
On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
*CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
I rewrote this question so that a software engineer of ordinary skill
can easily verify that the simulated P does call H in what is
essentially infinite recursion. **This simplification is the result of >>>> an extensive review (23 emails) by a leading computer scientist over the >>>> weekend.**
Does H(P,P) correctly determine the halt status of the halting problem's >>>> pathological input?
The following H and P have the above specified pathological relationship >>>> to each other.
typedef void (*ptr)();
int H(ptr p, ptr i);
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on >>>> this basis and rejects this input as non-halting.
Thus it is an incorrect assessment, as we'll see below.
*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an accept or >>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
Again, emphasis on "actual behaviour".
*Then (by logical necessity) this is understood to implement that*
Every simulating halt decider that correctly simulates its input until >>>> it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.
You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does
correctly simulating P which calls it.
*The execution trace of function P() simulated by function H() shows*
(1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this
infinitely recursive simulation.
Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not
different.
This proves that H(P,P) correctly predicts that its correctly simulated >>>> input would never terminate normally.
As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is
Welcome back.
When H(P,P) correctly simulates its input this is the ultimate measure
of the actual behavior specified by this input.
No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
A security guard at the front door is only required to validate people
coming in the front door the actual behavior of the actual input to H(P,P). >>
This same security guard is not required to validate people coming in
the back door the direct execution of P(P). Unless a computation is
specified as an actual input to H it is not in the domain of the
computable function that H implements.
H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
If a program M would halt given input X, then H(M, X) is required to be non-zero.
If a program M would not halt given input X, then H(M, X) is required to be zero.
If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) isa "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.function and input we are talking about.
When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the
To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
A) H(P, P) returns 0 and P(P) terminates.
B) H(P, P) returns non-zero and P(P) terminates.
C) H(P, P) returns 0 and P(P) does not terminate.
D) H(P, P) returns non-zero and P(P) does not terminate.
B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
A1) H(P, P) returns 0 because it correctly determines that the input
that it correctly simulates would never terminate normally.
No, that is not a correct answer. You have said numerous times that P(P) terminates.
A2) Directly executed P(P) halts because of (A)
On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:you are very rude.
On 7/13/2022 1:03 PM, Paul N wrote:
On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
On 7/13/2022 10:02 AM, Paul N wrote:
Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument,
not simulate correctly.
On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
*CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
I rewrote this question so that a software engineer of ordinary skill >>>>>> can easily verify that the simulated P does call H in what is
essentially infinite recursion. **This simplification is the result of >>>>>> an extensive review (23 emails) by a leading computer scientist over the >>>>>> weekend.**
Does H(P,P) correctly determine the halt status of the halting problem's >>>>>> pathological input?
The following H and P have the above specified pathological relationship >>>>>> to each other.
typedef void (*ptr)();
int H(ptr p, ptr i);
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on >>>>>> this basis and rejects this input as non-halting.
Thus it is an incorrect assessment, as we'll see below.
*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an accept or >>>>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
Again, emphasis on "actual behaviour".
*Then (by logical necessity) this is understood to implement that* >>>>>> Every simulating halt decider that correctly simulates its input until >>>>>> it correctly predicts that this simulated input would never terminate >>>>>> normally, correctly rejects this input as non-halting.
You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does
correctly simulating P which calls it.
*The execution trace of function P() simulated by function H() shows* >>>>>> (1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this
infinitely recursive simulation.
Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not
different.
This proves that H(P,P) correctly predicts that its correctly simulated >>>>>> input would never terminate normally.
As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is
is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.It is an easily verified fact that H(P,P) correctly simulates its inputWelcome back.
When H(P,P) correctly simulates its input this is the ultimate measure >>>> of the actual behavior specified by this input.
No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
to everyone having sufficient knowledge of the x86 assembly language
which currently seems to be hardy no one besides me. Back in the 1986
when I began my career about 10% of all programmers had familiarity
with the x86 language. This is the language that MSDOS and versions
of MS Windows prior to Windows NT were written in. Windows NT switched
to mostly C/C++.
The 23 emails that I had with a leading computer scientist made that
very clear. Because of this I re-framed my explanation so that any
expert C programmer that totally understands infinite recursion would be
able to see that infinitely nested simulation is essentially the same
thing.
The next important point that requires one to have top software
engineering skills that allowed me to transform H into a pure thus
computable function: Infinitely nested simulation can be detected the
first time that the simulated input calls the simulator with its same
arguments. Infinite recursion requires seeing two such calls in a row.
This change allowed me to discard the need for static local memory and
do everything in local memory.
No this a very long standing misconception. H is required to determineA security guard at the front door is only required to validate people >>>> coming in the front door the actual behavior of the actual input to H(P,P).
This same security guard is not required to validate people coming in
the back door the direct execution of P(P). Unless a computation is
specified as an actual input to H it is not in the domain of the
computable function that H implements.
H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
whether or not its correct simulation of its input would ever reach the
normal termination of this input.
Since no one ever bothered to think through the application of a
simulating halt decider to the HP's impossible inputs they always stated
the requirements incorrectly never realizing their mistake.
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
In the H/P concrete example it is easily proven that the actual behavior
of the actual input to H(P,P) is not the behavior of the directly
executed P(P). The best proof of this is the x86 execution trace of each
that precisely corresponds to what the x86 source code of P specifies.
From this is is obvious that the correctly simulated P cannot possibly
terminate normally and the executed P(P) halts.
Those lacking knowledge of the x86 language can understand that this
first halt deciding principle is necessarily correct:
*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
And this second halt deciding principle follows from the first one by
logical necessity.
*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.
This is a misconception that can only be true if the halt decider is
If a program M would halt given input X, then H(M, X) is required to be non-zero.
If a program M would not halt given input X, then H(M, X) is required to be zero.
required to report on something besides the actual behavior of its
actual input.
The ultimate measure of the actual behavior of the actual input is the
provable correct simulation of this input by the simulating halt decider.
To assume that this behavior must be the same as the directly executed
P(P) after it has been conclusively proven to not be that same as an
established fact is at least a little nutty.
That people unequivocally state that I must be wrong entirely on the
basis that they lack sufficient understanding of the x86 language to
understand my proof is a worst case example of the ad ignorantiam logic
error.
If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X)
function and input we are talking about.
Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the
Because that would require that a halt decider must sometimes make its--
To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
A) H(P, P) returns 0 and P(P) terminates.
B) H(P, P) returns non-zero and P(P) terminates.
C) H(P, P) returns 0 and P(P) does not terminate.
D) H(P, P) returns non-zero and P(P) does not terminate.
B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
A1) H(P, P) returns 0 because it correctly determines that the input
that it correctly simulates would never terminate normally.
No, that is not a correct answer. You have said numerous times that P(P) terminates.
A2) Directly executed P(P) halts because of (A)
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Halting problem https://en.wikipedia.org/wiki/Halting_problem
...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.
The property that an arbitrary program P will finish running or not is determined by
running P as an independent program
On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:argument, you are very rude.
On 7/13/2022 3:47 PM, wij wrote:
On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
On 7/13/2022 1:03 PM, Paul N wrote:
On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
On 7/13/2022 10:02 AM, Paul N wrote:
Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your
does not simulate correctly.
On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
*CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
I rewrote this question so that a software engineer of ordinary skill >>>>>>>> can easily verify that the simulated P does call H in what is
essentially infinite recursion. **This simplification is the result of >>>>>>>> an extensive review (23 emails) by a leading computer scientist over the
weekend.**
Does H(P,P) correctly determine the halt status of the halting problem's
pathological input?
The following H and P have the above specified pathological relationship
to each other.
typedef void (*ptr)();
int H(ptr p, ptr i);
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on
this basis and rejects this input as non-halting.
Thus it is an incorrect assessment, as we'll see below.
*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually >>>>>>>> specified by these inputs.
Again, emphasis on "actual behaviour".
*Then (by logical necessity) this is understood to implement that* >>>>>>>> Every simulating halt decider that correctly simulates its input until >>>>>>>> it correctly predicts that this simulated input would never terminate >>>>>>>> normally, correctly rejects this input as non-halting.
You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which
correctly simulating P which calls it.
*The execution trace of function P() simulated by function H() shows* >>>>>>>> (1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this >>>>>>>> infinitely recursive simulation.
Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not
different.
This proves that H(P,P) correctly predicts that its correctly simulated
input would never terminate normally.
As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is
is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.It is an easily verified fact that H(P,P) correctly simulates its input >>>> to everyone having sufficient knowledge of the x86 assembly languageWelcome back.
When H(P,P) correctly simulates its input this is the ultimate measure >>>>>> of the actual behavior specified by this input.
No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
which currently seems to be hardy no one besides me. Back in the 1986
when I began my career about 10% of all programmers had familiarity
with the x86 language. This is the language that MSDOS and versions
of MS Windows prior to Windows NT were written in. Windows NT switched >>>> to mostly C/C++.
The 23 emails that I had with a leading computer scientist made that
very clear. Because of this I re-framed my explanation so that any
expert C programmer that totally understands infinite recursion would be >>>> able to see that infinitely nested simulation is essentially the same
thing.
The next important point that requires one to have top software
engineering skills that allowed me to transform H into a pure thus
computable function: Infinitely nested simulation can be detected the
first time that the simulated input calls the simulator with its same
arguments. Infinite recursion requires seeing two such calls in a row. >>>> This change allowed me to discard the need for static local memory and >>>> do everything in local memory.
No this a very long standing misconception. H is required to determine >>>> whether or not its correct simulation of its input would ever reach the >>>> normal termination of this input.A security guard at the front door is only required to validate people >>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
This same security guard is not required to validate people coming in >>>>>> the back door the direct execution of P(P). Unless a computation is >>>>>> specified as an actual input to H it is not in the domain of the
computable function that H implements.
H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
Since no one ever bothered to think through the application of a
simulating halt decider to the HP's impossible inputs they always stated >>>> the requirements incorrectly never realizing their mistake.
A halt decider must compute the mapping from its inputs to an accept or >>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
In the H/P concrete example it is easily proven that the actual behavior >>>> of the actual input to H(P,P) is not the behavior of the directly
executed P(P). The best proof of this is the x86 execution trace of each >>>> that precisely corresponds to what the x86 source code of P specifies. >>>>
From this is is obvious that the correctly simulated P cannot possibly >>>> terminate normally and the executed P(P) halts.
Those lacking knowledge of the x86 language can understand that this
first halt deciding principle is necessarily correct:
*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or >>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
And this second halt deciding principle follows from the first one by
logical necessity.
*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until >>>> it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.
This is a misconception that can only be true if the halt decider is
If a program M would halt given input X, then H(M, X) is required to be non-zero.
If a program M would not halt given input X, then H(M, X) is required to be zero.
required to report on something besides the actual behavior of its
actual input.
The ultimate measure of the actual behavior of the actual input is the >>>> provable correct simulation of this input by the simulating halt decider. >>>>
To assume that this behavior must be the same as the directly executed >>>> P(P) after it has been conclusively proven to not be that same as an
established fact is at least a little nutty.
That people unequivocally state that I must be wrong entirely on the
basis that they lack sufficient understanding of the x86 language to
understand my proof is a worst case example of the ad ignorantiam logic >>>> error.
If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X)
the function and input we are talking about.
Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not
Because that would require that a halt decider must sometimes make its--
To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
A) H(P, P) returns 0 and P(P) terminates.
B) H(P, P) returns non-zero and P(P) terminates.
C) H(P, P) returns 0 and P(P) does not terminate.
D) H(P, P) returns non-zero and P(P) does not terminate.
B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
A1) H(P, P) returns 0 because it correctly determines that the input >>>>>> that it correctly simulates would never terminate normally.
No, that is not a correct answer. You have said numerous times that P(P) terminates.
A2) Directly executed P(P) halts because of (A)
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Halting problem https://en.wikipedia.org/wiki/Halting_problem
...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.
The property that an arbitrary program P will finish running or not is determined by
running P as an independent program
halt status decision on a basis other than the actual behavior of its
actual input that long standing misconception has been refuted.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Because we often encountered a problem to know whether a 'independent' running
program P will halt or not, therefore, this is an interested problem.
We don't have such a problem asking H(P,P), the P 'simulated' by H halt or not.
On 7/13/2022 1:03 PM, Paul N wrote:
On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
On 7/13/2022 10:02 AM, Paul N wrote:
Firstly, this subject matter is not relevant in comp.lang.c orWelcome back.
comp.lang.c++, so please stop posting any of it there. If I see any
more posts of this sort in either of those newsgroups I shall assume
that, regardless of the merits of your argument, you are very rude.
On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
*CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
I rewrote this question so that a software engineer of ordinary skill >>>>> can easily verify that the simulated P does call H in what is
essentially infinite recursion. **This simplification is the result of >>>>> an extensive review (23 emails) by a leading computer scientist
over the
weekend.**
Does H(P,P) correctly determine the halt status of the halting
problem's
pathological input?
The following H and P have the above specified pathological
relationship
to each other.
typedef void (*ptr)();
int H(ptr p, ptr i);
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its
simulation on
this basis and rejects this input as non-halting.
Thus it is an incorrect assessment, as we'll see below.
*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an
accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
Again, emphasis on "actual behaviour".
*Then (by logical necessity) this is understood to implement that*
Every simulating halt decider that correctly simulates its input until >>>>> it correctly predicts that this simulated input would never terminate >>>>> normally, correctly rejects this input as non-halting.
You have stated numerous times that a program that "correctly
simulates its input" can have different results. Thus it is not
clear what you mean by the phrase. There is no logical necessity to
accept anything about a correct simulation which does not simulate
correctly.
*The execution trace of function P() simulated by function H() shows* >>>>> (1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this
infinitely recursive simulation.
Ah, but there are instructions in H which escape from the infinite
recursion. You've said numerous times that there are. See only a few
lines up. If you pretend that they are somehow not there, you are
not correctly simulating H and hence not correctly simulating P
which calls it.
This proves that H(P,P) correctly predicts that its correctly
simulated
input would never terminate normally.
As you've said above, in capitals and with asterisks, changing the
subject is not a rebuttal. You're trying to change the subject from
the actual behaviour of P(P) to some sort of "simulated" behaviour
of P(P) which you have said yourself is different.
When H(P,P) correctly simulates its input this is the ultimate measure
of the actual behavior specified by this input.
No, the actual behaviour is the actual behaviour! If H correctlky
simulates this behaviour then it too will also be the same, but you
have siad numerous times that it does not correctly simulate the
behavoutr.
It is an easily verified fact that H(P,P) correctly simulates its input
to everyone having sufficient knowledge of the x86 assembly language
which currently seems to be hardy no one besides me. Back in the 1986
when I began my career about 10% of all programmers had familiarity
with the x86 language. This is the language that MSDOS and versions
of MS Windows prior to Windows NT were written in. Windows NT switched
to mostly C/C++.
The 23 emails that I had with a leading computer scientist made that
very clear. Because of this I re-framed my explanation so that any
expert C programmer that totally understands infinite recursion would be
able to see that infinitely nested simulation is essentially the same
thing.
The next important point that requires one to have top software
engineering skills that allowed me to transform H into a pure thus
computable function: Infinitely nested simulation can be detected the
first time that the simulated input calls the simulator with its same arguments. Infinite recursion requires seeing two such calls in a row.
This change allowed me to discard the need for static local memory and
do everything in local memory.
A security guard at the front door is only required to validate people
coming in the front door the actual behavior of the actual input to
H(P,P).
This same security guard is not required to validate people coming in
the back door the direct execution of P(P). Unless a computation is
specified as an actual input to H it is not in the domain of the
computable function that H implements.
H takes two arguments. The first is a program to be considered and the
second is the input that could be supplied to that program. H is
required to decide, correctly, whether the program would halt given
that input, ie whether M(X) would halt.
No this a very long standing misconception. H is required to determine whether or not its correct simulation of its input would ever reach the normal termination of this input.
Since no one ever bothered to think through the application of a
simulating halt decider to the HP's impossible inputs they always stated
the requirements incorrectly never realizing their mistake.
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
In the H/P concrete example it is easily proven that the actual behavior
of the actual input to H(P,P) is not the behavior of the directly
executed P(P). The best proof of this is the x86 execution trace of each
that precisely corresponds to what the x86 source code of P specifies.
From this is is obvious that the correctly simulated P cannot possibly terminate normally and the executed P(P) halts.
Those lacking knowledge of the x86 language can understand that this
first halt deciding principle is necessarily correct:
*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
And this second halt deciding principle follows from the first one by
logical necessity.
*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate normally, correctly rejects this input as non-halting.
If a program M would halt given input X, then H(M, X) is required to
be non-zero.
If a program M would not halt given input X, then H(M, X) is required
to be zero.
This is a misconception that can only be true if the halt decider is
required to report on something besides the actual behavior of its
actual input.
The ultimate measure of the actual behavior of the actual input is the provable correct simulation of this input by the simulating halt decider.
To assume that this behavior must be the same as the directly executed
P(P) after it has been conclusively proven to not be that same as an established fact is at least a little nutty.
That people unequivocally state that I must be wrong entirely on the
basis that they lack sufficient understanding of the x86 language to understand my proof is a worst case example of the ad ignorantiam logic error.
If for some combination M, X the function H(M, X) gives the wrong
answer, then it is not a halt decider. If particular, if H(M, X) = 0
but M(X) does halt, then the answer is wrong. You can't get out of it
by arguing that M(X) is "direct" and H(M, X) is a "correct
simulation", whatever that might mean. The answer needs to relate to
the actual behaviour, as you yourself have said numerous times.
Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does
not halt, H(P, P) is required to be zero. Anything else is the wrong
answer.
When we calculate H(P, P), we are supplying P as the first argument
and so P is specified as an actual input to H. And we are interested
in the actual behaviour of P, the actual input. There is no "back
door" by which you can say that P(P) is not the function and input we
are talking about.
To summarise, if H(P, P) terminates (which you have never denied),
then there are at most four possibilities:
A) H(P, P) returns 0 and P(P) terminates.
B) H(P, P) returns non-zero and P(P) terminates.
C) H(P, P) returns 0 and P(P) does not terminate.
D) H(P, P) returns non-zero and P(P) does not terminate.
B and C are clearly not possible from the definition of P. In A and
D, H produces the wrong answer.
A1) H(P, P) returns 0 because it correctly determines that the input
that it correctly simulates would never terminate normally.
No, that is not a correct answer. You have said numerous times that
P(P) terminates.
A2) Directly executed P(P) halts because of (A)
On 7/13/2022 4:11 PM, wij wrote:
On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:
On 7/13/2022 3:47 PM, wij wrote:
On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:Because that would require that a halt decider must sometimes make its
On 7/13/2022 1:03 PM, Paul N wrote:
On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:It is an easily verified fact that H(P,P) correctly simulates its
On 7/13/2022 10:02 AM, Paul N wrote:
Firstly, this subject matter is not relevant in comp.lang.c or >>>>>>>> comp.lang.c++, so please stop posting any of it there. If I see >>>>>>>> any more posts of this sort in either of those newsgroups IWelcome back.
shall assume that, regardless of the merits of your argument,
you are very rude.
On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote: >>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
I rewrote this question so that a software engineer of ordinary >>>>>>>>> skill
can easily verify that the simulated P does call H in what is >>>>>>>>> essentially infinite recursion. **This simplification is the >>>>>>>>> result of
an extensive review (23 emails) by a leading computer scientist >>>>>>>>> over the
weekend.**
Does H(P,P) correctly determine the halt status of the halting >>>>>>>>> problem's
pathological input?
The following H and P have the above specified pathological
relationship
to each other.
typedef void (*ptr)();
int H(ptr p, ptr i);
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Simulating halt decider H detects that its simulated input is >>>>>>>>> essentially calling H in infinite recursion. H aborts its
simulation on
this basis and rejects this input as non-halting.
Thus it is an incorrect assessment, as we'll see below.
*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an >>>>>>>>> accept or
reject state on the basis of the actual behavior that is actually >>>>>>>>> specified by these inputs.
Again, emphasis on "actual behaviour".
*Then (by logical necessity) this is understood to implement that* >>>>>>>>> Every simulating halt decider that correctly simulates its
input until
it correctly predicts that this simulated input would never
terminate
normally, correctly rejects this input as non-halting.
You have stated numerous times that a program that "correctly
simulates its input" can have different results. Thus it is not >>>>>>>> clear what you mean by the phrase. There is no logical necessity >>>>>>>> to accept anything about a correct simulation which does not
simulate correctly.
*The execution trace of function P() simulated by function H() >>>>>>>>> shows*
(1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this >>>>>>>>> infinitely recursive simulation.
Ah, but there are instructions in H which escape from the
infinite recursion. You've said numerous times that there are. >>>>>>>> See only a few lines up. If you pretend that they are somehow
not there, you are not correctly simulating H and hence not
correctly simulating P which calls it.
This proves that H(P,P) correctly predicts that its correctly >>>>>>>>> simulated
input would never terminate normally.
As you've said above, in capitals and with asterisks, changing >>>>>>>> the subject is not a rebuttal. You're trying to change the
subject from the actual behaviour of P(P) to some sort of
"simulated" behaviour of P(P) which you have said yourself is
different.
When H(P,P) correctly simulates its input this is the ultimate
measure
of the actual behavior specified by this input.
No, the actual behaviour is the actual behaviour! If H correctlky
simulates this behaviour then it too will also be the same, but
you have siad numerous times that it does not correctly simulate
the behavoutr.
input
to everyone having sufficient knowledge of the x86 assembly language >>>>> which currently seems to be hardy no one besides me. Back in the 1986 >>>>> when I began my career about 10% of all programmers had familiarity
with the x86 language. This is the language that MSDOS and versions
of MS Windows prior to Windows NT were written in. Windows NT switched >>>>> to mostly C/C++.
The 23 emails that I had with a leading computer scientist made that >>>>> very clear. Because of this I re-framed my explanation so that any
expert C programmer that totally understands infinite recursion
would be
able to see that infinitely nested simulation is essentially the same >>>>> thing.
The next important point that requires one to have top software
engineering skills that allowed me to transform H into a pure thus
computable function: Infinitely nested simulation can be detected the >>>>> first time that the simulated input calls the simulator with its same >>>>> arguments. Infinite recursion requires seeing two such calls in a row. >>>>> This change allowed me to discard the need for static local memory and >>>>> do everything in local memory.
No this a very long standing misconception. H is required to determine >>>>> whether or not its correct simulation of its input would ever reachA security guard at the front door is only required to validate
people
coming in the front door the actual behavior of the actual input >>>>>>> to H(P,P).
This same security guard is not required to validate people
coming in
the back door the direct execution of P(P). Unless a computation is >>>>>>> specified as an actual input to H it is not in the domain of the >>>>>>> computable function that H implements.
H takes two arguments. The first is a program to be considered and >>>>>> the second is the input that could be supplied to that program. H
is required to decide, correctly, whether the program would halt
given that input, ie whether M(X) would halt.
the
normal termination of this input.
Since no one ever bothered to think through the application of a
simulating halt decider to the HP's impossible inputs they always
stated
the requirements incorrectly never realizing their mistake.
A halt decider must compute the mapping from its inputs to an
accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
In the H/P concrete example it is easily proven that the actual
behavior
of the actual input to H(P,P) is not the behavior of the directly
executed P(P). The best proof of this is the x86 execution trace of
each
that precisely corresponds to what the x86 source code of P specifies. >>>>>
From this is is obvious that the correctly simulated P cannot
possibly
terminate normally and the executed P(P) halts.
Those lacking knowledge of the x86 language can understand that this >>>>> first halt deciding principle is necessarily correct:
*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an
accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
And this second halt deciding principle follows from the first one by >>>>> logical necessity.
*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until >>>>> it correctly predicts that this simulated input would never terminate >>>>> normally, correctly rejects this input as non-halting.
This is a misconception that can only be true if the halt decider is >>>>> required to report on something besides the actual behavior of its
If a program M would halt given input X, then H(M, X) is required
to be non-zero.
If a program M would not halt given input X, then H(M, X) is
required to be zero.
actual input.
The ultimate measure of the actual behavior of the actual input is the >>>>> provable correct simulation of this input by the simulating halt
decider.
To assume that this behavior must be the same as the directly executed >>>>> P(P) after it has been conclusively proven to not be that same as an >>>>> established fact is at least a little nutty.
That people unequivocally state that I must be wrong entirely on the >>>>> basis that they lack sufficient understanding of the x86 language to >>>>> understand my proof is a worst case example of the ad ignorantiam
logic
error.
If for some combination M, X the function H(M, X) gives the wrong--
answer, then it is not a halt decider. If particular, if H(M, X) = >>>>>> 0 but M(X) does halt, then the answer is wrong. You can't get out
of it by arguing that M(X) is "direct" and H(M, X) is a "correct
simulation", whatever that might mean. The answer needs to relate
to the actual behaviour, as you yourself have said numerous times. >>>>>>
Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P)
does not halt, H(P, P) is required to be zero. Anything else is
the wrong answer.
When we calculate H(P, P), we are supplying P as the first
argument and so P is specified as an actual input to H. And we are >>>>>> interested in the actual behaviour of P, the actual input. There
is no "back door" by which you can say that P(P) is not the
function and input we are talking about.
To summarise, if H(P, P) terminates (which you have never
denied), then there are at most four possibilities:
A) H(P, P) returns 0 and P(P) terminates.
B) H(P, P) returns non-zero and P(P) terminates.
C) H(P, P) returns 0 and P(P) does not terminate.
D) H(P, P) returns non-zero and P(P) does not terminate.
B and C are clearly not possible from the definition of P. In A >>>>>>>> and D, H produces the wrong answer.
A1) H(P, P) returns 0 because it correctly determines that the input >>>>>>> that it correctly simulates would never terminate normally.
No, that is not a correct answer. You have said numerous times
that P(P) terminates.
A2) Directly executed P(P) halts because of (A)
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Halting problem https://en.wikipedia.org/wiki/Halting_problem
...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.
The property that an arbitrary program P will finish running or not
is determined by
running P as an independent program
halt status decision on a basis other than the actual behavior of its
actual input that long standing misconception has been refuted.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Because we often encountered a problem to know whether a 'independent'
running
program P will halt or not, therefore, this is an interested problem.
We don't have such a problem asking H(P,P), the P 'simulated' by H
halt or not.
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
Everyone's rebuttal to this is that the halt decider must be a mind
reader and report on the behavior of a computation that only exists in
the minds of the readers and its not the same computation that is
specified by its inputs.
That is goofy and nutty and crazy.
On Friday, 15 July 2022 at 03:22:17 UTC+8, olcott wrote:
...
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Try this main(), tell us the result.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
On Friday, 15 July 2022 at 03:59:24 UTC+8, olcott wrote:
On 7/14/2022 2:36 PM, wij wrote:
On Friday, 15 July 2022 at 03:22:17 UTC+8, olcott wrote:Been there done that many times.
...
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Try this main(), tell us the result.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
If we accept that the behavior of the executed P(P) is the behavior that
H must report on then we are saying that H must report on the behavior
that is not the actual behavior of its actual input.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Are you so impotent and don't know the result of this simple main()?
On Friday, 15 July 2022 at 04:22:49 UTC+8, olcott wrote:
On 7/14/2022 3:16 PM, wij wrote:
On Friday, 15 July 2022 at 03:59:24 UTC+8, olcott wrote:I know the result and posted the result and all of the code and full
On 7/14/2022 2:36 PM, wij wrote:
On Friday, 15 July 2022 at 03:22:17 UTC+8, olcott wrote:Been there done that many times.
...
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Try this main(), tell us the result.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
A halt decider must compute the mapping from its inputs to an accept or >>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
If we accept that the behavior of the executed P(P) is the behavior that >>>> H must report on then we are saying that H must report on the behavior >>>> that is not the actual behavior of its actual input.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Are you so impotent and don't know the result of this simple main()?
execution trace dozens of times. I am skipping ahead and saying why
these results don't matter.
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
I did not say anything, simple asking what the result of this main() is to establish
basic fact of discussion.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
On 7/14/2022 3:16 PM, wij wrote:
On Friday, 15 July 2022 at 03:59:24 UTC+8, olcott wrote:
On 7/14/2022 2:36 PM, wij wrote:
On Friday, 15 July 2022 at 03:22:17 UTC+8, olcott wrote:Been there done that many times.
...
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Try this main(), tell us the result.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
If we accept that the behavior of the executed P(P) is the behavior that >>> H must report on then we are saying that H must report on the behavior
that is not the actual behavior of its actual input.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Are you so impotent and don't know the result of this simple main()?
I know the result and posted the result and all of the code and full execution trace dozens of times. I am skipping ahead and saying why
these results don't matter.
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
On 7/14/2022 2:36 PM, wij wrote:
On Friday, 15 July 2022 at 03:22:17 UTC+8, olcott wrote:
...
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Try this main(), tell us the result.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
Been there done that many times.
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually
specified by these inputs.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
If we accept that the behavior of the executed P(P) is the behavior that
H must report on then we are saying that H must report on the behavior
that is not the actual behavior of its actual input.
*Halting problem proofs refuted on the basis of software engineering* https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
On 7/14/2022 3:27 PM, wij wrote:
On Friday, 15 July 2022 at 04:22:49 UTC+8, olcott wrote:
On 7/14/2022 3:16 PM, wij wrote:
On Friday, 15 July 2022 at 03:59:24 UTC+8, olcott wrote:I know the result and posted the result and all of the code and full
On 7/14/2022 2:36 PM, wij wrote:
On Friday, 15 July 2022 at 03:22:17 UTC+8, olcott wrote:Been there done that many times.
...
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Try this main(), tell us the result.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
A halt decider must compute the mapping from its inputs to an
accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
If we accept that the behavior of the executed P(P) is the behavior
that
H must report on then we are saying that H must report on the behavior >>>>> that is not the actual behavior of its actual input.
*Halting problem proofs refuted on the basis of software engineering* >>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Are you so impotent and don't know the result of this simple main()?
execution trace dozens of times. I am skipping ahead and saying why
these results don't matter.
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
P(P) is not the actual behavior of the actual inputs.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
I did not say anything, simple asking what the result of this main()
is to establish
basic fact of discussion.
int main()
{
Output("Input_Halts = ", H(P, P));
P(P);
}
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
When simulating halt decider H(P,P) simulates its input we can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P).
The above shows that the simulated P cannot possibly terminate normally. Because H can see the same (1)(2)(3) that we see H aborts its simulation
of P and rejects P as non-halting.
P(P) is not the actual behavior of the actual inputs to H(P,P)
P(P) is not the actual behavior of the actual inputs to H(P,P)
P(P) is not the actual behavior of the actual inputs to H(P,P)
P(P) is not the actual behavior of the actual inputs to H(P,P)
If you have enough technical skill you can find the answer to your
question in the code below.
int main()
{
P(P);
}
_P()
[000013b4](01) 55 push ebp
[000013b5](02) 8bec mov ebp,esp
[000013b7](01) 51 push ecx
[000013b8](03) 8b4508 mov eax,[ebp+08]
[000013bb](01) 50 push eax
[000013bc](03) 8b4d08 mov ecx,[ebp+08]
[000013bf](01) 51 push ecx
[000013c0](05) e82ffdffff call 000010f4
[000013c5](03) 83c408 add esp,+08
[000013c8](03) 8945fc mov [ebp-04],eax
[000013cb](04) 837dfc00 cmp dword [ebp-04],+00
[000013cf](02) 7402 jz 000013d3
[000013d1](02) ebfe jmp 000013d1
[000013d3](02) 8be5 mov esp,ebp
[000013d5](01) 5d pop ebp
[000013d6](01) c3 ret
Size in bytes:(0035) [000013d6]
_main()
[000013e4](01) 55 push ebp
[000013e5](02) 8bec mov ebp,esp
[000013e7](05) 68b4130000 push 000013b4
[000013ec](05) e8c3ffffff call 000013b4
[000013f1](03) 83c404 add esp,+04
[000013f4](02) 33c0 xor eax,eax
[000013f6](01) 5d pop ebp
[000013f7](01) c3 ret
Size in bytes:(0020) [000013f7]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000013e4][0010230a][00000000] 55 push ebp [000013e5][0010230a][00000000] 8bec mov ebp,esp [000013e7][00102306][000013b4] 68b4130000 push 000013b4 [000013ec][00102302][000013f1] e8c3ffffff call 000013b4 [000013b4][001022fe][0010230a] 55 push ebp [000013b5][001022fe][0010230a] 8bec mov ebp,esp [000013b7][001022fa][00000000] 51 push ecx [000013b8][001022fa][00000000] 8b4508 mov eax,[ebp+08] [000013bb][001022f6][000013b4] 50 push eax [000013bc][001022f6][000013b4] 8b4d08 mov ecx,[ebp+08] [000013bf][001022f2][000013b4] 51 push ecx [000013c0][001022ee][000013c5] e82ffdffff call 000010f4
H: Begin Simulation Execution Trace Stored at:1123b6
Address_of_H:10f4
[000013b4][001123a2][001123a6] 55 push ebp [000013b5][001123a2][001123a6] 8bec mov ebp,esp [000013b7][0011239e][00102372] 51 push ecx [000013b8][0011239e][00102372] 8b4508 mov eax,[ebp+08] [000013bb][0011239a][000013b4] 50 push eax [000013bc][0011239a][000013b4] 8b4d08 mov ecx,[ebp+08] [000013bf][00112396][000013b4] 51 push ecx [000013c0][00112392][000013c5] e82ffdffff call 000010f4
H: Infinitely Recursive Simulation Detected Simulation Stopped
[000013c5][001022fa][00000000] 83c408 add esp,+08 [000013c8][001022fa][00000000] 8945fc mov [ebp-04],eax [000013cb][001022fa][00000000] 837dfc00 cmp dword [ebp-04],+00 [000013cf][001022fa][00000000] 7402 jz 000013d3 [000013d3][001022fe][0010230a] 8be5 mov esp,ebp [000013d5][00102302][000013f1] 5d pop ebp [000013d6][00102306][000013b4] c3 ret [000013f1][0010230a][00000000] 83c404 add esp,+04 [000013f4][0010230a][00000000] 33c0 xor eax,eax [000013f6][0010230e][00000018] 5d pop ebp [000013f7][00102312][00000000] c3 ret
Number of Instructions Executed(998) == 15 Pages
On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:argument, you are very rude.
On 7/15/2022 7:34 AM, Paul N wrote:
On Thursday, July 14, 2022 at 8:56:21 PM UTC+1, olcott wrote:
On 7/14/2022 6:42 AM, Paul N wrote:
On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
On 7/13/2022 1:03 PM, Paul N wrote:
On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
On 7/13/2022 10:02 AM, Paul N wrote:
Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your
does not simulate correctly.
I see you have now started a new thread on this very subject in both comp.lang.c and comp.lang.c++. You clearly are very rude.
On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote: >>>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
I rewrote this question so that a software engineer of ordinary skill
can easily verify that the simulated P does call H in what is >>>>>>>>>> essentially infinite recursion. **This simplification is the result of
an extensive review (23 emails) by a leading computer scientist over the
weekend.**
Does H(P,P) correctly determine the halt status of the halting problem's
pathological input?
The following H and P have the above specified pathological relationship
to each other.
typedef void (*ptr)();
int H(ptr p, ptr i);
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
Simulating halt decider H detects that its simulated input is >>>>>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
this basis and rejects this input as non-halting.
Thus it is an incorrect assessment, as we'll see below.
*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually >>>>>>>>>> specified by these inputs.
Again, emphasis on "actual behaviour".
*Then (by logical necessity) this is understood to implement that* >>>>>>>>>> Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.
You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which
correctly simulating P which calls it.
*The execution trace of function P() simulated by function H() shows*
(1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this >>>>>>>>>> infinitely recursive simulation.
Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not
different.
This proves that H(P,P) correctly predicts that its correctly simulated
input would never terminate normally.
As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is
saying why you were wrong, and you saying that they didn't understand?The latest rewrite of my paper (initially written as a reply to you) can >>>> be fully understood at the C level with no need to have any access toIt is an easily verified fact that H(P,P) correctly simulates its input >>>>>> to everyone having sufficient knowledge of the x86 assembly language >>>>>> which currently seems to be hardy no one besides me. Back in the 1986 >>>>>> when I began my career about 10% of all programmers had familiarity >>>>>> with the x86 language. This is the language that MSDOS and versions >>>>>> of MS Windows prior to Windows NT were written in. Windows NT switched >>>>>> to mostly C/C++.Welcome back.
When H(P,P) correctly simulates its input this is the ultimate measure >>>>>>>> of the actual behavior specified by this input.
No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.
No it is not. Firstly, you have never posted the code to H so of course we can't verify it.
the source-code of H. I will publish all the the source-code very soon, >>>> yet not until after my work has been validated.
The source-code is correct and complete yet must be refactored to clean >>>> it up before publication.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.This is also much more clearly shown in the rewrite of my paper that I >>>> did a few minutes ago. It can now be seen at the C level that the
simulation of the input to H(P,P) is correct.
It was very easy to see that the simulation of the input to H(P,P) is
correct by simply matching the execution trace of the simulated P to its >>>> x86 source code. I annotated the x86 source-code to make this much
easier for C programmers. I explain line-by-line exactly how the x86
code corresponds to its C source.
The 23 emails that I had with a leading computer scientist made that >>>>>> very clear. Because of this I re-framed my explanation so that any >>>>>> expert C programmer that totally understands infinite recursion would be >>>>>> able to see that infinitely nested simulation is essentially the same >>>>>> thing.
It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them
At the time my proof was only written in x86 assembly language and heThis would be disrespecting his privacy. The point is that I now have an >>>> excellent measure that I have improved my words so much that my work is >>>> not simply rejected out-of-hand without review even by leading computer >>>> scientists.
A halt decider must compute the mapping from its inputs to an accept or >>>> reject state on the basis of the actual behavior that is actuallyThe next important point that requires one to have top software
engineering skills that allowed me to transform H into a pure thus >>>>>> computable function: Infinitely nested simulation can be detected the >>>>>> first time that the simulated input calls the simulator with its same >>>>>> arguments. Infinite recursion requires seeing two such calls in a row. >>>>>> This change allowed me to discard the need for static local memory and >>>>>> do everything in local memory.
A security guard at the front door is only required to validate people >>>>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
This same security guard is not required to validate people coming in >>>>>>>> the back door the direct execution of P(P). Unless a computation is >>>>>>>> specified as an actual input to H it is not in the domain of the >>>>>>>> computable function that H implements.
H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
No this a very long standing misconception. H is required to determine >>>>>> whether or not its correct simulation of its input would ever reach the >>>>>> normal termination of this input.
No, what I have said is right. You are the one bringing in ideas about simulation.
specified by these inputs.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
If we accept that the behavior of the executed P(P) is the behavior that >>>> H must report on then we are saying that H must report on the behavior >>>> that is not the actual behavior of its actual input.
In the latest revision to my paper it is much more obvious that thatSince no one ever bothered to think through the application of a
simulating halt decider to the HP's impossible inputs they always stated >>>>>> the requirements incorrectly never realizing their mistake.
A halt decider must compute the mapping from its inputs to an accept or >>>>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
Yes.
In the H/P concrete example it is easily proven that the actual behavior >>>>>> of the actual input to H(P,P) is not the behavior of the directlyYou've included the word "actual" twice in that sentence and yet you still seem to think that the actual behaviour is not what really happens. How many "actual"s do you need?
executed P(P). The best proof of this is the x86 execution trace of each >>>>>> that precisely corresponds to what the x86 source code of P specifies. >>>>>
From this is is obvious that the correctly simulated P cannot possibly >>>>>> terminate normally and the executed P(P) halts.
If P(P) halts then a correct simulation of it will also halt.
actual behavior of the actual input is not the same as the behavior of >>>> the directly executed P(P).
Did your expert in any way agree that the "actual behaviour" is different from the behaviour when P(P) is directly executed? Have you found anyone at all who agrees with you on this point?
had no knowledge of x86 assembly language Now it can be understood in C.
That would require H to be a mind reader and report on something other
If H is required to report on the behavior of the direct execution of
P(P) this forces H to report on something besides the actual behavior of >>>> its actual input.
Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?
than the actual behavior of its actual input.
There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.
I spent about three hours in my reply to you, how much time did you
spend three minutes?
rewritten a few minutes ago to be much easier to understand:
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
On 7/16/2022 10:54 AM, Mike Terry wrote:
On 16/07/2022 12:23, Paul N wrote:
On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
On 7/15/2022 11:17 AM, Paul N wrote:
On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
On 7/15/2022 7:34 AM, Paul N wrote:
Do you accept that if H were required to report on the behaviour >>>>>>> of the direct execution of P(P) then it would not be possible to >>>>>>> write such an H?That would require H to be a mind reader and report on something
other
than the actual behavior of its actual input.
There's no mind involved. If P is a computer program then P(P) is
perfectly well defined. Either H can work out what it will do, or
it can't.
You haven't said in what way a "mind" is involved in the direct
execution of P(P).
It is like you ask your wife to go to the store and buy "a dozen eggs" >>>> fully expecting her to understand that what you mean by "a dozen eggs" >>>> is {a half gallon of grape juice}. When she gets back with the eggs you >>>> ask her where is the grape juice?
No, you are the one who is twisting the meaning of words. When I talk
about the actual behaviour of P(P) I mean what actually happens when
P(P) is executed. That's what the words "actual" and "behaviour" mean.
You are using the words "actual behavior" to mean something else
which is clearly different. It seems to relate to some sort of
simulator, which you simultaneously claim to be correct while
acknowledging it produces different results from executing P(P)
directly.
Can you tell us if that "actual behavior" does actually happen in any
circumstances, or is it (despite the name) just a theoretical thing?
A halt decider must compute the mapping from its inputs to an accept or >>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
Yes, where the actual behaviour is the behaviour that actually happens.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
Yes, if the simulation is correct. You've insisted numerous times
that your own simulator is incorrect.
PO's simulation is correct at the individual instruction level. His H
steps the simulation forward a number of steps, and each of those
steps exactly matches the P(P) calculation steps. At some point
before the final P RET instruction, his H decides to stop stepping
(for whatever reason), so H's simulation is *incomplete*.
This review was very helpful thanks.
That is the only sense in which P(P) and "the simulated input to
H(P,P)" differ - H simply stops simulating before P(P) terminates.
*If you carefully examine this you will see that the simulated P cannot* *possibly ever terminate normally by reaching its "return" instruction*
typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
When simulating halt decider H(P,P) simulates its input it can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.
The above shows that the simulated P cannot possibly (reachs it “return” instruction and) terminate normally. H(P,P) simulates its input then P
calls H(P,P) to simulate itself again. When H sees that this otherwise infinitely nested simulation would never end it aborts its simulation of
P and rejects P as non-halting.
On 16/07/2022 12:23, Paul N wrote:
On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
On 7/15/2022 11:17 AM, Paul N wrote:
On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
On 7/15/2022 7:34 AM, Paul N wrote:
Do you accept that if H were required to report on the behaviourThat would require H to be a mind reader and report on something other >>>>> than the actual behavior of its actual input.
of the direct execution of P(P) then it would not be possible to
write such an H?
There's no mind involved. If P is a computer program then P(P) is
perfectly well defined. Either H can work out what it will do, or it
can't.
You haven't said in what way a "mind" is involved in the direct
execution of P(P).
It is like you ask your wife to go to the store and buy "a dozen eggs"
fully expecting her to understand that what you mean by "a dozen eggs"
is {a half gallon of grape juice}. When she gets back with the eggs you
ask her where is the grape juice?
No, you are the one who is twisting the meaning of words. When I talk
about the actual behaviour of P(P) I mean what actually happens when
P(P) is executed. That's what the words "actual" and "behaviour" mean.
You are using the words "actual behavior" to mean something else which
is clearly different. It seems to relate to some sort of simulator,
which you simultaneously claim to be correct while acknowledging it
produces different results from executing P(P) directly.
Can you tell us if that "actual behavior" does actually happen in any
circumstances, or is it (despite the name) just a theoretical thing?
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
Yes, where the actual behaviour is the behaviour that actually happens.
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
Yes, if the simulation is correct. You've insisted numerous times that
your own simulator is incorrect.
PO's simulation is correct at the individual instruction level. His H
steps the simulation forward a number of steps, and each of those steps exactly matches the P(P) calculation steps. At some point before the
final P RET instruction, his H decides to stop stepping (for whatever reason), so H's simulation is *incomplete*.
That is the only sense in which P(P) and "the simulated input to H(P,P)" differ - H simply stops simulating before P(P) terminates.
On 7/16/22 8:18 PM, olcott wrote:
On 7/16/2022 10:54 AM, Mike Terry wrote:
On 16/07/2022 12:23, Paul N wrote:
On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
On 7/15/2022 11:17 AM, Paul N wrote:
On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
On 7/15/2022 7:34 AM, Paul N wrote:
Do you accept that if H were required to report on the behaviour >>>>>>>> of the direct execution of P(P) then it would not be possible to >>>>>>>> write such an H?That would require H to be a mind reader and report on something >>>>>>> other
than the actual behavior of its actual input.
There's no mind involved. If P is a computer program then P(P) is
perfectly well defined. Either H can work out what it will do, or
it can't.
You haven't said in what way a "mind" is involved in the direct
execution of P(P).
It is like you ask your wife to go to the store and buy "a dozen eggs" >>>>> fully expecting her to understand that what you mean by "a dozen eggs" >>>>> is {a half gallon of grape juice}. When she gets back with the eggs
you
ask her where is the grape juice?
No, you are the one who is twisting the meaning of words. When I
talk about the actual behaviour of P(P) I mean what actually happens
when P(P) is executed. That's what the words "actual" and
"behaviour" mean.
You are using the words "actual behavior" to mean something else
which is clearly different. It seems to relate to some sort of
simulator, which you simultaneously claim to be correct while
acknowledging it produces different results from executing P(P)
directly.
Can you tell us if that "actual behavior" does actually happen in
any circumstances, or is it (despite the name) just a theoretical
thing?
A halt decider must compute the mapping from its inputs to an
accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
Yes, where the actual behaviour is the behaviour that actually happens. >>>>
It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.
Yes, if the simulation is correct. You've insisted numerous times
that your own simulator is incorrect.
PO's simulation is correct at the individual instruction level. His
H steps the simulation forward a number of steps, and each of those
steps exactly matches the P(P) calculation steps. At some point
before the final P RET instruction, his H decides to stop stepping
(for whatever reason), so H's simulation is *incomplete*.
This review was very helpful thanks.
That is the only sense in which P(P) and "the simulated input to
H(P,P)" differ - H simply stops simulating before P(P) terminates.
*If you carefully examine this you will see that the simulated P cannot*
*possibly ever terminate normally by reaching its "return" instruction*
Which just doesn't matter as Halting is defined based on the actual
machine and not a simulation.
On 7/16/2022 2:28 PM, Mike Terry wrote:
On 16/07/2022 17:40, Richard Damon wrote:
But "incomplete" is incorrect if your logic assumes that the
simulation not reaching the final state PROVES non-halting.
I don't believe PO thinks that, irrespective of how badly he explains
things. I think he believes that the simulation would never halt
*because his never-halting-abort test matched*, NOT simply as a
consequence of aborting. E.g. he seems to understand that a simulator
that steps 10 steps then stops regardless, does not imply that the
simulated computation does not halt.
Although... he doesn't properly understand what halting means,
Halting means terminating normally by reaching the last "return"
instruction of the C function the last "ret" instruction of the x86 translation of this "C" function or the final state of a Turing machine.
*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.
On 16/07/2022 17:40, Richard Damon wrote:
But "incomplete" is incorrect if your logic assumes that the
simulation not reaching the final state PROVES non-halting.
I don't believe PO thinks that, irrespective of how badly he explains things. I think he believes that the simulation would never halt
*because his never-halting-abort test matched*, NOT simply as a
consequence of aborting. E.g. he seems to understand that a simulator
that steps 10 steps then stops regardless, does not imply that the
simulated computation does not halt.
Although... he doesn't properly understand what halting means,
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 63:45:19 |
| Calls: | 6,690 |
| Files: | 12,226 |
| Messages: | 5,345,649 |