Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

[olcott]

On 7/16/2022 10:54 AM, Mike Terry wrote:
> On 16/07/2022 12:23, Paul N wrote:
> PO's simulation is correct at the individual instruction level.
> His H steps the simulation forward a number of steps, and each
> of those steps exactly matches the P(P) calculation steps.

We can see from the x86 execution trace of the simulated P that the
behavior of this simulated P exactly matches its x86 source-code,
line-by-line.

What we can also see from this same execution trace is that when H calls
H(P,P) the simulated P remains stuck calling H(P,P) to simulate itself
again thus forever preventing this simulated P from ever terminating
normally by reaching its C:"return" or x86:"ret" instruction.

*H(P,P) correctly determines that its input never halts*

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

_P()
[000013c6](01) 55 push ebp // Save Base Pointer
register onto the stack
[000013c7](02) 8bec mov ebp,esp // Load Base Pointer
with Stack Pointer
[000013c9](01) 51 push ecx // Save the value of
ecx on the stack
[000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax with
argument to P
[000013cd](01) 50 push eax // push 2nd argument
to H onto the stack
[000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx with with
argument to P
[000013d1](01) 51 push ecx // push 1st argument
to H onto the stack
[000013d2](05) e82ffdffff call 00001106 // push return address
on the stack; call simulated H
[000013d7](03) 83c408 add esp,+08 // remove call
arguments from stack
[000013da](03) 8945fc mov [ebp-04],eax // load Halt_Status
with return value from H
[000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare Halt_Status
to 0
[000013e1](02) 7402 jz 000013e5 // if Halt_Status == 0
goto 000013e5
[000013e3](02) ebfe jmp 000013e3 // goto 13e3
[000013e5](02) 8be5 mov esp,ebp // Load Stack Pointer
with Base Pointer
[000013e7](01) 5d pop ebp // Restore Base
Pointer value from stack
[000013e8](01) c3 ret // return to caller
Size in bytes:(0035) [000013e8]

_main()
[000013f6](01) 55 push ebp // Save Base Pointer register
onto the stack
[000013f7](02) 8bec mov ebp,esp // Load Base Pointer with Stack
Pointer
[000013f9](05) 68c6130000 push 000013c6 // Push P (2nd argument to H)
onto the stack
[000013fe](05) 68c6130000 push 000013c6 // Push P (1nd argument to H)
onto the stack
[00001403](05) e8fefcffff call 00001106 // push return address onto the
stack and call executed H
[00001408](03) 83c408 add esp,+08 // remove call arguments from
stack frame
[0000140b](01) 50 push eax // Push return value from H
onto the stack
[0000140c](05) 6837050000 push 00000537 // Push address of "Input_Halts
= " onto the stack
[00001411](05) e870f1ffff call 00000586 // call Output with its pushed
arguments.
[00001416](03) 83c408 add esp,+08 // remove call arguments from
stack frame
[00001419](02) 33c0 xor eax,eax // set eax to 0
[0000141b](01) 5d pop ebp // Restore Base Pointer
register from stack
[0000141c](01) c3 ret // return to 0 operating system
Size in bytes:(0039) [0000141c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000013f6][0010235f][00000000] 55 push ebp
[000013f7][0010235f][00000000] 8bec mov ebp,esp
[000013f9][0010235b][000013c6] 68c6130000 push 000013c6 // Push P (2nd
argument to H) onto the stack
[000013fe][00102357][000013c6] 68c6130000 push 000013c6 // Push P (1nd
argument to H) onto the stack
[00001403][00102353][00001408] e8fefcffff call 00001106 // push return
address; call executed H

H: Begin Simulation Execution Trace Stored at:11240b
Address_of_H:1106
[000013c6][001123f7][001123fb] 55 push ebp
[000013c7][001123f7][001123fb] 8bec mov ebp,esp
[000013c9][001123f3][001023c7] 51 push ecx // Save the
value of ecx on the stack
[000013ca][001123f3][001023c7] 8b4508 mov eax,[ebp+08] // Load eax
with argument to P
[000013cd][001123ef][000013c6] 50 push eax // push 2nd
argument to H onto the stack
[000013ce][001123ef][000013c6] 8b4d08 mov ecx,[ebp+08] // Load ecx
with with argument to P
[000013d1][001123eb][000013c6] 51 push ecx // push 1st
argument to H onto the stack
[000013d2][001123e7][000013d7] e82ffdffff call 00001106 // push
return address; call simulated H
H: Infinitely Recursive Simulation Detected Simulation Stopped

[00001408][0010235f][00000000] 83c408 add esp,+08
[0000140b][0010235b][00000000] 50 push eax // Push return
value from H onto the stack
[0000140c][00102357][00000537] 6837050000 push 00000537 // Push address
of "Input_Halts = " onto stack
[00001411][00102357][00000537] e870f1ffff call 00000586 // call Output
with its pushed arguments
Input_Halts = 0
[00001416][0010235f][00000000] 83c408 add esp,+08
[00001419][0010235f][00000000] 33c0 xor eax,eax // set eax to 0
[0000141b][00102363][00000018] 5d pop ebp
[0000141c][00102367][00000000] c3 ret // return to 0
operating system
Number of Instructions Executed(987) == 15 Pages



--
Copyright 2022 Pete Olcott

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

[Richard Damon]

On 7/16/22 11:11 PM, olcott wrote:
> On 7/16/2022 10:54 AM, Mike Terry wrote:
> > On 16/07/2022 12:23, Paul N wrote:
> > PO's simulation is correct at the individual instruction level.
> > His H steps the simulation forward a number of steps, and each
> > of those steps exactly matches the P(P) calculation steps.
>
> We can see from the x86 execution trace of the simulated P that the
> behavior of this simulated P exactly matches its x86 source-code,
> line-by-line.
>
> What we can also see from this same execution trace is that when H calls
> H(P,P) the simulated P remains stuck calling H(P,P) to simulate itself
> again thus forever preventing this simulated P from ever terminating
> normally by reaching its C:"return" or x86:"ret" instruction.

Except it doesn't because H is KNOWN to abort its simulation when it
sees that the simulation will reach the first call to H in the simulation.

You logic is based on the assumption that H actually won't stop
simulating its input, when in actual fact it will. Thus you have a false
premise in your logic, so H never actually proved its fact considering
the H that it is.

Yes, H can prove that IF H never aborts, that this makes a P that never
halts. But since this is NOT the definition of H, that doesn't say
anything about what the machine where H does abort its simulation.

This points us to the fundamental issue, you are using an unproven
definition of what a Halting Decider decides on. The REAL definition is
based on if the machine when run will come to a halt or not.

Your definition is based on the potentially partial simulation by H, you
need to prove the condtions match, EVEN IF THE INPUT REFERS TO THE
DECIDER H (since that is an allowed condition).

In particular, you definition must match the results for the program P
as defined or it is proved to not be equivalent, which it does not.

>
> *H(P,P) correctly determines that its input never halts*

FALSE. You use an incorrect rule. The fact that P(P) calls H(P,P) with
no conditional in P does NOT prove that its input will never halt if H
has code that detects this case and stops its simulation, as that
demonstartionally doesn't have infinite behavior.

H needs to look at the program that IS there, including ALL the behavior
of H which is part of it.

[olcott]

On 7/17/2022 6:37 AM, Richard Damon wrote:
> On 7/16/22 11:11 PM, olcott wrote:
>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>  > On 16/07/2022 12:23, Paul N wrote:
>>  > PO's simulation is correct at the individual instruction level.
>>  > His H steps the simulation forward a number of steps, and each
>>  > of those steps exactly matches the P(P) calculation steps.
>>
>> We can see from the x86 execution trace of the simulated P that the
>> behavior of this simulated P exactly matches its x86 source-code,
>> line-by-line.
>>
>> What we can also see from this same execution trace is that when H
>> calls H(P,P) the simulated P remains stuck calling H(P,P) to simulate
>> itself again thus forever preventing this simulated P from ever
>> terminating normally by reaching its C:"return" or x86:"ret" instruction.
>
> Except it doesn't because H is KNOWN to abort its simulation when it
> sees that the simulation will reach the first call to H in the simulation.
>
> You logic is based on the assumption that H actually won't stop
> simulating its input, when in actual fact it will. Thus you have a false
> premise in your logic, so H never actually proved its fact considering
> the H that it is.
>
> Yes, H can prove that IF H never aborts, that this makes a P that never
> halts. But since this is NOT the definition of H, that doesn't say
> anything about what the machine where H does abort its simulation.
>

Halting means terminated normally when the correctly simulated P reaches
its last instruction. Even though I have corrected you on this many
hundreds of times you still fail to understand that an aborted
simulation does not mean that the simulated input halted. You are
moronically stupid on this point.

Unless the concept of a UTM is bogus the actual behavior of the
correctly simulated input does specify the behavior that H must examine.

As soon as any simulating halt decider correctly determines that its
simulated input would never terminate normally it is correct to report
this simulation and report non-halting.

> This points us to the fundamental issue, you are using an unproven
> definition of what a Halting Decider decides on. The REAL definition is
> based on if the machine when run will come to a halt or not.
>
> Your definition is based on the potentially partial simulation by H, you
> need to prove the condtions match,

I did do this you just aren't smart enough to understand.

(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.

The above shows that the simulated P cannot possibly (reachs it “return”
instruction and) terminate normally. H(P,P) simulates its input then P
calls H(P,P) to simulate itself again. When H sees that this otherwise
infinitely nested simulation would never end it aborts its simulation of
P and rejects P as non-halting.

> EVEN IF THE INPUT REFERS TO THE
> DECIDER H (since that is an allowed condition).
>
> In particular, you definition must match the results for the program P
> as defined or it is proved to not be equivalent, which it does not.

Then you continue to reject the concept of a UTM.

[olcott]

On 7/17/2022 6:37 AM, Richard Damon wrote:

> On 7/16/22 11:11 PM, olcott wrote:
>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>  > On 16/07/2022 12:23, Paul N wrote:
>>  > PO's simulation is correct at the individual instruction level.
>>  > His H steps the simulation forward a number of steps, and each
>>  > of those steps exactly matches the P(P) calculation steps.
>>
>> We can see from the x86 execution trace of the simulated P that the
>> behavior of this simulated P exactly matches its x86 source-code,
>> line-by-line.
>>
>> What we can also see from this same execution trace is that when H
>> calls H(P,P) the simulated P remains stuck calling H(P,P) to simulate
>> itself again thus forever preventing this simulated P from ever
>> terminating normally by reaching its C:"return" or x86:"ret" instruction.
>
> Except it doesn't because H is KNOWN to abort its simulation when it
> sees that the simulation will reach the first call to H in the simulation.

The problem here is that you remain moronically stupid on this point,
initially took it as dishonesty because I would not believe that someone
was actually that stupid.

*Mike already corrected you on this moronically stupid point*

On 7/16/2022 2:28 PM, Mike Terry wrote:
> On 16/07/2022 17:40, Richard Damon wrote:
>> But "incomplete" is incorrect if your logic assumes that the
>> simulation not reaching the final state PROVES non-halting.
>
> I don't believe PO thinks that, irrespective of how badly he explains
> things. I think he believes that the simulation would never halt
> *because his never-halting-abort test matched*, NOT simply as a
> consequence of aborting. E.g. he seems to understand that a simulator
> that steps 10 steps then stops regardless, does not imply that the
> simulated computation does not halt.

[Richard Damon]

And YOU are the moron for thinking that just because a simulation was
aborted the CORRECT simulation of that input can't continue to reach the
final state.

An Aborted Simulation is not a complete and correct simulation that
shows if a machine halts. Non-Halting means that the machihe itself, or
a complete and correct emulation of the machine will never halt.

>
> Unless the concept of a UTM is bogus the actual behavior of the
> correctly simulated input does specify the behavior that H must examine.

The actual behavior of the correctly simulated input is exactly what a
UTM can show. You give the UTM the same input as the H that aborted its
simulation, and the UTM's behavior will either confirm or disprove the
decided behavior of the Halt Decider.

>
> As soon as any simulating halt decider correctly determines that its
> simulated input would never terminate normally it is correct to report
> this simulation and report non-halting.

Right, if it CORRECTLY determines that its simulated input, using ALL
the behavior of that simulated input, would never terminate.

Thus, if H might abort its simulation and return 0, then when H sees a
call to H, it needs to take into account that that H being called might
do the same, and in fact WILL do the same as this H if it has the same
input.

Thus, if H starts to decide that it will declair the input non-halting,
it needs to look at the input as if the call to H will return a 0 and
make sure the answer is still correct, NOT just assume that the H will
continue simulating, since H is thinking of doing something else.

>
>
>> This points us to the fundamental issue, you are using an unproven
>> definition of what a Halting Decider decides on. The REAL definition
>> is based on if the machine when run will come to a halt or not.
>>
>> Your definition is based on the potentially partial simulation by H,
>> you need to prove the condtions match,
>
> I did do this you just aren't smart enough to understand.
>
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.

AGAIN. (3) is INCORRECT. But apparently you are too stupid to understand
that because apparently you failed your first year of computer science.

>
> The above shows that the simulated P cannot possibly (reachs it “return”
> instruction and) terminate normally. H(P,P) simulates its input then P
> calls H(P,P) to simulate itself again. When H sees that this otherwise
> infinitely nested simulation would never end it aborts its simulation of
> P and rejects P as non-halting.

False premises NEVER prove anything. Fix your rule (3) or you are just
spreading lies.

>
>
>> EVEN IF THE INPUT REFERS TO THE DECIDER H (since that is an allowed
>> condition).
>>
>> In particular, you definition must match the results for the program P
>> as defined or it is proved to not be equivalent, which it does not.
>
> Then you continue to reject the concept of a UTM.
>

> Nope. Your H isn't a UTM, because it fails to meet the definition.

You also seemed to have failed English, as you don't understand what a
definition means.

UTM(P,P) will Halt if H(P,P) return 0, thus showing that H(P,P) is wrong
even by the definition of correct simulation.

FAIL.

[olcott]

Your replies are moronically stupid because they always make sure to
maimtain the same false assumptions (utterly impervious to all reason)
even when these false assumptions corrected hundreds of times.

On 7/16/2022 2:28 PM, Mike Terry wrote:
> On 16/07/2022 17:40, Richard Damon wrote:
>> But "incomplete" is incorrect if your logic assumes that the
>> simulation not reaching the final state PROVES non-halting.
>
> I don't believe PO thinks that, irrespective of how badly he explains
> things. I think he believes that the simulation would never halt
> *because his never-halting-abort test matched*, NOT simply as a
> consequence of aborting. E.g. he seems to understand that a simulator
> that steps 10 steps then stops regardless, does not imply that the
> simulated computation does not halt.

[Richard Damon]

NAME ONE FALSE ASSUMPTION!

(Not something that you think the defintion is wrong, but where I am
"assuming" something that factually isn't true)

FAILURE TO GIVE A SPECIFIC ANSWER SHOULD BE TAKEN BY ALL THAT YOU ARE
JUST A LIAR.

[olcott]

On 7/16/2022 2:28 PM, Mike Terry wrote:
> On 16/07/2022 17:40, Richard Damon wrote:
>> But "incomplete" is incorrect if your logic assumes that the
>> simulation not reaching the final state PROVES non-halting.
>
> I don't believe PO thinks that, irrespective of how badly he explains
> things. I think he believes that the simulation would never halt
> *because his never-halting-abort test matched*, NOT simply as a
> consequence of aborting. E.g. he seems to understand that a simulator
> that steps 10 steps then stops regardless, does not imply that the
> simulated computation does not halt.

[Richard Damon]

SO, whats wrong with my statement.

An incomplete simulation not reaching a halting state does NOT prove
that the input is non-halting.

Since you use the term correct simulation to imply that it actually
shows that the input is non-halting, YOU are the one making a false
assumption that the fact that the PARTIAL simulation of that H did,
didn't reach a Halt PROVES that the input is non-halting.

The fact that P(P) Halts, and that by YOUR implementation of P, H(P,P)
must refer to the behavior of P(P), ANYTHING that says that a correct
simulation of the input to H(P,P) is non-halting is incorrect.

DEFINITION.

Yes, you present a "Proof" that the answer is correct, but it includes a
number of unsourced claims, at least one of which has been pointed out
to be incorrect.

If you take this to an arbiter of Truth, a statement based on the actual
definition (ones that YOU quote) saying one thing and a "proof" based on
unsourced and some incorrect premises, it should be obvious which one is
true, and who is being incorrect.

I STAND ON MY STATEMENT.

Do you want to put your statement to the test, what are you willing to
put up?

NEXT!

[olcott]

*Yes it does, this is simply over your head*
Once a non-halting behavior pattern is correctly matched the simulation
can be aborted and the input rejected as non-halting.

[Richard Damon]

No, you are totally wrong on that. If you say I am mistaken, which of
these statements, which PROVE my point, is in error? If none are, then
my statement is PROVEN. Note, these are based on the well established
definition of Computation Theory and statement YOU have made about your
program.

Just claiming you have proven the opposite is NOT enough, as all that
does is show that your logic system is inconsistent, because you have
added inconsistent rules to your system (likely rules that just aren't
true).

1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be
returning 0.

2) P calls H(P,P)

3) P, as the impossible program, is defined to as H about the behavior
or itself with its input

4) This means the call to H(P,P) is defined to be asking H about the
behavor of P(P)

