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
*H and P match the above halting problem relationship to each other*
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.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a non-halting behavior pattern such that it correctly determines that a complete
simulation of the input would never stop running, or reach the final
state of this input then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each other*
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.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly determined
that a correct and complete simulation of the input would never stop
running, or reach the final state of this input then the SHD aborts
its simulation and returns 0.
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
*H and P match the above halting problem relationship to each other*
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.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it correctly determines that a complete simulation of the input would never stop running, or reach
the final state of this input then the SHD aborts its simulation and
returns 0.
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
*H and P match the above halting problem relationship to each other*
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.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a non-halting
behavior pattern such that it correctly determines that a complete
simulation of the input would never stop running, or reach the final
state of this input then the SHD aborts its simulation and returns 0.
So, you are just admitting to the category error?
On 6/12/2022 12:07 PM, Richard Damon wrote:
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete simulation of the input would never stop running, or reach
the final state of this input then the SHD aborts its simulation and
returns 0.
So, you are just admitting to the category error?
THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL:
A halt decider must compute the mapping from its input finite strings to
its own accept or reject state on the basis of the actual behavior that
is actually specified by this input finite string.
All rebuttals to this are exactly the same as looking for a white dog in
your living room by looking for a black cat in your kitchen.
On 6/12/2022 1:00 PM, Richard Damon wrote:
On 6/12/22 1:16 PM, olcott wrote:
On 6/12/2022 12:07 PM, Richard Damon wrote:
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it correctly determines that
a complete simulation of the input would never stop running, or
reach the final state of this input then the SHD aborts its
simulation and returns 0.
So, you are just admitting to the category error?
THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL:
A halt decider must compute the mapping from its input finite strings
to its own accept or reject state on the basis of the actual behavior
that is actually specified by this input finite string.
All rebuttals to this are exactly the same as looking for a white dog
in your living room by looking for a black cat in your kitchen.
Right, and the input to H needs to be a representation of the macine
and its input, in this case P and P.
The correct x86 emulation of the machine code of P by H is the ultimate measure of the behavior specified by P to H.
On 6/12/22 2:07 PM, olcott wrote:
On 6/12/2022 1:00 PM, Richard Damon wrote:
On 6/12/22 1:16 PM, olcott wrote:
On 6/12/2022 12:07 PM, Richard Damon wrote:
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it correctly determines
that a complete simulation of the input would never stop running,
or reach the final state of this input then the SHD aborts its
simulation and returns 0.
So, you are just admitting to the category error?
THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL:
A halt decider must compute the mapping from its input finite
strings to its own accept or reject state on the basis of the actual
behavior that is actually specified by this input finite string.
All rebuttals to this are exactly the same as looking for a white
dog in your living room by looking for a black cat in your kitchen.
Right, and the input to H needs to be a representation of the macine
and its input, in this case P and P.
The correct x86 emulation of the machine code of P by H is the
ultimate measure of the behavior specified by P to H.
And by definition, the correct x86 emualation behaves exactly the same
as the program the code comes from.
On 6/12/2022 1:22 PM, Richard Damon wrote:
On 6/12/22 2:07 PM, olcott wrote:
On 6/12/2022 1:00 PM, Richard Damon wrote:
On 6/12/22 1:16 PM, olcott wrote:
On 6/12/2022 12:07 PM, Richard Damon wrote:
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it correctly determines
that a complete simulation of the input would never stop running, >>>>>>> or reach the final state of this input then the SHD aborts its
simulation and returns 0.
So, you are just admitting to the category error?
THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL: >>>>> A halt decider must compute the mapping from its input finite
strings to its own accept or reject state on the basis of the
actual behavior that is actually specified by this input finite
string.
All rebuttals to this are exactly the same as looking for a white
dog in your living room by looking for a black cat in your kitchen.
Right, and the input to H needs to be a representation of the macine
and its input, in this case P and P.
The correct x86 emulation of the machine code of P by H is the
ultimate measure of the behavior specified by P to H.
And by definition, the correct x86 emualation behaves exactly the same
as the program the code comes from.
The direct execution of P(P) is conclusively proven to have a different sequence of instructions that its correct x86 emulation by H.
This is caused by the fact that when H(P,P) is executed before its input
its emulated the sequence has a different starting point than when P is executed before H is executed.
All competent software engineers will know that changing an invocation sequence can change the outcome.
On 6/12/22 2:48 PM, olcott wrote:When P(P) is executed its behavior conditionally depends on the return
On 6/12/2022 1:22 PM, Richard Damon wrote:
On 6/12/22 2:07 PM, olcott wrote:
On 6/12/2022 1:00 PM, Richard Damon wrote:
On 6/12/22 1:16 PM, olcott wrote:
On 6/12/2022 12:07 PM, Richard Damon wrote:
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it correctly determines >>>>>>>> that a complete simulation of the input would never stop
running, or reach the final state of this input then the SHD
aborts its simulation and returns 0.
So, you are just admitting to the category error?
THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL: >>>>>> A halt decider must compute the mapping from its input finite
strings to its own accept or reject state on the basis of the
actual behavior that is actually specified by this input finite
string.
All rebuttals to this are exactly the same as looking for a white
dog in your living room by looking for a black cat in your kitchen. >>>>>>
Right, and the input to H needs to be a representation of the
macine and its input, in this case P and P.
The correct x86 emulation of the machine code of P by H is the
ultimate measure of the behavior specified by P to H.
And by definition, the correct x86 emualation behaves exactly the
same as the program the code comes from.
The direct execution of P(P) is conclusively proven to have a
different sequence of instructions that its correct x86 emulation by H.
Kind of hard for something to not match its definition and still be
correct.
This is caused by the fact that when H(P,P) is executed before its
input its emulated the sequence has a different starting point than
when P is executed before H is executed.
Nope, P starts at its beginning both times.
On 6/12/2022 2:04 PM, Richard Damon wrote:
On 6/12/22 2:48 PM, olcott wrote:When P(P) is executed its behavior conditionally depends on the return
On 6/12/2022 1:22 PM, Richard Damon wrote:
On 6/12/22 2:07 PM, olcott wrote:
On 6/12/2022 1:00 PM, Richard Damon wrote:
On 6/12/22 1:16 PM, olcott wrote:
On 6/12/2022 12:07 PM, Richard Damon wrote:
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it correctly determines >>>>>>>>> that a complete simulation of the input would never stop
running, or reach the final state of this input then the SHD >>>>>>>>> aborts its simulation and returns 0.
So, you are just admitting to the category error?
THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL: >>>>>>> A halt decider must compute the mapping from its input finite
strings to its own accept or reject state on the basis of the
actual behavior that is actually specified by this input finite
string.
All rebuttals to this are exactly the same as looking for a white >>>>>>> dog in your living room by looking for a black cat in your kitchen. >>>>>>>
Right, and the input to H needs to be a representation of the
macine and its input, in this case P and P.
The correct x86 emulation of the machine code of P by H is the
ultimate measure of the behavior specified by P to H.
And by definition, the correct x86 emualation behaves exactly the
same as the program the code comes from.
The direct execution of P(P) is conclusively proven to have a
different sequence of instructions that its correct x86 emulation by H.
Kind of hard for something to not match its definition and still be
correct.
This is caused by the fact that when H(P,P) is executed before its
input its emulated the sequence has a different starting point than
when P is executed before H is executed.
Nope, P starts at its beginning both times.
value of H.
When H(P,P) is executed the correctly emulated P cannot possibly reach
the point where its behavior depends on H.
On 6/12/22 3:48 PM, olcott wrote:
On 6/12/2022 2:04 PM, Richard Damon wrote:
On 6/12/22 2:48 PM, olcott wrote:When P(P) is executed its behavior conditionally depends on the return
On 6/12/2022 1:22 PM, Richard Damon wrote:Kind of hard for something to not match its definition and still be
On 6/12/22 2:07 PM, olcott wrote:
On 6/12/2022 1:00 PM, Richard Damon wrote:
On 6/12/22 1:16 PM, olcott wrote:
On 6/12/2022 12:07 PM, Richard Damon wrote:
On 6/12/22 12:10 PM, olcott wrote:
On 6/12/2022 11:07 AM, olcott wrote:
rewritten:
*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a >>>>>>>>>> non-halting behavior pattern such that it correctly determines >>>>>>>>>> that a complete simulation of the input would never stop
running, or reach the final state of this input then the SHD >>>>>>>>>> aborts its simulation and returns 0.
So, you are just admitting to the category error?
THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT >>>>>>>> ALL:
A halt decider must compute the mapping from its input finite
strings to its own accept or reject state on the basis of the
actual behavior that is actually specified by this input finite >>>>>>>> string.
All rebuttals to this are exactly the same as looking for a
white dog in your living room by looking for a black cat in your >>>>>>>> kitchen.
Right, and the input to H needs to be a representation of the
macine and its input, in this case P and P.
The correct x86 emulation of the machine code of P by H is the
ultimate measure of the behavior specified by P to H.
And by definition, the correct x86 emualation behaves exactly the
same as the program the code comes from.
The direct execution of P(P) is conclusively proven to have a
different sequence of instructions that its correct x86 emulation by H. >>>
correct.
This is caused by the fact that when H(P,P) is executed before its
input its emulated the sequence has a different starting point than
when P is executed before H is executed.
Nope, P starts at its beginning both times.
value of H.
When H(P,P) is executed the correctly emulated P cannot possibly reach
the point where its behavior depends on H.
You seem confused. We aren't comparing P(P) to H(P,P) and saying they
need to generate the same sequence of states.
We are comparing P(P) to the correct emulation of the input to H(P,P),
or the two different calls to H(P,P) (from main or from P(P)).
IF P(P) can call H(P,P) and get returned the value 0,
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it never halts.
When the correct partial simulation of the input matches a non-halting
behavior pattern such that it can be correctly determined that a correct
and complete simulation of the input would never stop running, or reach
the final state of this input then the SHD aborts its simulation and
returns 0.
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
*H and P match the above halting problem relationship to each other*
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.
Additionally H(P,P) reports non-halting. Therefore you conclude that H is correct.
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this input
then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
never halts. Additionally H(P,P) reports non-halting. Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of P.
Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this input
then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
never halts. Additionally H(P,P) reports non-halting. Therefore
you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of P.
Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace
and see that P is calling H with the same arguments that it was
called with and there are no instructions in P that would break
this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a counter-example that proves it to be incorrect.
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this input
then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
never halts. Additionally H(P,P) reports non-halting. Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of P.
Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
Naive.
/Flibble
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this input
then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
never halts. Additionally H(P,P) reports non-halting. Therefore
you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of P.
Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace
and see that P is calling H with the same arguments that it was
called with and there are no instructions in P that would break
this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no instructions
in P that would break the cycle.
/Flibble
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this
input then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
it never halts. Additionally H(P,P) reports non-halting.
Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of
P. Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its
own machine address) is able to look though the prior execution
trace and see that P is calling H with the same arguments that
it was called with and there are no instructions in P that would
break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>> When the correct partial simulation of the input matches a >>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>> determined that a correct and complete simulation of the >>>>>>>>>> input would never stop running, or reach the final state of >>>>>>>>>> this input then the SHD aborts its simulation and returns >>>>>>>>>> 0.
So your case is that you have dry run P(P) and determined
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
*H and P match the above halting problem relationship to >>>>>>>>>> each other*
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.
that it never halts. Additionally H(P,P) reports
non-halting. Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it >>>>>>>> correctly determines that a correct and complete emulation of >>>>>>>> its input would never stop running or reach the "ret"
instruction of P. Instead it would be stuck in infinitely
recursive emulation.
I have updated the algorithm so that it is a pure function of >>>>>>>> its inputs. As soon as P calls H for the first time, H
(knowing its own machine address) is able to look though the >>>>>>>> prior execution trace and see that P is calling H with the
same arguments that it was called with and there are no
instructions in P that would break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated
on another forum, thus saying that it is simply Naive carries
zero weight.
The only way that the last paragraph can be rebutted is to
find a counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines that
there are no instructions in P that would break the cycle.
Publish the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes this
is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it would
be very easy to write a program that examines the correct x86
emulation of the above P to determine that P cannot break out of its recursive emulation.
That you imply that this cannot be correctly determined without
actually seeing the code that does this can't reasonably be construed
as any honest mistake.
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that >>>>>>> it never halts. Additionally H(P,P) reports non-halting.
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the
input would never stop running, or reach the final state of
this input then the SHD aborts its simulation and returns 0. >>>>>>>>
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
*H and P match the above halting problem relationship to each >>>>>>>> other*
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.
Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of
its input would never stop running or reach the "ret"
instruction of P. Instead it would be stuck in infinitely
recursive emulation.
I have updated the algorithm so that it is a pure function of
its inputs. As soon as P calls H for the first time, H
(knowing its own machine address) is able to look though the
prior execution trace and see that P is calling H with the
same arguments that it was called with and there are no
instructions in P that would break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines that
there are no instructions in P that would break the cycle. Publish
the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes this is
merely playing head games.
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that >>>>>>>>> it never halts. Additionally H(P,P) reports non-halting.
When the correct partial simulation of the input matches a >>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>> determined that a correct and complete simulation of the
input would never stop running, or reach the final state of >>>>>>>>>> this input then the SHD aborts its simulation and returns 0. >>>>>>>>>>
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
*H and P match the above halting problem relationship to each >>>>>>>>>> other*
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.
Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of
its input would never stop running or reach the "ret"
instruction of P. Instead it would be stuck in infinitely
recursive emulation.
I have updated the algorithm so that it is a pure function of
its inputs. As soon as P calls H for the first time, H
(knowing its own machine address) is able to look though the
prior execution trace and see that P is calling H with the
same arguments that it was called with and there are no
instructions in P that would break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines that
there are no instructions in P that would break the cycle. Publish
the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes this is
merely playing head games.
You've got nothing.
/Flibble
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>>>> When the correct partial simulation of the input matches a >>>>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>>>> determined that a correct and complete simulation of the >>>>>>>>>>>> input would never stop running, or reach the final state of >>>>>>>>>>>> this input then the SHD aborts its simulation and returns >>>>>>>>>>>> 0.
So your case is that you have dry run P(P) and determined >>>>>>>>>>> that it never halts. Additionally H(P,P) reports
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
*H and P match the above halting problem relationship to >>>>>>>>>>>> each other*
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.
non-halting. Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it >>>>>>>>>> correctly determines that a correct and complete emulation of >>>>>>>>>> its input would never stop running or reach the "ret"
instruction of P. Instead it would be stuck in infinitely
recursive emulation.
I have updated the algorithm so that it is a pure function of >>>>>>>>>> its inputs. As soon as P calls H for the first time, H
(knowing its own machine address) is able to look though the >>>>>>>>>> prior execution trace and see that P is calling H with the >>>>>>>>>> same arguments that it was called with and there are no
instructions in P that would break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated >>>>>>>> on another forum, thus saying that it is simply Naive carries
zero weight.
The only way that the last paragraph can be rebutted is to
find a counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines that
there are no instructions in P that would break the cycle.
Publish the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes this
is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it would
be very easy to write a program that examines the correct x86
emulation of the above P to determine that P cannot break out of its
recursive emulation.
That you imply that this cannot be correctly determined without
actually seeing the code that does this can't reasonably be construed
as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish source
code so we don't have to guess.
/Flibble
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input >>>>>>>> would never stop running, or reach the final state of this
input then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
it never halts. Additionally H(P,P) reports non-halting.
Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of
P. Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its
own machine address) is able to look though the prior execution
trace and see that P is calling H with the same arguments that
it was called with and there are no instructions in P that would
break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines that
there are no instructions in P that would break the cycle. Publish the source code of your algorithm.
/Flibble
On Mon, 13 Jun 2022 15:14:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>>>>>> When the correct partial simulation of the input matches >>>>>>>>>>>>>> a non-halting behavior pattern such that it can be >>>>>>>>>>>>>> correctly determined that a correct and completeIn the above case when H(P,P) partially emulates its input >>>>>>>>>>>> it correctly determines that a correct and complete
simulation of the input would never stop running, or >>>>>>>>>>>>>> reach the final state of this input then the SHD aborts >>>>>>>>>>>>>> its simulation and returns 0.So your case is that you have dry run P(P) and determined >>>>>>>>>>>>> that it never halts. Additionally H(P,P) reports
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
*H and P match the above halting problem relationship to >>>>>>>>>>>>>> each other*
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.
non-halting. Therefore you conclude that H is correct. >>>>>>>>>>>>
emulation of its input would never stop running or reach >>>>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in >>>>>>>>>>>> infinitely recursive emulation.
I have updated the algorithm so that it is a pure function >>>>>>>>>>>> of its inputs. As soon as P calls H for the first time, H >>>>>>>>>>>> (knowing its own machine address) is able to look though >>>>>>>>>>>> the prior execution trace and see that P is calling H with >>>>>>>>>>>> the same arguments that it was called with and there are no >>>>>>>>>>>> instructions in P that would break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and
validated on another forum, thus saying that it is simply
Naive carries zero weight.
The only way that the last paragraph can be rebutted is to >>>>>>>>>> find a counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines
that there are no instructions in P that would break the cycle.
Publish the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes
this is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it
would be very easy to write a program that examines the correct x86
emulation of the above P to determine that P cannot break out of
its recursive emulation.
That you imply that this cannot be correctly determined without
actually seeing the code that does this can't reasonably be
construed as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish source
code so we don't have to guess.
/Flibble
The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly determine
that the correctly emulated input to H(P,P) never halts?
If it is possible then H(P,P)==0 is proven to be correct.
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.
You've got nothing, nothing but hot air.
/Flibble
On 6/13/2022 3:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>>>> When the correct partial simulation of the input matches >>>>>>>>>>>> a non-halting behavior pattern such that it can beIn the above case when H(P,P) partially emulates its input >>>>>>>>>> it correctly determines that a correct and complete
correctly determined that a correct and completeSo your case is that you have dry run P(P) and determined >>>>>>>>>>> that it never halts. Additionally H(P,P) reports
simulation of the input would never stop running, or >>>>>>>>>>>> reach the final state of this input then the SHD aborts >>>>>>>>>>>> its simulation and returns 0.
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
*H and P match the above halting problem relationship to >>>>>>>>>>>> each other*
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.
non-halting. Therefore you conclude that H is correct. >>>>>>>>>>
emulation of its input would never stop running or reach >>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in >>>>>>>>>> infinitely recursive emulation.
I have updated the algorithm so that it is a pure function >>>>>>>>>> of its inputs. As soon as P calls H for the first time, H >>>>>>>>>> (knowing its own machine address) is able to look though >>>>>>>>>> the prior execution trace and see that P is calling H with >>>>>>>>>> the same arguments that it was called with and there are no >>>>>>>>>> instructions in P that would break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and
validated on another forum, thus saying that it is simply
Naive carries zero weight.
The only way that the last paragraph can be rebutted is to
find a counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines
that there are no instructions in P that would break the cycle.
Publish the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes
this is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it
would be very easy to write a program that examines the correct x86
emulation of the above P to determine that P cannot break out of
its recursive emulation.
That you imply that this cannot be correctly determined without
actually seeing the code that does this can't reasonably be
construed as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish source
code so we don't have to guess.
/Flibble
The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly determine
that the correctly emulated input to H(P,P) never halts?
If it is possible then H(P,P)==0 is proven to be correct.
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.
On 6/13/2022 3:50 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:14:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott
wrote:
*The criterion measure for a simulating halt decider >>>>>>>>>>>>>> SHD* When the correct partial simulation of the input >>>>>>>>>>>>>> matches a non-halting behavior pattern such that it >>>>>>>>>>>>>> can be correctly determined that a correct and complete >>>>>>>>>>>>>> simulation of the input would never stop running, or >>>>>>>>>>>>>> reach the final state of this input then the SHD aborts >>>>>>>>>>>>>> its simulation and returns 0.So your case is that you have dry run P(P) and
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
*H and P match the above halting problem relationship >>>>>>>>>>>>>> to each other*
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.
determined that it never halts. Additionally H(P,P) >>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is >>>>>>>>>>>>> correct.
In the above case when H(P,P) partially emulates its >>>>>>>>>>>> input it correctly determines that a correct and complete >>>>>>>>>>>> emulation of its input would never stop running or reach >>>>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in >>>>>>>>>>>> infinitely recursive emulation.
I have updated the algorithm so that it is a pure
function of its inputs. As soon as P calls H for the >>>>>>>>>>>> first time, H (knowing its own machine address) is able >>>>>>>>>>>> to look though the prior execution trace and see that P >>>>>>>>>>>> is calling H with the same arguments that it was called >>>>>>>>>>>> with and there are no instructions in P that would break >>>>>>>>>>>> this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and
validated on another forum, thus saying that it is simply >>>>>>>>>> Naive carries zero weight.
The only way that the last paragraph can be rebutted is to >>>>>>>>>> find a counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines
that there are no instructions in P that would break the
cycle. Publish the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions
of P provide no means for the emulated input to H(P,P) to
break out of repeated x86 emulations your request for code
that recognizes this is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it
would be very easy to write a program that examines the correct
x86 emulation of the above P to determine that P cannot break
out of its recursive emulation.
That you imply that this cannot be correctly determined without
actually seeing the code that does this can't reasonably be
construed as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish
source code so we don't have to guess.
/Flibble
The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly
determine that the correctly emulated input to H(P,P) never halts?
If it is possible then H(P,P)==0 is proven to be correct.
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.
You've got nothing, nothing but hot air.
/Flibble
What dishonest person says when they know that they have been
correctly refuted. On the other hand when an honest person forms a
rebuttal they use reasoning to point out errors.
On Mon, 13 Jun 2022 15:56:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:50 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:14:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott >>>>>>>>>>>>>>> wrote:
*The criterion measure for a simulating halt decider >>>>>>>>>>>>>>>> SHD* When the correct partial simulation of the input >>>>>>>>>>>>>>>> matches a non-halting behavior pattern such that it >>>>>>>>>>>>>>>> can be correctly determined that a correct and complete >>>>>>>>>>>>>>>> simulation of the input would never stop running, or >>>>>>>>>>>>>>>> reach the final state of this input then the SHD aborts >>>>>>>>>>>>>>>> its simulation and returns 0.So your case is that you have dry run P(P) and
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
*H and P match the above halting problem relationship >>>>>>>>>>>>>>>> to each other*
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.
determined that it never halts. Additionally H(P,P) >>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is >>>>>>>>>>>>>>> correct.
In the above case when H(P,P) partially emulates its >>>>>>>>>>>>>> input it correctly determines that a correct and complete >>>>>>>>>>>>>> emulation of its input would never stop running or reach >>>>>>>>>>>>>> the "ret" instruction of P. Instead it would be stuck in >>>>>>>>>>>>>> infinitely recursive emulation.
I have updated the algorithm so that it is a pure
function of its inputs. As soon as P calls H for the >>>>>>>>>>>>>> first time, H (knowing its own machine address) is able >>>>>>>>>>>>>> to look though the prior execution trace and see that P >>>>>>>>>>>>>> is calling H with the same arguments that it was called >>>>>>>>>>>>>> with and there are no instructions in P that would break >>>>>>>>>>>>>> this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and
validated on another forum, thus saying that it is simply >>>>>>>>>>>> Naive carries zero weight.
The only way that the last paragraph can be rebutted is to >>>>>>>>>>>> find a counter-example that proves it to be incorrect.
Publish your algorithm which determines that there are no >>>>>>>>>>> instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines >>>>>>>>> that there are no instructions in P that would break the
cycle. Publish the source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions
of P provide no means for the emulated input to H(P,P) to
break out of repeated x86 emulations your request for code
that recognizes this is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it
would be very easy to write a program that examines the correct
x86 emulation of the above P to determine that P cannot break
out of its recursive emulation.
That you imply that this cannot be correctly determined without
actually seeing the code that does this can't reasonably be
construed as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish
source code so we don't have to guess.
/Flibble
The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly
determine that the correctly emulated input to H(P,P) never halts?
If it is possible then H(P,P)==0 is proven to be correct.
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.
You've got nothing, nothing but hot air.
/Flibble
What dishonest person says when they know that they have been
correctly refuted. On the other hand when an honest person forms a
rebuttal they use reasoning to point out errors.
You simply ignore any reasoning pointing out errors. You are dishonest
and you've got nothing.
/Flibble
On 6/13/2022 4:16 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:56:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:50 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:14:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott >>>>>>>>>>>>>>> wrote:
*The criterion measure for a simulating halt decider >>>>>>>>>>>>>>>> SHD* When the correct partial simulation of the input >>>>>>>>>>>>>>>> matches a non-halting behavior pattern such that it >>>>>>>>>>>>>>>> can be correctly determined that a correct and >>>>>>>>>>>>>>>> complete simulation of the input would never stop >>>>>>>>>>>>>>>> running, or reach the final state of this input then >>>>>>>>>>>>>>>> the SHD aborts its simulation and returns 0. >>>>>>>>>>>>>>>>So your case is that you have dry run P(P) and >>>>>>>>>>>>>>> determined that it never halts. Additionally H(P,P) >>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is >>>>>>>>>>>>>>> correct.
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 >>>>>>>>>>>>>>>>
*H and P match the above halting problem relationship >>>>>>>>>>>>>>>> to each other*
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.
In the above case when H(P,P) partially emulates its >>>>>>>>>>>>>> input it correctly determines that a correct and >>>>>>>>>>>>>> complete emulation of its input would never stop >>>>>>>>>>>>>> running or reach the "ret" instruction of P. Instead >>>>>>>>>>>>>> it would be stuck in infinitely recursive emulation. >>>>>>>>>>>>>>
I have updated the algorithm so that it is a pure >>>>>>>>>>>>>> function of its inputs. As soon as P calls H for the >>>>>>>>>>>>>> first time, H (knowing its own machine address) is able >>>>>>>>>>>>>> to look though the prior execution trace and see that P >>>>>>>>>>>>>> is calling H with the same arguments that it was called >>>>>>>>>>>>>> with and there are no instructions in P that would >>>>>>>>>>>>>> break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and >>>>>>>>>>>> validated on another forum, thus saying that it is simply >>>>>>>>>>>> Naive carries zero weight.
The only way that the last paragraph can be rebutted is >>>>>>>>>>>> to find a counter-example that proves it to be
incorrect.
Publish your algorithm which determines that there are no >>>>>>>>>>> instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which
determines that there are no instructions in P that would
break the cycle. Publish the source code of your algorithm. >>>>>>>>>
/Flibble
Because everyone can see that above first seven instructions >>>>>>>> of P provide no means for the emulated input to H(P,P) to
break out of repeated x86 emulations your request for code
that recognizes this is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it
would be very easy to write a program that examines the correct
x86 emulation of the above P to determine that P cannot break
out of its recursive emulation.
That you imply that this cannot be correctly determined without
actually seeing the code that does this can't reasonably be
construed as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish
source code so we don't have to guess.
/Flibble
The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly
determine that the correctly emulated input to H(P,P) never
halts?
If it is possible then H(P,P)==0 is proven to be correct.
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.
You've got nothing, nothing but hot air.
/Flibble
What dishonest person says when they know that they have been
correctly refuted. On the other hand when an honest person forms a
rebuttal they use reasoning to point out errors.
You simply ignore any reasoning pointing out errors. You are
dishonest and you've got nothing.
/Flibble
I provided the reasoning above and it is still there.
You provided no rebuttal to this reasoning as the clearly record
shows.
On 6/13/2022 5:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 16:20:00 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 4:16 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:56:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:50 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:14:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote: >>>>>>>>>>>>>>>>> On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott >>>>>>>>>>>>>>>>> wrote:
*The criterion measure for a simulating halt >>>>>>>>>>>>>>>>>> decider SHD* When the correct partial simulation >>>>>>>>>>>>>>>>>> of the input matches a non-halting behavior >>>>>>>>>>>>>>>>>> pattern such that it can be correctly determined >>>>>>>>>>>>>>>>>> that a correct and complete simulation of the >>>>>>>>>>>>>>>>>> input would never stop running, or reach the final >>>>>>>>>>>>>>>>>> state of this input then the SHD aborts its >>>>>>>>>>>>>>>>>> simulation and returns 0.So your case is that you have dry run P(P) and >>>>>>>>>>>>>>>>> determined that it never halts. Additionally H(P,P) >>>>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H >>>>>>>>>>>>>>>>> is correct.
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 >>>>>>>>>>>>>>>>>>
*H and P match the above halting problem >>>>>>>>>>>>>>>>>> relationship to each other*
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.
In the above case when H(P,P) partially emulates its >>>>>>>>>>>>>>>> input it correctly determines that a correct and >>>>>>>>>>>>>>>> complete emulation of its input would never stop >>>>>>>>>>>>>>>> running or reach the "ret" instruction of P. Instead >>>>>>>>>>>>>>>> it would be stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>
I have updated the algorithm so that it is a pure >>>>>>>>>>>>>>>> function of its inputs. As soon as P calls H for the >>>>>>>>>>>>>>>> first time, H (knowing its own machine address) is >>>>>>>>>>>>>>>> able to look though the prior execution trace and >>>>>>>>>>>>>>>> see that P is calling H with the same arguments that >>>>>>>>>>>>>>>> it was called with and there are no instructions in >>>>>>>>>>>>>>>> P that would break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and >>>>>>>>>>>>>> validated on another forum, thus saying that it is >>>>>>>>>>>>>> simply Naive carries zero weight.
The only way that the last paragraph can be rebutted is >>>>>>>>>>>>>> to find a counter-example that proves it to be
incorrect.
Publish your algorithm which determines that there are >>>>>>>>>>>>> no instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which
determines that there are no instructions in P that would >>>>>>>>>>> break the cycle. Publish the source code of your
algorithm.
/Flibble
Because everyone can see that above first seven
instructions of P provide no means for the emulated input >>>>>>>>>> to H(P,P) to break out of repeated x86 emulations your
request for code that recognizes this is merely playing
head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that
it would be very easy to write a program that examines the
correct x86 emulation of the above P to determine that P
cannot break out of its recursive emulation.
That you imply that this cannot be correctly determined
without actually seeing the code that does this can't
reasonably be construed as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish
source code so we don't have to guess.
/Flibble
The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly
determine that the correctly emulated input to H(P,P) never
halts?
If it is possible then H(P,P)==0 is proven to be correct.
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.
You've got nothing, nothing but hot air.
/Flibble
What dishonest person says when they know that they have been
correctly refuted. On the other hand when an honest person forms
a rebuttal they use reasoning to point out errors.
You simply ignore any reasoning pointing out errors. You are
dishonest and you've got nothing.
/Flibble
I provided the reasoning above and it is still there.
You provided no rebuttal to this reasoning as the clearly record
shows.
The hubris is unbelievable.
/Flibble
So far every single reviewer has managed to dodge a rigorous
point-by-point software engineering review of H(P,P)==0.
Like you they resort to mere rhetoric presumably because they know
that when using correct reaoning as a basis that every rebuttal must
fail.
On Mon, 13 Jun 2022 16:20:00 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 4:16 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:56:44 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:50 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 15:14:48 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 3:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:47:16 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:29 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 14:25:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott >>>>>>>>>>>>>>>>> wrote:
*The criterion measure for a simulating halt decider >>>>>>>>>>>>>>>>>> SHD* When the correct partial simulation of the input >>>>>>>>>>>>>>>>>> matches a non-halting behavior pattern such that it >>>>>>>>>>>>>>>>>> can be correctly determined that a correct and >>>>>>>>>>>>>>>>>> complete simulation of the input would never stop >>>>>>>>>>>>>>>>>> running, or reach the final state of this input then >>>>>>>>>>>>>>>>>> the SHD aborts its simulation and returns 0. >>>>>>>>>>>>>>>>>>So your case is that you have dry run P(P) and >>>>>>>>>>>>>>>>> determined that it never halts. Additionally H(P,P) >>>>>>>>>>>>>>>>> reports non-halting. Therefore you conclude that H is >>>>>>>>>>>>>>>>> correct.
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 >>>>>>>>>>>>>>>>>>
*H and P match the above halting problem relationship >>>>>>>>>>>>>>>>>> to each other*
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.
In the above case when H(P,P) partially emulates its >>>>>>>>>>>>>>>> input it correctly determines that a correct and >>>>>>>>>>>>>>>> complete emulation of its input would never stop >>>>>>>>>>>>>>>> running or reach the "ret" instruction of P. Instead >>>>>>>>>>>>>>>> it would be stuck in infinitely recursive emulation. >>>>>>>>>>>>>>>>
I have updated the algorithm so that it is a pure >>>>>>>>>>>>>>>> function of its inputs. As soon as P calls H for the >>>>>>>>>>>>>>>> first time, H (knowing its own machine address) is able >>>>>>>>>>>>>>>> to look though the prior execution trace and see that P >>>>>>>>>>>>>>>> is calling H with the same arguments that it was called >>>>>>>>>>>>>>>> with and there are no instructions in P that would >>>>>>>>>>>>>>>> break this cycle.
Naive.
/Flibble
The last paragraph has been extensively reviewed and >>>>>>>>>>>>>> validated on another forum, thus saying that it is simply >>>>>>>>>>>>>> Naive carries zero weight.
The only way that the last paragraph can be rebutted is >>>>>>>>>>>>>> to find a counter-example that proves it to be
incorrect.
Publish your algorithm which determines that there are no >>>>>>>>>>>>> instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which
determines that there are no instructions in P that would >>>>>>>>>>> break the cycle. Publish the source code of your algorithm. >>>>>>>>>>>
/Flibble
Because everyone can see that above first seven instructions >>>>>>>>>> of P provide no means for the emulated input to H(P,P) to
break out of repeated x86 emulations your request for code >>>>>>>>>> that recognizes this is merely playing head games.
You've got nothing.
/Flibble
Every competent software engineer can very easily tell that it >>>>>>>> would be very easy to write a program that examines the correct >>>>>>>> x86 emulation of the above P to determine that P cannot break
out of its recursive emulation.
That you imply that this cannot be correctly determined without >>>>>>>> actually seeing the code that does this can't reasonably be
construed as any honest mistake.
Are you pattern matching x86 opcodes "EB FE" or not? Publish
source code so we don't have to guess.
/Flibble
The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly
determine that the correctly emulated input to H(P,P) never
halts?
If it is possible then H(P,P)==0 is proven to be correct.
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.
You've got nothing, nothing but hot air.
/Flibble
What dishonest person says when they know that they have been
correctly refuted. On the other hand when an honest person forms a
rebuttal they use reasoning to point out errors.
You simply ignore any reasoning pointing out errors. You are
dishonest and you've got nothing.
/Flibble
I provided the reasoning above and it is still there.
You provided no rebuttal to this reasoning as the clearly record
shows.
The hubris is unbelievable.
/Flibble
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a non-halting
behavior pattern such that it can be correctly determined that a correct >>> and complete simulation of the input would never stop running, or reach
the final state of this input then the SHD aborts its simulation and
returns 0.
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
*H and P match the above halting problem relationship to each other*
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.
never halts.
Additionally H(P,P) reports non-halting. Therefore you conclude that H is
correct.
In the above case when H(P,P) partially emulates its input it correctly determines that a correct and complete emulation of its input would
never stop running or reach the "ret" instruction of P. Instead it would
be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called with
and there are no instructions in P that would break this cycle.
On 6/13/2022 2:12 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 13:25:50 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 1:07 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 12:51:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:Publish your algorithm which determines that there are no
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that >>>>>>>> it never halts. Additionally H(P,P) reports non-halting.
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input >>>>>>>>> would never stop running, or reach the final state of this
input then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each >>>>>>>>> other*
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.
Therefore you conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its >>>>>>> input would never stop running or reach the "ret" instruction of >>>>>>> P. Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its >>>>>>> inputs. As soon as P calls H for the first time, H (knowing its
own machine address) is able to look though the prior execution
trace and see that P is calling H with the same arguments that
it was called with and there are no instructions in P that would >>>>>>> break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
instructions in P that would break the cycle.
/Flibble
_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]
That is a trace of P, it is not an algorithm which determines that
there are no instructions in P that would break the cycle. Publish the
source code of your algorithm.
/Flibble
Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes this is
merely playing head games.
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this input
then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
never halts. Additionally H(P,P) reports non-halting. Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of P.
Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.
The only way that the last paragraph can be rebutted is to find a counter-example that proves it to be incorrect.
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this input
then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
never halts. Additionally H(P,P) reports non-halting. Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of P.
Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with your conclusion?
I don't remember seeing one, so I think this is another of your lies.
On 6/13/2022 6:18 PM, Richard Damon wrote:
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input
would never stop running, or reach the final state of this input >>>>>>> then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each
other*
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.
never halts. Additionally H(P,P) reports non-halting. Therefore you >>>>>> conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its
input would never stop running or reach the "ret" instruction of P.
Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and >>>>> see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with your
conclusion?
I don't remember seeing one, so I think this is another of your lies.
The last paragraph has been extensively reviewed and validated on
another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.
On 6/13/2022 7:06 PM, Richard Damon wrote:
If there has been no evidence that anyone has presented then this is not proof at all that the claim is true.
On 6/13/22 7:25 PM, olcott wrote:
On 6/13/2022 6:18 PM, Richard Damon wrote:
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it >>>>>>>> never halts. Additionally H(P,P) reports non-halting. Therefore you >>>>>>>> conclude that H is correct.
When the correct partial simulation of the input matches a
non-halting behavior pattern such that it can be correctly
determined that a correct and complete simulation of the input >>>>>>>>> would never stop running, or reach the final state of this input >>>>>>>>> then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each >>>>>>>>> other*
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.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its >>>>>>> input would never stop running or reach the "ret" instruction of P. >>>>>>> Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its >>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own >>>>>>> machine address) is able to look though the prior execution trace >>>>>>> and
see that P is calling H with the same arguments that it was called >>>>>>> with and there are no instructions in P that would break this cycle. >>>>>> Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with your
conclusion?
I don't remember seeing one, so I think this is another of your lies.
The last paragraph has been extensively reviewed and validated on
another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.
Nope, lack of evidence of error is not evidence of lack of error.
If there is no evidence that anyone could ever possibly present then
this is proof that the claim is true.
On 6/13/2022 7:31 PM, Richard Damon wrote:
On 6/13/22 8:20 PM, olcott wrote:
On 6/13/2022 7:06 PM, Richard Damon wrote:
If there has been no evidence that anyone has presented then this is
On 6/13/22 7:25 PM, olcott wrote:
On 6/13/2022 6:18 PM, Richard Damon wrote:
The last paragraph has been extensively reviewed and validated on
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD* >>>>>>>>>>> When the correct partial simulation of the input matches a >>>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>>> determined that a correct and complete simulation of the input >>>>>>>>>>> would never stop running, or reach the final state of this input >>>>>>>>>>> then the SHD aborts its simulation and returns 0.So your case is that you have dry run P(P) and determined that it >>>>>>>>>> never halts. Additionally H(P,P) reports 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
*H and P match the above halting problem relationship to each >>>>>>>>>>> other*
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.
Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it >>>>>>>>> correctly determines that a correct and complete emulation of its >>>>>>>>> input would never stop running or reach the "ret" instruction >>>>>>>>> of P.
Instead it would be stuck in infinitely recursive emulation. >>>>>>>>>
I have updated the algorithm so that it is a pure function of its >>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its >>>>>>>>> own
machine address) is able to look though the prior execution
trace and
see that P is calling H with the same arguments that it was called >>>>>>>>> with and there are no instructions in P that would break this >>>>>>>>> cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on >>>>>>> another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a >>>>>>> counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with
your conclusion?
I don't remember seeing one, so I think this is another of your lies. >>>>>
another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.
Nope, lack of evidence of error is not evidence of lack of error.
not proof at all that the claim is true.
If there is no evidence that anyone could ever possibly present then
this is proof that the claim is true.
Evidence of error HAS been given, and IGNRORED by you, proving your
ignorance, and that you are a pathological liar.
Only the rebuttals that you and Flibble provide are woefully incorrect.
You can't even understand that a dead process does not continue to
execute and Flibble cannot understand that unreachable code has no
effect on behavior.
On 6/13/22 8:20 PM, olcott wrote:
On 6/13/2022 7:06 PM, Richard Damon wrote:
If there has been no evidence that anyone has presented then this is
On 6/13/22 7:25 PM, olcott wrote:
On 6/13/2022 6:18 PM, Richard Damon wrote:
The last paragraph has been extensively reviewed and validated on
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote:
*The criterion measure for a simulating halt decider SHD*So your case is that you have dry run P(P) and determined that it >>>>>>>>> never halts. Additionally H(P,P) reports non-halting. Therefore >>>>>>>>> you
When the correct partial simulation of the input matches a >>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>> determined that a correct and complete simulation of the input >>>>>>>>>> would never stop running, or reach the final state of this input >>>>>>>>>> then the SHD aborts its simulation and returns 0.
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
*H and P match the above halting problem relationship to each >>>>>>>>>> other*
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.
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it
correctly determines that a correct and complete emulation of its >>>>>>>> input would never stop running or reach the "ret" instruction of P. >>>>>>>> Instead it would be stuck in infinitely recursive emulation.
I have updated the algorithm so that it is a pure function of its >>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own >>>>>>>> machine address) is able to look though the prior execution
trace and
see that P is calling H with the same arguments that it was called >>>>>>>> with and there are no instructions in P that would break this
cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with
your conclusion?
I don't remember seeing one, so I think this is another of your lies. >>>>
another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.
Nope, lack of evidence of error is not evidence of lack of error.
not proof at all that the claim is true.
If there is no evidence that anyone could ever possibly present then
this is proof that the claim is true.
Evidence of error HAS been given, and IGNRORED by you, proving your ignorance, and that you are a pathological liar.
On Mon, 13 Jun 2022 19:45:49 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 7:31 PM, Richard Damon wrote:
On 6/13/22 8:20 PM, olcott wrote:
On 6/13/2022 7:06 PM, Richard Damon wrote:
If there has been no evidence that anyone has presented then this
On 6/13/22 7:25 PM, olcott wrote:
On 6/13/2022 6:18 PM, Richard Damon wrote:
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>>>> When the correct partial simulation of the input matches a >>>>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>>>> determined that a correct and complete simulation of the >>>>>>>>>>>> input would never stop running, or reach the final state >>>>>>>>>>>> of this input then the SHD aborts its simulation and
returns 0.So your case is that you have dry run P(P) and determined >>>>>>>>>>> that it never halts. Additionally H(P,P) reports
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
*H and P match the above halting problem relationship to >>>>>>>>>>>> each other*
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.
non-halting. Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it >>>>>>>>>> correctly determines that a correct and complete emulation >>>>>>>>>> of its input would never stop running or reach the "ret"
instruction of P. Instead it would be stuck in infinitely
recursive emulation.
I have updated the algorithm so that it is a pure function >>>>>>>>>> of its inputs. As soon as P calls H for the first time, H
(knowing its own machine address) is able to look though the >>>>>>>>>> prior execution trace and
see that P is calling H with the same arguments that it was >>>>>>>>>> called with and there are no instructions in P that would
break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated >>>>>>>> on another forum, thus saying that it is simply Naive carries
zero weight.
The only way that the last paragraph can be rebutted is to
find a counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with
your conclusion?
I don't remember seeing one, so I think this is another of your
lies.
The last paragraph has been extensively reviewed and validated on
another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.
Nope, lack of evidence of error is not evidence of lack of error.
is not proof at all that the claim is true.
If there is no evidence that anyone could ever possibly present
then this is proof that the claim is true.
Evidence of error HAS been given, and IGNRORED by you, proving your
ignorance, and that you are a pathological liar.
Only the rebuttals that you and Flibble provide are woefully
incorrect. You can't even understand that a dead process does not
continue to execute and Flibble cannot understand that unreachable
code has no effect on behavior.
Of course I understand that unreachable code has no effect on
behaviour; what has an effect on behaviour is changing unreachable code
to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),
your H never returns to allow such code to be reach which is an error:
all halting deciders return a value to their caller.
/Flibble
On 6/13/2022 7:31 PM, Richard Damon wrote:
On 6/13/22 8:20 PM, olcott wrote:
On 6/13/2022 7:06 PM, Richard Damon wrote:
If there has been no evidence that anyone has presented then this
On 6/13/22 7:25 PM, olcott wrote:
On 6/13/2022 6:18 PM, Richard Damon wrote:
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>> When the correct partial simulation of the input matches a >>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>> determined that a correct and complete simulation of the >>>>>>>>>> input would never stop running, or reach the final state >>>>>>>>>> of this input then the SHD aborts its simulation and
returns 0.So your case is that you have dry run P(P) and determined
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
*H and P match the above halting problem relationship to >>>>>>>>>> each other*
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.
that it never halts. Additionally H(P,P) reports
non-halting. Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it >>>>>>>> correctly determines that a correct and complete emulation
of its input would never stop running or reach the "ret"
instruction of P. Instead it would be stuck in infinitely
recursive emulation.
I have updated the algorithm so that it is a pure function
of its inputs. As soon as P calls H for the first time, H
(knowing its own machine address) is able to look though the >>>>>>>> prior execution trace and
see that P is calling H with the same arguments that it was
called with and there are no instructions in P that would
break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated
on another forum, thus saying that it is simply Naive carries
zero weight.
The only way that the last paragraph can be rebutted is to
find a counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with
your conclusion?
I don't remember seeing one, so I think this is another of your
lies.
The last paragraph has been extensively reviewed and validated on
another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.
Nope, lack of evidence of error is not evidence of lack of error.
is not proof at all that the claim is true.
If there is no evidence that anyone could ever possibly present
then this is proof that the claim is true.
Evidence of error HAS been given, and IGNRORED by you, proving your ignorance, and that you are a pathological liar.
Only the rebuttals that you and Flibble provide are woefully
incorrect. You can't even understand that a dead process does not
continue to execute and Flibble cannot understand that unreachable
code has no effect on behavior.
On Mon, 13 Jun 2022 19:45:49 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 7:31 PM, Richard Damon wrote:
On 6/13/22 8:20 PM, olcott wrote:
On 6/13/2022 7:06 PM, Richard Damon wrote:
If there has been no evidence that anyone has presented then this
On 6/13/22 7:25 PM, olcott wrote:
On 6/13/2022 6:18 PM, Richard Damon wrote:
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>>>> When the correct partial simulation of the input matches a >>>>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>>>> determined that a correct and complete simulation of the >>>>>>>>>>>> input would never stop running, or reach the final state >>>>>>>>>>>> of this input then the SHD aborts its simulation and
returns 0.So your case is that you have dry run P(P) and determined >>>>>>>>>>> that it never halts. Additionally H(P,P) reports
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
*H and P match the above halting problem relationship to >>>>>>>>>>>> each other*
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.
non-halting. Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it >>>>>>>>>> correctly determines that a correct and complete emulation >>>>>>>>>> of its input would never stop running or reach the "ret"
instruction of P. Instead it would be stuck in infinitely
recursive emulation.
I have updated the algorithm so that it is a pure function >>>>>>>>>> of its inputs. As soon as P calls H for the first time, H
(knowing its own machine address) is able to look though the >>>>>>>>>> prior execution trace and
see that P is calling H with the same arguments that it was >>>>>>>>>> called with and there are no instructions in P that would
break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated >>>>>>>> on another forum, thus saying that it is simply Naive carries
zero weight.
The only way that the last paragraph can be rebutted is to
find a counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with
your conclusion?
I don't remember seeing one, so I think this is another of your
lies.
The last paragraph has been extensively reviewed and validated on
another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.
Nope, lack of evidence of error is not evidence of lack of error.
is not proof at all that the claim is true.
If there is no evidence that anyone could ever possibly present
then this is proof that the claim is true.
Evidence of error HAS been given, and IGNRORED by you, proving your
ignorance, and that you are a pathological liar.
Only the rebuttals that you and Flibble provide are woefully
incorrect. You can't even understand that a dead process does not
continue to execute and Flibble cannot understand that unreachable
code has no effect on behavior.
Of course I understand that unreachable code has no effect on
behaviour; what has an effect on behaviour is changing unreachable code
to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),
your H never returns to allow such code to be reach which is an error:
all halting deciders return a value to their caller.
/Flibble
On 6/13/2022 8:15 PM, Mr Flibble wrote:
On Mon, 13 Jun 2022 19:45:49 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 7:31 PM, Richard Damon wrote:Of course I understand that unreachable code has no effect on
On 6/13/22 8:20 PM, olcott wrote:
On 6/13/2022 7:06 PM, Richard Damon wrote:
If there has been no evidence that anyone has presented then this
On 6/13/22 7:25 PM, olcott wrote:
On 6/13/2022 6:18 PM, Richard Damon wrote:
On 6/13/22 1:51 PM, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/13/2022 2:44 AM, Malcolm McLean wrote:Naive.
On Sunday, 12 June 2022 at 17:07:14 UTC+1, olcott wrote: >>>>>>>>>>>>> *The criterion measure for a simulating halt decider SHD* >>>>>>>>>>>>> When the correct partial simulation of the input matches a >>>>>>>>>>>>> non-halting behavior pattern such that it can be correctly >>>>>>>>>>>>> determined that a correct and complete simulation of the >>>>>>>>>>>>> input would never stop running, or reach the final state >>>>>>>>>>>>> of this input then the SHD aborts its simulation and >>>>>>>>>>>>> returns 0.
So your case is that you have dry run P(P) and determined >>>>>>>>>>>> that it never halts. Additionally H(P,P) reports
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
*H and P match the above halting problem relationship to >>>>>>>>>>>>> each other*
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.
non-halting. Therefore you
conclude that H is correct.
In the above case when H(P,P) partially emulates its input it >>>>>>>>>>> correctly determines that a correct and complete emulation >>>>>>>>>>> of its input would never stop running or reach the "ret" >>>>>>>>>>> instruction of P. Instead it would be stuck in infinitely >>>>>>>>>>> recursive emulation.
I have updated the algorithm so that it is a pure function >>>>>>>>>>> of its inputs. As soon as P calls H for the first time, H >>>>>>>>>>> (knowing its own machine address) is able to look though the >>>>>>>>>>> prior execution trace and
see that P is calling H with the same arguments that it was >>>>>>>>>>> called with and there are no instructions in P that would >>>>>>>>>>> break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated >>>>>>>>> on another forum, thus saying that it is simply Naive carries >>>>>>>>> zero weight.
The only way that the last paragraph can be rebutted is to
find a counter-example that proves it to be incorrect.
Can you point to the message where someone actually agreed with >>>>>>>> your conclusion?
I don't remember seeing one, so I think this is another of your >>>>>>>> lies.
The last paragraph has been extensively reviewed and validated on >>>>>>> another forum, not USENET.
Ultimately the truth of it depends on the fact that zero correct >>>>>>> rebuttals exist.
Nope, lack of evidence of error is not evidence of lack of error.
is not proof at all that the claim is true.
If there is no evidence that anyone could ever possibly present
then this is proof that the claim is true.
Evidence of error HAS been given, and IGNRORED by you, proving your
ignorance, and that you are a pathological liar.
Only the rebuttals that you and Flibble provide are woefully
incorrect. You can't even understand that a dead process does not
continue to execute and Flibble cannot understand that unreachable
code has no effect on behavior.
behaviour; what has an effect on behaviour is changing unreachable code
to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),
(1) It is no longer P it is X
(2) H(X,X)==1
your H never returns to allow such code to be reach which is an error:
all halting deciders return a value to their caller.
/Flibble
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of itsNaive.
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.
On 2022-06-13 11:51, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of itsNaive.
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.
And which forum would that be?
André
On 2022-06-13 21:50, olcott wrote:
On 6/13/2022 10:46 PM, André G. Isaak wrote:
On 2022-06-13 11:51, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:And which forum would that be?
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own >>>>>> machine address) is able to look though the prior execution trace and >>>>>> see that P is calling H with the same arguments that it was called >>>>>> with and there are no instructions in P that would break this cycle. >>>>> Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight. >>>
André
That is irrelevant.
It's certainly relevant to anyone interested in reading those reviews.
André
On 6/13/2022 10:46 PM, André G. Isaak wrote:
On 2022-06-13 11:51, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of itsNaive.
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and >>>>> see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.
And which forum would that be?
André
That is irrelevant.
On 6/13/2022 10:46 PM, André G. Isaak wrote:
On 2022-06-13 11:51, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of itsNaive.
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and >>>>> see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.
And which forum would that be?
André
That is irrelevant. You should know that Validity supersedes
credibility. Do you believe (like 40% of the electorate) that the
consensus of fools correctly determines the truth?
On 6/13/22 11:50 PM, olcott wrote:
On 6/13/2022 10:46 PM, André G. Isaak wrote:
On 2022-06-13 11:51, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:And which forum would that be?
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own >>>>>> machine address) is able to look though the prior execution trace and >>>>>> see that P is calling H with the same arguments that it was called >>>>>> with and there are no instructions in P that would break this cycle. >>>>> Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight. >>>
André
That is irrelevant. You should know that Validity supersedes
credibility. Do you believe (like 40% of the electorate) that the
consensus of fools correctly determines the truth?
Yes, and since you have none of the later, verification of validity is important.
You SAYING you have reviewed it elsewhere means absolutely nothing, but
if you have, then saying where should be easy and simple. If you
actually haven't, your lie gets revealed.
YOU of course know the answer for certain if you have done this.
If you have, why hide the proof and add fuel to the, thus false, claims
that you are lying about this. If you haven't, you need to ask yourself
why did you lie about it?
On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
On 6/13/2022 11:59 PM, André G. Isaak wrote:We're dealing with our hands tied behind our backs, because we can't see H.
On 2022-06-13 21:50, olcott wrote:I do appreciate that you are reviewing my work.
On 6/13/2022 10:46 PM, André G. Isaak wrote:
On 2022-06-13 11:51, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:And which forum would that be?
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <No...@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of its >>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own >>>>>>>> machine address) is able to look though the prior execution trace and >>>>>>>> see that P is calling H with the same arguments that it was called >>>>>>>> with and there are no instructions in P that would break this cycle. >>>>>>> Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight. >>>>>
André
That is irrelevant.
It's certainly relevant to anyone interested in reading those reviews.
André
So you don't feel technically qualified to assess the merits of this
directly yourself? The impossibility of finding a valid counter-example
disproving the claim counts as proof that the claim is true.
I and other people have suggested an explanation for the results that you
are seeing. But it can only be a shrewd guess. The behaviour of the program depends on how the emulator H is written. If it is in fact an emulator - some posters have disputed that. I doubt that they are right and that H is, as you describe it, an emulator. But it's impossible to actually prove these people wrong.
Yes, it is clear to us humans watching it that the
program is repeating itself. Thus we can appreciate
that it will never reach the final "ret" - indeed,
it won't even get to the infinite loop identified above.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
We're dealing with our hands tied behind our backs, because we can't
see H.
That's only partly true. A sketch of H was posted and we know that that
was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
On 6/14/2022 6:14 AM, Richard Damon wrote:
On 6/13/22 11:50 PM, olcott wrote:
On 6/13/2022 10:46 PM, André G. Isaak wrote:
On 2022-06-13 11:51, olcott wrote:
On 6/13/2022 11:13 AM, Mr Flibble wrote:
On Mon, 13 Jun 2022 09:27:08 -0500
olcott <NoOne@NoWhere.com> wrote:
I have updated the algorithm so that it is a pure function of its >>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own >>>>>>> machine address) is able to look though the prior execution trace >>>>>>> and
see that P is calling H with the same arguments that it was called >>>>>>> with and there are no instructions in P that would break this cycle. >>>>>> Naive.
/Flibble
The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero
weight.
And which forum would that be?
André
That is irrelevant. You should know that Validity supersedes
credibility. Do you believe (like 40% of the electorate) that the
consensus of fools correctly determines the truth?
Yes, and since you have none of the later, verification of validity is
important.
You SAYING you have reviewed it elsewhere means absolutely nothing,
but if you have, then saying where should be easy and simple. If you
actually haven't, your lie gets revealed.
YOU of course know the answer for certain if you have done this.
If you have, why hide the proof and add fuel to the, thus false,
claims that you are lying about this. If you haven't, you need to ask
yourself why did you lie about it?
If you can find an a valid counter example where my criteria does not
work then you have refuted it. If you have not found such a
counter-example then you have not refuted it. Everything else is merely dishonest dodge to avoid the actual point.
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can'tThat's only partly true. A sketch of H was posted and we know that that
see H.
was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
But that's not possible if H is hidden. PO seems to think that H doesn't matter because its behaviour can be inferred, but here he is wrong.
As for should we simply dismiss what PO is saying, it's reasonable to
do that to all people who claim to have "solved the halting problem" or otherwise refuted established results. It's even maybe reasonable to
dismiss people who post on Usenet claiming to have solved long-
standing open problems which aren't known to be insoluble. And that
might be a kindness to the proposer in the long run. But that bridge has
long since been crossed.
On 6/15/2022 5:05 AM, Malcolm McLean wrote:
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can'tThat's only partly true. A sketch of H was posted and we know that that
see H.
was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
But that's not possible if H is hidden. PO seems to think that H doesn't
matter because its behaviour can be inferred, but here he is wrong.
Its behavior is stipulated to only execute x86 emulation on its input
until a non-halting behavior pattern is recognized.
WHY IS IT SO IMPOSSIBLY DIFFICULT FOR YOU TO UNDERSTAND THIS?
Appendix I analyzes P(P) versus H(P,P)
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
As for should we simply dismiss what PO is saying, it's reasonable to
do that to all people who claim to have "solved the halting problem" or
otherwise refuted established results. It's even maybe reasonable to
dismiss people who post on Usenet claiming to have solved long-
standing open problems which aren't known to be insoluble. And that
might be a kindness to the proposer in the long run. But that bridge has
long since been crossed.
When my work is evaluated from a purely software engineering point of
view: It is very obviously correct that the input to H(P,P) does meet
this criteria, thus the complete x86 emulation of the input to H(P,P)
would never reach its "ret" instruction.
The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a complete emulation of the input would never stop running, or reach its “ret” instruction then the SHD aborts its emulation and correctly
returns 0.
I finally had one reviewer that did not lie about this.
It took a dozen forums 100 reviewers one year and thousands of messages
to find one reviewer that did not lie about very obviously correct
software engineering.
It is almost like I claim that 2 + 3 = 5 and most of the reviewers said
they simply don't believe in numbers and the rest said that even if
numbers do exist they could not be added together.
#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]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P [0000137a](05) 6852130000 push 00001352 // push P [0000137f](05) e81efeffff call 000011a2 // call H [00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = " [0000138d](05) e8e0f0ffff call 00000472 // call Output [00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[00001372][0010229e][00000000] 55 push ebp ...[00001373][0010229e][00000000] 8bec mov ebp,esp ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08] ...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
// The emulated H emulates the first seven instructions of P ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
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.
...[00001384][0010229e][00000000] 83c408 add esp,+08 ...[00001387][0010229a][00000000] 50 push eax ...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08 ...[00001395][0010229e][00000000] 33c0 xor eax,eax ...[00001397][001022a2][00100000] 5d pop ebp ...[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can'tThat's only partly true. A sketch of H was posted and we know that that
see H.
was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre.
PO has studiously avoided saying what the new mantra means.
That's
deliberate. He knows full well that H(X,Y) should report on the
behaviour of X(Y) but all of his previous wordings were just a little
too clear. Things like "yes, but H_Hat(H_Hat) only halts because H
stops it" and "H_Hat(H_Hat) would be non-terminating if line 15 were commented out".
Everything for the last couple of years has been a linguistic exercise,
not a technical one. Sure, some technical-looking things have been
posted like deliberately deceptive edited traces, but the gist of all
his posts has been to find some wording that can keep the discussion
going. Once it was 100% clear that he is determined to assert that H(H_Hat,H_Hat) == 0 is correct even though H_Hat(H_Hat) "halts" the game
was up, from a technical point of view.
The obvious way to answer it is to dry-run P(P).
He posted a trace of P(P) halting. H (deliberately not traced) spots
the magic pattern and returns 0 so P(P) halts.
But that's not possible if H is hidden. PO seems to think that H doesn't
matter because its behaviour can be inferred, but here he is wrong.
Surely you don't believe PO is being sincere about that? He know he
can't post H. He knows he can't even post the trace of H's execution
which is why the traces are edited. If H simply "didn't matter", why go
to the bother of editing the traces?
As for should we simply dismiss what PO is saying, it's reasonable to
do that to all people who claim to have "solved the halting problem" or
otherwise refuted established results. It's even maybe reasonable to
dismiss people who post on Usenet claiming to have solved long-
standing open problems which aren't known to be insoluble. And that
might be a kindness to the proposer in the long run. But that bridge has
long since been crossed.
I of all people can't advocate for dismissing what he is saying since
I've spent so long replying myself, and I've only stopped because he
called me a sadistic liar and there are some things that are just beyond
the pale for me.
Yes, it is clear to us humans watching
it that the program is repeating itself.
Thus we can appreciate that it will never
reach the final "ret" - indeed, it won't
even get to the infinite loop identified above.
It seems to be that stating that H(P,P) == 0 is wrong because P(P) halts
is all that needs to said. His reply, that P(P) is a non-input can be explained a few times, but exactly how H gets the wrong answer is not interesting to me.
I thought PO /might/ like to learn why his "P(P) is a non-input"
argument is rubbish, but he fell at the very first hurdle in my proposed exercises. It's possible that he really can't write a parity checking
Turing machine, but I think it's more likely that he could see what's
coming so he sabotaged the "learning" with all that "got to write a TM interpreter of my own" nonsense. (Were did that go, I wonder?)
Richard Damon <Richard@Damon-Family.org> writes:
On 6/15/22 7:17 AM, Ben Bacarisse wrote:<cut>
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
<cut>But that's not possible if H is hidden. PO seems to think that H doesn't >>>> matter because its behaviour can be inferred, but here he is wrong.
Surely you don't believe PO is being sincere about that? He know he
can't post H. He knows he can't even post the trace of H's execution
which is why the traces are edited. If H simply "didn't matter", why go >>> to the bother of editing the traces?
I thought PO /might/ like to learn why his "P(P) is a non-input"
argument is rubbish, but he fell at the very first hurdle in my proposed >>> exercises. It's possible that he really can't write a parity checking
Turing machine, but I think it's more likely that he could see what's
coming so he sabotaged the "learning" with all that "got to write a TM
interpreter of my own" nonsense. (Were did that go, I wonder?)
To be honest, it might not be "deliberate" in a conscious manner, but
is sub-conscious distracting him keeping him from seeing something
that he is unwilling to accept.
Ultimately, his problem is a wrong definition of wher Truth comes
from. Natural Lanugage isn't a source of truth, and can't be, because
it is a human creation, not a "natural" one. Just like his Theology
seems to stem from reality coming out of the individual, he seems to
believe that people get to create their own Truth, which goes against
the accepted definitions.
That's an interesting perspective. It seems impossible that anyone
could sustain that view for long, but there's nowt so queer as folk.
On 6/15/2022 9:03 AM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:
On 6/15/22 7:17 AM, Ben Bacarisse wrote:<cut>
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
<cut>But that's not possible if H is hidden. PO seems to think that H
doesn't
matter because its behaviour can be inferred, but here he is wrong.
Surely you don't believe PO is being sincere about that? He know he
can't post H. He knows he can't even post the trace of H's execution >>>> which is why the traces are edited. If H simply "didn't matter",
why go
to the bother of editing the traces?
I thought PO /might/ like to learn why his "P(P) is a non-input"
argument is rubbish, but he fell at the very first hurdle in my
proposed
exercises. It's possible that he really can't write a parity checking >>>> Turing machine, but I think it's more likely that he could see what's
coming so he sabotaged the "learning" with all that "got to write a TM >>>> interpreter of my own" nonsense. (Were did that go, I wonder?)
To be honest, it might not be "deliberate" in a conscious manner, but
is sub-conscious distracting him keeping him from seeing something
that he is unwilling to accept.
Ultimately, his problem is a wrong definition of wher Truth comes
from. Natural Lanugage isn't a source of truth, and can't be, because
it is a human creation, not a "natural" one. Just like his Theology
seems to stem from reality coming out of the individual, he seems to
believe that people get to create their own Truth, which goes against
the accepted definitions.
That's an interesting perspective. It seems impossible that anyone
could sustain that view for long, but there's nowt so queer as folk.
The notion of truth can be easily formalized using a very simple system
that making the Tarski Undefinability theorem (that "proves" truth
cannot be formalized") seem quite ridiculous.
Here is the Tarski proof.
https://liarparadox.org/Tarski_275_276.pdf
Within correct reasoning (not quite the same thing as logic)
One can know that an expression of natural or formal language is true
one of two ways:
(1) It is stipulated to be true like Haskell Curry elementary theorems
Then the elementary statements which belong to T we shall
call the elementary theorems of T; we also say that these
elementary statements are true for T. Thus, given T, an
elementary theorem is an elementary statement which is true.
https://www.liarparadox.org/Haskell_Curry_45.pdf
It is by this exact same process that we know that a cat is
an animal and not an office building. Natural language has
its own set of elementary theorems.
(2) Expressions of language that are derived by applying truth
preserving operations to (1)
When we do this many undecidable problems cease to exist.
An expression of language that is true and unprovable cannot possibly
exist. It is either provable or untrue.
To the same extent that logic systems diverge from this framework they diverge from correct reasoning. We have to go all the way back to the syllogism to find a logic system that does not diverge from this framework.
On 6/15/2022 6:17 AM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can't >>>>> see H.That's only partly true. A sketch of H was posted and we know that that >>>> was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre.
PO has studiously avoided saying what the new mantra means.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
So when I say that the provably correct execution traces in Appendix I
show that P(P) halts and the correct and complete x86 emulation of the
input to H(P,P) never reaches the "ret" instruction of this input these
words are pure nonsense gibberish to you?
That's
deliberate. He knows full well that H(X,Y) should report on the
behaviour of X(Y) but all of his previous wordings were just a little
too clear. Things like "yes, but H_Hat(H_Hat) only halts because H
stops it" and "H_Hat(H_Hat) would be non-terminating if line 15 were
commented out".
I proved otherwise in my Appendix I
Everything for the last couple of years has been a linguistic exercise,
not a technical one. Sure, some technical-looking things have been
posted like deliberately deceptive edited traces, but the gist of all
That is libelous.
his posts has been to find some wording that can keep the discussion
going. Once it was 100% clear that he is determined to assert that
H(H_Hat,H_Hat) == 0 is correct even though H_Hat(H_Hat) "halts" the game
was up, from a technical point of view.
The obvious way to answer it is to dry-run P(P).
He posted a trace of P(P) halting. H (deliberately not traced) spots
the magic pattern and returns 0 so P(P) halts.
If one simply assumes that H runs an x86 emulator on its input until H correctly determines that its complete and correct simulation of its
input wold never stop running then one sees that the behavior of P is consistent with this. It is quite ridiculous that this is too hard for you.
Here is a tutorial if you are utterly clueless about the x86 language. https://www.cs.virginia.edu/~evans/cs216/guides/x86.html
But that's not possible if H is hidden. PO seems to think that H doesn't >>> matter because its behaviour can be inferred, but here he is wrong.
Even if H dances the Gig and runs a house of prostitution on the side we
can see on the basis of the behavior of P that H has performed a correct
x86 emulation on its input until this input matches a non-halting
behavior pattern.
Surely you don't believe PO is being sincere about that? He know he
can't post H. He knows he can't even post the trace of H's execution
which is why the traces are edited. If H simply "didn't matter", why go
to the bother of editing the traces?
I will be able to post the source-code relatively soon. The one thing
that was holding me back was transforming the algorithm that H uses to
decide the halt status for P into a pure function of its inputs.
If I claim that 2 + 3 = 5, it is easy to see that this is correct.
If there are sixty pages of code between each of the above five elements
then it takes a lot of work to see that I even said 2 + 3 = 5.
As for should we simply dismiss what PO is saying, it's reasonable to
do that to all people who claim to have "solved the halting problem" or
otherwise refuted established results. It's even maybe reasonable to
dismiss people who post on Usenet claiming to have solved long-
standing open problems which aren't known to be insoluble. And that
might be a kindness to the proposer in the long run. But that bridge has >>> long since been crossed.
I of all people can't advocate for dismissing what he is saying since
I've spent so long replying myself, and I've only stopped because he
called me a sadistic liar and there are some things that are just beyond
the pale for me.
I apologize for this. Because everyone was refusing to affirm that the correct and complete x86 emulation of the input to H(P,P) never reached
the "ret" instruction of P and this is so very easy to confirm as a fact
it seemed reasonable to call everyone refusing to affirm this a liar.
When you finally said that you neither affirm nor deny this, then and
only then did I have proof that you are not a liar on this point.
It took one year, one hundred reviewers across dozens of forums and
thousands of messages before one reviewer provided a step-by-step
analysis of my code and affirmed:
On 6/14/2022 6:47 AM, Paul N wrote:
Yes, it is clear to us humans watching
it that the program is repeating itself.
Thus we can appreciate that it will never
reach the final "ret" - indeed, it won't
even get to the infinite loop identified above.
It seems to be that stating that H(P,P) == 0 is wrong because P(P) halts
is all that needs to said. His reply, that P(P) is a non-input can be
explained a few times, but exactly how H gets the wrong answer is not
interesting to me.
I explain this in in my Appendix I, I won't go through it again here.
I thought PO /might/ like to learn why his "P(P) is a non-input"
argument is rubbish, but he fell at the very first hurdle in my proposed
exercises. It's possible that he really can't write a parity checking
I got sick then my now homeless friend needed help getting a home.
I plan on getting back to that, yet not until I complete the changes to
H so that it can be published.
Turing machine, but I think it's more likely that he could see what's
coming so he sabotaged the "learning" with all that "got to write a TM
interpreter of my own" nonsense. (Were did that go, I wonder?)
I was sick.
On 15/06/2022 11:05, Malcolm McLean wrote:
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:PO recently (yesterday?) posted one of his traces with P(P) halting.
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can'tThat's only partly true. A sketch of H was posted and we know that that
see H.
was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
But that's not possible if H is hidden. PO seems to think that H doesn't
matter because its behaviour can be inferred, but here he is wrong.
Inside that trace, we see P call H, and immediately after that in the
trace we see NOT H trace entries (all suppressed), but the trace entries
from "H simulating the input to H(P,P)" - i.e. exactly the trace entries
PO claims are substantially different from the computation steps of P(P)
[aka "running" P(P) directly].
So, /are/ they substantially different? NOT IN THE SLIGHTEST! (As I've suggested a few times, but the evidence is there in PO's own post...)
All we see is that H simulating P(P) calculates EXACTLY the same entries
as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS SIMULATION. Not
one shred of any evidence of diversion!
Of course, it's true we don't see the suppressed H entries, but I don't
see any reason to think those would be any different if included. PO is simply confused by his own code, and invents silly PSR explanations to
try to justify it all to himself. The explanation is obvious to anyone who's analysed - H mistakenly decides it sees non-halting behaviour and
so stops simulating, whereas the computation itself (while containing
the pattern H spotted - nobody denies that I think) proceeds further and after a short while halts. (PO's rule is unsound, and why shouldn't it
be - he's never felt the need to offer any /proof/ that it's sound. He
just really really really realy thinks it is!)
The most PO could come up with to explain this would be "ok, P(P) and
H's simulation of the input to H(P,P) /are/ identical step for step as
far as H simulates, so the difference in computation states /must/ occur
in the computation steps that H never got to!".
That's Dumb, Dumb,
Dumb thinking, but it wouldn't surprise me if that's what PO eventually
comes up with... (He's not capable of thinking it through rationally.)
Mike.
As for should we simply dismiss what PO is saying, it's reasonable to
do that to all people who claim to have "solved the halting problem" or
otherwise refuted established results. It's even maybe reasonable to
dismiss people who post on Usenet claiming to have solved long-
standing open problems which aren't known to be insoluble. And that
might be a kindness to the proposer in the long run. But that bridge has
long since been crossed.
On 6/15/2022 6:31 PM, Mike Terry wrote:
On 15/06/2022 11:05, Malcolm McLean wrote:
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:PO recently (yesterday?) posted one of his traces with P(P) halting.
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can't >>>>> see H.That's only partly true. A sketch of H was posted and we know that that >>>> was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre. The obvious way to answer it is to dry-run P(P). >>> But that's not possible if H is hidden. PO seems to think that H doesn't >>> matter because its behaviour can be inferred, but here he is wrong.
Inside that trace, we see P call H, and immediately after that in the
trace we see NOT H trace entries (all suppressed), but the trace
entries from "H simulating the input to H(P,P)" - i.e. exactly the
trace entries PO claims are substantially different from the
computation steps of P(P) [aka "running" P(P) directly].
So, /are/ they substantially different? NOT IN THE SLIGHTEST! (As
I've suggested a few times, but the evidence is there in PO's own
post...)
All we see is that H simulating P(P) calculates EXACTLY the same
entries as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS
SIMULATION. Not one shred of any evidence of diversion!
Of course, it's true we don't see the suppressed H entries, but I
don't see any reason to think those would be any different if
included. PO is simply confused by his own code, and invents silly
PSR explanations to try to justify it all to himself. The explanation
is obvious to anyone who's analysed - H mistakenly decides it sees
non-halting behaviour and so stops simulating, whereas the computation
itself (while containing the pattern H spotted - nobody denies that I
think) proceeds further and after a short while halts. (PO's rule is
unsound, and why shouldn't it be - he's never felt the need to offer
any /proof/ that it's sound. He just really really really realy
thinks it is!)
It is the case that the correct and complete x86 emulation of the input
to H(P,P) never reaches its "ret" instruction and on this basis it is
correct to say that it is non-halting.
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
The most PO could come up with to explain this would be "ok, P(P) and
H's simulation of the input to H(P,P) /are/ identical step for step as
far as H simulates, so the difference in computation states /must/
occur in the computation steps that H never got to!".
I never say anything like that. It is ridiculously simple for any fully competent software engineer to easily determine that
the correct and complete x86 emulation of the input to H(P,P) never
reaches its "ret" instruction.
That's Dumb, Dumb, Dumb thinking, but it wouldn't surprise me if
that's what PO eventually comes up with... (He's not capable of
thinking it through rationally.)
Mike.
As for should we simply dismiss what PO is saying, it's reasonable to
do that to all people who claim to have "solved the halting problem" or
otherwise refuted established results. It's even maybe reasonable to
dismiss people who post on Usenet claiming to have solved long-
standing open problems which aren't known to be insoluble. And that
might be a kindness to the proposer in the long run. But that bridge has >>> long since been crossed.
On 15/06/2022 11:05, Malcolm McLean wrote:
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:PO recently (yesterday?) posted one of his traces with P(P) halting.
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can'tThat's only partly true. A sketch of H was posted and we know that that
see H.
was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
But that's not possible if H is hidden. PO seems to think that H doesn't
matter because its behaviour can be inferred, but here he is wrong.
Inside that trace, we see P call H, and immediately after that in the
trace we see NOT H trace entries (all suppressed), but the trace entries
from "H simulating the input to H(P,P)" - i.e. exactly the trace entries
PO claims are substantially different from the computation steps of P(P)
[aka "running" P(P) directly].
So, /are/ they substantially different? NOT IN THE SLIGHTEST! (As I've suggested a few times, but the evidence is there in PO's own post...)
All we see is that H simulating P(P) calculates EXACTLY the same entries
as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS SIMULATION. Not
one shred of any evidence of diversion!
Of course, it's true we don't see the suppressed H entries, but I don't
see any reason to think those would be any different if included. PO is simply confused by his own code, and invents silly PSR explanations to
try to justify it all to himself. The explanation is obvious to anyone who's analysed - H mistakenly decides it sees non-halting behaviour and
so stops simulating, whereas the computation itself (while containing
the pattern H spotted - nobody denies that I think) proceeds further and after a short while halts. (PO's rule is unsound, and why shouldn't it
be - he's never felt the need to offer any /proof/ that it's sound. He
just really really really realy thinks it is!)
The most PO could come up with to explain this would be "ok, P(P) and
H's simulation of the input to H(P,P) /are/ identical step for step as
far as H simulates, so the difference in computation states /must/ occur
in the computation steps that H never got to!". That's Dumb, Dumb,
Dumb thinking, but it wouldn't surprise me if that's what PO eventually
comes up with... (He's not capable of thinking it through rationally.)
Mike.
On 6/15/2022 6:31 PM, Mike Terry wrote:
On 15/06/2022 11:05, Malcolm McLean wrote:
On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:PO recently (yesterday?) posted one of his traces with P(P) halting.
Malcolm McLean <malcolm.ar...@gmail.com> writes:The current claim is that the direct execution of P(P) has different
We're dealing with our hands tied behind our backs, because we can't >>>>> see H.That's only partly true. A sketch of H was posted and we know that that >>>> was wrong. And we know that H is wrong by definition because H(X,Y)
does not report on the "halting" of X(Y). There are other detailed
errors we can't critique without the actual H, but do you really care
about those details?
behavior to the correct simulation of the input to H(P,P).
This is pretty bizarre. The obvious way to answer it is to dry-run P(P). >>> But that's not possible if H is hidden. PO seems to think that H doesn't >>> matter because its behaviour can be inferred, but here he is wrong.
Inside that trace, we see P call H, and immediately after that in the
trace we see NOT H trace entries (all suppressed), but the trace
entries from "H simulating the input to H(P,P)" - i.e. exactly the
trace entries PO claims are substantially different from the
computation steps of P(P) [aka "running" P(P) directly].
So, /are/ they substantially different? NOT IN THE SLIGHTEST! (As
I've suggested a few times, but the evidence is there in PO's own
post...)
All we see is that H simulating P(P) calculates EXACTLY the same
entries as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS
SIMULATION. Not one shred of any evidence of diversion!
Of course, it's true we don't see the suppressed H entries, but I
don't see any reason to think those would be any different if
included. PO is simply confused by his own code, and invents silly
PSR explanations to try to justify it all to himself. The explanation
is obvious to anyone who's analysed - H mistakenly decides it sees
non-halting behaviour and so stops simulating, whereas the computation
itself (while containing the pattern H spotted - nobody denies that I
think) proceeds further and after a short while halts. (PO's rule is
unsound, and why shouldn't it be - he's never felt the need to offer
any /proof/ that it's sound. He just really really really realy
thinks it is!)
The most PO could come up with to explain this would be "ok, P(P) and
H's simulation of the input to H(P,P) /are/ identical step for step as
far as H simulates, so the difference in computation states /must/
occur in the computation steps that H never got to!". That's Dumb,
Dumb, Dumb thinking, but it wouldn't surprise me if that's what PO
eventually comes up with... (He's not capable of thinking it through
rationally.)
Mike.
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", 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]
(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret" instruction it remains stuck in repeated cycles of emulation.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.
(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.
*technically competent honest reviewers will know that*
Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.
The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never reach
its "ret" instruction as a pure function of its inputs.
Now that I finally figured out a very simple way to transform H(P,P)==0
into a pure function of its inputs I will be able to provide the
source-code proving this. I refrained from providing the source-code
before because I knew it would be rejected for using static local memory.
Since the above does prove that H(P,P)==0 is correct whether or not H
can compute this and we know that P(P) halts then
*technically competent honest reviewers* will know that the behavior of
the simulated input is not the same as the directly executed input.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 119:06:00 |
| Calls: | 6,662 |
| Files: | 12,210 |
| Messages: | 5,334,367 |