*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

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/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
>
>
>

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On Sun, 12 Jun 2022 11:10:00 -0500
olcott <polcott2@gmail.com> 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.
>
> >      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 H you invoke from main() returns a value whilst the H you invoke
from P does not so they are not the same H. A halt decider, H, must
always return a value to its caller for it to qualify as a halt decider.

/Flibble

On Sun, 12 Jun 2022 11:07:05 -0500
olcott <NoOne@NoWhere.com> 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.
>
> 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 H you invoke from main() returns a value whilst the H you invoke
from P does not so they are not the same H. A halt decider, H, must
always return a value to its caller for it to qualify as a halt decider.

/Flibble

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?

The ONLY criterion measure of a Halt Decider is that A Halt Decider
accepts an input that represents an Halting Computation and rejects
inputs that represent a non-halting Computation.

If "Your Criteria" EVER disagrees with this, as appearently it does for
P(P), then your criteria is INVALID, and your Simulating Halt Deciders
are NOT Halt Deciders.

YOU FAIL

Remember the Rules, you don't get to make the rules, but need to live
within the established rules if you want to playan existing game (like
the Halting Problem).

Note, you might be able to actually prove that with proper definitions
that this criteria can be proven to actually match the official
criteria, but such a proof also established the definitions of those
terms and shows that no such finite "non-halting behavior pattern"
actually exists in the simulation of P(P).

This is established because if any such pattern was assumed to exist,
and put into H, the a correct and complete simulation of P(P) will see
that P(P) call a H(P,P) and it simulating to that pattern, aborting its
simulation and returning the reject (0) and P then halting. The key
thing to notice is that H simulated N steps of its simulation, and the
point that it makes that decision is at a step > N in the outer simultion.

Thus a SHD built by this rule will NEVER find a pattern that allows it
to abort, and thus never gives an answer, thus failing to be a decider,
that must answer for ALL inputs in finite time.

>
>>       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 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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/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.

That is the source of the Mapping.

The definition of the Results of that Mapping, is if P(P) Halts or not,
that is a legal (if impossible) required results.

Do you disagree that for a DEFINED H, that P(P) will definitely either
Halt or Not?

If so, we can define a mapping from the finite string representation of
P(P) to that result.

Now, part of the problem that you are running into is that you don't
seem to understand what the representation of P needs to be, it isn't
just the "C Function" P, it is the Algorithm of P, or the PROGRAM P, so
that representation needs to include EVERYTHING that P uses, thus
includes its copy of H, so it can't just be the machine code from
compiliation of just the function P.

That you fail to understand that H is ACTUALLY REQUIRED to compute this
results if it wants to be a Halt Decider, then you are showing you are
just ignorant of what this field is about.

If you claim that we can't actually ask a decider about the behavior of
a machine and input from a representation, then you are just agreeing
with the theory, that it impossible to build such a machine.

You arguement just show you don't even understan dwhat the Halting
Theorem is about.

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/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.

Thus the correct x86 emulation of the input to H(P,P) halts if P(P)
halts, and doesn't halt if P(P) doesn't halt.

Thus H(P,P) returning 0 is incorrect if P(P) Halts when H(P,P) returns
0, which it does, so that answer is unconditionally wrong to give by H.

That is basic definition.

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/12/22 2:48 PM, olcott wrote:
> 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.

If it affects H, then H is just proved not to be a compuation, or a Pure
Function.

>
> All competent software engineers will know that changing an invocation
> sequence can change the outcome.
>
>

But both are invoced the same, as H(P,P). If context matters, then H is
NOT a Computation or a Pure Function, BY DEFINITON. PERIOD.

Since being a Computation is a REQUIREMENT for a Halt Decider, if it
fails to be a Computation, it isn't a Halt Decider.

So, you just admitted that your H doesn't meet the requirements to be a
Halt Decider.

On 6/12/2022 2:04 PM, Richard Damon wrote:
> On 6/12/22 2:48 PM, olcott wrote:
>> 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.
When P(P) is executed its behavior conditionally depends on the return
value of H.

When H(P,P) is executed the correctly emulated P cannot possibly reach
the point where its behavior depends on H.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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:
>>> 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.
> When P(P) is executed its behavior conditionally depends on the return
> 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, then the CORRECT
simulation of the input to H(P,P) will do the same, because you have
DEFINED that H(P,P) WILL abort its simulation, and thus it doesn't do a
"Correct Simulation of its input".

Since you have already admitted that H doesn't ACTUALLY perform a
correct and complete emulation of its input, you can't use the logic
that if it did it would never return an answer. THAT is UNSOUND Logic.

If this IS the behavior of H, then H is NOT a pure function of its
inputs, since in both cases we are just calling H(P,P) and thus
somewhere the code is depending on something besides the input to behave
differently.

If you want to claim that H IS just a pure function of its input, but
does behave differerently, then what is the instruction that created the
first difference in behavior?

Since you claim that H only depends on its input, the inputs to that
instruction will be the same for the two cases, but the instruction does
two different things.

I don't think you can show that, because you design for H is likely not
actually a pure function of its inputs (or it is using a function that
isn't a pure function ITS inputs, which makes H not pure either).

Go ahead, prove me a liar and post what instruction behaved differently
in the two cases with the same input.

On 6/12/2022 5:16 PM, Richard Damon wrote:
> 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:
>>>> 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.
>> When P(P) is executed its behavior conditionally depends on the return
>> 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,

This is the part where you seem to be a brain dead moron.
I use these harsh terms because I have totally explained this to you
many hundreds of times.

The correctly emulated input to H(P,P) cannot possibly get any return
value from H because it keeps calling H in infinitely nested emulation
until it has its emulation aborted.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/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.
>>
>> 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.
>>
> 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.

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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.
> >>
> >> 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.
> >>
> > 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.
>
> 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 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.
>>>>
>>>> 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.
>>>>
>>> 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.
>>
>> 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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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.
> >>>>
> >>>> 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.
> >>>>
> >>> 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.
> >>
> >> 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*
>>>>>> 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.
>>>>>>
>>>>> 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.
>>>>
>>>> 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]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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.
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>> 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.
> >>>>
> >>>> 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 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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.
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>> 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.
> >>>>>>
> >>>>>> 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 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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.
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 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.

Click here to read the complete article

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.
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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
>