From Newsgroup: comp.ai.philosophy

On 8/20/2025 8:24 PM, Mike Terry wrote:

On 20/08/2025 22:01, olcott wrote:

On 8/20/2025 3:15 PM, Mike Terry wrote:

On 20/08/2025 03:08, Richard Heathfield wrote:

On 20/08/2025 02:37, Mike Terry wrote:

On 19/08/2025 19:06, Richard Heathfield wrote:

<snip>

But HHH is not a factorial calculation. It is a function that
takes a function pointer it can only assign or dereference, and
then returns 0.

ok, we've got onto cross purposes.

Agreed.

I was not talking about HHH, because HHH involves recursive
simulation, not recursive call.

Understood.

Let me re-state: I accept your explanation that that's not how it
works. It *should* work that way, and the way it does work is
clearly broken, but okay, it doesn't.

That can't happen - (c) is performing the same calculation as
(a): same code and the same input.

Sure it could. When HHH detects that it's about to recurse into
itself it could just start off a new simulation, and if it starts >>>>>> to run away with itself it could can /its/ simulation and return 0. >>>>>

You are describing recursive /simulation/ (or emulation).  (I
think...)  HHH does not involve recursive call, so what I was
saying does not apply to HHH.

Right.

IF (as I originally thought) HHH worked by recursing into a new
simulation every time it hit DD's HHH call, that would be quite
clever. It would be easy to add static metrics to make the call
about aborting the recursion and unwinding the stack back to where
it can continue simulating DD, and nothing would be discarded as
being "unreachable".

Let's see if I've fully got what you're saying.  I'll use notation
HHH[n] for HHH running at nested simulation level n.  So HHH[0] is
outer HHH etc.

[Yeah, I know your eyes are already starting to glaze over!  All I
can say is the steps below are little steps with no big jumps, so if
you grab a pad and pen and cup of tea you can get through it -
believe that that can happen!!]

1. HHH[0] is simulating DD[1], and spots DD's "call HHH".
2. Rather than simulating that x86 call instruction, HHH decides to
spin up a new
    simulation of ... DD?  [must be...]

Numbering begins at 0.

My notation uses [n] to represent "simulation nesting level" n, with the convention that level 0 represents unsimulated code, i.e. called
directly from main().

I am changing my notation to be consistent with yours.
*These details are crucial for you and Kaz to see*

*Numbering begins at 0 for direct execution*
DD() is executed in main

HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.

DD[0] is invoked and calls HHH[0] that creates a
separate DD[1] process context with its own set of
16 virtual registers and virtual stack.

When HHH[0] encounters the call from DD[1] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same
DD[1] process context.

When HHH[1] begins simulating its own DD[2] it must
create a separate DD[2] process context with its own
set of 16 virtual registers and virtual stack...

on and on until OOM error (proving non-halting) when
we eliminate the u32* execution_trace data.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2