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

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.  It states
nothing about "directly executed" anything.

You're not dealing with that proof, you're dealing with your own
significantly different construction.  That is much less interesting.

[ .... ]

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.

It is when it is used as a proxy for steps of a proof.

  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.

I'm still not sure you understand what "simulation" means.

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

[ .... ]

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

Not at all.

It quite plainly does.

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

I've said before more than once, I'm not getting into fruitless
discussions about things other people have dealt with adequately.

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.

You are intellectually below the level needed to judge whether the many
errors pointed out to you are "actual" or not.  I think you can be pretty
sure that all of the others know exactly what recursion is.

[ .... ]

The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.

It's boring, though, and you've been over that point many, many times
with other people.

The above code roughly maps to the (TM equivalent)
RASP machine architecture.

Until you understand that DD emulated by HHH
according to the semantics of the x86 language
cannot possibly reach its own final halt state
your understanding will remain woefully deficient.

No sense going over any other points until after
you get this point.

You're not intellectually competent to judge other people's
understanding.  I have no interest in whether or not some function
"emulated" (whatever that might mean) by another reaches its (presumed
unique) final state.  It's all old, dull, dreary stuff which goes nowhere
very slowly.

The fact is, the halting theorem has been proven, amongs other ways, by
the proof you fail to understand.  In previous posts we had come up with
the topic of your misunderstanding of what a proof is and its status in
logic.  That discussion could have become interesting, but you just
snipped it, instead repeating for the hundredth time the old, dull,
dreary stuff.

Unless you come up with some interesting replies to the points I made in
my last post, this post will be my last in the current thread.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--
Alan Mackenzie (Nuremberg, Germany).