On 3/12/25 9:37 AM, olcott wrote:

On 3/11/2025 12:42 PM, Mike Terry wrote:

On 11/03/2025 13:46, Richard Heathfield wrote:

On 11/03/2025 13:31, olcott wrote:

On 3/11/2025 5:28 AM, Mikko wrote:

On 2025-03-10 23:41:13 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
   return;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

void DDD()
{
   HHH(DDD);
   return;
}

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.

Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.

Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.

Whether HHH does see those patterns cannot be inferred from the
information
given. Only about DDD one can see that it halts if HHH returns. In
addition,
the given information does not tell whether HHH can see patterns
that are
not there.

How many competent programmers you have asked?

Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.

Bring 'em on. Perhaps /they/ have the source to HHH, because without
it you don't have anything. (And btw whatever it is you claim to have
is far from clear, because all I've seen so far is an attempt to
express the Halting Problem in C and pseuodocode, where the
pseudocode reads: HHH(){ magic happens }

It takes newcommers a while to understand the context behind what PO
is saying, and he never bothers to properly explain it himself, and is
incapable of doing so in any rigorous fashion.

So I'll explain for you my interpretation.

His HHH is a C function called by DDD, which will "simulate" DDD().
The simulation consists of simulating the individual x86 instructions
of DDD [and functions it calls] sequentially, and may only be a /
partial/ simulation, because HHH also contains logic to analyse the
progress of the simulation, and it may decide at some point to simply
stop simulating.  (This being referred to as HHH "aborting" its
simulation.)

Of course, we expect that the (partial) simulation of DDD will exactly
track the direct execution of DDD, up to the point where HHH aborts
the simulation.  [This is NOT what PO's actual HHH code does, due to
bugs/ design errors/misunderstandings etc., but for the purpose of
PO's current point, you might consider this to be what happens.]

So if we imagine HHH never aborts, then HHH simulates DDD(), which
calls HHH, and (simulated) HHH will again simulate DDD() - a nested
simulation.  (PO calls this recursive simulation.)  This continues,
and such an HHH will obviously never terminate - in particular THE
SIMULATION by outer HHH will never proceed as far as DDD's final ret
instruction.  (This is genuine "infinitely recursive simulation")

OTOH if HHH logic aborts the simulation at some point, regardless of
how many nested levels of simulation have built up, it will be the /
outer/ HHH that aborts, because the outer HHH is ahead of all the
simulated HHH's in its progress and will reach its abort criterion
first.  At the point where it aborts, the DDD it is simulating will
clearly not have reached its final ret instruction, as then its
simulation would have ended "normally" rather than aborting.

So whatever HHH's exact logic and abort criteria, it will not be the
case that its *simulation of DDD* progresses as far as DDD's final ret
instruction:  either HHH never aborts so never terminates, or if it
does abort, the (outer) HHH simulating it will abort DDD before it
gets to the final ret instruction.

The key point here is that we are not talking about whether DDD()
halts!  We are only talking about whether HHH's /simulation/ of DDD
proceeds as far as simulating the final DDD ret instruction.  So at
this point we are not talking about the Halting Problem, as that is
concerned with whether DDD() halts, not whether some partial
simulation of DDD() simulates as far as the ret instruction.

Given that HHH is free to stop simulating DDD *whenever it wants*, you
might consider it rather banal to be arguing for several months over
whether it actually simulates as far as DDD's return. After all, it
could simulate one instruction and then give up, so it didn't get as
far as DDD returning - but SO WHAT!?  Why is PO even considering such
a question?

[PO would say something like "/however far/ HHH simulates this remains
the case", misunderstanding the fact that here he is talking about
multiple different HHHs, each with their own distinct DDDs. (Yes, none
of those different HHHs simulate their corresponding DDD to
completion, but all of those DDD halt [if run directly], assuming
their HHH aborts the simulation at some point.  We can see this just
from the given code of DDD: if HHH returns, DDD returns...)]

But if you think PO properly understands this you would be vastly
overestimating his reasoning powers and his capacity for abstract
thought.  Even if you "agree" that HHH (however coded) will not
simulate DDD to completion, you would not really be "agreeing" with PO
as such, because that would imply you understand PO's understanding of
all that's been said, and that there is a shared agreement on the
meaning of what's been said and its consequences etc., and we can
guarantee that will NOT be the case!  We could say PO "fractally"
misunderstands every technical concept needed to properly discuss the
halting problem (or any other technical topic).

PO's "understanding" will entail some idea that the situation means
that DDD "actually" doesn't halt, or that HHH is "correct" to say that
DDD doesn't halt.

This is Mike's very stupid mistake:
I always thought that Mike was much smarter than this (he usually is)

(Even though it demonstrably DOES halt if not aborted and simulated
further.

void DDD()
{
  HHH(DDD);
  return;
}

Every competent C programmer knows when any N steps of DDD
are correctly emulated by x86 emulator HHH (that can emulate
itself emulating DDD) that DDD never reaches its own "return"
instruction in any finite (or infinite) number of steps.

As a matter of actual verified fact HHH emulates the
first four instructions of the x86 machine code of DDD
which call itself to repeat this process.

And any even half competent programmer knows you define the behavior of
a program by what it does when run or fully emulate it,

The PARTIAL emulation done by HHH is irrelevent.

All you have done is PROVEN that HHH doesn't "correctly emulate" its
input, but aborts too soon, for EVERY version that does abort and return.

That, plus the fact that you show you don't understand what a "Program"
is, since neither DDD or HHH actually are ones.

_DDD()
[000020b2] 55             push ebp
[000020b3] 8bec           mov ebp,esp
[000020b5] 68b2200000     push 000020b2
[000020ba] e8c3fbffff     call 00001c82
[000020bf] 83c404         add esp,+04
[000020c2] 5d             pop ebp
[000020c3] c3             ret
Size in bytes:(0018) [000020c3]

_main()
[000020d2] 55             push ebp
[000020d3] 8bec           mov ebp,esp
[000020d5] 68b2200000     push 000020b2
[000020da] e8a3fbffff     call 00001c82
[000020df] 83c404         add esp,+04
[000020e2] 50             push eax
[000020e3] 6823070000     push 00000723
[000020e8] e855e6ffff     call 00000742
[000020ed] 83c408         add esp,+08
[000020f0] 33c0           xor eax,eax
[000020f2] 5d             pop ebp
[000020f3] c3             ret
Size in bytes:(0034) [000020f3]

 machine   stack     stack     machine        assembly
 address   address   data      code           language
 ========  ========  ========  ============== ============= [000020d2][0010370c][00000000] 55             push ebp [000020d3][0010370c][00000000] 8bec           mov ebp,esp [000020d5][00103708][000020b2] 68b2200000     push 000020b2 ; push DDD [000020da][00103704][000020df] e8a3fbffff     call 00001c82 ; call HHH New slave_stack at:1037b0

Begin Local Halt Decider Simulation   Execution Trace Stored at:1137b8 [000020b2][001137a8][001137ac] 55             push ebp      ; (1) DDD
[000020b3][001137a8][001137ac] 8bec           mov ebp,esp   ; (2) DDD
[000020b5][001137a4][000020b2] 68b2200000     push 000020b2 ; (3) DDD [000020ba][001137a0][000020bf] e8c3fbffff     call 00001c82 ; (4) DDD
New slave_stack at:14e1d8

And here is a lie, as that is NOT a correct emulation of the call HHH instruction.

[000020b2][0015e1d0][0015e1d4] 55             push ebp      ; (1) DDD
[000020b3][0015e1d0][0015e1d4] 8bec           mov ebp,esp   ; (2) DDD
[000020b5][0015e1cc][000020b2] 68b2200000     push 000020b2 ; (3) DDD [000020ba][0015e1c8][000020bf] e8c3fbffff     call 00001c82 ; (4) DDD

If you want to see the details of exactly how HHH
emulates itself emulating DDD https://github.com/plolcott/x86utm/blob/master/Halt7.c

The x86utm operating system infrastructure required by HHH https://github.com/plolcott/x86utm/blob/master/x86utm.cpp https://github.com/plolcott/x86utm/blob/master/include/Read_COFF_Object.h

Which shows that HHH does NOT correctly emulate itself, but gives up
before it gets the right answer,

Sorry, you are just proving that your work is a FRAUD.

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