Re: HHH(DDD) sees the exact same behavior pattern as HHH(Infinite_Recursion)

On 30/07/2024 08:19, joes wrote:

Am Mon, 29 Jul 2024 19:16:29 -0500 schrieb olcott:

On 7/29/2024 5:57 PM, Mike Terry wrote:

On 29/07/2024 20:36, Fred. Zwarts wrote:

Op 29.jul.2024 om 15:03 schreef olcott:

On 7/29/2024 2:29 AM, Fred. Zwarts wrote:

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

On 7/28/2024 2:59 AM, Fred. Zwarts wrote:

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

 

You didn't even bother to look at how HHH examines the execution
trace of Infinite_Recursion() to determine that Infinite_Recursion()
specifies non-halting behavior.
Because of this you cannot see that the execution trace of DDD
correctly emulated by DDD is essentially this same trace and thus
also specifies non-halting behavior.

>
That is only because you are cheating, by hiding the conditional
branch instructions of HHH, which should follow the call instruction
into HHH.
HHH simulating itself is more like
void Finite_Recursion (int N) {
    if (N > 0) Finite_Recursion (N - 1);
}

>
Also there is the crucial difference that Infinite_Recursion() trace is
a trace for a single x86 processor.  The HHH/DDD trace is not a single
processor trace, as it contains entries for multiple virtual x86
processors, all merged into one.  There are all sorts of argument that
can be applied to the simple single x86 processor trace scenario, that
simply don't work when transferred to a multi-processor-simulation
merged trace.  PO doesn't understand these differences, and has said
there is NO difference!  He also deliberately tries to hide these
difference, by making his trace output resemble a single-processor
trace as far as he can:

non sequitur:

The simple fact that you continue to ignore is that DDD is correctly
emulated by DDD according to the semantics of the x86 instructions of
DDD and HHH that includes that DDD does call HHH(DDD) in recursive
emulation that will never stop running unless aborted.

Nobody is ignoring that.
The "unless" applies - every HHH in fact aborts simulating.
 

-  suppressing trace entries in H which would make it obvious that the
matching calls

I am not suppressing any freaking trace entries

You are completely suppressing the trace of the simulator HHH.
 

Two complete simulations show a pair of identical TMD's are simulating a
pair of identical inputs. We can see this thus proving recursive
simulation.

Except for the Root variable.
 

     to HHH are from completely separate logical x86 processors.  The
output as he presents it
     looks pretty much identical to the corresponding (but totally
different character) CALL
     scenario where HHH calls DDD rather than simulating it.

Right. I was confused by that for a while. A call could not be aborted.

Exactly.  To avoid infinite recursion:
-  Recursive /call/ pattern MUST break from innermost call at some point, which then percolates back throught the stack of calls until the outer call finally returns.  This is (relatively) easy to reason about in a proof.
-  Recursive /simulation/ pattern can break exactly as for recursive call, but additionally might break from an outer simulation simply aborting its inner simulation.  This is more complex to reason about in a proof.
[But PO is TOTALLY incapable of reasoning about either scenario.  Still I doubt that will stop 5000 future posts with PO saying "everyone with the right skills can see my rule is sound", whilst responders repeat over and over that it patently is not sound since it fails with input DDD.]
Mike.