5) The ACTUAL program P(P) when run, will return (aka Halt) if H(P,P)
returns 0. You have admited this and even posted traces of this.

6) The definition of a correct simulation is a simulation that matches
the behavior of the thing it is simulationg.

7) Therefore, since the input to H(P,P) refers to P(P) (by 4), and P(P)
is proved to halt if H(P,P) returns 0 (by 5), by the definition of
correct simulation, the correct simulation of the input to H(P,P) must halt.

8) Thus, by either the REAL definition that H needs to answer based on
the behavior of the actual machine, or by the alternate acceptable
definition that looks at a correct and complete simulation of the input,
the input to H(P,P) Halts, and thus the CORRECT answer is
Accept/Halitng/1 not the 0 it provided.

Your problem is that you say "Once" the non-halting pattern is correctly
detected, which implies that there IS a finite non-halting pattern in
the simulation of P(P) that can be detected.

It has be PROVEN that ANY pattern ih the simulation of P(P) by H that is
added to H as a claimed non-halting pattern, then that make the behavior
of that P(P) (and the correct simulation of the input to H(P,P)) to be
Halting, as when H detects that pattern in its simulation of P(P), and
returns to P, P will return (aka halt) and then when we look at the
CORRECT AND COMPLETE simulation of the input, we see that shortly after
H INCORRECTLY gave up convinced that the input was non-halting, that the
simulation then sees (as it simulates H) the simulated H making that
decision, and returning to the P that called that simulated H, and that
P then returning (aka Halting).

Thus, there does not exist a finite pattern that H can reach in finite
time to detect.

Thus, H either simulates forever and fails to be a decider, or uses an
invalid pattern and incorrectly determines non-halting and gives the
wrong anwwer.

You are presuming the existance of something not known to exist (and in
fact proven to not exist).

[olcott]

I unblocked you from comp.theory can you move your non C++/C stuff there
please?