This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm
operating system that was created so that every detail of the halting
problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret" instruction).
Equally obvious is the fact that a partial x86 emulation of this input conclusively proves that its complete x86 emulation would never halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to
H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to
H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to
H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.
/Flibble
http://www.cuboid.me.uk/anw/G12FCO/lect18.htmlAt any given moment as the emulation proceeds, we are in one of not two
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 >>> [00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to
H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >>> [0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret” >>> instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.
/Flibble
It is when a simulating halt decider is assumed.
No one ever bothered to think the otherwise "impossible" input being
analyzed by a simulating halt decider ALL THE WAY THROUGH EVER BEFORE!
On 6/2/2022 1:12 PM, Andy Walker wrote:
http://www.cuboid.me.uk/anw/G12FCO/lect18.htmlAt any given moment as the emulation proceeds, we are in one of not two
but three states: the program has halted, or it is looping, or it is
still running and has not yet entered a loop. It's the third case that
kills us -- we just have to keep going, and wait for one of the other
two things to happen. The trouble is that it may be that neither of them
ever happens -- which is why `it must be in a loop' was in quotes above.
Andy Walker did provide a fundamentally flawed and totally shallow
analysis of an simulating halt decider.
At any given moment as the emulation proceeds,
we are in one of not two but three states:
(a) The program has halted,
(b) It is still running.
(c) IT HAS MATCHED AN INFINITE BEHAVIOR PATTERN
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
The above matches (c) for infinitely nested simulation.
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the
halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never
halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 >>>> [00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to
H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >>>> [0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret” >>>> instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.
/Flibble
It is when a simulating halt decider is assumed.
But you can not assume that an actual simulating Halt Decider actually exists.
On 6/3/2022 7:20 PM, Richard Damon wrote:
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>> halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never >>>>> halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 >>>>> [00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to
H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with >>>>> complete certainty that the emulated P never reaches its final “ret” >>>>> instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5) >>>>>
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether or not >>>> to enter the infinite loop is predicated on an infinite recursion (call >>>> H) that is not present in the Halting Problem proofs you are attempting >>>> to refute.
/Flibble
It is when a simulating halt decider is assumed.
But you can not assume that an actual simulating Halt Decider actually
exists.
I proved that H(P,P)==0 is correct.
On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
On 6/3/2022 7:20 PM, Richard Damon wrote:You've got nested simulations.
I proved that H(P,P)==0 is correct.
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>> halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never >>>>>> halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 >>>>>> [00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to >>>>>> H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with >>>>>> complete certainty that the emulated P never reaches its final “ret” >>>>>> instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5) >>>>>>
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether or not >>>>> to enter the infinite loop is predicated on an infinite recursion (call >>>>> H) that is not present in the Halting Problem proofs you are attempting >>>>> to refute.
/Flibble
It is when a simulating halt decider is assumed.
But you can not assume that an actual simulating Halt Decider actually
exists.
If H detects them as infinitely nested, and aborts, they are no longer infinitely
nested, so it gets the wrong answer (as happens here).
If H doesn't detects them as infinitely nested, and never aborts, H simulates forever, because they are infinitely nested.
Either way, H gets it wrong.
My own view is that you've actually got something interesting here. That isn't
shared by other posters, probably because you've put them off by claims to have
"solved the halting problem", repeated at great length.
On 6/3/22 11:51 PM, olcott wrote:
On 6/3/2022 7:20 PM, Richard Damon wrote:
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please
read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>> halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this
input conclusively proves that its complete x86 emulation would never >>>>>> halt.
Begin Local Halt Decider Simulation Execution Trace Stored
at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to >>>>>> H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its
input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know with >>>>>> complete certainty that the emulated P never reaches its final “ret” >>>>>> instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5) >>>>>>
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether or
not
to enter the infinite loop is predicated on an infinite recursion
(call
H) that is not present in the Halting Problem proofs you are
attempting
to refute.
/Flibble
It is when a simulating halt decider is assumed.
But you can not assume that an actual simulating Halt Decider
actually exists.
I proved that H(P,P)==0 is correct.
No, not for the ACTUAL halting problem.
You have shown that H(P,P) == 0 is correct if the problem is can H
simulate its input to a final state,
not does that input, when actually
run (or correctly simulate by the actual definition of correct
simulation) reach a final state.
On 6/4/2022 5:27 AM, Richard Damon wrote:
On 6/3/22 11:51 PM, olcott wrote:
On 6/3/2022 7:20 PM, Richard Damon wrote:
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please >>>>>>> read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>>> halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt >>>>>>> (meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this >>>>>>> input conclusively proves that its complete x86 emulation would
never
halt.
Begin Local Halt Decider Simulation Execution Trace Stored
at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to >>>>>>> H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its >>>>>>> input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know >>>>>>> with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5) >>>>>>>
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether
or not
to enter the infinite loop is predicated on an infinite recursion
(call
H) that is not present in the Halting Problem proofs you are
attempting
to refute.
/Flibble
It is when a simulating halt decider is assumed.
But you can not assume that an actual simulating Halt Decider
actually exists.
I proved that H(P,P)==0 is correct.
No, not for the ACTUAL halting problem.
You have shown that H(P,P) == 0 is correct if the problem is can H
simulate its input to a final state,
THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
H computes the mapping from its input finite strings to its accept or
reject state on the basis of the actual behavior specified by the actual input as measured by the correct x86 emulation of this input by H.
not does that input, when actually run (or correctly simulate by the
actual definition of correct simulation) reach a final state.
int sum(int x, int y)
{
return x + y;
}
It as is nutty to say that H(P,P) must return a value that does not correspond to its input as it is to expect sum(3,4) to return 23.
On 6/4/2022 5:01 AM, Malcolm McLean wrote:
On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
On 6/3/2022 7:20 PM, Richard Damon wrote:You've got nested simulations.
I proved that H(P,P)==0 is correct.
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please >>>>>>> read the linked paper provided below. This work is based on the
x86utm operating system that was created so that every detail of the >>>>>>> halting problem could be directly examined in C/x86.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
It is totally obvious that the _Infinite_Loop() would never halt >>>>>>> (meaning that it terminates normally by reaching its "ret"
instruction).
Equally obvious is the fact that a partial x86 emulation of this >>>>>>> input conclusively proves that its complete x86 emulation would
never
halt.
Begin Local Halt Decider Simulation Execution Trace Stored
at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to >>>>>>> H(P,P):
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its >>>>>>> input that it must emulate the first seven instructions of P.
Because the seventh instruction repeats this process we can know >>>>>>> with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.
Halting problem undecidability and infinitely nested simulation (V5) >>>>>>>
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
Unfortunately your logic is such that the decision as to whether
or not
to enter the infinite loop is predicated on an infinite recursion
(call
H) that is not present in the Halting Problem proofs you are
attempting
to refute.
/Flibble
It is when a simulating halt decider is assumed.
But you can not assume that an actual simulating Halt Decider actually >>>> exists.
If H detects them as infinitely nested, and aborts, they are no longer
infinitely
nested, so it gets the wrong answer (as happens here).
I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned rebuttal.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In the same way that H0 detects that the complete x86 emulation of _Infinite_Loop() would never reach its final "ret" instruction H(P,P) on
the basis of a partial simulation H(P,P) detects that the complete x86 emulation of its input would never reach its final "ret" instruction.
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
If H doesn't detects them as infinitely nested, and never aborts, H
simulates
forever, because they are infinitely nested.
Either way, H gets it wrong.
So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
as soon _Infinite_Loop() has had its simulation aborted it magically
leaps to its "ret" instruction.
My own view is that you've actually got something interesting here.
That isn't
shared by other posters, probably because you've put them off by
claims to have
"solved the halting problem", repeated at great length.
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm
Thanks, but I need to go watch some paint dry. Maybe next time.
On 6/4/2022 5:01 AM, Malcolm McLean wrote:
On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
On 6/3/2022 7:20 PM, Richard Damon wrote:
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:
You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer
infinitely nested, so it gets the wrong answer (as happens here).
I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned rebuttal.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In the same way that H0 detects .....
.... that the complete x86 emulation of _Infinite_Loop() would never
reach its final "ret" instruction H(P,P) on the basis of a partial
simulation H(P,P) detects that the complete x86 emulation of its input
would never reach its final "ret" instruction.
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
If H doesn't detects them as infinitely nested, and never aborts, H
simulates forever, because they are infinitely nested.
Either way, H gets it wrong.
So you are saying that it is impossible for H0 to correctly detect that _Infinite_Loop() would never reach its final "ret" instruction because
as soon _Infinite_Loop() has had its simulation aborted it magically
leaps to its "ret" instruction.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <NoOne@nowhere.com> wrote:
On 6/4/2022 5:01 AM, Malcolm McLean wrote:
On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
On 6/3/2022 7:20 PM, Richard Damon wrote:
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:
[ .... ]
You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer >>>> infinitely nested, so it gets the wrong answer (as happens here).
I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned >>> rebuttal.
I frequently read what you say. It's dull and repetitive. And wrong.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In the same way that H0 detects .....
We don't know what H0 detects, since its code is secret, and probably
doesn't exist.
.... that the complete x86 emulation of _Infinite_Loop() would never
reach its final "ret" instruction H(P,P) on the basis of a partial
simulation H(P,P) detects that the complete x86 emulation of its input
would never reach its final "ret" instruction.
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Yes. It's dull and repetitive and wrong. If it were correct, you would >> only need to say it once, and it would be accepted and acknowledged by
the experts in this group.
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
In this context, it does.
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
A turing machine runs until it halts. Terminated "normally" has no
meaning.
A Turing machine is said to halt whenever it reaches a configuration for which δ is not defined; this is possible because δ is a partial
function. In fact, we will assume that no transitions are defined for
any final state so the Turing machine will halt whenever it enters a
final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.
When translated into ordinary software engineering terms this means terminated normally. In a C function this means reaching the "ret" instruction.
That is one reason you avoid turing machines. They make things
too clear and well defined, leaving you no room to argue stupidities like
"halting doesn't mean stops running".
The reason that I avoid Turing machines is that 99% of the most
important details cannot be fully expressed or analyzed. After all of
these details are fully understood then it is very easy to apply the
same reasoning to the Linz proof as I have done in my paper.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
[ Followup-To: set ]
In comp.theory olcott <NoOne@nowhere.com> wrote:
On 6/4/2022 5:01 AM, Malcolm McLean wrote:
On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
On 6/3/2022 7:20 PM, Richard Damon wrote:
On 6/3/22 7:56 PM, olcott wrote:
On 6/3/2022 6:35 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <No...@NoWhere.com> wrote:
[ .... ]
You've got nested simulations.
If H detects them as infinitely nested, and aborts, they are no longer
infinitely nested, so it gets the wrong answer (as happens here).
I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned
rebuttal.
I frequently read what you say. It's dull and repetitive. And wrong.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In the same way that H0 detects .....
We don't know what H0 detects, since its code is secret, and probably
doesn't exist.
.... that the complete x86 emulation of _Infinite_Loop() would never
reach its final "ret" instruction H(P,P) on the basis of a partial
simulation H(P,P) detects that the complete x86 emulation of its input
would never reach its final "ret" instruction.
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Yes. It's dull and repetitive and wrong. If it were correct, you would
only need to say it once, and it would be accepted and acknowledged by
the experts in this group.
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
In this context, it does.
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
A turing machine runs until it halts. Terminated "normally" has no
meaning.
That is one reason you avoid turing machines. They make things
too clear and well defined, leaving you no room to argue stupidities like "halting doesn't mean stops running".
Yes, it appears that Linz is using the notation that any unspecified transition is the signal that the machine halts where it is, as opposed
to the notation with a defined set of final states (which have no
transitions specified, and all other states have ALL transitions
specified). These are "equivalent" descriptions in terms of computing
power unless you are playing Turing Golf and scoring based on the "size"
of the Turing Machine.
On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm
Thanks, but I need to go watch some paint dry. Maybe next time.
Until the notion of truth itself is formalized research in artificial >intelligence is hobbled.
A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.
This anchors the basis of Davidson's truth conditional semantics. This >creates the roadmap for artificial intelligence with unlimited potential.
Halting problem undecidability and infinitely nested simulation (V5)
On Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please read >>>> the linked paper provided below. This work is based on the x86utm
Thanks, but I need to go watch some paint dry. Maybe next time.
Until the notion of truth itself is formalized research in artificial
intelligence is hobbled.
A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.
This anchors the basis of Davidson's truth conditional semantics. This
creates the roadmap for artificial intelligence with unlimited potential.
Halting problem undecidability and infinitely nested simulation (V5)
You sound like the output of a simple markov chain chat bot thats been fed some doctorate level CS papers.
On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:
On Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please read >>>>> the linked paper provided below. This work is based on the x86utm
Thanks, but I need to go watch some paint dry. Maybe next time.
Until the notion of truth itself is formalized research in artificial
intelligence is hobbled.
A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.
This anchors the basis of Davidson's truth conditional semantics. This
creates the roadmap for artificial intelligence with unlimited
potential.
Halting problem undecidability and infinitely nested simulation (V5)
You sound like the output of a simple markov chain chat bot thats been
fed
some doctorate level CS papers.
I posted to this group because I have boiled down a key computer science problem into ordinary software engineering in C/x86.
In computability theory, the halting problem is the problem of determining,
from a description of an arbitrary computer program and an input, whether
the program will finish running, or continue to run forever. Alan Turing proved
in 1936 that a general algorithm to solve the halting problem for all possible
program-input pairs cannot exist.
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
#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
Because we can easily see that H(P,P)==0 is correct we can know that the otherwise "impossible" input to the halting problem proofs is correctly rejected as non-halting.
On 05.06.22 22:05, olcott wrote:
On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:What about the opposite: can you make a program that always correctly predicts that another program will halt? It doesn't seem to me that this
On Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:
This post assumes that you already know my work, otherwise please
read
the linked paper provided below. This work is based on the x86utm
Thanks, but I need to go watch some paint dry. Maybe next time.
Until the notion of truth itself is formalized research in artificial
intelligence is hobbled.
A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.
This anchors the basis of Davidson's truth conditional semantics. This >>>> creates the roadmap for artificial intelligence with unlimited
potential.
Halting problem undecidability and infinitely nested simulation (V5)
You sound like the output of a simple markov chain chat bot thats
been fed
some doctorate level CS papers.
I posted to this group because I have boiled down a key computer
science problem into ordinary software engineering in C/x86.
In computability theory, the halting problem is the problem of
determining,
from a description of an arbitrary computer program and an
input, whether
the program will finish running, or continue to run forever.
Alan Turing proved
in 1936 that a general algorithm to solve the halting problem
for all possible
program-input pairs cannot exist.
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
#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >> [0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.
Because we can easily see that H(P,P)==0 is correct we can know that
the otherwise "impossible" input to the halting problem proofs is
correctly rejected as non-halting.
case is included in what you did, but I must admit, computer science is
not my major.
Jeff Barnett <jbb@notatt.com> writes:
On 6/5/2022 5:59 PM, Mike Terry wrote:
The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?
What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.
Credit where it's due... POOP is Richard's. Mine was not as good.
On 6/5/22 9:03 PM, olcott wrote:
On 6/5/2022 7:40 PM, Ben wrote:
Jeff Barnett <jbb@notatt.com> writes:
On 6/5/2022 5:59 PM, Mike Terry wrote:
The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?
What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.
Credit where it's due... POOP is Richard's. Mine was not as good.
That was the initial incorrect rebuttal that claimed the concept of a
simulating halt decider is inherently invalid.
When a simulating halt decider H correctly predicts that its complete
simulation of its input finite string would never reach the final
state of this machine description then H has correctly rejected this
input as non-halting.
No, its based on the fact that you are trying to define the "correct"
answer for H to be something different than what the Halting Problem Requires.
On 06/06/2022 01:24, Jeff Barnett wrote:
On 6/5/2022 5:59 PM, Mike Terry wrote:<..snip..>>>
Sure.
The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?
What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.
But PO didn't invent the concept of (partially) simulating a computation
in order to compute certain properties of that computation! It's been around since Turing's days, and is very useful.
Mike.
On 6/5/2022 7:40 PM, Ben wrote:
Jeff Barnett <jbb@notatt.com> writes:
On 6/5/2022 5:59 PM, Mike Terry wrote:
The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?
What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.
Credit where it's due... POOP is Richard's. Mine was not as good.
That was the initial incorrect rebuttal that claimed the concept of a simulating halt decider is inherently invalid.
When a simulating halt decider H correctly predicts that its complete simulation of its input finite string would never reach the final state
of this machine description then H has correctly rejected this input as non-halting.
On 6/5/2022 8:58 PM, Mike Terry wrote:
On 06/06/2022 01:24, Jeff Barnett wrote:
On 6/5/2022 5:59 PM, Mike Terry wrote:<..snip..>>>
Sure.
The question right now is what you would call a TM which evaluates
the first 10 steps of a computation, and then does something else.
What is it doing while evaluating those 10 steps?
What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.
But PO didn't invent the concept of (partially) simulating a
computation in order to compute certain properties of that
computation! It's been around since Turing's days, and is very useful.
Mike.
That is true. I am apparently the first one that ever thought this
through well enough so that machine descriptions matching the following pattern could be correctly determined to be non-halting:
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
In that a partial simulation does correctly predict the behavior of a complete simulation it can be used to recognize infinite behavior patterns.
On 6/5/2022 8:59 PM, Richard Damon wrote:
On 6/5/22 9:03 PM, olcott wrote:
On 6/5/2022 7:40 PM, Ben wrote:
Jeff Barnett <jbb@notatt.com> writes:
On 6/5/2022 5:59 PM, Mike Terry wrote:
The question right now is what you would call a TM which evaluates >>>>>> the first 10 steps of a computation, and then does something else. >>>>>> What is it doing while evaluating those 10 steps?
What would I call it? POOP! It just goes to show the accuracy and
flexibility of Ben's acronym for any Peter-related concept.
Credit where it's due... POOP is Richard's. Mine was not as good.
That was the initial incorrect rebuttal that claimed the concept of a
simulating halt decider is inherently invalid.
When a simulating halt decider H correctly predicts that its complete
simulation of its input finite string would never reach the final
state of this machine description then H has correctly rejected this
input as non-halting.
No, its based on the fact that you are trying to define the "correct"
answer for H to be something different than what the Halting Problem
Requires.
If that was true then one of these facts wold not be verified:
(1) The relationship between H and P matches the pattern specified below:
(2) H does correctly compute the mapping from the x86 machine code to
its reject state on the basis
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
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 365 |
Nodes: | 16 (2 / 14) |
Uptime: | 25:09:26 |
Calls: | 7,769 |
Files: | 12,905 |
Messages: | 5,749,274 |