XPost: sci.logic

On 5/14/24 10:18 AM, olcott wrote:

On 5/14/2024 4:34 AM, Mikko wrote:

On 2024-05-13 18:07:37 +0000, Jeff Barnett said:

On 5/13/2024 3:06 AM, Mikko wrote:

Anyway, if an analyzer can never tell whether a program terminates
with every possible input then it is not a termination analyzer.

I don't think the above is true in the way you meant it. Recall that
the collection of all Turing machines with blank input tapes is the
same set of computations as the collection with arbitrary input
tapes. It's always possible to take any specific machine, T, and
initial tape, I, and produce machine T' with blank initial input tape
that is equivalent: T' initially writes I on its tape (say one
character output per state in sequence) then continues with the set
of states that comprises T.

So it is obvious that a termination analyzer (AKA a halt decider)
restricted to blank tape problems will do quite nicely and it is also
quite obvious that no such entity exists.

You only discuss halting decisions with specific inputs. THerefore you
say
nothing about termination analyzers and don't show any mistake in my
comment.

00 int H(ptr x, ptr x)  // ptr is pointer to int function
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12 }

In any case you diverged away form the whole point of this thread.
Richard is wrong when he says that there exists an H/D pair such
that D simulated by H ever reaches past its own line 03.

No, the fact that I published the proof, and you haven't even tried to
refute it shows that you have no basis for your claim and you are
nothing but a liar.

I note that you are not sure enough of your claim to take me up on the
take it or leave it challenge, or even commit to never again claiming no
one has refuted your statements, so obviously you have your doubts, but
still state something you are not sure of as a truth, which just makes
you an admitted liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/19/24 8:45 AM, olcott wrote:

On 5/19/2024 5:43 AM, Mikko wrote:

On 2024-05-18 14:35:43 +0000, olcott said:

On 5/18/2024 4:33 AM, Mikko wrote:

On 2024-05-17 15:53:33 +0000, olcott said:

On 5/17/2024 3:58 AM, Mikko wrote:

On 2024-05-16 14:08:50 +0000, olcott said:

On 5/16/2024 4:59 AM, Mikko wrote:

On 2024-05-15 14:52:01 +0000, olcott said:

On 5/15/2024 2:53 AM, Mikko wrote:

On 2024-05-14 14:10:47 +0000, olcott said:

On 5/14/2024 4:28 AM, Mikko wrote:

On 2024-05-13 14:42:05 +0000, olcott said:

On 5/13/2024 4:06 AM, Mikko wrote:

On 2024-05-12 17:12:00 +0000, olcott said:

On 5/12/2024 10:27 AM, Mikko wrote:

On 2024-05-12 13:59:28 +0000, olcott said:

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.

It is not sufficient to analyse something about >>>>>>>>>>>>>>>> termination. The
conventional meaning is that a termination analyser does >>>>>>>>>>>>>>>> not say
"yes" unless the analysed program terminates with every >>>>>>>>>>>>>>>> possible
input.

A specific program halts with every input is not at all >>>>>>>>>>>>>>> the same
thing as correctly analyzing every program with every input. >>>>>>>>>>>>>>

If you can't find out whether a program halts with every >>>>>>>>>>>>>> input even
after analyzing it with every input your analysis is not >>>>>>>>>>>>>> really
good enough for the purpose.

Anyway, if an analyzer can never tell whether a program >>>>>>>>>>>>>> terminates
with every possible input then it is not a termination >>>>>>>>>>>>>> analyzer.

My simple termination analyzer easily determines whether or >>>>>>>>>>>>> not
the limited class of programs that are in its domain halt on >>>>>>>>>>>>> every input. For example D() only has three classes of inputs >>>>>>>>>>>>> (a) Inputs that halt
(b) Inputs that do not halt
(c) itself.

If you can prove that it never gives a wrong "yes" answer >>>>>>>>>>>> you can call it a "termination analyzer". Even better if >>>>>>>>>>>> you can prove that it never gives a "yes" answer for an >>>>>>>>>>>> invalid input.

However, it is not useful if it does not say "yes" about any >>>>>>>>>>>> useful
or interesting program.

Because it is a termination analyzer it need not work for >>>>>>>>>>>>> all programs. A partial halt decider with a limited domain >>>>>>>>>>>>> seems to be the equivalent theory of computation terminology. >>>>>>>>>>>>

A partial halt decider is not a termination analyzer. Their >>>>>>>>>>>> input
spaces are distinct.

It correctly determines the halt status YES or NO
for a specific limited set of programs and ALL of
the inputs to this limited infinite set of programs.

The important difference is that a partial halting decider takes >>>>>>>>>> a pair (progam, input) for input but a halting analyzer takes >>>>>>>>>> a singlet (program).

One can analyze whether a specific program will halt with a
specific
input.

However, there is no way to ensure that the answer is ever found. >>>>>>>>

For the C version and the Turing machine version of the halting
problem
template an answer <is> found.

That is a very restricted set of programs that are not very
interesting.

If refuting the halting problem proofs is not very interesting then
what is interesting?

It is not sufficient that an answer must be given. There must be a >>>>>> proof that the wrong answer is never given. For programs outside of >>>>>> the domain and non-programs given as programs an answer that is
neither "yes" or "no" is permitted.

*Not at all. Not in the least little bit*
For the H/D pairs comprising the halting problem counter-example all >>>>> that needs be shown is that one of YES or NO <is> the correct answer. >>>>

That is trivial to show. What is hard is to tell which one is the
correct answer. Especially hard about D.

The halting problem proofs are intentionally formed to be isomorphic
to the liar paradox such that both YES and NO are the wrong answer
from every H.

Two PhD computer science professors wrote papers agreeing with this
assessment. I have had very extensive direct talks with professor
Hehner.

*Objective and Subjective Specifications* Eric C.R. Hehner 2017-7-10
https://www.cs.toronto.edu/~hehner/OSS.pdf

*The Halting Paradox Bill Stoddart* 20 December 2017
https://arxiv.org/pdf/1906.05340

I am not making an ALL KNOWING computer program that solves the
halting
problem. I am making a program that refutes the conventional halting >>>>> problem proofs.

A program alone cannot refute a proof.

My proof is step-by-step

Proofs typically are but a program can only be a part of a step
of a proof. A statement that contains a program can be a step of
a proof but the step must containt something else, too, so that
it is a statement about something.

Here are three more proofs that are self-evidently
true to anyone having sufficient knowledge of the
semantics of the C programming language:

So, no ACTUAL proof again, just stating thins as "self-evident"

Since it has been shown that your "self-evident" can be wrong quite
often, your claim of "self-evident" isn't worth the paper it (isn't)
written on.

// does not halt
void Infinite_Recursion(u32 N)
{
  Infinite_Recursion(N);
}

// does not halt
void Infinite_Loop()
{
  HERE: goto HERE;
}

// halts
int factorial(int n)
{
  if (n >= 1)
    return n*factorial(n-1);
  else
    return 1;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)