Re: DDD specifies recursive emulation to HHH and halting to HHH1

On 3/29/2025 2:25 PM, dbush wrote:

On 3/29/2025 3:19 PM, olcott wrote:

On 3/29/2025 2:01 PM, dbush wrote:

On 3/29/2025 2:58 PM, olcott wrote:

On 3/29/2025 1:37 PM, dbush wrote:

On 3/29/2025 2:15 PM, olcott wrote:

On 3/29/2025 4:31 AM, joes wrote:

Am Fri, 28 Mar 2025 14:27:36 -0500 schrieb olcott:

On 3/28/2025 2:17 PM, dbush wrote:

On 3/28/2025 3:02 PM, olcott wrote:

On 3/28/2025 1:12 PM, dbush wrote:

On 3/28/2025 1:57 PM, olcott wrote:

On 3/27/2025 9:33 PM, dbush wrote:

On 3/27/2025 10:10 PM, olcott wrote:

On 3/27/2025 8:24 PM, dbush wrote:

On 3/27/2025 9:21 PM, olcott wrote:

On 3/27/2025 8:09 PM, dbush wrote:

On 3/27/2025 9:07 PM, olcott wrote:

On 3/27/2025 7:38 PM, dbush wrote:

>

Good, because that's all that's required for a solution to the
halting problem:
>

There are sometimes when the behavior of TM Description D
correctly simulated by UTM1 does not match the behavior correctly
simulated by UTM2.

>
Irrelevant, because to satisfy the requirements, the behavior of
the described machine when executed directly must be reported.

>
I HAVE PROVED THAT THE REQUIREMENT IS WRONG NITWIT.

According to what? WE require it. YOU are answering a different question.
>

Category error.
I want to know if any arbitrary algorithm X with input Y will halt
when executed directly.

>
It is 100% impossible for any TM to take another executing TM as its
input.

Quit that.
>

But it can take a complete description of a TM that

>
Is not always a perfect proxy for the behavior of the direct execution
of the underlying machine.

>

Uh yes it is.
>

>
That my proof that I am correct
is over your head is less than
no rebuttal what-so-ever.

>
The fact that such TM description can be given to a UTM which will exactly replicate the behavior of the described TM when executed directly proves otherwise is apparently over your head.
>

>
One cannot correctly ignore the effect that a specified
pathological relationship has between its simulator
and its input on the behavior of this input.
>

>
All it means is that HHH does not correctly map DDD to 1 as per the requirements:
>

>
int sum(int x, int y) { return x + y; }
In the same way that sum(2,3) cannot be mapped to 7.

 It can, it just wouldn't meet the requirements of the mathematical "sum" function.
 

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
Likewise if HHH reported on the behavior of the
directly executed DD it would not be reporting
on the behavior that its actual input specifies.

>
Computations apply a set of finite string transformation
rules to an input finite string to derive an output finite
string.

 And if the mapping in question is not computable, no computation can do it.
 

The same way that the sum(2,3) cannot report 7.
If it is required to report 7 then the requirement is wrong.

>
The semantic property that input DDD specifies to HHH
is non-halting.
>

 int greater_than_5(int x)
{
     return 1;
}
 Similarly, the semantic property that input 3 specifies to greater_than_5 is a number greater than 5.

The name of a function is not binding on its algorithm.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer