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

On 7/14/25 11:53 AM, olcott wrote:

On 7/14/2025 6:37 AM, Richard Damon wrote:

On 7/13/25 10:46 PM, olcott wrote:

On 7/13/2025 8:33 PM, Richard Damon wrote:

On 7/13/25 4:43 PM, olcott wrote:

On 7/7/2025 9:07 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

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

[ .... ]

Is emulated by an x86 emulator named HHH.

>
That's no adequate description.  To make it so, you'd have to say what
you mean by an "x86 emulator".  The name you give it is irrelevant
>

  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.

>
The word "correctly" is fully redundant there.
>
The proof does not state whether the constructed function returns true or
false, i.e. whether it specifies non halting behaviour.

>
The proof is purported to prove THAT DD is an undecidable
input for HHH. This is its counter example refuting the
claim that a universal halt decider can exist.
>
>
>

>
But since your DD by your own admission is a category error for a halt decider, as you have specifically stated it isn't a program as the input doesn't include the code of the specific HHH that it calls, you proof is just invalid.
>
Sorry, all you proved is that you don't know what you are talking about.

>
That you keep trying to get away with refuting
this easily verified fact says a about about you
>
_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192  // push DDD
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]
>
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
>

>
Which isn't the definition of Non-Halting,

Reaching a final halt state <is> the definition of halting.
 

Right, but the OBJECT that measures that it the exectution of the Program, or a complete simulation.
Note, Non-Halting isn't everything that isn't halting, it is those things that Halting is defined for not reaching that state, even after an unbounded number of steps processed.
That is where you lies fail. You think not reaching the final state because you gave up means non-halting.
This is like saying the 10 mile trail is non-ending, because you gave up hiking it after 100 feet, and said "I can't get to the end, so it must be non-ending".
Sorry, you are just proving that you are just a stupid pathological liar that does't know the meaning of the words he uses, but makes up lies for definitions.