Re: DDD simulated by HHH cannot possibly halt (Halting Problem)

On 4/13/2025 3:49 PM, olcott wrote:

On 4/10/2025 6:44 PM, dbush wrote:

On 4/10/2025 7:39 PM, olcott wrote:

On 4/10/2025 6:25 PM, dbush wrote:

On 4/10/2025 7:07 PM, olcott wrote:

On 4/9/2025 11:05 PM, dbush wrote:

On 4/9/2025 11:54 PM, olcott wrote:

On 4/9/2025 9:11 PM, dbush wrote:

On 4/9/2025 9:47 PM, olcott wrote:

On 4/9/2025 3:56 PM, dbush wrote:

On 4/9/2025 4:35 PM, olcott wrote:

On 4/9/2025 1:58 PM, Fred. Zwarts wrote:

Op 09.apr.2025 om 19:29 schreef olcott:

>
On 4/8/2025 10:31 AM, Fred. Zwarts wrote:

Op 08.apr.2025 om 17:13 schreef olcott:

On 4/8/2025 2:45 AM, Fred. Zwarts wrote:

Op 08.apr.2025 om 06:33 schreef olcott:

>
typedef void (*ptr)();
int HHH(ptr P);
>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
int main()
{
   HHH(DD);
}
>
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input that
would otherwise prevent its own termination.

>
>
In this case there is nothing to prevent, because the finite string specifies a program that halts.

>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
This stuff is simply over-your-head.
HHH(DD) meets the above: *Simulating termination analyzer Principle*
Anyone with sufficient competence with the C programming language
will understand this.
>

Everyone with a little bit of C knowledge understands that if HHH returns with a value 0, then DDD halts.

>
DDD CORRECTLY SIMULATED BY HHH
NOT ANY OTHER DAMN DDD IN THE UNIVERSE NITWIT.
>

If HHH would correctly simulate DD (and the functions called by DD) then the simulated HHH would return to DD and DD would halt.

>
Simply over your level of technical competence.
>

But HHH failed to complete the simulation of the halting program,

>
HHH is only required to report on the behavior of its
own correct simulation (meaning the according to the
semantics of the C programming language) and would be
incorrect to report on any other behavior.

>
Which means HHH has conflicting requirements,

>
No, it just means that the ones that you have
been saying are f-cked up and no-one noticed this before.
>
 > because to perform a
 > correct simulation of its input it cannot halt itself, and therefore
 > can't report that.
In other words you simply "don't believe in" the variant
form of mathematical induction that HHH uses.

>
No, because the form it uses is "changing the input".
>
Changing the input is not allowed.

>
I never changed the input.

>
You absolutely did when you used the form of induction you did.
>
You hypothesized changing the code of HHH, which is part of the input.
>
Changing the input, hypothetically or otherwise, is not allowed.

>
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input that
would otherwise prevent its own termination.

>
Except when doing so changes the input, as you're doing.
>
Changing the input is not allowed.

>
As I pointed out simulating termination analyzers
are inherently required to terminate the simulation
of any input that would prevent their own termination.

>
Category error.  That would imply that the termination analyzer, i.e. an algorithm, has some potential choice or variation.

 termination analyzers must halt

And must map the halting function:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
And as you just said:

disagreeing with
this is ALWAYS STUPID !!!