Re: Termination analyzer defined ---OLCOTT IS WRONG !!!

On 5/12/24 9:59 AM, olcott wrote:

On 5/12/2024 3:45 AM, Mikko wrote:

On 2024-05-11 16:35:48 +0000, olcott said:
>

On 5/11/2024 4:39 AM, Mikko wrote:

On 2024-05-11 00:30:40 +0000, olcott said:
>

A termination analyzer is different than a halt decider in that it need
not correctly determine the halt status of every input. For the purposes
of this paper a termination analyzer only needs to correctly determine
the halt status of one terminating input and one non-terminating input.
The computer science equivalent would be a halt decider with a limited
domain that includes at least one halting and one non-halting input.

>
From https://www.google.fi/search?q=termination+analysis and
https://en.wikipedia.org/wiki/Termination_analysis :
>
"In computer science, termination analysis is program analysis which attempts to determine whether the evaluation of a given program halts for each input. This means to determine whether the input program computes a total function."
>
So the term "termination analysis" is already defined. The derived term
"termination analyzer" means a performer of termination analysis. That
does not agree with the propsed defintion above so a differnt term
should be used.
>
That "termination analysis" is a know term that need not be defined
is demostrated e.g. by
>
   https://arxiv.org/pdf/2101.09783
>
which simply assumes that readers know (at least approximately) what
the term means.
>

>
You are doing a great job performing an honest review!
So every time that Richard referred to a {termination analyzer} that
ignores its inputs *Richard was WRONG*

>
More important is that you are wrong whenever you use "termination
analyser" for something that by the conventional meaning isn't.
>

 A conventional termination analyzer is free to use any algorithm
as long as it analyzes termination.

Including not simulating any steps.

 

In particular, one thing that needs be considered is the input space.
A particular input is not relevant.
>

 A particular input is 100% relevant when trying to determine
the halt status of this input.
 *The pathology of an input CANNOT BE IGNORED*

Right, and thus H can't ignore that D calls THE DEFINED H, which you claim returns 0, and thus doesn't run forever.

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 It <is> the case that the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ never stops running
unless aborted when embedded_H is a simulating termination analyzer.
 

But since embedded_H WILL abort its simulation, (or H never answers and fails to be a decider), this logic is based on a false premise.

People can lie about this. What they cannot do is show steps proving
that it does stop running without being aborted.
 

It HAS been shown that the CORRECT simulation of the input to H(D,D) will terminate without being aborted. The key is that you H doesn't do a correct simulation.
Yes, your template creates a set of programs, that none of the limited set of simulating "Halt Deciders" will be able to simulate there input to a final state.
The problem is that this is NOT the definition of Halting or Non-Halting or what a Halt Decider is supposed to decide on.
You are just working on your POOP.