Re: Every HHH(DDD) is correct to reject its input

On 6/7/25 9:56 AM, olcott wrote:

On 6/7/2025 3:26 AM, Mikko wrote:

On 2025-06-06 16:33:23 +0000, olcott said:
>

On 6/6/2025 3:51 AM, Mikko wrote:

On 2025-06-05 16:01:46 +0000, olcott said:
>

On 6/5/2025 2:42 AM, Mikko wrote:

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

On 6/4/2025 2:39 AM, Mikko wrote:

On 2025-06-02 05:12:26 +0000, olcott said:
>

On 6/1/2025 6:20 AM, Mikko wrote:

On 2025-05-31 19:21:10 +0000, olcott said:
>

On 5/31/2025 2:11 PM, Mr Flibble wrote:

Olcott is doing this:
>
int main()
{
DDD(); // DDD calls HHH
}
>
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
>
Olcott should be doing this:
>
int main()
{
HHH(DDD);
}

>
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.

>
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.

>
void DDD()
{
   HHH(DDD);
   return;
}
>
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*

>
If it does then the "input" is not DDD, which specifies a halting
behaviour if HHH is a decider.

>
You can say these things only by making
sure to ignore the verified facts.

>
We can ignore irrelevant facts. But if you ignore relevant requirements
you can't prove that your soliution is correct.

>
As long as DDD emulated by HHH cannot possibly reach
its own "return" instruction final halt state then
DDD is non halting even if it is never simulated.

>
That is not what "non halting" means. If it can be exectuted to its
final halt state it is a halting computation, and we know that it
can be because it has been.

>
We cannot simply ignore and

>
Be specific: we cannot simply ignore the meaning of "non halting".
>

thus give up on

>
Ignoring is not the same as giving up. For example, you ignore
important relevant things but you don't give up.
>

the case where an input calls its own termination analyzer,
even if it is the historical precedent to give up.

>
The requirement for that case are the same as for any other case.
You may need to consider it separately if want to make your partial
decider to handle it.
>

 void DDD()
{
   HHH(DDD);
   return;
}
 The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
 *Every rebuttal to this changes the words*
 

WHich isn't the definition of halting the way you are using it, since you restrict the simulation to that of HHH.
Since UTM(DDD) will halt for every variation of DDD built on an HHH that returns an answer for HHH(DDD), every variation of HHH that returns 0 for HHH(DDD) is WRONG by the actual definitions that statement should be using.
HHH can return 0 if the correct and commplete simulation of that exact same input will never reach a final state.
These definition have the precondition that the input is the representation of a program, and since DDD calls HHH, that means its representation needs to include the code of HHH, which also then must be a program and thus have a fixed defined algorithm,
Since you are tring to avoid those requirements, "Halting" isn't a property of that input, so it is neither Halting or non-halting, but just a category error to ask about it.
This makes all your work just a big fat lie as it starts with that category error,