Re: The input to HHH(DDD) specifies a non-halting sequence of configurations +++

On 6/16/25 5:08 PM, olcott wrote:

On 6/16/2025 6:46 AM, Mikko wrote:

On 2025-06-15 15:00:02 +0000, olcott said:
>

On 6/15/2025 4:32 AM, Mikko wrote:

On 2025-06-14 14:07:49 +0000, olcott said:
>

On 6/13/2025 6:02 AM, Mikko wrote:

On 2025-06-11 14:03:41 +0000, olcott said:
>

On 6/11/2025 3:20 AM, Mikko wrote:

On 2025-06-10 15:41:33 +0000, olcott said:
>

On 6/10/2025 6:41 AM, Mikko wrote:

On 2025-06-10 00:47:12 +0000, olcott said:
>

On 6/9/2025 7:26 PM, Richard Damon wrote:

On 6/9/25 10:43 AM, olcott wrote:

On 6/9/2025 5:31 AM, Fred. Zwarts wrote:

Op 09.jun.2025 om 06:15 schreef olcott:

On 6/8/2025 10:42 PM, dbush wrote:

On 6/8/2025 11:39 PM, olcott wrote:

On 6/8/2025 10:32 PM, dbush wrote:

On 6/8/2025 11:16 PM, olcott wrote:

On 6/8/2025 10:08 PM, dbush wrote:

On 6/8/2025 10:50 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}
>
The *input* to simulating termination analyzer HHH(DDD)

>
No it's not, as halt deciders / termination analyzers work with algorithms,

>
That is stupidly counter-factual.
>

>
That you think that shows that

>
My understanding is deeper than yours.
No decider ever takes any algorithm as its input.

>
But they take a description/specification of an algorithm,

>
There you go.
>

which is what is meant in this context.

>
It turns out that this detail makes a big difference.
>

And because your HHH does not work with the description/ specification of an algorithm, by your own admission, you're not working on the halting problem.
>

>
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.

>
And HHH fails to see the specification of the x86 instructions. It aborts before it can see how the program ends.
>

>
This is merely a lack of sufficient technical competence
on your part. It is a verified fact that unless the outer
HHH aborts its simulation of DDD that DDD simulated by HHH
the directly executed DDD() and the directly executed HHH()
would never stop running. That you cannot directly see this
is merely your own lack of sufficient technical competence.

>
And it is a verified fact that you just ignore that if HHH does in fact abort its simulation of DDD and return 0, then the behavior of the input, PER THE ACTUAL DEFINITIONS, is to Halt, and thus HHH is just incorrect.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?

>
If HHH is not a decider the question is not interesting.

>
I switched to the term: "termination analyzer" because halt deciders
have the impossible task of being all knowing.

>
The termination problem is in certain sense harder than the halting
problem.

>
Not at all

>
That's in another sense in which nothing is harder than impossible.
>

void DDD()
{
   HHH(DDD);
   return;
}
>
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.

>
It is not a correct termination analyzer if if gives the wrong answer.

>
*Key verified facts such that disagreement is inherently incorrect*
>
(a) HHH(DDD) does not correctly report on the behavior of its caller.

>
True.
>

(b) Within the theory of computation HHH is not allowed to report
     on the behavior of its caller.

>
False. The theory of computation does not prohibit anything.

>
*Sure it does*
A termination analyzer / partial halt decider is required
to report on the sequence of state transitions that its
input specifies. It is not allowed to report on anything else.

>
The word "partial" means that it is not required to report.
But if it does report it is required to report correctly whether
the computation described by the input halts if fully executed.
An incorret report is not allowed but a lack of report is.
>

 Its input could be described as performing some
arbitrary unspecified sequence of steps, thus
"described" is an insufficiently precise term.

Nope, because that would not be a CORRECT represention of the program.
Of course, since

 To correct that error I say that the termination
analyzer must report on the behavior specified
by the sequence of steps of its input.

WHich since the input isn't a "sequence of steps" is just a category error.
It is some precise representation/desciption/specification that gives the algorithm of the program it is talking about, allowing the recreation of the steps, WHEN COMPLETELY RUN/SIMULTED.
Since HHH stops, the steps it sees are not the full "behavior of the input"

 void DDD()
{
   HHH(DDD);
   return;
}
 When one or more instructions of DDD are correctly
simulated by ANY simulating termination analyzer HHH
then this correctly simulated DDD never reaches its
simulated "return" statement final halt state.

But it is only "Correctly Simulated" when it is COMPLETELY simulated, at least as far as the determination of "Halting".

 Thus no DDD of any HHH/DDD pair halts when "halts"
is defined as reaching a final halt state.

wrong, as you are implying reaching the final state of what the input has specfied, which is the unaborted simulation of that input.
You are just claiming the right to LIE.,

 Since this *is* a verified fact any disagreement
is inherently incorrect.
 

Right, the HALTING is fully verified, and you lies are verified to be LIES.
Your problem is you don't know the meaning of the words (or do but just ignore them).
You seem to thing that computation are prone to just randomly "blowing up" and stoping in the middle of doing them.