Re: Everyone on this forum besides Keith has been a damned liar about this point

On 6/10/25 11:45 AM, olcott wrote:

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

On 2025-06-09 15:29:26 +0000, olcott said:
>

On 6/9/2025 10:06 AM, dbush wrote:

On 6/9/2025 10:55 AM, olcott wrote:

On 6/9/2025 6:55 AM, dbush wrote:

On 6/9/2025 12:15 AM, olcott wrote:

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

>
>
Which you stated only includes the instructions of the function DDD on multiple occasions (see below),

>
It is proven that you are a liar by the part of
my reply that you erased.
>
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.
>

>
Then you admit that that finite string includes the machine code of the function DDD, the machine code of the function HHH, and the machine code of everything that HHH calls down to the OS level, and that address 000015c3 is part of DDD?

>
I admit that:
(a) DDD correctly simulated by HHH,
(b) the directly executed DDD() and
(c) the directly executed HHH()
WOULD NEVER STOP RUNNING UNLESS
HHH ABORTS ITS SIMULATION OF DDD.

>
However, because HHH aborts its simulation,
(c) the directly executed HHH(DDD) halts, and therefore
(b) the directly executed DDD() halts, and therefore
(a) the correctly simulated DDD halts.
>

 The correctly simulated DDD cannot possibly halt
when you understand that it must reach its own
simulated "return" statement final halt state.

But it DOES reach that point when CORRECTLY simulated, it is just that your actual HHH doesn't do that.

 This means that the input to HHH(DDD) does specify
a non-halting sequence of configurations. Anyone
looking at this any other way was simply wrong.
 

No, first you have admitted that your HHH and DDD are just semantically unqualified for the question, since they are categorically NOT programs, and the question is about programs.
When we fix this issue by fixing the interpretation of your terms, then it is only the "Hypothetical DDD" (different from the real DDD) that is built on and simulated by the Hypothetical HHH (which is different than the real HHH) will become non-halting, but that Hypothetical HHH just fails to decide.
With the REAL DDD and HHH, HHH just fails to correctly simulated DDD, but the actual correct simulation of that DDD will see DDD call HHH(DDD) and after a bit it will return 0 to that DDD (but only after the point that HHH gave up on its simulation) and that DDD will halt.
Thus the REAL DDD is halting, and HHH is just returning the wrong answer, and you logic *IS* the same as calling 1 equal to 2, as you confuse the pair of HHH and DDD to the "Hypothetical HHH" and "Hypothetical DDD" pair which is different.