On 6/4/22 11:11 AM, olcott 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: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
Right, and for the simulation of H(P,P), that is all that happen
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
_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.
On 6/4/2022 11:11 AM, Richard Damon wrote:
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct simulated. >>>>
_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.
Right, it emulates the first seven instructions,
BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven instructions of
P we know that it will keep doing this every time that H(P,P) is invoked
as long as the simulation continues.
This is the exact same process that H0(Infinite_Loop) correctly
determines that its input specifies infinite behavior.
BRAIN DEAD MORONS believe that infinite behavior can only be correctly recognized after infinite simulation.
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
_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.
Right, it emulates the first seven instructions,
On 6/4/22 12:25 PM, olcott wrote:That is what a brain dead moron (or a despicable liar) would say.
On 6/4/2022 11:11 AM, Richard Damon wrote:
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct
simulated.
_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.
Right, it emulates the first seven instructions,
BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven instructions
of P we know that it will keep doing this every time that H(P,P) is
invoked as long as the simulation continues.
Nope, different invocations of H's so not part of the same trace.
On 6/4/2022 12:15 PM, Richard Damon wrote:
On 6/4/22 12:25 PM, olcott wrote:That is what a brain dead moron (or a despicable liar) would say.
On 6/4/2022 11:11 AM, Richard Damon wrote:
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct
simulated.
_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.
Right, it emulates the first seven instructions,
BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven instructions
of P we know that it will keep doing this every time that H(P,P) is
invoked as long as the simulation continues.
Nope, different invocations of H's so not part of the same trace.
The whole point is whether or not the correct x86 emulation of the
original input would ever reach its final "ret" instruction.
If the answer is "no" because a big red dragon incinerates this input
with its breath of fire then the answer is still "no".
On 6/4/22 1:23 PM, olcott wrote:
On 6/4/2022 12:15 PM, Richard Damon wrote:
On 6/4/22 12:25 PM, olcott wrote:That is what a brain dead moron (or a despicable liar) would say.
On 6/4/2022 11:11 AM, Richard Damon wrote:
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen >>>>>>>
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct
simulated.
_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.
Right, it emulates the first seven instructions,
BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven
instructions of P we know that it will keep doing this every time
that H(P,P) is invoked as long as the simulation continues.
Nope, different invocations of H's so not part of the same trace.
The whole point is whether or not the correct x86 emulation of the
original input would ever reach its final "ret" instruction.
Right, the correct x86 emulation of the ORIGINAL input. The second layer
of simulation is
On 6/4/2022 1:09 PM, Richard Damon wrote:
On 6/4/22 1:23 PM, olcott wrote:
On 6/4/2022 12:15 PM, Richard Damon wrote:
On 6/4/22 12:25 PM, olcott wrote:That is what a brain dead moron (or a despicable liar) would say.
On 6/4/2022 11:11 AM, Richard Damon wrote:
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen >>>>>>>>
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct
simulated.
_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.
Right, it emulates the first seven instructions,
BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven
instructions of P we know that it will keep doing this every time
that H(P,P) is invoked as long as the simulation continues.
Nope, different invocations of H's so not part of the same trace.
The whole point is whether or not the correct x86 emulation of the
original input would ever reach its final "ret" instruction.
Right, the correct x86 emulation of the ORIGINAL input. The second
layer of simulation is
invoked in the same execution chain that invokes the first layer and is
thus a subordinate aspect of this first emulation.
[ 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".
On 6/4/22 2:14 PM, olcott wrote:
On 6/4/2022 1:09 PM, Richard Damon wrote:
On 6/4/22 1:23 PM, olcott wrote:
On 6/4/2022 12:15 PM, Richard Damon wrote:
On 6/4/22 12:25 PM, olcott wrote:That is what a brain dead moron (or a despicable liar) would say.
On 6/4/2022 11:11 AM, Richard Damon wrote:
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen >>>>>>>>>
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct >>>>>>>>> simulated.
_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.
Right, it emulates the first seven instructions,
BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven
instructions of P we know that it will keep doing this every time
that H(P,P) is invoked as long as the simulation continues.
Nope, different invocations of H's so not part of the same trace.
The whole point is whether or not the correct x86 emulation of the
original input would ever reach its final "ret" instruction.
Right, the correct x86 emulation of the ORIGINAL input. The second
layer of simulation is
invoked in the same execution chain that invokes the first layer and
is thus a subordinate aspect of this first emulation.
Nope, the execution of that is NOT part of the actual execution trace of
the original input.
On 6/4/2022 1:31 PM, Richard Damon wrote:
On 6/4/22 2:14 PM, olcott wrote:
On 6/4/2022 1:09 PM, Richard Damon wrote:
On 6/4/22 1:23 PM, olcott wrote:
On 6/4/2022 12:15 PM, Richard Damon wrote:
On 6/4/22 12:25 PM, olcott wrote:That is what a brain dead moron (or a despicable liar) would say.
On 6/4/2022 11:11 AM, Richard Damon wrote:
On 6/4/22 11:51 AM, olcott wrote:
On 6/4/2022 10:38 AM, Richard Damon wrote:
On 6/4/22 11:11 AM, olcott wrote:THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
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
Right, and for the simulation of H(P,P), that is all that happen >>>>>>>>>>
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
And the input to H(P,P) does TERMINATE NORMALLY when correct >>>>>>>>>> simulated.
_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.
Right, it emulates the first seven instructions,
BRAIN DEAD MORONS DON'T GET THIS:
Because we verified that H(P,P) emulates the first seven
instructions of P we know that it will keep doing this every time >>>>>>> that H(P,P) is invoked as long as the simulation continues.
Nope, different invocations of H's so not part of the same trace.
The whole point is whether or not the correct x86 emulation of the
original input would ever reach its final "ret" instruction.
Right, the correct x86 emulation of the ORIGINAL input. The second
layer of simulation is
invoked in the same execution chain that invokes the first layer and
is thus a subordinate aspect of this first emulation.
Nope, the execution of that is NOT part of the actual execution trace
of the original input.
When you start denying easily verifiable facts I quit even glancing at
what you say for at least a week.
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 software engineering confirms that such an H0 could exist is
sufficient proof that H0 does exist whether or not it is encoded.
It is encoded.
.... 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.
Not with the damned liars on this forum that are only interested in
rebuttal and don't give a rat's ass about the truth.
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.
So you are saying that the term "terminated normally" is complete
gibberish to every software engineer? Why do you lie about this?
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".
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 6/4/22 2:37 PM, olcott wrote:
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 software engineering confirms that such an H0 could exist is
sufficient proof that H0 does exist whether or not it is encoded.
It is encoded.
And it is well know that a limited halt decider to detect programs like
that can exist. But that doesn't show that the needed H to decide P does.
.... 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.
Not with the damned liars on this forum that are only interested in
rebuttal and don't give a rat's ass about the truth.
You mean the one named Peter Olcott?
He is the biggest liar on the forum.
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.
So you are saying that the term "terminated normally" is complete
gibberish to every software engineer? Why do you lie about this?
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".
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.
Right, so to show non-halting, you need to show that if you run the
machine for an unbounded number of steps, it will not reach a final state.
On 6/4/2022 1:54 PM, Richard Damon wrote:
On 6/4/22 2:37 PM, olcott wrote:
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 software engineering confirms that such an H0 could exist is
sufficient proof that H0 does exist whether or not it is encoded.
It is encoded.
And it is well know that a limited halt decider to detect programs
like that can exist. But that doesn't show that the needed H to decide
P does.
.... 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.
Not with the damned liars on this forum that are only interested in
rebuttal and don't give a rat's ass about the truth.
You mean the one named Peter Olcott?
He is the biggest liar on the forum.
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.
So you are saying that the term "terminated normally" is complete
gibberish to every software engineer? Why do you lie about this?
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".
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.
Right, so to show non-halting, you need to show that if you run the
machine for an unbounded number of steps, it will not reach 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 101:38:42 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,334,862 |