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

On 7/15/25 7:48 AM, Mr Flibble wrote:

On Tue, 15 Jul 2025 07:42:56 -0400, Richard Damon wrote:
 

On 7/14/25 11:20 PM, olcott wrote:

On 7/14/2025 9:57 PM, Richard Damon wrote:

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.
>
>

_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.
>
Do you really think that you can get away with disagreeing with the x86
language?
>
>

Why do YOU think you can?
>
Your above "Input" can be simulated past the instruction at 0000219A
because we lack the data of what is next.
>
Your problem is you started with the lie to yourself that you could
change the rules, and thus made yourself into a pathological liar that
has just lost the rules of the game.
>
In this case, your problem is you tried to redefine what non-halting
means, becuase your mind just can't handle the actual definition, and
some of its consequences. Partial emulations, by themselves, NEVER
define a program to be non-halting, only complete execution or complete
simulation. PERIOD.
>
Sorry, you just proved you are an idiot that has brainwashed himself and
apparently lost the key to get out.

 No. Partial simulation is a perfectly valid approach for a partial decider.
 /Flibble

Yes, but not as the thing that defines that an input is non-halting.
You need to use the partial simulation to actually prove that the full correct simulation of that input would not halt. And that input doesn't change to use that correct simulator, it still calls the partial simulator as that is what is in the input.
Note, the problem comes when you try to say that the "correct simulation" must be done by the decider, as then it can't be a partial decider, and just stuck in a contradiction, thus making such a criteria invalid.