Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

[olcott]

(a) Verify that the execution trace of P by H is correct by comparing
this execution trace to the ax86 source-code of P.

(b) Verify that this execution trace shows that P is stuck in infinitely
nested simulation (a non-halting behavior).

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

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

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) lines = 237 pages


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

[wij]

Many problems. Pick the major one:
P is invalid, because your halting decider H is not shown to exist
(there is another reason). You can say H(..) comprises of several million
lines of source codes. But this does not matter because this is your
choice of the proof. The important thing is, as a proof, THE PROOF HAS TO BE
SHOWN existent, or it does not exist (you refuted something does not exist !!!)

[Ben]

olcott <No...@NoWhere.com> writes:

> (a) Verify that the execution trace of P by H is correct by comparing
> this execution trace to the ax86 source-code of P.

P called with what argument? I assume P.

> (b) Verify that this execution trace shows that P is stuck in
> infinitely nested simulation (a non-halting behavior).

Something is wrong in your code if P(P), or a simulation of P(P), does
not halt, since you told us that it does. Post the code and someone
will help you find the bug.

> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }

Unless you are retracting any of the facts you have previously stated,
we know (because you've told us) that H(P,P) returns 0 and we know
(because you've told us) that P(P) halts. The trace of the execution
will either confirm this, or the trace is faulty. Nothing new can come
from looking at traces of mystery code.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

[olcott]

(a) The trace is verifiably correct if one has the technical skill.
(b) The trace is proved non-halting if one has the technical skill.
You simply don't seem to have the technical skill.

I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU ERASED.

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

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

[Richard Damon]

No, it is verifiably INCORRECT for one with even a tiny bit of skill.

> (b) The trace is proved non-halting if one has the technical skill.
> You simply don't seem to have the technical skill.
>

Nope, the trace proves you are LYING about actually simulating the input.

Trace breaks here. A CORRECT Trace would now trace the operation of the
copy of H that P is using.

Also, the following never happens as code in the call to H unless H just
calls its input at which point it can't 'abort' this 'simuation'

> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>

Thus proving that H didn't just call its input (or the H being called by
P isn't the same as the H deciding on H(P,P) and thus you are lying
about build P correctly.

> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion (infinitely nested simulation) non-halting behavior pattern.

FALSE. YOU are forgetting that the H being called will (if it is the
same code as the H deciding) will also abort its simulation, thus
breaking the "infinite recursion", thus the proof is UNSOUND.

[Ben]

olcott <No...@NoWhere.com> writes:

> On 5/10/2022 10:50 AM, Ben wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> (a) Verify that the execution trace of P by H is correct by comparing
>>> this execution trace to the ax86 source-code of P.
>>
>> P called with what argument? I assume P.

You won't even correct a trivial point.

>>> (b) Verify that this execution trace shows that P is stuck in
>>> infinitely nested simulation (a non-halting behavior).
>>
>> Something is wrong in your code if P(P), or a simulation of P(P), does
>> not halt, since you told us that it does. Post the code and someone
>> will help you find the bug.

Don't you want to know what's wrong with your code? Your trace shows
that you are not even nesting any simulations so that's one error right
there. But there are clearly others.

>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>
>> Unless you are retracting any of the facts you have previously stated,
>> we know (because you've told us) that H(P,P) returns 0 and we know
>> (because you've told us) that P(P) halts. The trace of the execution
>> will either confirm this, or the trace is faulty. Nothing new can come
>> from looking at traces of mystery code.

Are you retracting any of the facts you have previously stated? If not,
you are, as you no doubt know by now, wrong by definition.

> (a) The trace is verifiably correct if one has the technical skill.

A trace is neither correct not incorrect. It just shows a (partial)
program execution. It "correctly" shows that H is not doing what you
claim (it shows no nested simulation) so maybe that means it's
"incorrect"?

> (b) The trace is proved non-halting if one has the technical skill.
> You simply don't seem to have the technical skill.

The trace shows H not doing what you claim. The fact that don't address
this gross misdirection on your part make it more a lie than an error.

> I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU
> ERASED.

There's no point in repeatedly posting a trace that it at best the wrong
one and at worst a lie. The right trace to post (again) would be the
one showing P(P) halting.

Obviously, you'd like people to talk about something other than the bald
fact that you are wrong by definition: H(P,P) == false "even though P(P)
halts" (your words).

[olcott]

On 5/10/2022 10:50 AM, Ben wrote:

> olcott <No...@NoWhere.com> writes:
>
>> (a) Verify that the execution trace of P by H is correct by comparing
>> this execution trace to the ax86 source-code of P.
>
> P called with what argument? I assume P.
>
>> (b) Verify that this execution trace shows that P is stuck in
>> infinitely nested simulation (a non-halting behavior).
>
> Something is wrong in your code if P(P), or a simulation of P(P), does
> not halt, since you told us that it does. Post the code and someone
> will help you find the bug.
>

If you had the technical skill you could verify that it is 100%
impossible for there to be anything wrong with the code on the basis of
that of the verifiably correct execution trace that it derives.

In other words you simply don't have the skill to see that the verified
facts supersede your incorrect opinions.

>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>
> Unless you are retracting any of the facts you have previously stated,
> we know (because you've told us) that H(P,P) returns 0 and we know
> (because you've told us) that P(P) halts. The trace of the execution
> will either confirm this, or the trace is faulty. Nothing new can come
> from looking at traces of mystery code.
>


--

[olcott]

On 5/11/2022 8:21 AM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 5/10/2022 10:50 AM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>> this execution trace to the ax86 source-code of P.
>>>
>>> P called with what argument? I assume P.
>
> You won't even correct a trivial point.
>
>>>> (b) Verify that this execution trace shows that P is stuck in
>>>> infinitely nested simulation (a non-halting behavior).
>>>
>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>> not halt, since you told us that it does. Post the code and someone
>>> will help you find the bug.
>
> Don't you want to know what's wrong with your code? Your trace shows
> that you are not even nesting any simulations so that's one error right
> there. But there are clearly others.
>

Here is the same trace that also shows the recursive simulation memory
allocations. I erase them because they are distracting.

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352

[0000137a](05) 6852130000 push 00001352

[0000137f](05) e81efeffff call 000011a2

[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423

[0000138d](05) e8e0f0ffff call 00000472

[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352

...[0000137a][00102296][00001352] 6852130000 push 00001352

...[0000137f][00102292][00001384] e81efeffff call 000011a2

--Allocation[002022b2](00000018)
--Allocation[002022d2](00000034)
--Allocation[0020230e](00000034)
--Allocation[0020234a](00010000)
New slave_stack @20234a
--Allocation[00212352](0003a980)

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

H_Root:1

...[00001352][0021233e][00212342] 55 push ebp

...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax

...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx

...[0000135d][00212332][00001362] e840feffff call 000011a2

--Allocation[0024ccda](00000018)
--Allocation[0024ccfa](00000034)
--Allocation[0024cd36](00000034)
--Allocation[0024cd72](00010000)
New slave_stack @24cd72
H_Root:0

...[00001352][0025cd66][0025cd6a] 55 push ebp

...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax

...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx

...[0000135d][0025cd5a][00001362] e840feffff call 000011a2

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423

---[0000138d][00102296][00000423] e8e0f0ffff call 00000472

Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret

Number_of_User_Instructions(1)
Number of Instructions Executed(15892)

>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>
>>> Unless you are retracting any of the facts you have previously stated,
>>> we know (because you've told us) that H(P,P) returns 0 and we know
>>> (because you've told us) that P(P) halts. The trace of the execution
>>> will either confirm this, or the trace is faulty. Nothing new can come
>>> from looking at traces of mystery code.
>
> Are you retracting any of the facts you have previously stated? If not,
> you are, as you no doubt know by now, wrong by definition.
>
>> (a) The trace is verifiably correct if one has the technical skill.
>
> A trace is neither correct not incorrect.

That seems to be a weasel worded way to attempt to derive a fake
rebuttal. The trace of the repeated first seven instructions of the
simulated P corresponds to the behavior specified by these first seven
instructions in the x86 source code of P.

> It just shows a (partial)
> program execution. It "correctly" shows that H is not doing what you
> claim (it shows no nested simulation) so maybe that means it's
> "incorrect"?
>

I added the nested simulation memory allocation details.

>> (b) The trace is proved non-halting if one has the technical skill.
>> You simply don't seem to have the technical skill.
>
> The trace shows H not doing what you claim. The fact that don't address
> this gross misdirection on your part make it more a lie than an error.
>

The trace conclusively proves that H does correctly simulate two of the
nested simulations that the x86 source-code of P specifies.

>> I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU
>> ERASED.
>
> There's no point in repeatedly posting a trace that it at best the wrong
> one and at worst a lie.

That you say it is wrong or a lie without understanding it is itself
wholly dishonest. If you don't understand it then you have no basis to
say that it is wrong. The most that you can honestly say is that you
don't understand how it could be correct.

> The right trace to post (again) would be the
> one showing P(P) halting.
>
> Obviously, you'd like people to talk about something other than the bald
> fact that you are wrong by definition: H(P,P) == false "even though P(P)
> halts" (your words).
>

(a) The correct simulation of the input to H(P,P) never halts.
(b) The correct simulation of the input to H1(P,P) halts.
(c) The direct execution of P(P) halts.

(b) and (c) are computationally equivalent.
(a) and (b) are NOT computationally equivalent.

[Ben]

olcott <No...@NoWhere.com> writes:

> Here is the same trace that also shows the recursive simulation memory
> allocations. I erase them because they are distracting.

You are admitting you are posting edited traces? Who would have guessed
that! Are you still editing them? There's still no evidence of nested
simulation.

> (a) The correct simulation of the input to H(P,P) never halts.

The correct simulation of P(P) halts.

> (b) The correct simulation of the input to H1(P,P) halts.

No one cares about H1. It's H that's wrong.

> (c) The direct execution of P(P) halts.

And H(P,P) == false.

> (b) and (c) are computationally equivalent.

According to you, one halts and the other does not. They are clearly
not equivalent.

> (a) and (b) are NOT computationally equivalent.

No one cares about H1. It's H(P,P)==false even though P(P) halts that's
wrong.

[Ben]

olcott <No...@NoWhere.com> writes:

> On 5/10/2022 10:50 AM, Ben wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> (a) Verify that the execution trace of P by H is correct by comparing
>>> this execution trace to the ax86 source-code of P.
>>
>> P called with what argument? I assume P.
>>
>>> (b) Verify that this execution trace shows that P is stuck in
>>> infinitely nested simulation (a non-halting behavior).
>>
>> Something is wrong in your code if P(P), or a simulation of P(P), does
>> not halt, since you told us that it does. Post the code and someone
>> will help you find the bug.
>
> If you had the technical skill you could verify that it is 100%
> impossible for there to be anything wrong with the code on the basis
> of that of the verifiably correct execution trace that it derives.

You trace clearly and accurately shows that what you call the
"simulation of the input" is wrong.

H(P,P) == false is wrong because P(P) halts. H is supposed to be able
to tell us which calls terminate and which ones won't. Your H is wrong
by definition.

[olcott]

On 5/11/2022 2:54 PM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 5/10/2022 10:50 AM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>> this execution trace to the ax86 source-code of P.
>>>
>>> P called with what argument? I assume P.
>>>
>>>> (b) Verify that this execution trace shows that P is stuck in
>>>> infinitely nested simulation (a non-halting behavior).
>>>
>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>> not halt, since you told us that it does. Post the code and someone
>>> will help you find the bug.
>>
>> If you had the technical skill you could verify that it is 100%
>> impossible for there to be anything wrong with the code on the basis
>> of that of the verifiably correct execution trace that it derives.
>
> You trace clearly and accurately shows that what you call the
> "simulation of the input" is wrong.
>

That is utter nonsense.
We can see that H(P,P) does execute a pure simulation of its input on
the basis of the execution trace of P (up to the point where P would
call H a second time from its same machine address with identical
parameters) provided by H and the x86 source code of P.

The first seven machine instructions of P from [00001352] to [0000135d]
are proven to be correctly simulated in sequence, until P calls H(P,P)
which repeats this process.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

Execution trace of the simulation of the input to H(P,P) by H

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

The new simulation gets a new stack giving it a new value for ESP
[00212332] of the prior simulation becomes [0025cd6a] in the new
simulation.

...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

For the last several weeks it has always been your provably incorrect
opinions against my provably verified facts.

> H(P,P) == false is wrong because P(P) halts. H is supposed to be able
> to tell us which calls terminate and which ones won't. Your H is wrong
> by definition.
>


--

[Richard Damon]

So, is the following execution now UNCONDITIONAL, or is there an implied
condition between each instruction as the simulator decides if it is
going to continue.

Note, that the operation of converting a trace of a simulation into a
trace of the simulated machine is only valid for UNCONDITIONAL
simulation. If the simulation is conditional, at a minimum you need to
mark the conditional or interprete with the implied conditionals.

> H_Root:0
> ...[00001352][0025cd66][0025cd6a] 55              push ebp
> ...[00001353][0025cd66][0025cd6a] 8bec            mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508          mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50              push eax
> ...[00001359][0025cd62][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51              push ecx
> ...[0000135d][0025cd5a][00001362] e840feffff      call 000011a2
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Which, is invalid since it is ignoring the implied conditionals between
all of the above instructions.

UNSOUND LOGIC.

WRONG. You have an incorrect trace unless H UNCONDITIONAL executes the
input, but it can't since it is shown to abort,

Thus YOU LIE about the trace.

>
>>  It just shows a (partial)
>> program execution.  It "correctly" shows that H is not doing what you
>> claim (it shows no nested simulation) so maybe that means it's
>> "incorrect"?
>>
>
> I added the nested simulation memory allocation details.

But not the actual nested simulation details

You imply unconditional simulation, when it is conditional.

>
>>> (b) The trace is proved non-halting if one has the technical skill.
>>> You simply don't seem to have the technical skill.
>>
>> The trace shows H not doing what you claim.  The fact that don't address
>> this gross misdirection on your part make it more a lie than an error.
>>
>
> The trace conclusively proves that H does correctly simulate two of the
> nested simulations that the x86 source-code of P specifies.

Nope, it proves it INCORRECTLY simulates the nested simulation.

>
>>> I PUT BACK IN THE MANDATORY DETAILS THAT PROVE MY POINT THAT YOU
>>> ERASED.
>>
>> There's no point in repeatedly posting a trace that it at best the wrong
>> one and at worst a lie.
>
> That you say it is wrong or a lie without understanding it is itself
> wholly dishonest. If you don't understand it then you have no basis to
> say that it is wrong. The most that you can honestly say is that you
> don't understand how it could be correct.

Nope, shows you don't understand how nested simulations actually works.

>
>>  The right trace to post (again) would be the
>> one showing P(P) halting.
>>
>> Obviously, you'd like people to talk about something other than the bald
>> fact that you are wrong by definition: H(P,P) == false "even though P(P)
>> halts" (your words).
>>
>
> (a) The correct simulation of the input to H(P,P) never halts.

WRONG.

> (b) The correct simulation of the input to H1(P,P) halts.

SAME INPUT, thus differing simulations prove that one is wrong.

> (c) The direct execution of P(P) halts.

Which proves what the CORRECT simulation must do.

>
> (b) and (c) are computationally equivalent.
> (a) and (b) are NOT computationally equivalent.
>

Thus H is NOT a Halt Decider, but just a POOP decider.

(H1 isn't one either, as it will fail the same way for a P1 built on H1
instead of H).

[Ben]

olcott <No...@NoWhere.com> writes:

> On 5/11/2022 2:54 PM, Ben wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>> this execution trace to the ax86 source-code of P.
>>>>
>>>> P called with what argument? I assume P.
>>>>
>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>> infinitely nested simulation (a non-halting behavior).
>>>>
>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>> not halt, since you told us that it does. Post the code and someone
>>>> will help you find the bug.
>>>
>>> If you had the technical skill you could verify that it is 100%
>>> impossible for there to be anything wrong with the code on the basis
>>> of that of the verifiably correct execution trace that it derives.
>> You trace clearly and accurately shows that what you call the
>> "simulation of the input" is wrong.
>
> That is utter nonsense.

The whole exchange is ridiculous. You post traces you now admit are
edited. You won't post the code for H because you know it's wrong. All
the rest of your posts are just frantic attempts to take the focus away
from the facts you have already admitted: that H(P,P) == false even
though P(P) halts.

H is unable to do the job it is supposed to do: correctly determine the
halting or otherwise of certain function calls. There are no arguments
that can be passed to H so that H can tell us that the function call
P(P) halts.

You have used the same diversion again and again. When confronted with
a huge mistake, you post even more errors to try draw attention away
from the big mistake. All the errors in your recent posts are of no
significance compared to the fact that H does not do the job is it
supposed to do.

[olcott]

On 5/11/2022 7:25 PM, Ben wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 5/11/2022 2:54 PM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 5/10/2022 10:50 AM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> (a) Verify that the execution trace of P by H is correct by comparing
>>>>>> this execution trace to the ax86 source-code of P.
>>>>>
>>>>> P called with what argument? I assume P.
>>>>>
>>>>>> (b) Verify that this execution trace shows that P is stuck in
>>>>>> infinitely nested simulation (a non-halting behavior).
>>>>>
>>>>> Something is wrong in your code if P(P), or a simulation of P(P), does
>>>>> not halt, since you told us that it does. Post the code and someone
>>>>> will help you find the bug.
>>>>
>>>> If you had the technical skill you could verify that it is 100%
>>>> impossible for there to be anything wrong with the code on the basis
>>>> of that of the verifiably correct execution trace that it derives.
>>> You trace clearly and accurately shows that what you call the
>>> "simulation of the input" is wrong.
>>
>> That is utter nonsense.
>
> The whole exchange is ridiculous. You post traces you now admit are
> edited.

I normally have that debug info disabled so it need not be edited.
You needed to see that it really is recursive simulation (because you
didn't believe me) so I left these details in.

> You won't post the code for H because you know it's wrong.

That is a ridiculously stupid thing to say when it is so dead obvious
that I proved that the code is correct on the basis of the 14 lines of
correct simulation that it produces.

It is also dead obvious and that and second function call from the same
machine address to the same function with the same parameters
conclusively proves infinite recursion.

These things have been DEAD OBVIOUS for six months and everyone here is
too stupid, dishonest or ignorant to acknowledge them.

[Richard Damon]

No, it is clear that the traces you are posting aren't corerct as P
calls H and then H simulates its input, but we NEVER see that simulation
happening, only another call to P.

You have presented ZERO proof that you actually HAVE a simulator.

You have just proved that YOU are the "stupid" one because you can't see
that a Halt Decider needs to decide of the Compuation asked about.

If H(P,P) isn't asking about P(P), and you won't say HOW to ask about
that, it just provides very convincing evidence that H isn't a Halting
Decider.

You also have a HISTORY of making out and out FALSE statements that you
later try to back off on, but were clearly incorrect from the beginning,
so you have PROVEN yourself to be a LIAR, so your word is worthless.

You don't understand Turing Machines.

You don't understand Computation Theory.

You don't seem to understand what Formal Logic is, as you seem incapable
of actually proving anything, but just jump out to irrelvent analogies
that don't actually prove anything.

I don't think you even really understand what Truth is, and seem to
confuse it with Knowledge.

In other words, you are just ignorant about all you claim to have grand
ideas on.

You FAIL.

[Ben]

No, I said it is not a nested simulation -- i.e. a simulation of a
function that then simulates a simulation and so on. It clearly isn't.
The trace is not a trace of what you claim your H is doing. That's why
you are hiding H and why you will never publish it.

>> You won't post the code for H because you know it's wrong.
>
> That is a ridiculously stupid thing to say when it is so dead obvious
> that I proved that the code is correct on the basis of the 14 lines of
> correct simulation that it produces.

Yet you still hide the code! You know it's wrong. If you really
thought you had anything of value, you would have have published
everything. Keeping secrets is a dead give-away.

> These things have been DEAD OBVIOUS for six months and everyone here
> is too stupid, dishonest or ignorant to acknowledge them.

Yet you have published nothing! It is, according to you, obvious that
you are right, so why are you not published and famous? Is every
journal editor and CS professor (the people editors get to review
papers) also stupid and dishonest? And how could you possibly know?

The truth is you simply can't find a way to make H(P,P) == false even
though P(P) halts sound anything other than preposterous, so what could
you possibly publish? No one will take traces over the code and you
know that when you show the code the game is up.

[olcott]

I wrote it and it was the very most difficult part to write and thus I
know for a fact that it is.

> The trace is not a trace of what you claim your H is doing. That's why
> you are hiding H and why you will never publish it.

The trace is the trace of the input to H(P,P) does not bother to display
of the 236 pages of execution trace of H performing a pure simulation on
P that calls H that performs a pure simulation of P that would call H
again.

While the two levels of H are performing a pure simulation of their
inputs they have no behavior what-so-ever that can possibly have any
effect on the behavior of either of the simulated (P,P) instances.

This allows their instructions to be safely ignored when outputting the
most relevant portion of the execution trace. Instead of 237 pages we
only need to look at 14 lines.

*Maybe we should go over this point again and again over and*
*over hundreds of times if needed until you understand it*


It is so dead obvious that I proved that the code is correct on the

basis of the 14 lines of correct simulation that it produces.

It is also dead obvious and that and second function call from the same
machine address to the same function with the same parameters
conclusively proves infinite recursion.

These things have been DEAD OBVIOUS for six months and everyone here is
too stupid, dishonest or ignorant to acknowledge them.

[Richard Damon]

Except they DO. There are conditional branches, that contain the
capability to break the "infinite loop", and in fact which WILL break
the infinite loop of the outer simulator does.

Thus, the "rule" that the outer simulator is using isn't actually satisfied.

>
> This allows their instructions to be safely ignored when outputting the
> most relevant portion of the execution trace. Instead of 237 pages we
> only need to look at 14 lines.
>

Nope.

> *Maybe we should go over this point again and again over and*
> *over hundreds of times if needed until you understand it*
>

YOU are stuck in the infinite loop, because you don't understand your
termination conditin.

>
> It is so dead obvious that I proved that the code is correct on the
> basis of the 14 lines of correct simulation that it produces.

Yes, it is dead obvious that H is wrong, and the trace is incorrrect.

And, from your reports,

>
> It is also dead obvious and that and second function call from the same
> machine address to the same function with the same parameters
> conclusively proves infinite recursion.
>

Nope.

> These things have been DEAD OBVIOUS for six months and everyone here is
> too stupid, dishonest or ignorant to acknowledge them.
>

If you claim it is dead obvious, why haven't you submitted the paper,
before YOU are dead.

I think it is because you know you haven't actually proved what you
need, and are trying to refine your lie to try and get something that
maybe someone will publish posthumously out of pity, and maybe people
will be kind to the dead. It won't work, as you ideas are just too bad.

[Ben]

And you are determined to prevent anyone else from knowing it by (a)
hiding the code, and (b) publishing traces that don't show it. Show the
code or it didn't happen.

> These things have been DEAD OBVIOUS for six months and everyone here
> is too stupid, dishonest or ignorant to acknowledge them.

Yet, as I said, you have not been published, and you remain unheard of.

Dead obvious things that overturn key theorems should be easy to
publish. Even if you can't write clearly enough on your own, you should
be able to find a professor to co-author a paper with you. Since it's
dead obvious, how hard could it be to write?

Or maybe you are just deluded and wrong? After all, H(P,P) == false
even though P(P) halts is wrong by definition. You might struggle to
get anyone to co-author such a paper.

[wij]

On Tuesday, 10 May 2022 at 20:26:33 UTC+8, olcott wrote:

> (a) Verify that the execution trace of P by H is correct by comparing
> this execution trace to the ax86 source-code of P.
>
> (b) Verify that this execution trace shows that P is stuck in infinitely
> nested simulation (a non-halting behavior).
>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>

H does not exist !!!. Your POOH is incorrect, totally garbage, nonsense.

According to GUR https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
It is dead obvious that correct halting decider dose not exist.