Re: My reviewers think that halt deciders must report on the behavior of their caller

On 6/3/2025 10:08 PM, olcott wrote:

On 6/3/2025 8:54 PM, dbush wrote:

On 6/3/2025 5:39 PM, olcott wrote:

They all say that HHH must report on the behavior of
direct execution of DDD()
>

>
Because that's what we want to know about:
>
>
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
>
>

yet never bother to notice
that the directly executed DDD() is the caller of HHH(DDD).
>

>
That doesn't change the fact that we want to know if any arbitrary algorithm X with input Y will halt when executed directly, and we want an H that tell us that in *all* possible cases.
>

void DDD()
{
   HHH(DDD); // When DDD calls HHH(DDD) this HHH is not
   return;   // accountable for the behavior of its caller
}

>
It is accountable when that's what we're asking for.
>

 That is just not the way that computation actually works.
 

Are you saying that no algorithm H exists that meets the below requirements?
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
Failure to answer in your next post or within the next hour of you next post in this news group will be taken as you official on-the-record admission that in fact no H exists that satisfies the below requirements, and therefore that the theorem that the halting problems proofs prove are correct.

>
On the other hand HHH(DDD) is accountable for the
behavior that its actual input actually specifies.

>
Which is the behavior of the algorithm DDD consisting of the fixed code of the function DDD, the fixed code of the function HHH, and the fixed code of everything function HHH calls down to the OS level, and behavior is halting.
>

>
HHH(DDD) simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     *would never stop running unless aborted* then
>

>
And again you lie by implying that Sipser agrees with your meaning of the above when the fact is that he doesn't:
>
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
 > I exchanged emails with him about this. He does not agree with anything
 > substantive that PO has written. I won't quote him, as I don't have
 > permission, but he was, let's say... forthright, in his reply to me.
>
>

 The words only have one single correct meaning.
 

And because the words "simulating halt decider" means something that uses simulation to meet the below requirements:
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
That meaning can only be the behavior of UTM(D).