Re: How do simulating termination analyzers work? ---Truth Maker Maximalism FULL_TRACE

On 7/9/2025 3:53 AM, Fred. Zwarts wrote:

Op 08.jul.2025 om 16:33 schreef olcott:

On 7/8/2025 3:22 AM, Fred. Zwarts wrote:

Op 07.jul.2025 om 20:40 schreef olcott:

On 7/7/2025 2:49 AM, Fred. Zwarts wrote:

>
Op 07.jul.2025 om 05:07 schreef olcott:

On 7/6/2025 4:23 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 7/6/2025 12:52 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 7/6/2025 11:02 AM, Alan Mackenzie wrote:

>

[ .... ]
>

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

>

Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.

>

An argument like this is at such a low level of abstraction as to be near
valuless.

>

It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.

>
A complete concrete specification would necessarily include a description
of what you mean by "simulation".

>
I specifically mean that this x86 machine code
_DD()
[00002162] 55             push ebp
[00002163] 8bec           mov ebp,esp
[00002165] 51             push ecx
[00002166] 6862210000     push 00002162 ; push DD
[0000216b] e862f4ffff     call 000015d2 ; call HHH
[00002170] 83c404         add esp,+04
[00002173] 8945fc         mov [ebp-04],eax
[00002176] 837dfc00       cmp dword [ebp-04],+00
[0000217a] 7402           jz 0000217e
[0000217c] ebfe           jmp 0000217c
[0000217e] 8b45fc         mov eax,[ebp-04]
[00002181] 8be5           mov esp,ebp
[00002183] 5d             pop ebp
[00002184] c3             ret
Size in bytes:(0035) [00002184]
Is emulated by an x86 emulator named HHH.
>

 But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny pieces
out of it and dealing with those.  The proof you claim to refute has no
notion of simulation, for example; it doesn't need it.
>

>
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
     specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
>

That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.

>
It doesn't.  See above.
>

>
It need not be a Turing machine to exactly match
the same pattern.
>

Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.

>
It is a waste of time to discuss things at such an unnecessarily low
level of abstraction.
>

>
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any low level of abstraction.
>

  But analysing it a bit further, it is not clear exactly what
you mean by "simulated by HHH".

>

Do you have any idea what "simulation" means?

>
Yes.  I'm not sure you do,

>
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
>

though, which is why I was prompting you to be
more concrete.  When Alan Turing published his seminal paper, he took a
very great deal of space specifying exactly what he meant by a "machine".
>
[ .... ]
>

It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.

>

So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?

>
Whether endless recursion happens depends on whether HHH(DD) returns 0.

>
Not at all. Anyone should instantly see that no HHH
can possibly ever return to any simulated DD.
>
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
>

Others have pointed out problems with your reasoning here over a long
period of time.  I don't want to repeat that.
>

>
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
>

[ .... ]
>

The directly executed DDD() is not an input to HHH.

>

Vague word salad again.

>

We have the exact same thing in the Linz proof.

>

You do not.  There is no concept of "directly executed" in turing
machines, and Linz's proof concerns turing machines.  Other people here
have said that one of the reasons you present your propositions as C, and
even some x86 assembly language, is to avoid the precision afforded by
turing machines.  I'd tend to agree with them, here.

>
>

Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly
executed Ĥ.

>
OK, that's a start, but it doesn't apply to turing machines.
>

>
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
*Those ARE Turing machines*
>

[ .... ]
>

DD simulated by HHH is a non-halting pattern that HHH does recognize.

>
That is disputed by everybody else on this newsgroup.
>

>
*Yet they cannot ever point out even a single actual mistake*
>

>

I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.

>
Your postings are stuffed full of vagueness and ambiguity.

>
_DD()
[00002162] 55             push ebp
[00002163] 8bec           mov ebp,esp
[00002165] 51             push ecx
[00002166] 6862210000     push 00002162 // push DD
[0000216b] e862f4ffff     call 000015d2 // call HHH
[00002170] 83c404         add esp,+04
[00002173] 8945fc         mov [ebp-04],eax
[00002176] 837dfc00       cmp dword [ebp-04],+00
[0000217a] 7402           jz 0000217e
[0000217c] ebfe           jmp 0000217c
[0000217e] 8b45fc         mov eax,[ebp-04]
[00002181] 8be5           mov esp,ebp
[00002183] 5d             pop ebp
[00002184] c3             ret
Size in bytes:(0035) [00002184]
>
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.

It is incomplete, because it has a call instruction, but does not specify how this call instruction could be simulated,

You are a damned liar.
>

>
As usual, no rebuttal, but claims without evidence.
I proved my statement in the part you removed from the quote.
Not telling the whole truth also counts as lying. Lying is dishonest.

>
When I explain something 500 times and people say
I never said it that is sufficient evidence to call
them a liar (or they have dementia).
>
Here is the full execution trace of HHH(DDD)
that included HHH emulating itself emulating DDD.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
>

 You can repeat your errors even more often, but that does not make them true.
Even the trace proves that HHH aborts prematurely, before it can see that the finite recursion would reach the final halt state only one cycle later.

Sure and infinite loops end when you wait until
the heat death of the universe.

Your 'proofs' turns out to be false claims without evidence.

What actual programming experience do you have?
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer