On 20/08/2025 02:18, Kaz Kylheku wrote:

On 2025-08-19, olcott <[email protected]> wrote:

On 8/19/2025 5:58 PM, Andr� G. Isaak wrote:

On 2025-08-19 11:42, olcott wrote:

On 8/19/2025 12:06 PM, Kaz Kylheku wrote:

You show that even though DD contradicts the result reported by the HHH >>>>> embedded into it, a /different/ HHH (using the same procedure name and >>>>> body, distinguished from DD's HHH by a hidden static flag) can decide >>>>

(1) The static flag is dead and not used.
�� if (**execution_trace == 0x90909090) is used instead.

But if (**execution_trace == 0x90909090) creates the exact same problem
as using a static variable. You're creating a global state which your
HHH accesses and thus HHH is not a pure function. Except you're doing it >>> in a far messier and more questionable way.

Andr�

I have known that for years.

After I got people here to quit lying about the
behavior of DD correct simulated by HHH I had
intended to fix that issue.

The correct simulation doesn't matter.

The static flag (whether using a "static" variable, or de-facto static
data stored in the code segment) throws a monkey wrench into the
claim you are making based on a correct simulation.

I agree. PO should eliminate the global variables in HHH et al:
a) Make the global trace table local to HHH. So there is no
need for the Root variable controlling once-off global
initialisation.
b) Also make each outer and inner HHH processing the same. All simulation
levels capture trace records from their nested simulations, and all levels
perform the same abort checking.
c) Get rid of the _ASM directives storing data directly into the code segment.
(That's the same as using static variables, but we've got rid of that
anyway with (a),(b).)

Then the (partial) simulation would be "correct" at the instruction+data level, and nested
simulations would match the outer ones etc. [Up to the point simulations are aborted of course.]

The if statement testing the valueo of *execution_trace, together
with another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).

I don't believe that's PO's intention, or even a good way of looking at things. This is just a
judgement, not a factual claim, but I'll try to justify my thinking...

WHY does PO make the outer HHH different? It's NOT because he needs it to be for his argument - he
doesn't. If PO fixed (a),(b),(c) above, then inner and outer HHHs and DDs would become completely
identical in their simulations, completely matching the stand-alone execution of HHH/DD. [Exactly
as they must be!] And I suggest nothing in PO's argument would change. It would /still/ be the
case that DD halts when run stand-alone, and HHH(DD) would still decide never-halts even though DD
halts, for the same reason they does now:

- HHH [SL0: Simulation level 0, i.e.outer HHH] would simulate DD [SL1] and spot PO's so-called
"infinite recursive emulation" pattern in the simulation, and abort [SL1], then return never-halts.
- DD [SL0] would call HHH[SL0] which would behave as above and return never-halts (after a bit of
simulating and so on), then DD will return.

Nothing in PO's argument changes. He doesn't need inner HHH[DD]s to "never terminate" when
considered as computations in their own right. HHH[SL0] has spotted PO's so-called non-halting
pattern regardless, so "non-halting behaviour has been expressed" and outer HHH is right [in
PO-world] to return non-halting. Of course, PO will /claim/ that DD [SL1,2,3...] "would never halt
if Also it is still the case that as in PO's most famous fly-spray phrase "DD correctly simulated by
HHH can never be simulated as far as its return instruction" remains true.

One difference in actual behaviour compared to PO's current design using globals: the HHH
[SL1,2,3...] (nested) simulations would execute the instructions to capture their own nested traces,
and check them for abort patterns, JUST LIKE OUTER HHH. Well that's fine and as it should be! The
"big picture" flow of control is not significantly changed, because HHH [SL0] is way ahead of [SL1]
and way way ahead of [SL2] etc., and as both are treading exactly the same computation path, SL0 is
always going to spot the abort pattern before SL1,2,3... simulations. And the new code running in
HHH [SL1,2,3...] does not affect HHH [SL0] abort decisions.
----

So if PO's use of globals is NOT to make SL1,2,3... behave differently regarding halting, WHY did PO
do it that way? Answer: he simply could not see how to do it "properly"! So he did it "wrong" and
just carried on. It's not key to any of his arguments...

The fact that HHH (top level) can correctly decide something
that HH (recursive) doesn't decide is not interesting and
doesn't speak to the Halting Theorem.

But I don't think that's what PO actually argues either, as I tried to explain above.

Contrary to your repeatedly stated belief, The Halting Theorem doesn't
say that there exist test cases whose halting is indeterminate such that
they cannot be decided by /any/ decider.

Any case not correctly decided by one decider is susceptible to being perfectly well decided by a different decider. Anyone who groks halting already knows this and that is all you have shown.

The honest thing would be to eliminate static variable mutations
and if tests in your code and use different names, as I suggested
years ago.

Use HHH_toplevel for the top-level decider, and HHH_recursive
for the recursive one.

void DD(void)
{
if (HH_recursive(DD)) {
// if decider says halts, loop; otherwise return.
for (;;);
}
}

main() {
puts(HHH_toplevel(DD) ? "Halts!" : "Halts not!");
return 0;
}

Exercise; just complete the implementations of HH_toplevel and
HH_recursive.

HH_toplevel contains all the logic of the original HHH when
*execution_trace is 0x90909090.

HH_recursive contains all the logic of the original HHH
when *execution_trace was not found to be 0x90909090.

It's 100% equivalent to what you are doing, except for names. Names
don't mean anything. But distinct entities should be given distinct
names, so that we don't confuse ourselves and keep our arguments
honest.

The thing is IMO that if we imagine PO's coding/design errors being fixed, i.e. my (a),(b),(c)
above, then your distinction between HH_recursive/HH_toplevel goes away, and none of his results or
arguments change. So the point you're making is not really core to PO's arguments, I'd say.


Regards,
Mike.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)